EP3721349B1 - Data from a source device to a data requester - Google Patents

Data from a source device to a data requester Download PDF

Info

Publication number
EP3721349B1
EP3721349B1 EP17933977.5A EP17933977A EP3721349B1 EP 3721349 B1 EP3721349 B1 EP 3721349B1 EP 17933977 A EP17933977 A EP 17933977A EP 3721349 B1 EP3721349 B1 EP 3721349B1
Authority
EP
European Patent Office
Prior art keywords
data
source device
data provider
mode
provider
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP17933977.5A
Other languages
German (de)
English (en)
French (fr)
Other versions
EP3721349A4 (en
EP3721349A1 (en
Inventor
Swarup Kumar Mohalik
Ramamurthy Badrinath
Sandhya BASKARAN
Sambit Nayak
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP3721349A1 publication Critical patent/EP3721349A1/en
Publication of EP3721349A4 publication Critical patent/EP3721349A4/en
Application granted granted Critical
Publication of EP3721349B1 publication Critical patent/EP3721349B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2895—Intermediate processing functionally located close to the data provider application, e.g. reverse proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • the invention relates to a method, data providers, a computer program and a computer program product for providing device data from a source device to a data requester.
  • Constrained devices are constrained in one or more of power usage (e.g. due to only being battery operated), processing power, network connectivity, etc. Constrained devices can e.g. be sensors reporting data and/or actuators being controlled from a remote device.
  • the Constrained Application Protocol is an application protocol which is similar to Hypertext Transfer Protocol (HTTP), but is simpler and involves less overhead.
  • the CoAP protocol is particularly applicable to low power devices, such as IoT devices.
  • LWM2M Open Mobile Alliance Lightweight Machine to Machine
  • LWM2M clients are protocol from the Open Mobile Alliance that targets the management of constrained devices, denoted LWM2M clients. It makes use of the CoAP protocol and creates a set of common interfaces for management. It also creates a reusable object model that defines the data sent between LWM2M clients and a LWM2M server.
  • LWM2M provides two operations to access data from the LWM2M clients: read and observe-notify.
  • Read is an operation through which a data requester (such as an application on a server) pulls the required data from the source device.
  • Observe-notify utilises a pushbased operation: when a data requester needs data periodically or based on events, it issues the observe command and the source device then notifies the data to the data requester either periodically or when the event happens.
  • the LWM2M server processes and forwards the read/observe requests to the clients for each data requester independently.
  • a LWM2M read operation exercises the LWM2M protocol twice: once on the forward request path (server to client to source device) and once on the backward data path (source device to client to server).
  • Prior art document US 2017048336 discloses a relay module for use in a lightweight machine to machine (LWM2M) communication network, wherein said relay module comprises a first interface module for interfacing with one or more server devices, and a second interface module for interfacing with a plurality of client devices and a processing unit is adapted to establish at least one group object instance, wherein each group object instance is used to control communication between a server device and a group of client devices.
  • LWM2M lightweight machine to machine
  • US2017237815 discloses a system system comprising one or more IoT devices, a device gateway, a network of interconnect end-points, an application server gateway and one or more destination application servers, the device gateway is operationally connected to one or more IoT devices and configured to manage requests for one or more application virtual data paths (VDPs) for the one or more IoT devices.
  • VDPs application virtual data paths
  • a method for providing device data from a source device to a data requester comprising the steps of: determining operating mode for the data provider in respect of the source device, the operating mode being either a pass-through mode or a cache mode, based on estimated resource usage for each of the pass-through mode and the cache mode; receiving a read request from the data requester, the read request requesting device data from the source device; when the data provider is in the pass-through mode, transmitting a corresponding read request to the source device and forwarding a read response, comprising device data, from the source device to the data requester; when the data provider is in the cache mode, retrieving device data from storage of the data provider and transmitting a read response to the data requester, the read response comprising the device data from storage; and populating, when the data provider is in the cache mode, the storage of the data provider with device data received from the source device.
  • the resource usage may comprise computation cost.
  • the resource usage may be estimated based on a density of predicted future read requests from data requesters towards the source device.
  • the read request may comprise an indicator of acceptable device data age defining a maximum age of device data that is acceptable for the data requester.
  • the step of populating comprises ensuring the device data is populated sufficiently frequently to always satisfy the acceptable device data age.
  • the step of populating may comprise sending an observe command to the source device, causing the source device to repeatedly notify the data provider with current device data.
  • the step of populating may comprise sending a minimum wait time, indicating a minimum time duration following a notify from the source device during which no more notify actions will be performed by the source device to the data provider.
  • the step of populating may comprise sending a maximum wait time, indicating a maximum time duration following a notify from the source device after which the source device must perform a notify action to send current device data, even when the device data remains the same compared to a preceding notify action.
  • the read request and the read response may be transmitted in accordance with a LWM2M, Lightweight Machine to Machine, specification, version 1.0 or later.
  • the step of populating the storage of the data provider may be performed in a separate sequence of execution from the step of retrieving device data from storage.
  • a data provider for providing device data from a source device to a data requester.
  • the data provider comprises: a processor; and a memory storing instructions that, when executed by the processor, cause the data provider to: determine operating mode for the data provider in respect of the source device, the operating mode being either a pass-through mode or a cache mode, based on estimated resource usage for each of the pass-through mode and the cache mode; receive a read request from the data requester, the read request requesting device data from the source device; when the data provider is in the pass-through mode, transmit a corresponding read request to the source device and forwarding a read response, comprising device data, from the source device to the data requester; when the data provider is in the cache mode, retrieve device data from storage of the data provider and transmitting a read response to the data requester, the read response comprising the device data from storage; and populate, when the data provider is in the cache mode, the storage of the data provider with device data received from the source device.
  • the resource usage may comprise computation cost.
  • the resource usage may be estimated based on a density of predicted future read requests from data requesters towards the source device.
  • the read request may comprise an indicator of acceptable device data age defining a maximum age of device data that is acceptable for the data requester.
  • the instructions to populate comprise instructions that, when executed by the processor, cause the data provider to ensure the device data is populated sufficiently frequently to always satisfy the acceptable device data age.
  • the instructions to populate may comprise instructions that, when executed by the processor, cause the data provider to send an observe command to the source device, causing the source device to repeatedly notify the data provider with current device data.
  • the instructions to populate may comprise instructions that, when executed by the processor, cause the data provider to send a minimum wait time, indicating a minimum time duration following a notify from the source device during which no more notify actions will be performed by the source device to the data provider.
  • the instructions to populate may comprise instructions that, when executed by the processor, cause the data provider to send a maximum wait time, indicating a maximum time duration following a notify from the source device after which the source device must perform a notify action to send current device data, even when the device data remains the same compared to a preceding notify action.
  • the read request and the read response may be transmitted in accordance with a LWM2M, Lightweight Machine to Machine, specification, version 1.0 or later.
  • the instructions to populate the storage of the data provider may be performed in a separate sequence of execution from the instructions to retrieve device data from storage.
  • a data provider comprising: means for determining operating mode for the data provider in respect of a source device, the operating mode being either a pass-through mode or a cache mode, based on estimated resource usage for each of the pass-through mode and the cache mode; means for receiving a read request from a data requester, the read request requesting device data from the source device; means for transmitting, when the data provider is in the pass-through mode, a corresponding read request to the source device and forwarding a read response, comprising device data, from the source device to the data requester; means for retrieving device data from storage of the data provider and transmitting a read response to the data requester, the read response comprising the device data from storage; and means for populating, when the data provider is in the cache mode, the storage of the data provider with device data received from the source device.
  • a computer program for providing device data from a source device to a data requester.
  • the computer program comprises computer program code which, when run on a data provider causes the data provider to: determine operating mode for the data provider in respect of the source device, the operating mode being either a pass-through mode or a cache mode, based on estimated resource usage for each of the pass-through mode and the cache mode; receive a read request from the data requester, the read request requesting device data from the source device; when the data provider is in the pass-through mode, transmit a corresponding read request to the source device and forwarding a read response, comprising device data, from the source device to the data requester; when the data provider is in the cache mode, retrieve device data from storage of the data provider and transmitting a read response to the data requester, the read response comprising the device data from storage; and populate, when the data provider is in the cache mode, the storage of the data provider with device data received from the source device.
  • a computer program product comprising a computer program according to the third aspect and a computer readable means on which the computer program is stored.
  • Fig 1 is a schematic diagram illustrating an environment in which embodiments presented herein can be applied.
  • a data requester 11 wants to retrieve device data from a source device 10.
  • the data requester 11 can be any computer application which benefits from the device data provided by the source device 10.
  • the data requester 11 can form part of an application program running on a server, desktop computer, laptop computer, tablet computer or smartphone or any other suitable device. While only one data requester 11 is shown in Fig 1 , the data provider can provide device data for a particular source device 10 to multiple data requesters 11.
  • the source device 10 can be a constrained device in a context of internet of things (IoT). Hence, the source device 10 may be extremely limited in terms of power usage (e.g. due to only being battery operated), processing power, network connectivity, etc. While only one source device 10 is shown in Fig 1 , the data provider 1 can be implemented to provide device data from a plurality of source devices 10.
  • IoT internet of things
  • a data provider 1 is located between the data requester 11 and the source device 10.
  • the data provider 1 can be provided as part of a computer, e.g. a server, in order to facilitate communication between the data requester and the source device 10 and reduce power usage by the source device 10.
  • the data requester 11 and the data provider 10 can communicate using any suitable protocol, and can e.g. be based on Internet Protocol (IP), over any suitable bearer, including any one or more of Ethernet, WiFi, any cellular network, Bluetooth, etc.
  • IP Internet Protocol
  • the data requester can use UDP (User Datagram Protocol) and/or TCP (Transmission Control Protocol) and e.g. HTTP (Hypertext Transfer Protocol) and/or COAP (Constrained Application Protocol).
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • HTTP Hypertext Transfer Protocol
  • COAP Constrained Application Protocol
  • the data provider 1 also has access to a data storage 66, which may form part of the data provider or can be provided separately from the data provider.
  • LWM2M When LWM2M is applied, the data requesters are LWM2M servers and the source devices are LWM2M clients.
  • LWM2M provides two operations to access device data from the LWM2M clients: read and observe-notify. Read is an operation through which a data requester pulls the required device data from the source device. Observe-notify is a pushbased operation: when an data requester needs device data periodically or based on events, it issues the observe command to the source device, whereby the source device notifies the device data to the data requester either periodically or when the event happens. Since the data provider 1 is between the data requester 11 and the source device, the data provider 1 acts as a LWM2M client for the data requester 11 and the data provider acts as a LWM2M server for the source device 10.
  • LWM2M read operation exercises the LWM2M protocol twice: once on the forward request path (server to client to device) and once on the backward data path (device to client to server).
  • the LWM2M protocol is an application layer communication protocol between a LWM2M server and a LWM2M client.
  • the total computation power required is reduced for providing device data from the source device 10, by appropriate switching between read and observe-notify modes for the source device 10. As explained in more detail below, this is achieved by setting the data provider 1 in one of two modes: pass-through mode or cache mode, for a particular source device 10.
  • Figs 2A-2D are sequence diagrams illustrating communication between various entities of embodiments which can be applied in the environment of Fig 1 .
  • FIG 2A this illustrates communication when the data provider is in pass-through mode for a particular source device 10.
  • the data requester 11 sends a read request 20a to the data provider 1.
  • the data provider passes a corresponding read request 20b to the source device 10.
  • the data provider 1 forwards a corresponding read response 21a to the data requester 11, containing the device data of the read response 21b from the source device 10.
  • the data provider 1 thus forwards the read request from the data requester 11 to the source device 10 and forwards the read response from the source device 10 to the data requester 11.
  • the pass-through mode is a form of pull based data retrieval.
  • FIG 2B this illustrates communication when the data provider 1 is in a cache mode for a particular source device 10.
  • the storage 66 has been populated with device data, e.g. as illustrated in Figs 2C and 2D , and explained below.
  • the data requester 11 transmits a read request 20a to the data provider 1.
  • the data requester 11 transmits a fetch 22 command to the storage 66 to obtain the device data from storage 66, instead of from the source device 10.
  • the storage 66 response with the applicable device data 23, after which the data provider 1 composes a read response 21a comprising the device data and transmits this to the data requester 11.
  • the data requester 11 receives the applicable device data, but the source device 10 does not need to do any communication, or any processing for this particular read request, thus saving a significant amount of power.
  • the storage 66 must have been populated with device data. This is illustrated in Figs 2C and 2D .
  • the data provider 1 first transmits a command 25 to the source device 10 with two parameters: a minimum wait time (Pmin) and a maximum wait time (Pmax). The function of these parameters will be explained below.
  • the data provider also transmits an observe command 26 to the source device 10.
  • the observe command 26 causes the source device 10 to repeatedly notify the data provider 1 with current device data.
  • the type of device data to be transmitted from the source device 10 is specified in the observe command 26.
  • the source device 10 transmits a first notify message 27a to the data provider 1.
  • the first notify message 27a contains current device data.
  • the data provider 1 then stores 28a the received device data in the storage 66.
  • the source device 10 transmits a second notify message 27b to the data provider 1.
  • the second notify message 27b contains current device data.
  • the data provider 1 again stores 28b the received device data in the storage 66. This process continues in the same way until this procedure is stopped by the data provider 1 or the source device 10.
  • Pmin indicates a minimum time duration following a notify from the source device 10 during which no more notify actions will be performed by the source device 10 to the data provider 1.
  • Pmax indicates a maximum time duration following a notify from the source device 10 after which the source device 10 must perform a notify action to send current device data, even when the device data remains the same compared to a preceding notify action.
  • Pmin and Pmax indicate minimum and maximum time between two consecutive notify messages.
  • Fig 2C The sequence illustrated in Fig 2C is similar to Fig 2D .
  • the observe command 26 comprises an indication that the source device 10 should send the device data to the storage 66.
  • the source device 10 sends its notify messages 27a, 27b, ... directly to the storage 66. This alleviates some processing in the data provider 1.
  • Fig 3 is a flow chart illustrating embodiments of methods for providing device data from a source device 10 to a data requester 11 performed in the data provider 1 of Fig 1 .
  • the data requester 11 can be one or more applications requesting device data from the source device 10.
  • the data provider 1 determines operating mode for the data provider 1 in respect of the source device 10.
  • the operating mode is either a pass-through mode (see Fig 2A ) or a cache mode (see Fig 2B ).
  • the operating mode is determined based on estimated resource usage for each of the pass-through mode and the cache mode.
  • the resource usage can e.g. comprise computation cost. Computation cost is the amount of computation power required, for instance in terms of processor (CPU) usage.
  • the resource usage can be estimated based on a density of predicted future read requests from data requesters 11 towards the source device. In other words, the resource usage can be estimated based on many such read requests per time unit (e.g. second) are predicted to be received.
  • the determination is based on whether it is more efficient to obtain device data from the source device 10 using the read mode or the observe mode.
  • the operating mode is set to pass-through.
  • the observe mode is set to cache.
  • c() is the computation cost incurred in a specific node (in this case being either the data provider 1 or the source device)
  • t() is the time taken by each node for performing required tasks for the communication to occur
  • C1 is a unit cost for c(data provider)+c(CoAP)+c(source device) defined here in the sole purpose of simplifying notation herein.
  • c(read) is equal to the computation cost for communication in the data provider 1 plus the computation cost for the CoAP protocol usage plus the computation cost for communication in the source device 10, all multiplied by two.
  • the multiplication by two is there since the read implies both a read request and a read response, both implying a communication between the data provider 1 and the source device 10.
  • t(read) is equal to the time for communication in the data provider 1 plus the time for communication in the source device 10, all multiplied by two.
  • the time for the CoAP signal propagation is negligible.
  • the multiplication by two is there since the read implies both a read request and a read response, both implying a communication between the data provider 1 and the source device 10.
  • waste(T) If waste(T) is positive, it means cost of read is more than Observe-Notify-Store-Extract. Hence, by estimating the number of reads from data requester 11 semantics and/or history (e.g. using machine learning), waste for a future time period is predicted, leading to the selection of read mode or observe mode for the source device 10, corresponding respectively to a pass-through mode and cache mode for the data provider 1.
  • step 40 can be performed in a separate sequence of execution from the other steps of the method. Separate sequence of execution can be implemented using separate threads or separate processes. Step 40 can be repeated at certain intervals and/or when a need to determine operating mode occurs.
  • the data provider 1 receives a read request from the data requester 11.
  • the read request requests device data from the source device 10.
  • the read request comprises an indicator of acceptable device data age, defining a maximum age of device data that is acceptable for the data requester 11. For instance, a time critical application on the data requester 11 would have a much shorter acceptable device data age than an application on the data requester 11 which is not time critical.
  • An example of a time critical application is an alarm sensor while an example of an application which is not time critical is weather sensors.
  • step 43 the data provider 1 forks the method depending on the current operating mode.
  • step 40 occurs in a separate sequence of execution, the mode is communicated from the execution sequence of step 40 to the execution sequence of step 43, e.g. using inter-thread communication or inter-process communication.
  • the data provider 1 is in the pass-through mode (for the source device 10 in question)
  • the method continues to a transmit read request and forward response step 44.
  • the data provider 1 is in the cache mode (for the source device 10 in question)
  • the method continues to a retrieve device data from storage and transmit read response step 46.
  • the data provider 1 transmits a read request (corresponding to the read request received in the receive read request step 42) to the source device 10.
  • the data provider 1 forwards the read response, comprising device data, from the source device 10 to the data requester 11. This is illustrated in Fig 2A .
  • the data provider 1 retrieves device data from storage 66 of the data provider 1 and transmits a read response to the data requester 11.
  • the read response then comprises the device data which has been retrieved from storage 66. This is illustrated in Fig 2B .
  • the read request and the read response can be transmitted in accordance with a LWM2M, Lightweight Machine to Machine, specification, version 1.0 or later.
  • a populate storage step 48 the data provider populates, when the data provider is in the cache mode, the storage of the data provider with device data received from the source device.
  • the populate storage step 48 could be performed regardless of whether the current operating mode is the pass-through mode or the cache mode, but it is at least performed when the data provider is in the cache mode and is not necessarily performed when the current operating mode is the pass-through mode. It is to be noted that even though the populate storage step 48 is shown to occur after step 44 and step 46, the populate storage step 48 can be performed in a separate sequence of execution from the other steps of the method, and step 46 in particular.. In other words, step 48 does not need to be performed each time step 46 is performed.
  • this populating ensures the device data is populated sufficiently frequently to always satisfy the acceptable device data age.
  • the storage is populated sufficiently often such that the acceptable device data age in the read request is satisfied.
  • the shortest acceptable device data age is the most strict requirement, and thus needs to be complied with. This can be achieved by sending an observe command to the source device 10. The observe command causing the source device 10 to repeatedly notify the data provider 1 (or the storage 66 directly) with current device data.
  • this comprises sending a minimum wait time (Pmin).
  • the minimum wait time indicates a minimum time duration following a notify from the source device 10 during which no more notify actions will be performed by the source device 10 to the data provider 1.
  • this can comprise sending a maximum wait time (Pmax).
  • Pmax a maximum wait time
  • the maximum wait time indicates a maximum time duration following a notify from the source device 10 after which the source device 10 must perform a notify action to send current device data, even when the device data remains the same compared to a preceding notify action.
  • the data provider 1 may then also set the Pmin and Pmax attributes on the source device 10 before performing the observe action, as illustrated in Figs 2C and 2D .
  • a typical read request is used here as a baseline and compare the semantics of cache mode with it.
  • T is used to denote the expected time a read request typically takes before replying back with its known device data.
  • the idea is that the data provider 1 in cache mode should - at worst - wait T before replying back with the known device data.
  • Such action by the data provider 1 addresses latency considerations for the requests for device data while servicing reads requests from its own layer in the cache mode.
  • the data provider also ensures it is not serving old device data, or at least conforming to any desired staleness (acceptable device data age) semantics of the request, if any. How this is achieved is described above with reference to the populate storage step 48.
  • the Pmin and Pmax attributes have certain implications on such behaviour, and the following approach is used by the data provider 1 for such attributes.
  • any change in the observed device data in the source device 10 is notified to the data provider 1, and thus the data provider 1 is assured that it gets the device data that a typical passed-through read request would have obtained.
  • the typical time taken by a notification to be received by the data provider 1 must not be greater than T/2, which in turn means that a notification response from the source device 10 to the data provider 1 and its processing has similar cost/latency as a read response from the source device 10 to data provider 1.
  • the only extra cost/latency in the case of notification to the data provider 1 is for the action of storing the device data, so if that if this is relatively small or of a smaller order as compared to T, then it does not affect the above described semantics significantly.
  • one approach to address the potential staleness of the device data is to allow the read request to include a parameter for acceptable device data age, i.e. the request specifies how old device data it can tolerate.
  • the data requester 11 doing read requests can exploit such capability according to their own requirements.
  • the data provider 1 in turn would set the Pmin based on such values of acceptable device data age from multiple read requests.
  • the data provider 1 Since the data provider 1 switches to cache mode based on predicted number/volume/density of read requests, it may be useful to predict a possible non-zero Pmin value to use as well. Such prediction can be based on learning from history of read requests. For instance, if there is a noticeable pattern of a large number of read requests with some values of acceptable device data age coming in at a specific time during the day, this may be due to several data requesters 11 kick-in their periodic daily activity around the same time.
  • the data provider 1 When the data provider 1 is in the cache mode, and a read request arrives with a higher value of acceptable device data age than the predicted and configured Pmin value, then the predicted Pmin value suffices. But if a read request arrives with a lower value of acceptable device data age than the Pmin value configured by the data provider 1, then the data provider 1 will pass it through as a read request to the source device 10 directly, if it is a one-off request. If such a request is noticed by the data provider 1 as a periodic pattern in recent history, then the data provider 1 will learn and adapt to lower its predicted Pmin value accordingly.
  • the data provider 1 will increase the Pmin as required based on periodic exploration of the values of acceptable device data age of read requests waiting at the data provider 1 layer.
  • Pmax also serves as a heartbeat mechanism to the source device 10. This will depend upon the need of the data requester 11 to check the live status of the resource. In the absence of any other determination, Pmax can be set to 2 ⁇ Pmin. Note that the LWM2M standard stipulates that Pmax > Pmin.
  • the data provider 1 switches between the cache mode and the pass-through mode depending on what is best for the source device 10 in terms of resource usage, while complying with the requests from the data requesters 11. This significantly reduces resource usage for the source device 10.
  • Fig 4 is a schematic diagram illustrating components of the data provider of Fig 1 according to one embodiment.
  • a processor 60 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc., capable of executing software instructions 67 stored in a memory 64, which can thus be a computer program product.
  • the processor 60 can be configured to execute the method described with reference to Fig 3 above.
  • the memory 64 can be any combination of random access memory (RAM) and read only memory (ROM).
  • the memory 64 also comprises persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory.
  • a data memory 66 is also provided for reading and/or storing data during execution of software instructions in the processor 60.
  • the data memory 66 can be any combination of random access memory (RAM) and read only memory (ROM).
  • RAM random access memory
  • ROM read only memory
  • the data memory 66 can be any single one or combination of magnetic memory, optical memory, solid-state memory or even remotely mounted memory.
  • the data provider 1 further comprises an I/O interface 62 for communicating with external entities, such as the data requester and source device 10.
  • the I/O interface 62 also includes a user interface.
  • Fig 5 is a schematic diagram showing functional modules of the data provider 1 of Fig 1 according to one embodiment.
  • the modules are implemented using software instructions such as a computer program executing in the data provider 1.
  • the modules are implemented using hardware, such as any one or more of an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits.
  • the modules correspond to the steps in the methods illustrated in Fig 3 .
  • a mode determiner 70 corresponds to step 40.
  • a read request receiver 72 corresponds to step 42.
  • a mode evaluator 73 corresponds to step 43.
  • a pass-through provider 74 corresponds to step 44.
  • a cache provider 76 corresponds to step 46.
  • a storage populator 78 corresponds to step 48.
  • Fig 6 shows one example of a computer program product comprising computer readable means.
  • a computer program 91 can be stored, which computer program can cause a processor to execute a method according to embodiments described herein.
  • the computer program product is an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc.
  • the computer program product could also be embodied in a memory of a device, such as the computer program product 64 of Fig 4 .
  • the computer program 91 is here schematically shown as a track on the depicted optical disk, the computer program can be stored in any way which is suitable for the computer program product, such as a removable solid state memory, e.g. a Universal Serial Bus (USB) drive
  • USB Universal Serial Bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
EP17933977.5A 2017-12-04 2017-12-04 Data from a source device to a data requester Active EP3721349B1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2017/050569 WO2019111266A1 (en) 2017-12-04 2017-12-04 Data from a source device to a data requester

Publications (3)

Publication Number Publication Date
EP3721349A1 EP3721349A1 (en) 2020-10-14
EP3721349A4 EP3721349A4 (en) 2020-12-30
EP3721349B1 true EP3721349B1 (en) 2022-02-02

Family

ID=66751336

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17933977.5A Active EP3721349B1 (en) 2017-12-04 2017-12-04 Data from a source device to a data requester

Country Status (4)

Country Link
US (1) US11050838B2 (zh)
EP (1) EP3721349B1 (zh)
CN (1) CN111480329B (zh)
WO (1) WO2019111266A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020241661A1 (ja) * 2019-05-30 2020-12-03 京セラ株式会社 通信機器、通信機器の制御方法、通信方法、サーバ、及び通信システム

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040003101A1 (en) * 2002-06-26 2004-01-01 Roth David J. Caching control for streaming media
US8447837B2 (en) * 2005-12-30 2013-05-21 Akamai Technologies, Inc. Site acceleration with content prefetching enabled through customer-specific configurations
US9071545B2 (en) * 2012-11-03 2015-06-30 Netronome Systems, Incorporated Network appliance that determines what processor to send a future packet to based on a predicted future arrival time
US20150019686A1 (en) * 2013-07-12 2015-01-15 Seven Networks, Inc. Distributed caching systems with configurable extended caching optimization
WO2015161903A1 (en) * 2014-04-25 2015-10-29 Telefonaktiebolaget L M Ericsson (Publ) Apparatus and method for managing client devices
WO2015174916A1 (en) * 2014-05-14 2015-11-19 Telefonaktiebolaget L M Ericsson (Publ) Periodic management stabilization for internet of things
WO2015187068A1 (en) * 2014-06-02 2015-12-10 Telefonaktiebolaget L M Ericsson (Publ) Merging proxy
US10212233B2 (en) 2014-08-07 2019-02-19 Telefonaktiebolaget L M Ericsson (Publ) Data transfer in a system of connected things
US10893051B2 (en) * 2015-07-02 2021-01-12 Convida Wireless, Llc Resource-driven dynamic authorization framework
CN106330398A (zh) 2016-08-29 2017-01-11 中国联合网络通信集团有限公司 一种确定物联网业务的数据传输模式的方法及装置

Also Published As

Publication number Publication date
US11050838B2 (en) 2021-06-29
EP3721349A4 (en) 2020-12-30
EP3721349A1 (en) 2020-10-14
US20200304590A1 (en) 2020-09-24
CN111480329B (zh) 2023-07-11
CN111480329A (zh) 2020-07-31
WO2019111266A1 (en) 2019-06-13

Similar Documents

Publication Publication Date Title
JP7097525B2 (ja) モノのインターネットのリソースサブスクリプション方法、デバイス、およびシステム
RU2670794C9 (ru) Способ и система формирования гибкого узла на локальных или распределенных вычислительных системах
WO2017112365A1 (en) Managing communication congestion for internet of things devices
US11425209B2 (en) Communication system
WO2017112366A1 (en) Managing communication congestion for internet of things devices
WO2017112364A1 (en) Managing communication congestion for internet of things devices
US9417907B1 (en) Impact management of system tasks
EP3143781B1 (en) Periodic management stabilization for internet of things
EP3329657A1 (en) A method a server and a client for policy based control of m2m devices
US10159041B2 (en) Communication apparatus, method of controlling the same, and non-transitory computer-readable storage medium
CN105612778A (zh) 基于移动设备应用层协议测量值的无线电或网络评估选择方法
EP3721349B1 (en) Data from a source device to a data requester
CN112436951B (zh) 一种预知流量路径的方法和装置
Kiani et al. Context-aware service utilisation in the clouds and energy conservation
EP3685567B1 (en) Load shedding of traffic based on current load state of target capacity
US9300561B2 (en) Business intelligence-infused smart retransmission processing
JP2020136745A (ja) ゲートウェイ、通信システム及び通信方法
US10313253B2 (en) Non-blocking request processing method and device
CN114035861A (zh) 集群配置方法、装置、电子设备和计算机可读介质
US20160099997A1 (en) Method and system for managing application data in a communication device
JP2017107382A (ja) プログラム実行システム、プログラム実行方法、および、プログラム
US12028403B2 (en) Observation of resources by a CoAP client
US20180227245A1 (en) Method, apparatus and system for addressing resources
JP2012018483A (ja) 情報処理制御システム、情報提供装置、処理頻度通知装置および情報処理制御方法
KR102367017B1 (ko) 통신 네트워크 시스템 및 그것의 제어방법

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20200629

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

A4 Supplementary search report drawn up and despatched

Effective date: 20201126

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 15/16 20060101AFI20201120BHEP

Ipc: H04L 29/06 20060101ALI20201120BHEP

Ipc: H04L 29/08 20060101ALI20201120BHEP

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 15/16 20060101AFI20210531BHEP

Ipc: H04L 29/06 20060101ALI20210531BHEP

Ipc: H04L 29/08 20060101ALI20210531BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20210716

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

Ref country code: AT

Ref legal event code: REF

Ref document number: 1466769

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220215

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602017053077

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220202

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1466769

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220602

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220502

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220502

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220503

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220602

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602017053077

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20221103

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230523

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20221231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221204

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20221231

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20231227

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20231229

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20171204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220202