Patent Application
20220124008
A machine-to-machine (M2M) or Internet of Things (IoT) service layer (SL) is a technology specifically targeted towards providing value-added services for M2M/IoT devices, IoT applications and IoT data. Recently, several industry standard bodies, such as oneM2M, the European Telecommunications Standards Institute (ETSI), the Open Connectivity Foundation (OCF) and the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) group, have been developing M2M/IoT SLs to address the challenges associated with the integration of M2M/IoT devices, applications and data into deployments with the Internet/Web, cellular, enterprise, and home network.
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 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. From a deployment perspective, an M2M/IoT SL can be deployed on various types of network nodes including servers, gateways and devices.
The oneM2M standards body has defined a M2M/IoT SL. The purpose of this SL is to provide “horizontal” services that can be utilized by different “vertical” M2M systems and applications, such as e-health, fleet management, and smart homes.
Described herein is a Service Layer (SL) capability, which may be referred to hereinafter as a Message Flow Management (MFM) Service, that enables dynamic control of the rate of particular SL messages that are destined to an IoT device or application, referred to herein as a target entity (TE), based on its SL status. During or after registration of the TE with the SL, the TE may configure one or more MFM policies that may define rules for the MFM Service, including the criteria for when the MFM should be activated or deactivated, the requirement that the MFM Service should achieve, such as, for example, reducing the rate of particular SL messages targeting the TE based on the type of the message, the priority of the message, the size of the message, and/or the originator of the message. Based on the one or more MFM policies, the SL entity that provides MFM Services may detect when the MFM for the TE should be activated, such as when the TE is unavailable or has limited capability to process particular SL messages. On behalf of the TE, the SL entity that provides MFM Services can cooperate with remote SL entities in the network to inform them that the MFM for the TE is activated and the actions that they need to perform to achieve the requirement defined in the MFM policies. On receiving this information, these remote SL entities in the network can perform actions such as:
In accordance with one aspect, an automated SL message flow management architecture is disclosed herein to support automated SL message flow management that can control the rate of particular SL messages destined to a SL entity based on the type of the message, the priority of the message, the size of the message and/or the originator of the message.
In another aspect, a method is disclosed for a TE to configure a MFM Service by creating/updating/deleting MFM policies that define rules to perform the MFM Service, including the criteria for when the MFM should be activated or deactivated, the requirement that the MFM Service should achieve, such as, for example, reducing the rate of particular SL messages targeting the TE based on the type of the message, the priority of the message, the size of the message and originator of the message.
In another aspect, MFM operational methods are disclosed that may be initiated after the MFM is activated for a TE. The SL entity that provides the MFM Service for the TE may cooperate with remote SL entities in the network to achieve the requirement defined in the MFM Policies.
These MFM operational methods may comprise reactive MFM operational methods for use when the SL entity that provides the MFM Service receives a SL message that is subjected to MFM. These reactive MFM operation methods may include (1) an end-to-end reactive MFM operational method for use where the SL entity that provides the MFM Service coordinates with an originator of an SL message to achieve the requirement defined in the applicable MFM policy(ies), and (2) a hop-by-hop reactive MFM operational method for use where the SL entity that provides the MFM Service coordinates with one or more SL entities that are on the SL path of the SL message targeted to the TE to achieve the requirement defined in applicable MFM policy(ies).
The MFM operational methods may also comprise a proactive MFM operational method which may be applied before the SL entity that provides the MFM Service receives a SL message that is subjected to MFM. The SL entity that provides the MFM Service may discover and select SL entities to provide MFM services, along with itself, for the TE.
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.
A more detailed understanding may be had from the following description, given by way of example in conjunction with accompanying drawings wherein:
The following is a list of acronyms relating to service layer technologies that may appear in the following description. Unless otherwise specified, the acronyms used herein refer to the corresponding term listed below:
The following terms may have the following meanings:
An IoT application may comprise a software entity that performs application specific functionality pertaining to Internet of Things (IoT) use cases, such as sensing, monitoring, actuating or the like.
An IoT service may comprise a software entity that provides capabilities for IoT applications and devices, such as data management, security, device management, and the like.
An IoT device may comprise an entity that can host one or more IoT applications. An IoT device may also contain IoT services.
An IoT entity may comprise an IoT application, IoT service or IoT device.
An IoT service platform may comprise a system that provides IoT services to enrollees of the platform and their IoT devices, applications, data and users on behalf of a service provider.
An IoT service provider may be any stakeholder, such as a company, individual, corporation, or other organization, responsible for the deployment and management of an IoT service platform.
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 may 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 may 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 may 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.
As shown in
As shown in
A M2M gateway 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 other 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, 6LoWPAN, 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.
Referring to
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 gateways 14 and M2M 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 gateways and M2M 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 network apparatuses of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.
Referring also to
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, servers and other network apparatuses 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′.
Generally, a Service Layer, such as the Service Layers 22 and 22′ illustrated in
Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a Resource-Oriented Architecture (ROA) to access services.
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. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the network apparatus in order to perform the various required functions of the network apparatus. For example, the processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the network apparatus 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor 32 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
The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other network apparatuses, including M2M servers, gateways, device, 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.
In addition, although the transmit/receive element 36 is depicted in
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 network apparatus 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the network apparatus 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
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. For example, the processor 32 may store session context in its memory, as described above. 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 network apparatus 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 an apparatus or configure an apparatus, and in particular underlying networks, applications, or other services in communication with the network apparatus. In one embodiment, the display/indicators 42 may present the graphical user interface illustrated in
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 network apparatus 30. The power source 48 may be any suitable device for powering the network apparatus 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.
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 network apparatus 30. It will be appreciated that the network apparatus 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
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 sensor, 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 network apparatus 30 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 network apparatus 30 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 52.
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 a processor, such as 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, that 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 E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials.
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.
Memories 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 may 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 may 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 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.
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. Display 86, in combination with the computer-executable instructions executed by CPU 91, may generate and operate the graphical user interface illustrated and described in
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
As mentioned above, a M2M/IoT service layer (SL) is a technology specifically targeted towards providing value-added services for M2M/IoT devices, IoT applications and IoT data. Several industry standard bodies have been developing M2M/IoT SLs to address the challenges associated with the integration of M2M/IoT devices, applications and data into deployments with the Internet/Web, cellular, enterprise, and home network.
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 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.
From a deployment perspective, an M2M/IoT SL can be deployed on various types of network nodes including servers, gateways and devices, as shown in
The oneM2M standards body has defined a M2M/IoT SL. The purpose of the one M2M SL is to provide “horizontal” services that can be utilized by different “vertical” M2M systems and applications, such as e-health, fleet management, and smart homes. As shown in
The oneM2M architecture is a distributed architecture and supports deploying M2M/IoT services in a distributed manner across the following types of Nodes:
application Service Node (ASN): an ASN is a Node that contains one CSE and contains at least one application entity (AE). As an example of a physical mapping, an ASN may reside in an M2M device.
application Dedicated Node (ADN): an ADN is a Node that contains at least one AE and does not contain a CSE. As an example of a physical mapping, an application Dedicated Node may reside in a constrained M2M device.
Middle Node (MN): a MN is a Node that contains one CSE and contains zero or more AEs. As an example of a physical mapping, a MN may reside in an M2M gateway.
Infrastructure Node (IN): an IN is a Node that contains one CSE and contains zero or more AEs. A CSE in an IN may contain CSE functions not applicable to other node types. As an example of a physical mapping, an IN may reside in an M2M Service Infrastructure.
Non-oneM2M Node (NoDN): a non-oneM2M Node 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
In M2M/IoT service layer deployments, for example a oneM2M service layer deployment, a device may receive a SL message from multiple SL entities. For example, a device may publish or announce its resource to different SL entities resulting in multiple applications discovering the announced resource and sending requests to retrieve the resource on the device at any time. As another example, a device may create multiple resource subscriptions at multiple remote SL entities. These multiple SL entities may send notification messages to the device when the respective notification criteria have been met.
IoT devices may be mobile and constrained devices that are battery powered. When a device's battery is low, the device may want to reduce the number of requests it receives to help conserve its battery. As another example, when the transceiver of a device detects weak signal strength, the device may also want to reduce the number of messages it receives until signal strength improves. However, current M2M/IoT service layers do not support capabilities to dynamically control the rate of SL messages that are destined to an IoT device or application based on the status of the device. For example, if a device wants to stop receiving request messages that access its locally hosted resources, the device itself has to de-announce its resources on all SL entities to which it has previously announced its resource. As another example, to reduce the number of notification messages it receives, a device itself should delete, disable or change the rate of notifications on all SL entities to which it has subscribed, as illustrated in
Described herein is a Service Layer (SL) capability, which may be referred to hereinafter as a Message Flow Management (MFM) Service, that enables dynamic control of the rate of particular SL messages that are destined to an IoT device or application, referred to herein as a target entity (TE), based on its SL status. During or after registration of the TE with the SL, the TE may configure one or more MFM policies that may define rules for the MFM Service, including the criteria for when the MFM should be activated or deactivated, the requirement that the MFM Service should achieve, such as, for example, reducing the rate of particular SL messages targeting the TE based on the type of the message, the priority of the message, the size of the message, and/or the originator of the message. Based on the one or more MFM policies, the SL entity that provides MFM Services may detect when the MFM for the TE should be activated, such as when the TE is unavailable or has limited capability to process particular SL messages. On behalf of the TE, the SL entity that provides MFM Services can cooperate with remote SL entities in the network to inform them that the MFM for the TE is activated and the actions that they need to perform to achieve the requirement defined in the MFM policies. On receiving this information, these remote SL entities in the network can perform actions such as:
In accordance with one aspect, an automated SL message flow management architecture is disclosed herein to support automated SL message flow management that can control the rate of particular SL messages destined to a SL entity based on the type of the message, the priority of the message, the size of the message and/or the originator of the message.
In another aspect, a method is disclosed for a TE to configure a MFM Service by creating/updating/deleting MFM policies that define rules to perform the MFM Service, including the criteria for when the MFM should be activated or deactivated, the requirement that the MFM Service should achieve, such as, for example, reducing the rate of particular SL messages targeting the TE based on the type of the message, the priority of the message, the size of the message and originator of the message.
In another aspect, MFM operational methods are disclosed that may be initiated after the MFM is activated for a TE. The SL entity that provides the MFM Service for the TE may cooperate with remote SL entities in the network to achieve the requirement defined in the MFM Policies.
These MFM operational methods may comprise reactive MFM operational methods for use when the SL entity that provides the MFM Service receives a SL message that is subjected to MFM. These reactive MFM operation methods may include (1) an end-to-end reactive MFM operational method for use where the SL entity that provides the MFM Service coordinates with an originator of an SL message to achieve the requirement defined in the applicable MFM policy(ies), and (2) a hop-by-hop reactive MFM operational method for use where the SL entity that provides the MFM Service coordinates with one or more SL entities that are on the SL path of the SL message targeted to the TE to achieve the requirement defined in applicable MFM policy(ies).
The MFM operational methods may also comprise a proactive MFM operational method which may be applied before the SL entity that provides the MFM Service receives a SL message that is subjected to MFM. The SL entity that provides the MFM Service may discover and select SL entities to provide MFM services, along with itself, for the TE.
With reference to
The MFM-MF may store MFM policies that may be created by a TE, or another SL entity on behalf of the TE. The MFM policies may define MFM triggering conditions and MFM service requirements. Based on a MFM triggering condition defined in one or more MFM policies, the MFM-MF may monitors the real-time MFM context information associated with a TE and decide whether to activate the MFM service for the TE. The MFM context information may comprise, but is not limited to, one or more of the battery power, the signal strength, and the service schedule of the TE. Additional context information may comprise network congestion or fault condition information involving the network connectivity to the TE. As one example, the MFM activation condition may be the battery power of the TE is below a threshold, the signal strength of the TE is below a threshold, the TE is not available to provide service based on its service schedule, the network connectivity to the TE is not available or congested, or a combination of these of conditions.
Alternatively, the TE may also send a request to activate the MFM service. If MFM is activated, the MFM-MF may send a MFM Action Request to the MFM-CF located on other SL entities to perform the MFM service for the TE, as also shown in
The MFM-MF may be implemented as a service. The service may either be a standalone service or implemented as a sub-service of an IoT Service Layer. The MFM-MF service may be hosted on various types of network nodes such as IoT servers, IoT gateways and IoT devices.
Although the example MFM service architecture described above and illustrated in
As illustrated in step 1, individual IoT entities 908a, 908b, 908c, such as TEs or other SL entities acting on behalf of TEs, may send requests to the MFM Service 906 in the SL 904 to create MFM policies containing rules that provide guidance to perform the MFM Service. For example, the TE may create a policy that when its battery power is below a threshold, it intends to stop receiving SL notification messages. As another example, the TE may create a policy that when it is not available based on its schedule, it intends to stop receiving all SL messages destined to it. Requests to create MFM policies may be issued by IoT entities 908a-c at different times, for example, when a service subscriber enrolls, or when a device, application or user performs SL registration to a SL, or sometime thereafter. This action may also be triggered by a user who is handling the IoT entity (e.g., device). For example, the user may use a GUI to configure information in the device and initiate the device sending a request to the SL requesting MFM Service.
Table 1 illustrates the contents of one example of a MFM policy. As shown, the MFM policy may comprise one or more attributes, such as MFM Context, MFM Context Monitor Method, MFM Activation Criteria, MFM Requirements, MFM Operation Method, MFM Policy Creator, and/or MFM Target Entity List. A description of each attribute is provided in Table 1. The MFM policy may be implemented using any suitable data structure, such as a table, a database record, an array, a matrix, or the like. The data structure containing the attributes of the MFM policy may be stored in a memory of the IoT entity (e.g., entities 902, 910a-c) that maintains the policy. The attributes of the policy may also be expressed in the form of a mark-up language, such as extensible mark-up language (XML) or the like. When transmitted in the form of a message or request, the attributes of the MFM policy may comprise the payload of such message or request.
With continued reference to
In step 3, based on MFM Activation Criteria defined within a MFM policy, the MFM Service may detect that the MFM Service should be activated or deactivated for a TE. Alternatively, the MFM Service may also allow a TE, such as a user application, to send an explicit request to define and manually activate the MFM Service for the TE. In such a case, the request may contain all or some of the information listed in Table 2. An MFM Action Management Entry may be created after the MFM Service is activated for the TE based on the MFM Policy, as shown in Table 2. An MFM Action Management Entry may be removed after the MFM Service is deactivated for the TE.
In step 4, based on the MFM Requirements defined within a MFM policy, the MFM Service may perform MFM operations that can control the rate of SL messages that are destined for the TEs, as further described below. The MFM Service may initiate MFM operation methods such as but not limited to the following:
Several SL MFM operational methods are proposed to fulfill the MFM requirements described above. The MFM-MF may perform a MFM operation reactively when it receives a SL message that is subjected to MFM. For example, if the TE cannot receive SL notification messages as defined in the MFM requirement of a MFM policy, a MFM operation can be initiated reactively when the MFM-MF receives a SL notification message destined for the TE. The MFM-MF may also start a MFM operation proactively when the MFM is activated. For example, if the TE is not available based on its service schedule, a MFM operation may be initiated proactively before receiving any SL message destined to the TE. Both reactive and proactive methods are described more fully below.
Reactive Service Layer Message Flow Management Method
When the MFM-MF receives a SL message that is subjected to MFM, the MFM-MF may coordinate with the Originator of the SL message to meet the MFM requirements defined in the MFM policies. In addition, the MFM-MF may also coordinate with one or more MFM-CF on SL entities that are on the SL path that the SL message travels towards the TE. Both scenarios are described below.
End to End Reactive Service Layer Message Flow Management
In step 0, based on an MFM Activation Criteria defined within a MFM policy, the MFM Service on Gateway 1 may activate the MFM for Device 1.
In step 1, Device 2 may send a SL request message to Device 1. For example, Device 2 may send a SL notification message to Device 1.
In step 2, when the Registrar entity of Device 1, i.e. Gateway 1, receives the request, the MFM-MF on Gateway 1 may decide whether the request is subject to MFM. For example, based on some or all of the information in Table 2, Gateway 1 may check the type and the priority of the message, and may decide whether the message is subject to MFM. Gateway 1 may also measure the rate of the message destined for the Device 1 and decide whether the message is subject to MFM. If the message is subject to MFM, then Gateway 1 may send a response to Device 2 that the message is dropped due to MFM. When Device 2 receives the response, it may not retransmit the same SL message.
In step 3, Gateway 1's MFM-MF may send a MFM Action Request to Device 2 to create a MFM action on Device 2's MFM-CF for Device 1 and the SL entities that register to Device 1. In the MFM request, the MFM-MF on Gateway 1 may specify all or some of the MFM information as shown in Table 2. The MFM information may include the expected message rate to Device 1 and the duration of the MFM Service. For example, Gateway 1's MFM-MF may indicate in the request, Device 1's service schedule and that Device 1 is not available to receive any SL notification messages when it is not available for service.
In step 4, after receiving the request, the MFM-CF on Device 2 may create a MFM action entry to store the MFM action. The MFM action entry may contain some or all of the information listed below in Table 3. The MFM-CF on Device 2 may cooperate with other SL functions on Device 2 to perform the MFM actions. For example, the MFM-CF may cooperate with a SL subscription and notification function to buffer or filter/drop notifications that target Device 1 and Application 1 until the time specified by the MFM duration.
In step 5, the MFM-CF on Device 2 may send a MFM action response message to the MFM-MF on Gateway 1.
In step 6, the MFM-MF on Gateway 1 may add Device 2 into the MFM Action Performer List. If there is an update about the MFM action for Device 1, then the MFM-MF on Gateway 1 may send a MFM action request to update the MFM Action Entry on the MFM-CF on Device 2.
Hop-by-Hop Reactive Service Layer Message Flow Management
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM Service on Gateway 1 may activate the MFM for Device 1.
In step 1, Application 1 may send a SL request message to Device 1. For example, Application 1 may send a request message to retrieve a resource hosted on Device 1.
In step 2, when the Registrar entity of Device 1, i.e. Gateway 1, receives the request, Gateway 1 may decide whether the request is subject to MFM. For example, MFM may be activated because Device 1 is not available for service and does not want to receive any SL message. In this case, Gateway 1 may send a SL response message to Application 1 stating that Device 1 is not available and that the SL request message has been dropped.
In step 3, the MFM-MF on Gateway 1 may send a MFM Action Request to a MFM-CF on an intermediate SL entity along the SL routing path to Application 1. In the MFM Action Request, the MFM-MF on Gateway 1 may indicate a number of SL entities and the criteria of the SL entity that can create a MFM action for Device 1. For example, the MFM-MF on Gateway 1 may specify it only allows the SL entity that is the closest to the originator on the SL path to create the MFM action. In another example, the MFM-MF on Gateway 1 may specify it allows any SL entity on the SL path to create the MFM action if the SL entity has originated or forwarded messages that are subjected to MFM. The MFM-MF on Gateway 1 may specify some or all of the MFM information of Table 2. The MFM context information may include the expected message rate to Device 1 and the duration of the MFM action period. For example, Gateway 1 may indicate in the request Device 1's service schedule and that it is not currently available to receive any SL messages until a specified time. Alternatively, the content of the MFM action request may be included in the SL response from Gateway 1 in step 2.
In step 4, the MFM-CF on Gateway 3 may store the MFM Action Request and forward it to the next hop along the SL routing path (i.e. the Server) for Application 1.
In step 5, the MFM-CF on Gateway 3 may forward the MFM Action Request to the Server.
In step 6, the MFM-CF on the Server may store the MFM Action Request and forward it to the next hop along the SL routing path (i.e. Gateway 2) for Application 1.
In step 7, the MFM-MF on the Server may forward the MFM Action Request to Gateway 2.
In step 8, the MFM-CF on Gateway 2 may store the MFM Action Request. In this example, since Application 1 is registered to Gateway 2, if Gateway 2 knows Application 1 does not have a MFM-CF and cannot process the request, Gateway 2 will not forward the MFM Action Request to Application 1 and process the request as described in step 11. Otherwise, Gateway 2 forwards the MFM Action Request to Application 1.
In step 9, Gateway 2 forwards the MFM Action Request to Application 1.
In step 10, Application 1 responds with an error since it does not host a MFM-CF and cannot process the request.
In step 11, the MFM-CF on Gateway 2 may know that Application 1 does not have a SL that supports a MFM-CF either by indicating in the response or from registration information. The MFM-CF on Gateway 2 creates a MFM action entry to store the MFM action. The MFM action entry may contain information in Table 3. The MFM-CF can cooperate with SL functions on the same entity to perform MFM operations. For example, if the TE (i.e. Device 1) is not available to receive any SL messages, the MFM-CF can cooperate with SL forwarding function to not send SL messages that are destined for Device 1.
In step 12, MFM-CF on Gateway 2 may send a MFM action response message to MFM-CF on Server and indicates in the response that it has performed the MFM action for the TE (i.e. Device 1).
In step 13, after receiving the response, the MFM-CF on the Server knows that the MFM-CF on Gateway 2 has performed MFM actions for the TE. The MFM-CF on the Server can decide whether it will also perform an MFM action for the TE based on the number of SL entities allowed and the criteria to create the MFM action for the TE. If so, it may create a MFM action entry to store the MFM action. The MFM action entry may contain some or all of the information in Table 3. The MFM-CF can cooperate with SL functions on the same entity to perform MFM operations. For example, if the TE is not able to receive any SL messages, the MFM-CF can cooperate with the SL forward function to stop forwarding or sending SL messages that are destined for the TE.
In step 14, the MFM-CF on the Server may send a MFM action response message to the MFM-CF on Gateway 3 and may indicate in the response that the SL entity(s) (may include itself) on the SL path that have created the MFM action for the TE.
In step 15, after receiving the response, the MFM-CF on Gateway 3 knows that the MFM-CF on Gateway 2 and/or the Server has performed MFM actions for the TE. The MFM-CF on Gateway 3 can decide whether it may also perform MFM actions for the TE. If so, it may create a MFM action entry to store the MFM action. The MFM action entry may contain some or all of the information in Table 3. The MFM-CF may cooperate with the SL functions on the same entity to perform MFM operations. For example, if the TE is not able to receive any SL messages, the MFM-CF may cooperate with a SL forward function to stop forwarding or sending SL messages that are destined for the TE.
In step 16, the MFM-CF on Gateway 3 may send a MFM action response message to the MFM-MF on Gateway 1 and indicate in the response SL entities on the SL path (may include itself) that have created a MFM action for the TE.
In step 17, the MFM-MF on Gateway 1 may add SL entities on the SL path that have performed the MFM action for the TE into the MFM Action Performer List. If there is an update about the MFM action for the TE, for example, the MFM is deactivated since the state of the Device 1 has changed, then the MFM-MF on Gateway 1 may send a MFM action request to update the MFM Action Entry on all SL entities on the SL entities List.
Hop by Hop Reactive Service Layer MFM with MFM Discovery
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM Service on Gateway 1 may activate MFM for Device 1.
In step 1, Application 1 may send a SL request message to Device 1. For example, Application 1 may send a request message to retrieve a resource hosted on Device 1.
In step 2, when the Registrar entity of Device 1, i.e. Gateway 1, receives the request, Gateway 1 may decide whether the request is subject to MFM. For example, MFM is activated since Device 1 is not available for service and does not want to receive any SL messages. In this case, Gateway 1 may send a SL response message to Application 1 stating that Device 1 is not available and that the SL request message has been dropped.
In step 3, the MFM-MF on Gateway 1 may send a MFM Discovery Request to a MFM-CF on an intermediate SL entity along the SL routing path to Application 1. In the MFM Discovery Request, the MFM-MF on Gateway 1 may indicate whether the SL entity has the capability and offers to create a MFM action for Device 1. The MFM Discovery Request can also request to obtain the history statistics, e.g. message rate, about SL messages that are subject to MFM, e.g. a notification message destined to Device 1.
In step 4, the MFM-CF on Gateway 3 may store the MFM Discovery Request and may forward it to the next hop along the SL routing path (i.e. the Server) for Application 1.
In step 5, the MFM-CF on Gateway 3 may forward the MFM Discovery Request to the Server.
In step 6, the MFM-CF on the Server may store the MFM Discovery Request and forward it to the next hop along the SL routing path (i.e. Gateway 2) for Application 1.
In step 7, the MFM-CF on the Server may forward the MFM Discovery Request to Gateway 2.
In step 8, the MFM-CF on Gateway 2 may store the MFM Discovery Request. Since Application 1 is registered to Gateway 2, if Gateway 2 knows Application 1 does not have a MFM-CF and cannot process the request, Gateway 2 will not forward the MFM Action Request to Application 1 and may process the request as described in step 11. Otherwise, Gateway 2 may forward the MFM Discovery Request to Application 1.
In step 9, Gateway 2 may forward the MFM Action Request to Application 1.
In step 10, Application 1 may respond with an error since it does not host a MFM-CF and cannot process the request.
In step 11, after receiving the response, the MFM-CF on Gateway 2 may add information in the response about whether it offers to create a MFM action for Device 1. The MFM-CF on Gateway 2 may also provide the history statistics about SL messages that are subject to MFM if indicated in the request.
In step 12, the MFM-CF on Gateway 2 may send a MFM Discovery Response message to the MFM-CF on the Server.
In step 13, similar to step 11, after receiving the response, the MFM-CF on the Server may add information in the response about whether it offers to create a MFM action for Device 1 in the response. The MFM-CF on the Server may also provide the history statistics about SL messages that are subject to MFM if indicated in the request.
In step 14, the MFM-CF on the Server may send a MFM Discovery Response message to the MFM-CF on Gateway 3.
In step 15, similar to Step 11, after receiving the response, the MFM-CF on Gateway 3 may add information in the response about whether it offers to create a MFM action for Device 1. The MFM-CF on Gateway 3 may also provide history statistics about SL messages that are subject to MFM if indicated in the request.
In step 16, the MFM-CF on Gateway 3 may send a MFM Discovery Response message to the MFM-MF on Gateway 1.
In step 17, by extracting information from the MFM Discovery Response message, the MFM-MF can obtain a list of entities on the SL path that offer to perform a MFM action for the TE. The MFM-MF may also obtain history statistics about SL messages that are subject to MFM and originated or forwarded by these SL entities. Based on this information, the MFM-MF on Gateway 1 can decide one or more SL entities to perform MFM actions. For example, the MFM-MF on Gateway 1 can choose the SL entity that is the closest to Application 1, e.g. Gateway 2 and which is the registrar entity of Application 1. In another example, the MFM-MF on Gateway 1 can choose the SL entities that have sent or forwarded SL messages larger than a threshold. The MFM-MF on Gateway 1 may then request to create a MFM action on the selected SL entity, for example, using the procedure described above for End-to-End Reactive Service Layer Message Flow Management illustrated in
Proactive Message Flow Management
In the methods for reactive message flow management discussed above, the MFM-MF on Gateway 1 may only start a MFM operation method when it receives a SL message that is subject to MFM based on MFM policies. Described below are methods in which the MFM-MF may coordinate with other SL entities after MFM is activated and before receiving any SL messages. These SL entities may provide MFM services along with Gateway 1. A discovery procedure may be initiated by the MFM-MF to find these SL entities; the SL entities should meet the following criteria: (1) have a MFM-MF function, and (2) be willing to provide MFM services for the TE.
Note that the objective of the discovery procedure proposed here may be different from the proposed discovery procedure for the reactive operation methods discussed above. That is, the objective of the discovery procedure for the reactive operation methods is to find a SL entity that is closer to the Originator. The objective of the discovery procedure in the proactive methods described below is to find a SL entity that is not too far from the TE.
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM Service on Gateway 1 activates the MFM for Device 1.
In step 1, the MFM-MF on Gateway 1 may send a MFM Action Management Discovery Request to its Registrar Entity, i.e., Gateway 3, to discover SL entities that can perform MFM action management along with Gateway 1. In the request, the MFM-MF on Gateway 1 may specify the maximum number of times this request can be forwarded. For example, the MFM-MF on Gateway 1 may specify in the request it can be forwarded twice.
In step 2, Gateway 3 may receive the MFM Action Management Discovery Request and may determine whether it has capability to offer MFM action management for the TE. Gateway 3 may also decrease the maximum number of times this request can be forwarded by 1. If the maximum number of times is equal to or greater than 1, Gateway 3 may forward the request to its Registrar Entity.
In step 3, Gateway 3 may send an Action Management Discovery Response back to the MFM-MF on Gateway 1. In the response, Gateway 3 may indicate it does not have a MFM-MF capability but that it has a MFM-CF which could create a MFM action for the TE.
In step 4, the MFM-MF on Gateway 3 may forward the MFM Action Management Discovery Request to its Registrar entity, i.e. the Server.
In step 5, the Server may receive the MFM Action Management Discovery Request and may determine whether it has capability to offer MFM action management for the TE. The Server may decrease the maximum number of times this request can be forwarded by 1. If the maximum number of times is equal to or greater than 1, the Server may forward the request to its Registrar Entity. In this example, because the Server does not have a Registrar SL Entity, it does not forward the request.
In step 6, the Server may send an Action Management Discovery Response back to the MFM-MF on Gateway 1. In the response, the Server may indicate it has the MFM-MF capability to offer MFM Action Management for the TE.
In step 7, the MFM-MF on Gateway 1 may select the SL Entity that offers MFM Action Management, i.e. the Server, and the SL Entity that can perform the MFM action, i.e. Gateway 3. The MFM-MF on the Gateway 1 may start a procedure to create MFM Action Management on the Server as described in steps 8-11. The MFM-MF on Gateway 1 can use the procedure described above for end-to-end reactive service layer message flow management (and illustrated in
In step 8, the MFM-MF on Gateway 1 may send a MFM Action Management Request to the MFM-MF on the Server to create a MFM Management Entry. In the request, the MFM-MF on Gateway 1 may specify some or all of the MFM information shown in Table 2. The MFM context information may include the expected message rate to Device 1, and the duration of the MFM action period. For example, the MFM-MF on Gateway 1 may indicate in the request about Device 1's service schedule that defines when the device can and cannot receive SL notification messages.
In step 9, after receiving the request, the MFM-MF on the Server may create a MFM action management entry to store the MFM information, such as some or all of the information shown in Table 2. By creating the MFM action management entry, the MFM-MF on the Server provides the MFM service along with Gateway 1 for the TE.
In step 10, the MFM-MF on the Server may send a MFM Action Management response message to the MFM-MF on Gateway 1.
In step 11, the MFM-MF on Gateway 1 may add the Server into the MFM Action Manager List. If there is an update about the MFM management for the TE, for example, the MFM may be deactivated since the state of the Device 1 has changed. The MFM-MF on Gateway 1 may send a MFM management request to update the MFM Action Management Entry on the MFM-MF on the Server.
In step 12-16, when the Server receives a SL message that is subject to MFM Service, the MFM-MF on the Server may start MFM operations as described above with respect to the reactive service layer message flow methods.
The MFM-MF may analyze the MFM Context against MFM Activation Criteria defined within one or more MFM Policies that have been created and configured within the MFM Service. Based on MFM Activation Criteria defined within a MFM Policy, the MFM Service may detect that a MFM should be deactivated. Alternatively, the MFM Service may allow a TE (e.g. user application) to send an explicit request to manually deactivate MFM. Once deactivated, the MFM Service could then perform MFM actions for the TE to deactivate the MFM.
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM Service on Gateway 1 may determine to deactivate the MFM for Device 1.
In step 1, the MFM-MF on Gateway 1 may check the MFM Action Performer List and MFM Action Manager List. For each entry in MFM Action Performer List, the MFM-MF on Gateway 1 may initiate a MFM action deletion procedure as described in steps 2-4. For each entry in the MFM Action Manager List, the MFM-MF on Gateway 1 may initiate a MFM action management deletion procedure as described in step 5-7.
In step 2, the MFM-MF on Gateway 1 may send a MFM action deletion request to the SL entity in the MFM Action Performer List, e.g. Gateway 2. The request may contain the SL ID of the TE, i.e. Device 1.
In step 3, after receiving the request, the MFM-CF on Gateway 2 may remove the MFM action associated with Device 1.
In step 4, the MFM-CF on Gateway 2 may send a MFM action deletion response to Gateway 1 to confirm the deletion of the MFM action.
In step 5, the MFM-MF on Gateway 1 may send a MFM action management deletion request to the SL entity(ies) that are in the MFM Action Manager Entity list, e.g. the Server. The request may contain the SL ID of the TE, i.e. Device 1.
In step 6, after receiving the request, the MFM-MF on the Server may remove the MFM action management associated with Device 1. If the Server also has a MFM Action Performer Entity list associated with Device 1, for each entry in the list, the MFM-MF on the Server may initiate the MFM action deletion procedure described in steps 2-4.
In step 7, the MFM-MF on the Server may send a MFM management action deletion response to Gateway 1 to confirm the deletion of the MFM action management.
As mentioned above, the oneM2M standards organization defines capabilities supported by a oneM2M Service Layer. The oneM2M Service Layer may be instantiated as a Capability Services Entity (CSE) which comprises a set of Capability Service Functions (CSF). The Message Flow Management Service described herein may be implemented as a new CSF, as shown in
Attributes and Resources
The following new resources and attributes may be defined to support the Message Flow Management Service described herein within the oneM2M architecture.
oneM2M <mfmPolicy> Resource
In a oneM2M implementation, the MFM CSF may support a MFM Policy resource such as a <mfmPolicy> resource. Such a <mfmPolicy> resource may be created, updated and deleted by an AE or CSE or provisioned into the MFM CSF using out-of-band mechanisms, such as device management. A <mfmPolicy> resource may support attributes which are based on the MFM Policy attribute definitions defined in Table 1. Table 4 shows one example of the attributes that may be defined for the <mfmPolicy> resource.
oneM2M <mfmActionManagement> Resource
In a oneM2M implementation, once MFM is activated for a TE, the MFM CSF may manage MFM action(s) in a new <mfmActionManagement> resource. The <mfmActionManagement> resource may be created, updated and deleted by the MFM CSF when a MFM is activated, modified, or tom-down, respectively. The <mfmActionManagement> resource may support some or all of the attributes defined in Table 5, which are based on the MFM Action Management attribute definitions defined in Table 2.
oneM2M <mfmAction> Resource
A new <mfmAction> resource may be defined in which the MFM CSF may store a MFM Action. The <mfmAction> resource may be created, updated, and deleted by the MFM CSF when a MFM Action is established, modified, or torn-down, respectively. The <mfmAction> resource may support some or all of the attributes defined in Table 6.
oneM2M Procedure Enhancements
Reactive MFM Procedure
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM CSF on MN-CSE 1 may activate the MFM for AE 1 by creating a <mfmActionManagement> resource as shown in Table 7. For example, AE 1 would not receive a notification request.
In step 1, ASN-CSE 1 may send a service request message to AE 1. For example, ASN-CSE 1 may send a SL notification request to AE 1.
In step 2, when the Registrar entity of AE 1, i.e. MN-CSE 1, receives the request, the MFM CSF on MN-CSE 1 may decide whether the request is subject to MFM. For example, if the MFM is activated and AE 1 does not want to receive any SL notification request messages, then MN-CSE 1 may send a response to ASN-CSE 1 that the message is dropped due to MFM.
In step 3, MSN-CSE 1's MFM CSF may send a MFM Action Request to ASN-CSE 1 to create a MFM action on ASN-CSE 1's MFM CSF for AE 1. The MFM Action Request may indicate that AE 1 does not want to receive any SL notification messages.
In step 4, after receiving the request, the MFM CSF on ASN-CSE 1 may create a MFM action resource to store the MFM action. The MFM action resource may contain some or all of the information in Table 3. For example, the MFM CSF on ASN-CSE 1 may cooperate with a SL subscription and notification function to drop notifications that target AE 1 until the time specified by the MFM duration as shown in Table 8.
In step 5, the MFM CSF on ASN-CSE 1 may send a MFM action response message to the MFM CSF on MN-CSE 1.
In step 6, the MFM CSF on MN-CSE 1 may add ASN-CSE 1 into the mfmParticipateList.
Proactive MFM Procedure
In step 0, based on MFM Activation Criteria defined within a MFM Policy, the MFM CSF on MN-CSE 1 may activate the MFM for MN-CSE 3 by creating a <mfmActionManagement> as shown in Table 9. For example, MN-CSE 3 would not receive a request to retrieve its resources.
In step 1, MSN-CSE 1's MFM CSF may send a MFM Action Request to IN-CSE to create a MFM action on IN-CSE's MFM CSF for MN-CSE 3. The MFM Action Request may indicate that MN-CSE 3 does not want to receive any request to retrieve its resource.
In step 2, after receiving the request, the MFM CSF on IN-CSE may create a MFM action resource to store the MFM action. The MFM action resource may contain information in Table 3. For example, with reference to Table 10, the MFM CSF on IN-CSE may cooperate with a resource discovery function not to discover the announced resource on MN-CSE 3. The MFM CSF on IN-CSE may cooperate with a SL forwarding function not to forward the request to retrieve the resource on MN-CSE 3.
In step 3, the MFM CSF on IN-CSE may send a MFM action response message to the MFM CSF on MN-CSE 1.
In step 4, the MFM CSF on MN-CSE 1 may add IN-CSE 1 into the mfmParticipateList.
In step 5, ASN-CSE 1 may send a service request message to IN-CSE. For example, ASN-CSE 1 may send a SL resource discovery request to IN-CSE.
In step 6, when IN-CSE receives the request, the MFM CSF on IN-CSE may decide whether the request is subject to MFM. For example, if the MFM is activated and MN-CSE 3 does not want to receive any SL resource retrieve request messages, then IN-CSE will not include the resource on MN-CSE 3 in the response to ASN-CSE 1.
A user interface may be added to a M2M/IoT Server or Gateways that hosts a MFM CSF (e.g. an oneM2M IN-CSE or MN-CSE) to display Service Layer MFM Policy information and active MFM information. One example user interface is illustrated in
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 an apparatus 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 may be implemented in the form of such computer executable instructions. 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 may be used to store the desired information and which may be accessed by a computer.
In the foregoing description and accompanying 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 each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.
This written description uses examples to disclose the subject matter of the claims, including the best mode, and also to enable any person skilled in the art to practice the claimed subject matter, including making and using any devices or systems and performing any incorporated methods. The patentable scope of this subject matter is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims.
This application claims the benefit of U.S. Provisional Patent Application No. 62/793,057, filed Jan. 16, 2019, which is hereby incorporated by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2019/065419 | 12/10/2019 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62793087 | Jan 2019 | US |
