Patent Description:
An M2M/IoT SL can provide applications and devices access to a collection of M2M/IoT oriented capabilities. A few examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via Application Programming Interfaces (APIs) which make use of message formats, resource structures and resource representations supported by the M2M/IoT SL.

From a protocol stack perspective, SLs are typically situated above the Application Protocol Layer and provide value added services to applications they support. Hence SLs are often categorized as 'middleware' services. <FIG> shows an exemplary service layer <NUM> between the Application Protocols <NUM> and Applications <NUM>.

oneM2M has defined a M2M/IoT SL. The oneM2M service layer can provide "horizontal" services that can be utilized by different "vertical" M2M systems and applications, such as e-Health, fleet management, and smart homes. The architecture of the oneM2M SL, as shown in <FIG>, defines a Common Service Entity (CSE) <NUM> that supports four reference points. The Mca reference point interfaces with the Application Entity (AE) <NUM>. The Mcc reference point interfaces with another CSE <NUM> within the same service provider domain and the Mcc' reference point interfaces with another CSE in a different service provider domain. The Mcn reference point interfaces with the underlying network service entity (NSE) <NUM>. A NSE <NUM> provides underlying network services to the CSEs, such as device management, location services and device triggering. A CSE <NUM> contains multiple logical functions called "Common Service Functions (CSFs)", such as "Discovery", "Data Management & Repository". <FIG> illustrates the CSFs supported by oneM2M.

As shown in <FIG>, the oneM2M architecture enables a number of nodes including Application Service Node (ASN) <NUM>, Application Dedicated Node (ADN) <NUM>, Middle Node (MN) <NUM>, Infrastructure Node (IN) <NUM>, and a Non-oneM2M Node (NoDN) <NUM>.

An ASN <NUM> is a Node that contains one CSE and contains at least one Application Entity (AE). As one example of a physical mapping, an ASN <NUM> could reside in an M2M Device.

An ADN <NUM> is a Node that contains at least one AE and does not contain a CSE. As one example of physical mapping, an Application Dedicated Node <NUM> could reside in a constrained M2M Device.

A MN <NUM> is a Node that contains one CSE and contains zero or more AEs. As one example of physical mapping, a MN <NUM> could reside in an M2M Gateway.

An IN <NUM> is a Node that contains one CSE and contains zero or more AEs. A CSE in an IN <NUM> may contain CSE functions not applicable to other node types. As one example of physical mapping, an IN <NUM> could reside in an M2M Service Infrastructure.

A non-oneM2M Node <NUM> is a Node that does not contain oneM2M Entities (neither AEs nor CSEs). Such Nodes represent devices attached to the oneM2M system for interworking purposes, including management.

The possible configurations of inter-connecting the various entities supported within the oneM2M system are illustrated in <FIG>.

In oneM2M, an entity any create a <container> resource as a place to store data as shown in <FIG> and in <FIG>. The actual data content is stored in the <contentInstance> child.

oneM2M defines an announced resource scheme to facilitate the resource discovery. As shown in <FIG>, after sensor <NUM> creates a resource at the M2M Gateway <NUM>, sensor <NUM> may request the M2M Gateway <NUM> to announce the information to the M2M server <NUM> and <NUM>. Thus, other entities can discover the announced resource at M2M Server <NUM> and <NUM>. In particular, the sensor <NUM> sends a request to create two entries associated with M2M Server <NUM> and <NUM> in the announceTo attribute at the original resource on M2M Gateway <NUM>. The M2M Gateway <NUM> then sends a request to M2M Server <NUM> and <NUM> to create an announced resource. The announced resource has a subset of attributes of the original resource with the same value. For example, the expiration time of the announced resource is the same as the original resource. The M2M Server <NUM> or <NUM> does not have the access right to edit the announced resource it stores. For example, the M2M Server <NUM> or <NUM> cannot modify or delete an announced resource it stores. For example, if the resource on M2M Gateway <NUM> is changed, the M2M Gateway <NUM> will send an update request to M2M Server <NUM> and <NUM> to update the announced resource as shown in <FIG>.

A caching strategy can decrease latency and improve throughput by taking load off back-end servers and databases. Caching has been applied to the Internet. Two main mechanisms are web caching and Content Delivery Networks. A web cache temporarily stores or caches web documents passing through it, such as HTML pages and images, to reduce bandwidth usage, server load, etc. Subsequent requests may be satisfied from the cache if certain conditions are met. Content Delivery Networks (CDNs) intend to increase Internet capacity by replicating content files to caches (i.e. surrogate servers) close to end users. The surrogate servers cache a set of content files and deliver them on behalf of the origins to decrease the traffic going through the origin servers as well as to decrease the overall network traffic. Typically, the surrogate servers are located at the edge of the network close to the end users. A content provider can sign up with a CDN provider, and nearby end users can then retrieve the content files from the surrogate server in a transparent fashion.

Currently in M2M system, caching is mainly supported at the Application Protocol Layer. HTTP and CoAP are two major Application Protocol Layer protocols used in M2M systems. The following illustrates the caching mechanisms supported in HTTP and CoAP.

HTTP [Hypertext Transfer Protocol -- HTTP/<NUM>, RFC <NUM>] supports caching so that content can be stored by the browser locally or a proxy which sits somewhere between the client and the origin server, and reused when required. Some types of data such as stock prices and weather forecasts are frequently changed and it is important that the browser does not display stale versions of these resources. By carefully controlling caching, it is possible to reuse static content and prevent the storage of dynamic data.

HTTP defines three basic mechanisms for controlling caches: freshness, validation, and invalidation.

Freshness allows a response to be used without re-checking it on the origin server. HTTP provides two ways for servers to specify the freshness lifetime of a response: the Expires header and the max-age cache control directive. The Expires header's value is the date and time when a response becomes stale. The max-age cache control directive specifies the number of seconds that the response should be considered fresh.

Validation can be used to check whether a cached response is still good after it becomes stale. A cache can make a conditional request using the If-Modified-Since header to see if it has changed. Another kind of validator provided by HTTP/<NUM> is known as an entity tag (ETag). An entity tag is an opaque string used to identify a specific instance of an object. A cache uses an ETag to validate its object with the If-None-Match request header.

Invalidation is usually a side effect of another request that passes through the cache. If a URL associated with a cached response later gets a POST, PUT or DELETE request, the cached response will be invalidated.

In HTTP, a cache decides if a particular response is cacheable by looking at different components of the request and the response. Specifically, it examines the following:.

These different factors interact in a somewhat complicated manner; details can be found in the Hypertext Transfer Protocol -- HTTP/<NUM>, RFC <NUM>.

CoAP [Constrained Application Protocol (CoAP), IETF RFC <NUM>] supports the caching of responses in order to efficiently fulfill requests. Simple caching is enabled using freshness and validity information carried with CoAP responses. A cache could be located in an end-point or an intermediary.

CoAP defines a more simplified freshness model, validation model and invalidation model than HTTP.

Unlike HTTP, the cacheability of CoAP responses does not depend on the request method, but instead depends on the response code. Details can be found in Constrained Application Protocol (CoAP), IETF RFC <NUM>. Moreover, to support sleeping device, an entity named Resource Directory (RD) is introduced to host descriptions of resources held on other servers [draft-ietf-core-resource-directory-<NUM>, "CoRE Resource Directory"]. This allows an entity to look up those resources via a RD. A sleeping device can also store resource representations in an entity called Mirror. This allows an entity to retrieve those resources via a Mirror Server.

Cited references include <CIT> and <CIT>.

A good caching strategy can decrease latency by huge percentages, and improves throughput by taking load off expensive back-end servers and databases. Currently in M2M systems, caching is mainly supported at the Application Protocol Layer. Caching at the Service Layer may be able to provide complete access control and subscription features for a cached resource, and Service Layer caching may be employed by entities outside of a provider's network and may not require a CDN provider. However, current Service Layer (SL) implementations lack capabilities to manage cached resources.

Two methods are described herein for the creation of SL cached resources:.

By using the described methods, a Caching Entity can store a cached copy of a SL resource while the Original Hosting Entity can maintain a registry of the corresponding cached resources. Optionally, the Original Hosting Entity can set cache parameters to govern the lifetime of the cache on a Caching Entity.

Additionally, two methods are described for M2M/IoT SL technologies to refresh a cached resource:.

By using the described methods, a Caching Entity can keep storing the cached copy of the resource and the Original Hosting Entity can obtain statistics about the cached resource. By knowing the statistics information, e.g. how many times a resource is retrieved on each Caching Entity, the Original Hosting CSE can better manage the resource. For example, the Original Hosting CSE may control how many times the resource can be accessed by a user. In another example, the Original Hosting CSE may charge fee to the user based on how many times the resources are accessed.

Also, a method is described for an Original Hosting Entity to update cached copies stored on Caching Entities when the original resource is updated. By using the method, the original resource and the cache copies of the resource are synchronized.

Still further, two methods are described for the deletion of cached copies of a resource:.

By using these methods, a Caching Entity may delete the cached copy of a resource.

The Service Layer cache management mechanisms described herein may be embodied in a oneM2M Service Layer implementation.

Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

A more detailed understanding may be had from the following description, given by way of example in conjunction with accompanying drawings wherein:.

Disclosed herein are mechanisms for managing cached resources at a service layer of a communications network, such as an M2M communications network. The following abbreviations may be used throughout the following description:.

The following terms may have the following general meanings:
"Cacheability" may be considered to be an attribute associated with a resource to indicate whether the resource is allowed to be cached at a Caching Entity. The attribute has two values, one is Cacheable and the other one is non-Cacheable.

"Cacheable" may be the value of the Cacheability that indicates the original resource is allowed to be cached at a Caching Entity.

A "Caching Entity" may be an SL Entity that stores a copy of a resource representation hosted at another SL entity.

An "M2M/IoT Service layer (SL)" may be a software middleware layer that supports value-added services for M2M/IoT applications and devices through a set of Application Programming Interfaces (APIs) and underlying networking interfaces.

An "M2M/IoT application" may be an application targeting a particular M2M/IoT use case (e.g. eHealth, smart energy, home automation).

"Non-Cacheable" may be a value of the Cacheability that indicates the original resource is not allowed to be cached at a Caching Entity.

An "Original Hosting Entity" may be an SL Entity that hosts the original resource.

"SL Caching" may be ae process by which an SL Entity stores a copy of the resource representation hosted at another SL entity.

A "SL Entity" may be an M2M Device, M2M Gateway, or a device in the M2M Area Network or the M2M Application Layer or M2M Service Layer software components.

A "SL Resource" may be a uniquely addressable entity in M2M/IoT SL.

Caching at the Service Layer has been proposed in the ETSI M2M architecture. The caching supported at the Service Capabilities Layer (SCL) <NUM> is illustrated in <FIG>. The caches can be at the SCL <NUM>, and the SCL <NUM> can be in charge of managing all the cached resources in the caches.

The Service Capabilities Layer caching is able to provide complete access control and subscription features of the cached resource, which are not supported by the caching scheme in application layer protocols such as HTTP and CoAP. Service Layer caching can be employed for entities outside of the provider's network and do not require a CDN provider.

There are many M2M/IoT use cases where service layer caching can be used to improve the performance of service layer communications.

As illustrated in <FIG>, temperature sensors (e.g., sensor <NUM>) in an apartment complex periodically report the temperature to an M2M Gateway <NUM> via Wi-Fi LAN <NUM>. Multiple residents (User <NUM> and User <NUM>) register to a M2M server <NUM> and monitor the temperature readings using an application hosted on a device, such as a phone <NUM>, <NUM>. When the M2M Server <NUM> receives a request from a user to retrieve a temperature reading on the M2M Gateway <NUM>, the M2M server <NUM> forwards the request to the M2M Gateway <NUM> that hosts the temperature reading resources, as shown in <FIG>. The messages between the M2M Server <NUM> and the M2M Gateway <NUM> can result in a lot of overhead involving repeated requests to retrieve the same resource. To reduce the overhead introduced by the messages, the M2M Server <NUM> can create a local cached copy of the temperature reading resource at the service layer with the same access control policy as the original resource hosted at the M2M Gateway <NUM>. When the M2M Server <NUM> receives a request, it can use the local cached copy of the resource to serve the request instead of forwarding the request to the M2M Gateway <NUM>. The local cached copy of the resource must be synchronized with the original version stored on the M2M Gateway <NUM>. In other words, when the content of the resource on the M2M Gateway <NUM> is changed, all its cached copies stored on the M2M Server <NUM> should be updated or deleted.

Current M2M/IoT SL technologies lack methods to manage the cached copies of resources hosted by Service Layer entities. For existing SL technologies, when an entity creates a cached copy of a SL resource representation, it does not interact with the entity that hosts the original resource. For example, as described in the use case, after the M2M Server receives a response from the M2M Gateway <NUM>, it creates a cached copy of the resource without letting the M2M Gateway <NUM> know of this cached copy. Thus, the SL entity in the system that hosts the original resource, e.g. M2M Gateway <NUM>, is not aware that a cached copy of the resource has been created. This can introduce the following types of problems.

First, the original resource and the cached copies of the resource cannot be synchronized. When the original resource on the Original Hosting Entity is updated, the cached copies on the Caching Entities cannot be updated. For example, when the original copy of the resource on the M2M Gateway <NUM> is updated, the M2M Gateway <NUM> is not able to send a message to update the cached copy hosted on the M2M server. Therefore, when a M2M Application retrieves the resource, the M2M server may return an out of date cached copy of the resource, as illustrated in <FIG>.

As another example, when the original resource on the Original Hosting Entity is deleted, the cached copies on the Caching Entities cannot be deleted. For example, when the original copy of the resource on the M2M Gateway <NUM> is deleted, the M2M Gateway <NUM> is not able to send a message to delete the cached copy on the resource hosted on the M2M server. Therefore, when a M2M Application retrieves the resource, the M2M server may return an invalid cached copy of the resource.

Additionally, an Original Hosting Entity may be unable to obtain information and statistics regarding accesses made to the cached copies of resources. For example, the M2M Gateway <NUM> may want to track how many times a resource is retrieved, which entities performed the retrieval and at what time of day, etc. Therefore, if the M2M Server creates a cached copy without communicating with the M2M Gateway <NUM>, the M2M Gateway <NUM> will not be able to obtain this type of information.

<FIG> illustrates one embodiment of an SL cache management system. As shown, SL entities, e.g. M2M Servers <NUM> and <NUM>, can host a cached copy of the original resource. A SL cache registry <NUM> is used on the Original Hosting Entity, e.g. M2M Gateway <NUM>. The SL cache registry <NUM> is used to keep track of other SL entities <NUM> and <NUM> hosting cached versions of the resource.

As illustrated in <FIG>, new methods are described for creating, refreshing, updating and deleting SL cached resources. These methods include a method for creating a cached copy of a resource at a Cache Entity; a method for refreshing SL cached resources to keep the cached resources on the Caching Entities; a method for updating SL cached resources to keep them synchronized when their corresponding original resources are updated, and methods for deleting SL cached resources.

Note, for illustrative purposes, the SL entity that hosts the original resource is shown as an M2M Gateway <NUM> and the Caching Entity is shown as an M2M Server. It will be noted the SL entity hosting an original or cached resource could be an M2M Gateway <NUM>, Server or Device and the descriptions provided in this document are not meant to be limiting.

Several methods are described for an entity to create a cached copy of a SL resource.

<FIG> illustrates one embodiment of a method initiated by a Caching Entity for creating a SL cached resource. An Entity, e.g. a M2M server, may initiate this process if it frequently receives requests that retrieve the same resource, e.g. more than K times in a second. Alternatively, an application could explicitly indicate that a resource should be cached by sending a message that indicates a specific URI should be cached, by setting an attribute that is associated with the URI to be cached, etc..

In step <NUM> of <FIG>, the Caching Entity (i.e. M2M Server) that intends to create a cached copy of a SL resource sends a resource cache creation request to the Original Hosting Entity (i.e. M2M Gateway <NUM>). The request may contain information as shown in Table <NUM>.

Note that this request could be a CRUD operation that targets the OriginalResourceURI. The fields of Table <NUM>, other than the OriginalResourceURI, could be attributes of the OriginalResourceURI.

In step <NUM> of <FIG>, after receiving the request, the Original Hosting Entity <NUM> accepts or rejects the cache creation request based on policies as shown in <FIG>.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> first checks a "cacheability" attribute associated with the resource. The attribute (cacheability) is a common resource attribute that can be used to distinguish whether a particular resource is cacheable or not. This attribute could be configured in multiple ways. In one implementation, it could be configured by the application that creates the resource. In another implementation, it could be configured by the SL entity that hosts the resource.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> determines whether the entity that sends the request is granted permission to cache the resource. The Original Hosting Entity <NUM> checks the cached control policy of the requested resource. The cached control policy can be a standalone policy or as an enhancement of Access Control Policy (ACP). In the cached control policy, a list of IDs of SL entities that are allowed to cache resources are stored in the cached control policy. Using this cached control policy, the Original Hosting Entity <NUM> can check the ID of a Caching Entity <NUM> that is initiating a cache request for a targeted resource and compare this ID against the caching privileges of the ACP associated target resource. If the ID matches, then permission can be granted to allow the caching to be performed, otherwise it can be denied.

In step <NUM> of <FIG>, if the requested resource cannot be cached, the Original Hosting Entity <NUM> will send a rejection in the resource cache creation response.

In step <NUM> of <FIG>, if the requested resource can be cached, the Original Hosting Entity <NUM> adds an entry in its SL cache registry <NUM>, the detail information and format of the SL cache registry <NUM> is shown in Table <NUM>. Note that since a resource could be cached by multiple entities, there may be multiple entries in the Cache registry <NUM> for a given original resource.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> accepts the cache request.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> will send the resource cache creation response to the Caching Entity <NUM>. The response contains information as shown in Table <NUM>. In the message, the Original Hosting Entity <NUM> notifies whether it allows the Caching Entity <NUM> to create a cache copy of the resource. Note that this request could be a CRUD operation that targets the CachedResourceURI. The fields of Table <NUM>, other than the CachedResourceURI, could be attributes of the original resource.

In step <NUM> of <FIG>, the Caching Entity <NUM> will process the cache response as shown in <FIG>. If the entity is allowed to cache the resource, it stores a cached copy of the content under the cached resource URI in Table <NUM> along with additional attributes and sub-resources in Table <NUM>.

In step <NUM> of <FIG>, the Caching Entity <NUM> first checks the Cache Decision filed in the response message. It goes to step <NUM> if the request is approved and goes to step <NUM> otherwise.

In step <NUM> of <FIG>, the Caching Entity <NUM> sets the expiration time of the cached copy based on the value in the cache response message. If there is no expiration time in the cache response message, it will set the cache expiration time by itself.

In step <NUM> of <FIG>, the Caching Entity <NUM> sets the Access Control Policy of the cached copy based on the value in the cache response message. If there is no Access Control Policy in the cache response message, it will set the Access Control Policy by itself.

In step <NUM> of <FIG>, the Caching Entity <NUM> stores a copy of the content under the URI, which is the cachedResourceURI in Table <NUM> along with additional attributes and sub-resources in Table <NUM>. This URI is used between the Original Hosting Entity <NUM> and the Caching Entity <NUM> for cache management and is not visible to other entities in the network.

In step <NUM> of <FIG>, the Caching Entity <NUM> will discard the cache response and will not create a cached copy of the resource.

As illustrated in <FIG>, a Resource Cache Creation Request message can be sent independently or can be embedded in a resource retrieval request. Similarly, the Resource Cache Creation Response message can be embedded in a resource retrieval response sent by the M2M Gateway <NUM>.

It is understood that the entities performing the steps illustrated in <FIG>, such as the Original Hosting Entity (M2M Gateway) <NUM> and Caching Entity (M2M Server1) <NUM>, may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, an apparatus configured for wireless and/or network communications or a computer system such as those illustrated in <FIG> or <FIG>. That is, the method(s) illustrated in <FIG> may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in <FIG> or <FIG>, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in <FIG>. It is also understood that the functionality illustrated in <FIG> may implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, rather, they may communicate via forwarding or a routing function. It is also understood that any transmitting and receiving steps illustrated in <FIG> may be performed by communication circuitry of the respective apparatus under control of the processor of the apparatus and the computer-executable instructions (e.g., software) that it executes.

<FIG> illustrates one embodiment of a method initiated by an Original Hosting Entity for creating a SL cached resource. In this method, the M2M Gateway <NUM> initiates the SL resource cache creation process. Note that, in the oneM2M service layer announced resource methods, the M2M Gateway <NUM> cannot create a resource announcement unless an AE or CSE changes the AnnounceTo attribute associated with the original resource. However, in one embodiment, the original resource hosting entity does not require a third party entity to trigger the cache creation procedure. For example, the original resource hosting entity can initiate the cache creation process based on the location information provided by an M2M server during a retrieve of a resource. In another example, the original resource hosting entity can initiate the cache creation process when an M2M server retrieves a resource frequently. Moreover, in the service layer caching scheme, an entity, e.g. an application, can access the cached resource using the URI that is the same as it access the original resource. However, in the announced resource scheme, an announced resource has a different URI from the original resource.

In step <NUM> of <FIG>, the Original Hosting Entity (i.e. M2M Gateway <NUM>) sends a resource cache indication message to the SL entity that would create a cached copy. The resource cache indication contains information as shown in Table <NUM>. Additionally it may indicate to the caching entity that it wants the caching entity to collect statistics about how often the cached copy is accessed. These statistics may be used by the Original Hosting entity to make decisions about whether or not the cached copy should be maintained. For example, if the cache is never read, then the original hosting entity may decide to delete the cache entry and cache a different resource.

In step <NUM> of <FIG>, after receiving the Resource Cache Indication, the Caching Entity decides whether it creates a cached copy of the resource. For example, if the entity does not support resource caching or it does not have enough memory to store a cached resource, it will not create a cached copy of the resource.

In step <NUM> of <FIG>, the Caching Entity sends its decision in the Resource Cache Confirmation as shown in Table <NUM>. If it has created a cached copy of the resource, it sends the URI of the cached resource.

In step <NUM> of <FIG>, the Original Hosting Entity processes the cache confirmation. If the Caching Entity has cached the resource, it adds an entry in the SL Cache Registry registration table, the detailed information of a SL Cache registry <NUM> is shown in Table <NUM>.

As illustrated in <FIG>, the Resource Cache Indication message can be embedded in a resource retrieval response sent by the M2M Gateway <NUM>.

In step <NUM> of <FIG>, application <NUM> sends a request to retrieve resource "A", hosted on the M2M Gateway <NUM>.

In step <NUM> of <FIG>, M2M Server <NUM> forwards the request to M2M Gateway <NUM> since it does not have a cached copy of the resource "A" that is hosted on M2M Gateway <NUM>.

In step <NUM> of <FIG>, when processing the request, M2M Gateway <NUM> may detect that M2M Server <NUM> has retrieved the same resource frequently, e.g. more than k times in a minute. Therefore, M2M Gateway <NUM> requests the M2M Server <NUM> to create a cache copy of the resource in order to reduce its workload.

In step <NUM> of <FIG>, the M2M Gateway <NUM> inserts a Cache Indication message inside the response message. The resource cache indication contains information as shown in Table <NUM>.

In step <NUM> of <FIG>, after receiving the response, M2M Server <NUM> sends a response with the resource representation of resource "A" to Application <NUM>.

In step <NUM> of <FIG>, M2M Server <NUM> will extract the Cache Indication message from the response, and decides whether it will create a cached copy of the resource.

In step <NUM> of <FIG>, M2M Server <NUM> sends its decision in the Resource Cache Confirmation as shown in Table <NUM>. If it has created a cached copy, it sends the URI of the cached resource.

In step <NUM> of <FIG>, M2M Gateway <NUM> process the cache confirmation. If the caching entity has cached the resource, it adds an entry in the SL Cache registry <NUM>. The detailed information of a SL Cache registry <NUM> is shown in Table <NUM>.

In step <NUM> of <FIG>, application <NUM> sends a request to retrieve resource "A", hosted on the M2M Gateway.

In step <NUM> of <FIG>, the M2M Server <NUM> check its cache and find the cached resource.

In step <NUM> of <FIG>, the M2M Server <NUM> sends a response with the resource representation of cached resource "A" to Application <NUM>.

It is understood that the entities performing the steps illustrated in <FIG> may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, an apparatus configured for wireless and/or network communications or a computer system such as those illustrated in <FIG> or <FIG>. That is, the method(s) illustrated in <FIG> may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in <FIG> or <FIG>, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in <FIG>. It is also understood that the functionality illustrated in <FIG> may implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, rather, they may communicate via forwarding or routing function. It is also understood that any transmitting and receiving steps illustrated in <FIG> may be performed by communication circuitry of the apparatus under control of the processor of the apparatus and the computer-executable instructions (e.g., software) that it executes.

A cached copy of a SL resource may be removed if the expiration time associated with the cached resource expires. Moreover, the expiration time associated with a SL Cache registry <NUM> entry may also expire and be removed by the Original Hosting Entity. Therefore, cache refresh methods are desirable in order for the Caching Entity keeps storing the cached resource. Two cache refresh methods are described herein to maintain a cached resource in a Caching Entity.

<FIG> illustrates one embodiment of a method by which a Caching Entity, e.g. M2M Server, can refresh a cached copy of a SL resource before the expiration time associated with the cached copy expires.

In step <NUM> of <FIG>, the Caching Entity sends a Cache Refresh Request to the Original Hosting Entity. The Cache Refresh Request contains information as shown in Table <NUM>. The cache Refresh Request contains the new proposed cache expiration time and statistics associated the cached resource. For example, how frequently the cached resource has been retrieved and how many times it has been retrieved since the last refresh. The Original Hosting CSE can better manage the resource by knowing these statistics information. For example, the Original Hosting CSE may control how many times the resource can be accessed by a user. In another example, the Original Hosting CSE may charge fee to the user based on how many times the resources are accessed.

In step <NUM> of <FIG>, the Original Hosting Entity processes the Cached Refresh Request. The Original Hosting Entity obtains the statistic of the cached resource, and may decide whether to allow the Caching Entity to continue caching the resource. For example, the Original Hosting Entity allows the Caching Entity to continue to cache the resource if the cached resource has been retrieved frequently. If it decides that the Caching Entity can continue to cache the copy, it will provide a new value of the expiration time. This value will be stored in the SL Cache registry <NUM> as well as returned in the response. Otherwise, it will initiate deleting the cached copy and also deleting the corresponding entry from the SL Cache registry <NUM>.

In step <NUM> of <FIG>, the Original Hosting Entity sends the cache refresh response to the Caching Entity. The request contains information as shown in Table <NUM>.

In step <NUM> of <FIG>, the Caching Entity processes the cache refresh response as follows. If the Caching Entity is allowed to cache the resource, it will set a new value to the expiration time of the cached copy and update the resource content and attribute based on the information in the response. It will also begin collecting a new set of statistics for the cached resource. Otherwise, it can initiate a cache deletion process.

<FIG> illustrates one embodiment of a method by which an Original Hosting Entity e.g. M2M Gateway <NUM>, can refresh a cached copy of a SL resource.

The Original Hosting Entity <NUM> may trigger the proactive cache refreshment process in many situations. For example, the process is triggered if the expiration time associated with the resource cached registry is about to expire. In another example, the process is triggered if the Original Hosting Entity <NUM> intends to obtain statistics about the cached copy stored at the Caching Entity <NUM>. For example, the Original Hosting Entity <NUM> wants to know how frequently the cached copy is retrieved at the Caching Entity <NUM>.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> sends the cache refresh indication to the entity that stores the cached copy. The cache refresh indication contains information as shown in Table <NUM>.

In step <NUM> of <FIG>, after receiving the Cache Refresh Indication, the Caching Entity <NUM> decides whether it will maintain the cache copy and if so sets the expiration time to the new value.

In step <NUM> of <FIG>, the Caching Entity <NUM> will send its decision in the Cache Refresh Confirmation as shown in Table <NUM>. If it agrees to maintain the cached copy, it will send its new expiration time. If the Caching Entity <NUM> does not want to maintain the cached copy, for example, due to limited resource, it will not set the new expiration time. The Caching Entity <NUM> will also include the statistics about the cached resource if it is requested by the Original Hosting Entity <NUM>.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> processes the Cache Refresh Confirmation. If the caching entity <NUM> has agreed to keep the cached copy, it sets the new value to the expiration time within the SL Cache registry <NUM> associated with the cached copy. Otherwise, it will initiate a cache deletion process.

It is understood that the entities performing the steps illustrated in <FIG> and <FIG> may be logical entities that may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of, and executing on a processor of, an apparatus configured for wireless and/or network communications or a computer system such as those illustrated in <FIG> or <FIG>. That is, the method(s) illustrated in <FIG> and <FIG> may be implemented in the form of software (i.e., computer-executable instructions) stored in a memory of an apparatus, such as the apparatus or computer system illustrated in <FIG> or <FIG>, which computer executable instructions, when executed by a processor of the apparatus, perform the steps illustrated in <FIG> and <FIG>. It is also understood that the functionality illustrated in <FIG> and <FIG> may implemented as a set of virtualized network functions. The network functions may not necessarily communicate directly, rather, they may communicate via forwarding or routing function. It is also understood that any transmitting and receiving steps illustrated in <FIG> and <FIG> may be performed by communication circuitry of the apparatus under control of the processor of the apparatus and the computer-executable instructions (e.g., software) that it executes.

It is desirable to enable the original resource and all cached copies to be synchronized. In particular, if the original resource on the Original Hosting Entity <NUM> is changed, all cached copies on Caching Entities <NUM> and <NUM> should also be updated. Methods to update a SL cached resource are described hereinafter.

As illustrated in <FIG>, if an original resource is changed, the Original Hosting Entity <NUM> can initiate a cache update process to update all cached copies stored at one or more Caching Entities <NUM> and <NUM> as shown in <FIG>. Note that, the triggering events for the cache refresh method and the cache update method may be different. In particular, a cache refresh is triggered by a timeout and a cache update is triggered by an update of the original resource on the Original Hosting Entity <NUM>.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> checks the SL Cache registry <NUM> associated with the resource and obtains a list of Caching Entities <NUM> and <NUM> that store a cached copy of the resource. Note that an original resource could have an attribute associated with it, which indicates the locations of a cached resource. An attribute could also be a pointer to an entry in the list of cached entities.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> sends the cache update request to each Caching Entity <NUM> and <NUM> in the list. The cache update request contains information as shown in Table <NUM>.

In step <NUM> of <FIG>, after receiving the Cache Update Request, the Caching Entity <NUM> will update the cached copy based on the information in the request.

In step <NUM> of <FIG>, the Caching Entity <NUM> will send the result of the update in the Cache Update Response as shown in Table <NUM>. If it set up an expiration time that is different from the value in the request, it will send the new expiration time. The Caching Entity <NUM> will also include the statistics about the cached resource if it is requested by the Original Hosting Entity <NUM>.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> processes the Cache Update Response. It sets the new value to the expiration time within the SL Cache registry <NUM> associated with the cached copy, if the caching entity proposes new expiration time. The Original Hosting Entity <NUM> can initiate a cache deletion process, if the Caching Entity <NUM> fails to update the cached copy.

Either the Original Hosting Entity <NUM> or the Caching Entity <NUM> or <NUM> can initiate a cache deletion process to delete a copy of cached cache. Two methods are described herein to delete a cached resource in a Caching Entity <NUM> or <NUM>.

<FIG> illustrates a method for cache deletion initiated by a Caching Entity <NUM>. The Caching Entity <NUM> may initiate the cache deletion process in many scenarios. For example, the process can be triggered when the Caching Entity <NUM> does not have enough space to cache the resource. In another example, the process can be triggered when the Caching Entity <NUM> fails to refresh the cached copy. In yet another example, the Caching Entity <NUM> may decide to delete the entry if it has not been accessed for some time. The detailed descriptions for the cache deletion process are as follows.

In step <NUM> of <FIG>, the Caching Entity <NUM> sends the Cache deletion request to the Original Hosting Entity <NUM>. The Caching Entity <NUM> may include the reason of the cache deletion and the statistics about how often the cached copy is accessed in the request (See Table <NUM>). There are several reasons that the Caching Entity <NUM> requests to delete the cached copy. In one example, the cached copy has not been retrieved for a long time period. In another example, the Caching Entity <NUM> lacks available resources to continue caching.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> processes the cache deletion request and may decide whether to grant the deletion request based on the reason in the request. For example, the Original Hosting Entity <NUM> may reject the request if the reason in the deletion request is low retrieval frequency. In another example, the Original Hosting Entity <NUM> may grant the deletion request if the reason in the deletion request is the Caching Entity lacks of resource. The Original Hosting Entity <NUM> removes the entry in the cache registry <NUM> associated with the cached copy if it grants the cache deletion request.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> sends a cache deletion response to the Caching Entity <NUM>.

In step <NUM> of <FIG>, the Caching Entity <NUM> removes the cached resource after receiving the deletion response that grants the deletion request.

The Original Hosting Entity <NUM> may also initiate the cache deletion process as shown in <FIG> in many scenarios. For example, the process can be triggered when the original resource is removed by the originator. In another example, the process can be triggered when the Original Hosting Entity <NUM> fails to refresh the cached copy. In another example, the Original Hosting Entity <NUM> may decide, based on statistics about the number of times a cached copy is accessed, that the cached copy should be deleted. In yet another example, a change in access rights of the original resource may cause the Original Hosting Entity <NUM> to decide to delete the cached copy. The detail descriptions for the cache deletion process are as follows.

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> sends the Cache deletion indication to the Caching Entity <NUM>. The Original Hosting Entity <NUM> may include the reason of the cache deletion in the indication message.

In step <NUM> of <FIG>, the Caching Entity <NUM> removes the cached copy include all associated attributed and sub-resource.

In step <NUM> of <FIG>, the Caching Entity <NUM> sends a Cache Deletion Confirmation message to the Original Hosting Entity <NUM>. The Caching Entity <NUM> may include the statistics about how often and how many times the cached copy is accessed in the Cache Deletion Confirmation message (See Table <NUM>).

In step <NUM> of <FIG>, the Original Hosting Entity <NUM> removes the cache registry <NUM> associated with the cached copy after receiving the Cache Deletion Confirmation message.

oneM2M defines the capabilities supported by the oneM2M Service Layer. The oneM2M Service Layer is instantiated as a Capability Services Entity (CSE) <NUM> which. CSEs may communicate with the Cache Management CSF <NUM> via the Mcc and Mcc' reference point to create and manage cache copies.

Table <NUM> describes a number of new attributes that may be added to the existing oneM2M common resource, or to one of the other base resource types, or even to a new base type "cachableResource".

Table <NUM> describes a new supported operation that may be authorized by accessControlOperations.

The existing Request message may be enhanced with several new parameters for supporting cache management. As shown in Table <NUM>, requests over the Mcc and Mcc' reference points, from an Originator to a Receiver, may contain the new parameters as an optional parameter.

The existing response message may be enhanced with several new parameters for supporting cache management. As shown in Table <NUM>, responses over the Mcc and Mcc' reference points, from a Receiver to an Originator will contain the new parameters as an optional parameter.

Several new resources may be defined to support the service layer cache management methods described herein.

The <cacheRegistry> resource may store the information to manage a cached resource under a resource, e.g. <container>, as shown in <FIG> in the original resource hosting CSE. It has a child resource <cacheRegistryEntry>. The cache registry information can also be kept in attributes associated with the individual resources that are cached.

<FIG> shows one embodiment of the child resource <cacheRegistryEntry>. Table <NUM> shows the new attributes of the <cacheRegistryEntry> child resource in addition to the universal and common attributes defined in oneM2M.

One embodiment of a <cacheTable> resource is shown in <FIG>. It may store information to manage a cached resource at the CSEBase in the Caching CSE. It has a child resource < cacheEntry >, illustrated in <FIG>. Table <NUM> lists the attributes of the <CacheEntry> resource in accordance with one embodiment.

To realize the mechanisms and procedures described in this disclosure, oneM2M procedures may be enhanced. <FIG> illustrates one embodiment of a method initiated by a Caching Entity <NUM> for creating a SL cached resource. An Entity <NUM>, e.g. a M2M server may initiate this process as follows if or when it receives a request from an Application <NUM>, which requests to retrieve a resource from a M2M Gateway <NUM>.

In step <NUM> of <FIG>, the Application CSE sends a retrieve request to the M2M Server CSE to retrieve container1 on the M2M Gateway CSE. The retrieve request contains the URI (MN-CSE1/AE1/Container1).

In step <NUM> of <FIG>, the M2M Server CSE will look at it <CacheTable> and do not find a cached copy of the contained requested.

In step <NUM> of <FIG>, the M2M Server CSE sends a message to the M2M Gateway <NUM> to retrieve container1 on the M2M Gateway CSE. The message contains a retrieve request for the resource at URI:MN-CSE1/AE1/Container1. If the M2M Server CSE intends to create a cached copy of the container1, the message also contains a request to create a new <CacheRegistryEntry> under <CacheRegistry> of Container1 on M2M Gateway <NUM>. The M2M Server <NUM> has to indicate the URI it would store the cached resource, e.g. IN-CSE/CacheTable/CacheEntry1 in the message.

In step <NUM> of <FIG>, the M2M Gateway <NUM> creates a new <CacheRegistryEntry> under <CacheRegistry> of Container1 if the resource is cacheable and the M2M server <NUM> has the authorized to cached the resource.

In step <NUM> of <FIG>, the M2M Gateway <NUM> sends a message that includes the resource representation of Contain1 and a request to create a new resource <CacheEntry> under IN-CSE1/CacheTable.

In step <NUM> of <FIG>, the M2M Server <NUM> creates a new <CacheEntry> under IN-CSE1/CacheTable based on the information in the response, e.g. the URI of the original resource.

In step <NUM> of <FIG>, the M2M Server <NUM> send the response to the Application CSE about the <constanstinstance> of the Container1.

In step <NUM> of <FIG>, the Application CSE sends a retrieve request to the M2M Server CSE to retrieve container1 on the M2M Gateway CSE. The retrieve request contains the URI (MN-CSE1/AE1/Containerl).

In step <NUM> of <FIG>, the M2M Server CSE will look at it <CacheTable> and find a cached copy of the contained requested based the OriginalResourceURI attribute.

In step <NUM> of <FIG>, the M2M Server <NUM> sends the response to the Application CSE about the <constanstinstance> of the Container1.

Interfaces, such as Graphical User Interfaces (GUIs), can be used to assist a user to control and/or configure functionalities related to service layer cache management. <FIG> is a diagram that illustrates one embodiment of a graphical user interface <NUM> that allows a user to enable/disable service layer caching, service layer caching statistics and service layer caching billing. <FIG> illustrates an embodiment of a user interface <NUM> for a SL entity (e.g. an oneM2M CSE) to configure and/or display cached resources. It is to be understood that interfaces <NUM> and <NUM> can be produced and presented using displays such as those shown in <FIG> described below.

The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. 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," "device," and "network node" may be used interchangeably.

The service layer may be a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

<FIG> is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system <NUM> 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, M2M server, or M2M service platform may be a component or node of the IoT/WoT as well as an IoT/WoT service layer, etc. Communication system <NUM> can be used to implement functionality of the disclosed embodiments and can include functionality and logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM>.

As shown in <FIG>, the M2M/ IoT/WoT communication system <NUM> includes a communication network <NUM>. The communication network <NUM> 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 <NUM> may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network <NUM> 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 <NUM> 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.

As shown in <FIG>, the M2M/ IoT/WoT communication system <NUM> 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 network nodes (e.g., servers, gateways, device, and the like). For example, the Field Domain may include M2M gateways <NUM> and terminal devices <NUM>. It will be appreciated that any number of M2M gateway devices <NUM> and M2M terminal devices <NUM> may be included in the M2M/ IoT/WoT communication system <NUM> as desired. Each of the M2M gateway devices <NUM> and M2M terminal devices <NUM> are configured to transmit and receive signals, using communications circuitry, via the communication network <NUM> or direct radio link. A M2M gateway <NUM> 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 <NUM> or direct radio link. For example, the M2M terminal devices <NUM> may collect data and send the data, via the communication network <NUM> or direct radio link, to an M2M application <NUM> or other M2M devices <NUM>. The M2M terminal devices <NUM> may also receive data from the M2M application <NUM> or an M2M terminal device <NUM>. Further, data and signals may be sent to and received from the M2M application <NUM> via an M2M service layer <NUM>, as described below. M2M terminal devices <NUM> and gateways <NUM> may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wireline for example.

Exemplary M2M terminal devices <NUM> 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.

Referring to <FIG>, the illustrated M2M service layer <NUM> in the field domain provides services for the M2M application <NUM>, M2M gateway devices <NUM>, and M2M terminal devices <NUM> and the communication network <NUM>. Communication network <NUM> can be used to implement functionality of the disclosed embodiments and can include functionality and logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM>. The M2M service layer <NUM> may be implemented by one or more servers, computers, devices, virtual machines (e.g. cloud/ storage farms, etc.) or the like, including for example the devices illustrated in <FIG> and <FIG> described below. It will be understood that the M2M service layer <NUM> may communicate with any number of M2M applications, M2M gateways <NUM>, M2M terminal devices <NUM>, and communication networks <NUM> as desired. The M2M service layer <NUM> may be implemented by one or more nodes of the network, which may comprises servers, computers, devices, or the like. The M2M service layer <NUM> provides service capabilities that apply to M2M terminal devices <NUM>, M2M gateways <NUM>, and M2M applications <NUM>. The functions of the M2M service layer <NUM> may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc..

Similar to the illustrated M2M service layer <NUM>, there is the M2M service layer <NUM>' in the Infrastructure Domain. M2M service layer <NUM>' provides services for the M2M application <NUM>' and the underlying communication network <NUM> in the infrastructure domain. M2M service layer <NUM>' also provides services for the M2M gateways <NUM> and M2M terminal devices <NUM> in the field domain. It will be understood that the M2M service layer <NUM>' may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M service layer <NUM>' may interact with a service layer by a different service provider. The M2M service layer <NUM>' by one or more nodes of the network, which may comprises servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.

Referring also to <FIG>, the M2M service layers <NUM> and <NUM>' provide a core set of service delivery capabilities that diverse applications and verticals can leverage. These service capabilities enable M2M applications <NUM> and <NUM>' 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 layers <NUM> and <NUM>' also enable M2M applications <NUM> and <NUM>' to communicate through networks <NUM> in connection with the services that the service layers <NUM> and <NUM>' provide.

The methods of the present application may be implemented as part of a service layer <NUM> and <NUM>'. The service layer <NUM> and <NUM>' is a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that may contain the connection methods of the present application. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL 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). Further, connection methods of the present application can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA ) and/or a resource-oriented architecture (ROA) to access services such as the connection methods of the present application.

In some embodiments, M2M applications <NUM> and <NUM>' may be used in conjunction with the disclosed systems and methods. The M2M applications <NUM> and <NUM>' may include the applications that interact with the UE or gateway and may also be used in conjunction with other disclosed systems and methods.

In one embodiment, the logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM> may be hosted within a M2M service layer instance hosted by an M2M node, such as an M2M server, M2M gateway, or M2M device, as shown in <FIG>. For example, the logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM> may comprise an individual service capability within the M2M service layer instance or as a sub-function within an existing service capability.

The M2M applications <NUM> and <NUM>' 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, servers and other nodes 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 <NUM> and <NUM>'.

Generally, the service layers <NUM> and <NUM>' define 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 as 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> or <FIG> described below.

Further, logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM> can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA ) and/or a Resource-Oriented Architecture (ROA) to access services of the present application.

<FIG> is a block diagram of an example hardware/software architecture of a M2M network node <NUM>, such as an M2M device <NUM>, an M2M gateway <NUM>, an M2M server, or the like. The node <NUM> can execute or include logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM>. The device <NUM> can be part of an M2M network as shown in <FIG> or part of a non-M2M network. As shown in <FIG>, the M2M node <NUM> may include a processor <NUM>, non-removable memory <NUM>, removable memory <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display, touchpad, and/or indicators <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>. The node <NUM> may also include communication circuitry, such as a transceiver <NUM> and a transmit/receive element <NUM>. It will be appreciated that the M2M node <NUM> may include any subcombination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the functionality described herein.

In general, the processor <NUM> may execute computer-executable instructions stored in the memory (e.g., memory <NUM> and/or memory <NUM>) of the node in order to perform the various required functions of the node. For example, the processor <NUM> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the M2M node <NUM> to operate in a wireless or wired environment. The processor <NUM> may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor <NUM> may also 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.

As shown in <FIG>, the processor <NUM> is coupled to its communication circuitry (e.g., transceiver <NUM> and transmit/receive element <NUM>). The processor <NUM>, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node <NUM> to communicate with other nodes via the network to which it is connected. In particular, the processor <NUM> may control the communication circuitry in order to perform the transmitting and receiving steps described herein and in the claims.

The transmit/receive element <NUM> may be configured to transmit signals to, or receive signals from, other M2M nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit/receive element <NUM> may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element <NUM> may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. It will be appreciated that the transmit/receive element <NUM> may be configured to transmit and/or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element <NUM> is depicted in <FIG> as a single element, the M2M node <NUM> may include any number of transmit/receive elements <NUM>. More specifically, the M2M node <NUM> may employ MIMO technology. Thus, in an embodiment, the M2M node <NUM> may include two or more transmit/receive elements <NUM> (e.g., multiple antennas) for transmitting and receiving wireless signals.

As noted above, the M2M node <NUM> may have multi-mode capabilities. Thus, the transceiver <NUM> may include multiple transceivers for enabling the M2M node <NUM> to communicate via multiple RATs, such as UTRA and IEEE <NUM>, for example.

The processor <NUM> may access information from, and store data in, any type of suitable memory, such as the non-removable memory <NUM> and/or the removable memory <NUM>. For example, the processor <NUM> may store session context in its memory, as described above. In other embodiments, the processor <NUM> may access information from, and store data in, memory that is not physically located on the M2M node <NUM>, such as on a server or a home computer. The processor <NUM> may be configured to control visual indications on the display to reflect the status of the system or to obtain input from a user or display information to a user about capabilities or settings. A graphical user interface, which may be shown on the display, may be layered on top of an API to allow a user to interactively do functionality described herein.

The processor <NUM> may receive power from the power source <NUM>, and may be configured to distribute and/or control the power to the other components in the M2M node <NUM>. The power source <NUM> may be any suitable device for powering the M2M node <NUM>.

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

For example, the peripherals <NUM> 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 interfaces, 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.

The node <NUM> may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node <NUM> may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals <NUM>. Alternately, the node <NUM> may comprise apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane.

<FIG> is a block diagram of an exemplary computing system <NUM> which may also be used to implement one or more nodes of an M2M network, such as an M2M server, gateway, device, or other node. Computing system <NUM> 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. Computing system <NUM> can execute or include logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM>. Computing system <NUM> can be an M2M device, user equipment, gateway, UE/GW or any other nodes including nodes of the mobile care network, service layer network application provider, terminal device <NUM> or an M2M gateway device <NUM> for example. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) <NUM>, to cause computing system <NUM> to do work. In many known workstations, servers, and personal computers, central processing unit <NUM> is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit <NUM> may comprise multiple processors. Coprocessor <NUM> is an optional processor, distinct from main CPU <NUM>, that performs additional functions or assists CPU <NUM>. CPU <NUM> and/or coprocessor <NUM> may receive, generate, and process data related to the disclosed systems and methods for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.

In operation, CPU <NUM> fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus <NUM>. Such a system bus connects the components in computing system <NUM> and defines the medium for data exchange. System bus <NUM> 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 <NUM> is the PCI (Peripheral Component Interconnect) bus.

Memories coupled to system bus <NUM> include random access memory (RAM) <NUM> and read only memory (ROM) <NUM>. Such memories include circuitry that allows information to be stored and retrieved. ROMs <NUM> generally contain stored data that cannot easily be modified. Data stored in RAM <NUM> can be read or changed by CPU <NUM> or other hardware devices. Access to RAM <NUM> and/or ROM <NUM> may be controlled by memory controller <NUM>. Memory controller <NUM> may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller <NUM> 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.

In addition, computing system <NUM> may contain peripherals controller <NUM> responsible for communicating instructions from CPU <NUM> to peripherals, such as printer <NUM>, keyboard <NUM>, mouse <NUM>, and disk drive <NUM>.

Display <NUM>, which is controlled by display controller <NUM>, is used to display visual output generated by computing system <NUM>. Such visual output may include text, graphics, animated graphics, and video. Display <NUM> 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 <NUM> includes electronic components required to generate a video signal that is sent to display <NUM>.

Further, computing system <NUM> may contain communication circuitry, such as for example a network adaptor <NUM>, that may be used to connect computing system <NUM> to an external communications network, such as network <NUM> of <FIG> and <FIG>, to enable the computing system <NUM> to communicate with other nodes of the network.

User equipment (UE) can be any device used by an end-user to communicate. It can be a hand-held telephone, a laptop computer equipped with a mobile broadband adapter, or any other device. For example, the UE can be implemented as the M2M terminal device <NUM> of <FIG> or the device <NUM> of <FIG>.

It is understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a node of an M2M network, including for example an M2M server, gateway, device or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above, including the operations of the gateway, UE, UE/GW, or any of the nodes of the mobile core network, service layer or network application provider, may be implemented in the form of such computer executable instructions. Logical entities such as sensors <NUM>, M2M gateway (original resource entity) <NUM>, M2M server (caching entity) <NUM> and <NUM>, applications <NUM> and <NUM>, cache registry <NUM>, cache management CSF <NUM> and logical entities to create interfaces such as interfaces <NUM> and <NUM> may be embodied in the form of the computer executable instructions stored on a computer-readable storage medium. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computer.

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.

Claim 1:
An apparatus (<NUM>), being a M2M Server, comprising a processor (<NUM>) and a memory (<NUM>), the memory storing computer-executable instructions which, when executed by the processor of the apparatus, cause the apparatus to:
receive, from an original hosting entity (<NUM>), being a M2M Gateway, a first request to create a cached data, wherein the first request comprises instructions to collect statistical information of the cached data;
create the cached data, and collect statistical information of the cached data based on the instructions;
send, to the original hosting entity, statistical information of the cached data;
receive, from the original hosting entity, a second request to perform a management operation on the cached data; and
perform the requested management operation on the cached data;
wherein the statistical information comprises frequency of retrieval of the cached data; and
wherein the management operation is to delete the cached data and is determined by the original hosting entity based on the frequency of retrieval from the statistical information of the cached data.