Some weeks ago, I posted about Aeriss Rapid Provisioning System that allows Customers to rapidly provision Devices for operation on the Aeris Network Services.
I briefly touched on the differences between Provisioning and Activatingtodays post will explain these in a bit more detail.
M2M Devices require special handling and unique billing services that are not typical for consumer (and corporate) cellular handsets and data cards.
- Automated factory floor On-Air testing of Devices when manufactured.
- Sitting in shipping or distribution for uncertain (sometimes lengthy periods).
These require fast provisioning capability (as discussed in that earlier post) and, equally importantly, the need to separate operate live on the air from receive monthly bills for services.
When Aeris first offered M2M Network Services in the mid-1990s, we recognized this requirement from our very first, high-volume Customer, who was selling business and residential security systems using our network services.
Automated Factory Floor Test
This Customer manufactured their Devices (including integrating the cellular radio from a radio supplier into their own security panel hardware) in Mexico, and tested the completed Devices at the factory, to confirm proper operation prior to boxing and packaging.
It was important to ensure that the installed units were functionally normally before they left the factory, since a later manual touch for faulty Devices was very expensive.
The manufacturing site in Mexico shipped the Devices to the Customer headquarters in the US, and from there they went into their multiple distribution channels.
One of these distribution channels sold the completed security Devices to security companiesthe medium to large (national) monitored security service companies in the US and Canada.
Other channels sold the Devices to other security companiessuch as small Mom-and-Pop monitored security service providers.
Thus, the period from final test to final installation varied, ranging from weeks to many monthssometimes more than a year.
The installation of the Devices in business and homes was done by field technicians who need to maximize the number of installed units per daywithout calling in to activate service and/or waiting to test the Device for proper operation.
These early requirements are similar to the needs of current Customers in just about every M2M Application.
To support the above requirements, Aeris needed to ensure that the processes were highly automatedunder the control of the Customerto eliminate human interaction, minimize time and reduce cost.
To address the requirements described above, Aeris created the concept of Device States:
and the transition actions (manualunder the control of the Customerand automatic) to move a Device between these states.
These actions (i.e., to move a Device) are invoked through the AerPort web portal, or via the XML/SOAP interfaces to the AerAdmin systems.
Some of the actions are also automaticthe state transitions occur when pre-defined operating conditions are met.
In this diagram (from our AerAdmin System Specification document):
the Device States are shown in Blue inside ovals and the State transition functions are shown with black arrows and Red text. Some of the automated actions are shown with black dotted arrows and Green text.
The Provisioned and Active-Billed States, and some of the transition actions are described below.
(For more detailed information on the other States and transition rules, current Customers can retrieve the AerAdmin System Specification document at the AerPort portal.)
In the Provisioned state, a Device is capable of operating on the network and can transmit and receive data, but it is not expected to provide active normal service to, or generate revenue for, the Customer.
The Device does have a billing rate plan assigned to it, but it is not being actively billed by Aeris for monthly chargeshowever, the Customer may have transmission costs for services, using the assigned rate plan, that are charged if the Device is used in the Aeris network prior to being activated.
Essentially, in the Provisioned state, the Device is known to, and can operate in, the Aeris AerFrame systems, but is not yet in an Active-Billed state.
In the Active-Billed state, the Device is active and operating on the network as expecteddelivering service to, and generating revenue for, the Customer.
This is the normal operational state for deployed Devices that are generating revenue for the Customer, and, thus, for Aeris.
A Device in the Active-Billed State has a rate plan assigned to it, and the Aeris billing system is generating detailed billing records from the data messages being transceived by the Device.
At the end of each billing period, the Aeris billing systems generate an invoice to the Customer, using the pricing arrangements contracted by the Customer .
Essentially, the Device is known to, and operating normally in, the Aeris AerFrame systems.
Manual Transitions From Provisioned to Active-Billed
A Device in the Provisioned state can be moved to the Active-Billed State.
Using the AerPort portal, the Customer can select one or more Devices and activate them by selecting the specific function.
If the Customer systems are also designed to use the AerAdmin XML/SOAP interfaces, this activation can be performed by the Customer systems as part of another process (for example, when a security system is installed, the installer can invoke an automated process to start service).
Automatic Transitions From Provisioned to Active-Billed
A Device in the Provisioned state may be automatically moved to the Active-Billed state.
If the Device in the Provisioned state exceeds certain parameters (such as the number of SMS packets transceived, or IP data bytes transmitted, or the Device has been in the Provisioned state for more than a number of billing periods), it is automatically moved to the Active-Billed state by the Aeris systems.
The value of these parameters (for example, the specific number of kilobytes allowed in the Provisioned state) depends on the contractual agreement between the Customer and Aeris.
Our Customers needed to be able to separate the ability to operate live on the network when necessary, from receive a monthly bill for services when they received revenue for service.
We understood this requirement and provided systems to support this need effectively, since the low monthly revenue of typical M2M Applications makes it difficult for our Customers to absorb costs for Devices that might not be generating revenue for them.
Download our free whitepaper: