Bringing new mobile phones and apps to market has been relatively quick and painless since the emergence of iPhone and Android platforms. The same is not true for M2M devices and apps. M2M can be very challenging. In fact, many M2M projects fail to get off the ground because of the myriad obstacles posed by the devices, the networks, and the application environment.
We at Omnilink® are well acquainted with these common obstacles, having worked through and around them to successfully bring some of the most complex and mission-critical M2M solutions to a variety of markets for 8 years. We’re also keenly aware of, and excited about, improvements that are looming on the industry’s horizon.
Challenge 1: Devices
What do M2M customers want? Most M2M customers want the devices they purchase today to work 3, 5, 7 years later. That’s because many M2M use cases necessitate a “set it and forget it” approach to hardware. It can be costly, difficult, and—and in many cases unnecessary—to refresh or upgrade devices as frequently as, say, consumers go through cell phones (about every 18 months). Not only do M2M customers want their devices to work years later, they want to be able to order more devices for years after the initial purchase.
It can be hard to give customers the device lifespan they want because M2M chipset and module supply and support are limited. That’s because chipset manufacturers—assessing the near-term opportunity—prioritize chipsets for mobile phones more highly than chipsets for M2M devices. So chipset manufacturers stop producing and supporting an M2M chipset, causing module manufacturers to stop producing and supporting modules with the discontinued chipsets. This in turn makes it difficult to sustain devices already in the market, and to maintain and increase M2M deployments.
For example, imagine that a company begins development of a custom M2M device. The module in the device is 2 years old, and the chipset in the module is 4 years old. A typical development cycle is 12-18 months, so 1.5 years after starting the project—when the device is nearing completion—the module is 3.5 years old. The chipset is now 5.5 years old and the manufacturer pulls support of the chipset. The module manufacturer soon follows suit and stops producing the module. What is the solution provider to do? The device manufacturer must either work with an unsupported chipset until more module supply is available or start from square one with a completely different module.
Imagine that the project launches and thousands of M2M devices have been in the field for 3 years when the chipset in use loses support. The only option presented by the module manufacturer: Encourage customers to swap out the modules with the unsupported chipsets for entirely new modules. The solution is profitable for the module makers, but expensive, inefficient and logistically complex for the solution provider and end customer.
How can these lifespan challenges be avoided? Experience is invaluable. We’ve found that the key is selecting the right module with the right chipset to ensure continued production and support. And, maintaining close relationships with manufacturers helps us to stay on top of what’s happening with chipsets and modules, making it possible to select those that will prove most successful for a given project.
Another challenge is that M2M device advancements are being stunted by the expense of integrated modules. While cell phone manufactures have the luxury of spinning their own integrated modules because their volumes are high enough to take advantage of economies of scale, M2M device manufacturers—who produce less volume per market segment—often must use the less expensive, off-the-shelf certified modules. Off-the-shelf modules are beneficial in that they decrease the scope of the certification process significantly, the time to launch, and the cost, but they also come with drawbacks like short battery life. It’s possible to create a device that combines several features like cellular radio, GPS, short-range communication, and application processing with long battery life but—because it requires an integrated module—it is cost-prohibitive.
What’s the fix? You can control costs while maximizing battery life and providing all necessary functionality by being smart about which off-the-shelf modules you select. Ideally, you want the module that provides all the features you need, and none of the features and hardware you don’t. Barring that, you want the module that provides all the features you need, and also gives you the ability to disable any unwanted features so that no battery is used for unwanted features.
Challenge 2: Networks
The current network certification processes are tailored to mobile phone development; certification hasn’t been adapted properly for M2M devices, though mobile phones and M2M devices are markedly different. For example, while phones have keyboards, screens for user interaction, and can accept voice calls, the majority of M2M devices do not have any of those features. So network certification and testing processes and documents are, in many cases, not applicable to M2M. The result is that certification may require the manufacturer to test M2M device behavior in cases where the device has to process incoming voice calls while running applications simultaneously. But the device does not support voice calls.
How to make it easier? It’s important to establish deep working relationships with carriers and network labs early on. Those ties can help you to push through—or even get waivers for—these certification conflicts. We’ve found it extraordinarily helpful to start the certification process as early as possible. Be prepared to start testing the moment the hardware is ready.
Carriers’ technical support suffers from the same lack of M2M adaptation. To address an issue with an M2M device, often includes rounds of irrelevant troubleshooting questions like “can you remove the battery and then put it back?” and “how many bars are you seeing on the screen?” Not only are devices more often in the field than in hand and available for such inspection, they don’t typically have removable batteries, screens, or coverage bars.
What’s the solution? Carriers’ must adapt their support processes to M2M. In the meantime, we’ve made sure that our M2M applications report enough critical diagnostic device information (battery, bars, tower details, application and firmware versions, etc.) to help grease the wheels of the troubleshooting process.
Lack of adaptation to M2M rears its head in other ways as well. Carriers periodically deploy new software enhancements across their networks that are not M2M-friendly. For example, one security enhancement may put in place to recognize all brief, around-the-clock data transfers as spam—because brief and continuous calls are inconsistent with typical human behavior—and to blacklist them. An enhancement like this—architected without regard for the behavior of the M2M devices that share the network with mobile phones—can have significant monetary repercussions for commercial M2M deployments, and catastrophic consequences for the mission critical M2M deployments like those used by governments to protect public safety.
How to protect against these risks? First, have tools and reports to help you immediately identify whether the cause of the issue is device-related or network-related. Make sure that your contracts with carriers require that they allocate dedicated account and support resources to your project. When there’s a critical issue, it’s essential to be able to quickly collaborate with a support team that has the M2M knowledge base to quickly resolve the issue.
Also, carriers’ billing systems round data size to the nearest kilobyte. This practice of rounding may not negatively impact phone customers with today’s standard all-you-can-eat smartphone plans, but it can significantly inflate the data price for M2M customers who only send small bytes of data at a time. Having a data plan that pools across several M2M devices would do much to reduce the overall cost.
Specialized M2M network providers do accommodate M2M customers by not implementing rounding practices in their billing. And they can provide interfaces to M2M application vendors to send messages to M2M devices and receive IP data without a phone number. But the cost savings and added security they offer are balanced by other deficits, like their inability to function as a national sales channel.
Additionally, carriers usually require that all devices—including M2M devices—have phone numbers, though M2M devices don’t need to support voice calls. This requirement is problematic because phone numbers provides a direct route to the device, which compromises security and increases the likelihood of spam.
The answer? These challenges will be resolved nicely once carriers adapt their policies and practices to M2M. In the meantime, we’ve had the most success using specialized M2M network providers.
Challenge 3: The Application Environment
M2M application development environments are not standardized like cell phone application platforms (iOS, Android, J2ME, Windows Mobile, BlackBerry, etc.). As a result, the application development and updating process is different across all types of devices. Application environments like BREW—which works with Qualcomm CDMA modules—are helpful but not all modules work with BREW.
M2M modules can leverage features like application updates and push notifications from standard mobile phone platforms provided they are trimmed to fit in to the M2M device. But an M2M device’s processing power is less and battery life requirements are more demanding.
What to do? Until M2M application development environments become more standardized and full-featured, M2M solution vendors will have to continue to select the application platform that is most suitable for the given solution’s requirements.
The Future is Bright
Carriers, module vendors, service vendors and standards organizations, more than ever before, are recognizing the potential of M2M. As a result, they are becoming more invested in it, which in turn helps the industry evolve, mature and develop solutions to the many challenges we currently face.
For example, Open Mobile Alliance (OMA) published phase 1 of the Lightweight M2M (LWM2M) standard for M2M devices last year, which moves the industry closer to having a standardized protocol for device management, service and application data transfer.
Module vendors like TelIt and Sierra have developed their own M2M platforms (m2mAIR and AirVantage, respectively), to help simplify M2M device management for users. These enablement platforms help M2M application vendors focus on server side applications while device management and communication to the cloud is managed by module vendor platforms.
AT&T M2M 360 is an example of carrier providing a control center to solve the problems related to the billing and management of M2M devices on the network. Sprint’s M2M Collaboration Center is another example of a carrier trying to decrease the time to market for M2M devices. Verizon has internal groups like PDI to traverse M2M device challenges.
The bottom line is that the M2M space faces obstacles that add to the solution’s total cost and hinders growth in certain markets. Over time, the M2M application platform will evolve from a closed platform to an open, well-defined platform, just as cell phone application platforms did. The certification process and support process will mature and become more suitable for M2M devices. In the meantime, choosing an experienced company to launch your M2M solutions will be the key to your success.
About Yogi Rajala
As Omnilink’s chief technical officer, Yogi Rajala introduces cutting-edge technologies into Omnilink’s arsenal of M2M solutions. Omnilink’s M2M knowledge and experience bridge the gap between market opportunity and business implementation, and have helped many a partner surmount M2M challenges and spin their vision of a connected world into reality.
Powered by WPeMatico