2010 Ninth International Conference on Mobile Business / 2010 Ninth Global Mobility Roundtable

Business Scenarios for Machine-to-Machine Mobile Applications

Vnia Gonalves
IBBT-SMIT, Vrije Universiteit Brussel Pleinlaan 2, 1050 Brussels, Belgium e-mail: vania.goncalves@vub.ac.be
AbstractM2M communications are capturing the attention of many stakeholders from application developers to mobile operators. Recent initiatives of the GSMA and of mobile operators show their interest in finding new sources of revenue through the adoption of wireless connectivity in a wide range of devices. A route to market these M2M devices can thus involve creating a platform of services that adds value and functionality to the devices and is a result of a combination of synergies between device manufacturers, application developers and mobile operators. Based on specific technical scenarios, this paper discusses several business scenarios wherein these stakeholders assume different levels of control over the customer relationship and the assets that make up the value proposition. Machine-to-Machine, Business Models, Platforms, Mobile Services.

Philippe Dobbelaere
Bell Labs, Alcatel-Lucent Copernicuslaan 50, 2018 Antwerp, Belgium e-mail: philippe.dobbelaere@alcatel-lucent.be We can thus outline that the M2M paradigm is deemed to open new markets and create new streams of revenue for device manufacturers, application developers and mobile network operators. One route to market these M2M devices as well as develop product differentiation could then involve creating a platform of services that adds value and functionality to these devices and is a result of a combination of synergies between device manufacturers, application developers and mobile operators. This platform would thus mediate between customers and the main stakeholders mentioned and would have different configurations depending on stakeholders approach to control crucial roles within the ecosystem. For instance, Ballon [9] proposes four different types of platforms oriented around their relative control over the customer relationship on the one hand, and the control over crucial tangible and intangible assets that make up the value proposition on the other. This paper proposes several business scenarios for M2M product creation and differentiation through a platform wherein application developers, devices manufacturers and mobile network operators take more or less active roles, i.e. control customer relationship and control the assets that compose the value proposition of the platform. This discussion reports to four technical cases described in the following section that are part of the WTEPlus (Moving beyond the Web2.0 / Telco2.0 / Enterprise2.0 paradigm) project [10]. These technical scenarios are focused on the improvement of home managed/unmanaged services for the home and transport services. Section III introduces the business model methodology and section IV benchmarks several business scenarios. II. TECHNICAL USE CASES

I.

INTRODUCTION

The emergence of the Internet of Things [1] paradigm is driving a potentially growing Machine-to-Machine (M2M) market, with among others, consumer and commercial metering and in vehicle applications accounting for the sectors with the most promising developments [2] [3]. These sectors have been the target of recent public policy initiatives and regulatory directives aiming at energy and transport efficiency and are therefore capturing the attention of many stakeholders. M2M communications then means that many consumer electronic devices can now be networked, interconnected and accessible or controllable remotely. Innovation is thus now shifting from the product (many devices are already present at home) to services that can be delivered or created on top of these devices. Recent interest and activity of mobile operators in M2M has arisen in projects such as the GSMAs Embedded Mobile Initiative. This market development program is designed to accelerate the adoption of wireless connectivity in a wide range of devices from the consumer electronics, clean technology, health care, transportation and utility sectors [4]. The key enabler of communication is a mobile network which facilitates the availability and flow of information between everyday devices. Moreover, Orange, Telenor and Vodafone are already giving the first steps towards providing a platform that integrates IT applications and infrastructure with the mobile operators network [5] [6] [7]. Recent standardisation efforts are also emerging in Europe within ETSI. The Machine-to-Machine Technical Committee was launched aiming at developing an end-to-end architecture for M2M [8].
978-0-7695-4084-9/10 $26.00 2010 IEEE DOI 10.1109/ICMB-GMR.2010.61 394 395

A. UC 1 - Personal Climotics The first use case is situated in the intersection between comfort services (climotics) and energy efficiency. Its aim is to help reduce global energy consumption by more intelligent control of the heating equipment, while still allowing the home tenants full control over their energy bill. Saving energy by modulating the peak consumption of heating equipment from the side of the energy provider is getting more attention, but the main drawback of this scheme is that it leaves the home tenants with almost no control over this process. In this scenario some control is given to the home tenants, through a mashup application that runs in the home. The mashup would get accurate energy cost per hour information from the energy supplier (e.g. Luminus,

Electrabel, Essent), a forecast of the ambient temperature and cloud coverage from a weather service provider, and gather absent periods inserted in a calendar application, e.g. Google calendar. The mashup would extend components delivered by the energy supplier (the equivalent of our current room thermostat, with enhanced features) with logic that can be tailored by the home tenant, allowing him full-customised control over the heating (or cooling) of the home. In the case of apartment buildings, some measure of synchronisation could be accomplished across the neighbouring apartments. Sensors involved would be thermometers in several parts of the building. Actuators would control the heating (on/off or proportional) and possibly fans for forced convection. The mashup could run on a home gateway, as application on a Linux based CE device like a Philips television, on a desktop computer, or on a dedicated platform. A mobile phone (Wifi or bluetooth) could serve as a user interface. Instead of forcing equipment in the home to run on less energy, people would be stimulated to make the right decision by means of adapting the energy cost and giving instant feedback of this cost to the users. B. UC 2 - Networked gate control This use case is situated in the building access control domain. It combines a video feed monitoring the entrance with a presence function for the home tenants. Some reasoning/scripting logic establishes a communication between the person at the entrance of the building and someone that has the authority to open the door, wherever that person is at the moment, based on the presence information. This communication could be a VOIP based session, not necessarily limited to a pointtopoint call (suppose it is someone visiting your children, you might want to check with them if they know the person involved). C. UC 3 - From "openstreetmap" to "opentransportschedule" Openstreetmap is an initiative to create road databases (similar to Mapquest, Tele-Atlas, etc.) in a DIY fashion. Opentransportschedule is a concept for a new service that wants to accomplish the same for public transport schedules. Capturing the actual trip info from cooperating users/vehicles in a multi-modal transport context could be achieved as well as the deduction of the transport mode (walking, cycling, driving a car, bus or metro, riding on a train, flying in an airplane) from the sensor context. This would considerably reduce the need to publish schedules and could also become a very strong competitor to trip planners, given its superior awareness of multi-modal trips. As a side effect, delays of public transport, based on local proximity, could be published (e.g. first subway vehicle is 10 minutes away from your stop, but if you cross the street to that other stop you can catch another one in 2 minutes). This would be a great tool to help people reach their destination in case a planned trip goes awry (railroads come to mind as a trivial example). With regards to valorisation, it could favour particular detours at cost (e.g. if opentransportschedule finds several

more or less comparable alternatives, have them walk by a certain shop with a certain advertising cost), or based on the preferences of the user (e.g. a certain prefers busy pedestrian-friendly streets, but another one might choose for a lonely walk in the park). D. UC 4 - Navigation improvement Finally, the last use case is focused on traffic safety. Assuming every car has a navigation device (e.g. Tomtom, which is Linux based) with a cellular interface to a femtocell basestation at the crossroads and there is some local processing capability in cabinets at the crossroads that can setup a communication session with these navigation devices, that also receive information from smart cameras (e.g. which cars are approaching from which direction, are there bike riders or pedestrians at the crossroads, etc). The local computing capability in the cabinets are backed up by a compute cloud that can run services that federate over increasing units of aggregation (i.e. multiple crossroads, multiple neighbourhoods, multiple cities, a complete highway, etc). As an initial application to kickstart infrastructure investment (the femtocells and the cabinets), a crossroads safety application and local traffic light control system would be deployed. This would regulate the green/red cycles on a local scale, and alert car drivers of potential dangerous situations involving other cars, bikers or pedestrians. Once the infrastructure is in place, a multitude of additional services could be added: large-scale traffic control (so called "green wave") speed control (by using electronic panels advising maximum speed) context aware information pushed to navigation devices (landmarks, food and drink opportunities, event ticketing). III. MODELLING APPROACH The various business model scenarios brought up in this paper show different ways of delivering the services to the consumer, as well as different types of interactions between actors. The various scenarios were modelled using three main building blocks roles, actors and stakeholders. A business role can be defined as a discrete set of responsibilities, actions, activities and authorizations that together have a coherent value-adding logic [5], e.g. application design, mobile access provision, etc.. A business actor is a marketplace entity that encapsulates a coherent set of roles and a stakeholder is a real-life organisation, e.g. an individual, institution, company, etc. with an interest in the outcome of a certain action [5]. In the context of this paper, the following roles were considered: Application Design: consists of the first phases of the software life cycle and is usually taken up by a software house or individuals (professional and nonprofessional developers). It consists in gathering the user and technical requirements and delivering a software package that complies with those requirements.

395 396

Application Hosting: consists of hosting the software code and the data required to run the application. This can occur in-house or outsourced. Application Provision: comprises the delivery and selling of software to specific market segments and additional technical support. Application Usage: is the act of using application services by end-users. Network Equipment Development: comprises the design and development of network equipment, implying the ownership of the intellectual capital necessary for the manufacturing of this equipment. Network Equipment Integration: consists of the provisioning of integrated network solutions to network operators. Mobile Access Provision: is the act of providing access to a given network to customers. In the context of this report, this role was simplified and therefore also includes backbone provision, last-mile provision and broadband access provision and applies to internet, fixed line or mobile services subscriptions. Mobile Access Consumption: is the act of using network access purchased from network access providers. CE Device Development: comprises the design and development of Consumer Electronics (CE) devices, implying the ownership of the intellectual capital necessary for the manufacturing of these devices. CE Device Marketing: consists of bringing to market consumer electronics devices to be used by consumers to interact with applications. CE Device Usage: is the act of purchasing and using a consuming electronics device obtained from a CE device marketer. The main actors considered relevant for this discussion are: Device manufacturer: the entity that develops and builds CE devices or other devices considered relevant in the M2M ecosystem, e.g. sensors, etc. Mobile Network Operator (MNO): the entity that provides mobile network connectivity to a device. Application Developer: designs and develops an application that explores the capabilities of a device or integrates information from different sources. This entity can be represented by an individual or an organisation. Application Integrator: the entity that, on one side, provides to developers an ecosystem for hosting and running applications, and on the other side, integrates and provides applications in the userenvironment. Consumer: the consumer holds a CE device and enabled with a mobile access subscription makes use of an M2M application. All business scenarios considered in the next section exhibit the same value network illustrated in Figure 1. In this figure, the value streams between roles and from and

towards the consumer are depicted. This way, dark arrows indicate service flows, while white arrows represent revenue flows. Only direct revenue flows are indicated though.

Figure 1. Generic Value Chain

The use cases considered in this paper privilege the access to information stored in devices and sensors (consumer electronics, utility meters, etc.), followed by the publication of this information over a mobile network and potentially combining it with mobile network operators contextual information and services (customer information, location, messaging, etc). Therefore was assumed that the consumer holds a CE device (mobile phone, television, computer, set-top box, etc) and a mobile telecommunications subscription (data or voice subscription). In addition, was considered that there are APIs made available by CE manufacturers and MNOs to facilitate, respectively, access to and integration of functionalities of devices and mobile networks. It was not considered relevant for this analysis to explore the actors that assume the roles of Network Equipment Development and Network Equipment Integration as those roles are related to the functioning of the network and are just mentioned here to make the value chain clear. IV. BUSINESS MODEL SCENARIOS Based on the actor that holds the direct customer relationship for application provisioning, the scenarios presented in this section are aggregated by the streams shown in Figure 1. A. Application Stream Scenarios 1) Description In the application stream two scenarios can be considered: 1. The application developer establishes a platform for software development and provision and manages a

396 397

direct relationship with the customer or sells applications to MNOs (Figure 2). 2. The application integrator establishes a platform for hosting and provision of applications, but relies on application developers to develop and publish applications on the platform (Figure 3). In the first scenario, the application developer develops, hosts and provides applications, i.e. establishes the entire platform for application development and provision. The application developer collects revenues from several operators or from only one, based on an exclusivity contract. Alternatively or complementarily, the application developer provides applications directly to the consumer. While the application developer can have two sources of revenue from distinct stream stakeholders, there is also potential for the MNO to collect revenues from consumers.

Figure 3. Application Integrator scenario

Figure 2. Application Developer scenario

The second scenario considers an application integrator that setups an application development platform in order to host and provide applications. Through this platform a set of APIs to interact with network devices, CE devices and so on is provided, in order to leverage creativity and innovation of a developers community or application developers such as ISVs or startups. In this context, the application integrator collects revenues from application developers using the platform and from consumers or MNOs to whom these applications are sold. In both scenarios consumers have direct access to the applications available in the platform without the mediation of the MNO.

2) Discussion All the technical use cases presented earlier could be deployed according to these scenarios, provided that access to hardware-related APIs is facilitated to application developers. In addition, although selling applications directly to consumers seems a reasonable business scenario for application developers/application integrators, a close cooperation with MNOs would be beneficial to guarantee platform adoption due to their large customer base and control over customer data. On one hand, applications can be charged to consumers on a one-time fee or pay per usage basis and on a pay per number of users basis to MNOs, on the other hand. Additional license fees or exclusivity contracts could also be negotiated with MNOs. In the second scenario, the application integrator could also charge developers for access to the platform on the basis of resource consumption, access to particular APIs or on a monthly fixed fee. The application integrator may strengthen its relationship with application developers and the value proposition of the platform towards developers by offering attractive revenue sharing contracts. A fast way to establish this platform could involve simply the expansion of an existing platform to incorporate M2M applications, avoiding high investments and risks. It should be mentioned that the main potential bottleneck of these scenarios is the lack of cooperation between platform owners and device manufacturers, preventing developers to get access to hardware-specific APIs. B. Mobile Stream Scenarios 1) Description In the mobile stream several scenarios reflecting more or less control of the value chain by the MNO can be considered. Still, the MNO guarantees the direct relationship with the customer for application provisioning:

397 398

3.

4.

The MNO setups an application development platform in order to host and provide applications, holding at the same time a marketplace to distribute applications submitted by application developers to its customer base. The MNO relies on developers innovation for the success of the platform (Figure 4). Apart from holding a platform for hosting and provision of applications, the MNO also chooses to have a technical department to develop applications internally. In this case, third-party applications developers are not involved and do not contribute to the innovation loop (Figure 5)

Figure 6. MNO holds CE device marketing scenario

5.

6.
Figure 4. MNO holds application provision scenario

7.

8.

Figure 5. MNO holds application design scenario

In a slightly changed configuration of the previous scenario, the MNO not only takes an active role on the application stream, but also takes up the active role of marketing devices to the end-user and takes control of additional functionalities delivered to the customer. This scenario can be compared to the bundle offers (mobile phone plus medium/long contract), which are mobile operators common practice across Europe (Figure 6). In this scenario, although the MNO still holds the customer relationship for application provisioning, the device manufacturer assumes a more active role in the application stream. The device manufacturer bundles the devices with software that is made available to the consumer through a platform established by the MNO. In addition, the MNO maintains its role of marketing devices to the customer (Figure 7). The device manufacturer holds application provisioning, but as part of a deal with the MNO, the device manufacturer provides the application provisioning platform to the MNO. In a nontransparent way, the costumer is redirected to the manufacturers platform whenever he tries to buy new software or use interfaces of the application. The MNO still sells the CE device to the customer and charges him for each application bought or used (Figure 8). Similarly to the previous scenario, the device manufacturer holds application provisioning, but opens the platform to the contribution of application developers. In this case, the revenue of an application is split between the MNO, the manufacturer and the application developer (Figure 9).

398 399

Figure 7. Device Manufacturer holds application design scenario

manufacturers would mainly depend on an open platform and attractive revenue sharing rates. In these scenarios developers and manufacturers collect revenues from one or several MNOs. However, compared to developers, manufacturers could actually have more bargaining power, since they control the underlying access layer to CE devices, resulting in both actors trying to exert a certain control over each other. In scenarios 4, 5 and 7, the MNO and the manufacturer, respectively, control the entire application development stream. These actors might incur in the risks of not having the necessary technical skills to implement the platform, having difficulties understanding the requirements of customers and developers, and neglecting this stream of their business, since revenues can be marginal, at least during an initial stage. In scenarios 5 to 8, the MNO takes up the additional role of marketing CE devices. This role can be feasible if the MNO establishes an alliance/agreement with certain device manufacturers in order to facilitate the deliverable of M2M devices to customers. This would increase implementation speeds, reduce the cost and complexity of delivering M2M devices to customers and enable economies of scale for manufacturers. In this case a revenue share deal between the two actors could be set up and would facilitate the deployment of technical use cases UC 2 and UC 4. Scenario 8 seems the least interesting scenario, since both MNOs and manufacturers rely on developers for the success of the platform implying a considerable risk for the former stakeholders. In addition, revenues would be split among three actors, potentially leading to a revenue split not that interesting for developers.

Figure 8. Device Manufacturer holds entire application stream scenario

2) Discussion The mobile stream scenarios envisioned deliver the advantage of involving the MNO and hence leverage the integration of mobile services and mobile network functionalities with consumer electronic devices. In all these scenarios, the MNO charges directly the customer either through the monthly bill or through one-time micropayments per application bought or used. Scenarios 3 and 6 reflect a two-sided business model and enable the MNO to collect revenues from selling applications to consumers and from application developers or manufacturers using the platform to host and market applications. Platform adoption by developers and

Figure 9. Device Manufacturer holds application provision to MNOs scenario

399 400

C. CE Device Stream Scenarios 1) Description In the CE device stream scenarios the device manufacturer holds the customer relationship for application provisioning and device marketing. The device manufacturer thus sells CE devices directly to the customer and likely also provides applications directly to the end-user through, for example, an application portal. These scenarios are similar to real-life cases of mobile handset manufacturers that hold platforms to sell applications to device owners: 9. The device manufacturer allows third-parties to participate in the application design and shares revenues with them (Figure 10). 10. In addition to the device stream, the device manufacturer assumes the entire application stream (Figure 11).

are currently more successful than similar platforms established by mobile operators.

Figure 11. Device Manufacturer holds application provisiong scenario

V.

CONCLUSIONS

Figure 10. Device Manufacturer holds application provisiong without application design scenario

2) Discussion The technical cases UC 2 and UC 4 could be deployed taking these two scenarios into account, since access to hardware-related APIs would be obviously facilitated. However, given that the MNO is not involved in the application provision, the possibilities to integrate with mobile phone functionalities decrease. In these scenarios, the device manufacturer sells applications directly to consumers, similarly to existing mobile manufacturers platforms, such as Nokia Ovi. Similarly to previous scenarios, consumers could be charged on a one-time fee or pay per usage basis. Previous considerations regarding opening the platform to application developers also apply to scenario 9. Although these two scenarios seem to have little implementation potential, they are comparable to the platforms established by mobile phone manufacturers, which

This paper suggested a set of business scenarios involving the creation of a platform of services that would add value and functionality to M2M devices. This platform would reduce the cost and complexity of delivering M2M devices to customers as well as increase implementation speeds of projects involving such devices. This platform would thus mediate between customers and the main stakeholders (application developers, MNOs and device manufacturers) and would have different configurations depending on the stakeholders approach to control crucial roles within the ecosystem. Although restricted to a specific set of technical cases, these scenarios can also be extrapolated and applied on more generic deployments and seem to have real-life applicability. Apart from the business configuration, there are however other issues that influence synergies between stakeholders and the configuration of services and thus should be considered when planning strategies to efficiently deliver M2M devices to consumers. Among others, the following issues can be highlighted: Current standardisation efforts can have a future outcome in economies of scale and massive production and integration of M2M devices. Regulatory constraints and incentives can have a significant impact on the development of certain sectors of CE device manufacturing. The importance of moving towards international solutions that work across borders (e.g. in the field of transport systems/services) may require additional efforts in harmonising roaming prices.

400 401

Promote the alignment between MNOs and device manufacturers and application developers by clear communication of the market and research opportunities. Security and privacy issues related to information sharing and collaboration with third-party stakeholders.

[1]

Pondering about the feasibility, advantages, disadvantages of these scenarios, as well as, the impact of external factors on their successful deployment could be topics of further research. Additional insight could be gained from a deep discussion about the similarities between these scenarios and real-life case studies of platforms available in the mobile services domain, taking the lessons learnt from there in order to evaluate the feasibility of the proposed scenarios. ACKNOWLEDGMENT This article is based on results from the WTEPlus project (IBBT project 10328), which is funded by the IBBT (Interdisciplinary Institute for BroadBand Technology) of Flanders, Belgium, as well as by the various partner companies. REFERENCES

ITU, Internet Reports: The Internet of Things, http://www.itu.int/osg/spu/publications/internetofthings/InternetofThi ngs_summary.pdf, 2005. [2] Strategy Analytics, Global Mobile M2M Market to reach $57 billion by 2004, http://www.strategyanalytics.com/default.aspx?mod=PressReleaseVie wer&a0=4072, 2008. [3] Juniper Research, Embedded Mobile & M2M Strategies Healthcare, Telematics, Metering & Connected Buildings 2009-2014, 2010. [4] GSMA, GSMA Advances Embedded Mobile Initiative with launch of competition, http://www.gsmworld.com/newsroom/pressreleases/2009/3439.htm, 2009. [5] Orange, Orange M2M Connect, http://www.business.orange.co.uk/servlet/Satellite?c=OUKPage&cid =1135953584842&pagename=Business, 2010. [6] Telenor, Telenor Objects - a new company and ambitious initiative in the Telenor family, http://telenorobjects.com/news/telenor-objects--a-new-company-and-ambitious-initiative-in-telenor.aspx, 2009. [7] Vodafone, Vodafone, Verizon Wireless and nPhase announce strategic alliance to provide global M2M solutions, http://www.vodafone.com/start/media_relations/news/group_press_re leases/2010/vodafone__verizon.html, 2010. [8] Shelby, Z., ETSI M2M Standardization, http://zachshelby.org/2009/03/16/etsi-m2m-standardization/, 2009. [9] Ballon, P., Control and Value in Mobile Communications: A political economy of the reconfiguration of business models in the European mobile industry. PhD thesis, Vrije Universiteit Brussel, 2009, Available online at http://papers.ssrn.com/paper=1331439. [10] IBBT, Web/Telco/Enterprise beyond x2.0, http://www.ibbt.be/en/project/wteplus, 2010.

401 402