WO2019067817A1

WO2019067817A1 - Enhanced resource sharing using reservation

Info

Publication number: WO2019067817A1
Application number: PCT/US2018/053266
Authority: WO
Inventors: Catalina Mihaela MLADIN; Rocco Di Girolamo; Quang Ly; Shoshana Loeb; Dale N. Seed; William Robert FLYNN IV; Zhuo Chen; Mahmoud Watfa; Chonggang Wang
Original assignee: Convida Wireless, Llc
Priority date: 2017-09-29
Filing date: 2018-09-28
Publication date: 2019-04-04

Abstract

A service layer access control policy (ACP) may define which service layer registrants are permitted to access which resources and services, as well as which operations they are allowed to perform on a given resource or service. It is recognized herein that current approaches to reserving resources, for instance by relying on ACPs, are inefficient and lack capabilities that might be required by future IoT deployments. In accordance with various embodiments, data, services, and resources can be reserved and managed, for instance in RESTful systems. For example, a node or service can reserve resources, data, or services from a host, such that other requests to access the resources, data, or services during the reservation are controlled or denied.

Description

ENHANCED RESOURCE SHARING USING RESERVATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62/565,676, filed September 29, 2017, which is hereby incorporated by reference in its entirety.

BACKGROUND

[0002] Referring initially to Fig. 1, an example protocol stack 200 is shown. From a protocol stack perspective, middleware service layers (M2M/IoT service layers) are typically layered on top of existing network protocol stacks, which may consist of, for example, application protocols 204, transport protocols 206, network protocols 208, and access network protocols 210. Service layers 202 generally provide value-added services to client applications and other services. Hence, service layers are often categorized as 'middleware' service layers. For example, Fig. 1 shows the service layer 202 located in between an IP networking stack and applications 201. Service layer instances may be deployed on various network nodes (e.g., gateways and servers) to provide value-added services to network applications, device applications, and to the network nodes themselves.

[0003] An M2M/IoT service layer is an example of one type of middleware service layer specifically targeted toward providing value-added services for M2M/IoT type devices and applications. An M2M service layer can provide applications and devices access to a collection of M2M centric capabilities supported by the service layer. A few examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities, among others, can be made available to applications via application programming interfaces (APIs) that make use of message formats, resource structures, and resource representations supported by the M2M service layer. [0004] With respect to the oneM2M service layer, a goal of oneM2M is to develop technical specifications that address the need for a common M2M service layer that can be readily embedded within various hardware and software platforms. For example, such a service layer could be relied upon to connect a wide variety of devices in the field with M2M application servers worldwide. The oneM2M services layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) (i.e., service layer), which can be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). These common functions may be exposed via the Mca, Mcc and Men reference points, as shown in Fig. 2. The Mca reference point designates communication flows between an Application Entity (AE) and a CSE, and the Mcc reference point designates communication flows between two CSEs in the same M2M Service Provider domain. Communications across Mca and Mcc can take place via paired Request/Response messages, wherein each request performs a specific RESTful operation (e.g., Create, Retrieve, Update, and Delete) upon a resource hosted on the targeted CSE. Mcc' is used between CSEs located in the Infrastructure Domain of different M2M SPs. Men is used between a CSE and an underlying Network Services Entity (NSE) for services other than transport and connectivity.

[0005] An example set of common service functions (CSF) supported by oneM2M is shown in Fig. 2. A particular CSE implementation might not support every function, but a complete implementation may include some, for instance all, the functions illustrated in Fig. 2.

[0006] Per the oneM2M RESTful architecture, CSFs are represented as a set of resources. A resource generally refers to a uniquely addressable entity in the architecture having a representation that can be manipulated via RESTful methods, such as Create, Retrieve, Update, and Delete. These resources may be addressable using Universal Resource Identifiers (URIs). A resource may contain child resources and attributes. A child resource may refer to a resource that has a containment relationship with a parent resource. The parent resource representation may contain references to its child resources. The lifetime of a child resource may be limited by the parent's resource lifetime. Each resource may support a set of attributes that store information about the resource. [0007] Turning now to authorization in the oneM2M service layer, service layer authorization mechanisms may be used to control access to resources and/or services hosted in the service layer. Authorization typically involves allowing authenticated registrants to access resources and services hosted in a service layer based on statically provisioned authorization policies and assigned roles. An authorization policy may refer to a set of rules that define whether a given service layer registrant is permitted to access a protected resource or service hosted in the service layer.

[0008] A service layer access control policy (ACP) may define which service layer registrants are permitted to access which resources and services, as well as which operations they are allowed to perform on a given resource or service. Service layer authorizations may be preceded by authentication. Authentication may refer to the process of validating that the identity of a service layer registrant is associated with a trustworthy credential. How to perform an authentication process may depend on the authentication mechanism used. For example, in the case of certificate-based authentication, authentication typically involves verifying a digital signature. Mutual Authentication is a two-way authentication that may occur between a registrant and the service layer to which it is registering. Thus, mutual authentication may refer to the process of a given service layer validating the identity of a given registrant, and the process of the registrant validating the identity of the service layer.

[0009] It is recognized herein that current approaches to reserving resources, for instance by relying on ACPs, are inefficient and lack capabilities that might be required by future IoT deployments.

SUMMARY

[0010] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure. [0011] In accordance with various embodiments, data, services, and resources can be reserved and managed, for instance in RESTful systems. For example, a node or service can reserve resources, data, or services from a host, such that other requests to access the resources, data, or services during the reservation are controlled or denied.

[0012] In an example, an apparatus requests a reservation for a resource hosted at a network node, such that, during the reservation, requests to access the resource are controlled by one or more parameters associated with the reservation. The reservation may applied on top of an access control policy, such that an access to resource by an originator that has access rights from the access control policy is temporarily controlled in accordance with the one or more parameters associated with the reservation. The apparatus may send a reservation request to the network node to trigger the reservation. The reservation request may include an identity of a policy governing the reservation. In some cases, only one request triggers the reservation. The reservation request may include a command to start the reservation. The reservation request may also indicate one or more events or conditions that trigger the reservation. Further, the apparatus may send a stop request to the network node, wherein the stop request including a command to release the reservation. In an example, the apparatus obtains at least one scope parameter associated with the reservation. Scope parameters may indicate, by way of example: 1) a type of trigger permitted for the reservation; 2) one or events permitted to trigger the reservation; 3) criteria associated with a priority of the reservation; 4) criteria that identifies which nodes can initiate the reservation; 5) one or more resources permitted to be reserved during the reservation; 6) timing criteria permitted for the reservation; and 7) or whether children of the resource are permitted to be included in the reservation.

[0013] In another example, an apparatus, for instance a host node, receives a reservation request for a reservation of a resource, such that, during the reservation, access to the resource by an originator that is otherwise authorized is temporarily controlled in accordance with one or more parameters associated with the reservation. The host node compares the one or more parameters associated with the reservation to respective criteria associated with the resource, and when the one or more parameters associated with reservation are acceptable as compared to the respective criteria associated with the resource, authorizes the reservation. The one or more parameters associated with the reservation may be included in the reservation request for the reservation. While the resource is reserved during the reservation, the host node may receive another request, from an originator, to access the resource. In some cases, the apparatus determines one or more privileges associated with the originator. Based at least in part on the one or more privileges, the apparatus may allow the originator access to the resource, deny the originator access to the resource, queue the request for access to the resource at a later time, or redirect the request to a different target. The criteria associated with the resource may be stipulated in a reservation policy, which may be received within the request or locally configured at the host node. Example criteria associated with the resource includes, without limitation: 1) a type of trigger permitted to reserve the resource; 2) one or events permitted to trigger the reservation of the resource; 3) an indication of which nodes can reserve the resource; 4) one or more rules for processing requests during the reservation; 5) timing criteria permitted for the reservation of the resource; and 6) whether children of the resource are permitted to be included in the reservation.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0015] Fig. 1 depicts an example protocol stack that includes a service layer between applications and application protocols.

[0016] Fig. 2 is a block diagram that shows oneM2M Common Service Functions

(CSFs).

[0017] Fig. 3 shows an example structure of an access control policy (ACP) resource.

[0018] Fig. 4 is an example call flow for making a resource reservation in accordance with an example embodiment.

[0019] Fig. 5 is an example call flow for setting up a resource reservation in accordance with various examples. [0020] Fig. 6 is an example call flow for making a resource reservation with an explicit scope in accordance with an example embodiment.

[0021] Fig. 7 is an example call flow for making a request-based resource reservation using a reserve flag in accordance with an example embodiment.

[0022] Fig. 8 is an example call flow for making a request-based resource reservation using a reserve operation in accordance with an example embodiment.

[0023] Fig. 9 is an example call flow for making an event-based reservation in accordance with an example embodiment.

[0024] Fig. 10 is a diagram that depicts example reservation states and the

corresponding states of the reserved resource, in accordance with an example embodiment.

[0025] Fig. 11 is a block diagram that shows the oneM2M CSFs shown in Fig. 2, but with a Resource Management Function (RMF) in accordance with an example embodiment.

[0026] Fig. 12 depicts an example of an oneM2M reservation policy resource.

[0027] Fig. 13 depicts another example of an oneM2M reservation policy resource, showing information elements implemented as attributes.

[0028] Fig. 14 depicts an example reservation status oneM2M resource in accordance with an example embodiment.

[0029] Fig. 15 depicts an example reservation instance oneM2M resource with attributes in accordance with an example embodiment.

[0030] Fig. 16 depicts an example reservation policy application programming interface (API) in accordance with an example embodiment.

[0031] Fig. 17A is a system diagram of an example machine-to-machine (M2M) or Internet of Things (IoT) communication system in which one or more disclosed embodiments may be implemented;

[0032] Fig. 17B is a system diagram of an example architecture that may be used within the M2M / IoT communications system illustrated in Fig. 17 A;

[0033] Fig. 17C is a system diagram of an example M2M / IoT terminal or gateway device that may be used within the communications system illustrated in Fig. 17 A; and

[0034] Fig. 17D is a block diagram of an example computing system in which aspects of the communication system of Fig. 17A may be embodied. DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0035] As an initial matter, before proceeding with the techical solution to the technical problems described herein, various terms used herein are now clarified by way of examples. Access Control Attributes may refer to a set of parameters of an originator, target resource, or environment against which there could be rules evaluated to control access. An Access Control Policy (ACP) may refer to a set of privileges that are represented by access control rules. An Access Control Rule may refer to a set of parameters defining allowed entities for certain operations within specified contexts that each entity has to comply with to grant access to an object. An Access Decision may refer to an authorization reached when a given entity's privileges are evaluated. An Authorization may refer to the granting of rights, which may include the granting of access based on access rights. Availability may refer to a reservation- related concept for describing target resource states. Exclusive Reservations may refer to reservations that allow only privileged requests to be executed for the entire duration of the reservation. A host may refer to an entity or node that hosts one or more resources. An M2M Service may refer to M2M oriented capabilities that are provided to applications, for instance through Application Program Interfaces (APIs). An M2M Service Node may refer to a network node hosting a service layer that supports one or more M2M Services for M2M communication. A Middle Node may refer to an M2M Service Node between the Originator and the Host. A middle node common service entity (CSE) may refer to a CSE in a middle node. Non-Exclusive Reservations may refer to reservations that allow non-privileged requests to be processed during specific inactive periods of the reservation lifetime. A Non-Privileged Entity may refer to a RESTful operation Originator that is authorized based on an ACP check, but whose requests are not treated preferentially for the duration of a reservation (e.g., the requests may be rejected, delayed, etc.). An originator may refer to an entity that creates a request and transmits it to another entity. A Privileged Entity may refer to a RESTful operation Originator that is authorized based on an ACP check, and whose requests are treated preferentially for the duration of a reservation. A Privileged Request may refer to an Authorized RESTful request that is treated preferentially for the duration of a reservation. A Receiver may refer to an entity that receives a request.

[0036] A Reservation may refer to a service or procedure provided by the Host of one or more resources for specific requests (e.g., Privileged Requests) for a limited time. For example, during a given reservation, the Privileged Requests may be treated preferentially. In some cases, the privileged requests may be the only requests to be executed against the reserved resource. A Reservation Instance may refer to an occurrence of a Reservation, and may be defined and characterized by specific conditions and rules, for example, based on which requests received during a reservation are processed. A Reservation Instance Scope may refer to a set of conditions and rules based on which requests are received during a reservation. By way of example, two reservations may have the same scope if the scope parameters are equal, however, the two reservations may each be represented by individual instances. A Reservation Originator may refer to an Originator that creates and sends a reservation request and thus may initiate a procedure on behalf of Privileged Entities. An originator may be referred to as otherwise authorized if it has access rights to a given resource from an access control policy, but access to the resource is temporarily controlled in accordance with one or more parameters associated with a reservation, as described further herein. In most cases, the Reservation Originator is different than the Privileged Entity, but they could be the same in other cases. A Reservation Policy may refer to a set of rules, conditions, and restrictions used by the system to authorize a reservation request and to determine reservation scope and handling rules. In some cases, a Reservation Policy may be used in conjunction with other mechanisms to authorize a reservation instance. RESTful generally refers to systems, operations, or the like, which are designed based on REST (REpresentational State Transfer) principles.

[0037] In an example, an apparatus may obtain at least one scope parameter of the one or more parameters associated with a given reservation. The scope parameter may be obtained by discovering one or more policies associated with a network node that hosts the resource associated with the given reservation. The scope parameter may indicate at least one of, for example and without limitation: 1) a type of trigger permitted for for the reservation; 2) one or more events permitted to trigger the reservation; 3) criteria associated with a priority of the reservation; 4) criteria that identifies which nodes can initiate the reservation; 5) one or more resources permitted to be reserved during the reservation; 6) timing criteria permitted for the reservation; and 7) whether children of the resource are permitted to be included in the reservation.

[0038] Turning now to access control policies (ACPs), by way of an overview, oneM2M defines the <accessControlPolicy> resources to support authorization. The

<accessControlPolicy> resource is comprised of privileges and self privileges attributes that represent a set of access control rules defining which entities (e.g., defined by

accessControlOriginators) have the privilege to perform certain operations (e.g., defined by accessContolOperations) within specified contexts (e.g., defined by accessControlContexts). Access control policy resources may be used by common service entities (CSEs) to make Access Decisions for specific resources. It is recognized herein that, once configured, these privileges may be static from the perspective of the service layer. Thus, the service layer does not dynamically create, update, or delete privileges on-the-fly.

[0039] For a particular privileges attribute, an access control rule may define which application entity (AE) or common service entity (CSE) (AE/CSE) is allowed for which operation. In some cases, for sets of access control rules, an operation is permitted if it is permitted by one or more access control rules in the set. For a resource that is not of the <accessControlPolicy> resource type, the common attribute accessControlPolicylDs for such resources may contain a list of identifiers that link that resource to <accessControlPolicy> resources. The CSE Access Decision for such a resource may follow the evaluation of the set of access control rules expressed by the privileges attributes defined in the <accessControlPolicy> resources.

[0040] In oneM2M, the selfPrivileges attribute represents the set of access control rules for the <accessControlPolicy> resource itself. The CSE Access Decision for

<accessControlPolicy> resource follows the evaluation of the set of access control rules expressed by the selfPrivileges attributes defined in the <accessControlPolicy> resource itself. The <accessControlPolicy> resource may contain the attributes specified in Table 1 below. Table 1 : Attributes of <accessControlPolicy> Resource

[0041] The set of Access Control Rules represented in privileges and selfl'rivileges attributes may be comprised of the tuples (accessControlOriginators, accessControlContext, and accessControlOperations) that are now described. The tuple accessControlOriginators may refer to a set of service layer registrants authorized to access resources associated with this authorization policy (e.g., list of CSE-IDs or AE-IDs). The tuple accessControlContext may refer to various types of authorization context, such as accessControlTimeWindows or accessControlLocationRegions. The context accessControlTimeWindows may indicate a window during which requests are allowed. In some examples, requests occurring outside this time, to resources associated with this authorization policy, are denied. The context

accessControlLocationRegions may indicate a list of locations where service layer registrants are allowed to be located when accessing resources associated with this authorization policy. In some examples, requests from service layer registrants from locations not in this list are denied. The context accessControlIpAddresses may indicate IP addresses of service layer registrants allowed to access resources associated with this authorization policy. In some examples, requests from service layer registrants that have IP addresses that are not in this list are denied. The tuple accessControlOperations may refer to the set of operations that each authorized service layer registrant is authorized to perform (e.g., Create, Retrieve, Update, and Delete).

[0042] In oneM2M, accessControlOriginators is a mandatory parameter in an access- control -rule-tuple. It represents the set of Originators allowed to use this access control rule. The set of Originators is described as a list of parameters, where the types of the parameter can vary within the list.

[0043] Table 2 below describes the supported types of parameters in the parameter accessControlOriginators . Table 2. Parameters in accessControlOriginators

[0044] In some cases, when the originatorlD is the resource-ID of a <group> resource that contains <AE> or <remoteCSE> as members, the Hosting CSE of the resource checks if the originator of the request matches one of the members in the memberlDs attribute of the <group> resource (e.g., by retrieving the <group> resource). In some examples, if the <group> resource cannot be retrieved or does not exist, the request is rejected.

[0045] In oneM2M, accessControlContexts is an optional parameter in an access- control -rule-tuple that contains a list, wherein each element of the list, when present, represents a context that is permitted to use this access control rule. Each request context is described by a set of parameters, wherein the types of the parameters can vary within the set. Table 3 describes the supported types of parameters in accessControlContexts. In some cases, the following

Originator accessControlContexts is considered for an access control policy check by the CSE.

Table 3. Parameters in accessControlContexts

[0046] In oneM2M, accessControlOperations is a mandatory parameter in an access- control -rule-tuple that represents the set of operations that are authorized using this access control rule. Table 4 describes the supported set of operations that are authorized by accessControlOperations. In an example, the following accessControlOperations are considered for an access control policy check by the CSE.

Table 4. Parameters in accessControlOperations

Nil me Description

RETRIEVE Privilege to retrieve the content of an addressed resource

CREATE Privilege to create a child resource

UPDATE Privilege to update the content of an addressed resource

DELETE Privilege to delete an addressed resource

DISCOVEB Privilege to discover the resource

NOTIFY Privilege to receive a notification

[0047] In oneM2M, accessControlPolicylDs is a common attribute of many oneM2M resources. This attribute contains a list of identifiers of an <accessControlPolicy> resource. The privileges attribute defined in the <accessControlPolicy> resource that are referenced determines who is allowed to access the resource containing this attribute for a specific purpose (e.g., Retrieve, Update, Delete, etc.). If a resource type does not have an accessControlPolicylDs attribute definition, then the accessControlPolicylDs for that resource may be governed in a different way. For example, the accessControlPolicylDs associated with the parent may apply to a child resource that does not have an accessControlPolicylDs attribute definition, or the privileges for access are fixed by the system. The corresponding resource type definitions and procedures may be referenced to see how access control is handled in such cases.

[0048] In some cases, if a resource type does have an accessControlPolicylDs attribute definition, but the (optional) accessControlPolicylDs attribute is not set, or it is set to a value that does not correspond to a valid, existing <accessControlPolicy> resource, or it refers to an <accessControlPolicy> resource that is not reachable (e.g. because it is located on a remote CSE that is offline or not reachable), then the system default access privileges apply. In some examples in oneM2M, resources are accessible if and only if the privileges (i.e., stored as privileges or selfPrivileges attribute of <accessControlPolicy> resource) allow it. Therefore, resources have an associated accessControlPolicylDs attribute, either explicitly (setting the attribute in the resource itself) or implicitly (by using the parent privileges or the system default policies). Thus, the system may provide default access privileges in case the Originator does not provide a specific accessControlPolicylDs during the creation of the resource. [0049] As described above, in Resource Oriented Architecture (ROA)-based systems, commands are executed when the Originators of RESTful operations are authorized at the Receiver for the requested operation. Authorizations may be performed by using Access Control checks based on local Access Control Policies (ACPs). ACP rules may grant access to multiple originators and are used for the access control of a large set of distinct resources, especially for network storage, which may create various technical problems. For example, it is recognized herein that, if several resources are to be used by a single entity at the expense of blocking operations from other entities, existing ACPs may need to be temporarily modified and/or more granular ACPs may need to be created. It is further recognized herein that this may require multiple operations that affect a large set of resources for a reservation that is for only a temporary duration. As a result, it is recognized herein that, in some cases, ACP modifications are an inefficient way of implementing reservations.

[0050] In addition, creating and/or updating ACPs may require special privileges in order to preserve the security of the system. Therefore, it is also recognized herein that, in some cases, ACPs are not well suited to provide dynamic privilege definitions.

[0051] To better understand the technical problem to which the technical solution described here is addressed, a use case is now presented for illustration. By way of example, consider a management application of a university campus, in which a central coordinator interacts with hundreds of devices and vehicles owned and operated by different stakeholders. For example, the central coordinator may interact with smartphone apps from individual users or authorized university personnel, buses from the transportation authority, university shuttles, traffic signals from the municipality, etc. In the example, the given devices allow the central coordinator access to specific resources hosted locally on each device, and access control is managed at the device level. In an emergency or special event situation, for example, the coordinator may need uninterrupted access to specific resources on the devices. During the uninterrupted access, the coordinator may need the state of each device to remain unchanged by other entities. Continuing with the example, a first reservation may be needed temporarily for shuttles and traffic lights in a specific area, in order to coordinate event traffic. And a second reservation may be needed for resources on students' mobile devices to allow for updates with critical event information, while temporarily blocking changes, for example, from the regular class alert system.

[0052] It is recognized herein that actions, such as the example actions described above, may require changes in the ACPs resources in many devices, where the ACPs are distinct from each other. It is further recognized herein that these changes may require individual RESTful operations to be performed for each change, thereby creating a large messaging overhead. In an example embodiment, however, a specific originator, which may already have privileges in these heterogeneous and distributed ACPs, can reserve a resource temporarily, with the existing privileges.

[0053] By way of another example, a variety of IoT applications are emerging, for instance in the industrial domain, which require tight integration with each other. For example, on a factory assembly floor with multiple robots, an application may require a status and functionality to be tightly coupled. Supervisory applications may provide monitoring and coordination at several levels. In one case, a complex functional flow may be implemented that triggers an action in one robot when several pieces of equipment reach a certain state (as indicated by associated resource attributes). The robot receives a notification in this case, but its actions may be predicated on the certainty that the equipment states are not modified for a certain duration from the time the notification is triggered. In more complex cases, some types of modifications should be allowed to occur, but not others.

[0054] It is recognized herein that existing Service Layer technologies do not coordinate operations or perform selective processing of incoming requests to allow (or prioritize) specific requests, such that data, resources, or services can be dynamically reserved on the fly, for example, based on context available in the service layer. It is further recognized herein that ACP modifications are an inefficient way of implementing reservations as a temporary filtering of operations (which are otherwise authorized), in order to provide privileged access to specific entities. Mainstream applications, such as those included in the examples above, may require dynamic but secure mechanisms to selectively and/or temporarily filter the operations allowed to be performed and to maintain resource state. Without an efficient and secure reservation mechanism resource sharing and access based solely on ACPs, it is recognized herein that the burden of coordinating more complex resource access schemes may fall on individual applications, which then may need the context of their peers that share access to the same resources.

[0055] As the size and complexity of IoT deployments increases, the burden of developing specialized applications with resource sharing capabilities may increase

exponentially. Thus, it is recognized herein that, in some cases, IoT/M2M Service Layer technologies are positioned to assist applications with resource sharing via resource reservation management.

[0056] Turning now to resource reservation, in accordance with an example

embodiment, a Reservation Management Function (RMF) 1102 (see Fig. 11) provides reservation services (for data, services, and resources) using various information

elements/metadata and new RESTful request parameters. In an example RESTful environment, a resource can be maintained in a state where only a subset of the RESTful operations targeting the resource are processed. In some cases, one or more operation originators (Privileged entities) are prioritized over others (Non-privileged entities). While many examples are described in the context of reserving resources for convenience, it will be understood that the described concepts can be applied to data and services in RESTful environments, without limitation. In an example, resource reservation is limited to entities that already have access to the resource through access control policies. The activation of a reservation may allow one or more Privileged entities to modify a given resource, while preventing Non-Privileged entities from modifying the same resource. The Privileged entities may be determined from information provided by a reservation as outlined in a Reservation Setup described below. Thus, in accordance with various examples, both Privileged and Non-Privileged entities may already have access to a resource via ACP, and enabling a reservation may determine which entities are Privileged and which are Non- Privileged.

[0057] Referring now to Fig. 4, an example system 400 is shown that includes an originator 402, a target or host 404, and an entity or node 406, which may be privileged or non- privileged. It will be appreciated that the example system 400 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Fig. 4, and all such embodiments are contemplated as within the scope of the present disclosure.

[0058] Figs. 4 to 9 (described hereinafter) illustrate various embodiments associated with reserving resources. In these figures, various steps or operations are shown being performed by one or more nodes, apparatuses, devices, servers, functions, or networks. For example, the apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms apparatus, network apparatus, node, server, device, entity, network function, and network node may be used interchangeably. It is understood that the nodes, devices, servers, functions, or networks illustrated in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of, and executing on a processor of, a node of such network, which may comprise one of the general architectures illustrated in Figs. 17A or 17B described below. That is, the methods illustrated in Figs. 4 to 9 may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a network node, such as for example the node or computer system illustrated in Figs. 17C or 17D, which computer executable instructions, when executed by a processor of the node, perform the steps illustrated in the figures. It is also understood that any transmitting and receiving steps illustrated in these figures may be performed by communication circuitry (e.g., circuitry 34 or 97 of Figs. 17C and 17D, respectively) of the node under control of the processor of the node and the computer-executable instructions (e.g., software) that it executes. It is further understood that the nodes, devices, and functions described herein may be implemented as virtualized network functions.

[0059] Referring in particular to Fig. 4, the host (target) 404 may be an entity that hosts the resource that is the target of the reservation. In some cases, the host 404 is the entity in charge of managing and enforcing the reservations. Assuming a system implementing access control, in some cases, the Host 404 also performs the access control checks and enforces the reservation rules that grant access and prioritize operations within specified contexts. The (Reservation) Originator 402 is the entity requesting/placing/making the reservation. In some cases, the Originator might also be the Host. Originators, such as the originator 402, which are different entities than a given host, such as the host 404, may initiate a reservation procedure via Reservation Requests. In some examples, reservation requests are implemented using RESTful operations available in the system. Several types of Reservation Requests are described herein. In some examples, only authorized Originators are able to request and be granted reservations.

[0060] During an example reservation, filtering occurs during which some requests, which can be referred to as Privileged Requests, are treated preferentially. For example, in some cases, privileged requests may be the only ones to be executed against the reserved resource for the duration of the reservation. The remainder of the requests may be referred to as Non- Privileged (or regular) Requests. The originators of Privileged Requests may be referred to as Privileged Entities. With respect to privileges, Reservation-based privileges may be applied and enforced logically after the CRUD privileges in existing ACPs. Thus, for example, a Privileged Request, in accordance with various examples, is also an authorized (or CRUD-privileged) request based on ACPs. Further, in this context, Non-Privileged Requests are operations which would be allowed should the reservation not exist (otherwise, they would be Un-Authorized Requests).

[0061] Therefore, in some cases, resource reservation is limited to entities that already have access to the resource through ACPs. Such entities can be referred to as otherwise authorized originators. Thus, the reservation can be applied on top of the ACP, such that an access to the reserved resource by an originator that has access rights from the ACP is temporarily controlled in accordance with one or more parameters associated with the

reservation. A reservation allows the processing of requests from one or more Privileged Entities while preventing requests from Non-Privileged Entities to be processed. Privileged Entities may be determined from information provided during the reservation procedure, as described in detail later in this disclosure.

[0062] Turning now to the concept of availability, availability may refer to a state that describes a target resource state. It may pertain to specific or generic resources and it may be changed during the reservation process. The Availability states of the target resource may be controlled by the resource Host based on reservation-related events or requests. In an example, Availability states include Available (A) or Reserved (R). Available (A) may refer to the resource state when there are no reservations triggered, when an existing reservation has stopped, or when the timing information of the reservation indicates an inactive time. Reserved (R) may refer to the state of a resource that is the target of a reservation, wherein the reservation may have been created and triggered (e.g., if an event other than creation is required), and may be active (e.g., if periods of activity and inactivity are specified).

[0063] Idle (I) refers to another additional availability state that may be used in some implementations. Idle (I) may refer to a specialized version of the Reserved (R) state, for instance when there are no Privileged Entities configured. The Idle state may be used, for example, when the Host uses reservations to lower processing load selectively.

[0064] In various examples, a Reservation Policy is used by the system to authorize a reservation request, and to determine the corresponding reservation scope and handling rules. A Reservation Policy may be used in conjunction with other mechanisms to authorize a reservation instance (occurrence). A Reservation Instance may be used to detail the conditions and rules of a reservation occurrence, for example, based on which of the requests received during a reservation are processed. These conditions and rules may also be referred to as Reservation Instance Scope. By way of example, two reservations may have the same scope if the parameters are equal, however, they may be represented by individual instances. For example, a single Reservation Policy may be provided on a device, and the policy may specify that only reservations shorter than 1 millisecond (ms) are allowed for the hosted resources. A first reservation request may ask for a reservation for Privileged Entity A. If the request asks for a 1 second reservation, it will not be authorized. If it requests a 0.5 ms reservation, it will be authorized and Reservation Instance X may be created. If another request asks for a 0.3ms reservation of the same resource, at a different time, for Privileged Entity B, it may be authorized and a new Reservation Instance may be created. Reservation policies and Reservation Instances are further described in detail below. The scope and handling rules specified by the Reservation Policy may allow reservations with a variety of options which are described in detail herein. For example, Exclusive and Non-Exclusive Reservations can be distinguished from each other. Non- Exclusive Reservations may refer to reservations that allow non-privileged requests to be processed during specific inactive periods of the reservation lifetime. Exclusive Reservations may refer to reservations that allow only privileged requests to be executed for the entire duration of the reservation. [0065] Referring again to Fig. 4, in accordance with the illustrated example, a reservation is setup at 0. As a result, the target resource Host 404 may begin services using (or based on) a reservation because the host 404 may have the necessary Reservation Policy information. In some cases, no Reservation Instances are created at 0. At 1, a reservation may be triggered, thereby creating a Reservation Instance. In an example, explicitly scoped reservations are used by entities other than the Host 404 to trigger a reservation. For example, the originator or requester 402 may directly provide the reservation instance scope information that allows the Host 404 to enforce the reservation via a regular CREATE operation. In an example Request-based registration, the Originator 402 uses enhancements in the RESTful request to trigger a reservation. The reservation instance scope may be provided implicitly, for example, by the host 404 determining the reservation instance scope based on local information. In an example event-based registration, the host 404 monitors one or more specific events that trigger the registration. Thus, the reservation instance scope may be defined implicitly by the host 404.

[0066] At 2, the reservation is authorized and created by the host 404. This may be closely linked to triggering at 1, in that the received request is authorized based on the information available at the host 404 from the setup at 0 (Reservation Policy). If authorized, the request may result in a new Reservation Instance being created. The parameters (e.g., scope) of the Reservation Instance may be based on the Reservation Policy and information included in the triggering request. At 3, external requests received during reservations are managed, for example, based on the requests are received from privileged entities or non-privileged entities. For example, during the reservation, the host 404 processes requests based on the reservation rules. In some examples, the processing of Privileged Requests is different than the processing of Non-Privileged Requests. At 4, the reservation is stopped or released. The reservation stop or release may depend on the triggering at 2. When the reservation is stopped, different processing incoming requests may cease.

[0067] Thus, as outlined above and as described further herein, an appratus or node may receive a reservation request for a reservation of a resource, such that, during the reservation, access to the resource by an originator that is otherwise authorized is temporarily controlled in accordance with one or more parameters associated with the reservation. The apparatus may compare the one or more parameters associated with the reservation to respective criteria associated with the resource. When the one or more parameters associated with reservation are acceptable as compared to the respective criteria associated with the resource, the apparatus may authorize the reservation. The one or more parameters associated with the reservation may be included in the reservation request for the reservation. The criteria associated with the resource may be stipulated in a reservation policy. While the resource is reserved during the reservation, the apparatus may receive a resource access request, from an originator that is otherwise authorized to access the resource, to acces the resource. The apparatus may determine one or more privileges associated with the originator. Based at least in part on the one or more privileges, the apparatus may allow the originator access to the resource, deny the originator access to the resource, queu the resource access request for access to the resource at a later time, or redirect the resource access request to a different target.

[0068] Referring generally to Fig. 11, the Reservation Management Function (RMF) 1102 can be implemented as a standalone service or as a sub-service of an IoT Service Layer. The RMF service can be hosted on various types of network nodes such as, for example, IoT servers, IoT gateways, and IoT devices. The RMF 1102 may manage the reservations for the resources hosted on that node. The RMF 1102 may be used in tandem with access control in processing incoming requests. In some cases, not all the resources on a node may support reservation. For example, in some cases, only some resources types may be reserved. Or in a specific implementation, resources of certain types might not be subject to reservations due to local policies. Moreover, by way of further example, some resources might not be subject to reservations during a certain period of time.

[0069] The RMF 1102 may maintaining reservation-specific information and metadata including, for example, policies, information pertaining to individual reservation instances, etc. The RMF 1 102 may process incoming requests for reservations or trigger reservations based on local events. The RMF 1102 may process incoming requests from Privileged and Non- Privileged Entities during a reservation. The RMF 1102 may maintain a reservation instance state and metadata, and manage its lifecycle. The RMF 1102 is further described below.

[0070] Various information elements (e.g., data, metadata, attributes, parameters, etc.) may help implement the RMF 1102. Example information is grouped logically below, but in some cases, the elements may be provided separately or omitted, depending on implementations. Additional details about their use (e.g., role within procedures, alternative implementations, etc.) are provided below.

[0071] For example, policy information may be provided in an initial, (pre)

configuration step. Policy information may be used to authorize reservations and to determine reservation instance scope and handling rules (e.g., which types of reservations will be allowed). Policy Information may include, for example and without limitation, a description, request privilege information (e.g., who is allowed to request a reservation), trigger criteria (e.g., what types of triggers may be used to start a reservation), and instance scope criteria (e.g., ranges or values for parameters to authorize a request). An apparatus or host node may receive an identity of the reservation policy in the reservation request, and may retrieve the reservation policy based on the identity of the reservation policy. In an example, the reservation policy is received via a local configuration.

[0072] Reservation instance information may be provided or created at the reservation request time. Reservation instance information may consist of the rules and conditions based upon which the requests received during a reservation are processed. The Instance Information may depend on, for example and without limitation, the type of trigger that requested the reservation, the reservation policy information described above, or on other local policies that may be available at the host. Status Information may be maintained at the host by the RMF 1102. Status information may be local or exposed via a resource. Status Information may include maintenance to associate reservation instances and policies with target resources, or information used to maintain a reservation state of the target.

[0073] Policy Information is now discussed in further detail. As mentioned above, reservation policies may be used to authorize reservations and to determine reservation instance scope and handling rules. Various information blocks may part of a policy, such as, for example and without limitation, Policy Description, Request Privileges, Trigger Context, and Instance Scope Criteria.

[0074] With respect to a Reservation Policy Description

(reservationPolicyDescription), each Reservation Policy may be described by a unique ID. In addition, access control privileges for the policy may be provided, to be used if the policy is implemented as a resource. Policy access control self-privileges may be defined in a manner similar to the selfPrivileges described above, for example, due to the role of the policy in the authorization process.

Table 5 : Example Reservation Policy Description

[0075] With respect to Reservation Request Privilege Information

(reservationRequestPrivilege), in some cases, only authorized entities are able to request and be granted reservations, for example, because of the possible impact of a reservation on other operations and entities. This block of information may provide rules that define which

Originator is allowed to request reservations and within which context. Context may include, for example and without limitation, Originator location, target Host location, time window for reservation request, etc. In some cases, the Reservation Request Privilege Information may be implemented as a single reservationRequestPrivilege attribute, and defined as an ordered list of Originators, contexts, and Targets, which are logically linked.

Table 6: Example Reservation Request Privilege Information

[0076] With respect to Reservation Trigger Criteria (reservationTriggerCriteria), reservation trigger criteria may provide information about the types of triggers that should be used in the reservation process. For example, in some cases, trigger criteria may indicate that the Host can support only explicit requests in order to be able to create a reservation instance. For each trigger type supported, there may be additional context information provided.

Table 7: Example Reservation Trigger Criteria

[0077] With respect to Reservation Instance Scope Criteria (instanceScopeCriteria), in addition to providing authorization information, Reservation Policies may be used to provide reservation criteria. As an example, a criterion could be that only reservations shorter than a specific time interval (e.g., 1) minute can be created based on this policy. These criteria may be used as a menu of allowed reservation options, or as constraints for operating within a specific policy. The criteria may apply to the individual reservation instances. In some cases, not all the criteria need to be provided explicitly. For example, if no specific criteria are provided in the policy, then reservation instances with any values for corresponding attributes may be allowed by the Host. Conversely, if a reservation instance is requested to be created based on this policy, but the corresponding attribute does not match the scope criteria (including not being present), the reservation instance creation request may be rejected. Similarly, reservation instance updates resulting in attributes not matching the criteria may be rejected. In some examples, the various criteria provided in the instanceScopeCriteria may be used in conjunction with other local policies at the receiving entity, e.g.: maximum percent time a resource may be reserved;

maximum duration for consecutive reservations on same resource or by the same requestor; etc. In some cases, depending on implementation, the local policies may be exposed as additional attributes of the reservation instance scope criteria in the table below. Alternatively, some of the attributes detailed below may be implemented instead via local policies, and thus might not be exposed.

Table 8: Example Reservation Instance Scope Criteria

For example, in some cases, only reservations that provide an explicit release

(stop) operation or time can be created based on this policy.

notificationCriteria Provides criteria based upon which the rules for notification handling for individual reservation instances can be set.

subscriptionCriteria Provides criteria based upon which the rules for subscription handling for individual reservation instances can be set.

discoverabilityCriteria Provides criteria based upon which the rules for handling of discovery

requests can be set.

retrievalCriteria Provides criteria based upon which the rules for handling of RETRIEVE (or non-modifying operations in general) can be set.

requestHandlingCriteria Provides criteria based upon which the rules for handling of incoming non- privileged requests can be set.

redirectionCriteria Provides criteria based upon which the rules for redirection handling for individual reservation instances can be set.

reservationEventNotification Provides criteria based upon which the rules for providing notifications- Criteria related to the lifecycle of the individual reservation instance can be set. generatedReservationlnstanc List of reservation instances generated based on this policy, provided as links eList or IDs, for example. Alternatively, the reservation instances created based on this policy may be child resources of the policy.

[0078] Reservation Instance Information (reservationlnstance) may consist of the rules and conditions based upon which Privileged and Non-Privileged Requests received during a reservation are processed. These rules and conditions may also be referred to as reservation scope (e.g., lifetime, descendant handling, etc.). The information that defines each reservation instance may depend on the type of trigger that initiated the reservation. In Explicit, Request- Based reservations, the reservation instance parameters may be provided in the reservation request itself (hence the term "explicit"). Before the reservation instance is created, in some examples, the parameters provided in the request are validated against the criteria

(instanceScopeCriteria) in the policy. If the operation is authorized and the validation is

successful, the reservation instance may be created. Given that Explicit Request-Based

reservations may be implemented via RESTful requests, the reservation instance in this case may be exposed, for example, via an associated resource. In Implicit, Request-Based reservations, the scope of the reservation may be based on an existing reservation instance or a policy, such that the instance parameters are not explicitly provided in the request. The reservation instance parameters may or may not be exposed by the Host in a RESTful manner, depending on

implementation. In Implicit, Event-Based reservations, the scope of the reservation may be based on the policy, and there is no explicit request. The reservation instance parameters may or may not be exposed by the Host in a RESTful manner, depending on implementation.

[0079] The information that defines each reservation instance may also depend on the governing Reservation Policy. For example, the instanceScopeCriteria part of the governing policy may be used to validate the parameters of the instance, even if the instance parameters will not be exposed, in some cases. The information that defines each reservation instance may also depend on local policies at the receiving entity. For example, local policies may indicate a maximum allowed time for one reservation, a maximum percent time reservation that can occur, a maximum number of certain types of reservations, etc. Depending on implementation, these may be part of the governing Reservation Policy.

Table 9: Example Reservation Instance Information

reservation instances. For example, in some cases, the reservation may apply to all the descendants of the target resource, may be limited to only a number of levels under the target resource, etc. Rules may also indicate which types of descendants may be affected by the reservation, e.g., only the subscription descendants of the target, etc.

releasePvule Provides rules for reservation release. For example, if too few or no privileged operation occurs for a certain amount of time, the reservation may be automatically released. The attribute may contain or point to a specific CRUD request which, if received, has the effect of releasing the reservation. Other release rules may be based on the number of non-privileged requests received within a period of time, low CPU utilization, low battery level of the Host, etc.

notificationPvule Provides rules for notification handling e.g. that during reservation notifications to non-privileged entities will be disabled, buffered, or forwarded.

subscriptionPvule Provides rules for subscription handling, e.g. that during reservation the creation of subscriptions will still be allowed or not for non- privileged entities.

discoverabilityRule Provides rules for handling of discovery requests. For example, it may indicate that discovery requests from Non-Privileged entities should consider this resource non-existent, include it in discovery responses or provide an indicator.

retrievalRule Provides rules for handling of RETRIEVE operations. Retrieval of the reserved resource may still be allowed for Non-Privileged entities during a reservation, since it does not lead to modification. This functionality may be combined with that of other rules such as discoverabilityRule and notificationRule, by implementing a single nonModifyingOperationRule.

requestHandlingRules Provides rules for handling of incoming non-privileged requests.

Simple rules may indicate only that the requests should be responded to with: "resource does not exist", "resource reserved", "access control failure", etc. The rule may also indicate that the requests should be redirected to a different target, that they should be queued for non-exclusive reservations, etc.

An example type of rule may also indicate that, in addition to a specific cause (e.g. "resource reserved"), timing information that can be used for scheduling of other communications. For example the response can include "re-try after" or "reserved until" values based on activity time and/or lifetime, or the reservationTiming information.

More elaborate schemes may provide different handing rules per request type, etc. By way of example, only RETRIEVE requests are to be queued during a non-exclusive reservation, all others should be rejected. This may effectively implement a non-exclusive reservation for RETRIEVE, and exclusive reservation for the other operations. Special handling rules may be provided for other reservation requests received during an existing reservation, e.g. that queueing of a specific number (or for a duration of time) of incoming reservation requests may be specified.

redirectionRule Provides rules for redirection of incoming non-privileged requests, if the requestHandlingRules indicates redirection. Simple rules may indicate only a target resource to which all non-privileged requests should be redirected to. More elaborate schemes may provide different handling or different redirection target per request type, or other context, e.g. redirect only when battery low.

reservationEventNotificationRule Provides rules for handling of notifications of specific events related to this reservation instance. For example, for a periodic reservation, notification should be sent to a list of recipients at reservation start, 2 seconds before each reservation period begins, when the reservation lifetime ends or the reservation is released, etc. Another reservation events may be un-privileged access, and the rule may indicate that a notification should be sent for each unprivileged access.

contextCollectionRule Provides rules for collection of context information related to the reservation. For example, it may indicate that statistics for non- privileged requests received should be stored in a specific container, or that specific state changes should be logged/saved during the reservation

trigger Optional parameter that indicates which event or request triggered this reservation instance. This information may be useful to be exposed to management applications, which may decide to send a release request depending on context.

[0080] With respect to Status Information (reservationStatus), information about the reservation status of a target may be maintained at the Host by associating it with the target (e.g., via child resources of the target or the target resource may be defined to include these parameters). The status information may also be maintained by the Host so as to not be exposed via a resource. In some cases, not all resources or resource types have to support reservation, and reservation services might not be available on all devices. The following information may be maintained by the Host for each reservation target, presented by way of example and without limitation.

Table 10: Example Status Information

provided implicitly, e.g., by the presence of availabilityStatus, through indicators or policies indicating that all resources on a specific Host are reservable or not, etc.

availabilityStatus Provides the status of the resource from an Availability (reservation) perspective i.e. Available/Reserved/Idle. The presence of this element can be used to indicate that the resource can be managed through reservation services.

governingReservationPolicylD Optional ID to the governing reservation policy. This information may be used in the Implicit Scope Reservations described herein.

pendingReservationList Optional list of the reservation instances targeting this resource that have been triggered. This information may be used in the Implicit Scope Reservations described herein methods.

[0081] Turning now to Enhanced Access Control Polices (R-ACPs), special privileges for performing reservation operations may be specified by enhancing the generic Access Control Policy (which provides rules for RESTful operations) and adding REServation as one of the controlled operations. For example, an enhancement to the privileges attributes in oneM2M is now considered, such that accessControlOperations may have the values shown in Table 11.

Table 11 : Example Enhanced Access Control Polices

[0082] In descriptions below, such reservation enhanced access control policies are referred to as Reservation Access Control Policy (R-ACP), which is based on the oneM2M ACP terminology, so as to not be confused with the Reservation Policy aspects as a whole. In some cases, systems implementing R-ACPs can also use regular ACPs. In an alternative example to the use of R-ACP, local rules/policies may be used. As an example, rules may be used that specify that all REServation operations may be granted authorization based on the same privileges as another operation (e.g., same as DELETE).

[0083] In accordance with an example embodiment, a new RESTful request parameter, which can be referred to as reserveFlag, is used for implementing reservation services. In some cases, this request parameter may be used with existing RESTful operations (e.g., CRUDN). For example, the parameter may indicate whether the CRUDN request shall also place a reservation on the target resource. Using START/STOP/NULL (or RESERVE/RELEASE/NULL) as example values for the flag, a START value may indicate whether the request originator also places a reservation on the resource. The STOP value may indicate a release of an existing reservation. This is an example implementation of reservations while performing regular RESTful operations. In some cases, the NULL value may be used for regular operations without added reservation functionality.

[0084] If the CRUDN operation is successful, for example, the request result may include a confirmation if the reservation was successful as well (e.g., in the operation status). If the CRUDN operation is not successful, there may be a local policy indicating that the reservation should not be done, or that may indicated in the response also via the operation status, for example.

[0085] The reserveFlag request parameter may be used in conjunction with a

Reservation Policy being available at the target. This parameter may be used for the Request- based Implicit Reservation procedure described in detail below, for example.

[0086] Conditional parameters may be used with the reserveFlag. In some cases, when RESTful operations use the reserveFlag parameter for implementing reservation services, additional request parameters may be used to provide dynamic information for the reservation. For example, a resDescendants flag may have the following example values and corresponding usages:

• resDescendants = TARGET-ONLY: indicates that only the target resource should be included in the reservation

• resDescendants = TARGET+CHILDREN: indicates that the target resource and its

immediate children should be included in the reservation.

• resDescendants = TARGET+ DESCENDANTS: indicates that the entire resource tree containing descendants of the target resource should be included in the reservation.

In one example, this flag (resDescendants) may be implemented with TRUE/FALSE values that indicate if all the descendants should be included (TRUE) or not (FLASE) in the reservation, along with the target resource.

[0087] As another example, a nonModifyingOperationsAllowed flag may have the following example values and corresponding usages:

• nonModifyingOperationsAllowed = TRUE: indicates that non-privileged request types, which do not result in resource changes (e.g., RETRIEVE), should still be allowed during the reservation (Non-Exclusive reservation).

• nonModifyingOperationsAllowed = FALSE: indicates that Reservation Policy rules apply for all operations, including, e.g., RETRIEVE.

[0088] In some cases, the conditions listed in Table 9 may be implemented as request parameters as well, for example, if they need to be modified in a dynamic fashion.

[0089] If the CRUDN operation is successful, the request result may include a confirmation if the reservation, based on the given conditions, was successful. For example, this confirmation may be included in the operation status. If the CRUDN operation is not successful, there may be a local policy indicating that the reservation should not be done, or it may be indicated in the response, also via the operation status for example.

[0090] Turning now to reservation setup (step 0 in Fig. 4), in order to enable reservation services, the host may be configured with various information, such as, by way of example and without limitation, reservation request criteria, reservation instance (scope) criteria, or a policy description. Reservation request criteria may include information enabling the host entity to process and authorize a reservation request. It may include the reservation request privilege information detailed herein and the reservation trigger criteria detailed herein.

Reservation instance (scope) criteria may include information enabling the host to create and manage reservation instances. Given that reservations create dependencies between multiple functions and entities, in some cases, scope can defined based on specific constraints or criteria. These constraints can be defined and provided in advance. A policy description may include information concerning the overall policy identification and management, as detailed herein.

[0091] Referring to Fig. 5, in accordance with the illustrated example, a

<reservationPolicy> resource includes reservationPolicyDescription,

reservationRequestPrivilege, reservationTriggerCriteria, and instanceScopeCriteria, which provides the information to determine which reservation requests can be authorized and which reservation instances can be created. The setup results in the creation of a <reservationPolicy> resource at the host 404 (or provisioning of the equivalent information).

[0092] It will be understood that implementation of the reservationRequestPrivilege functionality may vary as desired, such that this information might not be explicit in the

<reservationPolicy> resource. Instead, for example, R-ACP identities may be provided in the policy. In this case, the reservation setup may also include the creation of R-ACP resources.

[0093] The information provided to the host 404 during the setup phase may be delivered by various mechanisms (e.g., device management, pre-provisioning, CREATE

RESTful request, etc). Fig. 5 depicts alternative examples using CREATE RESTful requests to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other combinations and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, the alternative examples shown in Fig. 5, and all such embodiments are contemplated as within the scope of the present disclosure.

[0094] Referring to Fig. 5, in Alternative example A (Alt. A), R-ACP1 is created at the host 404 at A2, and the <reservationPolicy> resource RP1 is created at the Host 404 at A5. The RP1 reservationRequestPrivilege points to R-ACP1. In Alternative example B (Alt. B), <reservationPolicy> resource RP2 with reservationRequestPrivilege = (resOrigB, resContextB) is created at the host 404 at B2, based on the request from the originator 402 (at B 1). In

Alternative example C (Alt. C) R-ACP3 is created at the host 404 (at C2), based on the message received from the originator 402 (at CI). The <reservationPolicy> resource RP3 is created at the Host 404, based on the message received from the originator 402 at C4. In this example, reservationRequestPrivilege is not used (NULL). This example configuration may allow only reservations with an implicit scope. In Alternative example D ("Alt D), an API at the Host 404 is used directly input parameters, resulting in the creation of the <reservationPolicy> resource RP4. Thus, no setup signaling is used, as shown.

[0095] After the setup results in one or more policies being provided to the host 404, any resource creator (or authorized entity) can specify a Reservation Policy when creating or updating that resource (via the governingReservationPolicylD of the reservationStatus). This action (specifying a Reservation Policy) may considered part of the Setup. Having a reservation policy associated with a target resource may be used to process implicit scope reservations (e.g., both request and event based).

[0096] Turning now to reservation triggering, explicitly scoped resource reservations may be triggered by a reservation originator via a create operation that provides the

reservationlnstance explicitly in the request. The request (trigger) may be authorized by the host using the reservationRequestPrivilege and the reservationTriggerCriteria of the corresponding reservation policy. The scope of the ensuing reservation may be based on the reservationlnstance parameters validated against the instanceScopeCriteria, which may also be indicated in the reservation policy. For example, criteria associated with the resource may include at least one of, without limitation: 1) a type of trigger permitted to reserve the resource; 2) one or more events permitted to trigger the reservation of the resource; 3) an indication of which entities can reserve the resource; 4) one or more rules for processing requests during the reservation; 5) timing criteria permitted for the reservation of the resource; and 6) whether children of the resource are permitted to be included in the reservation.

[0097] Referring to Fig. 6, an example system 600 is shown that includes a reservation originator 602, a host 604, and request originators 606, which may be privileged or non- privileged. It will be appreciated that the example system 600 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Fig. 6, and all such embodiments are contemplated as within the scope of the present disclosure.

[0098] Fig. 6 depicts an example for an explicitly scoped resource reservation that uses alternative example A from the setup that is described with reference to Fig. 5. The host 604 receives the reservation request at 1. At 2a, the information contained in the request and the associated policy are used by the Host 604 to authorize and create the resource, which is further described below. At 2b, the Host 604 sends a response to the Originator 604 indicating whether the request was authorized. At 4b, the host 604 manages other requests during the reservation, which is described in detail below. At 3, the host 604 may receive on or more request from one or more request originators 606. These requests may be treated differently by the host 604, based on the reservation privileges of the respective request originator. For example, when the policy information and the reservation request originate at different entities, the reservation request originator 602 may first discover the policies supported by the host 604. The reservation originator 602 can then reference the policy in the request (at 1) and can also use it to select the reservation instance scope parameters that it needs and that also meet the validation criteria. The host 604 uses the policy referenced to authorize the reservation request, at 2a.

[0099] Referring now to Fig. 7, an example request-based reservation (with implicit scope) using the reserveFlag request parameter is shown. Fig. 7 shows an example system 700 that includes a reservation originator 702 (resOrigB), a host 704, and request originators 706, which may be privileged or non-privileged. It will be appreciated that the example system 700 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Fig. 7, and all such embodiments are contemplated as within the scope of the present disclosure.

[00100] As described above, the reserveFlag parameter may be used with any RESTful requests to place a reservation on a target resource. When the parameter indicates START (at 1) for a reservation, the Host 704 creates a reservation, at 2a. In one example, the reservation parameters used by the host 704 are based on the reservation policy indicated via the

governingReservationPolicylD of the target resource. Access control for the reservation request may be based on originator privileges for the requested CRUDN operation in the target resource ACP, and based on originator privileges for the reservation operation based on

reservationRequestPrivilege of the policy. In another example, if the target resource ACP IDs point to an R-ACP, access control is based on originator privileges in the R-ACP for both the requested CRUDN operation and for the reservation operation (RES). Reservation rules may be provided via local policies. In some cases, parameters such as timing, target resource, etc. are provided implicitly.

[00101] Still referring to Fig. 7, the value STOP for reserveFlag, which is sent by reservation originator 702 to the host 704 at 4a, may indicate the release of reservation. The release may be subject to policies such as duration, etc., which are checked at 4b by the host 704. If the STOP operation is successful, the request result sent at 4c by the host 704 to the originator 702 may include a confirmation of the success/failure of the reservation action (either stop or start) in the status, for example.

[00102] Thus, an apparatus may request a reservation for a resource hosted at a network node, such that, during the reservation, requests to access the resource are controlled by one or more parameters associated with the reservation, wherein the reservation is applied on top of an access control privilege, such that an access to the resource by an originator that has access rights from the access control privilege is temporarily controlled in accordance with the one or more parameters associated with the reservation. Requesting the resource may include sending a reservation request to the network node, wherein the reservation request comprises an identity of a policy governing the reservation. Requesting the resource may include sending only one reservation request to the network node, wherein the only one reservation request includes a command to start the reservation; or sending a reservation request that indicates one or more events or conditions that trigger the reservation. Further, a stop request may sent to the network node, wherein the stop request may include a command to release the reservation.

[00103] Group operations, including implicitly scoped reservations for example, may be implemented by using a single reservation policy that is associated with the entire group, e.g. via a <group> resource. In some cases, group operations may involve checking the ACPs of all the group members for RESTful requests. This check may also be performed for operations that include a reservation request. For example, in oneM2M, group operations may target the <fanoutPoint> virtual resource child of a group resource. In the case of implicitly scoped reservations, in one example, for each of the group members, the host 704 uses the

governingReservationPolicylD of the member resource to identify the policy. The host 704 then then checks the Reservation request originator 702 against the reservationRequestPrivilege of the policy (at 2a). When the privilege is granted, the host 704 checks the requested operation, e.g. UPDATE using the ACPs of the group member. In another example, for each of the group members, the host 704 uses the R-ACPs of the member resource ,and access control is based on the originator privileges in the R-ACP for both the requested operation (e.g. UPDATE) and for the reservation operation (RES).

[00104] In some cases, group-related optimizations may include restrictions for all group members to use the same reservation policy or R-ACP. Another level of optimization might be achieved by restricting the group resource itself to also use the same reservation policy or R-ACP as the entire group membership. The example flow illustrated in Fig. 7 uses

Alternative B from the setup described with reference to Fig. 5. The STOP request is sent at 4a at the end of the reservation, although alternatives may be implemented, such as a reservation lifetime expiration, etc.

[00105] Referring now to Fig. 8, an example system 800 includes a reservation originator 802, a host 804, and request originators 806, which may be privileged or non- privileged. It will be appreciated that the example system 800 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Fig. 8, and all such embodiments are contemplated as within the scope of the present disclosure. [00106] As shown in Fig. 8, a request-based resource reservation may also explicitly designate REServe as the RESTful operation of the request sent at 1 from the reservation originator 802 to the host 804. Access control in this example is based on privileges of the originators 806, using the ACPs of the target resource. Thus, in this example, R-ACPs are used and associated with the target resource. The setup at 0 therefore provides the Host 804 with the R-ACP, and associates it with the target resource.

[00107] The reservation scope used by the Host 804 may be based on the Reservation Policy indicated via the governingReservationPolicylD or may be provided via local policies. Parameters such as timing, target resource, etc. may be provided implicitly. The example call flow depicted in Fig. 8 uses the alternative example C from the Setup described with reference to Fig. 5. It includes also the UN-REServe request at the end of the reservation (at 4a), although alternatives may be implemented for releasing the reservation, such as a reservation lifetime expiration, etc.

[00108] Group reservation operations for the example illustrated in Fig. 8 may be handled the same as any other CRUD operation, using the REServe operation privileges in the R- ACP. In systems like oneM2M, this may involve, for example, checking the R-ACPs of all the group members (which are provided in the group definition) before fanning out the operation to each of the members.

[00109] Referring now to Fig. 9, an example event-based reservation (with Implicit Scope) is shown. Fig. 9 an example system 900 includes a reservation originator 902, a host 904, and request originators 906, which may be privileged or non-privileged. It will be appreciated that the example system 900 is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the embodiments disclosed herein in addition to, or instead of, a system such as the system shown in Fig. 9, and all such embodiments are contemplated as within the scope of the present disclosure.

[00110] In accordance with the illustrated example, an event-based resource reservation is used by the host 904 for local resource and request management. The host 904 monitors the events listed in the reservationTriggerContext attribute of a local

<reservationPolicy> resource. At 1, one of the reservation events listed in the trigger attribute occurs, and thus the triggering occurs. In response to the triggering, at 2, the host 904 creates the corresponding reservation based on the reservation instance scope criteria of the policy. As in the request-based reservation (which are also implicitly scoped), the policies provided for use with event-based implicit reservations may provide fewer scope options to be used to determine the necessary reservation instance. In some cases, the originator may be the resource host itself by default, or the reservationTriggerContext may specify an originator. The default or explicit originator may be used for the authorization process in conjunction with the

reservationRequestPrivilege element of the policy. Alternatively, in another example

implementation of event-based reservations, no reservationRequestPrivilege is required and all reservations triggered based on the governing event-based policy are authorized.

[00111] When the triggering event occurs, an alternative to creating a reservation instance is for the reservationTriggerContext to specify different reservation management actions related to an existing reservation instance. For example, an first Event El may the reservation instance, a second Event E2 may activate/deactivate the next reservation period provided by the reservation timing, a third Event E3 may release the reservation instance, and a fourth Event E4 may delete the reservation, etc.

[00112] Target resource related events that may trigger reservation actions may include, presented by way of example and without limitation: changes to a parameter, generation of a notification for a local subscription, or the like. Other types of events that can be used include, for example and without limitation, events associated with timers, counters, CPU utilization, etc. In order to implement more sophisticated event-based triggering, for instance triggering related to other resources, the reservationTriggerContext attribute may contain links to resources (e.g., <eventConfig> or <statsConfig> in oneM2M) which in turn define the triggering events. Combinations of these events may be used also to define patterns that are matched and monitored by the Host in order to trigger the reservation. As described herein, the host can reference any events for triggering via the reservationTriggerContext, so as to trigger

reservations.

[00113] Turning now to reservation authorization and creation, in some cases, only authorized originators are able to request and be granted reservations. Reservations triggered by the mechanisms described above may need to be authorized. When the policy information and the reservation request originate at different entities, the reservation request originator may first discover the policies supported by the host, and may then choose one to reference and determine the exact parameters to include in its reservation request. Then, the host may use the referenced policy to authorize the reservation request.

[00114] Using the information elements detailed herein, examples for providing authorization information are presented below, without limitation:

• R-ACPs, which can grant specific rights for reservation-related operations. This includes, in an Explicitly Scoped Reservation example, the special CREATE operation for a <reservationInstance>.

• The reservationRequestPrivilege, which is an attribute that may be employed such that the <reservationPolicy> provides, in addition to the reservation instance constraints, the functionality of an ACP for reservation operations, given that it may include

reservationPolicySelfPrivileges and reservationRequestPrivilege as well.

• Standardized information or local rules/polices. For example, rules may specify that all reservation operations may be granted authorization based on the same privileges as another operation (e.g., same as DELETE).

[00115] With respect to explicitly scoped reservations, in addition to the access control decision, the Host may verify the request by comparing the requested reservation values in the <reservationInstance> resource to be created against the criteria provided in the

<reservationPolicy> resource. In some cases, the host rejects requests for reservations that have parameters/scope that are incompatible with the policy criteria. The Host may also use other local information and/or policies in order to authorize the request. For example, the Host may reject a reservation if another one is active, or it may queue that request, as described above. This procedural phase may conclude with the <reservationInstance> resource as a child of the <resourcePolicy> or of one of the reservation target resources. The association between reservation targets, reservation instances, and the associated policies can be provided via attributes such as pendingReservations, governingReservationPolicylD, and

generatedReservationlnstanceList.

[00116] Turning now to managing requests during reservations, when a resource Rl is reserved based on a <reservationInstance> (e.g., it is included in the reservationTarget attribute), the host processes incoming CRUD requests. For example, if the reservation is active (e.g., based on reservationTiming and resource expiration), the host may check to determine whether the request originator is listed as a privilegedOriginator. If it is a privileged originator, the host may proceed to check the privileges of the request originator against the ACPs of the target resource. If the operation is a RETRIEVE, for example, and retrievalRule indicates it, the operation is executed and the appropriate response is returned. If the privileged originator has operation privileges based on the ACP, the operation may also be executed and the appropriate response is returned.

[00117] If the privileged originator does not have operation privileges based on the ACP for the requested operation, although it may for other operations, a response may be returned indicating that originator does have enough access privileges. If the originator is not a privileged originator (e.g., it is a Non-Privileged Entity/Originator), then the host may proceed based on requestHandlingRules and redirectionRule attributes of the reservation instance. For example, if the incoming operation is a DISCOVERY request, the discoverabilityRules may attribute indicate handling if the target Resource should be included in the result of a non- privileged request. By way of example, in some cases, if the target resource would have been discovered, should the reservation have not been in place, and the discoverabilityRule =

Discoverable, then the target resource is included in the discovery request even if the requester is Non-Privileged for DISCOVERY rights. By way of another example, if the target resource would have been discovered, should the reservation have not been in place, and the

discoverabilityRule = NotDiscoverable, then the target Resource is included in the discovery request when the requester is Non-Privileged for DISCOVERY rights. If requestHandlingRules indicates specific responses to the Non-Privileged requests (e.g., "resource does not exist", "resource reserved", "access control failure", etc.) a response message may be constructed accordingly and sent to the request Originator. In some cases, if requestHandlingRules indicates that the requests should be queued for non-exclusive reservations, the requests may be queued accordingly and responses may be provided when they get executed or expire. Specific handing rules may be specified for reservation requests themselves. For example, a rule may specify that a certain number of reservation requests should be queued. As with any handling rules specified per request type, separate queues (e.g., general, reservation, etc.) may be implemented by the RMF 1102. In another example, if requestHandlingRules indicates that the requests should be redirected to a different target, the redirectionRule may be used to determine the redirection target and the related context, and the request may be redirected accordingly.

[00118] Turning now to subscription and notification, entities that perform RESTful operations on resources that are subject to reservation may implement specific logic pertaining to the reservation state of the target resources. If the availabilityStatus attribute is implemented, for example, subscribing to changes in this attribute may inform requesters of the target resource state. In one example, a reservationEventNotificationRule is used for more sophisticated rules. As an example, the rule may instruct the host to "notify all the direct subscribers to the target resource when it becomes reserved or available" (e.g., even if they did not subscribe to the availabilityStatus attribute changes). Such a rule also allows the notifications to be provided even if the availability status is not exposed via an attribute.

[00119] Further notification enhancements may be implemented using the

notificationRule element, which may specify the effect that the parent resource reservation has on notifications. For example, notifications related to the reserved resource that is targeted that are sent to non-privileged entities may be stopped during reservation, or all notifications may be processed as if the reservation did not occur. The attribute may allow the implementation of more advanced rules, (e.g., that notifications to non-privileged entities should be forwarded to a different entity, buffered, buffered and only last one sent at reservation expiration, etc.).

[00120] The subscriptionRule element may also be used to implement enhancements, by allowing, for example, subscriptions to be created by non-privileged entities during the reservation. This may allow, for example, non-privileged entities that receive a response indicating that a request was not processed due to a reservation, to initiate the creation of a subscription to monitor for specific changes relevant to the request. The subscriptionRule may also indicate if such subscriptions should be automatically deleted or inactivated when the expiration expires.

[00121] Thus, one or more target entities may subscribe to a given resource so as to receive notifications related to the resource. While the given resource is reserved during a reservation, and based on the reservation policy, the host appartus or node may temporarily, for example and without limitation: 1) refrain from sending the notifications related to the resource, to the one or more target entities, 2) delay the notifications related to the resources, so as to send the notifications to the one more target entities at a later time; or 3) deny other originators from creating new subscriptions to the resource.

[00122] Referring to Fig. 10, a diagram shows example state transitions of an example reservation (and the associated reservation instance). Fig. 10 also shows the corresponding example states of the reserved resource, which are described in detail below. The states of the reserved resource may be managed by the RMF 1102 based on the states of the Reservation Instance.

[00123] Referring to Fig. 11, as shown, Reservation Manage Function (RMF) 1102 can be implemented as a CSF in an oneM2M system. The RMF 1102 CSF can be hosted on various types of Service Layer nodes, such as IoT servers, IoT gateways, and IoT devices. In some examples, the RMF 1102 provides management of the reservations for the resources hosted on that CSE. The RMF 1102 may use functionality provided by other CSFs, such as addressing and Identification, Security, Data Management and Repository, etc.

[00124] In a specific example deployment, not all resources hosted on a specific RMF CSE need to be provided with reservation support, or need to have triggered reservations at a given time. At the same time, in some cases, not all the oneM2M resource types may be specified to support reservation. Example oneM2M resources well-suited for reservation services include content sharing resources such as container, flexContainer and timeSeries; AEs, nodes, groups, etc.

[00125] In an example oneM2M system, the Information Elements detailed above can be implemented using enhancements of existing resources (e.g., ACPs to support R-ACP) and example new resources detailed below. In order to implement R-ACPs, in some cases, attributes of the oneM2M <accessControlPolicy> may be enhanced. Referring to Fig. 3, as detailed previously, the oneM2M <accessControlPolicy> resource 302 is comprised of privileges attributes 304 and selfPrivileges attributes 306 that represent a set of access control rules defining which AEs/CSEs are allowed to perform which operations. This set of Access Control Rules represented are comprised of tuples containing accessControlOriginators and

accessControlOperations. [00126] In an example, the accessControlOperations mandatory parameter may be enhanced with the RES and UN-RES operations detailed above, as shown in Table 12.

Table 12. Example New Parameters in accessControlOperations to support R-ACP

[00127] Referring to Fig. 12, the new <reservationPolicy> resource 1201 (shown at a high-level) can be provided to the host during the Setup using pre-provisioning, RESTful operations, etc. Fig. 12 indicates, by the description attribute 1202, that the reservation policy attribute 1201 may be a complex attribute that may be implemented in a variety of ways (e.g., e.g. ordered list, multiple attributes, etc.) For example, the description attribute 1202 may translate into separate attributes, resevationPolicylD and reservationPolicySelfPrivileges, as described above. In some cases, some or all of information elements detailed above are applicable to the reservation policy. In some examples, the parameters that are not exposed RESTfully may be absent from the resource definition and may be implemented as local settings/policies instead. The <reservationPolicy> resource 1201 may be created at the resource tree base (<CSEBase>), at the <node>, etc. The reservationPolicy resource 1201 with the information elements detailed above implemented as attributes is shown in Fig. 13.

[00128] In other example implementations, the reservationRequestPrivilege may be implemented, by way of example and without limitation: via three individual attributes:

reservationRequestOriginator, reservationRequestContext, and reservationRequestTarget; as a single attribute of type M2M: accessControlRule; or as a single attribute of type M2M: acpType. [00129] Referring now to Fig. 14, the <reservationStatus> resource 1402 is an example implementation of the reservationStatus information described above. The attributes may be implemented also as individual attributes of the resource types that allow reservations. In one example, in order to provide support for reservation of <timeSeries> resources, the status information attributes are made part of the <timeSeries> resource definition itself (see example Table 13 in which new attributes shown, although existing attributes may also be included).

Table 13. Example New attributes of <timeSeries> resource for reservation support

[00130] In another example, in order to provide support for reservation of <timeSeries> resources, the resource type definition may be enhanced to include <reservationStatus> 1402 as a child resource, such as shown in Table 14:

Table 14: Example Child resources of <timeSeries> resource

[00131] In some examples, referring to Fig. 15, a <reservationInstance> resource 1502 may be created at the resource tree base (<CSEBase>), as a child of the <reservationPolicy> or as the child of one of the reservation targets. Having the <reservationInstance> as a child of the <reservationPolicy> may useful for using the reservation for multiple targets, and for encapsulating reservation-related information. Having the <reservationInstance> 1502 as a child of the reservation target resource may be useful for enabling discovery of the reservation instances affecting a resource by external entities. As with the reservation policy, if reservation instance information is not exposed RESTfully, this information may be managed locally by the RMF.

[00132] Various new request parameters may be included in any oneM2M request in accordance with various embodiments. For example, the reserveFlag may be set to START to indicate that a request shall also place a reservation on the target resource. If the reserveFlag is set to STOP, an existing reservation may be released. In some cases, the flag may be used in conjunction with a Reservation Policy or a Reservation Instance being available for the target resource.

[00133] Referring to Fig. 16, an example API 1600 is shown that can used to provide settings and to create reservation policies. In this example, the API provides inputs for parameters that are reflected in the <reservationPolicy> resource 1201, as well as for parameters that might be enforced locally. The illustrated example corresponds to Alternative example D in the reservation setup described with reference to Fig. 5. In the example, the API provides a choice of 13 parameters to be provided to create <reservationPolicy> 1201, though it will understood that less parameters, additional parameters, or alternative parameters may be provided as desired. For example, if choosing to provide criteria/limitations for "targets" and "timing", a user can effectively set values for reservationTargetResourceCriteria and

reservationTimingCriteria. In some cases, the RMF may enforce a local policy to limit the maximum reserve time per resource, after which new reservations are denied. Thus, a reservation policy can be received via a local configuration.

[0100] It will be understood that the API in Fig. 16 is presented by way of example, and the APIs may be constructed as desired, such that configuration parameters can be viewed and altered as desired. It will be understood that the example user interfaces can be used to monitor and control alternative parameters as desired. It will further be understood that APIs can provide a user with various information in which the user is interested via a variety of charts or alternative visual depictions. [00134] Fig. 17A is a diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway or M2M service platform may be a component of the IoT/WoT as well as an IoT/WoT service layer, etc. Any of the devices, functions, nodes, or networks illustrated in any of Figs. 4 to 11 may comprise a node of a communication system such as the one illustrated in Figs. 17A-B.

[00135] As shown in Fig. 17A, the M2M/IoT/WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may comprise multiple access networks that provides content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[00136] As shown in Fig. 17A, the M2M/ IoT/WoT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, devices, of the network. For example, the Field Domain may include M2M gateways 14 and terminal devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M terminal devices 18 may be included in the M2M/ IoT/WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M terminal devices 18 are configured to transmit and receive signals via the communication network 12 or direct radio link. A M2M gateway device 14 allows wireless M2M devices (e.g. cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M

application 20 via an M2M service layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example. Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[00137] Referring to Fig. 17B, the illustrated M2M service layer 22 in the field domain provides services for the M2M application 20, M2M gateway devices 14, and M2M terminal devices 18 and the communication network 12. It will be understood that the M2M service layer 22 may communicate with any number of M2M applications, M2M gateway devices 14, M2M terminal devices 18, and communication networks 12 as desired. The M2M service layer 22 may be implemented by one or more servers, computers, or the like. The M2M service layer 22 provides service capabilities that apply to M2M terminal devices 18, M2M gateway devices 14 and M2M applications 20. The functions of the M2M service layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[00138] Similar to the illustrated M2M service layer 22, there is the M2M service layer 22' in the Infrastructure Domain. M2M service layer 22' provides services for the M2M application 20' and the underlying communication network 12' in the infrastructure domain. M2M service layer 22' also provides services for the M2M gateway devices 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22' may communicate with any number of M2M applications, M2M gateway devices and M2M terminal devices. The M2M service layer 22' may interact with a service layer by a different service provider. The M2M service layer 22' may be implemented by one or more servers, computers, virtual machines (e.g., cloud/compute/storage farms, etc.) or the like. [00139] Still referring to Fig. 17B, the M2M service layer 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The service layer 22 and 22' also enables M2M applications 20 and 20' to communicate through various networks 12 and 12' in connection with the services that the service layer 22 and 22' provide.

[00140] The M2M applications 20 and 20' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, and other servers of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20' .

[00141] Generally, a service layer (SL), such as the service layers 22 and 22' illustrated in Figs. 17A and 17B, defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE), which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the service layer may be implemented in a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a service layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device, or the like) having the general architecture illustrated in Fig. 17C or 17D described below.

[00142] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SO A) and/or a resource- oriented architecture (ROA) to access services, such as the above-described Network and Application Management Service for example.

[00143] Fig. 17C is a block diagram of an example hardware/software architecture of a node of a network, such as one of the nodes, devices, functions, or networks illustrated in Figs. 4 to 10, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figs. 17A and 17B. As shown in Fig. 17C, the node 30 may include a processor 32, a transceiver 34, a transmit/receive element 36, a speaker/microphone 38, a keypad 40, a display/touchpad 42, non-removable memory 44, removable memory 46, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the notifications and triggers related thereto described herein.

[00144] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the node 30 to operate in a wireless environment. The processor 32 may be coupled to the transceiver 34, which may be coupled to the transmit/receive element 36. While Fig. 17C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip. The processor 32 may perform application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or communications. The processor 32 may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

[00145] As shown in Fig. 17C, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the transmitting and receiving steps described herein (e.g., in Figs. 8-10) and in the claims. While Fig. 17C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[00146] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, devices, and the like. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals. [00147] In addition, although the transmit/receive element 36 is depicted in Fig. 17C as a single element, the node 30 may include any number of transmit/receive elements 36. More specifically, the node 30 may employ MTMO technology. Thus, in an embodiment, the node 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[00148] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[00149] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 to reflect the status of a node or configure a node (e.g., Fig.16), and in particular underlying networks, applications, or other services in communication with the UE. The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[00150] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[00151] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect devices, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[00152] Fig. 17D is a block diagram of an exemplary computing system 90 which may also be used to implement one or more nodes of a network, such as nodes, devices, functions, or networks illustrated in Figs. 8-10, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in Figs. 17A and 17B. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within central processing unit (CPU) 91 to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, which performs additional functions or assists CPU 91. CPU 91 and/or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for security protection.

[00153] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus. [00154] Memory devices coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92.

Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[00155] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[00156] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT -based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[00157] Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97 that may be used to connect computing system 90 to an external communications network, such as network 12 of Fig. 17A and Fig. 17B, to enable the computing system 90 to communicate with other nodes of the network. The communication circuitry, alone or in combination with the CPU 91, may be used to perform the transmitting and receiving steps described herein (e.g., in Figs. 4 to 9) and in the claims.

[00158] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[00159] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[00160] The following is a list of acronyms relating to service level technologies that may appear in the above description:

ACP Access Control Policy

ACR Access Control Rule

AE Application Entity

App Application

CoAP Constrained Application Protocol

CSE Common Service Entity

CSF Common Service Function

HTTP Hypertext Transfer Protocol

IN Infrastructure Node

IoT Internet of Things

IP Internet Protocol

M2M Machine-to-Machine

MN Middle Node

NSE Underlying Network Services Entity

REST REpresentational State Transfer

ROA Resource Oriented Architecture

RMF Reservation Management Function

TCP Transmission Control Protocol

UDP User Datagram Protocol

URI Uniform Resource Identifier

Claims

What is Claimed:

1. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform operations comprising:

receiving a reservation request for a reservation of a resource, such that, during the reservation, access to the resource by an originator that is otherwise authorized is temporarily controlled in accordance with one or more parameters associated with the reservation;

comparing the one or more parameters associated with the reservation to respective criteria associated with the resource; and

when the one or more parameters associated with reservation are acceptable as compared to the respective criteria associated with the resource, authorizing the reservation.

2. The apparatus as recited in claim 1, wherein the one or more parameters associated with the reservation are included in the reservation request for the reservation.

3. The apparatus as recited in any one of claims 1 and 2, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform operations comprising:

while the resource is reserved during the reservation, receiving a resource access request, from the orginator that is otherwise authorized, to access the resource;

determining one or more privileges associated with the originator; and

based at least in part on the one or more privileges:

allowing the originator access to the resource;

denying the originator access to the resource;

queuing the resource access request for access to the resource at a later time; or redirecting the resource access request to a different target.

4. The apparatus as recited in any one of the preceding claims, wherein the criteria associated with the resource are stipulated in a reservation policy.

5. The apparatus as recited in claim 4, wherein one or more target entities subscribe to the resource so as to receive notifications related to the resource, and the apparatus further comprises computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform further operations comprising: while the resource is reserved during the reservation, and based on the reservation policy, temporarily: 1) refraining from sending the notifications related to the resource, to the one or more target entities, 2) delaying the notifications related to the resources, so as to send the notifications to the one more target entities at a later time; or 3) denying other originators from creating new subscriptions to the resource.

6. The apparatus as recited in claim 4, the apparatus further comprising computer- executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform further operations comprising:

receiving an identity of the reservation policy in the reservation request; and

retrieving the reservation policy based on the identity of the reservation policy.

7. The apparatus as recited in claim 4, the apparatus further comprising computer- executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform operations comprising:

receiving the reservation policy via a local configuration.

8. The apparatus as recited in any one of the preceding claims, wherein the criteria associated with the resource comprise at least one of 1) a type of trigger permitted to reserve the resource; 2) one or more events permitted to trigger the reservation of the resource; 3) an indication of which entities can reserve the resource; 4) one or more rules for processing requests during the reservation; 5) timing criteria permitted for the reservation of the resource; and 6) whether children of the resource are permitted to be included in the reservation.

9. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform operations comprising:

requesting a reservation for a resource hosted at a network node, such that, during the reservation, requests to access the resource are controlled by one or more parameters associated with the reservation,

wherein the reservation is applied on top of an access control policy, such that an access to the resource by an originator that has access rights from the access control policy is temporarily controlled in accordance with the one or more parameters associated with the reservation.

10. The apparatus as recited in claim 9, wherein requesting the reservation comprises sending a reservation request to the network node, the reservation request comprising an identity of a policy governing the reservation.

11. The apparatus as recited in claim 9, wherein requesting the reservation comprises sending only one reservation request to the network node, the only one reservation request including a command to start the reservation.

12. The apparatus as recited in claim 9, wherein requesting the reservation comprises sending a reservation request that indicates one or more events or conditions that trigger the reservation.

13. The apparatus as recited claim 9, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform further operations comprising:

sending a stop request to the network node, the stop request including a command to release the reservation.

14. The apparatus as recited in claim 9, the apparatus further comprising computer- executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to perform further operations comprising:

obtaining at least one scope parameter of the one or more parameters associated with the reservation.

15. The apparatus as recited in claim 14, wherein requesting the reservation further comprises sending a reservation request to the network node, and wherein the reservation request complies with the one or more parameters.

16. The apparatus as recited in any one of claims 14 and 15, wherein obtaining the at least one scope parameter of the one or more parameters comprises discovering one or more policies associated with the network node that hosts the resource.

17. The apparatus as recited in any one of claims 14 to 16, wherein the at least one scope parameter indicates at least one of: 1) a type of trigger permitted for the reservation; 2) one or more events permitted to trigger the reservation; 3) criteria associated with a priority of the reservation; 4) criteria that identifies which nodes can initiate the reservation; 5) one or more resources permitted to be reserved during the reservation; 6) timing criteria permitted for the reservation; and 7) whether children of the resource are permitted to be included in the reservation.