MOSAIC 2B Architecture

Posted on 12/08/2014 by Daniel Steffen
MOSAIC 2B Architecture

The architecture of the MOSAIC 2B framework.

 

MOSAIC 2B Player Platform and MOSAIC 2B Control Unit (1)

The component interaction diagram presents the manner in which all components of the Mosaic 2B solution interacts to support the entrepreneurs’ business model. The system supports a direct internet connection between the MOSAIC 2B Player Platform and the MOSAIC 2B Control Unit using the GSM data network. Such a link is responsible for smaller overhead calls from the MOSAIC 2B Player Platform (client-side) to services exposed by the MOSAIC 2B Control Unit (server-side). This link is used to provide the following services: ordering of media content, payment for media content, upload of screening event details, upload to the MOSAIC 2B Server the logs of Visual Analytics application for micro-entrepreneur. The availability of this link relies on the physical location of the tablet device. Whenever the device is outside a GSM coverage area, this link will not be available. For this reason, the MOSAIC 2B Player Platform will include the capability to asynchronously process requests destined for this link when possible. The application will therefore support asynchronous responses as well. This link will not be utilized for large transfers of data as the carrier is relatively expensive. This link is considered uni-directional, from the MOSAIC 2B Player Platform to the MOSAIC 2B Control Unit only.

MOSAIC 2B Control Unit and DTN Application Layer (2)

The server hosting the MOSAIC 2B Control Unit will also include a DTN Application Layer which represents the main entry-point into the DTN network from the Control Unit’s perspective. Most of the heavy-weight (content size wise) traffic destined for the downlink (from the MOSAIC 2B Control Unit to the MOSAIC 2B Player Platform) will make use of the transport medium provided by this interface. Such an interface is envisaged to be a local (operating system) command interface and will allow the MOSAIC 2B Control Unit to submit files to the DTN network destined for delivery to a specific entrepreneur. The MOSAIC 2B Control Unit assembles the files and just requests the DTN Application Layer to transmit. There is no semantic meaning to the files from the DTN network perspective. This service is exposed by the DTN Application Layer and requires the file location and the target entrepreneur node name. Once invoked, the relevant file will be propagated through the DTN network in an asynchronous fashion until it is re-assembled at the desired end-point (edge infostation).

MOSAIC 2B Player Platform and Edge Infostation (3)

The edge infostation is the end-point for content delivered through the DTN network. It is the responsibility of the DTN Application Layer on the edge infostation to re-create files transmitted through the DTN network on its local storage device. We therefore require a mechanism to move content from the infostation to the MOSAIC 2B Player Platform running on the tablet, which is the real end-point for content. All of the infostations in the system is expected to form part of an ad-hoc wireless network. Although the entrepreneur’s tablet is not expected to form part of the DTN network, it will be configured to join the same ad-hoc wireless network of the infostations. The MOSAIC 2B Player Platform will therefore be able to connect to its corresponding edge infostation (they will be “paired” through configuration). The edge infostation will expose an SSH server. The MOSAIC 2B Player Platform will at regular intervals connect to the SSH server and do a file listing to find newly delivered files. If new files are available, the same connection mechanism will be used to move the file from the edge infostation to the tablet storage device. Once the file is downloaded to the tablet, it will be available for use by the MOSAIC 2B Player Platform. This interface therefore forms the last hop in delivering the same services. The entire path is considered uni- directional, from the edge infostation to the MOSAIC 2B Player Platform.

MOSAIC 2B Control Unit and WASP (4)

Due to the physical payment challenges it is envisaged that the entrepreneur pays for content by using his GSM network provider account. This is made possible with the use of a 3rd party WASP (Wireless Application Service Provider) service. A WASP exposes certain interfaces, which can be used to interact with mobile subscriber accounts in a service provider agnostic fashion. It is envisaged that the MOSAIC 2B Control Unit makes use of the “Event Billing” service of a WASP to collect money in an ad-hoc fashion from a mobile subscriber’s service provider account. This interface is typically a web service interface provided over the internet. An account is created with the WASP for MOSAIC 2B. Every ad-hoc billing event received by the WASP is then processed by firstly requesting the relevant subscriber to approve the payment and secondly deducting the required amount from the subscriber’s service provide account by interfacing directly with the relevant service provider in the background. At regular intervals, the WASP can then initiate a payout of collected money (after deducting fees) to MOSAIC 2B. This interface forms part of providing the mobile payment service. This link is considered bi-directional. The MOSAIC 2B Control Unit requests billing by contacting the WASP and the WASP in most cases responds with the result in an asynchronous fashion by calling back to the MOSAIC 2B Control Unit once payment is processed. The MOSAIC 2B Control Unit therefore has to expose a service in the format specified by the WASP for responses.

MOSAIC 2B Control Unit and MOSAIC 2B Analytics Service (5)

In order for the MOSAIC 2B Analytics Service to provide usable results it needs access to a number of data sources in the system. One of the main data sources is the MCU (MOSAIC 2B Control Unit) database itself. It is therefore envisaged that the MOSAIC 2B Control Unit exposes all information to the MOSAIC 2B Analytics Service in an easy-to-use format. The nature of this link would typically be a TCP/IP service available over the Internet and could be bi-directional when required. MOSAIC 2B Analytics service needs to send pre-processed analytics data to the MOSAIC-2B Player Platform, enabling the usage of the Visual Analytics application for micro-entrepreneur in offline mode. Thus, the MOSAIC 2B Analytics Service will use this link also to send data files to MOSAIC 2B Control Unit that receives it and forwards to the MOSAIC 2B Player Platform through the DTN (interaction #5, #2 and #3)

This entry was posted in News, Uncategorized and tagged , , , , , , , , , , , , , , , . Bookmark the permalink.