Page tree
Skip to end of metadata
Go to start of metadata
On this page:

Latest Update: Template

Status: Draft, Final

Version: Add the version number of this document

IPR Mode: Options are RAND, RF-RAND, FCTL - this should be the same as the IPR mode of your project

In this deliverable:


Copyright © TM Forum 2016. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to TM FORUM, except as needed for the purpose of developing any document or deliverable produced by a TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in the TM FORUM IPR Policy must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by TM FORUM or its successors or assigns.


Direct inquiries to the TM Forum office:

240 Headquarters Plaza,
East Tower – 10th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page:

1.    Charter Identification 


Strategic Program or Industry


Smart Cities and IoT TMF Programme

Project Type:

 Catalyst Project

IPR Mode:


Project Name:

 Service Level Management of Smart City Ecosystems and Trusted IoT

Project Champion / Sponsor:


Expiry Date of Charter

Note: This charter is subject

to an annual review at which

time a decision will be made

to extend the work period

or terminate the charter

 July 2016

Project Leader / Chairperson

 Nektarios Georgalas, BT

Previous Project:

Note: Only applies if this is

the next phase of an older


2015 Catalyst: "Enabling the Smart City Digital Ecosystem"

2.    Project Details

<< This is a mandatory section to provide a VERY BRIEF description of the project by completing the sub-sections below.>>


2.1. Description of this project

This Catalyst builds on the live Smart City use-case of MK:Smart (Milton Keynes, UK) delivering SLA-enabled Data Hubs with the ability to provide trusted IoT and Service Level Management. In the previous TMForum Live 2015 Catalyst entitled "Enabling the Smart City Digital Ecosystem", we demonstrated how BT’s Data Hub approach enables Data-driven Smart City Digital Ecosystems supporting the collection, trading and monetisation of data and data-intensive services. However, an open question remained regarding how customers can trust Data Hubs and IoT to deliver information and services with SLA guarantees they can sufficiently depend on for the development of mission-critical applications. This Catalyst project achieves a world first in demonstrating new SLA-centred Data Hub capabilities to guarantee Service Level and Data quality. These new capabilities allow:

  1. Data providers to publish and charge for their data feeds based on different Classes of Service and data quality levels, for example, data granularity, accuracy, timeliness etc.
  2. Data consumers to order data feeds and services trusting Data Hubs and IoT will deliver them at a guaranteed SLA.
  3. Data Hub accountability mechanisms to impose contractual terms when SLA breaches are detected by issuing customer remuneration/compensations and punitive charges on authorities (e.g. Data Providers or Service Providers) responsible for service disruption
  4. Data Hubs to operate at high performance and resilience providing continuous service and ensuring Customer Apps using data feeds operate within the promised SLAs end-to-end.
  5. Data providers to offer data feeds with associated terms and conditions and privacy policies that the Data Hub ensures data consumers abide by.
  6. Data to be collected and actuators to be triggered securely by IoT gateways, preventing situations of hacking and spoofing by rogue devices.

2.2. Project Business Benefit

 What business challenge are you addressing (metrics/KPI targets)?

The first iteration of this Catalyst looked at monetization opportunities in smart city ecosystems — the Data Hub allows each party to define how they want to make money from their data. In this Catalyst we are looking at testing commercial viability and trust – both of which will be essential to making a smart city data economy a reality. For this we have introduced Service Level Agreements, SLA analytics and accountability/monetisation and Trust/Privacy/Security features into the Data Hub, which are described in more detail below.


What technical challenges are you addressing?

There are two main technical challenges we tackle in the catalyst described by the following two end-to-end stories:

  • Delivering end-to-end SLAs covering three parts:
    • data providers offering data feeds with guaranteed Classes of Service,
    • Data Hub to make it reliable and scaleable at delivering data to customer apps and
    • customer apps performance which are hosted at the Data Hub data centre due to their need to be co-located with the data, e.g. big data analytics apps, and contend for infrastructure resources.
  • Ensure end-to-end trusted and secure delivery of sensor data


Core Message/Supporting Statement

  1. Data providers can board their data feeds on the hub with guaranteed classes of service
  2. Achieve SLAs for applications dependent on the data and optimise Data Hub IT resources to serve those applications
  3. Customers should trust the data is securely collected by IoT and should abide by Data Provider's Terms and Conditions (T&Cs) and privacy rules.


Proof Points in catalyst that support core messages

1. BT's Data Hub supports boarding of Data Feeds with different Classes of Service which are being charged at different price levels, monitoring data feed SLAs using SLA analytics and accounting for SLA breaches with customer refunds and provider penalties issue.

2. Cloudsoft's Application Management Platform (AMP) is used to orchestrate Data Hub components for auto-scaling and high availability of the Data Hub service to customer applications. Additionally, for Customer Applications hosted on Data Hub's premium infrastructure, Cloudsoft's contention management capability co-ordinates the use of

3. Huawei's IoT platform ensures secure collection of data only by authorised sensor and gateway devices, while BT's Data Hub allows Data Providers to impose their Terms and Conditions (T&Cs) and own privacy rules to determine who is authorised to access and how they can use the data from the hub.


How is this Catalyst technically innovative?

Service Level Agreements 

The new data economy means that applications and businesses may well rely on the data being provided through the Data Hub. Thus, the Data Hub should provide SLA guarantees to customers. The project develops implicit mechanisms to ensure the data hub platform is stable and reliable providing continuous service to customers through high performance and high availability mechanisms. Additionally, the data hub allows data providers expose guarantees for their data feeds delivery augmented with Class of Service differentiation, i.e. for the same data feed charge more for high sampling frequency data stream or for higher-speed data delivery. The Data Hub has also SLA analytics and accountability features for SLA monitoring and SLA breach detection such that should any authority (e.g. data hub service provider, data provider, network provider etc.) fall short of the agreement, it can can automatically calculate and apply customer compensations and data or service provider penalties.

Trust, privacy and security

Data providers offer data feeds with associated terms and conditions and the Data Hub ensures data consumers abide by these. Additionally, data providers can impose privacy rules on their data feeds, assigning who is authorized to access their data and with what conditions. Data providers also ensure that data collection is secure, allowing only authorised devices (e.g. sensors, gateways) to connect to the platform and rejecting ‘rogue’ devices, which could send false data.

How is this Catalyst commercially innovative?

The Data Hub approach not only does it enable the use of data, but also addresses how to monetise the data, applications, and related services, amidst a complex ecosystem of partners- this is the primary challenge of this Catalyst project. We achieve this using the concepts of the “Virtual Service Provider”  (VSP) and the “Virtual Service Operators” (VSO). This uses technology from BearingPoint called Infonova R6, which runs within BT’s Compute Management System (CMS), and  is based on TM Forum standards. The VSP acts as the procurement platform, buying in data and services for the Data Hub. These are then in turn delivered to VSOs who aggregate and sell these to end customers using their own commercial offerings and pricing- which may be applications, analytics, or even white labelled data hubs using their own brand. The Ecosystem Platform handles all the accounting, billing, cost and revenue allocations within the ecosystem- enabling the ecosystem to operate commercially. This provides tremendous commercial flexibility – where the ecosystem platform provider can enable any organisation to use Data Hub services, to contribute to Data Hub services, or to become their own commercially operable Data Hub.

Furthermore we monetise Data Feed SLAs. A data provider may offer each data feed with various Classes of Service (CoS), each CoS being charged at different price levels. For instance, the same data feed at bronze CoS, providing historic data with 24 hours delay, could be offered for free, at silver, providing 1 data point per hour, could be charged X and at gold, providing 1 data point per minute, may be charged Y. If CoS guarantees are breached our commercial model works out customer refunds and compensation for data loss and penalties by accounting for the SLA responsible partner and for the revenue split between the partners involved in the end-to-end service delivery.

Which Collaboration project are you associating with your project?

This Catalyst is associated with the TMF's Smart Cities Strategic, Open Digital Ecosystems (ODE) and Internet of Everything (IoE) strategic programmes.


How will the champions validate the solution and results?

The Catalyst builds on the live Smart City use-case of MK:Smart (Milton Keynes, UK) delivering SLA-enabled Data Hub capabilities. These capabilities are developed in a pre-production environment with intent on being released live with the next MK:Smart Data Hub release for trials in Milton Keynes.


If this project is successful, what are the next steps?

Next steps to the Catalyst work should look to:

  • expand the types of SLA supported by the Data Hub, e.g. guaranteed data delivery, delivery speed, levels of security etc. This way the Data Hub will provide various "canned" SLA templates to Data providers for them to use and tune accordingly in order to define the different Classes of Service for each Data Feed service provided via the Hub.
  • deliver coherent End-to-End Application-level SLA Orchestration looking at controlling and co-ordinating all aspects influencing SLA in concert across the Smart City Digital Ecosystem partners including IoT/sensors networks provider, data providers, network service providers, data hub service providers etc. 
  • standardise the billing models for SLA accountability regarding customer remuneration/compensations and provider punitive charges resulting from SLA breaches.
  • standardise new partnership models emerging by the development of these new SLA-centred Data Hub capabilities in the Catalyst.


What TM Forum assets are being used? List, be precise and show value derived

The detailed Catalyst relationship with TMF assets and the exact way they are used are described in depth in the B2B2X template slides which are made available for access on the Catalyst's Confluence website. Briefly, the TMF assets used are:

  • B2B2X Business & Partnering Model:

The business model of MK:Smart is documented using the business model canvas.  There are well-defined partnership component models (business model, contractual model, financial model, operational model). The detailed MK:Smart partnering model design can be viewed in the B2B2X template on the project's confluence site.

  • DSRA Architecture Blueprint:

MK:Smart is designed to be deployed on BT’s Cloud Management platform (CMS) - this platform provides a comprehensive set of platform functions according to the DSRA (see B2B2X template slides for detail).

  • Core Frameworx:
    • eTOM:  MK:Smart is leveraging the end-to-end processes of Infonova R6
    • SID:   The MK:Smart data model is implemented in R6 (for product and customer domain in particular) aligned with the SID
    • TAM:  MK:Smart is built on a TAM compliant functional architecture
  •  APIs:

MK:Smart is using REST API for internal and external interfaces. For details please check the B2B2X template.


What will be contributed back into TM Forum collaborative process? List, be precise and show value expected

 We intend to deliver the standardisation work mentioned in next steps above through collaboration with the appropriate TMF teams in order to enrich existing or produce new specifications, including the Digital Ecosystems/Digital Services team and the SLA Management Framework team. 

More specifically, we would like to work with the TMF SLA Management Framework team and contribute back to the community types of SLA encountered in the IoT space, an area which has been currently identified as missing from the framework. The Catalyst project will show an example SLA type based on frequency of datapoints sampled. However after TMForum Live we want to study what wider set of SLA types is typical and useful in Smart City and IoT environments and build features in the Data Hub offering SLA templates of the identified SLA types to help Data Providers define specific configurations for their Classes of Service at Data Feed porting stage.



2.3. Resourcing of Project


This is a mandatory section for each Catalyst Project.  The goal of this section is to clearly identify all the resources and skills required by the project to successfully deliver all the items listed in each Appendix to the charter.

This section identifies the human resources committed to participate in this work and the role to be filled by each participant. Unless otherwise noted, the level of commitment of all project participants is Best Effort.

At the time the charter is written, the individuals listed below are considered tentative participants. When the charter is approved, the tentative participants will be notified and they can “join” the project in the online community. From that point forward the project resources will be maintained and viewable in real-time.


Definition of Project Sponsor/Champion Role

Project Sponsor or a Champion role is usually taken on by a Service Provider, whose responsibilities include:

    • Confirming that the project solves a specific industry problem and the proposed deliverable would provide value for the industry.
    • Providing business requirements & clarifications
    • Providing feedback and help with the use cases within the project


There is no extra cost associated with being a Sponsor; however, those who are listed as Sponsors should be willing to commit to the time necessary to actively participate within the project as described above.


Resourcing of Deliverable(s)


<<List the resources that are committed to start the work for the deliverable or group of deliverables in this appendix.>>


Member Project Resources and Roles









(confirmed or tentative)

Project Leader

 Nektarios Georgalas



Marketing Lead

Nektarios Georgalas








Champion 1

 Nektarios Georgalas



Champion 2

Geoff Snelson

 Milton Keynes


Champion 3

John Reynolds 



Participant 1

 Andrew Thomson, Andreas Polz, Nico Mueller, Dirk Rejahl



Participant 2

 Duncan Johnston-Watt, Aled Sage, Graeme Miller, Ross Gray, Eleni Santorinaiou



Participant 3

Bradley Zili, Wenbing Yao



Participant 4

Matthieu D'Aquin 

Open University


Supporter 1





Supporter 2





3.    Project Deliverables

This is a mandatory section for each Catalyst Project.  The project deliverables for the project are introduced in the sections below, with the deliverables detailed in the associated Appendices, each of which is developed in a separate document but combined for easy display in the project area. Subsequent iterations of the deliverables can be submitted as amendments to the charter, thus allowing convenient in-project revisions as deemed necessary. Hyperlink appendix headers to corresponding appendices when added to the document.


3.1. Appendix 1.A – << Deliverables>>


The project deliverables for <<Team Name>> are introduced in the sections below.


Deliverable Type

Catalyst theatre presentation  

Deliverable Description & Purpose

To showcase the work of the catalyst  

Deliverable Work Stream Start Date

 January 2016  

Planned Approval Submission Date

 May 2016  

Work Requests To be Implemented






Deliverable will go to which Work stream?


Deliverable Type

 Catalyst booth presentation

Deliverable Description & Purpose

 Presentation and demos to showcase the Catalyst work

Deliverable Work Stream Start Date

January 2016

Planned Approval Submission Date

 May 2016

Work Requests To be Implemented






Deliverable will go to which Work stream?


4.    Additional Project Information


4.1. Project inputs & risks

4.1.1. Inputs to project

<< OPTIONAL Complete only if applicable -- this section should list and hyperlink the input specifications and artifacts on which this project will work during the term of this charter. >>

4.1.2.  Outside project scope

<< OPTIONAL Complete only if applicable>>

4.1.3. Risk Identification and Risk Mitigation

<< This section is OPTIONAL and should be used only to identify potential blocking items that require immediate attention. Note that in general, if there are risks related to lack of appropriate resources identified, this will result in the charter not being approved until such point as that risk is mitigated by securing the correct resource levels or by re-scoping the work to be appropriate for the known participants to complete in the timeframe. >>

Name of Deliverable and Risk Description



Mitigation Options

Risk Owner


High/Med/ Low

High/ Med/ Low




4.2. Interactions with other groups, projects & departments

4.2.1. Relationships to other TM Forum projects and Industry Groups

<< This section is to be used to identify the relationship that the project has, or plans to have, with other TM Forum projects and communities, what deliverables a project expects to receive from, and what items a project expects to deliver to other projects. If the project deliverables include work that relates to or enhances Frameworx or the framework elements (Application Framework (TAM), Business Process Framework (eTOM), Information Framework (SID), Integration Framework), the project is Required to call out the anticipated connection and contact the appropriate Frameworx projects. If the project deliverables include metrics or data analytics, the project is Required to call out the anticipated area of metric development and to contact the Business Metrics and Scaffold projects. >>

Internal TM Forum Projects

Relevant Deliverable

Description of to/From Deliverables

Associated CR/FR

(list or indicate if project expects to raise them)

Contact person







Relevant API

Description of to/From Deliverables

Associated API


Contact person








External Standards Organizations (SDO)

External SDO

Linkages and/or Scope of work

Liaison statement

(Required, in place, N/A )

Work Register

(Required, in place, N/A)

Contact person








5.    Administrative Section


5.1. Rules of Engagement

This project will operate under the terms set out in the Operating Guidelines with development following the process outlined in The Collaboration Program process and specific rules listed in the board-approved Rules of Engagement.

5.2. Approval Decisions

<<This section is completed by TM Forum staff during the approval phase>>


Approval Received

<< Yes/No >>

Date Approval Received

<< DD – Month - YYYY>>

Expiry Date of Charter

<< DD – Month - YYYY >>

Staff Support Assigned

<< Provides list of name(s) and details of availability >>

Additional resources supplied

<< Provide details >>


5.3. Document History

<< It is mandatory to complete this section each time a modification is made.>>














  • No labels