Methods and Apparatus for Internet of Things Resource Management

Abstract

Methods, Internet of Things (IoT) devices and network nodes for network resource management, the method in the IoT comprising: initiating a device shutdown procedure; and triggering the sending of a device shutdown message to a network node.

Claims

1-39. (canceled)

40. An Internet of Things device configured to assist network resource allocation, the Internet of Things device comprising: processing circuitry; memory containing instructions executable by the processing circuitry whereby the Internet of Things device is operative to: initiate a device shutdown procedure; and trigger sending of a device shutdown message to a network node.

41. The Internet of Things device of claim 40, wherein the shutdown message comprises a device identifier.

42. The Internet of Things device of claim 40, wherein the shutdown message comprises a task identifier.

43. The Internet of Things device of claim 40, wherein the shutdown message comprises a task count.

44. The Internet of Things device of claim 40, wherein the instructions are such that the Internet of Things device is operative to initiate the device shutdown procedure when: a remaining device battery power falls below a threshold level, a mains power supply to the device undergoes a scheduled or unscheduled period of inactivity, or a shutdown is instructed.

45. The Internet of Things device of claim 40, further configured to shut down.

46. The Internet of Things device of claim 45: wherein the instructions are such that the Internet of Things device is operative to restart following the device shutdown; wherein, if the device shutdown message is not sent prior to the shutdown, the device is configured to send the device shutdown message following the shutdown.

47. A network, comprising: a network node; an Internet of Things device configured to assist network resource allocation, the Internet of Things device comprising: processing circuitry; memory containing instructions executable by the processing circuitry whereby the Internet of Things device is operative to: initiate a device shutdown procedure; and trigger sending of a device shutdown message to the network node; wherein the network node is configured to receive the device shutdown message from the Internet of Things device.

48. The network of claim 47, wherein the network node is configured to generate a usage report.

49. The network of claim 48, wherein the usage report specifies a total network data usage of the Internet of Things device.

50. The network of claim 48, wherein the usage report specifies a total number of tasks performed by the Internet of Things device.

51. The network of claim 50, wherein the network node is further configured to multiply the total number of tasks performed by the Internet of Things device by a multiplication factor.

52. The network of claim 51: wherein the multiplication factor is an average data usage per instance of network access; and wherein the network node is configured to obtain an estimated total network data usage.

53. The network of claim 48, wherein the usage report categorizes instances of network access according to a task which initiated the network access.

54. The network of claim 48, wherein the network node is configured to receive plural device shutdown messages from plural Internet of Things devices, and to generate the usage report containing consolidated information from the plural device shutdown messages.

55. The network of claim 48, wherein the network node is configured to reallocate network resources.

56. The network of claim 55, wherein the reallocation of network resources comprises allocating network capacity to further devices.

57. The network of claim 55, wherein the allocation of network resources comprises reducing the total amount of network capacity provided.

58. The network of claim 47, wherein the network node comprises a receiver configured to receive the device shutdown message directly from the Internet of Things device.

59. An Internet of things device configured to assist network resource allocation, the Internet of Things device comprising: an initiator configured to initiate a device shutdown procedure; and a transmitter controller configured to trigger the sending of a device shutdown message to a network node.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0019] For a better understanding of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

[0020] FIG. 1 is a flowchart showing an example method performed by an IoT device;

[0021] FIG. 2 is a flowchart showing an example method performed by a network node;

[0022] FIG. 3A is a schematic diagram of an example of an IoT device;

[0023] FIG. 3B is a schematic diagram of a further example of an IoT device;

[0024] FIG. 4A is a schematic diagram of an example of a network node;

[0025] FIG. 4B is a schematic diagram of a further example of a network node;

[0026] FIG. 5 is a schematic diagram of a wireless communication system according to an aspect of an embodiment;

[0027] FIG. 6 is a signalling diagram for an initial configuration of an IoT device by a network node according to an aspect of an embodiment;

[0028] FIG. 7 is a signalling diagram for processes performed by an IoT device, network node and partner server, subsequent to the initial configuration of the IoT device, in an aspect of an embodiment.

DETAILED DESCRIPTION

[0029] The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as to not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers that are specially adapted to carry out the processing disclosed herein, based on the execution of such programs. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0030] Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

[0031] In terms of computer implementation, a computer is generally understood to comprise one or more processors, one or more processing modules or one or more controllers, and the terms computer, processor, processing module and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

[0032] In an aspect of an embodiment, an IoT device may be configured to initiate a device shutdown procedure. The device shutdown procedure may be initiated based on a device shutdown trigger, as shown in FIG. 1 (specifically in step S101). The IoT device may be, for example, the IoT device of either of FIG. 3A and FIG. 3B. The device shutdown procedure may be initiated by the processor 31 of the IoT device 30A shown in FIG. 3A, executing instructions stored in the memory 32, or may be initiated by the initiator 34 of the IoT device 30B shown in FIG. 3B.

[0033] The device shutdown trigger may take various forms; for a battery powered device the shutdown procedure may be initiated when the remaining device battery power falls below a predetermined threshold. This threshold may be set such that the device has sufficient power to complete a shutdown procedure (as discussed below) before running out of power, to avoid a situation in which the device runs out of battery power before completing the shutdown procedure. Where a remaining battery power threshold is used, this threshold may also or additionally be set based on other considerations, for example, the threshold may be set so as to ensure enough power would remain after the shutdown for the device to complete a restart procedure. The threshold may also be set based on additional or other considerations.

[0034] An IoT device which uses a mains power supply (or another external power supply, such as a generator) may be configured to initiate shutdown when the power supply undergoes a scheduled or unscheduled period of inactivity, that is, where the power source ceases to generate power for the IoT device for a period of time. This may be a scheduled period of inactivity; in some countries there are “rolling blackouts” which are scheduled periods during which the mains power supply to an area of the country is deactivated. The period of inactivity may also be unscheduled; an IoT device may initiate a shutdown procedure if it detects or is informed of a failure in an external power supply, and may further conduct the shutdown procedure utilising power reserves from a limited internal battery reserve. A power threshold may be monitored by the processor 31 of the IoT device 30A shown in FIG. 3A, executing instructions stored in the memory 32, or may be monitored by the power monitor 36 of the IoT device 30B shown in FIG. 3B.

[0035] The device shutdown trigger may also be an instruction received from an external source, where the instruction may be sent over the network and/or may be input directly into the IoT device using, for example, a key. The exact means by which the instruction is received by the IoT device would be dependent on the specific configuration of the device. The device shutdown trigger may be received by the processor 31 of the IoT device 30A shown in FIG. 3A via the interfaces 33, executing instructions stored in the memory 32, or may be received by the receiver 37 of the IoT device 30B shown in FIG. 3B.

[0036] In the aspect of an embodiment illustrated by FIG. 1, the device shutdown procedure may be initiated following the device shutdown trigger, as shown in step S102. The device shutdown procedure may encompass various processes depending upon the exact nature of the device; where the IoT device is a sensor the sensor may store one or more readings to an internal memory, where the IoT device is a domestic washing machine the IoT device may initiate a process to drain water from the drum. The process included in the device shutdown procedure are dependent upon the nature and function of the IoT device.

[0037] In an aspect of an embodiment, the device shutdown procedure comprises triggering the sending of a device shutdown message to a network node, as shown in step S103 of FIG. 1. The device shutdown message may be sent by the IoT device itself using suitable transmitting resources. Alternatively, the IoT device may trigger the sending of the device shutdown message, but the message may be sent by another entity, such as another device. The device shutdown message may be triggered by the processor 31 of the IoT device 30A shown in FIG. 3A using the interfaces 33 and executing instructions stored in the memory 32, or may be triggered by the transmitter controller 35 of the IoT device 30B shown in FIG. 3B.

[0038] The exact composition of the device shutdown message may vary depending upon the specific configuration of the system. Typically, the device shutdown message would include an identifier of the IoT device that triggered the message, however this is not always the case. In certain situations, for example, wherein there is a single IoT device connected to a network node, or wherein the network node does not differentiate between a number of IoT devices, the device shutdown message may not include an identifier for the IoT device. Where the IoT device may be configured to execute a number of different tasks or applications, the device shutdown message may additionally or alternatively include information on the tasks or applications, such as one or more application (or task) identifiers. The nature of the tasks or applications executed by an IoT device is determined by the specific nature of the IoT device, and may include the sending and receiving of data, physical movement of components within or by the IoT device, monitoring of parameters by the IoT device, and so on. Where an IoT device executes a complex application, the processes may be divided into a plurality of tasks, that is, an application may comprise plural tasks. In an example of this; where the IoT device is, for example a domestic appliance such as a clothes washing machine a complete cycle (application) may consist of a wash cycle (task) and subsequent drying cycle (task). Alternatively, more simple applications may consist of a single task, so the terms “task” and “application” may be interchangeable. Depending on the composition of a particular system, the device shutdown message may include application or task identifiers (or both) and may count applications executed or tasks executed.

[0039] In an aspect of an embodiment wherein the device shutdown message comprises at least one of a device identifier or an application/task identifier, the device shutdown message may comprise an application or task count. The exact nature of the count is determined by the specific IoT device. Where the IoT device is a sensor, the tasks counted may be readings taken, or readings transmitted from the IoT device using the network connection (which may or may not be the same value). Where the readings transmitted is sent as the task count, this may help in calculations of the amount of network resources used, particularly when combined with knowledge of the average amount of data sent in each reading transmission. For other IoT devices, the task count may be less closely related to the amount of network resources uses. Where the IoT device is, for example a domestic appliance such as a clothes washing machine, the task count may be the number of washing cycles completed. The task count may therefore be used to record a number of tasks executed by an IoT device even in cases wherein the tasks do not require network resources; this may be useful where the task count is used for charging purposes as discussed below. A single IoT device may be capable of executing a variety of applications, each of which may or may not comprise plural tasks. Accordingly, a single device shutdown message may comprise plural application and/or task identifiers, with associated counts.

[0040] In any of the aspects of embodiments, the application/task count may be the total number of applications/tasks (transmissions, washing cycles, etc.) completed since the first activation of the IoT device, or the first connection of the IoT device to the network. However, where total number information is used, this requires the IoT device to maintain a persistent record of the total task count, which may place additional requirements upon the device, for example, including sufficient storage that can retain information when the device is shutdown. Therefore, the task count may identify the count of tasks since the activation of the device, that is, not taking into account any tasks that occurred before the device was shutdown.

[0041] In an aspect of an embodiment, the method may further comprise shutting down the IoT device (see FIG. 1, step S104). The IoT device may be shut down following the sending of the device shutdown message, as shown in FIG. 1, step S106B and S104B. The IoT device may also be shutdown prior to the sending of the device shutdown message (see step S104A); this may be the case, for example, where a mains powered IoT device is subjected to an unscheduled loss of power as discussed above. In situations wherein the IoT device is shut down before the device shutdown message is sent, the device may be configured to retain the device shutdown message so that the message may be sent (see step S106A) following the restart of the device (see step S105). Sending the device shutdown message even in the event that the device has already shutdown and restarted may be helpful for charging purposes, for example, to retain an accurate record of tasks or applications executed by an IoT device. However, sending the device shutdown message after the shutdown and restart of the IoT device can lead to delays in the information contained in the shutdown message reaching the network node for onward transmission. Also, sending the device shutdown message after the shutdown and restart of the IoT device requires the information to be contained in the device shutdown message to be stored while the IoT device is in a shutdown state (either in the IoT device itself or in a further device responsible for sending the message, depending on the specific configuration of the system), which necessitates the provision of persistent storage. It is therefore preferable for the device shutdown message to be sent prior to the shutdown of the device, particularly for situations wherein the IoT devices are comparatively simple and/or may not be restarted.

[0042] In an aspect of an embodiment, the device shutdown message may be received by a network node, as shown in FIG. 2, step S201. The network node may be, for example, the network node of either of FIG. 4A and FIG. 4B. The device shutdown message may be received by the processor 41 of the network node 40A shown in FIG. 4A via the interfaces 43, executing instructions stored in the memory 42, or may be received by the receiver 44 of the network node 40B shown in FIG. 4B. The network node may be a conventional base station, as discussed above, or may be any other suitable transmission and reception unit such as a private node, picocell hub, and so on. For conciseness, the term “network node” is used herein to refer to all of the various alternatives where it is not necessary to indicate the specific type of network node used.

[0043] Although the network node may be connected to, and receive a device shutdown message from, a single IoT device, typically network nodes are connected to a plurality of IoT devices. The IoT devices may be linked and used for a common purpose, for example, a plurality of temperature sensors used to monitor the temperature at a variety of positions in a given area. Alternatively, the plurality of IoT devices may not be connected or linked to one another, and may all be connected to the network node for other reasons (such as the proximity of the network node to the IoT devices).

[0044] Where the network node is connected to a plurality of IoT devices, the network node may receive device shutdown messages from the plurality of IoT devices. The messages may be sent on an individual basis, for example, by each of the IoT devices themselves. Alternatively, and particularly where the device shutdown messages are triggered by the IoT devices but not transmitted by the IoT devices themselves, the device shutdown messages may be sent in batches by a unit responsible for transmissions. An example of a situation wherein device shutdown messages may be sent in batches is where the plurality of IoT devices are contained within a single area overseen by a single owner, for example, where a router in a domestic home is used to send device shutdown messages for a plurality of IoT devices contained in the home and connected to the router.

[0045] As shown in FIG. 2, step S202, the network node may then consolidate the information from the device shutdown message or messages. Where consolidation takes place, this may comprise one or more of accumulating information from the one or more device shutdown messages, deleting superfluous information, categorising the information from the device shutdown message or messages into two or more categories, and so on. The step of consolidation may be of particular use where plural device shutdown messages are received; the consolidation can then be used to accumulate data relating to the plural devices into a single unified report, which can then be transmitted on using the network in a single report (an example of which is discussed below), thereby reducing the amount of network traffic and saving network capacity. This is of particular use where the network node is connected to a large number of IoT devices; consolidating the information from, for example, a thousand IoT devices into a single report can result in a substantial reduction in onward traffic from the network node. The device shutdown messages may be consolidated by the processor 41 of the network node 40A shown in FIG. 4A, executing instructions stored in the memory 42, or by the report generator 45 of the network node 40B shown in FIG. 4B.

[0046] In addition or alternatively to consolidating information from one or more device shutdown messages, as discussed above, the network node may also apply a multiplication factor to the information. The multiplication factor may be applied by the processor 41 of the network node 40A shown in FIG. 4A, executing instructions stored in the memory 42, or by the multiplier 46 of the network node 40B shown in FIG. 4B. The application of the multiplication factor is illustrated in step S203 of FIG. 2. A number of different multiplication factors may be applied, including the application of different multiplication factors to different information from the same device shutdown message or messages. As an example of this, if information from a plurality of different device shutdown messages is consolidated and categorised into different categories based on the type of originating device (e.g. temperature sensor, pressure sensor), different multiplication factors could then be applied to each of the categories. Where an IoT device executes a plurality of different tasks or applications, different multiplication factors can be applied to counts for the tasks (applications) separately. Also, where plural IoT devices can execute the same task or application, the counts for these tasks or applications from across the device shutdown messages may be summed before applying multiplication factors.

[0047] The multiplication factors can be used to calculate various different parameters, some examples of which are discussed below. Where the multiplication factor provides an average data usage per instance of a particular task (or application) which is represented by a category, the product of the task count and the multiplication factor may provide an estimate of the total network data usage associated with the completion of the particular task by the IoT device or devices (in the active period terminated by the shutdown of the IoT device or devices). Where the task count is used to provide information used to charge a user, the multiplication factor may be a cost per task instance, allowing a combination with a task count for the given task to obtain a total cost incurred.

[0048] The network node may the generate a usage report using the information from the one or more received device shutdown messages, as shown in step S204 of FIG. 2. The report may be generated by the processor 41 of the network node 40A shown in FIG. 4A, executing instructions stored in the memory 42, or by the report generator 45 of the network node 40B shown in FIG. 4B. The report may be generated using the data from the one or more device shutdown messages with no substantial modification (such that the report is essentially a compilation of the different device shutdown messages). The report may be generated using consolidated information to which a multiplication factor has been applied if the specific aspect of an embodiment includes consolidation and multiplication. The generated usage report may then be transmitted on through the network (for example, to a central server) and/or used to reallocate network resources. As an example of the reallocation of network resources, where the usage report indicates that an IoT device has transmitted a given amount of data, at a given frequency, for a given period of time, this information may be used by the network node (or another component in the network) to identify an amount of network capacity which has been made available by the shutting down of the IoT device. The network node may then take steps to reallocate the network resources (as shown in step S205); this reallocation may take the form of making the network resources available to another IoT device or devices (or further, non-IoT device or devices), or deactivating network components to reduce the total network resources available to save energy. The reallocation of network resources may be executed by the processor 41 of the network node 40A shown in FIG. 4A, executing instructions stored in the memory 42, or by the resource reallocator 47 of the network node 40B shown in FIG. 4B.

[0049] An example of the processes which may be performed by an IoT device, network node and partner server in a network according to an aspect of an embodiment are discussed below, with reference to FIGS. 5, 6 and 7. FIG. 5 is a schematic of components in a network in accordance with an aspect of an embodiment. In the example shown in FIG. 5, the multiplication factor MF is provided to the network node from a further server, here referred to as the partner server. The present example relates to a system in which the usage report is used to charge a user for tasks executed by plural IoT devices. The partner server is responsible for providing multiplication factors to the network node that indicate a charge per task for tasks performed by the IoT devices. The multiplication factors may be set by a commercial company partnering the network operator, which is why the server is referred to as a partner server.

[0050] FIG. 6 is a signalling diagram for an initial configuration of an IoT device by a network node, typically although not exclusively performed when the IoT device is first connected to the network node, in the aspect of an embodiment shown in FIG. 5.

[0051] In the aspect of an embodiment shown in FIG. 6, the network node provisions (transmits) configuration information to the IoT device. The configuration information is used to configure the IoT device, including causing the IoT device to record the frequency with which a task is executed (the task count) until the IoT devices enters a power shutdown mode. The configuration information also causes the IoT device to set the value of a counter for the task count to zero on IoT device boot; the counter zeroing may therefore occur on initial activation of the device and/or activation following a shutdown. The IoT device then sends a message to the network node indicating that the initial configuration has been successfully completed. Using pseudocode:

[0052] Configure: [Shutdown mode, Task Frequency]

[0053] On boot: resets [Task Frequency].fwdarw.0

[0054] FIG. 7 is a signalling diagram for the processes performed by an IoT device, network node and partner server in an aspect of an embodiment, subsequent to the initial configuration of the IoT device (as shown in FIG. 6). For each instance of the task being executed by the IoT device, the task count in the IoT device is incremented. In pseudocode:

[0055] On run: [Task Frequency]++

[0056] Following a period of operation, the IoT device enters a power shutdown mode. A device shutdown may be triggered, for example, because the device battery is exhausted or falls to a predetermined threshold level , the device is subject to a scheduled or unscheduled interruption in mains power supply, a device shutdown message is received, and so on. The IoT device then stops performing a task and also stops updating the task frequency parameter stored on the IoT device. In the aspect of an embodiment illustrated in FIG. 7, the IoT device then fetches the updated task frequency and creates a new shutdown message, initiates transmission of the message towards the network node and disconnects from the network node. In the aspect of an embodiment shown in FIG. 7, the device shutdown message includes: [0057] i. device's frequency of completed tasks (task count) since device activation, [0058] ii. device ID (in the aspect of an embodiment shown in FIG. 7, the device ID is “P”), [0059] iii. device task ID.

[0060] In the aspect of an embodiment the operations performed by the IoT device are monitored on a per task basis, and the device shutdown message does not contain application IDs. Following disconnection, the IoT device completes the shutdown process.

[0061] In the aspect of an embodiment shown in FIG. 7, the device shutdown message is used to indicate the number of times the IoT device has performed a specific task, for the purpose of generating a report allowing charging of the operator of the IoT device based on the total number of tasks executed. The IoT device of FIG. 7 performs three tasks: A, B and C. An IoT may be capable of performing larger or smaller numbers of tasks, including performing a single task. Examples of tasks may include a washing machine performing a wash cycle, or a temperature sensor taking a temperature reading. The task to which a task count relates is identified by the device application ID in the shutdown message. In aspects of embodiments wherein an IoT device is capable of performing a variety of different tasks, the IoT device may retain separate task counts for each of the different tasks, which may be associated with different task IDs. The device shutdown message sent to the network node may then include the separate task counts (in conjunction with the task IDs). The devices may also record applications executed, which may consist of plural tasks as discussed above, and the device shutdown messages may include application IDs and application counts.

[0062] The device shutdown message is received at the network node. In the aspect of an embodiment shown in FIG. 7, reception in a network node of the message may trigger consolidated report creation logic (which then generates a consolidated usage report) if there is a non-zero task frequency/count received in a device shutdown message. In aspects of embodiments where the network node receives device shutdown messages from a plurality of IoT devices, such as the aspect of an embodiment shown in FIG. 7, the generation of a consolidated usage report may be triggered if a non-zero task (or application) frequency is received in a shutdown message from any of the IoT devices. In some aspects of embodiments, the generation of a consolidated usage report may not be triggered upon receipt of every device shutdown message, and may be triggered by only some of the device shutdown messages or by other triggers. As an example of a different trigger; in a system wherein one or more IoT devices are configured to shut down and activate frequently (for example, sensors that shut down between readings), the network node may be configured to generate a consolidated usage report including task count information from the one or more sensors on a periodic basis, such as hourly, daily, or at another periodicity. Additionally or alternatively, the consolidated usage reports may be generated when a predetermined number of device shutdown messages have been received, for example, 10 device shutdown messages.

[0063] As indicated in FIG. 7, the network node may group the task counts based on various grouping criteria. Potential criteria include grouping according to type of device (for example, task counts for plural devices of the same type may be grouped), application or task (task counts for the same task performed on different devices may be grouped, and/or for tasks that form part of the same application), location of IoT device or network node, time, service-ID (a particular service the user of the IoT device uses), service provider-ID (the party responsible for providing a particular service), uplink traffic, downlink traffic, and so on. The grouping criteria may be locally set at the network server, or may be set elsewhere in the network and communicated to the network server. The aspect of an embodiment shown in FIG. 7 uses the task type as a grouping criteria.

[0064] In the aspect of an embodiment shown in FIG. 7, the illustrated IoT device has the device ID “P”, as discussed above. The network node in FIG. 7 is also connected to the further IoT devices “Q” and “R”, which are not shown in FIG. 7. Using pseudocode, the calculation of the consolidated task frequency for task A (TFA) is calculated as:

TFA=[TP.sub.A+TQ.sub.A+TR.sub.A . . . ]

[0065] TP.sub.A, TQ.sub.A and TR.sub.A are incoming task frequencies of respective IoT devices (P,Q,R) as per grouping criteria (e.g. for task type ‘A’) received in device shutdown messages from the IoT devices at the network node. Equivalent calculations may also be performed for other tasks performed by IoT devices connected to the node, such as tasks “B” and “C”.

[0066] The network node of FIG. 7 may then apply one or more multiplication factors to the calculated consolidated task frequencies. As mentioned above, the aspect of an embodiment shown in FIG. 7 uses the consolidated task frequencies to generate a Charging Data Record (CDR); a record of the total costs accrued by a user due to one or more IoT devices performing tasks. As such, the multiplication factors used in the system shown in FIG. 7 are the costs applied by the network for each instance of the task being performed. The CDR may therefore be created as shown below (using pseudocode):

[0067] CDR=[k1*[TFA]]+[k2*[TFB]]+[k3*[TFC]+. . . ]

[0068] TFA=Consolidated task frequencies for application type ‘A’ for set of devices

[0069] TFB=Consolidated task frequencies for application type ‘B’ for set of devices

[0070] TFC=Consolidated task frequencies for application type ‘C’ for set of devices

[0071] k1=Multiplication factor for application type ‘A’ for set of devices.

[0072] k2=Multiplication factor for application type ‘B’ for set of devices

[0073] k3=Multiplication factor for application type ‘C’ for set of devices

[0074] In the aspect of an embodiment shown in FIG. 7 the multiplication factor is based on operator and partner agreed policies to charge for the usage of functionality which the IoT device offers. The network server and partner server may exchange multiplication factors as necessary to account for changes in charging rates. The multiplication factors may be set based on the cost per task agreed between a user and network operator, which may take into account (for example) the amount of data transmission required for the task.

[0075] Using the aspect of an embodiment shown in FIGS. 5, 6 and 7, an accurate CDR for tasks performed by IoT devices connected to a network node may be obtained. Ultimately, the obtained CDR may be combined with CDRs for other network nodes to generate an overall charging record.

[0076] It will be understood that the detailed examples outlined above are merely examples. According to embodiments herein, the steps may be presented in a different order to that described herein. Furthermore, additional steps may be incorporated in the method that are not explicitly recited above. For the avoidance of doubt, the scope of protection is defined by the claims.