Machine-to-Machine Service Enablement – Device Data Store Model Vanesa Čačković*, Željko Popović* and Miguel-Angel Monjas‡ *
Ericsson Nikola Tesla d.d. Krapinska 45, 10000 Zagreb, Croatia Email:
[email protected],
[email protected] ‡ Ericsson Via de los Poblados 13, Madrid, Spain Email:
[email protected] Abstract — Machine-to-Machine Service Enablement (M2M SE) is a collection of different software functions created to be generic and follow a number of principles such as separation of concerns, loose coupling and composition. The software functions are used to implement domain specific applications for different verticals. Different organizations may take care of M2M Connectivity and M2M Service Enablement, as coupling between them is not mandatory. Device owners (the entities owning devices and therefore the ones that may grant access to data being measured or inferred by devices) use the M2M Service Enablement platforms to access their devices and therefore being able to create applications fulfilling their business requirements. This paper explains the model and of Data Store for M2M data by following a similar approach of digital distribution platforms for mobile devices (usually named application stores). Keywords — Machine-to-Machine; Service Enablement; Device Data Store; horizontalization
I.
INTRODUCTION
From a technical point of view, the Device Store functionality belongs to the Machine-to-Machine Service Enablement (M2M SE) area. The definition of M2M SE is the following: The main purpose of the M2M SE layer is to make sense of the information that the devices are measuring or generating, which can be accessed over application layer protocols (usually over TCP/IP, such as HTTP/XML and so on; but also SMS, for instance). Thus, Service Enablement must guarantee a transparent access to devices, regardless of the connectivity technology, a uniform naming of such devices (usually through a URI), the exposure of a uniform Application programming interface (API) to developers, access control and secure access to devices, quality of service assurance (for instance, assigning priorities to data coming from sensors or throttling its outcomes) etc. [1]. Although the definition is vague, a summary can emphasize that data elements being originated by sensors, usually as sort of data streams, are accessible to developers by means of an API. Such an API can be accessible through an HTTP-based URI, a Rich Site Summary (RSS) feed or whatever technology that allows developers to access data from devices. Thus M2M SE bridges the gap between the physical and the virtual world.
12th International Conference on Telecommunications - ConTEL 2013 ISBN: 978-953-184-180-1, June 26-28, 2013, Zagreb, Croatia
Therefore, the Service Enablement API provides information generated by sensors in a meaningful way. It provides, for instance, real-time access to the data being measured by the device (provided that this one has an IP connection and the connectivity is sorted out so that end-to-end connectivity is achieved). It might, on the other hand, be a database that records the periodic measurements sent by sensor using, for instance, short messages. The Device Data Store part of the M2M Service Enablement provides two main features: •
Controlled exposure of an API so that developers can create applications that use data being provided by said devices.
•
The marketplace that developers use to search and choose the accesses to the devices they are interested in.
It is possible to provide an example of the first set of functionalities: For example, let us imagine a municipality deploying a wide range of sensors providing information about temperature, wind speed, pollution, humidity, available light, pressure and so on. A developer could think of a simple application just showing sensors over a Google maps layer and the value of the measured data so that his/her customers may see such values over a map. On the other hand, a key element of exposure of sensor data to developers is service level. That is, the different conditions under which the access to said data is done by developers. If we consider the previous example, let us imagine pollution sensors are modern devices with 3G access so that it is possible to query them whenever necessary using an application level protocol (possibly HTTP-based) over IP. On the other hand, the temperature and wind speed sensors are old-fashioned meteorological stations that send an SMS every ten minutes to a given "inbox". Therefore, for a same set of devices it could be possible to set up different service levels. The pollution sensors may provide two different service levels: one providing online access to devices at any time the application requires the pollution data; other providing data each minute (that is, sensors are queried every minute and the last reading of the pollution level is stored so that if a request from a client arrives later on, the last read value is provided).
325
V. Cackovic, Z. Popovic, M. A. Monjas
As a summary, it can be said that without the Device Data Store, device owner(s) are able to access their devices just for "self-consumption". That is, the M2M SE platform is able to provide an API so that developers "on behalf" of the owner create applications. With the introduction of Device Data Store, developers not working for device owners may also use them. In this paper we will describe a Device Data Store model. Section two will provide an explanation of M2M SE functionality, section three will show some examples of related work, section four will explain the data Store model in more details, section five will give an overview of regulatory aspects of M2M technology while the last, sixth chapter will give the conclusion of the paper with proposal for future work. II.
Remote assets and its related data are never exposed outside the resource layer unless the exposure layer has requested such action. In fact, logically the exposure layer handles even data access between different resources and applications in the resource layer since it handles authorization of access to resources. Fig. 2 shows the high level principles of these two layers: Resource API Resources
Exposure
MACHINE-TO-MACHINE SERVICE ENABLEMENT
The M2M Service Enablement (M2M SE) is part of the Connected Things (CT) Service Enablement Architecture as shown in the Fig. 1. Service consumers
Informatrion providers
RD i.e. Google maps
Web service provider
i.e. Google Youtube Amazon Content and Media enabler
sensors & actuators
Consumer electronics solutions
Transport solutions
Connected Consumer SE
Operator A Core + Access
Operator B Core + Access
Utility solutions
Connected things service provider
resource host
exposure, SLA, access control
applications, users and exterprises
M2M Service Enablement
M2M SE
Operator C Core + Access
Connectivity Enablement
i.e. Google SAP IBM
Operator D Core + Access
devices sensors, meters, cameras, smart home etc.
Fig. 1. Connected things Overview
The Connected Things (CT) Service Enablers offer services towards vertical solution providers (e.g. Transport or Utilities solutions), Connected Things providers (e.g. Telenor) or Web Service providers (e.g. Amazon). The Connected Things Service Enablers use services from access providers (e.g. mobile/fixed operators) to gain access to end devices (e.g. photo frames, sensor nodes, energy meters, car gateways) or data sources such as offline stored traffic data from transport authorities [2]. The concept of Exposure and Resources is vital to understand the overall principles of the M2M SE architecture. The Resource layer implements the business logic related to the remote assets (sensors and actuators) while the exposure layer handles access to these remote assets and related data via so called resources. The two layers are separated and loosely coupled. Specific directories are used by the resource layer to advertise the availability of resources and the corresponding services and data to the exposure layer.
326
gateway and proxy
ED
Fig. 2. Service enablement Architecture Principles – Exposure of M2M Resources
The following entities are used to create the logical architecture of the resource layer: resources, the resource hosts and the resource directory (RD). Resource is a representation of one or several assets. An asset can be a sensor, an actuator, an aggregation over several sensors, and so forth. The resource host is the facade for the resource and is the functional unit responsible for the registration of the resource in the resource directory (RD) and also the entity that implements the application business logic in M2M Service Enablement for the resource. The Resource Directory (RD) is the registry for all resources in the system. If a resource is not registered in the RD it is not addressable and therefore not visible to the exposure layer. The RD includes the URI of each resource as well as the interface specification that the resource exposes, for example the information of how to communicate with the resource, which is normally dependent on the type of RH. The exposure layer handles all types of requests towards Service Enablement after it has passed the basic Firewall and Authentication functions. It provides real time notifications for external parties via real time protocols such as SIP or bidirectional HTTP. The exposure layer handles SLA monitoring, authorization & permission granting as well as functionality to transform the data format between the accessing client and the resource host and to plug-in new application logic for forwarding of data to external entities
ConTEL 2013, ISBN: 978-953-184-180-1
Machine-to-Machine Service Enablement - Device Data Store Model
The exposure layer handles management and storage of different kinds of lists and groups. Entity Directory (ED) relates resources to real world objects such as persons and places. M2M SE is architected as a collection of different software functions. They are created to be generic and to follow a number of principles such as separation of concerns, loose coupling and composition. The software functions are used to implement composite domain specific applications for different verticals. M2M applications are able to communicate with M2M resources using a single namespace without specific knowledge of the technical details about highly heterogeneous infrastructures, devices, and protocols. The M2M SE layer enables easy development of eventdriven compositional business logic, and scalable execution of custom business logic to process and aggregate M2M events and data. The scope of the Service Enablement functional groups is described below: •
•
•
•
•
•
Service Exposure – Provides generic access to sensors, actuators and other applications provided by the M2M SE system. Service exposure supports custom APIs implementing service level agreement (SLA) enforcement and uses authorization, protocol adaptation, publish/subscribe engine etc. to provide its services. (This functional group maps to the Exposure layer shown in Fig. 2) Universal Naming & Message Routing – A device may expose any number of resources representing sensors and actuators, moreover resources may be software components not directly connected to a device and may also reside in the network. This functional group includes generic mechanisms such as Publish/Subscribe engine and protocol data format translation.
Since the focus of this paper is on implementation of Data Store model, Data Warehousing part of Service Enablement Architecture will be described in more details in following chapters. III.
RELATED WORK
Cosm or Pachube which is Cosm’s previous name (from 2008 to 2012) [3] is an on-line service provider allowing owners of sensors and devices to connect sensor data to the web and developers to build their own applications using such data. It was created in 2008 and released to the public in 2010. According to the site “About us” [4] Cosm connects people to devices, applications, and the Internet of Things. As a webbased service built to manage the world's real-time data, Cosm gives people the power to share, collaborate, and make use of information generated from the world around them. The offering of Cosm is structured around a hierarchy of data types: •
Environment or feed. It is a collection of measured data, often at a particular geo-location, defined by the creator of the feed and measured by sensors and devices. An environment can represent measurements coming from both physical (such as a room, a mobile device, a building or a forest) and virtual entities such as a Second Life model, server bandwidth monitoring, etc.
• Data stream. It represents an individual sensor or measuring device within an environment. Every data stream must have a unique (within the environment) alphanumeric ID. It can also specify 'units' (e.g. 'watts') as well as user-defined 'tags' (e.g. 'fridge_energy'). •
Data point. It represents a single value of a data stream at a specific point in time. It is simply a key-value pair of a timestamp and the value at that time.
Cosm offer to developers is structured in three levels (so-called plans): •
Service Development, Customization & Execution Development tools and execution environment of custom business logic for the implementation of realtime analysis of M2M events including the fundamental Composition of Real-Time Analytics Business Logic including complex event processing functions
Basic, with the following features: the developer may access all public feeds, access historical data from feeds up to one month old and access a limited number of data streams, with a limited number of requests per time unit.
•
Data Warehousing – Functionality to collect and store/cache M2M events and data for a variety of purposes such as caching/storing, aggregation, and data analytics.
Pro, with the following features: the developer may access all public feeds, access historical data from feeds up to one year old and access a larger amount of data streams, with a limited but larger number of requests per time unit.
•
Other SE functions – Other functionality that is related to M2M SE such as the Geocast enabler, group management, quality of service, security FW etc.
Premium, with the following features: the developers may access all public feeds and also private feeds, access to all historical data from feed and access to an even larger set of data streams with larger limits.
This current Cosm’s model has some limitations:
Other Supporting Functions - A variety of tools to provision, monitor and operate all other functions that are shared between M2M Application SE and M2M Connectivity SE such as charging, portal etc.
ConTEL 2013, ISBN: 978-953-184-180-1
On one hand, it does not allow developers to access the data feeds they are actually interested in, but the whole of the existing data feeds, depending on the level the developer has paid for. Therefore, the access control model is coarse-
327
V. Cackovic, Z. Popovic, M. A. Monjas
grained and does not support the possibility of accessing only the feeds the user is interested in. From a deployment point of view this coarse-grained access control model is simpler to implement and deploy. However, such a design decision has inherent drawbacks: it makes it difficult to dimension the system. That is, once a level of access is granted to a developer, she/he may access whatever feed she/he wishes, even if not necessary, estimates must take into account such fact and therefore foresee always an excess of capacity. Additionally, feeds always provide all the data points from their data streams. The lack of modulation in the amount of information provided to developers prevents the system from prioritizing clients (developers) and offering them different levels of quality of service. On the other hand, the Cosm model follows a strict publication-consumption model. In that model, clients (developers) are able to pay for and access device data published in the Cosm platform. However, they cannot play an active role stating which type of data they would be interested in accessing or which service levels conditions are enough for them in device data being published in the platform [11]. IV.
DEVICE OWNER 1’S DEVICES
DEVICE OWNER 2’S DEVICES
The main component of Device Data Store, as shown in Fig. 3, is the Device Data Marketplace in which device owners will be able to create so-called device data packages (packages for short). Such packages are similar to Cosm’s feeds but with some differences: mainly, device data packages are assigned not only geo-location or tags, as in the Cosm case (for instance, data provided by meteorological stations deployed in Zagreb by the municipality may be defined with tags “Zagreb”, “meteorology”; if more fine-grained, data can be described with tags “Zagreb” and “temperature”, “wind speed”, “pollution”, “humidity”, depending on the type of sensor), but also service level conditions that rule the way data coming from sensors will be offered to developers. Examples of such service level conditions can be the maximum number of clients per hour (concurrent or not), the sampling frequency, how fresh data is (that is, if the access to device data is performed in real-time or by accessing a cache recording past values of data) etc. Although not directly related to a technical effect, device data packages are also given a price. It will be usually
DEVICE OWNER n’S DEVICES
M2M Connectivity DEVICE STORE PLATFORM Device Metadata
M2M Service Enablement
Enforcement
DATA STORE MODEL
The Data Store model is enhancement of the Pachube model, by following a similar approach of digital distribution platforms for mobile devices (usually named application stores). Beyond pure business-related features, such platforms are able to distribute software applications for smart phones and control which application has been delivered to each user (owning a smart phone). Applications are not developed by the owner of the application store, but by external developers. Initially, provided that the user met the appropriate requirements, use of applications was granted on a per release basis. Next, developers were enabled to include a limited set of conditions in the use grant, for instance, setting the length of a subscription.
328
dependent on the service level conditions (a basic package will have a low price or even be free; a premium one will be more expensive). Device data packages descriptions will be made available in the Device Data Marketplace so that developers can search for suitable packages (for instance, introducing and combining different parameters such as tags, location, price, and service level conditions) and purchase them [11].
Package features DEVICE OW NER
Service Level conditions DEVELOPERS
Fig. 3. Device Data Store Architecture
Following this approach, developers are not given access to the whole of device data but only to the specific packages they are interested in (in terms of content, price and service level conditions). The Device Data Marketplace interworks with the M2M SE platform, since it is the one that provides actual access to data coming from sensors. When device owners set the service level conditions such conditions are translated into policies the M2M SE platform can use and feed to said platform. Thus, the M2M SE platform is able to enforce the service level conditions. That way, on one hand, the dimensioning of the M2M SE platform can be optimized. On the other, device owners may also plan its offer creating device data packages with different service levels so that their devices are not overloaded with queries coming from application developers. Additionally, the market place will enable developers to request device data packages that have not been defined by device owners. Besides full-fledged device data packages, device owners can define tentative device data packages, without service level conditions (it will be possible to define maximum values) and different price options so that developers may request the creation of actual service packages offering a given price. The main roles involved in the Data Store Architecture are the following:
ConTEL 2013, ISBN: 978-953-184-180-1
Machine-to-Machine Service Enablement - Device Data Store Model
1.
Device Owner: the actual owner of devices. The one that makes a decision on sharing the information coming from those devices with third parties so that they can develop applications.
2. Device Data Store operator: the owner of the Device Data Store. 3.
M2M SE platform operator: the entity in charging of actually making available data coming from sensors through an API to third parties. Operator of Device Data Store can be the same as the one of the M2M SE platform.
4.
Developer: those wishing to use data coming from sensors to create applications.
Device Data Store aims to provide a platform for the exhibition of packages of data coming from sensors to developers interested in using such data for the creation of applications. This platform, which can be named Device Data Marketplace, provides the means for: 1.
Device Owners to review the devices supported by the M2M SE platform and the data being provided by them (in terms of semantics, protocol and service level conditions), and thus create and activate device data packages comprising data coming from specific sensors, with specific tags, price and service level conditions.
2.
Device Owners to create tentative device data packages without actual service level conditions and prices (but with maximum values of service level conditions and a range of prices)
3.
Developers to search for suitable device data packages. They will be able to look for tag, location, price, service level conditions and combinations of the aforementioned options.
4.
Developers to search for tentative device data packages in a similar way as with full-fledged packages and ask for the creation and activation of said device data packages.
5.
Device Owners for receiving request for the creation of device data packages.
Once device data packages (both tentative and full-fledged) are created, their features are stored in a database. This Packages Database is one of the components of the Device Data Store. Once stored, said features will be accessed from the Marketplace in order to enable searches by developers. On the other hand, the service level conditions of said packages are provided to the M2M SE platform for it to enforce said conditions. Such conditions, will be pushed to the M2M SE platform or read by it for the database on demand (that is, whenever a request arrives to the M2M SE platform). Said conditions must be translated to policies understandable by the M2M SE platform. In summary, the Device Data Store comprises two main functional elements: the Marketplace and the Packages Database. Tight coupling between both elements is not needed.
ConTEL 2013, ISBN: 978-953-184-180-1
V.
MACHINE-TO-MACHINE TECHNOLOGY AND REGULATORY CHALLENGES
The M2M market is one of the fastest growing and most dynamic sectors in the electronic communications industry. Berg Insight, a market research firm, estimated that by the end of 2010 around 80 million devices were connected using mobile networks. They suggest 290 million will be connected in 2015. Another company, IMS Research estimates that by 2015, 100 million devices per year will be equipped with mobile wireless connectivity with a 30% compound aggregate growth rate [16]. Ericsson vision is that everything that can benefit from a connection will have one, predicting more than 50 billion connected devices by 2020. The increasing use of M2M could create a range of issues associated with market liberalization, frequency, numbering, access to public sector information and especially privacy. M2M solutions will enable generation of huge amount of data of different kind on all aspects of economies and societies. With accordance to standard architecture and service enablement, those data will be used by different applications besides the primary reason it is collected. Example for this would be combining the data sent by the smart meter with data collected from the smart appliances from the household to optimize the power consumption of a household. A washing machine could “smartly” start with the washing cycle when the power consumption is lowest, and the light bulbs could be automatically switched of if sensors for example detect that there is nobody present in the room. The key question here for governments and utility companies is how to promote the growth or development of the environment where this data is used. Governments could encourage research in approaches leading to “win-win” outcomes to the sharing of data or consider funding developments that could lead to broader economic and social benefits. Utilities may find it in their interest to include this kind of feature to deliver sustainable energy in an efficient and secured way while optimizing internal costs and processes. For M2M data collected by the public sector as part of its various roles, the “OECD Recommendation of the Council for enhanced access and more effective use of public sector information” C(2008)36 is valid. It recommends governments promote openness and for broad non-discriminatory competitive access and transparent conditions for re-use. Whenever the public sector develops M2M projects it should seek to include a mechanism, so that the data can be used in new ways to enhance the value of M2M for the public [15]. Not all M2M services have a privacy component to them, but, when there is one, it can give a detailed view of a user’s life. With up to 10 devices per person communicating, there will be a significant increase in the range of information potentially gathered on individuals. Health parameters, reading habits, location data, energy use, driving style and eating habits M2M can record it all. All this data can be recorded on individuals and used in a variety of useful applications, but it can also give a confronting insight into the lives of people [15]. When evaluating the privacy impacts of M2M, it is not enough to look only at the service itself. The network used for
329
V. Cackovic, Z. Popovic, M. A. Monjas
the service adds a layer to the privacy evaluation. Security mechanisms like authentication/authorization, group control, QoS and priority services, setting up the VPN tunnel/remote access, alarm handling/subscription handling, service continuity and so on which are already present in existing telecom networks could be reused to achieve the required security requirements of M2M applications. Due to the large scale and widespread use of M2M, which is forecasted by various players in the telecom market, the privacy and security issues may have different characteristics than similar debates in the past. For example, concerns around the potential implications for privacy have forestalled or prevented developments in the area of smart metering, until they are addressed. This is somewhat different to other new communication developments, where it is more frequently the case that such concerns arise after a new service is in the market. The huge amount of new connected devices will also have the influence in spectrum policy and numbering. M2M rigidify some of the allocation of spectrum. At this moment, a significant amount of M2M devices are equipped with 2G technologies like GSM and CDMA. The modules for 2G are inexpensive and effective. 3G has only limited coverage and the high speeds offered may not be necessary. European countries may, for example, see this problem emerge with the eCall system. In some countries automobiles have an expected economic lifespan of 15 years and eCall specifications only call for GSM. Smart meters, by way of contrast, are expected to work for 30 years. Even consumer electronics may be active for 10 years after purchase. The effect of this will be that with an expected lifetime of M2M of 10 to 30 years, the devices will need to continue to work during that period, without needing a replacement of communications modules. This may mean that the customers will want 2G networks to remain active well after 2030. In an industry that, in many countries, is not much older than 15 years, such planning horizons are unusual for some types of communication technologies. This is true for both the industry as well as for the regulators as the mobile network operator is unable to make commitments beyond the current spectrum license and governments may not be able to say what their policy will be 5 to 25 years ahead. Policy makers will need to take into account that the long lifetimes of many governments mandated and operated M2M projects, are consistent with the anticipated duration of the technologies that provide their platforms. Another major impact of huge amount of new M2M connected devices is that the network that will transport the M2M data will need to support multiple numbers. Devices will be identified with IP addresses (IPv4 and IPv6), telephone e.164 numbers or IMSI e.212 numbers. With each of these numbers there is a specific set of issues that will need attention. The depletion of unallocated IPv4 addresses has been expected for some time. The introduction of M2M on a large scale may provide an additional incentive that IPv6 needs to make its adoption more attractive to the market. Telephone numbers as defined in ITU recommendation E.164 are another scarce resource that countries may run out of because of M2M.
330
This could require them to open new ranges or to reorganize the numbering plan. IMSI-numbers identify individual SIM-numbers. The number is defined in the ITU E.212 recommendation. It is 15 digits long. The first five or six digits are a unique identifier of a mobile network (Mobile Country Code + Mobile Network Code). This leaves one or ten billion numbers for an individual network to assign to mobile phones and devices. For many networks, this seems to be a more than adequate amount. Given that many mobile network operators have E.212 ranges in multiple countries and sometimes even in one country, there does not seem to be an immediate shortage on the level of individual Mobile Network Operators. They would be able to assign between one and 10 billion devices. IMSI numbers are essential to the issue of liberalization. Policy makers and regulators would have to introduce changes if the provision of M2M is to be liberalized. The main reason that some M2M users cannot take up their envisioned role, in providing services in ways they deem most efficient for themselves and their customers, is because regulation was established when it was not envisioned that large scale M2M users would need to make use of resources subject to this regulation. Specifically, numbering policy does not allow M2M users to access some types of numbers that they need to enter the market as direct suppliers of services to themselves or their customers. VI.
CONCLUSION
In a world where billions of sensors and machines will be connected to the network, it is still unclear how exactly the profitable business model will look like, allowing the owners of the devices to benefit from or, at least, to cover the expenses due to the deployment and connection of devices. For the telecom industry, the key challenge will also be how to attract investments in solutions that offer an attractive business case and to stand out in a highly competitive market. The necessary first step towards the mass M2M market is to provide tools and interfaces for simple application development. The capabilities and services of the connected devices should be made available to applications in a way that hides the complexity of the underlying network offering the connectivity. Device Data Store provides a fine-grained model for accessing data coming from sensors. It allows the definition of different types of device data packages with different service level conditions, even referring to the same devices. Device Data Store aims to create further revenue streams in this new M2M environment for all the parties in the ecosystem. From the device owner’s point of view, this model opens the door for developers to create new applications (much in the same way as with application stores). Regulation will undoubtedly play a part in defining the M2M market over the next few years and will help to create platforms for new services (for example, privacy and storing of collected data, the eCall standard, smart metering penetration in the EU, emission reduction targets etc).
ConTEL 2013, ISBN: 978-953-184-180-1
Machine-to-Machine Service Enablement - Device Data Store Model
REFERENCES [1]
http://www.ericsson.com/ourportfolio/telecom-operators/serviceenablement, accessed May 2013 [2] Ericsson White Paper, “More than 50 billion connected devices, 284 233149 Uen”, February 2011 [3] Xively webpage, http://cosm.com/, accessed May 2013 [4] Xively webpage, https://xively.com/whats_xively/, accessed May 2013 [5] D. Katušić, M. Weber, I. Bojić, G. Ježić, M. Kušel „Market, Standardization, and Regulation Development in Machine-to-Machine Communications“, Software, Telecommunications and Computer Networks (SoftCOM), 2012 20th International Conference [6] IOT – i The Internet of Things Initiative, „D1.3 Analysis of Existing IoT Strategic Research Directions and Priorities“, http://www.ioti.eu/public/public-deliverables/, accessed May 2013 [7] SENSEI – Integrating the physical with the digital world of the network of the future, FP7 project contract no. 215923, December 2010, http://www.ict-sensei.org, accessed May 2013 [8] OneM2M webpage, http://www.onem2m.org, accessed May 2013 [9] Ž. Popović, V. Čačković, D. Burjan “Arhitektura mreže za M2M komunikacije”, Ericsson "Revija" broj 1/2012, http://www.ericsson.com/hr/etk/revija/Br_1_2012/01.pdf, accessed May 2013 [10] ICT PSP Objective (and sub-objective) identifier: CIP 1.3 / point a “Open Innovation for Internet-enabled services and next generation access (NGA) services in ‘smart’cities”, Proposal acronym: SMARTPOLIS, Proposal full title: Enabling an open Internet-enabled ecosystem for development of innovative Smart City services [11] Paul Russel, ETSI M2M Architecture Introduction, “A brief overview for Release 1 and Release 2”, ETSI M2M Workshop, 24-25 October 2012, http://www.etsi.org/news-events/news/609-2012-m2mworkshop, accessed May 2013 [12] Joerg SWETINA, Patricia MARTIGNE, Omar ELLOUMI, “Next steps for M2M standards: Abstraction & Semantics”, M2M Workshop, 24&25 october 2012, http://www.etsi.org/news-events/news/609-2012m2mworkshop, accessed May 2013 [13] John Soldatos, Martin Serrano, Manfred Hauswirth, “Convergence of Utility Computing with the Internet-of-Things”, 2012 Sixth International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing, pages 874 - 879 [14] InterDigital whitepaper “(M2M) Software Development Platform Standardized service layer and APIs create a common framework and roadmap for cellular operators, service providers and device manufacturers”, October 2012, http://www.interdigital.com/wpcontent/uploads/2012/10/InterDigital-M2M-white-paper_Oct2012.pdf, accessed May 2013 [15] OECD (2012), “Machine-to-Machine Communications: Connecting Billions of Devices”, OECD Digital Economy Papers, No. 192, OECD Publishing. http://dx.doi.org/10.1787/5k9gsh2gp043-en, accessed April 2013 [16] A. Daj, C. Samoilă, D. Ursutiu “Digital Marketing and Regulatory Challenges of Machine-to-Machine (M2M) Communications”, Remote Engineering and Virtual Instrumentation (REV), 2012 9th International Conference, pages 1-5 [17] Arkav Juliandri, Meis Musida, Supriyadi, “Positioning Cloud Computing in Machine to Machine Business Models”, Cloud Computing and Social Networking (ICCCSN), 2012 International Conference, pages 1-4
ConTEL 2013, ISBN: 978-953-184-180-1
331
This page intentionally left blank.
332
