sgem d132 m2m architecture for energy industry - …sgemfinalreport.fi/files/sgem_d132 m2m...

- 1 - D1.3.2: Architectural View of M2M Communication for Energy Industry

CLEEN OY Eteläranta 10, P.O. BOX 10, FI-00131 HELSINKI, FINLAND www.cleen.fi

D1.3.2: Architectural View of M2M Communication for Energy Industry

Revision History

Edition Date Status Editor

1.0 29.09.2011 First approved version Atte Länsisalmi

Abstract This document discusses the Machine to Machine (M2M) communication technologies that have been developed mainly by the ICT Industry, and considers how they can be used in the Energy Industry. M2M has received a lot of interest and it is already a fast growing business. Along with the mostly proprietary solutions that are in use today, many standardization organizations are involved, and work on creating solutions that extent their technologies for the use of M2M. M2M Standardization in the ICT arena is proceeding in two areas. First, the communication technologies are being enhanced to support the specific communication requirements of machine operated devices, and secondly, general M2M service platforms are being developed to support many M2M application domains or verticals. The most prominent European standardization activities for M2M are those done in 3GPP for enhancing their cellular 3G and 4G networks to support M2M communication, and ETSI’s work on M2M a service platform that can support various verticals. The Energy Industry, with Smart Metering being one of the key use cases, is one important vertical that is considered in this work as a reference case. We show in this document how the ETSI and 3GPP technologies can work together as an end to end M2M solution, and how that can be used in the Energy Industry. We find that that Smart Metering use case can be supported by the combination of ETSI and 3GPP standards, and the architectures align together quite well.



D1.3.2: Architectural View of M2M Communication for Energy Industry

Table of Contents Revision History .................................. .......................................................................................... 1

Abstract .......................................... ............................................................................................... 1

Table of Contents ................................. ......................................................................................... 2

1 Preface ........................................... ......................................................................................... 4

2 Abbreviations ..................................... .................................................................................... 4

3 Introduction ...................................... ...................................................................................... 7

4 M2M Communication Concept ......................... ..................................................................... 8

4.1 Introduction ......................................................................................................................... 8

4.2 M2M Communication Topology ........................................................................................... 9

4.3 M2M Verticals ..................................................................................................................... 9

4.4 M2M Optimized Communication Features ........................................................................ 11

4.4.1 M2M Service Enablement and Managed Connectivity ................................................ 11

4.4.2 M2M Optimizations in Communication Networks ........................................................ 12

4.4.3 Security ...................................................................................................................... 13

5 M2M Standardization ............................... ............................................................................ 14

5.1 Introduction ....................................................................................................................... 14

5.2 ETSI TC M2M ................................................................................................................... 14

5.2.1 Introduction ................................................................................................................ 14

5.2.2 ETSI M2M use cases ................................................................................................. 16

5.2.3 ETSI M2M Requirements ........................................................................................... 17

5.2.4 ETSI M2M Functional Architecture ............................................................................. 17

5.2.5 M2M Service Capabilities Platform, Interfaces ............................................................ 18

5.2.6 Device Management ................................................................................................... 21

5.3 3GPP ................................................................................................................................ 21

5.3.1 Initial phases and scope of 3GPP M2M work.............................................................. 21

5.3.2 3GPP MTC use cases and applications - Stage 1 ...................................................... 22

5.3.3 3GPP MTC architecture framework – Stage 2 ............................................................ 25

5.3.4 About security ............................................................................................................. 27

5.4 GSMA ............................................................................................................................... 27

5.5 IETF .................................................................................................................................. 28

5.6 OMA ................................................................................................................................. 30

5.7 Other standardization activities ......................................................................................... 31

5.8 Proposed M2M Partnership Project................................................................................... 31

6 M2M and Smart Grid Use Cases ...................... ................................................................... 33

6.1 Introduction ....................................................................................................................... 33

6.2 ETSI SG use cases with M2M ........................................................................................... 33

6.2.1 ETSI Report on Smart Metering Use Cases ............................................................... 33

6.2.2 ETSI Report on Smart Grid Impacts on M2M.............................................................. 36

6.2.3 Other Use Cases in ETSI that relate to Smart Grid ..................................................... 36

6.3 M2M Standards Support Smart Grid ................................................................................. 36



7 M2M Architectural Alternatives for Smart Grid ..... ............................................................. 37

7.1 Introduction ....................................................................................................................... 37

7.2 M2M Using ETSI and 3GPP technologies ......................................................................... 37

7.2.1 Introduction ................................................................................................................ 37

7.2.2 Basic M2M configuration ............................................................................................ 38

7.2.3 M2M Configuration using M2M Gateways .................................................................. 39

7.3 Other Solution Alternatives ............................................................................................... 40

7.4 Example Use Case - M2M for Smart Metering .................................................................. 41

8 Conclusions ....................................... .................................................................................. 44

9 References ........................................ ................................................................................... 45



1 Preface This report was written as a part of the Finnish national research project "Smart Grid and Energy Market" SGEM II. It received funding support from Tekes – Finnish Funding Agency for Technology and Innovation and the project partners. The report is as part of the SGEM WP1 task 1.3. Industry Landscape (ILS) project that concentrates on analyzing and reporting the Smart Grid standardization fora. The information has been gathered by studying the available draft and completed standards, meeting reports from the standardization meetings, as well as interviewing the subject matter experts in Nokia Siemens Network. The main part of the documentation work was done by Markku Tuohino and Atte Länsisalmi. We would like to thank our colleagues who supported us in this work, especially Juergen Heiles, Mehmet Ersue, Michael Rooke and Timo Knuutila.

2 Abbreviations 3G Third Generation Mobile Network Technologies, such as WCDMA 3GPP Third Generation Partnership Project (evolution of GSM based technologies) 3GPP2 Third Generation Partnership Project 2 (evolution of CDMA based technologies) 4G Fourth Generation Mobile Network Technologies, such as LTE 6LoWPAN IPv6 over Low-Power Wireless Personal Area Network AdHoc Temporary, Spontaneous or Short Termed APAC Asia - Pacific region API Application Programming Interface ARIB Association of Radio Industries and Businesses, Japanese Radio Standardization

forum ANSI American National Standards Institute ATIS Alliance for Telecommunications Industry Solutions, ANSI accredited

standardization forum BBF BroadBand Forum CCSA China Communications Standards Association cdma2000 marketing name for 3G Radio Technology developed by 3GPP2 CEN European Committee for Standardization CENELEC European Committee for Electrotechnical Standardization CoAP Constrained Application Protocol CoRE Constrained RESTful Environments COSEM Companion Specification for Energy Metering CPNS Converged Personal Network Services CSP Communication Service Provider DER Distributed Energy Resources dIa Interface between Device and Gateway Applications and M2M Service Capabilities



DLMS Device Language Message Specification DM Device Management DR Demand Response DSL Digital Subscriber Line E-UTRAN Evolved-UTRAN (3,5G RAN defined in 3GPP) E.164 Telephone Numbering standard by ITU-T EC European Commission EDGE Enhanced Data rates for GSM Evolution EMAN Energy Management EMP Embedded Mobile Program ePDG Evolved Packet Data Gateway ETSI European Telecommunications Standards Institute EU European Union GERAN GSM EDGE Radio Access Network (2G and 2,5G RANs defined by 3GPP) GGSN Gateway GPRS Support Node GSI Global Standards Initiative GSM Global Specification for Mobile communications GSMA GSM Association, Association for Mobile Network Operators using 3GPP

Technologies GW Gateway GwMO Gateway Management Object ICT Information and Communication Technology IEC International Electrotechnical Commission IED Intelligent Electronic Device IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IoT Internet of Things IMEISV International Mobile Equipment Identity, Software Version IMS IP Multimedia Services sub-system HAN Home Area Network HLR Home Location Register HSS Home Subscriber Server IP Internet Protocol IPv4 IP version 4 IPv6 IP version 6 IP-SM-GW IP-Short Message service-Gateway ITU International Telecommunication Union ITU-T International Telecommunication Union - Telecommunication Standardization

Sector LAN Local Area Network LLN Low power and Lossy network



LTE Long Term Evolution, 4G mobile communication system defined by 3GPP LTE-Uu LTE radio interface M2M Machine to Machine MDMS Meter Data Management System mIa Interface between M2M Service Capabilities in Device or Network and Application

Domain mId Interface between M2M Service Capabilities in the Device or Gateway and M2M

Service Capabilities in the Network and Application domain MME Mobile Management Entity MTC Machine Type Communications MTC-IWF MTC Interworking Function MTCi interface an entity outside the 3GPP system uses to communicate with UEs used

for MTC via 3GPP bearer services MTCsp interface an entity outside the 3GPP system uses to communicate with the MTC-

IWF related control plane signaling MTCsms interface an entity outside the 3GPP system uses to communicate with UEs used

for MTC via SMS NGN Next Generation Network NIST National Institute of Standards and Technology OMA Open Mobile Alliance PAM Priority Alarm Message PAN Personal Area Network PGW Packet data network Gateway PLC Power Line Communication PLMN Public Land Mobile Network PN Personal Network PoS Point of Sale PON Passive Optical Network PP Partnership Project PS Packet Switched QoS Quality of Service RAN Radio Access Network RFC Request For Comments Roll Routing Over Low power and Lossy networks SC Service Capability SDO Standards Development Organization SG Smart Grid SGIP Smart Grid Interoperability Panel SGSN Serving GPRS Support Node SIMTC System Improvement for Machine Type Communications SMS Short Message Service



SMS-SC SMS Service Center SO Smart Object TC Technical Committee TIA Telecommunications Industry Association TR Technical Report TTA Telecommunications Technology Association, Korean Telecommunication

Standardization Organization TTC Telecommunication Technology Committee, Japanese Telecommunication

Standardization Organization TS Technical Specification UE User Equipment UICC Universal Integrated Circuit Card Um GERAN radio interface Uu UMTS radio interface USN Ubiquitous Sensor Network UTRAN Universal Terrestrial Radio Access Network (3G RAN defined in 3GPP) WAN Wide Area Network WG Working Group WiFi Brand Certification name for IEEE 802.11 based WLAN WiMAX Worldwide Inter-operability for Microwave Access WLAN Wireless Local Area Network xDSL family of Digital Subscriber Line technologies such as ADSL (Asymmetric DSL) ZigBee A specification of a suite of communication protocols for WPANs.

3 Introduction Communication between different elements of the Smart Grid is the basis of most, if not all Smart Grid functions. The intelligence to be built into smarter grids focuses on making intelligent decisions about grid operation and electricity usage and generation based on real-time or near real-time information from all around the grid. This decision making, and the control operations thereof, may itself be done at geographically distributed locations, it may be done either in one or more centralized control centers, or it may be fully decentralized. Therefore the intelligence of the grid will rely on information being made available where it is needed via various ways of communication. The vast majority of this communication takes place between automated devices that are not directly operated by humans, such as Smart Meters and Intelligent Electronic Devices (IED) that have inbuilt communication logic. In general terms, we are talking about communication between machines. Similar need for machine based communication is also identified in many other industries. The use of fully automated communication devices is rising e.g. in transportation, for vending machines and for many health and consumer electronics applications. The ICT industry calls this concept with general term Machine to Machine Communication (M2M), and in the recent years, various aspects of it have been addressed in wireless and wired communication standards. All of the most prominent standardization organizations have looked into how their technologies can be improved to better accommodate M2M communication requirements, and we have also seen the start of



some completely new activities such as in ETSI and TIA that have started work for defining a common service platform for M2M. Typically the work in all of these forums has started by studying the requirements of each of the expected M2M verticals, such as Smart Grid, and a set of generalized requirements has been extracted from them. These requirements have been used to drive technical work addressing such items as intermittently communicating devices, chatty devices, low power devices, low data rate devices, simple devices, low mobility devices, and the general problems caused by the explosion of the number of M2M devices for address space and provisioning, etc. To achieve the benefits of scale in all levels, the M2M communication standards have been kept general, and are not specifying the application for any of the verticals. Instead standardized interfaces (APIs) and service enablers are defined which will be used by the applications in order to make use of the M2M services. Smart Grid is just one potential application realized on top of the M2M Communication technologies. Since there are many M2M standards, and requirements of a given Smart Grid application might be very specific, questions arise on how M2M can be used for Smart Grid, and how good the fit is. This report studies those aspects, and outlines a way on how M2M Communication can be used for the Smart Grid. In particular, we outline the M2M Communication architecture that could be used for some of the most interesting Smart Grid use cases. This study is made with focus on standards and technologies only, and aspects arising from the ownership of the communication networks and M2M service platforms are not considered. In other words, it is not considered whether the communication network is owned by the utility or by a Communication Service Provider (CSP). Also regional regulatory limitations and availability of radio frequencies for wireless communication are outside of the scope.

4 M2M Communication Concept

4.1 Introduction Machine to Machine (M2M) refers to wired or wireless communication to and from telecommunication capable devices, where the communication capabilities are not directly operated by a human, but instead, the communication logic is automatic, and programmed into the machine itself. In other words, M2M devices are some sort of automated machines, such as sensors, actors, Smart Meters or vending machines that communicate based on the programmed logic and triggers such as sensor input, rather than based on human users initiation. In several cases, communication is the addition to existing machines, and M2M advances the traditional functions of those machines in this sense. This can often be made possible by simply adding a separate communication module, such as an embedded cellular communication module, to the existing design of a machine and adding communication to its programmed logic, but also more integrated solutions are likely to emerge. The term M2M is most commonly associated with methods and technologies developed in the telecommunication industry to address the specific communication needs of machine devices. In data and IP communication industry the terms Smart Objects and Internet of Things are used to refer to very similar concepts. In this document we use the term M2M generally to refer to all of these technologies. In many cases M2M technologies are developed by enhancing the existing standards and solutions that were originally designed e.g. for human oriented communication like voice communication or for traditional IP networking, but also some original work is being done for just this purpose. The advance of communication technologies e.g. miniaturization of embedded communication modules, more affordable devices and communication services, and the demand for advanced and



innovative features from end users, are all drivers in many industries to use M2M more and more in their solutions. The communication industry sees this as an opportunity to expand their business, as the number of end devices is projected to raise manifold to that of today.

4.2 M2M Communication Topology Some M2M technologies address the scenario where the communication takes place locally between two or more devices, but in the most common scenario the communication happens between devices that are located remotely in the field, and a centrally located server. A variant of this topology also includes an M2M gateway, which concentrates the traffic between many devices and the centrally located server. The gateway may also translate protocols as needed. The M2M communication topology is shown in Figure 1.

LocalNetwork

M2MGW

Wide AreaNetwork

M2M Devices

M2MServer

LocalNetwork

Figure 1: M2M Communication Topology

The main M2M communication paradigm is that a remotely located device collects some data, such as temperature or meter reading, and that is made available to a central location for further analysis. In the reverse direction the device may receive commands from the central server e.g. for updating its operation logic, running its peripherals, or for managing its software and firmware. As said, the role of the M2M gateway is to concentrate traffic to and from many devices within the Local Area Network (LAN), or perhaps Personal Area Network (PAN) to one shared Wide Area Network (WAN) connection and to translate between different protocols used in the WAN and the LAN/PAN. In this case the M2M application does not need to know of the existence of a M2M Gateway, since it logically connects to each device directly.

4.3 M2M Verticals The term “M2M verticals” refers to the M2M usage areas. The naming and grouping of functions into M2M verticals varies in literature, but the most common grouping is based on the different industries where M2M is used. While the main scope of this document is M2M for Smart Grid, also some other examples of verticals are shown in Figure 2 and explained below. The description in the list below mainly concentrates on what kind of communication requirements each vertical has:

• Energy (Smart Grid): Electrical energy is the most prominent component of the Energy vertical, but the vertical also covers other energy types like gas. Energy is a versatile and growing area for M2M, where many different use cases would potentially benefit from M2M. Smart Metering has already been implemented using cellular M2M, and many other Smart



Grid use cases, such as Demand Response (DR), and Management of Distributed Energy Resources (DER) are envisioned to piggy back on the communication links used for Smart Metering. Some Grid Management and Control use cases have also been planned for M2M. Electric Vehicle charging is another example of a Smart Grid use case, which overlaps partly with the logistics and transportation vertical (see below) and which, as some other use cases, contains collecting information for billing the end user as an integral part of the use case. The Energy vertical can be split into many different types of M2M use cases, and it is not possible to completely generalize the communication requirements. Most of the equipment is stationary, so there is no requirement for mobility, and in most cases the amount of data to be sent is small. In many cases, like the Smart Metering, the communication link is used often, but for very short periods of time. Time critical Grid Management use cases like Tele Protection require very low latency and high availability.

• Logistics & Transportation: Some example applications in this vertical are navigation, road tool collection, vehicle and goods tracking and other logistics handling systems, and vehicle diagnostics. Majority of these applications require only small data volumes to be sent, and delay requirements are not tight, while the frequency of communication can be still be high. In-vehicle entertainment systems are another type of example, where data volume can be expected to be high.

• Home: The home appliances, consumer electronic devices and devices related to home automation are likely use cases for M2M communication. In most of these applications the data volumes are small and the time sensitivity is on low to intermediate level. On the other end of the spectrum are the home entertainment systems, which are likely to require higher data volumes for background downloads and online streaming.

• Security: Security applications utilizing M2M include e.g. remote surveillance, alarm systems, access control, and tracking of devices and humans or animals. One common denominator for these applications is that they are critical, and require high availability. Surveillance cameras also require high bandwidth.

• Payment: M2M services can be used in Payment applications to replace the usage of cash or direct usage of credit card at the point of sale. With M2M the transaction can be communicated for post pay or deducing an account. Examples of payment applications range from road tolls, to vending machines and other types of automated cashiers and mobile payment methods. Some payment applications require relatively high availability and small delay, e.g. when the customer is at the cashier, but others are more delay tolerant, when charging or account deduction can take place later, e.g. in a batch operation. Either way, high reliability is always required.

• Health: This vertical includes many health monitoring applications, and also care delivery solutions and telemedicine. The point is to allow the health care personnel to stay at their offices, and the clients of their services may stay home or continue their life without location restriction. Another branch of this vertical includes equipment in hospital and lab environments. Some of the most advanced monitoring and care delivery applications may require sending video, which requires high data volumes, but most health applications require reliable delivery of small data volumes with time sensitivity ranging from intermediate to high.



Energy:Smart Metering

Energy:Grid Management & Control

Energy:Renewables Management

Connected Homes

Payment

Transportation & Logistics

Health

Security

Energy:Smart Metering

Energy:Grid Management & Control

Energy:Renewables Management

Connected Homes

Payment

Transportation & Logistics

Health

Security

Figure 2: M2M Verticals and their Communication Ass ociations

4.4 M2M Optimized Communication Features M2M communication, as the definition here stands, has already been in use for quite some time. For example, the energy industry is already using cellular communication in various Smart Metering deployments and the operation of the transmission networks is widely automated. The way things are done today is however not optimized to this purpose since the special nature of M2M communication is not taken into account. In recent years, the ICT industry has been addressing this topic in various standardization activities, as well as in the solutions brought to the market. This section highlights some of the key aspects of this work. Further details of the key standardization activities are given in Section 0.

4.4.1 M2M Service Enablement and Managed Connectivi ty Looking at M2M from the Communication Service Provider’s (CSP) point of view, one of the first considerations is that since so many industries are using M2M on traditional communication services, each using their own solutions, it is necessary to start combining the M2M capabilities instead of continuing to create specific solutions. Figure 2 highlighted the logical connections between devices in the field and a central repository or server in several example verticals, and it can be seen that the communication paradigm is exactly the same in all of them. Creating almost similar M2M capabilities independently for each vertical would waste a lot of effort, and the approach used in standardization and many M2M solutions in the market today is to offer these services with a generic M2M service platform. This approach is shown in Figure 3 below, where the layer M2M Service Enablement and Managed Connectivity represents the M2M service platform. Each vertical is seen as one or more applications on top of the common platform, and communication networks, which are used here for connectivity, are on the layer below. The M2M platform can provide services such as collecting, warehousing and processing the data from M2M devices, managing the M2M devices, monitoring usage and collecting billing information, and managing the connectivity through the communication networks.



M2M Service Enablement and Managed Connectivity

Connectivity Networks

WANconnectivitymodule(s)

Application


PAN/LANmodule

PAN/LANconnectivity

module

Application

Application


Application


PAN/LANmodule

PAN/LANconnectivity

module

Application

Application

PaymentSecurityHomeTransport & LogisticsEnergy Health

Figure 3: M2M Verticals using common M2M capabiliti es

M2M platform capabilities try to fulfill the needs of all verticals. This is achieved by analyzing the needs of the different verticals, and specifying the superset of all required features. Quite often the requirements from different verticals are almost the opposite, e.g. while a Smart Meter can be assumed to be stationary the sole purpose of a cargo truck is to be mobile to transport goods. Therefore the M2M capabilities are made available in a flexible manner, so that conflicting requirements from different verticals do not lead to performance compromises in a given usage scenario.

4.4.2 M2M Optimizations in Communication Networks While the service related logic will be part of the M2M service platform, there are also a number of developments taking place in the networks used for connectivity. One of the first things that do not require any new technological development as such is optimizing the network configuration for M2M traffic within the existing parameters. The communication networks are often very finely tuned for their current purpose, and substantial changes can lead to unwanted situations. This is especially so for cellular communication, e.g. the 3G and 4G technologies defined by 3GPP or WiMAX defined in IEEE and WiMAX Forum, where radio network planning and optimization has to



be done with care and precision. M2M devices often have different traffic profiles and mobility behavior compared to human users, and as the ratio of them compared to human users raises, this will be taken into account in the network planning and optimization. A similar transition needed to be done when the number of smart phones started to rise in relation to other users. The network optimization starts by looking into how M2M communication uses the communication network resources. Real life experience from current M2M deployments shows that sometimes the communication logic at the M2M service level initiates communication of many devices at the same time, which at the communication network layer leads to excessive signaling, even signaling storms, and surges of data transmission. An example of this situation is when a large number of devices try to update their states in the server right when power delivery resumes after an interruption, and even initially, when devices were sending alarms about the power distribution interruption. Effective handling of these types of peak load situations is a network dimensioning issue, but there are limits to how much resources can be allocated only for peak load situations. Systems will have a certain maximum capacity, and if more load is experienced, network congestion will occur. Therefore these considerations have to be taken into account also in the design of M2M applications, including not only alarm and error conditions, but also the normal operating conditions. The M2M service logic should take this into account and try to avoid such communication storms. Using random delays in the establishment of the communication, if possible, is for example such an approach. Another required improvement is optimized handling of the sheer number of M2M devices in the business processes. In many M2M verticals ordering of subscriptions and commissioning of the M2M devices will happen in batches that consist of hundreds, thousands or maybe tens of thousands of units at one time, so automation of these operations and of the further maintenance of the devices as much as possible is desired. A related topic is the addressing of M2M devices, which in many operating environments presents severe challenges to the available addressing space. In the most optimal case this is handled in coordination with the M2M service platform, and the M2M applications. GSMA which is the 3GPP operators association is one of the forums where such network operation related issues are discussed. There are many more improvements that address functions deeper in the operation of communication networks, such as those defined by 3GPP. Many of them start from the thinking that functionality can be reduced for M2M terminals, and address aspects like: simple devices that require simplified protocols, low power devices that spend most of the time in sleep mode, devices with only short range communication capability, stationary or low mobility devices, and so on. Some more work is on the way for more advanced features that relate to many devices becoming connected via M2M. These address such topics as automatic configuration for creating mesh networks between devices, creating associations between the device and server automatically by advanced routing and so on. The Internet Engineering Task Force (IETF), which defines Internet Technologies that have strong relation to the IP protocol, has activities in this space. All in all, the improvements are made based on the thinking that communication networks identify M2M devices as one or more separate classes that can be handled based on their specific needs, which again vary based on the type of device, communication network, and the vertical that is being served. More details on how these types of M2M specific communication features are being introduced to communication networks via standardization are given in chapter 0.

4.4.3 Security In today’s world it is clear that any new communication solution has to have appropriate security features right from the beginning, and security is not an add on feature. Since the M2M communication paradigm itself is not new, many security solutions are already available, and using



them is more likely than inventing new ones. The selection needs to be based on full analysis of the expected threats, and desired level of security. Security work is not limited to the M2M service capability layer only. Since communication devices have new roles as part of various types of machines, it also needs to be considered what implications this has to the existing security features of those communication systems. For example, while it can be considered that a mobile phone is physically safe in its owners care most of the time, a city traffic sensor having a cellular M2M communication module inside of it may be exposed to risks most of the time. In this case it may be much easier for some third party to steal the device, remove the Smart Card, and try to use either the communication module, or the subscription associated to the Smart Card. These aspects need to be considered within the communication technology, and cannot be solved in the M2M service capability layer only.

5 M2M Standardization

5.1 Introduction M2M is gaining rapid and significant revenue generation in mobile and fixed networks. This has also generated lively standardization activities around M2M and these activities have been ongoing both in regional as well as global standards organizations. Some of the most important SDOs (Standards Development Organizations) that have already done a lot of work in the M2M area are: 3GPP, ETSI TC M2M, IETF (IoT Internet of Things, Smart Objects) and GSMA (GSM Association). 3GPP is defining the transport layer functionality for M2M from the wireless communication point of view, using approach which keeps the solution agnostic to the application or vertical it is used for. ETSI TC defines M2M service platform layer functionality for any type of transport network (mobile, fixed, NGN, etc.), and any type of application. In IETF the term “Internet of Things” is used for the trend where a large number of devices employ communication services offered by the Internet protocols. The term “constrained environments” is used where the additional protocols and their extensions help optimize the communications and lower the computational requirements, which benefits devices that are constrained in the sense that they have simpler processors, have less power to use (e.g. battery powered), have shorter range connectivity, etc. The objective is to enhance the IP protocol suite for “smart objects” that are constrained in this way, so that the technology would be better suitable for M2M applications such as smart metering. GSMA issued the Embedded Mobile Guidelines white paper with the focus on M2M communication with 3GPP cellular systems. In the following sections the content and status of these M2M standardization activities are presented with more detail.

5.2 ETSI TC M2M

5.2.1 Introduction ETSI Technical Committee Machine-to-Machine (ETSI TC M2M) aims to provide an end-to-end view of M2M standardization so that it will enable the integration of multiple vertical M2M applications. The main goal is to overcome the current M2M market fragmentation and the intention is to reuse existing mechanisms from telecom standards such as from OMA or 3GPP. The work within ETSI started at the M2M Workshop in June 2008, and by early 2009 ETSI had created the Technical Committee M2M and established an active work program supported by many WGs. ETSI TC M2M took a system approach to M2M standardization, reusing existing solutions where these are available and focusing on filling standardization gaps. This had resulted



in a number of architectural standards already being published with a complete package of standards (known as Release 1) expected to be completed by September 2011. Currently ETSI is finalizing the Release 1 with the main focus being on use cases for Smart Metering (TR 102 691) but it will also include eHealth use cases (TR 102 732) and some others. The Service requirements (TS 102 689) derived from the use cases, and the architecture specification (TS 102 690) which is still in the draft phase, will together define the M2M platform. The architecture consists of Service Capabilities (SC), which are basic functional building blocks for building the M2M platform. Smart Metering is seen as the important showcase for M2M. The intent of the technical report on Smart Metering is to identify requirements for the TC M2M platform to allow for creation of Smart Metering and also other Smart Grid Applications that could use the communication means provided for Smart Metering. It is believed that the Service Enablers that were defined based on the work done for Smart Metering and eHealth segments will also allow the building of other services like vending machines, alarm systems etc. Technical Standards (TS) and Technical Reports (TR) for Release 1:

• TR 102 691 Machine-to-Machine communications (M2M); Smart metering use cases – approved May 2010

• TS 102 689 Machine-to-Machine communications (M2M); M2M service requirements – approved August 2010

• TS 102 690 Machine-to-Machine communications (M2M); M2M functional architecture (frozen September 2011)

• TS 102 921 Machine-to-Machine communications (M2M); mIa, dIa and mId interfaces (Freeze planned autumn 2011)

• TR 102 725 Machine to Machine Communications (M2M); M2M definitions The documents planned for next release (Release 2) contains the Smart Grid use cases and update of the requirements and functional architecture documents with the definition of the interfaces. Figure 4 presents the list of all ETSI TC M2M deliverables [M2MConsETSI].



Figure 4: ETSI TC M2M Standards and Reports

5.2.2 ETSI M2M use cases ETSI TC M2M starting point was that M2M service requirements must enable consistent and cost-effective communication for wide range of applications. Table 1Table 3 lists the ETSI M2M use cases [ETSIM2Mreq]:

Table 1: ETSI M2M Use Cases

Use Case Domain Reference/Use Case Details Smart Meter use cases TR 102 691

eHealth use cases TR 102 732

Track and Trace use cases Use case – Emergency call Use case – Fleet Management Use case – Theft Management

Monitoring use cases Use case – Metering/Prepaid delivery of utilities (water, gas, electricity) Use case – Personal/animal protection Use case – Object protection

Transaction use cases Use case – PoS Terminal (Point of Sale terminals)

Control use cases Use case –Controlling vending machines Use case – Controlling production machines Management

Compensation use cases Utility account management for prepaid



Micro compensation for sensor readings Additional areas of applicability Service capabilities and primitives example micro compensation scheme

Home Automation use cases Energy efficiency at home

City Automation use cases TR 102 897

Connected consumer use cases

TR 102 875

Automotive use cases TR 102 898

5.2.3 ETSI M2M Requirements The M2M service requirements [ETSIM2Mreq] have been defined aiming at an efficient intoned delivery of M2M services with the following clauses:

• General requirements : describes communications features necessary for the correct establishment of M2M communications.

• Management : specifies requirements related to the management modes (malfunction detection, configuration, accounting, etc.).

• Functional requirements for M2M services : describes requirements related to functionalities 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.

5.2.4 ETSI M2M Functional Architecture The M2M system Architecture includes the following key elements, [ETSIM2March]:

• M2M Device: Device capable of replying to request for data contained within those devices or capable of transmitting data autonomously.

• M2M Area Network (Device Domain): Provide connectivity between M2M Devices and M2M Gateways, e.g. personal area network.

• M2M Gateway: Uses M2M capabilities to ensure M2M Devices inter-working and interconnection to the communication network.

• M2M Communication Networks (Network Domain): Communications between the M2M Gateway(s) and M2M application(s), e.g. xDSL, LTE, WiMAX, and WLAN

• M2M Applications: Contains the middleware layer where data goes through various application services and is used by the specific business-processing engines.

Other key functionalities:

• Network Management Functions: consists of all the functions required to manage the Access, Transport and Core networks: these include Provisioning, Supervision, Fault Management, etc.



• M2M Management Functions: consists of all the functions required to manage generic functionalities of M2M Applications and M2M Service Capabilities in the Network and Applications Domain. The management of the M2M Devices and Gateways may use a specific M2M Service Capabilities.

5.2.5 M2M Service Capabilities Platform, Interfaces ETSI TC M2M functional architecture is presented as a framework for the M2M Service Capabilities (SC). M2M SCs are the atomic components of the M2M platform, and there is mandate to implement them in any specific combination. ETSI M2M functional architecture provides three normative Reference Points which provide the basis for interoperability. This is depicted in the Figure 5 [ETSIM2March].

M2M Device Domain

M2M Service Capabilities

M2M Applications

Routing function

mIa

SC1

SC5

SC7 SC3

SC2

SC4 SC6

SC8

Communication modules

M2M Applications

dIa

M2M Service

Capabilities

Core Network B

Core Network A

Core Network Connection

mId

Figure 5: M2M Service Capabilities functional archi tecture framework

Service Capabilities provide functions that can be shared by the different M2M applications. An SC can use Core Network functionalities through a set of exposed interfaces (e.g. existing interfaces specified by 3GPP, 3GPP2, ETSI TISPAN, etc.). An SC can also invoke other capabilities. Additionally, an SC can interface to one or several Core Networks. Service Capabilities may be M2M specific or they can also be generic, i.e. providing support to other than M2M applications. Below is the list of ETSI defined M2M Service Capabilities (where “x” can be replaced by N for Network, G for Gateway and D for Device depending on which node the SC is in):

• Application Enablement (xAE),

• Generic Communication (xGC),

• Reachability, Addressing and Repository (xRAR),

• Communication Selection (xCS),

• Remote Entity Management (xREM),

• Security (xSEC),



• History and Data Retention (xHDR),

• Transaction Management (xTM),

• Compensation Broker (xCB),

• Telco Operator Exposure (xTOE),

• Interworking Proxy (xIP) The Reference Points defined by ETSI are:

• mIa Reference Point: allows an application to access the M2M Service Capabilities in the Networks and Applications Domain.

• dIa Reference Point : � allows a Device Application (DA) residing in an M2M Device to access the different

M2M Service Capabilities in the same M2M Device or in an M2M Gateway; � allows a Gateway Application (GA) residing in an M2M Gateway to access the

different M2M Service Capabilities in the same M2M Gateway;

• mId Reference Point: allows M2M SCs residing in an M2M Device or M2M Gateway to communicate with the M2M Service Capabilities in the Network and Applications Domain.

The stage 3 specification of mIa, dIa, and mId Reference Points are provided in ETSI TS 102 921.

In addition to the abstract M2M functional architecture shown in Figure 5, an alternative architecture view to ETSI high level system is depicted in Figure 6 [M2MConsETSI]. This shows more clearly the M2M Server as a collection of SCs in the network side.



Figure 6: ETSI M2M Architecture

The communication in ETSI M2M reference points is based on procedures that adopt a RESTful (Representational State Transfer) architecture style. The resource is the key concept in this style, and a RESTful architecture is about the transfer of representations of uniquely addressable resources [Roy]. This style is further described in [REST] as follows:

“REST-style architectures consist of clients and servers. Clients initiate requests to servers: servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations or resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource. REST was initially described in the context of HTTP, but is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of it.”

When handling resources in a RESTful architecture, there are four basic methods - so called 'verbs' - that could be applied to resources:

• CREATE: Create child resources. • RETRIEVE: Read the content of the resource. • UPDATE: Write the content of the resource. • DELETE: Delete the resource.



In addition to these basic methods in a RESTful style, the additional verbs introduced are:

• NOTIFY: Notify about a change of a resource as a consequence a subscription creation. • EXECUTE: Execute a management command or task which is represented by a resource.

This verb could correspond to one or multiple CREATE methods or UPDATED.

The largest known deployment of a REST compliant architecture is the World Wide Web. Different M2M applications can have fundamentally different requirements for communications and connectivity characteristics. Therefore the M2M Service Class framework is specified. A M2M Service Class specifies a pre-defined set of communications and connectivity characteristics. An overview of M2M Service Class properties is provided in Table 2.

Table 2: List of M2M Service Class properties

Property Name Possible Settings Mobility No / Yes (alt.: No / Limited / Full ) Scheduling Delay Store-And-Forward / Best Effort / Real-

time Required Data Rate 10 kbps

100 kbps 1 Mbps

10 Mbps Persistence No / Yes Priority Low/Normal/High

5.2.6 Device Management Existing device management enablers are reused in ETSI M2M functional architecture to implement the xREM service capability. OMA-DM and BBF-TR069 are existing device management standards that are used in different applications today, and in Release 1, only those are considered. An M2M system may choose to implement either one or both of them. ETSI M2M specifies also a specific data model (M2M Management Objects) for ETSI-compliant M2M service configurations.

5.3 3GPP

5.3.1 Initial phases and scope of 3GPP M2M work The work in 3GPP follows a 3 stage methodology where the service requirements are defined first (stage 1), the functional architecture with the logical information flows between the network entities is defined next (stage 2) to fulfill the related service requirements, and finally the detailed protocol specifications are developed based on the logical information flows (stage 3). The standards work in 3GPP is done using release cycles where the cycle is typically 2-3 years. For example, the release 10 had been frozen (completed in essence, with only corrections allowed) in the spring 2011, and current standards work for the Release 11 is ongoing. The 3GPP activity for M2M is called Machine-Type-Communications (MTC). This work was started in 2005 with initially studies for the service requirements. The scope of the work was to identify potential requirements to facilitate improvements in M2M communication and the more efficient use of radio and network resources. Special consideration was given to the following areas:

• Charging mechanisms: Current mechanisms have been defined for the human to human telephony market. In M2M the range of network usage is different, e.g. traffic volume may



vary from few bytes once a year to a few kilobytes every minute, and these are aspects visible to charging records.

• Addressing: Limited E.164 numbering space (telephone number) and IP address space limitations (IPv4 address scarcity) have been identified to be an issue.

• Types of communication. M2M network usage may vary from only communicating very seldom and sparingly, e.g. few bytes once a year to communicating actively every minute

• Fixed location, low mobility and low activity terminals. These are maybe the most common characteristics of M2M terminals throughout the verticals.

• Handling of large numbers of subscriptions and subscriber data within the network. Provisioning thousands of users at one time as network users need optimized operation.

• Handling issues of large number of M2M subscriptions for the user of M2M services. The same company using M2M services could have tens of thousands of M2M devices, and handling the subscriptions needs automated operation.

• Impact of optimizations for security resulting from improvements for M2M. M2M devices are used and regarded very differently than mobile phones, which needs to be considered from security point of view.

5.3.2 3GPP MTC use cases and applications - Stage 1 Current 3GPP MTC standardization work aims to optimize the current mobile network to better take into account the M2M communication. The MTC service requirements are drawn by analyzing the potential M2M use cases, and explaining how the 3GPP system needs to be evolved from its current use to fulfill the needs of M2M. In practical terms this means adding some functionality required to support M2M, but also making some changes to primarily just to assure that M2M fits into the system without causing problems. Note that the 3GPP definition for the concept of “use case” is different from what is often seen in literature for Smart Grid, where the term “use case” has the view point of the end user, i.e. which function the system provides to the end user. For example, 3GPP is looking for a potentially very large number of communication terminals and to large extent, little traffic per terminal. The corresponding use cases define the required optimizations, e.g. what kind of different overload scenarios may arise and what overload control functions are needed to prevent them. Certain M2M applications and services are more tolerant and can accept a lower level of performance, whereas some services will have similar service requirements as current mobile network services. The 3GPP use case work has looked into how these requirement differences affect the 3GPP system. 3GPP MTC use cases listed below in Table 3 are informative [3GPPM2MReq]. The description outlines what type of M2M communication is in question, and explains the impact and potential changes in 3GPP system rather than the detailed characteristics of any M2M vertical.

Table 3: Informative 3GPP M2M Use Cases (Ref 3GPP 2 3.368)

Use Cases (Informative) Description

Addressing from a centralized entity Use Case

Metering devices are typically monitored and controlled by a centralized entity outside or inside the network operator system. Due to the need for centralized control, the centralized entity will inform or poll the metering device when it needs measurement information rather than the metering device autonomously sending measurements. Depending on the nature of the metering application, low latency responses are sometimes required (metering for high pressure pipelines for example). To accomplish this, the centralized entity will need to inform the metering device when it needs a measurement.



Theft /Vandalism Vulnerable MTC Application Use Case

MTC Devices are often located in remote areas and ideally are untouched after installation for many years. The remote locales make these devices more susceptible to tampering by unauthorized persons. The tampering of the MTC Device is often accompanied by damage to the metering device. The network has security mechanisms for protection for this type of activity which may not be effective for MTC Devices. The network cannot prevent it but can detect it as early as possible in order to deactivate the ME’s service and the related USIM. In addition, often theft/vandalism vulnerable MTC Devices are stationary after initial installation and activation. The location of the MTC Device can be utilized to improve the detection of theft. If a known stationary devices moves, it can be concluded that the MTC Device has been stolen and thus the account deactivated.

Time Controlled MTC Application Use Case

For some MTC applications the actual time at which communication takes place is less important, but low communication costs are extremely important. A network operator can offer low communication fees for this type of applications by allowing communication to take place during low traffic time periods only. Possibly the network operator may want to dynamically adjust these time periods based on the actual network traffic load at a specific time.

Radio Network Congestion Use Case

Radio network congestion because of mass concurrent data transmission takes place in some MTC applications. One of the typical applications is the bridge monitoring with a mass of sensors. The network should be optimized to enable a mass of MTC Devices in a particular area to transmit data almost simultaneously.

Core Network Congestion Use Case

A large number of MTC Devices can be associated with a single MTC User and these MTC Devices together are part of a MTC Group. MTC Devices in the MTC Group are scattered over the network in such a way that the data simultaneously sent by the MTC Devices in any particular cell is limited and will not cause a radio network overload. Despite this, when a high number of MTC Devices are sending/receiving data simultaneously, data congestion may occur in the mobile core network or on the link between mobile core network and MTC Server where the data traffic related to MTC Group is aggregated. Preferably, a network operator and the MTC User have means to enforce a maximum rate for the data sent/received by the MTC Group.

Signaling Network Congestion Use Case

Congestion in the signaling network is caused by a high number of MTC Devices trying almost simultaneously: either to attach to the network or to activate/modify/deactivate a connection. In a 3GPP system supporting MTC applications such an overload of the network can be caused by high numbers of metering devices becoming active almost simultaneously after a period of power outage. Also some MTC applications generate recurring data transmissions at precisely synchronous time intervals (e.g. precisely every hour or half hour). Preferably, the 3GPP system provides means to the network operator and MTC User to spread the resulting peaks in the signaling traffic.

Access Control with billing plan Use Case

In some configurations it may be necessary to restrict the access of a UICC that is dedicated to be used only with machine type modules associated with a specific billing plan. It should be possible to associate a list of UICC to a list of terminal identity such as IMEISV so that if the UICC is used in another terminal type, the access will be refused.

Extra Low Power Consumption Use Case

For high mobility case, tracking MTC devices such as animal tracking MTC devices in natural world with high mobility require extra low power consumption. For cargo tracking, the cargo with a tracking MTC device could move very fast such as on a train or lorry, it is not desired to either change its battery or replace battery during the transport period, so extra low power consumption MTC devices are also required. For low mobility case, the gas meter MTC devices must be battery powered. Extra low power consumption for gas MTC devices is much more critical than electricity meters.

Extra Low Power Consumption with Time Controlled MTC Devices Use Case

Time Controlled MTC Devices which send or receive data only at certain pre-defined periods may be operated in one or more modes that minimize power consumption.

Location Specific MTC MTC Devices are generally programmed to autonomously set up a connection to



Devices Trigger Use Case report an event. However, in some implementations it is required that MTC Devices are triggered by the M2M application e.g. by sending them a SMS. In the future millions of this type of MTC Devices will be deployed, while it may be desirable from a M2M application perspective to poll only a sub-set of the MTC Devices in a specific area. For example, during a storm a water authority wants to get status information of dike sensors in a specific area. It is then required that only sensors in that specific area are triggered.

A more efficient and scalable polling mechanism is required to trigger M2M devices based on location information provided by the application or user, to subsequently set up a data or other type of connection e.g. a SMS, PDP context to the network.

End-to-end security for roaming MTC devices

An MTC Application communicates with a large number of MTC Devices that are located globally and may or may not be mobile. Examples of such devices are mobile navigation systems and payment terminals. Connectivity for the MTC Devices is provided by a single network operator that uses its roaming agreements to connect MTC Devices that are not within range of its own network.

From the perspective of the operator of the MTC application its MTC Server and the domain of its network operator are part of a trusted domain. However, the domain of the roaming operator is not seen as part of the trusted domain. The operator of the MTC application therefore requires end-to-end security for messages exchanged between MTC application and MTC Devices. The network operator does not have control over the security features in the domain of the roaming operators. The network operator needs to satisfy the MTC application owner’s end-to-end security requirement without relying on network security alone.

3GPP also lists some MTC applications from the different M2M verticals. They are intended to be indicative of the scope of the MTC work. They are presented in Table 4 [3GPPM2MReq].

Table 4: Applications of M2M in 3GPP (Ref 3GPP 23.3 68)

Service Area MTC applications Security Surveillance systems, Backup for landline, Control of

physical access (e.g. to buildings), Car/driver security Tracking & Tracing Fleet Management, Order Management, Pay as you

drive, Asset Tracking, Navigation, Traffic information, Road tolling, Road traffic optimization/steering

Payment Point of sales, Vending machines, Gaming machines Health Monitoring vital signs, Supporting the aged or

handicapped, Web Access Telemedicine points Remote diagnostics

Remote Maintenance/Control Sensors, Lighting, Pumps, Valves, Elevator control, Vending machine control, Vehicle diagnostics

Metering Power, Gas, Water, Heating, Grid control, Industrial metering

Consumer Devices Digital photo frame, Digital camera, eBook

The requirements drawn from this analysis are further categorized as Common and Specific Service Requirements (3GPP TS 22.368). These list required functions that are made available by the system to M2M devices, i.e. these again take a more end user point of view. The Common Service Requirements include:

• MTC device triggering



• Addressing and Identifiers

• Charging requirements

• Security requirements

• Remote MTC device management The Specific Service Requirements have been defined as MTC Features, which are:

• Low Mobility

• Time Controlled

• Time Tolerant

• Packet Switched (PS) Only

• Small Data Transmissions

• Mobile Originated Only

• Infrequent Mobile Terminated

• MTC Monitoring

• Priority Alarm Message (PAM)

• Secure Connection

• Location Specific Trigger

• Network Provided Destination for Uplink Data

• Infrequent Transmission

• Group Based MTC Features The idea here is that the subscription data for MTC subscriber would identify which MTC Features are available for that subscriber, and they could be individually activated. The Common Service Requirements are available for all MTC users in a 3GPP system that properly supports M2M. 3GPP has essentially completed the stage 1 use case analysis work, and the related requirement and feature description work. These are requirements for further specification work in 3GPP, and the work is now focusing on implementing these requirements in the specifications that define how the 3GPP system works.

5.3.3 3GPP MTC architecture framework – Stage 2 The work item name for M2M in 3GPP is currently SIMTC (System Improvements for Machine-Type-Communications (Release 11, [3GPPM2Marc]). The baseline Architectural Reference Model for MTC has been defined (see Figure 7). The model depicts the end-to-end application, where between the UE (User Equipment, i.e. the device in 3GPP terminology) used for MTC and the MTC Application, uses services provided by the 3GPP system, and optionally services provided by an MTC Server. The 3GPP system provides transport and communication services (including 3GPP bearer services, IMS (IP Multimedia Services sub-system) and SMS (Short Message Service)) including various optimizations that can facilitate MTC. Figure 7 shows a UE used for MTC connecting to the 3GPP Radio Access Network (UTRAN, E-UTRAN, GERAN) via the Um/Uu/LTE-Uu interface. Connection to 3GPP network can take place also via alternative access networks, e.g. I-WLAN. At the far right, the figure shows MTC User,



which represents the user of the M2M service, e.g. an application in one of the M2M verticals. 3GPP has defined various architectural models to cover the connection in between:

• Direct Model - Direct Communication provided by the 3GPP Operator: The MTC Application connects directly to the 3GPP operator network without the use of any MTC Server;

• Indirect Model – MTC Service Provider controlled communication: The MTC Server is an entity outside of the 3GPP Operator’s domain. The MTCi, MTCsp and MTCsms interfaces are external interfaces (i.e. to a third party M2M service provider);

• Indirect Model – 3GPP Operator controlled communication: The MTC Server is an entity inside the 3GPP Operator’s domain. The MTCi, MTCsp and MTCsms are internal interfaces to the 3GPP operator’s network;

• Hybrid Model: The direct and indirect models are used simultaneously in the hybrid model e.g. connecting the user plane (actual data from the application) using the direct model and doing control plane signaling using the indirect model with the involvement of the MTC Server.

Figure 7: 3GPP Architecture baseline for Machine-Ty pe Communication

The MTC related reference points are defined as follows [3GPPM2Marc]: MTCi: It is the reference point an entity outside the 3GPP system uses to

communicate with UEs used for MTC via 3GPP bearer services/IMS. MTCsms: It is the reference point an entity outside the 3GPP system uses to

communicate with UEs used for MTC via SMS. MTCsp: It is the reference point an entity outside the 3GPP system uses to

communicate with the MTC-IWF related control plane signaling. 3GPP has outlined that the ‘MTC Application’ entities and the reference point marked as API in Figure 7 are outside of 3GPP scope. These are used as abstracts to show the end-to-end view for MTC and simplify mapping to MTC specifications of other standardization organizations. For the API, for example, ETSI M2M API (mIa) could be used here.



The MTC Server is an entity which connects to the 3GPP network to communicate with UEs used for MTC and nodes in the PLMN (Public Land Mobile Network – generic name for cellular networks). SMS-SC is the Service Center for Short Message Service, and it is used for SMS delivery as an integrated 3GPP network service. The corresponding IP based service is handled by IP-Short Message-Gateway (IP-SM-GW). The MTC-IWF is a functional entity that is drawn to the architecture for the possibility for M2M related control between 3GPP network (nodes not defined) and some nodes outside 3GPP network, but this architectural option has not been specified further. The other nodes, HLR/HSS, SGSN/MME and GGSN/PGW/ePDG are respectively the database, the control node, and the user data plane gateway element in the existing standard 3GPP packet data communication network. In stage 2 level, the main MTC functionality specified by 3GPP in Release 10 is solely focused on overload and congestion control since some networks already experienced congestion caused by M2M applications. These features include specific ways to handle the mobility, the way M2M devices access 3GPP system. These are based e.g. the defined access class of the M2M device, or the network it is connected to. The full range of MTC congestion and overload control means becomes available when terminals specifically configured for MTC are used for M2M applications. Release 10 also covers radio network specific improvements which are at final stages of error correction phase. The congestion and overload control functions affect the overall system and required considerable efforts in 3GPP. Therefore, changes needed to the architecture, and core and radio network protocols related to the other MTC features explained in section 5.3.2 have been transferred to Release 11, which is due completion in September 2012.

5.3.4 About security 3GPP has earlier studied security aspects of various functions related to M2M. These include: remote provisioning and a change of subscription for M2M equipment, definition of a trust model for remote subscription management of M2M, identification of security threats and security requirements. Candidate solutions were also presented [3GPPM2Mfsonsec]. In addition, the usage of M2M Equipment with or without the 3GPP user identity smart card (UICC - Universal Integrated Circuit Card) was reviewed from different angles including study of related threats and counter-measures.

5.4 GSMA GSMA is the trade organization for communications industry that uses 3GPP technologies. The main target is to drive growth in this industry, by bringing the industry players together to discuss the opportunities and agree on common ways to solve any obstacles. Mobile operators form the main part of GSMA membership, but equipment vendors and other industry players, such as representatives from M2M verticals are also involved in the work. GSMA is not a standard defining organization, but it produces further definitions such as white papers and recommendations that are helpful in addition to standards defined in 3GPP and other SDOs. The Embedded Mobile Program (EMP) is a three year program within GSMA, which is now on its second year. Its task is to identify things that the 3GPP industry needs to consider for M2M operation. EMP is organized so that on one hand it looks into enablers for M2M operation, such as some specific technical aspects as well as marketing and coordination activities for making M2M happen in an optimized way in the marketplace. On the second hand, it looks into selected four market segments or verticals of M2M to assure the solutions address the needs of those usage areas. According to this principle, EMP has 9 Work Streams for enablers and verticals that are setup in matrix organization as shown in Figure 8.



EMP is not specifically considering energy as a vertical, but the energy industry has a central role in the Utilities work stream.

Figure 8: GSMA Embedded Mobile Program

The Embedded Mobile Guidelines White Paper [EMP EMG] is updated yearly, and summarizes the key findings of the Work Streams. It gives explicit recommendations for the development and implementation of devices containing an embedded cellular module, as well as the module itself. Also some application and network level considerations are included. The EMG white paper version 2 covers the following aspects:

• General Guidelines for Embedding Module Design

• Service Layer And Application Programming Interfaces (API)

• Guidelines for Provisioning and Management

• Guidelines for Testing and Certification

• Guidelines For Security And Fraud Risk Management

• Guidelines For Roaming

• Service Quality And Availability

• Specific Guidelines For Key Vertical Sector

5.5 IETF The Internet Protocol (IP), which has been originally developed as a data, is now also the base for a wide range of communication networks. IETF uses terminology such as Smart Objects and IoT (Internet of Things) for technologies and research topics related to M2M. Smart Objects are



constrained devices which are more and more connected to the IP network. The objective is to investigate how the limitations of the devices like energy constraints, bandwidth constraints, and memory constraints impact the design of the network and how to create solutions to overcome potential issues. Following paragraphs give an overview of IETF activities related to this area:

IPv6 over Low power WPAN (6lowpan):

The 6LoWPAN concept enables low-power devices with limited capabilities to participate in the Internet of Things. The 6lowpan working group defined the encapsulation and header compression mechanisms to allow the use of the IP protocol suite over wireless personal area networks, especially IEEE802.15-4.

The group has completed three RFCs:

• "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919), which documents and discusses the problem space and

• "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944), which defines the format for the adaptation between IPv6 and 802.15.4.

• “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks” (RFC 6282), which updates RFC4944 and specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPANs.

Active documents of 6LoWPAN WG can be found at: http://datatracker.ietf.org/wg/6lowpan/

Routing Over Low power and Lossy networks (Roll):

Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation connected homes and urban sensor networks (e.g. Smart Grid). Roll WG focuses on routing solutions these LLNs focusing only on IPv6 routing architectural framework.

The Roll WG developed following RFCs:

• RFC 5548: Routing Requirements for Urban Low-Power and Lossy Networks • RFC 5673: Industrial Routing Requirements in Low-Power and Lossy Networks • RFC 5826: Home Automation Routing Requirements in Low-Power and Lossy

Networks • RFC 5867: Building Automation Routing Requirements in Low-Power and Lossy

Networks

• RFC 6206: The Trickle Algorithm



The WG is currently working on various other documents related to routing in LLNs.

Active documents of roll WG can be found at: http://datatracker.ietf.org/wg/roll/

Core WG (Constrained RESTful Environments):

CoRE workgroup defines a framework for resource-oriented applications intended to run on constrained IP networks. This framework is going to address applications, which deal with the manipulation of simple resources on constrained networks, e.g. applications monitoring simple sensors (e.g. temperature sensors, light switches and power meters), or controlling actuators (e.g. light switches, heating controllers and door locks), but also managing devices.

As part of the framework for such applications, the WG currently defines a Constrained Application Protocol (CoAP) for the manipulation of Resources on a device.

Active documents of core WG can be found at: http://datatracker.ietf.org/wg/core/

Energy Management (EMAN):

Energy management is becoming an additional requirement for network management systems due to several factors including the rising energy costs, the increased awareness of the ecological impact of operating networks and devices, and the regulation of governments on energy consumption and production. The basic objective of energy management is operating communication networks and other equipments with a minimal amount of energy while still providing sufficient performance to meet service level objectives.

EMAN workgroup plans to work on the management of energy-aware devices and will develop several documents in this area.

Active documents of eman WG can be found at: http://datatracker.ietf.org/wg/eman/

Smart Object Directorate: The Smart Objects Directorate (previously named Smart Power Directorate) provides coordination between IETF and other bodies working on Smart Objectives and Smart Grids. Specifically it provides review and coordination on the use of Internet protocols to provide smart grid communications. The goal is to point other organizations to relevant IETF documents and provide review of documents from other organizations that depend upon Internet protocols.

5.6 OMA OMA published a white paper in the end of 2010 with the purpose to make recommendations to specific enhancements to existing OMA enablers and the development of new M2M enablers. The white paper surveyed the M2M standardization activities in other standards bodies (3GPP, 3GPP2, ETSI, GSMA, IEEE, IETF, ITU-T, and TIA) and identified potential gaps in end-to-end M2M standardization. In particular security is mentioned as one of the key factors for these new embedded systems to survive in a life expectancy of 20+ years.



Currently there are two main work items for M2M: “Lightweight M2M Enabler” which is lately approved and OMA Device Management (DM) Next Generation. OMA DM is structured around Management Objects, each specified for a specific purpose. There is also ongoing work with various other MOs, where the M2M aspects may also be added if necessary. One candidate is the Gateway Management Object (GwMO). Another work area, Converged Personal Network Services (CPNS), also has an objective to define interworking with ETSI M2M, as it is seen that seamless interoperation between CPNS GW and different M2M end devices is required. Furthermore the CPNS will facilitate the mapping of M2M GW functionality onto PN (Personal Network) GW.

5.7 Other standardization activities There are M2M standardization activities ongoing in other organizations as well. The following lists few of them:

• Currently 3GPP2 is working on three areas on M2M: o M2M Numbering. Among other things, the numbering AdHoc group is focused on

studying the capacity and other characteristics of cdma2000 identifiers, addressing schemes, and other numbering resources.

o M2M Architecture. A document to guide the detailed architecture development for 3GPP2 Architecture is being developed. It consists of requirements analysis, M2M key issues and solutions and impacts to normative specifications. The estimated completion schedule is 4Q/2011.

o M2M System Requirements. The document being worked on here provides the system requirements for M2M that will guide enhancing cdma2000 technology for the support of this feature. The target completion schedule is 4Q/2011.

• IEEE has in 2010 established the 802.16p activity to define enhancements to 802.16 based Broadband Wireless Access Systems (WiMAX) to support M2M applications. Currently they have a working document on requirements. 802.11 (WiFi) and 802.14 (ZigBee) are also IEEE technologies which are often used in the M2M context especially for the LAN, HAN and PAN area.

• ITU has a Global Standards Initiative on Internet of Things (IoT-GSI) which promotes a unified approach in ITU-T for development of technical standards enabling the Internet of Things on a global scale. This activity is accompanied by the ITU Joint Coordination activity on Internet of Things which coordinates the ITU-T work related to Internet of Things, taking into account standardization activities performed in other bodies including networks aspects of identification of things, and ubiquitous sensor network (USN). Several ITU-T questions have work items on ubiquitous networks and ubiquitous sensor networks. ITU-T has established the "Smart Grid Focus Group" with a focus on Smart Grid communication. The focus group has 3 working groups with 5 deliverables (Overview, Use Cases, Requirements, Architecture and Terminology). The focus group will be terminated by the end of 2011. It has to been seen how the work will be further progressed in ITU. The group cooperates especially with SGIP and took over a lot of the use cases and the conceptual model from SGIP.

5.8 Proposed M2M Partnership Project The standardization landscape for M2M has become complex due to immense interest in the topic. In addition to global M2M standardization activities such 3GPP MTC, there are also strong regional activities in Europe, in APAC region and in North America. The number of M2M activities has become large, and since some of them have overlapping scope they produce competing



standards. Another issue is the large number of vertical segments involved. Since common M2M platform has not existed, some vertical industries have their own platforms and standards which fragment the market even more. In fact the whole M2M ecosystem has become quite complex, as can be seen from Figure 9 [M2MConsATIS].

Figure 9: M2M Ecosystem

To avoid industry fragmentation, a number of SDOs working on M2M standardization, namely ARIB, ATIS, CCSA, ETSI, TIA, TTA and TTC have started discussions to join forces to define a generic common M2M platform just once, under a common "M2M Partnership Project" (M2MPP). These negotiations have attempted to evaluate what is the best way to proceed, and how especially vertical industries would be included. This is seen critical both to the successful M2M ecosystem and for the success for the proposed M2M PP. Discussions about forming the M2M PP are still ongoing. Standards organizations shown on various layers of the M2M ecosystem Figure 9 are focused on different layers of the systems and technologies, e.g. access and core network technologies and service capabilities (security, QoS, policy, transmission), Internet and private network technologies, service and application layer. The focus of the proposed M2M PP is on the service layer and will not include the various communication technologies like 3G, 4G and DSL.



6 M2M and Smart Grid Use Cases

6.1 Introduction This section discusses the applicability of M2M to Smart Grid as a use cases. Each SDO working on M2M seems to have their own way of defining use cases of M2M in terms of what functions it contains. 3GPP handles MTC use cases as means to optimize the mobile network communication. 3GPP does not specify the actual M2M verticals in any level of detail. ETSI TC M2M on the other hand has more information about use cases. In addition to the general M2M requirements, ETSI TC M2M has vertical specific Technical Reports which study special requirements and characteristics of each vertical. ETSI Smart Metering use case work refers to EC Mandate M/441, and it is based on use case work done by European Smart Metering Industry Group. It actually includes a broad range of smart grid use cases, some of which by some other definitions should be considered as totally separate use cases, but they are included with Smart Metering since they can use the same communication capabilities. For example, renewable energy (distributed generation actions) and demand response (DR) use cases are included. DR alone is a vast area with many different flavors. DR research and standards activities have been ongoing for years in the US. Renewable Energy Management is becoming more and more important. The motivation is to encourage the consumer also to become an energy producer. Therefore ETSI work on Smart Metering use cases can also be seen as a good overview and architectural framework of various technologies and stakeholder requirements that will impact in SG in the future. In addition to the Smart Metering use case document [ETSIM2MSM], ETSI also has started work under the title Smart Grid impacts to M2M [ETSIM2MSG]. This work is at its initial phase, but some use cases have already been included to the discussion. In addition to these two documents that specifically address the Energy Industry, ETSI is working on use cases for Connected Customer [ETSIM2MCon], City Automation [ETSIM2MCity] and Automotive Applications [ETSIM2MAuto] that also relate to the Energy Industry and Smart Grid in particular. We use the work done in ETSI as basis for evaluating how well M2M can support various Smart Grid applications.

6.2 ETSI SG use cases with M2M

6.2.1 ETSI Report on Smart Metering Use Cases The ETSI Smart Metering Use Cases TR [ETSIM2MSM] refers to EU standardization Mandate M/441 for an open architecture on utility meters. Use cases both from the Smart Grid Energy domain and Smart Grid Customer domain are defined. Smart Metering is defined as follows: “Smart meters are utility meters (electricity, gas, water, and heat meters) which may bring about the end of estimated bills and meter readings, and provide customers and energy distributors and suppliers with accurate information on the amount of utility being used. According to the TR Smart Metering provides:

• Customers with the information they require to become energy savvy and make smarter decisions about their energy usage,

• Energy suppliers with the means to better understand and service their customers,

• Distributors with an effective tool to better monitor and manage their networks.

• In addition, Smart Metering enables those customers who choose to generate their own electricity (micro generators) to be financially rewarded for their contribution to the national grid and distributors to better manage this contribution.”



The TR describes the (typical) Smart Metering configuration and a Smart Metering Information system with actors participating in the system. Main actors/stakeholders are e.g. Distribution Network operator, Consumer, Asset Entity (responsible for overall SM Information systems assets), Read Data entity, Bill Entity, Efficiency Entity, Energy Services Provider. Following table provides a list of collected use cases:

Table 5: Smart Metering use cases in ETSI

Use Case Description Obtain Meter Reading Data The Smart Metering Information System measures and records

consumption of units and provides these in the form of readings. The Smart Metering Information System provides this meter reading data to the Read Data Recipient. This reading data may be routinely sent to the Read Data Recipient as per a defined schedule and an example of this would be periodic readings, interval values or load profiles.

Install, Configure & Maintain the Smart Metering Information System

The Asset Entity installs, configures and maintains the Smart Metering Information System as required. the Asset Entity undertakes these configuration and/or maintenance actions where an issue on the Smart Metering Information System has been recognised. Monitoring and upgrade of the Smart Metering Information System's functionalities by the Asset Entity (including firmware updates) is dewcribed.

Support Prepayment Functionality Smart Metering Information System is configured to support the Prepayment functionality as defined by the Bill Entity. Occasions are described where the Prepayment functionality is managed locally on the Smart Metering Information System as well as instances where the management occurs remotely by the Bill Entity.

Monitor Power Quality Data The complexity of the system to move electric energy from the point of production to the point of consumption combined with variations in weather, generation, demand and other factors provide many opportunities for the quality of the supply to be compromised. Electrical devices may malfunction, fail prematurely or not operate at all. It is described how the Smart Metering Information System provides power quality data. The Distribution Network Operator, Asset Entity or Consumer is able to use this data to monitor the Supply performance and if necessary instigate actions to ensure correct performance levels.

Manage Outage Data Distribution Network Operator provides data to the Smart Metering Information System relating to a planned outage. In addition, the Smart Metering Information System may also provide information relating to unplanned outages to the Distribution Network Operator and/or Bill Entity.

Facilitate Demand Response Actions

Distribution Network Operator and/or the Efficiency Entity provide an instruction(s) relating to demand response to the Smart Metering Information System. It also describes High Level how the Consumer uses a display unit to view details from the Network Operator and/or the Efficiency Entity prior to the Consumer instigating the demand response action.

Facilitate Distributed Generation Actions

Distribution Network Operator and/or Efficiency Entity and/or Bill Entity provide instruction relating to distributed generation to the Smart Metering Information System. There may be distributed generating units such as solar units, wind turbines, micro generators in the home etc. which pose specific problems for controlling the electricity distribution network. The Consumer's equipment could be programmed to generate at an up to predefined level. The Consumer uses a display unit to view details from



the Distribution Network Operator and/or the Efficiency Entity and/or Bill Entity prior to instigating the distributed generation action (e.g. to initiate or stop generation).

Manage the Distribution Network using Smart Metering Information System Data

Distribution Network Operator uses data from the Smart Metering Information System and/or from defined points across the Distribution Network to optimise current asset utilisation and/or optimise future asset planning. This facilitates better management of the Distribution Network Operator's Distribution Network through informed decision making based on accurate and timely data from the Smart Metering Information System(s).

Manage Interference and Malfunctions to the Smart Metering Information System

Smart Metering Information System provides details of interference and malfunctions to its functionalities to the Asset Entity. Interference and malfunctions are threats that may compromise the confidentiality, integrity and availability of the Smart Metering Information System.

Interference is deemed to be unauthorised and can be deliberate (or illicit) or accidental (or innocent) - its management is in the form of event detection and prevention. The Asset Entity receives this data and manages follow-up actions to address the interference and/or malfunctions. This may including making changes to Smart Metering Information System configuration on site or remotely, or replacing the entire Smart Metering Information System.

Manage Tariff Settings on the Smart Metering Information System

Smart Metering Information System provides tariff and price information to the Consumer as per a predefined schedule or as a result of ad-hoc notifications from the Bill Entity. Examples may include amending unit price on the Smart Metering Information System following a change in tariff and where the Smart Metering Information System is switched between 1 or 2 rate metering.

Enable & Disable the Smart Metering Information System

The Asset Entity and/or the Bill Entity enable or disable the Smart Metering Information System according to predefined processes. This includes communication between the Asset Entity and/or the Bill Entity and the Smart Metering Information System and making changes to the Smart Metering Information System on site or remotely. It also includes the application of actions to limit the product availability through the Smart Metering Information System.

Interact with Devices at the Premise

Smart Metering Information System interacts with other Smart devices at the premise. It includes the provision of information to these devices and the management of that relationship via configuration and appropriate communication links. The Consumer can choose to approve or decline these interactions with the Smart device(s) as necessary. Smart devices at a premise may include thermostats or appliances with a high consumption.

Manage Efficiency Measures at the Premise using Smart Metering Information System Data

Smart Metering Information System provides the Efficiency and/or the Consumer with data that allows the Consumer to make informed choices relating to consumption at the premise. The Efficiency Entity instigates measures to improve efficiency or proposes measures for improving efficiency for the Consumer. The Consumer is able to approve or decline these measures.

Display Messages Smart Metering Information System receives, validates and displays messages from the Bill Entity and/or Energy Services Provider and/or the Efficiency Entity. These messages for the Consumer may include advice relating to the supply, advance notifications, generic information or for marketing purposes. The Consumer is able to approve or decline these messages.



6.2.2 ETSI Report on Smart Grid Impacts on M2M This work is in the initial phase, but there are early studies for Smart Grid use cases that benefit from the M2M architecture and some SG use cases are already tentatively listed in the ETSI Technical Report [ETSIM2MSG]. This work will look into the most relevant Smart Grids use cases which are used to derive high level requirements and it will provide a standard gap analysis. In ETSI context this will mean that the applicability of M2M APIs for Smart Grid applications and mechanisms to manage energy for end users will be checked and updated if needed. A set of recommendation for the ETSI M2M work will be derived. Dependencies and relationships also with other SG related standardization organizations e.g. with NIST (NIST Conceptual Model), CEN/Cenelec and IEC in particular will be shown. This work will further validate the applicability of ETSI M2M standards for Smart Grid.

6.2.3 Other Use Cases in ETSI that relate to Smart Grid ETSI M2M2 use cases work for some other verticals also includes features that are very close to Smart Grid The work in these documents is still ongoing but at least the following M2M use cases TRs include mechanisms also applicable for SG:

• Connected Consumer [ETSIM2MCon]: o Remote control of home appliance o Inventory Management: status report to service center (e.g. vending machine)

• City Automation [ETSIM2MCity]:

o Street light control • Automotive Applications [ETSIM2MAuto]:

o electric vehicle charging o vehicle-to-infrastructure communications

In addition to the specific use cases work ETSI has done for one or more of the M2M Verticals, also the general M2M capabilities that ETSI has defined up till now provide a good basis for Smart Grid and other Energy Industry use cases.

6.3 M2M Standards Support Smart Grid In the light of work done in ETSI, it can be said that Smart Grid is very well covered. Proper support will be defined for the most common use cases such as Smart Metering and related communication, Demand Response (DR), Management of Distributed Energy Resources (DER), Electric Vehicle Charging, and Building/Home Energy Management. This work is mostly related to the Service Capability layer and M2M Server (ref. earlier sections, e.g. 0 and 5.2.5), and the focus so far has been very Smart Metering oriented, although that concept has been treated with a very wide definition. In this work, there is no analysis about the direct management of IEDs in the Transmission or Distribution Grid. There may be some use cases in this area, such as Tele Protection that require very strict response time, in the order of 1-10ms, which cannot be supported by all of the available Communication Technologies. The very stringent delay requirements might be a consideration for an M2M platform implementation as well. However, the Service Capabilities that have been defined so far are likely fulfill the functionality requirements of these use cases as well.



7 M2M Architectural Alternatives for Smart Grid

7.1 Introduction Section 5.5 discusses how the standards and technologies explained in the earlier sections can be used to build a working M2M solution for the energy industry. The focus is on technologies standardized by ETSI and 3GPP, but also other standards and solutions are considered. The mainstream M2M solution, as defined by the standardization organizations, consists of three components. Starting from the bottom, they are: the Communication Capabilities via one or more communication networks that have been optimized for M2M, M2M Service Capabilities and M2M protocols which are realized by the M2M platform, and finally the M2M applications e.g. some Smart Grid related application such as Smart Meter reading. This creates a layered communication structure as shown in Figure 10.

M2M DeviceDomain

M2MService

Capabilities

Application

M2MService

Capabilities

Application

Communication capabilities

Application Protocols and Data

M2M Protocols

Commmunication Protocols

CommunicationNetworks

Communication capabilities

M2M ServerDomain

M2M Platform

Figure 10: Layered M2M Communication

The Communication Capabilities shown in the figure are mainly provided by the communication networks, but also some of it may be considered to belong to the M2M platform. The sections below discuss the interaction between communication networks and M2M platform in more detail. Also an example is given how this structure can be used in one example Smart Grid Use case, Smart Metering.

7.2 M2M Using ETSI and 3GPP technologies

7.2.1 Introduction M2M standardization work has been ongoing simultaneously in various standardization groups as explained in section 0. ETSI TC M2M is the leading European standardization activity for the common M2M platform, and ETSI also has active role in the negotiations for the new proposed M2M PP. 3GPP, where ETSI is also one of the partner organizations, is the leading global standardization organization for cellular and mobile broadband technologies, and they have been developing enhancements for M2M communication already for few years. The M2M work in these two independent organizations is unique in the sense that the activities are coordinated, and the first and foremost target has been to avoid overlapping specification. The groups have agreed a high level agreement to split the work into two independent layers as follows:



• 3GPP defines System Improvements for Machine Type Communication (SIMTC), which means enhancements to the 3GPP network for M2M. The intent is not to define a new system or network, but to consider what improvements and optimizations are required to the existing 3GPP system considering the specific nature of M2M. The applications that use the M2M are out of scope, and could be defined by anyone at the layer above. In short, the 3GPP work is limited to the communication network layer.

• ETSI defines general M2M functionality as a common platform for the support of various applications. This layer is agnostic to the communication layer below, and uses only generic communication capabilities provided by 3GPP or other communication networks. Therefore the details of the communication layer are out of ETSI TC M2M scope. Also ETSI does not define the applications themselves, only the capabilities that are made available for the applications are specified.

The ETSI and 3GPP defined layers are therefore essentially independent of each other, and do not assume or expect very much of each other. This is a good approach in the sense that it allows for maximum flexibility and independent development of these layers.

7.2.2 Basic M2M configuration Creating a working M2M system requires that the M2M components are put together in a meaningful way. An M2M system that implements both ETSI and 3GPP M2M standards is shown in Figure 11.

M2M ServerAccess NetworkCore

Network

3GPP Cellular

Application

mIa

mId

MTCiRadio

Interface

SM-SCmId

MTCsms

Application

Device

dIa

CommunicationCapabilities

M2MService

Capabilities


M2M

Service Capabilities

Figure 11: ETSI TC M2M defined M2M functions over 3 GPP M2M (SIMTC) interfaces

The device and the server communicate via mId interface on the ETSI defined M2M Service Capabilities layer. Figure 11 shows two alternative and independent ways for conveying the information from mId interface over the 3GPP network. One uses Short Message Service (SMS) and the MTCsms interface as shown on the top, and the other uses packet data bearer and the MTCi interface as is shown at the lower part of the figure. It is expected that the vast majority of the M2M communication will use the packet data bearer option. This means that M2M data that ETSI defined Device and Server applications would exchange is in form of IP packets (the lower red line) sent via a User Plane connection (the lower purple line) through the 3GPP Network as shown in the lower part of the figure. Since some current M2M applications use SMS as the carrier of information, or more often as a means to trigger the M2M Device to start using other communication means, 3GPP has kept SMS communication in their architecture. SMS has limited data throughput capabilities, and is a store and forward type of service, which does not suite the need of many M2M applications. Therefore SMS is not considered to be future proof solution for



M2M, and it is shown here for completeness only, and the different means of transporting SMS in the 3GPP network are not detailed out in the figure. The dIa interface within the M2M Device provides connection between the M2M Service Capabilities and the M2M Application, such as Smart Metering communication. Essentially it makes M2M communication available to the application in the device. The mIa interface connects the application in the network side to the M2M Service Capabilities within the M2M Server. Both interfaces are defined as Application Programming Interfaces (APIs). They make the M2M communication services available for the applications developed in the different verticals. This architecture does not assume that there is a specific communication between the ETSI and 3GPP defined layers. The MTCi interface is an IP interface defined between the gateway to the 3GPP network and the M2M Server, but it is used for exchanging User Plane (user data) packets between the end user (M2M Device) and the M2M Server (and further with the Application), and it does not contain any type of control signaling, which the M2M Server could use to connect to the 3GPP network itself. 3GPP has provisionally defined an interface called MTCsp, which could be used for this type of control signaling, but this interface has not been defined to the detail level yet.

7.2.3 M2M Configuration using M2M Gateways M2M Gateways (M2M GW) are defined in ETSI TC M2M Architecture as a means to aggregate traffic between a M2M Server and more than one M2M Devices. This is useful for such devices that cannot connect directly to the M2M Server, e.g. due to the lack of available direct communication means e.g. because they run different lower layer communication protocols, and aggregating the communication links in this way also allows more efficient usage of the communication links. The bottom portion of Figure 12 shows M2M configuration with a M2M GW, and the basic configuration without a GW is also shown on the top. These configurations are independent, and can exist in the same network without interfering each other. The operation with a M2M GW is basically the same as explained in section 7.2.2 above, the only difference being that when the GW is used, the ETSI defined dIa interface extends over the local network, instead of being internal to the device. The local networks can e.g. utilize technologies defined in IETF, which are not in the scope of 3GPP or ETSI standards (see further description in section 0). One of the key benefits of using the M2M GW is that it can bridge between different network technologies, and can ease up connecting devices from different environments to the M2M Server.

M2M Server

AccessNetwork

CoreNetwork

3GPP Cellular

Application

M2M Device

mIamIdMTCi


M2M Service

Capabilities

dIa

Application

Comm.

M2M SC

LocalNetwork

dIa

dIa

Application

M2M GWDevice

Comm.

M2M SC

Application

RadioInterface

Figure 12: M2M Communication using M2M Gateway



The M2M GW is defined only in the ETSI specifications, i.e. for the M2M Service Capability Layer, and 3GPP has not specified it as part of their architecture, although it has been raised few times. This means that one M2M Device in 3GPP network can have a role of M2M GW in the M2M Service Capability layer, but this is not visible to the 3GPP network, since the GW is the end device from 3GPP network perspective. The M2M Service Capability layer will take care of the specific aspects related to the M2M GW. This is the recommended way forward, as the clear split keeps the system less complex. In the lack of inter layer communication it would be very difficult to make use of GW functionality in both layers. The only addition 3GPP could consider is if there are specific communications requirements in 3GPP networks for a device operating as M2M GW, e.g. more data, higher availability requirement etc. but even these are generic capabilities that can be used also for non-GW M2M devices and devices in other device classes.

7.3 Other Solution Alternatives While using ETSI TC M2M and 3GPP standards together is the only coordinated combination for creating an end to end M2M communication system, there are naturally also other ways to combine the standards and using proprietary solutions remains as a possibility. Also both 3GPP and ETSI keep their standards open for other combinations, and are not tied to each other in any particular way. At least the following other cases can be considered:

• Using M2M connectivity through e.g. cellular networks without the use of specific M2M service platforms. In practical terms an example of this would be to continue the usage of cellular networks for Smart Metering as they are used today. 3GPP identifies this by defining the direct M2M alternative, mainly as a way forward for these existing deployments, by still making the new 3GPP M2M features available to them also. The benefit is that in this case the very specific nature of Smart Grid use case in question can be taken into account, e.g. the use existing Smart Meter standards like DLMS/COSEM may be easier than with M2M service platform. The cost is that this becomes a specific solution, and the scale economy benefit of common M2M platform is lost.

• Using other alternative standards as M2M service platform. We have described the use of the ETSI M2M platform since it is the primary European standard, but there are some competing standards that may be more applicable for certain regions, e.g. the ATIS and TIA M2M standard for North America. The most prominent alternative is however the future standard from the planned M2M Partnership Project (M2M PP) that is introduced in section

. The expectation is that this standard will use similar principles as those in the ETSI standard, as those are applied in other partner organizations as well, so it could be viewed as a direct continuation, or as replacement for the ETSI standard. It is therefore likely that this standard would operate much in the same way as discussed in this document for the ETSI standard. The uncertainty related to the timing of availability of this standard remains a concern.

• Using the ETSI M2M platform with other transport technologies than 3GPP. ETSI standards do not assume 3GPP technologies for transport and can be used with any communication technology providing IP connectivity. This is exemplified in using other transport technologies as shown in section 0 and Figure 12 for the local network under the M2M GW, but is not limited to M2M GW scenario. This is one of the strengths of the ETSI standard. Using other transport technologies, like WiMAX, DSL or PONs may be more relevant in some markets.

• Using proprietary M2M platform. In its capabilities, this solution can align quite well with what the ETSI standard solution can provide. The benefit of this case is that the technology can be available much sooner than the standards which are still in the making. In many



cases the proprietary M2M platforms would be integrated with the connectivity networks, but the level of integration can vary. The disadvantage of these solutions is that they are often offered by one company only, and the technology might not be compatible with other solutions. Migration to standard solutions can also often be available, which would be an option to look for.

• Usage of Internet of Things (IoT) technologies defined by IETF (see more in section 5.5). Some of these technologies are very promising for the local network environments, and some apply for full internet connectivity as well. Since these technologies represent solutions dedicated to certain limited areas, and IETF does not define an end to end architecture for these technologies, the integration of them into one end to end solutions is likely to be more difficult, and requires more attention. In our considerations we have placed these technologies mainly into the local environment, including home and personal area networks, since this is the primary use case they have been developed for. The usage of these technologies with M2M platform is a possibility, and e.g. the ETSI M2M GW solution provides a way to use them as a component in the end to end solution.

7.4 Example Use Case - M2M for Smart Metering Smart Metering is one of the most well known Smart Grid use cases, and the communication means developed for Smart Metering can be envisaged to be used also for other Smart Grid use cases, such as Demand Response, and Management of Distributed Energy Resources. Also, in some markets, Smart Metering has already been widely deployed as dedicated solutions that in most cases utilizes Cellular Communication, Power Line Communication or combination of both. Therefore it is interesting to see how Smart Metering could be realized as an application of the M2M technologies. Figure 13 shows the main components of Smart Metering solution placed on top of a simplified NIST SGIP Smart Grid Reference Diagram. They are the Meter Data Management System (MDMS), Meter Head-End, Metering Gateway, and the Smart Meter. The Metering Gateway aggregates the connections from many Smart Meters to the Meter Head-End. It is not present in all deployments, but we choose to show it in this analysis, because it can be deployed as a distributed element out in the field.



Bulk

GenerationCustomer

Distribution

Transmission

WFM

Internet / eBusiness

Markets Operations

Billing

CIS

(CRM)

Substation

LAN

Field Area

Network

WAN

Premises

Networks

DER

resource

Load

Device

GatewayCustomer

EMS

MDMS

Smart

MeterIED

DMS

IEDDER

Generator /

storage

EMS

DISTR

SCADA

IED

Plant

Control

System

Plant

Market

System / if

TRM

SCADA

RTO

SCADA

Substation

IED

Asset

mgmt

Energy

Market

Clearinghouse

Meter

Head-End

DR

(DRAS)

IED

Metering

Gateway

Service Provider

2

1

Figure 13 Smart Metering in NIST SGIP Reference Dia gram

There are basically two areas where the connectivity part of M2M as defined in section 6.3 could be used in Smart Metering. These are marked with numbers 1 and 2 in the figure. Case 1 and the combination of cases 1 and 2 can be mapped directly with the M2M solutions presented in sections 7.2.2 and 0, and shown in Figure 11 and Figure 12 respectively. M2M can be used in the following ways:

1 M2M used between Smart Meter and Metering Gateway (and not between Metering Gateway and Meter Head-End): This aligns e.g. with the existing deployments where Smart Meter has a cellular communication module. In this case the M2M Device is the Smart Meter itself, and it would have the mId interface to the M2M Server using 3GPP communication technologies. The M2M GW is not used at all. The Metering Gateway is the M2M application, and it would have the mIa interface towards the M2M Server. See Figure 14 below.

2 M2M used between Metering Gateway and Metering Head-End. In this case ETSI and 3GPP defined M2M stops at the Metering Gateway, and it would take the role of a regular M2M Device, and the remaining communication link to the Smart Meter is completely proprietary, and not considered as part of the M2M solution. The coordination of data collection from the Smart Meters would be completely in the



responsibility of the Metering Gateway. The Metering Gateway acting as the M2M Device would have the mId interface towards the M2M Server, which would have the mIa interface towards the Metering Head-End having the role of M2M Application.

1+2 M2M used between Smart Meter and Metering Gateway, and Metering Gateway and Metering Head-End: This aligns e.g. with the case where the Smart Meters are connected with PLC to the Metering Gateway, and cellular communication is used between Metering Gateway and Metering Head-End. In this case the Metering Gateway is acting as the M2M GW, and it would use the dIa interface towards the Smart Meter, and mId interface towards the M2M Server. The M2M Server connects via mIa interface with the Metering Head-End having the role of M2M Application. This case is highlighted in Figure 15 below.

Smart Meter

M2M Server

3GPPCellular

mId

MTCiRadio

Interface

Application

Device

dIa


M2MService

CapabilitiesCommunicationCapabilities

M2M


Metering Gateway

Application

mIa

Figure 14: ETSI and 3GPP defined M2M used between S mart Meter and Metering Gateway

LAN

Smart Meter

Application

Device


Metering Head-EndMetering Gateway

M2M Server

3GPPCellular

mId

MTCiRadio

Interface

Application

Gateway Device

dIa


M2MService

CapabilitiesCommunication

Capabilities

M2M


Application

mIa

dIa

Figure 15: ETSI and 3GPP defined M2M used between S mart Meter, Metering Gateway and

Metering Head - End

The other component of M2M solution that can benefit Smart Metering is the service capabilities offered by the M2M platform, such as data collection and dissemination capabilities, which could be used from the M2M Server. The M2M Server would be a centrally located element in the M2M solution, and would be shared with many M2M verticals, so we are not mapping it with the



elements related to Smart Metering. However, if this is treated as a dedicated solution for Smart Metering, it could be mapped with MDMS and partially also with the Metering Head-End, but the level of integration would depend on each case.

8 Conclusions The M2M business has seen a rapid growth in the recent years. Many dedicated solutions have been developed for the use in one or few particular use cases and they are successfully in use today. This can be called as the first phase of M2M. We are already in the middle of the second phase of M2M, where more general solutions that support a wider range of M2M verticals with the same technologies are being developed and standardized. Stake holders coming from multiple industries, with versatile and sometimes conflicting requirements, and multiple existing but different M2M solutions characterize the nature of this environment and the standardization landscape. M2M today is a complex ecosystem of multiple stakeholders and various regional but also global standards activities. The background of many activities is in the standardization groups developing various communication technologies, and the fact that they realize that their technology is already in the use for M2M, and it would be better to cover M2M also in the standards. Therefore the telecom industry which has a strong human-to-human communication background is being quickly covering a whole new area of M2M applications and communication needs. When the Energy Industry is added to this game with its own practices, technologies and requirements, especially the concept of Smart Grid with its many enhanced use cases, we find ourselves in the middle of a very interesting, demanding and truly challenging exercise. In this document we focused on explaining how the Energy Industry could use M2M technologies. We took primary focus to ETSI TC M2M and 3GPP standards, and showed how they could be used together. ETSI defines an M2M platform that can utilize any data transport technology, such as those provided by the 3GPP networks. 3GPP on its turn has made a number of improvements to their technologies to better suit the needs of M2M communication. These technologies were selected since the scope of these groups has been coordinated so that the standards are not overlapping, but complement each other providing the means of a layered M2M communication system. On the other hand, there is no standard that shows how to use them together, and the mapping between the two set of interfaces might not be self evident. We have made this mapping in the general use case, and furthermore we showed how to use them for Smart Metering, which is one of the key use cases for Smart Grid and the whole Energy Industry. Using ETSI and 3GPP standards, it is possible to build M2M service that can serve many industries. The main purposes of these solutions are to extent and enhance the communication and data handling capabilities for M2M in many verticals, and it is not a single solution for any particular vertical. It also fits the needs of the Energy Industry well in most of the use cases. In the case of Smart Metering, the mapping is aligned with the existing Smart Grid deployments. It is expected that only the most delay sensitive tele protection use cases might not be served properly with cellular communication. There are still some points of uncertainty in our analysis. The work in the standardization is still on the way, and even major changes can still take place, although it is thought to be unlikely, especially for 3GPP. On the M2M platform standardization side, discussions are progressing for starting a global M2M Partnership Project (M2M PP), which would collect all M2M platform level standardization into one group, and the various independent, regional and competing standardization would end. Representation also from different M2M vertical industries is also invited to this group. While this is a positive opportunity for the whole group of industries, the process raises concern with the timely availability of these standards. This timing gap can be filled



by using pre-standard M2M platform solutions that offer similar capabilities, and many of those can also be updated to standard compliance later, as the standards become available.

9 References

[3GPPM2MReq] 3GPP TS 22.368: "Service Requirements for Machine Type Communication (MTC)".

[3GPPM2March] 3GPP TR 23.888: "System Improvements for Machine-Type Communications".

[3GPPM2Mfsonsec] 3GPP TR 33.812 Feasibility Study on the security aspects of remote provisioning a change of subscription for M2M equipment

[3GPPM2Msec] 3GPP TR 33.868 Security aspects of Machine-Type Communications (Release 11);

[ETSIM2Mreq] ETSI TS 102 689: "Machine- to- Machine communications (M2M); M2M Service Requirements".

[ETSIM2March] ETSI draft TS 102 690: "Machine- to- Machine communications (M2M); Functional architecture".

[ETSIM2MSGPro] ETSI draft TS 102 921: "Machine- to- Machine communications (M2M); mIa, dIa and mId interfaces".

[ETSIM2MSM] ETSI TR 102 691: "Machine-to-Machine communications (M2M); Smart Metering Use Cases".

[ETSIM2Mdef] ETSI draft TR 102 725: "Machine to Machine Communications (M2M); Definitions".

[ETSIM2MSeH] ETSI draft TR 102 732: "Machine to Machine Communications (M2M); Use cases of M2M applications for eHealth".

[ETSIM2MCon] ETSI draft TR 102 857: "Machine to Machine Communications (M2M); Use cases of M2M applications for Connected Consumer".

[ETSIM2MCity] ETSI draft TR 102 897: "Machine to Machine Communications (M2M); Use cases of M2M applications for City Automation".

[ETSIM2MAuto] ETSI draft TR 102 989: "Machine to Machine Communications (M2M); Use cases of Automotive Applications in M2M capable networks".

[ETSIM2MSG] ETSI draft TS 102 985: "Machine-To- Machine; Applicability of M2M architecture to Smart Grid Networks; Impact of Smart Grids on M2M platform".

[M2MConsETSI] “M2M activities in ETSI”, Meeting of Potential Consolidation Partners#1, Seoul, July 2011].

[M2MConsATIS] “ATIS Thresholds for Success: M2M Standardization Consolidation”, Meeting of Potential Consolidation Partners#1, Seoul, July 2011].

[ETSIM2MCN] ETSI draft TR 101 531: "Machine- to- Machine communications (M2M); Reuse of Core network functionality by M2M Service Capabilities"



[Roy] Fielding, Roy Thomas (2000): "Architectural Styles and the Design of Network-based Software Architectures", Doctoral dissertation, University of California, Irvine, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[REST] Wikipedia: "Representational State Transfer", http://en.wikipedia.org/wiki/Representational_State_Transfer

sgem d132 m2m architecture for energy industry - …sgemfinalreport.fi/files/sgem_d132 m2m...

Documents