Patent Description:
An IoT network may include as "things", devices traditionally thought of as being in a network such as smartphone(s), laptop(s), personal computer(s), server(s), storage device(s), drive(s), etc., and/or other devices not traditionally thought of as being in a network such as light(s); appliance(s); vehicle(s); trash can(s); heating, ventilating, and air-conditioning (HVAC); window(s), window shade(s) and blind(s); door(s); lock(s); sensor(s); actuator(s); robot(s); camera(s); etc. An IoT network may include a private network and/or a publicly accessible network.

The oneM2M model used in the oneM2M (machine to machine) standard is a layered model supporting end to end machine to machine services. Such a model may be used for an IoT network. In accordance with the oneM2M release <NUM> specification, the layered model includes three layers: an application layer, a common services layer, and an underlying network services layer. An application entity (AE) is an entity in the application layer that implements an M2M application service logic. Each application service logic may be resident in a number of M2M nodes and/or more than once on a single M2M node. Each execution instance of an application service logic is termed an application entity. A common services entity (CSE) represents an instantiation of a set of common service functions of the M2M environments. Such service functions are exposed to other entities through Mca and Mcc reference points. Reference point Mcn is used for accessing underling network service entities. A network services entity (NSE) provides services from the underlying network to the CSEs. Document <CIT> disclosed data aggregation in an IoT system.

So that the present disclosure may be understood by those of ordinary skill in the art, a more detailed description may be had by reference to aspects of some illustrative implementations, some of which are shown in the accompanying drawings. The appended drawings, however, illustrate only some example features of the present disclosure and are therefore not to be considered limiting, for the description may admit to other effective features.

In accordance with common practice the various features illustrated in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may not depict all of the devices, blocks, stages, etc. of a given network, method, etc..

The invention of the present European patent is set out in the appended claims.

There is provided, in accordance with some embodiments of the presently disclosed subject matter, a method performed by a first device, comprising intercepting a first communication that is destined for a second device or that is originating from the second device but is not destined for the first device, the first communication requesting data relating to a third device or indicative of data determined by and relating to the third device, subsequent to the intercepting, generating a second communication destined for the second device, wherein the second communication is indicative of data relating to the third device that was determined by at least one of the first device or one or more fourth devices, and sending the second communication.

There is further provided, in accordance with some embodiments of the presently disclosed subject matter a device, comprising networking circuitry, and processing circuitry, wherein the processing circuitry is adapted to intercept communications entering the device via the networking circuitry, wherein the communications are not destined for the device and wherein the communications request data relating to any of one or more other devices or are indicative of data determined by and relating to any of the one or more other devices, collect data relating to any of the one or more other devices, the data that is collected including at least one of : data entering the device via the networking circuitry which was not determined by the one or more other devices, or data determined by the processing circuitry, generate other communications destined for any of one or more destination devices, each other communication indicative of at least part of the data that was collected, and send the other communications via the networking circuitry.

<FIG> illustrates a network <NUM>, in accordance with some embodiments of the presently disclosed subject matter.

As shown in <FIG>, network <NUM> includes a plurality of endpoint devices <NUM> (also referred to herein simply as endpoints) of which two are shown in <FIG>, namely device <NUM> and device <NUM>. Examples of endpoint devices <NUM> may include, for instance, smartphone(s), laptop(s), personal computer(s), server(s), storage device(s), drive(s), light(s); appliance(s); vehicle(s); trash can(s); heating, ventilating, and air-conditioning; window(s), window shade(s) and blind(s); door(s); lock(s); sensor(s); actuator(s); robot(s); camera(s), etc. Network <NUM> further includes one or more devices <NUM> which are part of a networking infrastructure <NUM> that supports communication by endpoint devices <NUM>. Device(s) <NUM> may therefore also be referred to herein as networking infrastructure device(s). Device(s) <NUM> may vary depending on network <NUM>, and may include any device(s) appropriate for network <NUM>. For example, device(s) <NUM> may include any of routers, gateways, switches, servers, storage devices, access points (e.g. for Wi-Fi), controllers, cellular base stations, modems, telephone adaptors, Meraki enterprise products, etc. The functionality of devices <NUM> may relate to the control plane and/or user plane of network <NUM>. Network <NUM> may in some cases support cloud computing. In such cases, one or more of devices <NUM> may be in the "cloud".

In some embodiments, network <NUM> may be an IoT network. In such embodiments, endpoint device(s) <NUM> may be "thing(s)" of the IoT network, and/or may also be referred to herein as IoT device(s).

Depending on the implementation, any two device(s) <NUM> and/or <NUM> may be adapted to communicate in any appropriate manner, e.g. via wireless and/or wired connection(s) in networking infrastructure <NUM>. For example, two or more devices <NUM> may be adapted to communicate with one another in order to facilitate communication between device <NUM> and <NUM>. Communication between any two devices <NUM> and/or <NUM> may be implemented at least in part via conventional interfaces, such as standardized <NUM>rd Generation Partnership Project (3GPP) interfaces, standardized European Telecommunications Standards Institute (ETSI) interfaces, Application program interfaces (APIs) (e.g. representational state transfer (REST or RESTful) APIs, mobility service engine (MSE) REST APIs, Cisco Prime APIs, Meraki APIs, etc.), etc.; and/or may be implemented at least in part via non-conventional interfaces.

Any device <NUM> or <NUM> may include any hardware and/or software appropriate for the functionality attributed to the device <NUM> or <NUM>. Software may include firmware, when suitable. In the example illustrated in <FIG> of a particular device <NUM> or <NUM>, the particular device <NUM> or <NUM> includes networking circuitry <NUM> appropriate for communicating in network <NUM>. Networking circuitry <NUM> may include components for wireless communication (e.g. any of antenna(s), transmitter(s)/receiver(s), etc.) and/or components for wired communication (e.g. wired network interface(s), wired network switch(es), etc.). In the example illustrated in <FIG>, the particular device <NUM> or <NUM> further includes processing circuitry <NUM> for performing functionality attributed herein to the particular device <NUM> or <NUM>, including functionality relating to communicating via networking circuitry <NUM> and/or other functionality. Processing circuitry <NUM> may include, for instance any of the following: processor(s), state machine(s), other type(s) of integrated circuit(s) comparator(s), adder(s), multiplier(s), shift register(s), combinatory logic (such as multiplexer(s), OR gate(s), AND gate(s), XOR gate(s) etc.), electronic component(s) (e.g. resistor(s), inductor(s), capacitor(s), diode(s), transistor(s), other switching component(s), etc.), wiring, etc. Processing circuitry <NUM> may additionally or alternatively include one or more integrated circuits (e.g. field programmable gate array(s) (FPGA(s)), application specific integrated circuit(s) (ASIC(s)), full-custom integrated circuit(s), etc.), printed circuit boards (also referred to as printed circuit board assemblies), and/or the like, which may for instance comprise circuitry (such as examples of processing circuitry <NUM> described in the previous sentence) that is suitable for inclusion in such integrated circuit(s), printed circuit board(s) and/or the like. If processor(s) are included in processing circuitry <NUM>, each included processor may be of any suitable type operative to execute instructions, such as a load store processor, a processing pipe, a programmable very long instruction word (VLIW) engine, etc. Processor(s) may include, for example, any of the following: graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)) central processing units (CPU(s)), etc. Any device <NUM> or <NUM> which includes processing circuity <NUM> is also referred to herein as a computer.

In the illustrated example, the particular device <NUM> or <NUM> further includes at least one memory <NUM>. Each memory <NUM> may be of any appropriate type such as an optical computer readable storage medium, a magnetic computer readable storage medium, or an electronic computer readable storage medium. If there is a plurality of memories <NUM>, any two memories <NUM> in the plurality may be of the same type or different types. The at least one memory <NUM> may include, for instance, any of the following: volatile, non-volatile, erasable, non-erasable, removable, non-removable, writeable, re-writeable memory, for short term storing, for long term storing, etc., such as registers, read-only memory (ROM), static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, embedded DRAM, etc. In embodiments where processing circuitry <NUM> includes processor(s), memory/ies <NUM> may store computer readable program code (also referred to herein as software or instructions), the processor(s) being adapted to execute such computer readable program code in order to perform at least part of the functionality attributed to the particular device <NUM> or <NUM>. The at least one memory <NUM> may additionally or alternatively store data relating to the subject matter (e.g. by implementing one or more databases in network <NUM> which will be described in more detail below).

Optionally, the particular device <NUM> or <NUM> includes one or more other modules known in the art such as input/output modules for interacting with users of the device <NUM> or <NUM>, etc..

It is noted that reference herein to a device (e.g. device <NUM> or <NUM>) in the single form should be construed to cover embodiments where all of the hardware and/or software that comprises the device is included within a single physical unit (i.e. within a single enclosure), as well as embodiments where not all of the hardware and/or software that comprises the device is included within a single physical unit (i.e. not included within a single enclosure).

Although network <NUM> is referred to in the single form, network <NUM> may in some examples comprise sub-parts which may also be referred to as networks, as will be understood by those skilled in the art.

For example, if network <NUM> includes a mobile network, network <NUM> may include a radio access network (RAN) and a core network (also referred to as a "packet core"). The mobile network may be a 3GPP network for instance for <NUM>, <NUM>, <NUM> or <NUM> cellular network technology. A device which connects via a radio access network is also referred to herein as a user equipment (UE). In one particular embodiment, the mobile network may be a <NUM> narrowband IoT network, (e.g. in accordance with 3GPP release <NUM>), and/or the packet core may be a next generation packet core. Network <NUM> may additionally or alternatively include the Internet, local area network(s) (e.g. Ethernet, Wi-Fi), and/or other packet data network(s).

In some embodiments, network <NUM> or a part thereof may be operated by a service provider (e.g. mobile operator); and/or network <NUM> or a part thereof may be operated by an enterprise, individual or family which also operates at least part of devices <NUM>. For example, a service provider may operate at least part of networking infrastructure <NUM> (e.g. networking infrastructure of a packet core and RAN that are included in network <NUM>); and an enterprise may operate devices <NUM> and optionally may also operate a part of networking infrastructure <NUM>. As another example, an enterprise may operate both networking infrastructure <NUM> and devices <NUM>. Network <NUM> or any part thereof may be private and/or public.

In examples where network <NUM> comprises sub-parts (e.g. networks with different protocols), a particular device <NUM> in networking infrastructure <NUM> which enables the interfacing between different sub-parts is also referred to herein as a gateway. Such a gateway may for instance perform protocol translation and/or other conversion, as necessary to interface between the different sub-parts. In some embodiments where a gateway interfaces to a mobile network, the gateway may be a UE, adapted to connect via a radio access network of the mobile network.

<FIG> is a functional block diagram of network <NUM>, in accordance with some embodiments of the presently disclosed subject matter.

For example, <FIG> emphasizes the functionality of network <NUM> which enables data regarding any particular endpoint device <NUM> (e.g. endpoint device <NUM> of <FIG>) to be provided to other endpoint device(s) <NUM> in network <NUM> (e.g. endpoint device <NUM> of <FIG>), even when such data is not determined by the particular endpoint device <NUM>. Consequently, the particular endpoint device <NUM> may not be required to have the capabilities of determining all data that may be provided regarding the particular endpoint device <NUM>; enabling the particular endpoint device <NUM> to be simpler and cheaper than if all data which may be provided regarding the particular endpoint device <NUM> would have to be determined by the particular endpoint device <NUM>. Moreover, not requiring all the data to be determined by the particular endpoint device <NUM> may enable a lower data rate to be sufficient between the particular endpoint device <NUM> and networking infrastructure <NUM>.

Endpoint device <NUM> of <FIG> is assumed to be the destination endpoint for data regarding endpoint device <NUM> which is the subject endpoint. Therefore destination endpoint <NUM> may perform the functionality of a data consumer (represented by the functional block data consumer <NUM> in <FIG>), or in other words may implement data consumer <NUM> of <FIG>. Subject endpoint <NUM> may determine some of the data and therefore may perform the functionality of a data source (represented by the functional block internal data source <NUM> in <FIG>) for some of the data, whereas other data may be determined by external data source(s) <NUM> and/or by a data handler <NUM> shown in <FIG>. Subject endpoint <NUM> may therefore be referred to as implementing internal data source <NUM>. An endpoint device is termed herein a subject endpoint device or subject device if the endpoint device is the subject of the data, or in other words the data relates to the subject endpoint device; whereas an endpoint device is termed herein a destination endpoint device or destination device if the data is destined for the endpoint device.

For example, consumption of data regarding one or more subject endpoint device <NUM> in network <NUM>, including regarding subject endpoint <NUM>, by data consumer <NUM>, may include the administration of subject endpoints <NUM> by data consumer <NUM>. In such an example, destination endpoint device <NUM> may be used by an end-user such as an administrator responsible for subject endpoint device(s) <NUM>, for obtaining data regarding subject endpoint device(s) <NUM>. Consumption of data regarding subject endpoint(s) <NUM> (e.g. more specifically administration of subject endpoint device(s) <NUM>) by data consumer <NUM> may include any appropriate activities such as sending communications (e.g. requests for data regarding subject endpoint device(s) <NUM>), receiving communications (e.g. including data regarding subject endpoint device(s) <NUM>), evaluating received data, acting based on received data, etc. As an example of administration, assuming that the data relates to trash cans when subject endpoint devices <NUM> are trash cans, acting based on the received data may include scheduling garbage collection, etc..

It is noted that for simplicity's sake, the description herein will refer to a single data consumer <NUM>, consuming data regarding one or more subject endpoint devices <NUM>. However, the functional block data handler <NUM> and optional functional block(s) hub <NUM>, central interface <NUM>, external data source(s) <NUM> and/or translator <NUM> shown in <FIG> and which will now be described, may in some embodiments service a plurality of data consumers (e.g. associated with various destination devices <NUM>), each of the data consumers consuming data relating to a respective set of one or more subject endpoint devices <NUM> performing the functionality of internal data source(s). In such embodiments, there may or may not be overlap in subject endpoint devices <NUM> between the sets.

The functional block data handler <NUM> and optional functional block(s) hub <NUM>, central interface <NUM>, external data source(s) <NUM> and/or translator <NUM> shown in <FIG> may be part of networking infrastructure <NUM> of <FIG>. The functional block(s) <NUM>, <NUM>, <NUM>, <NUM> and/or <NUM> may therefore be implemented by one or more devices <NUM> (<FIG>) in networking infrastructure <NUM> (or in other words one or more devices <NUM> may perform the functionality represented by functional block(s) <NUM>, <NUM>, <NUM>, <NUM> and/or <NUM>). The functional blocks may be implemented by any appropriate configuration. For example, any functional block <NUM>, <NUM>, <NUM>, <NUM> or <NUM> may represent functionality performed by a single device <NUM> in networking infrastructure <NUM>, or may represent functionality performed by a plurality of devices <NUM>. As another example, any two or more functional blocks <NUM>, <NUM>, <NUM>, <NUM> and/or <NUM> may represent functionality performed by a single device <NUM> or by a plurality of devices <NUM>. As another example, although hub <NUM>, data handler <NUM>, interface <NUM>, and data source(s) <NUM> are shown in <FIG> in separate functional blocks, part or all of hub <NUM>, data handler <NUM>, interface <NUM>, and data source(s) <NUM> may be co-located, or may even be in the same physical unit.

Optional hub <NUM> may be adapted to act as a hub for communications in network <NUM>. Hub <NUM> may include a resource database <NUM> where resources relating to network <NUM> may be registered and state data for the resources may be stored. For example, if resources include data consumer(s) (e.g. including data consumer <NUM>) and/or internal data source(s) (e.g. including internal data source <NUM>), then state data may include identifiers of data consumer(s) and/or internal data source(s) (e.g. identifiers of corresponding destination and/or subject endpoint devices <NUM>). Other examples of resources and state data are described further below. Generally, state data for a resource may include numerical, textual and/or any other type of data descriptive of the state of the resource. Hub <NUM> may additionally or alternatively include transferer <NUM> adapted to transfer communications in network <NUM>.

Data handler <NUM> may be adapted to handle data regarding subject endpoints <NUM>. As such, data handler <NUM> may include a communication generator <NUM> adapted to generate a communication for data consumer <NUM>, which is indicative of data regarding subject endpoint <NUM> that was not determined by internal data source <NUM>, but was instead determined by other source(s) such as external data source(s) <NUM> and/or data handler <NUM>.

Optionally, the generated communication is also indicative of data regarding subject endpoint <NUM> that was determined by internal data source <NUM>, and in such a case the data not determined by internal data source <NUM> may be referred to herein as enriching the data determined by internal data source <NUM>. Data handler <NUM> may further include an interceptor/sender <NUM> adapted to intercept communications destined for data consumer <NUM> and/or to intercept communications from data consumer <NUM> that are not destined for data handler (e.g. that are destined for internal data source <NUM> and/or for translator <NUM>). Depending on the intercepted communication, the intercepted communication may proceed to data consumer <NUM> or to the other destination (e.g. internal data source <NUM> and/or translator <NUM>); the intercepted communication may not proceed and instead a communication generated by communication generator <NUM> may be sent to data consumer <NUM>; or the intercepted communication may proceed and a communication generated by communication generator <NUM> may additionally be sent to data consumer <NUM>. The term "interception" is used herein because the intercepted communication intercepted by interceptor/sender <NUM> is not destined for data handler <NUM>. It is noted that communication(s) between data consumer <NUM> and internal data source <NUM>/translator <NUM> are optionally communicated via transferer <NUM> and in such a case interceptor/sender <NUM> may be adapted to intercept a communication being transferred between transferer <NUM> and internal data source <NUM>/translator <NUM>. In some examples, interceptor/sender <NUM> may be adapted to perform the functions of a proxy server in network <NUM>.

Data handler <NUM> may further include a collector <NUM> adapted to collect data from external data source(s) <NUM>, optionally via a separate central interface <NUM>, and/or to collect data determined by analyzer <NUM>. Collector <NUM> may be adapted to provide collected data to communication generator <NUM>, to a resource manager <NUM> (if included) for registering in resource database <NUM> and/or to a handler database <NUM> (if included in data handler <NUM>).

Data handler <NUM> optionally also includes any of the following functional blocks: resource manager <NUM>, an analyzer <NUM> and/or handler database <NUM>. Resource manager <NUM>, if included, may be adapted to register resources in resource database <NUM> for which state data is to be determined by external data source(s) <NUM> and/or by analyzer <NUM>; and optionally to provide to, and/or receive from, the resource database <NUM> the state data for such resources. Such state data may be the most recent state data for respective resources collected by collector <NUM>. The most recent collected state data that was collected for a resource may be current state data (e.g. reflective of the current state of the resource as of the time of determination of the state data), and/or predicted state data (e.g. reflective of a predicted future state of the resource that was most recently determined as of the time of collection).

Handler database <NUM>, if included, may be adapted to store the most recent data collected by collector <NUM> relating to subject device(s) <NUM>. The most recent collected data may be reflective of current data regarding subject device(s) <NUM> (e.g. current state(s) of resource(s)) as of the time of determination; and/or may be reflective of predicted future data regarding subject devices <NUM> (e.g. predicted future state(s) of resource(s)) that was most recently determined as of the time of collection. Handler database <NUM> may be additionally or alternatively adapted to store previously collected data (e.g. previously collected state data for resources) collected by collector <NUM>. Previously collected data, collected prior to the most recent collecting (e.g. at various times prior to the most recent collecting), is also referred to herein as historical collected data or historical data.

Analyzer <NUM>, if included, may be adapted to analyze data that was collected, such as data that was not yet stored or will not be stored, data stored in handler database <NUM>, and/or data stored in resource database <NUM> (e.g. which analyzer <NUM> may be adapted to obtain via resource manager <NUM>). Analyzer <NUM> may further be adapted, based on a result of the analysis to perform one or more actions. Such action(s) may include, for instance, any of the following: determining data (e.g. current data and/or predicted future data) relating to subject endpoints <NUM> for provision to collector <NUM> (e.g. in case such data is used by communication generator <NUM> for formulating communications); determining changes in resources (e.g. including proposing resource(s) to resource manager <NUM> for registering in resource database <NUM>); and/or determining changes in collection (e.g. including proposing to collector <NUM> to collect data which was not previously collected).

A communication generated by communication generator <NUM> may be indicative of data regarding subject endpoint <NUM>, for instance:.

It is noted that data relating to subject endpoint <NUM> may not necessarily exclusively relate to subject endpoint <NUM>, and may in some cases also relate to other subject endpoint(s) <NUM>. For example, data regarding a collection of subject endpoints <NUM> that includes subject endpoint <NUM> may be considered to be related to subject endpoint <NUM> although not exclusively.

A communication is indicative of specific data by including the specific data or by including an identifier for retrieving the specific data. For example, data stored in resource database <NUM>, or an identifier for retrieving such data, may be retrieved by resource manager <NUM> and provided to communication generator <NUM> for inclusion in a generated communication. As another example, data stored in handler database <NUM>, or an identifier for retrieving such data, may be retrieved by communication generator <NUM> from handler database <NUM> for inclusion in a generated communication. As another example, data in an intercepted communication, or an identifier in an intercepted communication for retrieving such data may be provided by interceptor/sender <NUM> to communication generator <NUM> for inclusion in a generated communication. As another example, collector <NUM> may provide data that was collected to communication generator <NUM> for inclusion in a generated communication, etc. An example of an identifier for retrieving specific data may be a uniform resource identifier (URI) for retrieving specific data such as the most recent collected data and/or previously collected data from resource database <NUM>, from handler database <NUM>, or from any other database (such as a translator database <NUM> to be described further below). A communication may include the indication (e.g. the specific data, an identifier for retrieving the specific data, etc.), for instance, in the payload, in header(s), etc. of the communication.

In some examples where network infrastructure <NUM> includes a packet core, hub <NUM> and/or data handler <NUM> may be implemented in the packet core. Additionally or alternatively, for example, at least part of hub <NUM> (e.g. including resource database <NUM>) may be implemented in the cloud. Additionally or alternatively, the routing table of transferer <NUM>, and the routing table(s) of translator <NUM> and/or internal data source <NUM>, may be implemented such that interceptor/sender <NUM> is the default gateway for communications being transferred between transferer <NUM> and translator <NUM>/internal data source <NUM>. Additionally or alternatively, for example, interceptor/sender <NUM> may be adapted to intercept communications by being implemented such that interceptor/sender <NUM> may intercept communications being transferred from the mobility management entity (MME) on the T6a interface, such as communications including data payloads over the control plane (e.g. data carried short message service SMS); and/or may intercept communications being transferred from the Serving Gateway/PDN Gateway (SPGW) on the SGi interface, such as communications carrying regular user plane payloads.

Optional external data source(s) <NUM> may represent any appropriate functionality for determining data regarding subject endpoint <NUM> (and optionally other subject endpoints <NUM>) in network <NUM>. For example, external data source(s) <NUM> may represent detecting and/or computing functionality. Determination of data by data source(s) <NUM> and/or by data handler <NUM> may occur in response to a request from collector <NUM>, and/or independently of any request by collector <NUM>. If occurring independently, the determination may occur periodically and/or upon the occurrence of one or more events. Device(s) <NUM> which implement external data source(s) <NUM> may also be referred to herein as source devices. In some examples where network infrastructure <NUM> includes a packet core and a radio access network, external data source(s) <NUM> may be implemented in the packet core and/or in the radio access network.

Optional translator <NUM> may represent protocol translation and/or other conversion functionality between a sub-part of network <NUM> which implements internal data source <NUM>, and another sub-part of network <NUM> which implements interceptor/sender <NUM>. Translator <NUM> optionally also represents other functionality such as dynamic discovery of new devices, device management, security and access rights, subscription and notification, and/or data management and repository. Translator <NUM> may include translator database <NUM> for storing data determined by internal data source <NUM>. For example, resources may be registered in translator database <NUM> (e.g. by internal data source <NUM>) for state data that is to be determined by internal data source <NUM>. Resources for state data determined by internal data source <NUM> may be registered in translator database <NUM> (e.g. by internal data source <NUM>) and/or in resource database <NUM> (e.g. by translator <NUM> and/or by internal data source <NUM>). State data determined by internal data source <NUM> may be stored in translator database <NUM> (e.g. by internal data source <NUM>) and/or in resource database <NUM> (e.g. by translator <NUM> and/or by internal data source <NUM>). In some embodiments where data determined by internal data source <NUM> is stored, translator <NUM> and/or internal data source <NUM> may formulate communications for data consumer <NUM> using stored data (e.g. stored in translator database <NUM>), and/or using identifiers for retrieving such stored data. Translator <NUM> and/or internal data source <NUM> may additionally or alternatively formulate communications for data consumer <NUM> using data that was not stored.

In some embodiments translator <NUM> may be omitted, e.g., if internal data source <NUM> is not implemented by a different sub-part of network <NUM> than interceptor/sender <NUM>. In some embodiments, hub <NUM> may be omitted, e.g. if registration of resources at hub <NUM> does not take place. In some embodiments, separate central interface <NUM> may be omitted, e.g. if collector <NUM> interfaces directly to external data source(s) <NUM>. In some embodiments, external data source(s) <NUM> may be omitted, e.g. if data not determined by internal data source <NUM> may be determined by data handler <NUM>. In some embodiments, a translator may be added between data consumer <NUM> and hub <NUM>, e.g. if data consumer is implemented by a different sub-part of network <NUM> than hub <NUM>.

Any of the functional blocks (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in any of the above) shown in <FIG> may be implemented by hardware and/or software included in one or more devices <NUM> and/or <NUM> shown in <FIG>. It should be understood that the functional blocks of <FIG> are presented to simplify the discussion of the subject matter, and that in some embodiments, the functionality attributed herein to any two or more functional blocks may be performed by a consolidated functional block; the functionality attributed herein to any single functional block, may be distributed among two or more functional blocks; and/or functionality attributed herein to a particular functional block may be performed in addition or instead by one or more other functional blocks. It should also be understood that the lines shown in <FIG> between the functional blocks are for illustration of certain possible interactions between functional blocks, and that in some embodiments there may be fewer, more and/or different interactions between the functional blocks than illustrated in <FIG>.

As mentioned above, in some embodiments, network <NUM> may be an IoT network in which the oneM2M model may be applied. In such embodiments, resources may be registered in accordance with the oneM2M model, and the communications in network <NUM> may be in accordance with the oneM2M model (e.g. in accordance with the communication management requirements specified in TS-<NUM>-V2. <NUM> and/or in other oneM2M specification(s)). In accordance with the oneM2M model, for instance, the following operations may be performed in network <NUM>: create, retrieve, update, delete, and notify. An appropriate device <NUM> (e.g. server) in networking infrastructure <NUM> (<FIG>) may include an IN-CSE (infrastructure common service entity). IN-CSE may be software which, in conjunction with processor(s) <NUM> adapted to run the software, may at least partly implement hub <NUM> (<FIG>). For example, the IN-CSE, in conjunction with processor(s) <NUM> adapted to run the software and in conjunction with memory/ies <NUM> for storing data, may at least partly implement a register (e.g. resource database <NUM> - <FIG>) of hub <NUM>. Destination endpoint device <NUM> (<FIG>) may include an IN-AE (infrastructure application entity), for example, software for consuming data regarding subject device <NUM> (1A) and optionally other subject devices <NUM> (e.g. where the software in conjunction with processor(s) <NUM> which are adapted to run the software, may at least partly implement data consumer <NUM> of <FIG>). If subject device <NUM> is a light, for instance, then the software may remotely control the light. In another instance, if subject device <NUM> is a trash can, then the software may manage collection of trash from the trash can. The IN-AE may register to the IN-CSE. An appropriate gateway <NUM> in networking infrastructure <NUM> (<FIG>) may include a middle node common service entity (MN-CSE). MN-CSE may be software which, in conjunction with processor(s) <NUM> adapted to run the software, may at least partly implement translator <NUM> (<FIG>). For example, the MN-CSE, in conjunction with processor(s) <NUM> adapted to run the software and in conjunction with memory/ies <NUM> for storing data, may at least partly implement a register (e.g. translator database <NUM>- <FIG>) of translator <NUM>. The MN-CSE may register to the IN-CSE. A subject endpoint <NUM> may include an application dedicated node application entity (ADN-AE), e.g. which registers to a CSE (e.g. to MN-CSE and/or to IN-CSE), or may include an application service node (ASN) AE and CSE. The ASN-CSE may register to the MN-CSE and/or to the IN-CSE. For example, the ADN or ASN may include software, which in conjunction with processor(s) <NUM> adapted to run the software, may at least partly implement internal data source <NUM>. It is noted that when reference is made herein to MN/ASN-CSE, the reference should be understood to refer to either or both the MN-CSE or the ASN-CSE. A device <NUM> in networking infrastructure <NUM> (<FIG>) may include another CSE. The other CSE may be software which, in conjunction with processor(s) <NUM> adapted to run the software, may at least partly implement central separate interface <NUM> (if included in network <NUM>). For convenience sake, such oneM2M terms are shown in brackets on <FIG>.

<FIG> illustrates a oneM2M base ontology, in accordance with some embodiments of the presently disclosed subject matter. The oneM2M ontology shown in <FIG> includes classes of: thing, thing property, device, area network, interworked device, variable, aspect, service, function, controlling function, measuring function, command, operation, input datapoint, output datapoint, operation state, operation input, operation output, set_output datapoint, set_input datapoint, simpletype variable, variable conversion, metadata, etc.; and the relationship between such classes. A class shown with shading indicates that the class appears more than one time in <FIG>. If the oneM2M standard is used in network <NUM>, then one or more of such classes may be registered as resources. The state data of registered resources may vary. For example, the state data may vary over time, may vary depending on the configuration of network <NUM>, may vary depending on the characteristics of endpoint devices <NUM>, etc. Some classes such as the variable class, aspect class, etc., may not be registered as resources but may instead function as placeholders (e.g. containers) for the state data of certain registered resources.

<FIG> illustrates an example of the usage of the oneM2M ontology, in accordance with some embodiments of the presently disclosed subject matter. More specifically, <FIG> relates to subject endpoint <NUM> and shows certain examples of classes which may be registered as resources; the state data of the registered resources determined by device(s) <NUM> in networking infrastructure <NUM>. Such device(s) <NUM> may implement external data source(s) <NUM> and/or data handler <NUM>.

For simplicity's sake, <FIG> may not necessarily show certain intermediate classes and certain relationships between classes. In the example of <FIG>, it is assumed that network <NUM> includes a RAN and that subject endpoint device <NUM> is a temperature sensor. Therefore thing <NUM> is "temperature sensor". Temperature sensor <NUM> is related by "has location" to a thing property <NUM> "best RAN location approximation". Best RAN location approximation <NUM> is related by "is a" to a variable "latitude/longitude pair" <NUM>. Temperature sensor <NUM> is related by "has last seen" to a thing property <NUM> "was last seen on the network". Was last seen on the network <NUM> is related by a "is a" to a variable "UTC timestamp" <NUM>. Temperature sensor <NUM> is related by "has RF signal" to a thing property <NUM> "last reported radio frequency (RF) signal measure" <NUM>. Last reported RF signal measure <NUM> is related by a "is a" to a variable "decibel (dB) level" <NUM>. Temperature sensor <NUM> is related by "has operation state" to an operation state <NUM> "last operation state". Last operation state <NUM> is related by "is a" to a simpletype variable "idle, connected, etc." <NUM>. Temperature sensor <NUM> is related by "is adjacent to" to one or more other temperature sensors, of which two are shown: a "thing another near-by temperature sensor" <NUM>, and a "thing another near-by temperature sensor" <NUM>. Temperature sensor <NUM>, another near-by temperature sensor <NUM>, and another near-by temperature sensor <NUM> are all related by "is part of" to an area network <NUM> "temperature sensors".

It should be understood that <FIG> is not meant to be comprehensive and may be broadened, changed, or narrowed depending on the data that is to be determined by external data source(s) <NUM> and/or by data handler <NUM>, the type of subject endpoint device <NUM> to which the data is related, etc. Additionally or alternatively, <FIG> may include resource(s) whose state data is determined by internal data source <NUM> implemented by subject endpoint device <NUM>.

Examples of collector <NUM>, separate central interface <NUM> and external data source(s) <NUM> relating to collection of data will now be provided with reference to <FIG>. The examples assume that network infrastructure <NUM> includes a packet core conforming with a 3GPP architecture, e.g. for <NUM>, <NUM>, <NUM> or <NUM>.

<FIG> illustrates a collection architecture <NUM>, in accordance with some embodiments of the presently disclosed subject matter.

Collection architecture <NUM> is an example of indirect interface collection, because in collection architecture <NUM> the collection by a collector <NUM> is performed via a separate central interface, namely a service capability exposure function (SCEF) <NUM>, which may be used for various purposes, not necessarily all of which are related to the subject matter. For example, SCEF <NUM> may be used for communication, subscription, context, and control purposes. SCEF <NUM> may be an example of separate central interface <NUM> of <FIG>.

Collector <NUM> may be an example of collector <NUM> (<FIG>), and data sources <NUM> may be examples of external data source(s) <NUM> of <FIG>. Collector <NUM> may act as an application server to SCEF <NUM>. Data sources <NUM> may include an authorization server, a home subscriber server (HSS), a RAN Congestion awareness function (RCAF), a charging data function (CDF), a charging gateway function (CGF), a serving general packet radio service support node (SGSN), a serving call state control function (S-CSCF), a policy and charging rules function (PCRF), a broadcast multicast service center (BM-SC), an online charging function (OCF), an online charging system (OCS), a machine type communications interworking function (MTC-IWF), an interworking SCEF (IWK-SCEF) and/or an MME cellular IoT serving gateway node (MME,C-SGN). REST APIs <NUM> may be used to pull information from SCEF <NUM>. Interfaces <NUM> between SCEF <NUM> and data sources <NUM> may include OAuth2, Rx, Nt, S6t, MB2, Ns, Ro, Gy, Rf, Ga, Tsp, T6b, T6a, ISC, and/or T7.

<FIG> illustrates another collection architecture <NUM>, in accordance with some embodiments of the presently disclosed subject matter. Collection architecture <NUM> is an example of direct interface collection, because the collection is performed via an integrated central interface <NUM>, namely an integrated SCEF which is used exclusively to collect data for the subject matter.

For example, data may be collected from data source(s) <NUM>, data source(s) <NUM> being an example of external data source(s) <NUM> (<FIG>. Collector <NUM> may be an example of collector <NUM> of data handler <NUM> (<FIG>). Collector <NUM> includes an application server (AS) <NUM>, and includes the integrated SCEF <NUM> which is dedicated to the purposes of the subject matter.

In <FIG>, data source(s) <NUM> include MME <NUM>; and interface(s) <NUM> between data source(s) <NUM> and integrated SCEF <NUM> include a T6a interface <NUM> between MME <NUM> and integrated SCEF <NUM>. An API <NUM> for non-IP data delivery (NIDD) configuration is used between integrated SCEF <NUM> and AS <NUM>. A UE <NUM> is shown using an attach procedure with MME <NUM>. UE <NUM>, for example may be a an endpoint device or gateway (e.g. destination endpoint device <NUM> or a gateway, such as a <NUM> hotspot, connected to destination endpoint device <NUM> via wireless and/or wired connection(s)). In some embodiments, data source(s) <NUM> may include other relevant entity/ies in addition to or instead of MME <NUM>, such as relevant entity/ies of a packet core and/or of a RAN, e.g. HSS, PCRF, etc. In such embodiments interface(s) <NUM> may include other interface(s), in addition to or instead of T6a, such as S6t, Rx, Nt, etc..

<FIG> illustrates yet another collection architecture <NUM>, in accordance with some embodiments of the presently disclosed subject matter. Collection architecture <NUM> is an example of indirect interface collection, where the collection is via a separate central interface, as well as being an example of direct interface collection.

In <FIG> as in <FIG>, SCEF <NUM> is used for various purposes, not necessarily all of which are related to the subject matter. For example, SCEF <NUM> may be used for communication, subscription, context, and control purposes. Collector <NUM> may be an example of collector <NUM> (<FIG>), and data sources <NUM> may be examples of external data source(s) <NUM> (<FIG>). Collector <NUM> may act as an application server to SCEF <NUM>. Data sources <NUM> may include data sources <NUM> such as an authorization server, an HSS, an RCAF, a CDF, a CGF, an SGSN, an S-CSCF, a PCRF, a BM-SC, an OCF, an OCS, an MTC-IWF, an IWK-SCEF, and/or an MME, C-SGN. Such data sources <NUM> may interface with SCEF <NUM> via interfaces <NUM> such as an OAuth2, Rx, Nt, S6t, MB2, Ns, Ro, Gy, Rf, Ga, Tsp, T6b, T6a, ISC, and/or T7. Data sources <NUM> may further include data sources <NUM> such as a session management function (SMF), user plane function (UPF), and access and mobility function (AMF) which interface directly via interface(s) <NUM> to collector <NUM> , or in other words do not interface via SCEF <NUM>. For example, MME is shown interfacing via T6A <NUM> to SCEF <NUM>, as well as directly via T6a <NUM> to collector <NUM>. Session management data from SMF and/or UPF <NUM>, and data from northbound interfaces to AMF and/or MME <NUM> may be useful to collect, e.g. when at least part of subject endpoint devices <NUM> are conventional UEs such as <NUM> devices. Also shown in <FIG> are REST APIs <NUM> to pull information from SCEF <NUM>.

Additionally or alternatively to collection architectures <NUM>, <NUM> and <NUM> discussed with reference to <FIG>, data from external data sources <NUM> (e.g. entities included in a radio access network) may be transported to data handler <NUM> by adding headers to UDP packets, e.g. in accordance with the IETF PLUS initiative.

Additionally or alternatively to collection architectures <NUM>, <NUM> and <NUM> discussed with reference to <FIG> and depending on network <NUM>, the implementation of an appropriate collection architecture for network <NUM> may include any other appropriate interfacing in addition to and/or instead of the specific types of interfacing discussed with reference to <FIG>. For example, collector <NUM> may use mobility service engine (MSE) REST APIs to interface to external data source(s) <NUM> which are wireless access points, collector <NUM> may use Cisco Prime APIs to interface to external data source(s) <NUM> which are wired routing/switches, collector <NUM> may use Meraki APIs to interface to external data source(s) <NUM> which are Meraki enterprise products, etc..

<FIG> is a flowchart of a method <NUM>, in accordance with some embodiments of the presently disclosed subject matter. Method <NUM> may be performed for network <NUM>. Method <NUM> is described with reference to destination endpoint device <NUM> and subject endpoint device <NUM> of <FIG>, but may be applied to any suitable endpoint devices <NUM>. Method <NUM> is further described with reference to the functional blocks of <FIG>, but functionality relevant to performance of method <NUM> may be implemented in any other appropriate way. It should be understood that a stage attributed to a functional block may be equivalently attributed to a device <NUM> or <NUM> which implements the functional block.

In optional stage <NUM>, an MN-CSE or ASN-CSE is identified (e.g. by data handler <NUM>) for an endpoint device such as endpoint device <NUM>. Data handler <NUM> may identify the MN-CSE or ASN-CSE by intercepting the registration of the MN-CSE or ASN-CSE to the IN-CSE. For example, if network <NUM> includes a mobile network, the MN-CSE or ASN-CSE may be included in the attaching UE (e.g. subject endpoint device <NUM> or an appropriate gateway <NUM> which implements translator <NUM>) from the RAN perspective. Stage <NUM> may be omitted, for instance, if communication in network <NUM> is not in accordance with the oneM2M standard, or if identification is not required to perform the remainder of method <NUM>.

In optional stage <NUM>, one or more resources are generated (e.g. by resource manager <NUM> of data handler <NUM>) relating to subject endpoint device <NUM>, wherein the state data of the resource(s) are to be determined by source(s) other than internal data source <NUM> (e.g. are to be determined by any of external data source(s) <NUM> and/or data handler <NUM>). For example, resource manager <NUM> may generate the resource(s) by registering the resource(s) in resource database <NUM>.

Such resource(s) may be generated in stage <NUM> in addition to at least one resource generated concurrently, beforehand, and/or afterwards whose state data is to be determined by internal data source <NUM>. The generation of resource(s) whose state data is to be determined by internal data source <NUM> may be performed by the MN-CSE/ASN-CSE identified in stage <NUM>. The latter generation may include registering resource(s) in resource database <NUM>, and/or registering resource(s) in a database implemented at least partly by MN-CSE/ASN-CSE (e.g. translator database <NUM>). Optionally, other resource(s) relating to network <NUM> may additionally or alternatively be generated.

Resource generation may be supported by the "create" operation if the OneM2M model is being used. Stage <NUM> may be repeated for additional resources relating to subject endpoint device <NUM> as necessary (e.g. if necessary based on a result of an analysis by analyzer <NUM> - see stage <NUM> below) or may be performed for all resources all at once. Generation of the resource(s) may include specification of relationship(s) among the generated resource(s) and/or between the generated resource(s) and previously generated resource(s).

Stage <NUM> may be omitted if the oneM2M model is not being used for communication in network <NUM>, or if stage <NUM> is not required to perform the remainder of method <NUM>.

In stage <NUM>, data is collected (e.g. by collector <NUM> of data handler <NUM>) from source(s) other than internal data source <NUM> (e.g. from external data source(s) <NUM> and/or from analyzer <NUM> of data handler <NUM>). For example, the collection in stage <NUM> from any of external data source(s) <NUM> may utilize any of collection architectures <NUM>, <NUM> or <NUM> discussed with reference to <FIG>, <FIG> or <FIG>, and/or any other collection architecture discussed herein.

In embodiments where resource(s) are generated in stage <NUM>, the collected data may include state data for one or more of the resource(s) generated in stage <NUM>. The collected state data may be stored for the respective resource(s) in resource database <NUM>, e.g. by resource manager <NUM> of data handler <NUM>.

In optional stage <NUM>, the collected data may be stored (e.g. by collector <NUM> of data handler <NUM>) in handler database <NUM>. Stage <NUM> may be omitted, for instance, if historical collected data is not used (e.g. by analyzer <NUM> or by communication generator <NUM> of data handler <NUM>). The collected data may be anonymized prior to storage.

Depending on the embodiment, stage <NUM> and optionally stage <NUM> may be performed one or more times in method <NUM>. For example, stage <NUM> may be performed periodically, or upon any appropriate event. Appropriate event(s) may include, for instance, changed or additional data becoming available due to being determined (e.g. when changed state data for a resource, or data for an additional resource, is determined). Appropriate event(s) may additionally or alternatively include, for instance, stage <NUM> occurring meaning that an iteration of stage <NUM> and optionally stage <NUM> may follow an iteration of stage <NUM>. Appropriate event(s) may additionally or alternatively include, for instance, a proposal that additional data that was not previously collected is to be collected based on a result of an analysis of analyzer <NUM> - see stage <NUM> below; etc. If the collected data includes current and/or predicted state data then each time new current or predicted state data for the same resource is collected, the new current or predicted state data may be used to update resource database <NUM> for the respective resource.

It is noted that for the data that is collected, determination of the data by external data source(s) <NUM> and/or by data handler <NUM> may occur in response to a request from collector <NUM>, and/or independently of any request by collector <NUM>. If occurring independently, the determination may occur periodically and/or upon the occurrence of one or more events that are independent of any request by collector <NUM>.

In stage <NUM>, a request communication originating from the data consumer <NUM> that is not destined for data handler <NUM> (e.g. that is destined for translator <NUM> or internal data source <NUM>), a notification communication that is destined for data consumer <NUM>, or a response communication that is destined for data consumer <NUM> is intercepted (e.g. by interceptor/sender <NUM> of data handler <NUM>). The request communication may request data relating to subject endpoint device <NUM> (e.g. that was or will be determined by internal data source <NUM>, and/or by other source(s) such as external data source(s) <NUM> and/or data handler <NUM>). The notification communication may be indicative of data (e.g. state data for at least one resource) determined by internal data source <NUM>. The response communication may be in response to an earlier intercepted request communication. The response communication may be indicative of data (e.g. state data for at least one resource) determined by internal data source <NUM>.

Interception in stage <NUM> may be performed for protocols supported by OneM2M operations such as HTTP, COAP, MQTT, etc.; and/or may be performed for other protocol(s). For example, in accordance with the oneM2M model, the operation "retrieve" may be representative of a request communication, and the operation "notify" may be representative of a notification communication. In other examples, the request communication may be a JSON request, an XML request, etc. The interception of a communication may include proxying the request, response, or notification communication between hub <NUM> (e.g. in the oneM2M model, more specifically between IN-CSE that is at least partly implementing hub <NUM>) and data handler <NUM>. When the interception includes proxying, interceptor/sender <NUM> may be adapted to act as a proxy server.

In stage <NUM> it is determined (e.g. by interceptor/sender <NUM> of data handler <NUM>) if the intercepted communication is to proceed to the destination thereof, such as to data consumer <NUM>, internal source <NUM>, or translator <NUM> (e.g. in the one M2M model more specifically to IN-AE, or to MN/ASN-CSE). Depending on the embodiment, an intercepted communication may proceed under various circumstances. For example, it may be determined that intercepted request communications proceed, but intercepted response communications and intercepted notification communications do not proceed. As another example, it may be determined that intercepted communications (whether they be request, response or notification communications) proceed (and in such an example, stage <NUM> may be omitted). As another example, certain selectively determined request, response and/or notification communications may proceed but others may not proceed. Under selective determination, for instance, a request communication may not proceed if the requested data is determinable by source(s) other than internal source <NUM>, whereas a response communication may not proceed if the request communication, which triggered the response communication, requested data that is partly determinable by source(s) other than internal source <NUM>. Additionally or alternatively under selective determination, a notification communication, or a response communication whose triggering request communication did not request data determinable by source(s) other than internal source <NUM>), may not proceed if additional and/or changed data relating to subject endpoint device <NUM> has been collected by collector <NUM>. The changed data may differ from data indicated in an earlier iteration of stage <NUM> (see below description of stage <NUM>), if any; and/or the additional data may be in addition to data indicated in an earlier iteration of stage <NUM>, if any. If there was no earlier iteration of stage <NUM> with respect to data consumer <NUM> and internal source <NUM>, then any collected data may be considered as additional data. Continuing with describing the latter instance of selective determination, for a oneM2M implementation, the changed data may be updated current/predicted state data for one or more previously generated resources, and/or the additional data may be current/predicted state data for one or more newly generated resources.

In stage <NUM>, if it was determined that the intercepted communication should proceed, then in stage <NUM> the intercepted communication is sent (e.g. by interceptor/sender <NUM>) to the destination (e.g. data consumer <NUM>, internal data source <NUM>, or translator <NUM>). Stages <NUM> and <NUM> may then be omitted.

If instead in stage <NUM>, it is determined that the intercepted communication should not proceed to the destination, then method <NUM> omits stage <NUM> and continues to stage <NUM>. Additionally or alternatively, in some embodiments, any intercepted communication may proceed to the destination in stage <NUM>, and in addition stage <NUM> may be performed under certain circumstances. For example, stage <NUM> may be performed in addition, after a request communication is intercepted that requests data that is at least partly determinable by source(s) other than internal data source; and/or after a request communication is intercepted provided that changed and/or additional data has been collected since the last iteration of stage <NUM>. In such embodiments, stage <NUM> may be omitted, or may be modified to determine whether or not stage <NUM> should also be performed.

In stage <NUM>, a communication is generated (e.g. by communication generator <NUM> of data handler <NUM>). The communication is destined for data consumer <NUM> (e.g. in the one M2M model, more specifically for IN-AE). It is noted that if the intercepted communication was a response or notification communication, then the generated response or notification communication may be destined for the destination for which the intercepted communication was destined (e.g. data consumer <NUM>). If the intercepted communication was a request communication, then the generated response communication may be destined for the sender of the request communication (e.g. data consumer <NUM>).

The generated communication may be indicative of data relating to subject endpoint device <NUM> that was not determined by internal data source <NUM>, but determined by other source(s) such as external data source(s) <NUM> and/or data handler <NUM>.

The generation of the generated communication includes enriching the intercepted communication (e.g. notification communication or response communication from subject endpoint device <NUM>) to generate the generated communication. The generated communication may be indicative of both data determined by internal data source <NUM>, and also of data determined by other source(s) such as external data source(s) <NUM> and/or data handler <NUM>.

The data relating to subject endpoint <NUM> that the generated communication is indicative of may not necessarily exclusively relate to subject endpoint <NUM>, and may in some cases also relate to other subject endpoint(s) <NUM>.

The generated communication may be indicative of data, for instance, by including the data and/or by including URI(s) to retrieve the data. For example the URI(s) may be URI(s) corresponding to the data in any of resource database <NUM>, handler database <NUM> and/or translator database <NUM>. The data and/or the URI(s) (and/or any other indication of the data) may be included, for instance, in a payload and/or in header(s) of the generated communication. Continuing with describing such an instance, data, URI(s) and/or any other indication of the data may be included in the payload of a response communication to a "retrieve" request, in a payload of a "notify" operation communication, in a payload of a JSON or XML response communication, and/or in an extra header of a response communication packet, etc. If the oneM2M model is applicable, the data indicated in the generated communication may include state data, and the generated communication may be indicative of state data (whether determined by internal data source <NUM>, and/or determined by other source(s) such as data handler <NUM> and/or external data source(s) <NUM>, etc. ), by including the state data and/or by including URI(s) to the state data that is in one or more databases such as resource database <NUM> and/or translator database <NUM>.

In stage <NUM>, the generated communication is sent (e.g. by interceptor/sender <NUM> of data handler <NUM>). The sent response or notification communication may subsequently be received by data consumer <NUM>.

In some embodiments, the sending of the generated communication may include proxying the generated communication between hub <NUM> (e.g. in the oneM2M model, more specifically between IN-CSE that is at least partly implementing hub <NUM>) and data handler <NUM>. When the sending includes proxying, interceptor/sender <NUM> may be adapted to act as a proxy server.

Any of stages <NUM> to <NUM> may be repeated for additional communications sent by or destined for data consumer <NUM>, which relate to subject endpoint device <NUM>.

Any of stages <NUM> to <NUM> may be repeated for other subject endpoint device(s) <NUM> regarding which data is consumed by data consumer <NUM>, e.g. for administration purposes.

In optional stage <NUM>, collected data (e.g. stored in resource database <NUM> and/or in handler database <NUM>) may be analyzed (e.g. by analyzer <NUM> of data handler <NUM>). For example the analyzed data may include data determined by internal data source <NUM> relating to subject endpoint device <NUM>; data determined by other internal data source(s) of other subject endpoint device(s) <NUM> relating to the other subject endpoint device(s) <NUM>; data determined by other source(s) that are not internal data sources (such as external data source(s) <NUM> and/or data handler <NUM>), relating to subject endpoint device <NUM> and/or other subject other endpoint device(s) <NUM>; etc. The analyzed data may include the most recent collected data and/or historical collected data. A result of the analysis may be stored in handler database <NUM>. Additionally or alternatively, the result may be used for future action(s) such as performance of any of stage(s) <NUM> to <NUM> described below. Additionally or alternatively, the result may be communicated, for instance to data consumer <NUM>, e.g. in communication(s) generated by communication generator <NUM> in stage <NUM> or in other communication(s) independent of any interception of communications. The analysis performed in stage <NUM> may include any suitable analysis. For example, the analysis may include statistics regarding the usage of certain endpoint devices in given areas, analytics of certain endpoint devices' mobility from RAN antenna sites to others, etc..

In optional stage <NUM>, based on the result of the analysis, analyzer <NUM> may predict future data relating to subject endpoint device <NUM> and/or other subject endpoint device(s) <NUM>. For instance, assuming that the oneM2M model is applied, if subject endpoint device <NUM> is a pollution sensor, the pollution sensor may determine pollution current state data for a resource of pollution. The historical collected pollution state data that was collected over time and current pollution state data for the various pollution sensors (e.g. data stored in handler database <NUM>) may be used to train analyzer <NUM> so that analyzer <NUM> may predict the future pollution state data of a particular pollution sensor (e.g. subject endpoint device <NUM>) during a march in the city. The training may result in an appropriate machine learning model which may then be applied to predict the future pollution state. In another instance, if subject endpoint device <NUM> is a trash can, the historical and/or current data of percentage full on various days of the week and/or times of day, may be used to train analyzer <NUM> to predict when the trash should be emptied. The future data (e.g. future pollution state data, future trash collection day/time) determined by analyzer <NUM> may then be collected by collector <NUM>.

The future data (e.g. future pollution state data, future trash collection time/day, etc.) may be indicated to data consumer <NUM>. For example, the data indicated in communication(s) generated by communication generator <NUM> in stage <NUM> may include future data determined by analyzer <NUM>. Additionally or alternatively, future data determined by analyzer <NUM> may be indicated in a communication independent of any interception of communications.

In optional stage <NUM>, based on the result of the analysis, it is determined (e.g. by analyzer <NUM>) whether additional resources should be generated, and/or particular resources be deleted. If it is determined that additional resource(s) are to be generated, stage <NUM> may be repeated for subject endpoint device <NUM> and/or other subject endpoint device(s) <NUM>. If it is determined that particular resource(s) are to be deleted, then resource manager <NUM> may delete one or more resources for subject endpoint device <NUM> and/or other subject endpoint device(s) <NUM>. Stage <NUM> may be omitted, if analysis is not performed.

In optional stage <NUM>, based on the analysis, it is determined (e.g. by analyzer <NUM>) whether additional data relating to subject endpoint device <NUM> and/or other subject endpoint device(s) <NUM> is be collected; and/or whether certain data relating to subject endpoint device <NUM> and/or other subject endpoint device(s) <NUM> that is being collected is to stop being collected. If it is determined that additional data is to be collected, then collector <NUM> may collect such additional data in a repetition of stage <NUM>. If it is determined that certain data is to stop being collected, then collector <NUM> may not collect such data in a repetition of stage <NUM>. Stage <NUM> may be omitted, if analysis is not performed.

For example, assuming the oneM2M model, the current state data of the location resource(s) for more than one endpoint device (e.g. subject endpoint device <NUM> and other subject endpoint device(s) <NUM>) may have been collected in stage <NUM> and may have been analyzed in stage <NUM> (e.g. by analyzer <NUM> of data handler <NUM>). The result of the analysis may cause analyzer <NUM> to propose the generation (e.g. by resource manager <NUM> of data handler <NUM>) of an area network resource and/or a quantity resource for the quantity of subject endpoint devices <NUM> in the area. Such resource(s) may be considered to relate to subject endpoint device <NUM>, even though also relating to other subject endpoint devices <NUM>. Referring to the instance of subject endpoint device <NUM> being a pollution sensor discussed with reference to stage <NUM>, the area network resource and quantity resource may relate to the pollution sensor and to other pollution sensors in the vicinity of the pollution sensor (e.g. connecting to the same cell, such as the same <NUM> cell, in a mobile network included in network <NUM>). Such resource(s) may be generated (e.g. by resource manager <NUM>) in a repetition of stage <NUM>.

Continuing with describing the latter example, the result of the analysis may additionally or alternatively cause analyzer <NUM> to propose collecting current state data for other resource(s) (e.g. for the area network resource and/or quantity resource). Analyzer <NUM> may consequently determine certain current state data (e.g. current quantity for the quantity resource), for instance, from individual pollution sensor data (e.g. stored in resource database <NUM>, stored in handler database <NUM>, or not yet stored). Additionally or alternatively, certain current state data (e.g. identifiers of pollution sensors in the area for the area network resource) may have already been determined by analyzer <NUM> during the analysis of stage <NUM>. Analyzer <NUM>, for instance, may determine the current quantity and/or identifiers based on the location resource current state data of various pollution sensors (e.g. stored in resource database <NUM> or handler database <NUM>, or not yet stored). The current state data (e.g. identifiers and/or current quantity) which analyzer <NUM> proposes to collect may be collected by collector <NUM>, in a repetition of stage <NUM>.

Stages <NUM> to <NUM>, if performed, may be performed periodically or upon the occurrence of one or more events, such as data consumer <NUM> requesting that an analysis be performed.

In some embodiments, method <NUM> may include more, fewer, and/or different stages than illustrated in <FIG>. In some embodiments, the order of stages may differ from the order illustrated in <FIG>. In some embodiments, stages that are shown in <FIG> as being performed sequentially may be performed in parallel, and/or stages that are shown as being performed in parallel may be performed sequentially. In some embodiments, the iteration of various stages may differ from the iteration illustrated in <FIG>.

Method <NUM> may be repeated with respect to one or more other data consumers <NUM>, if any, in network <NUM>.

Dataflow diagrams which are in accordance with the oneM2M standard are now presented to further illustrate the subject matter.

<FIG> is a diagram of a dataflow <NUM>, in accordance with some embodiments of the presently disclosed subject matter.

Dataflow diagram <NUM> illustrates an example in accordance with the oneM2M standard, including an IN-AE <NUM>, an IN-CSE <NUM>, a data handler <NUM>, and an MN/ASN-CSE <NUM>. Data handler <NUM> and IN-CSE <NUM> may be, for instance, in a packet core of a mobile network. Data handler <NUM> may be an example of data handler <NUM> of <FIG>.

In stage <NUM>, MN/ASN-CSE <NUM> generates a "thing" resource, namely an ASN-node resource for subject endpoint device <NUM> of <FIG>. The ASN-node resource is generated by registering the resource in an IN-CSEbase <NUM> in IN-CSE <NUM>. IN-CSEbase <NUM> may be an example of resource database <NUM> of <FIG>. The ASN-node resource may be registered in IN-CSEbase <NUM>, as being related to an ASN-remoteCSE resource, which is assumed to have already been registered.

In stage <NUM>, MN/ASN-CSE <NUM> generates one or more "thing property" resources relating to the ASN-node resource, such as resources for device information, for battery information and for firmware information. Such resources are generated by registering the resources in IN-CSEbase <NUM>.

In stage <NUM>, data handler <NUM> generates one or more "thing property" resources relating to the ASN-node resource, such as a location resource. The location resource is generated by registering the resource in IN-CSEbase <NUM>. Stage <NUM> may be an example of stage <NUM> of <FIG>.

In the oneM2M model, the resources mentioned in stages <NUM>, <NUM> and <NUM> may be registered in IN-CSEbase <NUM> by using one or more "create" operations. The resources may all be related as shown in IN-CSE <NUM>.

In stage <NUM>, IN-AE <NUM> sends a request destined for MN/ASN-CSE <NUM>. The request asks for the current state data for the battery resource. The request is received by IN-CSE <NUM>. In oneM2M, the retrieve operation may be used for the request.

In stage <NUM>, data handler <NUM> intercepts the request, including proxying the request. The interception in stage <NUM> may be an example of stage <NUM> of <FIG>.

In stage <NUM>, data handler <NUM> collects the current state data for the location resource from the <NUM>, <NUM>, <NUM> or <NUM> RAN which is adapted to determine the value, e.g. based on triangulation. The location current state data may include, for instance, the longitude and latitude. Stage <NUM> may be an example of stage <NUM> of method <NUM>, where the location current state data is determined by external data source(s) <NUM> (<FIG>) that are RAN entity/ies.

In stage <NUM>, the request is forwarded by data handler <NUM> to MN/ASN-CSE <NUM>. The forwarding of the request results in a pulling of the battery information determined by the ASN (i.e. the ASN of subject endpoint device <NUM>). Depending on the embodiment, the ASN may have determined the battery information independently of the request or in response to the request. The forwarding in stage <NUM> may be an example of stage <NUM> of method <NUM>.

In stage <NUM>, the response is sent by MN/ASN-CSE <NUM> to data handler <NUM>. The response includes the battery information determined by the ASN. The response is intercepted by data handler <NUM>. The interception of the response in stage <NUM> may be an example of stage <NUM> of method <NUM>.

In stage <NUM>, the response from MSN/ASN-CSE <NUM> is proxied and enriched by data handler <NUM>. The response sent by data handler <NUM> that is destined for IN-AE <NUM> includes the location current state data determined by the RAN, as well as the battery current state data (e.g. <NUM>% full battery level) determined by the ASN. The enrichment in stage <NUM> may be an example of stage <NUM> of method <NUM>, and the proxying of stage <NUM> may be an example of stage <NUM> of method <NUM>.

In stage <NUM>, IN-CSE <NUM> forwards the response from data handler <NUM> to IN-AE <NUM>. Dataflow <NUM> then ends.

In stage <NUM>, MN/ASN-CSE <NUM> generates a "thing" resource, namely an ASN-node resource for subject endpoint device <NUM> (<FIG>). The ASN-node resource is generated by registering the resource in an IN-CSEbase <NUM> in IN-CSE <NUM>. IN-CSEbase <NUM> may be an example of resource database <NUM> (<FIG>). The ASN-node resource may be registered in IN-CSEbase <NUM>, as being related to an ASN-remoteCSE resource, which is assumed to have been previously registered.

In stage <NUM>, IN-AE sends a request destined for MN/ASN-CSE <NUM>. The request asks for the current state data for the location resource. The request is received by IN-CSE <NUM>. In oneM2M, the retrieve operation may be used for the request.

The request is not forwarded to MN/ASN-CSE <NUM>, since no current state data is required to be determined by the ASN (i.e. by the ASN of subject endpoint device <NUM>), in order to respond.

In stage <NUM>, the response to the request is generated and proxied by data handler <NUM>. The response sent by data handler <NUM> that is destined for IN-AE <NUM> includes the location current state data determined by the RAN. The generation in stage <NUM> may be an example of stage <NUM> of method <NUM>, and the proxying of stage <NUM> may be an example of stage <NUM> of method <NUM>.

In stage <NUM>, MN/ASN-CSE <NUM> generates a "thing" resource, namely an ASN-node resource for subject endpoint device <NUM> of <FIG>. The resource is generated by registering the resource in an IN-CSEbase <NUM> in IN-CSE <NUM>. IN-CSEbase <NUM> may be an example of resource database <NUM> of <FIG>. The ASN-node resource may be registered in IN-CSEbase <NUM>, as being related to an ASN-remoteCSE, which is assumed to have been previously registered.

In stage <NUM>, MN/ASNN-CSE <NUM> generates one or more "thing property" resources relating to the ASN-node resource, such as resources for device information, for battery information and for firmware information. Such resources are generated by registering the resource in IN-CSEbase <NUM>.

In stage <NUM>, data handler <NUM> generates one or more "thing property" resources relating to the ASN-node resource such as a location resource. The location resource is generated by registering the resource in IN-CSEbase <NUM>. Stage <NUM> may be an example of stage <NUM> of <FIG>.

In oneM2M, the resources mentioned in stages <NUM>, <NUM> and <NUM> may be registered in IN-CSEbase <NUM> by using one or more "create" operations. The resources may all be related as shown in IN-CSE <NUM>.

In stage <NUM>, the ASN (i.e. the ASN of subject endpoint device <NUM>) determines that the battery is critically low. Accordingly the ASN generates a notification that the battery is critically low, thereby pushing the battery current state data for the battery information resource. The notification is destined for IN-AE <NUM>. MN/ASN-CSE <NUM> sends a notification that includes the battery current state data, and the notification is intercepted by data handler <NUM>. The interception of the notification in stage <NUM> may be an example of stage <NUM> of <FIG>. In the oneM2M model, the notify operation may be used for such a notification.

In stage <NUM>, data handler <NUM> collects the current state data for the location resource from the <NUM>, <NUM>, <NUM> or <NUM> RAN which is adapted to determine the value, e.g. based on triangulation. Stage <NUM> may be an example of stage <NUM> of method <NUM>, where the location current state data is determined by external data source(s) <NUM> (<FIG>) that are RAN entity/ies.

In stage <NUM>, the notification is proxied and enriched by data handler <NUM>. The notification sent by data handler <NUM> which is destined for IN-AE <NUM> includes the location current state data determined by the RAN as well as the current state data (e.g. critically low) determined by the ASN. The enrichment in stage <NUM> may be an example of stage <NUM> of method <NUM>, and the proxying may be an example of stage <NUM> of method <NUM>.

In stage <NUM>, IN-CSE <NUM> forwards the notification from data handler <NUM> to IN-AE <NUM>. Dataflow <NUM> then ends.

Dataflow diagram <NUM> illustrates an example in accordance with the oneM2M standard, including an IN-AE <NUM>, an IN-CSE <NUM>, a data handler <NUM>, and an MN/ASN-CSE <NUM>. Data handler <NUM> and IN-CSE <NUM> may be, for instance, in a packet core of a mobile network. Data handler <NUM> may be an example of data handler <NUM> of <FIG>.

In stage <NUM>, MN-CSE <NUM> generates a "thing" resource, namely an ASN-node resource for endpoint device <NUM> of <FIG>. The resource is generated by registering the resource in an IN-CSEbase <NUM> in IN-CSE <NUM>. IN-CSEbase <NUM> may be an example of resource database <NUM> of <FIG>. The ASN-node resource may be registered in an IN-CSEbase <NUM>, as being related to an ASN-remoteCSE resource, which is assumed to have been previously registered.

In stage <NUM>, MSN-CSE <NUM> generates one or more "thing property" resources relating to the ASN-node resource, such as resources for device information, for battery information and for firmware information. Such resources are generated by registering the resource in IN-CSEbase <NUM>.

In stage <NUM>, data handler <NUM> compiles a list of endpoint devices <NUM> at the same location, using RAN information (e.g. the compiled list may be a result of analyzing collected RAN location current state data). Stage <NUM> may be an example of stage <NUM>, <NUM> and/or <NUM> of <FIG>.

In stages <NUM> and <NUM>, data handler <NUM> generates one or more resources relating to the ASN-node resource, based on the compiled list of stage <NUM>. For example, an area network resource may be generated in stage <NUM> that the ASN-node resource "is part of" (and that other ASN-node resources for other endpoint devices <NUM> at the location of subject endpoint device <NUM> may be part of). In stage <NUM>, interworked device property resources may be generated, including, for example, specification of the relationships between various ASN-node resources, the area network resource and the interworked device property resources. The generation of resources in stage <NUM> and <NUM> may be an example of stages <NUM> and <NUM> of method <NUM>.

Subsequent to stage <NUM>, IN-AE <NUM> may request, via data handler <NUM>, a list of endpoint devices <NUM> located in the same area. Dataflow <NUM> then ends.

Data flows <NUM> to <NUM> may be modified to rely on payload in JSON responses, payload in XML responses, headers in response communication packets, etc., for conveying data regarding endpoint devices <NUM> that was not necessarily determined by the endpoint devices <NUM>. For example, such modification may be applied in addition to or instead of the oneM2M model discussed with reference to <FIG>.

Data flows <NUM> to <NUM> are not meant to be comprehensive, and other data flows may be used to illustrate the flow of data in network <NUM>.

Some embodiments of the subject matter may provide any of the following advantages.

First, data relating to a subject endpoint device may be provided to a destination endpoint device without the data being requested by the destination endpoint device.

Second, data relating to a subject endpoint device, which was not requested, may enrich other data relating to the subject endpoint device that was requested. For example, responses and/or notifications to the destination endpoint device may be indicative of both the data and the other data.

Third, in a network that includes a subject endpoint device, networking infrastructure, and a destination endpoint device, data relating to a subject endpoint device that is determined by networking infrastructure device(s) may be received by a destination endpoint device without the destination endpoint device using any APIs (e.g. rest APIs) to request the data. In addition, an SCEF may be optional in such a network.

Fourth, data determined by networking infrastructure device(s) regarding a subject endpoint device may be indicated in the payload of a communication, as if the data were determined by the endpoint device.

Fifth, the oneM2M standard and associated entities thereof (e.g. IN-AE, IN-CSE, MN/ASN-CSE etc.) may be used to support communications.

Sixth, if the network includes a <NUM> narrowband IoT network, a goal may be to achieve an extended coverage of <NUM> dB compared to legacy General Packet Radio Service (GPRS) devices, corresponding to achieving a target maximum coupling loss of <NUM> dB. At such a maximum coupling loss, a data rate of at least <NUM> bps may be supported at the application layer for both the uplink and downlink. At such a data transfer rate, the design of subject endpoint devices may be cautious regarding the payload and may exclude certain data that may be useful to destination endpoint devices. The subject matter allows for such excluded data to be provided to destination endpoint devices even if excluded by subject endpoint device design.

Seventh, regardless of the type of network, cheaper and/or simpler subject endpoint devices may be designed and deployed in the network, because at least some data regarding the subject endpoint devices may be determined by networking infrastructure device(s). For example, such subject endpoint devices may not be required to include the extra components to determine data that may be determined by networking infrastructure device(s).

Eighth, the subject matter may enable data determined by networking infrastructure device(s) that is not currently exploited, or inefficiently exploited, to be exploited by providing communications indicative of the data to destination endpoint devices, by analyzing the data, etc..

Ninth, if a service provider operates networking infrastructure device(s) which generate communications indicative of data determined by networking infrastructure device(s) regarding subject endpoint device(s), the service provider may be able to provide a solution to operator(s) of the subject endpoint device(s), such as enterprise(s), which allows the operator(s) to have access to more data regarding the subject endpoint devices, without additional investment in, or upgrading of the subject endpoint devices.

Other advantages may be apparent from the description herein.

It will be appreciated that the subject matter contemplates, for example, a computer program product comprising a computer readable medium having computer readable program code embodied therein for executing one or more methods disclosed herein; and/or for executing one or more parts of method(s) disclosed herein, e.g. with reference to any of <FIG>. Further contemplated, for example, is computer readable program code for executing method(s) disclosed herein; and/or for executing part(s) of method(s) disclosed herein. Further contemplated, for example, is a computer readable medium having computer readable program code embodied therein for executing method(s) disclosed herein; and/or for executing part(s) of method(s) disclosed herein.

In the above description of example embodiments, numerous specific details are set forth in order to provide a thorough understanding of the subject matter. However, it will be appreciated by those skilled in the art that some examples of the subject matter may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the subject matter.

It will also be appreciated that various features of the subject matter which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the subject matter which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

Claim 1:
A method performed by a first device (<NUM>), comprising:
intercepting (<NUM>) a first communication that is destined for a second device (<NUM>) or that is originating from the second device but is not destined for the first device, the first communication requesting data relating to a third device (<NUM>) or indicative of data determined by and relating to the third device;
subsequent to said intercepting, generating (<NUM>) a second communication destined for the second device, wherein the second communication is indicative of data relating to the third device that was determined by at least one of the first device or one or more fourth devices (<NUM>); and
sending (<NUM>) the second communication,
wherein said generating includes enriching the first communication to generate the second communication, the second communication being indicative of both the data determined by and relating to the third device and the data relating to the third device that was determined by the at least one of the first device or the one or more fourth devices,
wherein a communication is indicative of specific data by including the specific data or by including an identifier for retrieving the specific data.