CC BY
73
Machine-to-Machine Communications: the view from Russia
Manfred Schneps-Schneppe, Dmitry Namiot
Abstract— The paper describes the current state on M2M communications and targets mostly Smart Metering Communication Mandate and Open API from ETSI. We provide a description for the current state of this API as well as propose some extensions we are working on. Our proposals are oriented to more tight integration of M2M API and modern web development tools and approaches. Also this paper outlines some practical systems being implemented locally (Russia, Latvia) and suggests the prospect directions for the joint projects in M2M area.
Keywords— ETSI, M2M, Open Metering, Smart Home
I. INTRODUCTION
In 2009, US’s administration takes the attention to the energy efficiency as a national task: namely: to smart grid problems [1]. The biggest roadblock to the adoption of smart grid technology by the electric industry for years has been the absence of interoperability standards. The array of proprietary technologies is a veritable minefield for firms looking to make multi-million dollar investment decisions on technology that could become obsolete.
Gartner reportedly expects more than 150 million smart meters to be installed worldwide within five years, half in North America. While analog chip companies in particular seemed positioned to profit, sales of ancillary products such as digital thermostats could double the economic opportunity, according to Texas Instruments.
The National Institute of Standards and Technology highlights 31 standards with "relevance" to smart-grid development. Central to this report [2] is cyber-security. In 2011, NIST publishes six new smart grid standards which cover: Internet protocol, Energy usage information, Smart meter upgrades, etc.
The Russian answer to this US initiative had followed immediately. On 23d November 2009, the Law “On energy saving and energy efficiency approving” was issued. By 2020 Russia's energy intensity should be reduced by 40%. Russia should aggressively install water, gas, heat and electricity meters. This program provides exceptionally favorable conditions for the revival of domestic instrument. The major weakness here is the lack of Russian standards.
M. Schneps-Schneppe is with the Ventspils International Radio Astronomy Centre, Ventspils University College, Ventspils, Latvia (e-mail: manfreds.sneps@gmail.com).
D. Namiot is with the Faculty of Computational Mathematics and Cybernetics Lomonosov Moscow State University, Moscow, Russia (email: dnamiot@gmail.com).
The rest of the paper is organized as follows. Sections 2 and 3 contain an analysis of M2M API standardization activities. In Section 4 we discuss automated building software issues. ETSI. In Section 5 we consider Open Metering System specification, which is based on M-bus protocol. Section 6 is devoted to Emergency
Communications requirements.
II. Smart metering standardization mandate
Considering M2M communications as a central point of Future Internet, European commission creates standardization mandate M/441 [3]. The mandate M/441, issued on 12th March 2009 to CEN, CENELEC and ETSI, is a major development in shaping the future European standards for smart metering and Advanced Metering Infrastructures. The general objective of the mandate is to ensure European standards that will enable interoperability of utility meters (water, gas, electricity, heat), which can then improve the means by which customers’ awareness of actual consumption can be raised in order to allow timely adaptation to their demands. In this report cooling has been considered as the same time as heating. There are about 110 applicable technical standards available today which cover parts of a Smart Metering application. No standard covers the full application range.
In order to achieve full interoperability, as requested by Mandate M/441, and with the OSI model as a reference, open interface standards must be defined for all layers of the communications protocol stack that reside on the meter, both upstream and downstream. Communications standardization does not mean to define meters, devices or software systems itself, but to make interfaces, messages and workflows interoperable (Figure 1). The mandate is centered on the interoperability of smart metering and communications architecture to support smart meters taking into account four interfaces:
E - Electricity meter communications,
M - Non-electricity meter communications,
H - Display and Home automation and G - interface to PSTN networks, public mobile networks, DSL or broadband TV communication lines.
Interactors of M2M remote gateways are electricity meters, non-electricity meters (generally battery powered) or home automation and customer information systems. ETSI’s standardization process started three years ago, and now there is an agreement on high-level system architecture as well as the requisite service capabilities [4]. What relates to interfaces E, M, and H, the scope of Mandate M/441 includes the interoperability of smart devices only; the
Fig. 1. M2M interfaces.
search for the unique interface is not considered.
Interface standards comprise three main elements:
- lower protocol layer standards, generally comprising the physical and data link layers standards
- higher layer standards, generally comprising the network, transport and applications layer standards as required
- data model standards.
III. The current state of M2M standards
Let us start from the basic moments. Right now market players are offering own standards for M2M architecture. As per ETSI, M2M architecture includes three layers [5]:
- M2M device domain
- Network domain
- Application domain
There is a dedicated Technical Committee for developing standards on M2M communications [6].
ETSI TR 102 691 is probably the most elaborated document in ETSI’s suite. It describes the following requirement areas to M2M applications:
Management - specifies requirements related to the management modes (malfunction detection, configuration, accounting, etc.).
Functional requirements for M2M services - describes functionalities-related requirements for M2M (data collection & reporting, remote control operations, etc.).
Security - covers the requirements for M2M device authentication, data integrity, privacy, etc.
Naming, numbering and addressing - provides the requirements relating to naming, numbering and addressing schemes specific to M2M.
Note that such a division by our opinion is one of the weakest points in the whole ETSI approach [7]. Rather than create some unified approach with the minimal basic (what is usually good for the development), ETSI approach potentially leads to the huge set different APIs. We saw the similar approach in Parlay for example. As seems to us this approach could not be welcomed by developers.
ETSI is not the only source for the standardization in M2M area. The biggest alternative source is Open Mobile Alliance (OMA) [8] that develops mobile service enabler specifications. OMA drives service enabler architectures and open enabler interfaces that are independent of the underlying wireless networks and platforms. An OMA
Enabler is a management object designated for a particular purpose. It is defined in a specification and is published by the Open Mobile Alliance as a set of requirements documents, architecture documents, technical specifications and test specifications. Examples of enablers would be: a download enabler, a browsing enabler, a messaging enabler, a location enabler, etc. Data service enablers from OMA should work across devices, service providers, operators, networks, and geographies. You can see a more detailed comparison in our previous article [9], for example.
As there are several OMA standards that map into the ETSI M2M framework, a link has been established between the two standardization bodies in order to provide associations between ETSI M2M Service Capabilities and OMA Supporting Enablers [8]. Specifically, the expertise of OMA in abstract, protocol-independent APIs creation, as well as the creation of APIs protocol bindings (i.e. REST, SOAP) and especially the expertise of OMA in RESTful APIs is expected to complement the standardization activities of ETSI in the field of M2M communications. Additionally, OMA has identified areas where further standardization will enhance support for generic M2M implementations, i.e. device management, network APIs addressing M2M service capabilities, location services for mobile M2M applications [9].
Our own proposal for ETSI extensions targets Web Intents usage as a main communication mechanism [10,11]. Web Intents could be used as add-on for the more traditional REST approach. The main goal for our suggestions is the simplifying of development phases for M2M applications. This proposal can substantially reduce development costs and accelerate the time to market. The key advantages are JSON versus XML usage for data transfer, asynchronous communications, integrated calls, client side deployment for M2M applications and the ability to bypass sandbox restrictions.
IV. Automated building software issues
Open standards, open protocols, open architecture and open web are some of the key concepts in the Building Automation System (BAS) industry, but there are some misunderstandings. Protocols are interoperable, not interchangeable. Many people believe that open implies that if a controller fails from one vendor, they can replace it with another vendor. It is not as simple as plug and play. Programming is proprietary: The open protocol standards (e.g., BACnet or LonWorks) do not define a standard programming language or rules to program an application controller. Programs are not visible to end user. In the most cases, the manufacturer and/or the system integrator will not allow the facility manager to view the programs.
The OpenAPI relates to several interfaces of M2M architecture (Figure 2):
Interface 1 is the interface between the platform and external service providers running their services remotely.
Interface 2 is the interface between the platform and the customer applying the features offered by the platform. The interface may be supported on leased lines or on the Internet,
and accessed conveniently via a standard web browser.
Interface 3 is a set of interfaces supporting additional functionality (installation support, access to remote databases, remote operation and management of platform, etc.).
Interface 4 is the interface to the backbone IP network.
Interface 5 is the application level interface between the service platform and Connected Objects on the device side.
Interface 6 is proprietary and/or application specific (non-IP based and requires gateway).
Interface 7 may be identical to Interface 4 (IP based, interconnected through routers).
We have here two key tasks: 1) to reduce the great number of existing M2M device protocols (Interfaces 6 and 7) and 2) to simplify M2M application service developing work by the standardized API and the proper middleware (Interfaces 1 and 2).
The goals for M2M middleware are obvious. M2M middleware helps us with heterogeneity of M2M applications. Heterogeneity of service protocols inhibits the interoperation among smart objects using different service protocols and/or API’s. We assume that service protocols and API’s are known in advance. This assumption prevents existing works from being applied to situations where a user wants to spontaneously configure her smart objects to interoperate with smart objects found nearby [12]. M2M API provides the abstraction layer necessary to implement interactions between devices uniformly. The M2M API provides the means for the device to expose its capabilities and the services it may offer, so that remote machines may utilize them. Consequently, such an API is necessary to enable proactive and transparent communication of devices, in order to invoke actions in M2M devices and receive the relating responses as well as the simplified management of resources.
V. Open metering systems : from Germany to Russia
Leading meter manufacturers and technology providers in Europe have joined the effort to create the new open standard for metering based on m-bus protocol (Figure 3). Tables are numbered with Roman numerals.
The new Open Metering System (OMS) specification has been developed to meet a demand for interoperable solutions for meter reading, and a unified approach for the different media (electricity, gas, heat and water). In 2009, the three-part specification was released [13].
The specification defines a Multi Utility Communication (MuC) device, which acts like an intelligent data concentrator between the automated meter management (AMM) back office system (for billing or other purposes), and the metering and actuator devices.
Fig. 3. M-Bus system
The MuC can be integrated into a meter (typically an electricity meter) or it can be a standalone unit (Figure 4). The primary communication is between meters and the MuC. A lot of effort has been put into unifying this part to support all media, as well as actuators and displays. The secondary communication is defined as an extension of the primary communication using simple repeaters or a multihop routing protocol. The tertiary communication is between the MuC and the back office AMM system.
Fig. 2. M2M architecture
Fig. 4. A simplified metering system
The new specification is based on established norms and standards where it has been possible. The tertiary communication is solely based on TCP/IP, and the primary communication is based on the M-Bus standard (wired or
wireless), EN 13757.
The specified data format is OBIS (Object Identification System) coded values. The wired/Wireless M-Bus link to the meter supports both OBIS (not shown), as well as the M-Bus application data format (EN 13757-3). The MUC will translate the M-Bus application data format into OBIS before it is sent to the AMM on the operation data channel. A service data channel from the MUC to the AMM supports M-Bus formatted data as well.
The first local implementation for the similar service was performed by joint Latvian-Russian group [14]. It was home gateway prototype for multi-tenant house (Figure 5). The Open Source PBX Asterisk plays a role of telephone exchange for connections between sensors, analog and soft-phones, and GSM modem. A new component (proxy) was developed and integrated into the Asterisk platform [15].
of groups that are currently poorly served by 911 systems, including those with disabilities, residents and travelers in rural areas, and workers and residents in high-rise buildings. Therefore, the functional components have been tested. They include the ability to send and receive voice, video, text, and data, and improvements to 911 access for deaf/hearing-impaired.
To fulfill Service 911 requirements, we need some omputing appliance similar to the Sagem Orange Tabbee (Figure 6).
Fig. 5. Home gateway
The main functionality of the proxy is to translate telecommunication calls into HTTP requests to external web services. Telecommunication services are located separately from the PBX, while the information they receive from Asterisk is presented as a HTTP-request. Upon receiving necessary parameters, such as (calling/called number) a web service produces and forwards its instructions to the proxy. The latter receives and translates them into Asterisk instructions. The main idea is to integrate the traditional telecom services and M2M applications. For example, use an ordinary call and text to speech services for getting measurements info from M2M system.
VI. Emergency communication service and Russian “Social Socket”
Emergency Telecommunications and Public Safety are areas requiring considerable standardization activity. Existing infrastructures and services have been shown to be inadequate when faced with widespread disruption due to natural disasters and other emergency situations. ETSI is heavily committed in this area and is co-operating with other organizations around the globe [16]. ETSI pays now a great attention to the security aspects of emergency communications. Today’s 911 system in the U.S. is built on an infrastructure of analog technology that does not support many of the features that most Americans expect are part of an emergency response [17]. Only a digitized system with seamless IP-based connectivity can fully support the needs
Fig. 6. Sagem Orange
The Russia’s analogue for this is so called “social socket” rather popular in Moscow. Social socket contains a speaker warning, emergency button and provides access to additional social services and low-speed Internet. It has no less than eight TV channels and three radio channels wire Device is integrated into local emergency service "112": each "social outlet" has an identification number, so after a call for the service the caller could be identified (Figure 7).
— Eight TV channels
Fig. 7. Social socket
For delivery to the apartments planned volume of information (alerts, emergency button, internet, eight television channels and three radio channels wired) the proposed pilot project plans to bring four pairs of wires (instead of the now defunct one pair). But this approach is contrary to the latest international standards of building home networks. According to recommendations of the ITU series G.hn, all this information, plus telephone service to be delivered over a single twisted pair of copper wires. As the prospect services for such kind of devices we propose telecom-based integration (e.g. ADSL line). By our opinion any call-based services (e.g. call to perform actions, call to perform monitoring, etc.) could be welcomed by the users. They could be much simple (especially for aged people), comparing with internet-based access from smart phones.
VII. Conclusion The progress in M2M communications area depends on
“Modernization of Russian economy” plan. The plan was first set out in the framework of the St. Petersburg dialogue between Russia and Germany in 2008, and has been ever more central in the EU-Russian agenda since 2010. At the November 2009 EU-Russia summit, the final EU-Russian Joint Statement on the Partnership for Modernization was signed. The corresponding memorandum with the US is focused on the commercialization of the results of research in Skolkovo - a controversial Russian techno-park.
As a case study in the framework of Partnership for Modernization, a Russian-Latvian co-operative project could be mentioned. The goal is to develop Building Automation System especially for heat consumption measuring in multitenant houses with so called vertical one-tube heating system. The accuracy of temperature measurements is up to 0.1Co. Data are collected by wireless M-Bus protocol.
References
[1] Obama administration gets wise to smart grid's big hurdle April 6, 2009 http://www.smartgridtoday.com.
[2] Obama Admin Releases Initial 'Smart Grid' Standards http://www. nytimes. com/ gwire/2009/09/24/24greenwire-obama-admin-releases-initial-smart-grid-standa-98180.html.
[3] Mandate M/441 SMART METERS CO-ORDINATION GROUP (SM-CG) Technical Report on Communications V0.2 SMCG_Sec0020_DC, 2011.
[4] EURESCOM project P1957, “Open API for M2M applications”, http://www.eurescom.de/public/projects/P1900-series/P1957.
[5] “CEN, CENELEC and ETSI in the field of measuring instruments for the development of an open architecture for utility meters involving communication protocols enabling interoperability”. M/441 SMART METERS CO-ORDINATION GROUP, FINAL REPORT (Version 0.7 - 2009-12-10), CENELEC.
[6] ETSI TR 102 691 V1.1.1 (2010-05). Technical Report. “Machine-to-Machine communications (M2M); Smart Metering Use Cases”.
[7] M. Sneps-Sneppe and D. Namiot “M2M Applications and Open API: What Could Be Next?” Internet of Things, Smart Spaces, and Next Generation Networking, Lecture Notes in Computer Science Volume 7469, 2012, pp. 429-439, DOI: 10.1007/978-3-642-32686-8_40
[8] OMA http://www.openmobilealliance.org/
[9] Sneps-Sneppe, M and Namiot, D. “About M2M standards and their possible extensions”, Future Internet Communications (BCFIC), 2012 2nd Baltic Congress on, pp. 187-193 DOI: 10.1109/BCFIC.2012.6218001
[10] Y.Daradkeh, D.Namiot, and M. Sneps-Sneppe. "M2M Standards: Possible Extensions for Open API from ETSI." European Journal of Scientific Research 72.4 (2012), pp.628-637
[11] D. Namiot "Web Intents as an Extension for M2M Open API." European Journal of Scientific Research 94.3 (2013), pp. 452-462.
[12] N. Blum, I. Boldea, T. Magedanz, and T. Margaria “Service-oriented access to next generation networks: from service creation to execution” J Mobile Networks and Applications archive, Vol. 15 Issue 3, June 2010
[13] Open Metering System Specification. Vol 3. Tertiary Communication and OMS-MUC. Issue 2.0.0 / 2011-01-31.
[14] M. Sneps-Sneppe, D. Namiot, A. Maximenko, and D. Malov „Wired Smart Home: energy metering, security, and emergency issues” // International Conference on Ultra Modern Telecommunications ICUMT-2012, IEEE, Oct 2012.
[15] M Schneps-Schneppe and D Namiot “Telco Enabled Social Networking: Russian Experience”, Baltic Conference Advanced Topics in Telecommunication, Tartu, 2008, pp. 33-40
[16] Rizzo and Ch. Brookson „ETSI White Paper No. 1 Security for ICT -the Work of ETSI”
http://www.etsi.org/WebSite/document/Technologies/ETSI_WP1_Se curity_Edition_4.pdf Reviesed: Jan, 2013
[17] L. K. Moore „Emergency Communications: The Future of 911”, Congressional Research Service, 7-5700, RL34755, 2009
