TKI: Onlive (2017-2018)

Creating the MVP

The goal of this TKI research project was to research and develop the technological components of the Onlive MVP in close cooperation with the market (below the parties who form our market parties and partners of this TKI project). Technical components of the MVP  consist of the dynamic formation of groups and creation of value adding plugins. Big data, sensoring and hybrid networks play an important role in this. We need to handle and integrate different kind of new technologies to establish a secure and scalable platform that allows us to realize the business proposition. The research questions related to these are further explained in the paragraphs below.

 All the parties that worked together on creating the ONLIVE MVP.

All the parties that worked together on creating the ONLIVE MVP.

RQ1. How to enable the dynamic emergence of groups?

Users form groups without having to do anything. This makes interacting with people who share the same context effortless. However, determining that someone is in the same context (e.g. standing next to you), requires using the sensors of the smartphone and possible emitting some signal. There are for example several ways to determine the location of a smartphone. In this project, we want to research how we can combine information from several sensors, so groups of people can be created automatically and in a generic way. We built upon the concepts and software developed for Transient Apps

artboard about groups.png


The context engine predicts what groups are relevant for you!

RQ2. How to dynamically deploy plug-ins based on context information?

Plug-ins are the software that allows people to interact within groups. For example, during a soccer match, a group could be formed within the stadium and a plug-in can be offered that allows people to interact during the match. This plug-in is specific to the context of this match, and is not necessary for users who do not attend the match. In order to make the platform scalable, we need to make sure that the plug-in is only installed on the smartphones of people who are part of this group. This requires a system in which plug-ins are automatically downloaded (or possibly updated) based on available groups, and an intelligent way of managing which plug-ins should be installed on the smartphone. For this we can built upon the concepts and software developed in the Transient Apps project.

RQ3. What kind of functionality should the platform offer plug-ins and how can functionality be extended in the future?

Plug-ins are functionalities that allow people to interact in a specific way within a group. These plug-ins could be developed by third parties. What it is that these plug-ins do exactly may differ a lot between use cases. In order to function, these plug-ins might need functionality which needs to be offered by the Onlive platform (e.g. take a picture or record audio). We need to determine which functionality should be offered by the platform for most use cases, and what we should do if new use cases arise that need new functionality.

Artboard about context.png


The available cards inside a nearby group determines what plugins in the group should be downloaded. 

The group hosts of context groups determine what plugins should be downloaded.

RQ4. How can groups be created and data from plug-ins be exchanged without relying on an Internet connection?

The Netherlands has in general very good Internet coverage. However, during events that are very busy, and in other countries, mobile Internet might not be available. Currently, Onlive relies on a stable Internet connection. However, Onlive could add much more value to its users if it would be able to work without an Internet connection. It is possible for smartphones to communicate directly with each other through Bluetooth or Wifi Direct. Furthermore, mesh network technology allows the creation of a network which is larger than the individual smartphones that are connected with each other. We want to investigate if it is feasible to use direct or hybrid communication to perform the tasks of the Onlive platform (emergence of groups, dynamically deploying plug-ins and exchanging data form plugins). If so, we need to know what the impact will be on the software architecture and have to identify possible ways of implementing this.

Artboard about meshnetworking.jpg


We did research on (open source) mesh networking technologies. 

RQ5. How can the Onlive backend be designed in a robust and scalable way?

When no direct communication possible, the Onlive backend is responsible for determining groups, providing plug-ins to smartphones and allowing plugins to exchange data. When Onlive becomes popular, the number of users will increase beyond the capabilities of one machine. Also, we cannot rely on the availability of a single machine to keep the Onlive platform working. In order to do that, the backend needs to be designed in such a way that machines can be added to handle traffic when needed, and that the failure of a single machine should not disrupt services. Technologies are available to do this, but because of the uniqueness of the Onlive concept it is difficult to apply these technologies directly to the Onlive backend.

App tech.png

Software architecture

An overview of the developed technology

RQ5: What are market requirements regarding Onlive and what does this mean for the technical development of the platform?

Value will only be created if Onlive is able to play in on the various context categories and corresponding plugin demand. Understanding of the market enables the right strategy to ensure that software developers are interested in developing plugins by Onlive methods and create value and users are interested in capturing that value by installing and making use of Onlive. It may be clear that it is important to translate customer requirements into a technical functional model.

3105Onlive-concept en businessplan.pptx.png

The market

Our project partners were the market parties that we regularly asked to give feedback on our decisions and results. Without their input, we could not have developed the MVP. 


Name *