You are here

WP1 - Use Cases, Requirements and Architecture

Work package title: Use Cases, Requirements and Architecture
Start date or starting event: M1
Activity Type: RTD
Leader: ETH - Brian Trammell


This WP elaborates the architecture and ownership model for the measurement plane to be developed during the course of the project, based on a set of use cases defined in the same WP. The objectives of this work package are:

  • The definition and complete description of at least five different use cases to address the main applications and the mPlane beneficiaries to be served by the mPlane platform.
  • The specification of a set of functional and technical requirements to be met by the platform architecture, as well as by the design and implementation of each component.
  • The specification of the architecture for the mPlane platform, including all components and the interfaces between them.
  • The definition of a possible ownership model that specifies how data, knowledge and machines can be shared among mPlane adopters.
  • The detailed design of protocols and interfaces to be used among the components of the platform, including implementation of common protocol code for component development.
  • The design of access control and data protection mechanisms and processes to be applied across the all mPlane components and interfaces.
  • The definition of a User Interface to control, configure and interact with the mPlane system.

Description of work

The workpackage contains four tasks:

 Partners contribution

  • ETH (WP leader) will lead the work package, tasks T1.1, T1.2, and T1.4, and edit deliverables D1.1, D1.3, and D1.4. ETH will thus contribute on all WP topics
  • POLITO will work on T1.1 by helping defining use cases, especially working in the change detection use case. In T1.2, POLITO will contribute to the definition of the probe architecture especially focusing on passive probes.
  • FUB will work on T1.1 and T1.2 especially focussing on the SLA certification use case and on the active probe architecture definition.
  • SSB will work on T1.3 on access control and data protection, providing both theoretical work and actual implementation of the primitives suitable to the task to be linked with WP2.
  • TI will work mainly on T1.1 (from an operator’s point of view all the use case defined are interesting), especially focusing on metrics definition. TI will also contribute to T1.2 and T1.3 with ISP requirements.
  • ALBLF will work on T.1.1 to define the use cases related to “Troubleshooting the Cloud”.
  • EURECOM will work on T1.1 on the definition of the use case about QoE measurements and troubleshooting, and in T1.2 on the definition of the architecture related to the Repositories, linking its definition with activities on WP3.
  • ENST will work on T1.1 (especially on correlation of QoE with QoS)  and T1.2 (especially on mPlane probes and Supervisor design) and overview T1.4
  • NEC will lead the definition and elaboration of the use case “Troubleshooting the Cloud” and contribute to the architecture specification of the continuous measurements.
  • TID will work on T1.1 (especially on the smartphone scenario) and the rest of the tasks to ensure smartphones can be natively accommodated by the mPlane architecture.
  • FW will work mainly on T1.1 (from an operator’s point of view all the use case defined are interesting), especially focusing on metrics definition in cooperation with TI.
  • NETVISOR will work on use cases esp. the QoE one. In T1.2 NETVISOR participates in probe design, and provide implementation services in T1.4
  • FTW will contribute to tasks T1.1 and T1.2, both regarding the definition of use cases (particularly regarding QoE measurements and troubleshooting, smartphone scenario, and changes detection) as well as to the specification and requirements of mPlane architecture (particularly regarding the Supervisor and intelligent reasoner).
  • FHA will work on T1.2 in the definition of the architecture, with special interest on the active probe design and interfacing with external repositories.
  • ULG will cooperate in the definition of the architecture with special attention to T1.3 on the access control and data protection
  • ALBELL will work on T1.1 and cooperate with POLITO to define the anomaly detection use case.


The work package will produce four deliverables, which taken together will comprise the architecture manual for the mPlane platform. In addition to providing a point of coordination among mPlane consortium members, they will act as a source for any standardization or dissemination efforts leading from the architectural work in the project.

  • D1.1 (M3; editor: ETH): Use Case Elaboration and Requirement Specification. This deliverable is meant to be Public. It details the selected use cases and the rationale behind their selection. Each use case identifies the data to be collected and the knowledge derived therefrom, the beneficiaries served by the use case, and the various entities involved in the measurement. From these use cases, specifies a set of requirements applying to the whole mPlane platform, organized into functional requirements (i.e., the actions each component must support) and technical requirements (i.e.. “how” each action must be done, e.g. performance constraints, security requirements, etc.).
  • D1.2 (M9; editor: SSB): Specification of mPlane Access Control and Data Protection Mechanisms. This deliverable is meant to be Public. Details the design of access control and data protection mechanisms and interfaces to be applied across the platform, additionally describing the considered ownership model for mPlane adopters. The mechanisms and interfaces will draw from a comprehensive analysis of the present state of the art, and follow current best practices in the area.
  • D1.3 (M12; editor: ETH): mPlane Architecture Specification. This deliverable is meant to be Public. Drawing on the requirements identified in D1.1, provides a detailed specification of the responsibilities of each component of the mPlane platform and the interfaces among them. To the extent possible, these interfaces will be drawn from existing standards, and/or designed to meet industry best practices.
  • D1.4 (M24; editor: ETH): Final Requirements, Architecture, Access Control & Data Protection, Interface Specifications. This deliverable is meant to be Public. Based on the design and implementation experience of the consortium partners with the mPlane platform, this document reviews the requirements, architecture, and data protection methods defined within this work package, evaluating them for suitability and updating them as necessary to account for new developments during the project’s second year, both within the project as well as in the state of the art. This document also contains the final specification of the interface protocols used within the architecture.