We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.I2ND.CDI - FIWARE Forge Wiki

FIWARE.OpenSpecification.I2ND.CDI

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.I2ND.CDI
Chapter I2ND,
Catalogue-Link to Implementation [N/A ]
Owner INTEL PERFORMANCE LEARNING SOLUTIONS LIMITED, TELECOM ITALIA S.P.A., FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V. and UNIVERSITA' DEGLI STUDI DI ROMA "LA SAPIENZA",

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright

Legal Notice

Please check the following Legal Notice (essential patents license) to understand the rights to use these specifications.

Overview

The Connected Devices Interface (CDI) Generic Enabler (GE) provides to FI-WARE chapters and Use Case Projects applications and services, the means to detect and to optimally exploit capabilities and aspects about the status of connected devices, through the implementation of interfaces and Application Programming Interfaces (APIs) towards device features.

The term “connected devices” refers to a broad range of networked electronic components, including Handsets (cellular phones, smart phones), Tablets, Media phones, Smart TVs, Set-Top-Boxes, In-Vehicle Infotainment, Information kiosks, each being able to connect to a communication network.

The CDI is a GE located in the connected device, as shown in the figure below, with the aim to provide common APIs for exploiting device capabilities, resources, contextual information and contents to network services and developer’s applications.

Connected Devices Interfacing (CDI) target usage
Connected Devices Interfacing (CDI) target usage

The CDI GE open specifications expose API to access connected device features and provide them to applications which execute on the device (On Device Access), including for example battery power, network status, location systems, quality of service, media capabilities, phone available features and sensors, profile information and status information. Moreover, additional APIs will detail how connected devices can be accessed via a Remote Management service (via a REST API).

Also, the network operator can exploit the CDI API to remotely manage the parameters used by the device for establishing the connection to the network such as policies for access network discovery and selection, attachment and connectivity policies, as well as management of the Quality of Service control and in-device routing policies in order to enable the mobile device to best match and react on its own to contextual situation (e.g. coexistence of Wi-Fi and 3G coverage, usage of another connection over another access network for better QoS etc.). The result is that end users can enjoy their favourite contents, anywhere and anytime, using their preferred apps across heterogeneous networks and connected devices.

This means that same applications and network services can be used consistently over dissimilar connected devices, if they are equipped with the CDI. Moreover, apps provided by FI-WARE application developers will be able to exploit capabilities and features a specific device platform can provide. This allows cloud hosted application services for example, to render their interfaces to make best use of individual devices and their relative connectivity. To realise this, the CDI GE offers a uniform and standardized access and easy portability across multiple device classes of the mentioned features.

To look at this in terms of practical benefits, a hypothetical scenario may involve a cloud-hosted media rich service accessible by many consumers across fixed or mobile terminal devices. The service provider may want to ensure that all consumers get the best possible experience, as a function of their connectivity, the display and processing power (noting remaining battery power) of their device. So, by programmatically enabling the service with the ability to detect relevant details of the client device and its connectivity, decisions may be made at run-time in terms of selecting different levels of media ‘richness’ including sizing, resolution, 2d or 3d, etc., for individual users.

Another example might relate to location-based services, where the location of the device (shopping mall), might be a useful indication of the customer’s intention and then, suggest useful sidebar links in the form of advertising offers. Yet another one might be the availability of triaxial accelerometers on the device combined with a user profile indicating a preference for this as a user input modality, which could be comprehended directly into the rendered UI configuration of a service.

Basic Concepts

A major challenge to be faced when defining CDI GE specifications, is to provide common interfaces to devices functionality required by the application developers perspective. In fact, it is recognised that the extreme fragmentation of platforms adopted for connected devices, including a variety of different OSs and programming languages, is introducing several troubles to develop once for all the application and make it run on all these devices. While applications development can exploit different programming paradigms (native versus interpreted versus scripting applications), the CDI GE specifications attempt to find a convergence point at least on the interfaces. The basic assumption for the definition of CDI interfaces is that they are defined as independent as possible from specific technology implementation and programming paradigm, thus creating a layer on top of the technology dependent architecture of the devices, which enables communicating with the applications and the network services.

Supporting different devices for different uses and purposes (in the following referred as form factors) is central to CDI GE, therefore the exposed interfaces provide an abundance of features and platform discovery functionalities.

Architecture of CDI

The CDI is unique in FI-WARE as it creates an execution environment for applications on connected devices, and supports the inter-GE communication throughout FI-WARE. There are three main interfaces presented by the CDI Generic Enabler. These are:

  1. On Device Interface
    This interface supports applications (apps) running on the connected device. It presents a uniform set of functionalities across all connected devices, regardless of form factor.
  2. Distributed Compute
    The distributed compute interface provides an easy and convenient method for CDI based applications to communicate between cloud and connected device. It allows an application written for CDI to execute both on the connected device and on a cloud hosted device.
  3. Remote Management Interface
    The remote management interface presents an externally accessible interface which supports other Generic Enablers. It provides the following functionality:
    • Push Notification Framework
      It provides a push notification framework where external GEs can signal connected devices with information and data
    • Remote Device Management
      Configuring device and network settings
    Main purposes of the remote device management interface are to provide an access to CDI to manage:
    • Installation and management of configuration information (both initial and operational information) in devices.
    • Update of firmware and software
    • Retrieval of management information from devices
    • Processing of events and alarms generated by devices
    • Performing diagnostic tests
    • Controlling device capabilities
    The managed information includes e.g. configuration settings, operating parameters, software and parameters, application settings, user preferences.
  4. Mobility Manager Interface
    The mobility manager interface connects to the S3C GE in order to:
    • Receive network policies
      Based on available network interfaces the S3C GE can transmit policy rules to the devices, describing when to connect to which network interface.
    • Request network information
      In order to provide a specific QoS pertaining connectivity the mobility manager interface is used to request information about available network interfaces that meet certain connectivity requirements.


The high level architecture of the CDI is represented by the following FMC model.

CDI High Level Overview


Note: The "Non-CDI Generic Enabler" represents any other GE (Generic Enabler) or 3rd party server or cloud hosted service which needs to access the remote interfaces provided by the CDI GE. It is included purely for illustrative purposes only.

Main Interactions

For each of the three main interfaces specified for the CDI GE, the following sections will provide insights about their components and the interactions taking place among them.

On Device Interface

On Device APIs are aimed at providing applications with a common and homogeneous set of instructions to access functionalities natively supported by a wide set of devices. Applications are executed in a Web-RunTime (WebRT) since most of devices support, or at least are going to support, an environment (usually a browser) compliant with web technologies and languages (HTML5, CSS, JavaScript). These basic concepts can be mapped in the following refined architecture where main structural components and technical requirements are highlighted in order give a more comprehensive specification.

On-Device interface system architecture

Web applications

CDI based applications will be developed on top of web languages, therefore they will be interpreted and rendered by a WebRT provided by the CDI enabled device. Applications can be displayed in a web browser, or alternatively within a native standard view as usual for native applications. The CDI frontend enables applications to discover the availability of all APIs they depend on and use them by means of easy to use JavaScript calls.

CDI frontend

This is the interface point between applications and the CDI system. It offers a common powerful interface that abstracts a broad set of devices. Since the addressed set of devices is wide, the frontend API also supports service discovery routines, in order to discover whether required functionalities are effectively provided by the native platform. If APIs are available the application can easily perform invocations and get replies back from the native software. Invocation replies are delivered as asynchronous callbacks, which is definitely in line with the nature of web based applications (JavaScript programs run in a single thread, which discourages the use of synchronous (blocking) calls). The CDI frontend makes use of a messaging system in order to bring invocations out of the WebRT.

Messaging system

This layer offers an API for the CDI frontend to exchange messages with the underlying system. Such messages bear API calls (top-down direction) and callbacks (bottom-up direction) generated by applications while using the CDI API. Communication is supported by an Inter Process Communication (IPC) channel that interconnects components in the WebRT with an API message Handler aimed at providing delivery of the API calls to demanded "glue" components. This handler also enables asynchronous callbacks to transit back to applications through the IPC pipe.

Backend modules

Each of these modules is responsible for a single API functional block (i.e. Sensors, QoE etc.) and act as glue between the non-native (JavaScript) and native contexts. Backend modules receive API call invocations by the API message Handler, dispatch them at low level and generate callbacks upon responses of the native software.

On Device API functionalities

The following is a detailed description of the functionality supported by the interfaces accessed through the On Device Interface. . Each group of functionality is further subdivided into Functional Blocks.

Device Sensors

All connected devices targeted in FI-WARE contain a range of sensors which can provide useful functionality to application developers. CDI will support the following four sensor types:

  • Camera
  • Microphone
  • Geo-Location
  • Device Orientation & Accelerometer

The interactions with the sensors are broken out into functional descriptions below. A description of the interfaces provided to the developer is also supplied. These functional blocks are available on all devices which support these sensors types. Not all devices may support them, therefore the specification of a sensor discovery functionality is also supplied.

  • Camera
    The camera interface allows the developer to capture images and video.  Devices often have more than one camera. The interface enumerates the available cameras and allows the developer to select the camera to use. For developer convenience the interface defines a default, implicit camera for use when an explicit camera is not specified by the developer.
    User authentication: The user will be prompted for permission the first time the application requests to use the camera. If the user allows the application to access the camera, then all subsequent requests will complete without prompting.
  • Microphone
    The developer will be able to write applications which can record audio. Devices can support more than one microphone. The interface enumerates the available microphones and allows the developer to select a microphone to use. For developer convenience the interface defines a default implicit microphone for use when an explicit microphone is not specified.
    User authentication: The user will be prompted for permission the first time the application attempts to record audio. If the user allows the application to access to the microphone, then all subsequent access attempts will complete without prompting.
  • Geo-Location
    The application developer is able to retrieve information about the devices location. This includes the longitude, latitude, altitude, and speed. This API provides both a polling format, where the developer can simply request the current location, and a notification format where the developer can be informed when the location or speed changes. This notification framework will provide the developer with a range of friendly methods for monitoring the devices location.
    User authentication: The user will be prompted for permission the first time the application requests Geo-Location. If the user allows the application to access the geo-location, then all subsequent requests will complete without prompting.
  • Device Orientation & Accelerometer
    The developer will be able to capture information on the devices orientation (compass) and physical orientation; rotation on the x, y and z axes. The accelerometer information provides the developer with notification of orientation or rotation changes. Again, this call back / notification framework provides a battery of friendly methods for detecting changes in the devices position.
    User authentication: No user authentication is required to capture the device orientation & accelerometer data.
  • Sensor Discovery
    The developer will be able to obtain information on the sensors available to the device.
    • Camera
      Information about the camera includes, the number of cameras, camera placement (front, back, unknown) camera resolution, and flash support. Additionally, capture capabilities of the camera are also be provided, including:
      • What image formats are supported
      • Is video capture supported
      • What video capture formats are supported
    • Microphone
      Information on the microphone includes the number of microphones, their placement (on device, or on a headset), encoding support (what formats are supported).
    • Boolean values exist to determine if each of the following is supported:
      • Device Orientation (Compass)
      • Accelerometer
      • Geo-Location

Quality of Experience (QoE)

All devices equipped with a Web Run Time can provide useful QoE control functionality to application developers. The QoE control functionality is provided by the QoE Engine functional block. This functional block is able to combine explicit QoE feedbacks (in form of clicks) coming from the user, with the QoS level provided by the network. Both inputs are matched against a target QoE level to be achieved, and network resources are explicitly requested in order to approximate the target as much as possible. For what concerns interfaces, a mobile application developer will be able to instantiate a graphical object (i.e., a button), logically related to an application flow (i.e., audio, video, file transfer etc.), allowing the final user of the application to express his current degree of satisfaction (QoE) while enjoying the service. The application developer can use an interface with the following functionalities:

  • Provide QoE feedback
    To be used by the application developer to inform the underlying QoE framework, that the user is expressing a bad QoE feedback. This functionality must be attached to a button. Ideally, the user is more unsatisfied, as the number of clicks on the button increases. The QoE Engine is also able to distinguish unfair and wrong calls of the functionality, performed respectively by malicious and incapable users.
  • Start/Resume QoE monitoring
    To be used by the application developer to inform the underlying QoE framework that a new application flow has been started or that a paused application flow has been resumed. The effect is that the QoE Engine starts/restarts monitoring the flow.
  • Pause QoE monitoring
    To be used by the application developer to inform the underlying QoE framework that the application flow is not currently under the attention of the user. For instance, when the window passes in background, or when a pause button is pressed.
  • Stop QoE monitoring
    To be used by the application developer to inform the underlying QoE framework that the application flow doesn't need to be monitored anymore. For instance when the window is closed, or when a stop button is pressed.
  • Express Mean Opinion Score (MOS)
    A developer can decide to provide the user the possibility to express a final rating for his experience. There are five possible ratings (EXCELLENT, GOOD, FAIR, POOR, BAD). The MOS rating will enrich the Context database maintained by the QoE framework running underneath.
  • Track the real-time evolution of QoE parameters
    The application developer has the possibility to track in real-time the evolution of QoE parameters related to the users. For instance the developer can track the Click Rate of the user and show it on the screen. Other possibilities include tracking the real-time evolution of the allocated bandwidth for a given network flow.
  • Configure the network controller
    The application developer can use this functionality to choose among different implementations of network controllers, in charge of gathering information about network flows and applying the QoS rule defined by the QoE Engine. If no network controller is available, this feature can be disabled.

User Profile

This set of interfaces provides the connected device applications a means to access user identification and authentication procedures.

  • Access to local and personal device data
    Each of the functional blocks that expose PII (Personally Identifiable Information) such as photos, contacts, camera, etc, has a separate User authentication step. In this separate user authentication step the user receives a prompt requesting them to grant an application access to a functional block. Prompting the user, every time an application attempts to access a PII functional block, would result in multiple recurring prompts. This would make applications which access these functional blocks impossible to use. To balance the need for user awareness of an application's behaviour with the need to provide a consistent and appealing user interface, the CDI will prompt the user initially and only once. Subsequent accesses to a functional block by an application will no longer result in a user prompt.
    If the user declines an application's request to access a functional block, then the application will receive an error message informing it that it does not have permission to access the functional block.
    User authentication: Please refer to the "User authentication" descriptions provided in each of the functional blocks described.
  • Security and Sign on
    Devices may be used by more than one person. In order to offer a secure, safe, and personalised experience it is often important to know information about both the device and the currently active user. To facilitate that, CDI enforces a user identification process. Users will need to identify themselves to the CDI, and once identified (signed in) the CDI will assume that this same user is continually logged in, in perpetuity. Via a prompt, the user may explicitly sign out (log out). If no user is currently signed in (identified) to the CDI, then the client will display a sign in page. The user's account will be protected by a password. Once logged in, the user will have the ability to change this password. The password will be associated with the user's device, and optionally an email address. When an incorrect password is entered, an error message will be displayed. The error message will invite the user to try again. If users forget their password, they may reset the device, losing all information stored on it, and create a new user account via the initial start up scenario.
    User authentication: The CDI supports an initial start up scenario where no user is associated with a device. In this case, the user is invited to create an account on the device. Once this is done, the only way the user can access CDI functionality is to ensure that they are signed on. Once signed into the CDI, the user's stored credentials can then also be used to grant them access to resources stored within other generic enablers. This provides them with a SSO (Single Sign On) experience.
  • Access to User Profile Information
    To ensure a personalised experience, the developer may obtain information about the currently signed on user. This includes user data like Gender, Date of Birth, Home address, Telephone numbers (mobile, home, work etc), Email addresses, IM details, User profile photo, and Full name.
User authentication: The user will be prompted for permission the first time the application requests to access her profile. If the user grants access then all subsequent requests will complete without prompting.

Device Features

Application developers need to understand the limitations and opportunities presented to their applications by the devices upon which they run. Information describing the device is presented to the application, to allow the application to tailor itself accordingly. Likewise, any requests by the CDI device to other GEs via a RESTFUL interface also include enough information to allow the cloud hosted component to tailor its response to the device. Therefore the functional blocks below divide this task into two segments, "On Device Profile Information" and "Off Device Profile Information".

On Device Profile Information
Applications running on the device have access to the following information:

  • Device form factor. A boolean value for each of the following indicating that the device is: a phone (phone like - supports calling), a Tablet, a PC, a Set top box, an in-car system
  • Screen size. The screen is described using numeric values indicating: the screen size (width x height), the colour depth (bit depth), the DPI of the device (pixels per inch)
  • Available Inputs. The available input methods are described by (boolean) values indicating: Touch screen support, Hardware QWERTY keyboard, On screen keyboard, Numeric keypad (T9), Stylus support.
  • Processor Type. Details about the processor are provided to the application. This includes an enumerated value indicating the processor family (e.g. X86, ARM, Other), an enumerated value indicating machine word size (e.g. 32bit or 64bit), an integer value representing the number of cores.
  • Available Disk (Storage) Space. During the lifetime of almost any application, the need will arise to utilise disk space, either for the download of content from the cloud / internet or the storage of locally produced content.  Storage will be described by integer values representing the total size of the disk in bytes, total number of bytes consumed, the total number of bytes available.
This information allows any application to adapt itself to the actual state of the disk of the device.
  • Connectivity. The network connectivity of the connected device is provided to the developer. This is expressed in two forms, firstly as the available connectivity options, and secondly as the currently connected (if any) connectivity options.
    • Available - Multiple boolean values indicate the presence of the following technologies: Wi-Fi, Bluetooth, Cellular
    • Current - A list of the currently connected technologies is provided. For each entry in the list of connected technologies, the signal strength is expressed as a percentage. Multiple triples of one boolean, one integer and one floating point value indicate if the technology is connected (boolean), its signal strength (integer) and its estimated bandwidth in MB/s, where zero MB/s is used when the technology is not connected. Applies to the following technologies: Wi-Fi, Bluetooth, Cellular
  • Battery State. The state of the battery can be used to tailor applications and services, allowing application to throttle their behaviour when in low power situations, in order to allow the users to continue using their device for longer. The battery information will be provided to the application as follows:
    • A (boolean) value indicating if the device is currently charging
    • A (integer) value representing the length of time remaining before the battery is completely discharged
    • A percentage value indicating the current battery charge state
  • Media Services Support (see "Discovering Media Features Supported")
  • Device Sensor Support (see "Sensor Discovery")
  • Personal Data Interface Availability ( see "Personal Data Interface Availability")
  • Messaging Interface Availability (see "Messaging Interface Availability")
    User authentication: None


Off Device Profile Information
The following details will be provided to other GEs or cloud devices when requesting services. For complete details, see above.

  • Current connectivity
  • Media Services Support For Consumption
  • Processor Type
  • Screen size
  • Device form factor
    User authentication: None

Media Services

In order to offer the best possible media experience on the device, it is important to understand what media formats and codecs the device can support. Usually, devices can play back more codecs than they can record or produce. This explains the following functional blocks.

  • Discovering Media Features Supported For Consumption
    An array of mime types will be used to describe the media formats supported for media consumption. This will be similar to the standard HTTP accept header.
    User authentication: None
  • Discovering Media Features Supported For Production
    An array of mime types will be used to describe the media formats supported for media production.
    User authentication: None

Personal Data Services

Getting access to personal data on a device opens up a wide range of possible applications. It also allows applications and devices to integrate seamlessly with cloud hosted services. In order to support this, the following functional blocks have been created.

  • Contacts
    For any communication devices, from a PC running an email client to a mobile phone supporting voice calls, an address book or storage of contacts and their details is vitally important. This functional block supports this by enabling an application to search for contacts, read contact details, update contact details (change, add and remove fields on a contact), and delete a contact entry.
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.
  • Calendar
    Many devices also act as personal organisers for the user, and are able to access and interact with the daily schedule, which provides scope for a wide range of personalised experiences. CDI provides an interface to the developers allowing them to both read and write calendar entries. However, devices can support more than one calendar, e.g. the user's calendar from work, and a calendar for home. CDI will enumerate all the available calendars on the device and provide context information for each one, allowing developers to select the most appropriate calendar for editing.
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.
  • Gallery
    Galleries offer access to a collection of digital visual media stored on the device, which includes both images and video clips. The gallery interface allows an application to search for media based on production date, displayed based on either ascending or descending order in a UI based "picker". An array of URIs representing the media elements selected by the user is returned to the application.
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.
  • File System Access
    All devices have a file system, or file like system. Access to the file system facilitates the creation of a wide range of applications and services. This functional block allows an application to read the contents of directories, search directories for files, navigate directories, rename files, read and update file attributes, read and write a file's binary data.
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.
  • Personal Data Interface Availability
    Not all devices will support all of the functionality provided by Personal Data Services. Therefore, a discovery interface will be provided allowing an application to query the device for supported functional blocks. The supported functional blocks will be expressed as a collection of (boolean) values including contact support, calendar support, gallery support and File System Access.
User authentication: N/A.

Phone

It is important that applications running a device can leverage the power and facilities offered by the device. An application running on a phone should be aware of it and be able to access phone status and/or operations. The functionality presented in the functional blocks below is available when the boolean value indicating that the device is a phone is set to true (on). The blocks break the functionality up into two segments, monitoring device status and using phone operations.

  • Phone Status
    Before invoking any functionality it is important for the application to be able to assess the current state of the device. This can be implemented e.g. through an enumerated value, which can be used to identify the phone state as Engaged, Ringing, Dialling, InCall or Idle. The interface also allows the application to monitor the device for changes in state. If the device is currently in the Engaged, Ringing, Dialling or InCall state, then the application will also be able to query the device for the destination phone number of the call.
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved, all subsequent requests will complete without prompting the user.
  • Phone Operations
    The following functionality is supported by this function block:
    • Make Call: the application may invoke a new call
    • End Call: the application may end a call which is in progress
    • Answer Call: the application may answer an incoming call
    • Reject Call: the application may reject an incoming call
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.

Messaging

Increasingly, devices come equipped as standard with communication technology. Consequently, it makes sense to offer that functionality to application developers, where possible. This group of functionality deals with Email, SMS and MSS messaging.

  • Email
    This functional block will allow the application to compose emails on behalf of the user.
User authentication: The application may compose and address the email, however sending the email will require direct input from the user.
  • SMS
    This functional block will allow the application to compose SMSs on behalf of the user.
User authentication: The application may compose and address the SMS, however sending the SMS will require direct input from the user.
  • MMS
    This functional block will allow the application to compose MMSs on behalf of the user.
User authentication: The application may compose and address the MMS, however sending the MMS will require direct input from the user.
  • Messaging Interface Discovery
    Not all devices will support all of the functionality provided by the messaging interface. Therefore, a discovery interface will be provided allowing an application to query the device for supported functional blocks. The supported functional blocks will be expresses as a collection of (boolean) values for Email, SMS and MMS.
User authentication: N/A.

Device Connectivity

Providing access to device connectivity allows a developer to create applications which can adapt to both the available band width and available access points. The following functional blocks allow a developer to discover the types of connectivity which are available on the current device. While cellular network connectivity is usually fixed by the network operator, the connection to Wi-Fi Access points is typically at a user's discretion. The functional blocks below provide additional functionality over Wi-Fi interfaces, to allow the creation of applications which can assist the end user.

  • Discovering Connectivity
    See Device Features - Connectivity (above).
  • Detecting Current Connection Settings
    See current connectivity under the device features group (above).
  • Wi-Fi Interfaces
    The application is able to see:
    • A list of currently available Wireless access points, their SSIDs and BSSIDs along with signal strength
    • The currently connected access point, its SSID, BSSID and signal strength
    • The application is able to disconnect from a currently connected access point or request connection to a new access point
User authentication: The user will be prompted for permission the first time the application requests use of this feature. If approved all subsequent requests will complete without prompting the user.

Distributed Compute

The distributed compute interface implements a client and server technology. This technology breaks an application down into a set of asynchronous functions, where each of the the asynchronous functions can be executed on any connected device or cloud based machine. The distributed compute interface connects client devices running CDI and server machines, which run a small distribute compute service together to in an adhoc and dynamic grid. The distribute compute implements the following functions:

  • Connected Device Communication
    Provides a common, easy to use method for connecting devices to the cloud.
  • Cloud and Client Workload Balancing
    Provides a way to share workload across client devices and cloud devices (virtual machines) treating each device in the same way.

Remote Management Interface

The CDI remote management interface implements a client according to the Open Mobile Alliance – Device Management (OMA DM) specification. The OMA DM Working Group (http://www.openmobilealliance.org/technical/DM.aspx) specifies protocols and mechanisms to perform management of devices. The evolution to OMA DM 2.0 is based on RESTful architecture, which is adopted for CDI interface specification. This makes the CDI interface more uniform with the remaining FI-WARE architecture, and provides a platform neutral protocol to allow servers to remotely manage devices, by operating over a HTTP transport and notification protocol.

This interfacing functionality is not available in the first release of the FI-WARE platform, and will be detailed in the final FI-WARE release.

Remote Management implements the following functions:

  • Device Configuration:
    Provides a common mechanism to remotely configure one of more settings of the device.
  • Firmware Update:
    Provides a common mechanism to remotely verify, download and install a firmware to the device.

Mobility Manager Interface

The main purpose of the Mobility Manager interface is to provide an access network selection function that empowers the CDI device to select network interfaces according to the connectivity requirements of CDI applications or by network operator policies. This access network selection is transparent to the applications.

  • S3C Interface
    The Mobility Manager component uses and extends the OpenEPC platform, which is part of the S3C GE, addressing mobile devices with customized and optimized communication services, including the network status information from the device itself, as well as the information which is received from the network operator, such as the available resources in the vicinity of the mobile device.
    Therefore, the Mobility Manager provides a network interface to the S3C GE for the following functions:
    • Requirements on QoS
      Communication with the core network platform to receive extended information on the vicinity environment. This mechanism allows communicating requirements for the QoS/QoE of the connected devices.
    • Routing Policies
      Receive routing policies for policy based access network selection. This mechanism empowers the mobile device with the vicinity network status including access network discovery information, inter-system mobility and routing policies enabling the forwarding of the data traffic from the mobile device to the appropriate access networks.
    • Vicinity environment information
      Vicinity network information format to be transmitted from the network operator to the devices. This provides a mechanism to dynamically aggregate the information on the network status of the device including static and dynamic local information on the momentary active and potentially available device interfaces, and a common presentation mechanism of this information towards the applications.
  • Interface to Applications
    The Mobility Manager also exposes an internal API to CDI applications that provides the following functionality:
    • Request QoS level
      An application can request a specific level of QoS. This allows the application developer to adapt the connectivity of the device to the current needs of the running applications.
    • QoS Notifications
      An application can register as a listener for a specific kind of QoS level. The application then gets notified by the Mobility Manager if the QoS level becomes available and can react on the situation, e.g. start transferring data if more bandwidth is available.
  • Interface to QoE Component
    Furthermore, the Mobility Manager provides an interface to the QoE Engine component. The QoE Engine measures the QoE of applications and user and tries to adapt QoS parameter if the QoE is insufficient. Therefore, the Mobility Manager provides an interface that allows the QoE to use the following functions:
    • Application Monitoring
      The QoE Engine can monitor information of QoS parameter of a certain application. This information pertains to the connectivity status of an application, e.g. used bandwidth.
    • QoS Requests
      The QoE Engine can request a certain QoS level for a specific application. According to the measured QoE of an application, the QoE engine can invoke a change of QoS parameter in order to optimise the QoE.

Basic Design Principles

Since the beginning of FI-WARE activity, it was stressed that a variety of development paradigms and technologies are available to program and interact with different types of connected devices. The attempt made with the CDI Architecture specifications is to keep a high level of abstraction which should help us to avoid technology dependent definitions. It is however recognised that, when moving to a reference implementation, a specific programming paradigm has to be adopted. A number of emerging solutions for interfacing to device capabilities (and also for other functionality) rely on web based technologies, which are nowadays available on most terminals. This trend seems to favour the development of applications which can run on web browsers or runtime engines.

The architecture for the initial reference implementation of CDI will be designed to be a hardware and platform agnostic runtime, supporting developers in the creation of compelling user experiences across a range of heterogeneous devices via a common development and programming environment. The CDI implementation will therefore utilise a Web Run Time to offer a common programming environment across multiple devices and platforms. This Web Run Time (WRT) environment will be HTML5 and JavaScript based. Hence, the application developer will interact with the CDI implementation through them, as the APIs will be defined for such languages.

The CDI team seeks to build upon existing Web Run Time technologies. Therefore, rather than create a new platform, CDI implementation will extend existing platforms to deliver the required functionality. There are a number of complementary technologies in this area at various stages of development. The CDI aims to utilise current web standards or emerging standards. Therefore CDI will evolve over time to encompass the most promising WRT technologies.

Minimal Native Code

The CDI will support many different operating systems and hardware platforms. Normally supporting this variety of target platforms would require considerable effort in porting code between operating systems and hardware platforms. To minimise this developers contributing to CDI should try to write as much of their code as possible in a portable way. As CDI will ensure that every target platform has a JavaScript environment CDI contributing developers are encouraged to write as much of their logic as possible in JavaScript. This will ensure that a developer's contribution will be portable between the target platforms. Code not written in JavaScript should be kept to a minimum.

Standard Method of Supporting Native Code

A standard interface for connecting to the JavaScript engine exists. This provides a standard set of interfaces which all native code can use. This reduces the amount of porting required between platforms. This is required to support the components which must execute in a native environment. This includes a number of networking elements and low-level QoS / QoE metrics, which can only be gathered and managed by native code.

Limited API Exposure

The total number of APIs exposed to other GEs and application developers should be kept to a minimum, and should enable the scenarios and feature requirements provided by the Use Case projects, as well as by the FI-WARE team.

Interface Definition Tools

There are two main interfaces presented by the CDI GE, an On Device interface and an Off Device interface. Within the reference implementation, the On Device interface will be a JavaScript interface. The Off Device interface, which is accessible directly by other Generic Enablers, will be a REST based interface. These will be defined using the following definition languages:

On Device Interface Definition Language: WebIDL

WebIDL is the interface definition language of choice for JavaScript based environments. WebIDL was defined by the W3C standards body and has been used to define many key technologies. As CDI Generic Enabler aims for a JavaScript based implementation, all defined functional blocks will use WebIDL.

A full definition of WebIDL is available from the W3C web site at the following location: http://www.w3.org/TR/WebIDL/

Off Device Interface Definition Language: FMC

Interfaces which are accessible directly by other GEs and are not based on JavaScript shall be described using FMC (Fundamental Modelling Concepts). More details on FMC can be found here: http://www.fmc-modeling.org/


Detailed Specifications

Open API Specifications

Following is a list of Open Specifications linked to the CDI Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE. Specifications labeled as "DRAFT" are planned for future Major Releases of FI-WARE but they are provided for the sake of future users.



Re-utilised Technologies/Specifications

The CDI Component uses a range of existing technologies including, for a number of reasons:

  • W3C Specifications for Contacts, Get User Media, File API access etc
Used for API design and utilisation of existing specifications
http://www.w3c.org
  • W3C WebIDL
Used for JavaScript API definition
http://www.w3.org/TR/WebIDL/
  • Open Mobile Alliance – Device Management (OMA DM)
Used for the CDI remote management interface
http://www.openmobilealliance.org/technical/DM.aspx
  • Boot to Gecko
Used for API design and utilisation of existing specifications
https://wiki.mozilla.org/B2G
  • PhoneGap
Used for API design and utilisation, API comparison, and an initial run time environment
http://www.phonegap.com
  • Webinos
Used for API design and utilisation, API comparison, and as a runtime environment
http://www.webinos.org

Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions


  • Connected Devices: A connected or smart device can be an advanced device located at home, such as a set top box and multimedia device (including advanced TVs), PCs, storage (NAS like), indoor handset (home/advanced DECT), or game consoles. Furthermore, mobile devices, such as mobile/smart phones (GSM/3-4G), tablets, netbooks, on-board units, (in-car devices) or information kiosks are connected devices, too. It is very likely that new devices will appear and fall into this “smart devices” category during the project execution (femto cells, etc.).
  • Cloud Proxy: A device encompassing broadband connectivity, local connectivity, routing and networking functionalities as well as service enabling functionalities supported by a modular software execution environment (virtual machines, advanced middleware). The “Cloud Proxy” or “Home Hub” is powerful enough to run local applications (for example home automation related tasks such as heating control or content related ones such as Peer to Peer (P2P) or content backup). It will also generally include local storage and may be an enabler for controlling privacy as some content or data could be stored locally and could be controlled only by the user without having the risk of seeing his/her data controlled by third parties under consideration of the overall security architecture.
  • Open Networking: Open networking is a concept that enables network nodes to provide intelligent network connectivity by dynamic configuration via open interfaces. Examples for provided features are the fulfillment of bandwidth or quality requirements, seamless mobility, or highly efficient data transport optimised for the application (e. g., with minimum network resource or energy consumption).
  • Network Service: Network Service is a control and policy layer/stratum within the network architecture of a service provider. The Network Service provides access to capabilities of the telecommunication network, accessed through open and secure Application Programming Interfaces (APIs) and other interfaces/sub-layers. The Network Service concept aims at providing stratum that serves value-added services and applications at a higher application and service layer and exploits features of the underlying transport and technology layer (e. g. via NetIC interfaces).
  • Functional Block: A block of common functionality represented by a single API consisting of functions, objects and structures.
  • Mobility Manager: The component within the CDI GE responsible for managing connectivity with networks and data bearers
  • QoE: Quality of Experience; a measurement representation and assessment of the experience a user receives.
  • WebIDL: Web Interface Definition Language; the format used to express JavaScript or other non-REST based APIs.
  • QoS: Quality of Service; a measurement representation and assesment of the quality of data transmission a device / user receives over a network.
  • OpenEPC: OpenEPC is a prototype implementation of the 3GPP Evolved Packet Core (EPC) – Release 10 – that enables academia and industry researchers and engineers around the world to obtain a practical look and feel of the capabilities of the Evolved Packet Core. OpenEPC Rel. 3, the current version available, includes all the components of the 3GPP architecture including the interfaces with various access technologies and service platforms.
Personal tools
Create a book