Overview
M2M as a technology is about to experience an unprecedented revival of interest in its commercialization on potentially countless type of practical M2M applications with the prediction of phenomenal market demands and will be affecting all areas of our lives.
The condition for innovation and productization of M2M Apps over-the-air, over-the-wire or over-power-lines is ripe and ready and the consumer market’s appetite for “all-Things-Internet” will only increase with time. With approximately 5 billion people already connected in the mobile communication arena, the wireless phone market is becoming saturated and highly competitive. Finding a differentiated edge is paramount for wireless network and service providers to move into the next phase of new service creation and revenue source.
The advent and gradual adoption of IPv6 with its astronomical addressable units is a solid stepping stone as well as a springboard for M2M. Without it, trying to identify billions of endpoint devices easily would very much be a hard problem to solve, indeed.
Wired and Wireless Land and Mobile Network convergence and seamless mobility for the mobile phone segment of the communication industry has paved the way to a much broader range of vertical applications for a variety of industries that are heading towards building autonomous self-organizing networks (SON).
With 3G and now 4G LTE aiming at being ubiquitous in the near future, the cost of moving a byte is cheaper than ever and the ARPB (average revenue per byte) is going up. Cost of bandwidth still matters however, as a formidable business overhead for MNOs and MVNOs alike. They need new infusions of value-added services to sustain a more consistent growth rate with low investment, low churn and higher ROI.
The M2M market presents a whole new avenue for green field deployments in all areas of a “connected world” view.
Main Requirements
Standardization is key to M2M interoperability. The stakeholders must come together with requirements from their respective industry and build standards not unlike the Wireless standards that are in use today. Off-the-shelf plug-n-play efficiency and lower total cost of ownership (TCO) are also common features for considerations.
Here are a few main requirements:
· Design and architecture need to address the mobility attribute specifically for M2M devices. It tends to be low to none or only in a bounded region.
· M2M events detection is needed as a main functionality in addition to device and traffic flow performance and safety monitoring.
· Take into consideration that small amount of data exchanges between M2M devices and M2M server/service is usually frequent and at pre-defined time intervals.
· Take into consideration the non-time-critical nature of M2M data transfers between M2M devices and M2M servers and the potentially massive volume of bytes arriving simultaneously to the server for processing.
· Network operator must support packet-switched services with or without an MSISDN.
· Detection mechanisms must be in place for indicating ‘Offline’ when M2M device is disconnected from the network and timely reporting of ‘Jamming’ when M2M device is being jammed due to broadband interference.
· Priority Alarm Message (PAM) service is required for immediate reporting of theft or vandalism.
· Group categorization of M2M devices based on feature types is essential for automatic device discovery and bulk provisioning and processing.
· Location based services for pre-defined triggers to associated actions via M2M devices.
· All communication connections must be secured especially via roaming operators and from a global perspective.
· The wired and wireless system as a whole needs to be made more efficient for M2M applications where low power consumption (e.g. optimum performance per-watt-density), low mobility and a small form factor for M2M embedded modules are usually required.
· M2M as SaaS (Software as a Service) via cloud computing must take into consideration of reserving huge storage space for data aggregation and the potentially longer period for data retention.
Technical Challenges
M2M standards are just beginning to come together amidst a still very fragmented and proprietary M2M market. Existing M2M applications are built with vertical stack architecture for dedicated single applications often with proprietary communication stacks or simply making use of the AT command set as the modem interface targeting specific industries such as remote health management, vehicle tracking systems and smart grid metering which currently sit as islands and do not interoperate with each other.
To facilitate an efficient and easy-to-use mechanism for creating M2M enterprise applications needs a mature and comprehensive M2M integrated development platform that allows for business-oriented personnel to navigate and build applications without programming knowledge. A stable and robust abstraction layer needs to function as the foundation with building blocks for value-added service creation in M2M-ready networks.
Many M2M devices are equipped with low bandwidth and shorter range wireless technologies including Bluetooth and Zigbee to higher bandwidth using GPRS, HSPA and the recent emergence of 3G M2M devices with anticipation of the broader distribution of 4G M2M embedded modules and external adaptors to come. The shelf life of these gears as installed base will last from 5 to 10 years on average and lower bandwidth radio serves the need for most of the current M2M applications. Backward compatibility and optimization for M2M implementations are critical and must still cover the range of access technologies from RF, WiFi, 2.5G all the way to 4G/LTE-Advanced for the foreseeable future.
One of the form factors for M2M in an endpoint device is the UICC module. Existing UICC modules are not up to task for best performance under rugged conditions in terms of more extreme temperatures, humidity and in situations resembling a battle field in that hardened form factors are imperative. M2M modules are largely characterized by having low processing power and little memory space. A small footprint for the residing software is essential and can present a real constraint for data transfers, processing, and message exchanges, parsing and data manipulation.
Strictly speaking, machine-to-machine communication implies zero human intervention. The system needs to be cognitive and autonomous; being able to self-govern, self-diagnose, self-heal and self-optimize are desirable M2M design end goals.
Architectural Goals
The “Internet of Things” reference architecture will encompass M2M functionalities overlaying existing core network infrastructure with components bearing similar service layer capabilities. Connectivity shall extend to non-conventional devices including home appliances, buildings, vehicles and containers, monitoring and surveillance devices, recreational devices, telematics and sensors; applicable venues can only be limited by imagination.
The content and context of an M2M application instance separating from application object models presents themselves as resources in a hierarchical fashion is common in the design of RESTful architectures. The core network and transport layers shall be agnostic to the different device types and data transmission methods even with known limitations in transmission range and capacity, power availability, spatial coverage and location.
Data mining techniques capable of efficiently handling massive amount of data generated by M2M devices goes a long way. A horizontal and modular design on service capabilities for the service layer not unlike the IMS’ (Internet Multimedia Subsystem) has been proposed and posit within each of the M2M network component, namely the M2M device, M2M gateway and M2M server.
Currently, this includes Application Enablement, Security, Generic Communication, Reachability, Addressing and Repository, Remote Entity Management, Communication Selection (e.g. based on a preferred carrier list or least cost routing table), Subscription Control, Compensation Broker (i.e. for policy and charging), Telco Operator Exposure, Transaction Management, History and Data Retention and Interworking Proxy. Service-oriented architecture (SoA) also suits well in supporting peer communications among the service modules between the 3 main M2M network elements.
In order to leverage available spectrums and unlicensed bands in the emerging TV Whitespace (TVWS) for over-the-air transmission and general efficiency for M2M applications, the PHY and MAC layers of the M2M stack needs to be adjusted to cater to the M2M requirements especially in the wireless personal access networking (WPAN) protocol domain.
For embedded Internet on the M2M module, protocols like HTTP, TCP/IP, XML and SOAP are not designed for machine-type communications. A binary form of XML, EXI (Extensible XML Interchange) on the other hand is designed to restrict the size of the module and optimize transmission. IETF’s CoAP (Constrained Application Protocol) is another M2M-friendly protocol which simplifies signaling and compress data packets to achieve smaller M2M application footprints.
Interpretive programming language like ’lua’ is a light weight and robust programming tool for M2M devices; together with a recently completed lightweight remote device management protocol; the Converged Personal Network Service (CPNS) module from OMA DM, they are offered as building tools designed specifically for M2M and can make a big impact on device size, performance and robustness.
Connectionless transport protocol UDP is used with the option to request acknowledgment if desired. Addressing and routing over IPv6 shall be made compatible with the requirements for low power and lossy networks.
To provide scalability and extensibility, pushing M2M network intelligence to the edge so as to reduce signaling and control traffic over the network is recommended. It needs to strike a delicate balance however, with what little resources a M2M device may have to carry out required processing. M2M gateway plays the role of providing core functionalities such as Threshold checking, Least cost route searching, etc. and act as an Aggregator Proxy for all traffic coming through from connected M2M devices.
Current Standards
The ETSI (European Telecommunication Standards Committee) TS 102 series specifications cover M2M requirements, functionalities, architectural components and use cases for vertical application types such as eHealth, City Automation and Smart Grids. At the heart of these specifications is a strategy to reuse-by-modification existing networking components to suit the requirements of M2M.
3GPP (3rd Generation Partnership Project) has started to address Machine-Type Communication (MTC) since Release 10 and its latest draft on Systems Improvements for Machine-Type Communication TR 23.888 is well on its way to rectification. The major components are the MTC Application, MTC Server, MTC-IWF (Interworking Function) and the MTC module on endpoint devices. Associated interfaces include MTCsp, MTCsms, MTCi and MTCu. Together with the TS 37 series on Multiple radio access technology aspects, 3GPP’s progress made on M2M is now catching up and in parallel to ETSI's.
OMA (Open Mobile Alliance) is also well positioned to adopt M2M with a new service enabler module, Converged Personal Network Service (CPNS) designed for configuring, maintaining, monitoring and updating M2M devices in the categories of intelligent buildings, fleet management, sensor equipment just to name a few. It is working with other major standard bodies on the subject including GSMA (GSM Association), UPnP (Universal Plug-n-Play), DLNA (Digital Living Network Alliance) and ETSI (European Telecommunications Standards Institute).
Reusing and overlaying of the existing OMA DM service enablers with M2M requirements fits the bill nicely. Some of the mapped functionalities include but not limited to M2M’s NIP (Network Interworking Proxy) to OMA’s CPNS (Converged Personal Network Service) and GwMO (Gateway Management Object), TOE (Telco Operator Exposure) to XDM (XML Document Management), ParlayREST (Restful bindings for Parlay X Web Services) and LOC (Location Based Services); M2M’s RAR (Reachability, Addressing and Repository) to GwMO (Gateway Managed Object) and CPNS (Converged Personal Network Service), as well as REM (Remote Entity Management) to FUMO (Firmware Update Management Object), SCOMO (Software Component Management Object), DM (Device Management) and GwMO (Gateway Management Object).
IETF (Internet Engineering Task Force) studied implications of Embedded Internet since 2007 with RFC 4919 (draft-ietf-6lowpan-problem) on 6LoWPAN (IPv6 over Low Power and Lossy Networks) and is continuing that effort in the areas of defining a M2M web transfer protocol designed for contrained networks, the Constrained Application Protocol (CoAP), Neighbor Discovery Optimization, Transmission of IPv6 Packets over Low Energy access technologies e.g. Bluetooth and more. Another piece of important work is on IPv6 Routing for Low power and Lossy Networks.
PTCRB as a global organization created by Mobile Network Operators to provide an independent evaluation process where GERAN, UTRAN and E-TRAN device type Certification can take place has added M2M devices to its service portfolio.
Along with DLMS (Device Language Message Specifications), a lightweight interpretive and embeddable scripting language Lua is especially suited for rapid prototyping for M2M devices and is becoming an M2M scripting language of choice.
The latest indication of M2M being the next if not the current Killer-App comes from the announcement of the forming of an M2M Industry Working Group led by Sierra Wireless, Eclipse Foundation, IBM and Eurotech to provide open source tools for M2M.
Explorations into how M2M relates to Cognitive Radio, SON (Self Organizing Network) and TV White Space are yet some of the many pieces to the seamless connectivity and autonomous computing puzzle.
Role of the M2M operator
M2M network operators (MNOs), M2M virtual network operators (MVNOs) and Application Service Providers (ASPs) are anticipating explosive growth of the M2M market and from it a major revenue source. MNO partnerships with carriers and software vendors to provide a complete end-to-end solution for M2M customers allow early market entry in building a customer base that is more often committed to a longer term relationship with their M2M service providers than mobile phone customers. M2M customer presents relatively lower churn, lower cost to maintain and lower profit margin than the mobile phone subscription business. This calls for a new business model that can be scaled up quickly in density and application types vertically from different industries.
The primary component of operator’s M2M platform is the M2M server offering M2M Service Capabilities to 3rd party M2M application providers via M2M Application API, which expedites application development and facilitates application interoperability.
M2M requires specific customer support for areas that current MNOs may not necessarily have expertise in e.g. truck tracking devices for fleet management, telematics, intelligent buildings covered by surveillance cameras or medical monitoring devices. It would be a CAPEX for M2M operators to acquire this expertise as new applications and new device types are being added to their support offerings.
To be competitive and be able to differentiate one self, MNOs have to ensure that their network can function conducive to M2M runtime requirements i.e. network optimized for M2M operations. Being able to maintain connectivity for a large number of M2M devices and to handle big burst of a huge number of small packet data transmissions in turn triggering certain actions from each and all devices simultaneously can tax the system and may require special load balancing strategies as a counter measure.