Internet of Things (IoT) Device Management (full life cycle) and Billing will be key pieces of the IoT Infrastructure. An integrated platform for Device Management and Billing at the IoT Service Layer correlated with Billing at the Network Layer is shown in the Figure Above.

For Device Management multiple protocols exist, but the relatively new LWM2M Protocol for constrained devices and the upgraded OMA DM2.0 Protocol are protocols that are of interest for a generic IoT device management platform.

Given the predicted number of IoT devices and the variation in characteristics of these devices, such as limited network bandwidth, low power and memory, a generic interface for management of these devices such as LWM2M is required. LWM2M is based upon REST and CoAP. CoAP is an alternative to HTTP for resource constrained devices, but supports very similar operations – (GET, POST, PUT, DELETE).

Device Lifecycle Management consists of:

• Firmware update (via a URL sent in the update message)
• Software Management
• Device Memory
• Connected Network Information
• Battery Status
• Device Information
• Device Capabilities
• Reboot
• Record Device Event Log
• Network Communication Policy
• Network Access Rues

Note that applications that run on the device can also be managed (configured) using the Protocol.

It is also possible for the device manager in the service layer to request status notifications on attributes (if the attribute changes) at the device layer.

Billing can cover network usage (assuming a 3^rd party provider is used) and charges related to applications on the IoT platform. For the latter, charging can be independent of the underlying network or correlated with the underlying network. For independent service layer (OneM2M CSE/ETSI SCL) charging, the Service charging and Accounting CSF module in the Service Layer can charge on Events such as CRUD operations on data, as an example the reading a location of a device from the service layer. Charging rules are configurable at the SCA, and may be provisioned via the Mca reference point (see below). The chargeable events are recorded by the IN-CSE according to the charging rules, and the SCA then generates charging records and sends the records to the billing domain via the Mch interface.

The charging Management Function, which is a component of the SCA, handles the charging policies and can interact with the charging system in the underlying network.

Rating and Billing for use of a 3^rd party charged network could in one use case just require the use of unlimited data bundles. However, there are some considerations that network operators may take into account for pricing models.

More sophisticated bundles may be based upon transmission times (important in some M2M networks as it’s not advisable for all devices to send a report on the hour), data packet size, and mobility of the device, mobility generally having a higher cost for the network operator.

A Charging System that can charge both the underlying network and the IoT Service Layer and correlate these charges as required, could be used for both the MNO and the MVNO model.

Other charging models are required for the case where multiple IoT service providers interact with each others services. As an example Application A on the Service Layer could use Data from Application B. In this case Application A is charged by Application B, if the charging policy of the Service Layer has been setup to charge for this type of event. Similarly an Application on another Service Layer could use data from an application on this Service Layer and similar charging policies could apply.