Many of you probably remember Commander Data, the android on the hit science-fiction television show Star Trek: The Next Generation, based on the original Star Trek series created by Gene Roddenberry.
If you were a fan of the series, you know about the location on Commander Datas back that, when pressed, would cause him to shut down.
Of course, not everyone knew about this Master On/Off switch, but, on a few episodes, this Master On/Off switch was indeed used to de-activate him temporarily.
Particularly under conditions where Commander Data truly needed to be turned off.
Similarly, M2M Devices may need to be turned off when it makes senseeither temporarily or permanently.
Let me explain ...
How do you plan to remove units?
In the mid 1990's, when Aeris began discussions with Carriers to set up the roaming arrangements under which we offer network services, we met with Ameritech (now part of AT&T) in Chicago.
I was enthusiastically detailing our machine data services (before the acronym M2M even existed), and waxing about how our patented MicroBurst solution would enable a class of applications to send data to and from hosts for a variety of purposes.
A very experienced Director at Ameritech, Dick Gove, asked a question that I will treasure a long, long time: How do you plan to remove units?
I was quite taken aback and silent for a few seconds. Huhn? We wanted to add units month over month for ever-increasing service revenues not remove them!
Runaway and Other Devices
I must have looked blank, because Dick elaborated further, What if a unit is stolen? Or runs away and transmits continuously? If a unit impacts the network in some way, can we disable it?'
The light dawned!
Cellular data devices that may be connected to good sources of electrical power (unlike batteries in handsets that eventually lose power when left untended), could continue to transmit if the application firmware chooses to do so.
Or certainly register on the network when they are powered upperhaps multiple times a day.
For example, a security Device could continue to transmit heartbeats on a regular basis (I am alive and well messages), even if the home owner or business decided to cancel their security service.
A vehicle could power up and the installed M2M Device in the vehicle could register on the cellular network and be ready to transmit even if the owner had sold the car and no longer desired service.
We Needed a Solution
I promised Dick that I would come up with a solution to his How do I disable a runaway unit? concern, and return to present it to his satisfaction.
On my flight home, I realized that we needed to not only handle the scenario of runaway units, but also handle other potential issues, i.e., for more than just malfunctioning Devices:
- What if our Customer wanted to be able to remove all his units from service once the Application had run its course? Could we permanently disable their units?
- What if our Customer went out of business? How could we permanently remove their deployed units from the network?
- What if the application needed temporary disables? Could the Customer suspend the units for a period of time and ask us not to bill them?
- What if a Customer failed to pay their bills? Could Aeris turn off services at the Devices temporarily?
- The cost of touching a runaway Device to shut it down could be expensive! Could we prevent transmissions while we get technical resources to the Device site?
Clearly, the need for both temporary disables (i.e., one that could be re-enabled remotely) and permanent disables was vital!
Sending technicians to remote locations to remove Devices from service is prohibitively expensive. Product recalls, or expecting End-customers to bring their units in for service/replacement, simply is not practical or possible in many cases particularly for units that are deployed or mobile in the entire country (think of a long-haul trucking fleet application!).
The scenario where a unit could continue to stay on the network indefinitelyeven if we wanted to take it out of service temporarily or permanentlywas an issue we had to address.
Aeris Module Control Functions
Also on the flight, I thought about how we could modify the firmware in the cellular radio to allow us to disable units in the field.
And also to extend the concept of device disables further than Dick had asked for ... to address the questions I raised above.
Aeris worked on a capability (now patented) that we incorporated into our radio modules that would allow Aeris and the Customer to temporarily disable Devices in the field.
As well as allow Aeris to permanently disable Devices so that they needed to be returned to the factory to be re-enabled for service.
These functionality had to be carefully designed to prevent accidental or deliberate, i.e., uncontrolled, invocation (imagine a Home Security device where the burglar can disable the cellular radio inside the unit too easily!)
These capabilities were added to our early release of our Aeris Module Control Functions inside the radio Modules, and we developed and released a set of new functions to our data Application Programming Interface (API) connections to our Customer host systems.
Life Cycle Management
As is very common with new product and new service and new technology development, we techiesparticularly in start-up companiescan get all caught up in the excitement of what we are trying to do and forget about an important issue: Product Life Cycle Management!
This is not just an issue for Aeris.
In this day and age, where the general concern of product obsolescence and over-full landfills, green products, etc. is paramount, it is important to recognize that products do have an end-of-life.
In particular, when M2M cellular Devices reach their end-of-life, they must be carefully removed from service to avoid impacting the network.
Recovery of Number Resources
Resources, such as numbers inside the units, must be recovered for re-use.
Otherwise, we run the risk of problems, such as the exhaustion of Electronic Serial Numbers ("ESN"), that complicate cellular network operation.
Even though many ESNs in the world are not in use (old Analog AMPS and EIA-136 TDMA phones are gone, many older CDMA phones are no longer in service, etc.), the records are non-existent and incompleteindeed, they cannot be updated because many companies have ceased doing business, etc.
Thus, old ESNs simply cannot be re-used.
Radio Disables and Removal
To avoid cellular presence on the network once a Device must be removed from service, power must be permanently removed from the unit.
Without the possibility of accidental power-up at any time in the future, since its numbers may have been re-used in another Device and confuse the operation of the new unit.
Other Good Reasons
Clearly, there are other reasons for making sure that the entire Product Life Cycle Management is properly handled in all M2M Applications and a full discussion is beyond the scope of this post.
Furthermore, related to the topic of Life Cycle Management is the issue of Application Updates, but that is the subject of another future post too!
Regardless, I encourage readers to contact our Customer Sales Engineering department to learn more about this topic and the capabilities that we provide our Customers to assist them with this very important aspect of their M2M Application deployments.
The End of the Story
By the way, when I returned to Ameritech to present our solution to the concern that Dick Gove had raised, he was very happy that we had addressed the topic beyond his original questions and concerns.
In a technical evaluation of Aeris vs. our competition, we were selected for deploying our MicroBurst data service on the Ameritech network!
And the rest is history.
P.S. Dick, I have not been able to track you down to thank youeven in this Google-enabled erabut I do want you to know that your inputs were vital to us. We implemented the capability and once, we used it to remove a few thousand errant Devices that could have impacted our business very badly! Thanks much, Dick!