Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

* indicates that this field is required

Project Name*Open Digital Architecture (ODA) Project
IPR Mode*

RAND

Explanations of each mode is available at http://www.tmforum.org/IPRPolicy/11525/home.html

Project Start Date*July 2018
Project End Date*February 2019
Type of Project*Development Project
Strategic Program

Operational Agility Program - Simplification, Automation  & Intelligence

Previous Project CharterODA Project Charter (R18.0) - A Core Project Area Charter
Project Workspace LinkOpen Digital Architecture Project Home
Project Sponsor*
 Project Team Lead*Ken Dilbeck
 TM Forum Staff Support

 

1. Table of Contents

2. Project Overview


Developing best practices and standards in certain fields greatly benefits from frequent joint work or exchange of live collaboration materials with other TM Forum projects. 

To facilitate low-friction collaboration between such projects, this RAND Project Charter is a member of a larger “Core Project Area” which holds the RAND Project Charters; Frameworx (Fx), Open APIs (APIs) & Open Digital Architecture (ODA).

The Core Project Area Project Charter may be seen here; Core Project Area Charter (R18.5) - DRAFT


ODA sets a new vision for operational and business support systems (OSS/BSS), and a de facto standard for the design of open digital platforms. ODA embraces fresh ideas and the latest thinking, with the ambition to deliver a model-driven and data-driven architecture that relies on the use of metadata, microservices and a clear set of normalized APIs.

ODA offers an industry-agreed blueprint, language and set of key design principles to follow. It will provide pragmatic pathways for the journey from maintaining monolithic, legacy software solutions, towards managing nimble, cloud-based capabilities that can be orchestrated using AI. It is a reference architecture that maps TM Forum’s Open APIs against technical and business platform functions.

By providing a clear statement of intent that technology suppliers can aspire to deliver, ODA is expected to streamline the procurement process for IT systems and remove friction from the supply chain. ODA will offer a standardized blueprint enabling vendors to participate in a marketplace for reusable solutions to common business challenges.

3. User Stories

Provide a high-level description of how an end-user might use the output of the project.

If desired, copy and paste the table below to create multiple instances of the table and complete it for each user story.

As a..
I need to...
So that I can...
To do this I need...

4. Dependencies

Add in other projects and Frameworx dependencies this project will have. Please enter if your project will require INPUT FROM, produce OUTPUT TO or require JOINT WORKING with the named projects/Frameworx. In the COMMENTS column describe the nature of the input, output or joint working.

Project NameINPUT FROM OUTPUT TO JOINT WITHCOMMENTS (describe nature of Input/Output/Joint)Project Contact (ODA)Project Contact (Other project)
APIJoint withDefine requirements and review deliverables Steve Harrop, Andreas Polz
CEMInput fromCustomer & Partner requirements Cecilia Ortega Lagos
Data AnalyticsInput fromData Analyics requirements Cecilia Ortega Lagos
IOE/Digital EcosystemsInput fromEcosystems requirements Nancy Lyness
Explore AIOutput toDefine requirements and review deliverables Cecilia Ortega Lagos
FrameworxInput from/Output to/Joint withWork with Fx team to define ODA components and Functional Framework Avi Talmor, Kaj Jonasson

5. Participants

This section identifies the human resources and skills required by the project to successfully deliver the items listed in this charter.  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.

* indicates that this is a required field or role.

RoleName*Company* Confluence “@” mentionComments
Project Team Lead*    
Project Co-Team Lead    
Mentor    
Sponsor*    
Participant*    
Observer    
Reviewer    
Subject Matter Expert    
Workstream Lead    
Staff    
    
     

 

Role Descriptions & Responsibilities given in section 11

 

6. Project Workstreams and Deliverables ODA-46 - Getting issue details... STATUS

The project workstreams and deliverables for this project are introduced in the sections below.

6.01. Workstream 1: Key Requirements & Principles ODA-48 - Getting issue details... STATUS

Workstream Leader: TBD

Ref #

Deliverable short name

Deliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes

6.01.1

Concepts and Principles Document

GB998

(CORE)

Demonstrate the principle of high cohesion between data and process but loose coupling between components
Deliver examples of these principles in action, focusing on the Customer & Partner Management layer (pick a small scope, get input from CEM project)
      
6.01.2 

 

       
6.01.3Roadmap for later releases.(STRETCH)       

 


6.02. Workstream 2: Functional Architecture ODA-47 - Getting issue details... STATUS

Workstream Leader: Sylvie Demarest

Ref #Deliverable short nameDeliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.02.1

Template

(CORE)

Create a “template” that other teams may use to do a “desk-top walk through” of their scenario or business problem to validate or challenge the ODA principles – catalysts could use also. This “template” could then be used by other teams

      
6.02.2 (CORE)
Demonstrate the principle of high cohesion between data and process but loose coupling between components
Deliver examples of these principles in action, focusing on the Customer & Partner Management layer (pick a small scope, get input from CEM project)
Sketch how an end to end scenario would work between layers
Include metrics (e.g. number of times a component is re-used)
Deliver low-hanging fruit ODA enablers by repackaging our existing assets into ODA deliverables  
      
6.02.3 (CORE)
Demonstrate how to achieve the desired decoupling
Map TM Forum Open APIs onto the functional architecture
      
6.02.4ODA Functional ArchitectureIG1167 R18.5 Chapter 4

Engagement Management

  • Based on use cases that will illustrate separation between Front-Ends and processes at Party, Core Commerce or Production, define information and technical functions covered by Engagement Management
      
6.02.5ODA Functional ArchitectureIG1167 R18.5 Chapter 4

Frameworks Mapping

  • Enrich and validate eTOM level 2 and SID ABE mappings proposed in 18.0 as only informative.
  • Illustrate a first example of mapping with the Functional Framework, starting with order handling and order delivery.
  • Enrich the list of Open API’s proposed by each functional block.
      
6.02.6ODA Functional Architecture

IG1167 R18.5 Chapters 5 to 17


Structure of the document

  • Review the structure of the ODA Functional Architecture document
  • Write empty chapters (5 to 17) or separate in several documents
      
6.02.7ODA Functional ArchitectureIG1167 R18.5 Chapters 4 & 9

Use Cases

  • Choose and illustrate a set of examples covering every block of the functional architecture:

    • Product offering / Product / CFS / RFS / Resource examples  ( Core Commerce Mgt / Production)
      • with different types of CFS : Access, OTT service, ….
      • and Resources : Device, Human  operation, …
      • and partner product : TV channel, ….
      • See Telefonica draft example
    • Multi-channel customer interaction (Engagement Mgt / Party Mgt)
    • Chatbot interaction and knowledge base access (Engagement Mgt  / Intelligence Mgt)
    • « Next best offer » example type (Engagement Mgt / Core Commerce Mgt / Intelligence Mgt)
      

 


6.03. Workstream 3:  Ecosystem Capabilities

Workstream Leader: Johan VandenbergheHugo Vaughan

Ref #Deliverable short nameDeliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes
6.03.1Ecosystem Requirements & Principles(CORE)

Contribute ecosystem requirements and principles to Requirements and Principles Workstream

Provide requirements to ensure that ODA enables CSPs to become a contributor to an ecosystem platform and/or a curator of such a platform (on-boarding etc.)

Develop an IoT ecosystem scenario & requirements to prove the ecosystem capabilities of ODA (harvest from Catalysts where appropriate)

      
6.03.2Ecosystem Diagrams 

Contribute diagrams to Functional Architecture Workstream

Evaluate ODA data architecture vs support for data protection / privacy regulation

      
6.03.3Ecosystem Termonology & Taxonomy

TMF071

(CORE)

Include references to DPRA / DSRA existing assets in ODA documents.

      

 


6.04. Workstream 4: Service & Resource Management

Workstream Leader: TBD

Ref #Deliverable short nameDeliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes

6.04.1

User Guide for Network Slice Management

GB999

(Plus supporting SID and API documents)

User Guide for Network Slice Management 

Shows how to manage network slices using TM Forum artifacts including Open APIs

  • The Connectivity Models needed  between ODA Commerce and production for a Network slices including UML and API data models (expectation is sample JSON schemas for Open API Service Ordering TMF641)
  • Mapping the specific platforms and the supporting management systems that take part in 5G slice management.
  • Architectural impacts of the data models on the supporting management systems:  intent based management with guaranteed SLAs; configuration of Policy for service assurance and SLA as part of the onboarding metadata; what meta data needs to be discovered; and how policy interacts with SLA and Service Assurance.
Architects and Developers

Describes how 5G network slices can be managed as abstracted connectivity services between ODA Commerce and Production functions groupings to achieve ODA decoupling.

Demonstrates how connectivity service models can be mapped to the the 5G catalyst functions and systems based on 5G standards in 3GPP used in  the DTW 2018 Nice 5G catalysts.

Scoping of APIs, architecture and connectivity servicesUser guide describing how to expose  managment of  Network slices as an ODA Production function supported by API and SID artefacts for the NaaS connectivity services.AT&T, BT, NTT,Orange, Telenor, TIM, Teoco, Mycom-OSI  ( DTW 5G catalysts sponsors 

6.04.2

Lifecycle Management for 5G Network Slice Services

Coordination activity

TOSCA template for 5G services

This work item is about pro-actively coordinating the alignment and consistency  of three deliverablse acorss ODA and and IoE Program.

  • Solution Guide for Network Slice Management. charter WI 6.04.1
  • TR276 update Monetising 5G
  • Lifecycle 5G management template descriptor based on 6.05.3: exemplar based on one of the TR276 service examples Formal deliverable s are an example in 6.05.3 and a github schema
     
DevelopersGoal  is to ensure that  the IoE prgramemonetising 5G reuseable multi-insustry services are aligned with the USer guide of across multipleagreement between ioE TR276 and ODA teams on how to proceed   Orange Teoco 

6.04.3

Deployment Pattern for SDN/NFV Solutions

IG xxxx 

Study the deployment patterns  SDN/NFV solutions. using the Green and Brown field examplees

Identifies the risk and challenges from CSPs perspective of differentdeplument paterns

Analyze the various Opensource solutions and SDOs work.

study will recommned wehter a DOman Orchetrator ( DO)  approach can address the CSP diverse deployment needs.

Architects and DevelopersInform CSP about dployment options for SDN/NFV with a focus ontehte role of Domain orchestratorsScoping study and outline proposal Study reportNetcracker  

6.04.4

Policy Management for Zero-touch Automation

 IG xxxx deferred

 Deferred to R19.

Specification of use cases that illustrate the need for policy management, with a focus on zero-touch automation. The use cases will be used to derive requirements, which in turn, will be used to identify information model and API needs. 

The work item will consider traditional Event – Condition – Action (ECA) policy management as well as intent-based policy management.

Note some work in in IG1174 Section 4.1 which can be leveraged in next release.

Architects and DevelopersExploratory Report (with IG document number) that provides use cases and requirements concerning policy management for zero-touch automation. The deliverable will make recommendations concerning suitable information models or subset thereof (e.g., subset of the SID Policy with extensions for intent-based policy management) and recommendations concerning API needs.     
 6.04.5

 ODA Intelligence Management Implementation Guide

(proposal added at AW Dallas may be reallocated to OLM workstram 6.05.x)

IG : Exploratory Report

 

 This Workstream aims at operationalizing the Design principle and High level Architecture Design of “ODA Intelligence Management “defined IG 1167 by describing the whole process when moving from Design phase to Execution (run-time) phase of Decision making Element and associated Managed Entities.

 In this process Autonomic behaviour of a Decision Making Element auto-discovers the ODA Intelligence Management Policy, Goals and Objectives, other Decision Making Elements it requires to collaborate with, and the capabilities of the Decision Making Element’s assigned Managed Entities (the (information that gets available at run-time). Then the Decision Making Element performs the self-* operations on its assigned ODA Managed Entities by orchestrating (launching and/or configuring) the Managed Entities when required. Orchestration means launching (at run-time) a Managed Entity if no instance exists yet that can provide a desired service and then configuring the instance (the newly launched or an already existing one).

The outcome is to provide guidance to all the actors involved in the process (Architects, Operations Managers, Algorithm Developers, Digital Service Providers, ISVs, and Standard Makers) along with a detailed description of the associated Catalyst that aims at showcasing an implementing the guidance for a real use case in the decision making space. This Catalyst could be conducted jointly with ETSI GANA community.

 Architects, Operations Managers, Algorithm Developers, Digital Service Providers, SVs and Standard Makers

Guide  defining the  operationalization of the Design principle and High level Architecture Design of “ODA Intelligence Management “defined IG 1167 by describing the whole process when moving from Design phase to Execution (run-time) phase of Decision making Element and associated Managed Entities.Guide

Includes a detailed description of the associated Catalyst that aims at showcasing an implementing the guidance for a real use case in the decision making space. This Catalyst could be conducted jointly with ETSI GANA community.

Scoping and seeking broader vendor support and first draft

 Intelligence Management Implementation Guide and detailed scope and description of the associated Catalyst and the partners Orange 

 


6.05. Workstream 5: Onboarding & Lifecycle Management

Workstream Leader: TBD

Ref #Deliverable short nameDeliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes

6.05.1

Model-Driven Onboarding of Physically Oriented Resources

 IG / TR?

Development of a model-driven process flow for the onboarding and subsequent planning and instantiation of physical devices. The process should also cover those virtualized devices which behave as a software implementation of a physical device. 

The value-add of using the SID model and/or TOSCA to harmonize various YANG device models will be considered.

Illustated using some real world examples.

It is possible this will be delivered as a part of IG1176

Operations, architects and developers.

Model-driven onboarding of: 

a)      Physical network devices.

b)      Virtual devices which behave as software implementations of hardware devices.

c)       The components and ports of the above.

Scoping and seeking broader  vendor support

Process flow candicates

 BT

 

6.05.2

Onboarding of ODA Components in a Cloud Native Environment

Exploratory Report

Requirements for the onboarding of services and resources in a cloud native ecosystem such as the Microsoft Azure Marketplace.

Architects and developers  

The report will describe how existing TM Forum artifacts can be reused, with an identification of gaps and required updates

Scoping analysis

Best practice for Cloud Native Environment

 

 

6.05.3

TOSCA Enhancements for Model-Driven Automation

IG1176

 Note recent TOSCA Simple Profile v1.2 Document appears to have  covered the majority of the known gaps arising from work in IG 1141 on Commercial operations asna tecnical onboarding.
Soto simplifiy  and speed up the work the  focus is on applying TOSC v1.2 to two use cases

  • 5G catalysts network Slices
  • Physical and Virtual functions

 and capturing learning points and TOSCA gaps for posible liason with OASIS

Architects and developers  

 Best practice guide with examples showing how SID ODA and ZOOM models e.g License, metrics can be used to define the TOSCA extended profile metadata for:

  1. Procurement commercial and operational onboarding and Service planning
  2. and operational provisioning and assurance (Intent, AI and policy based) 
  3. applied to two use cases

 Scope examples ans gernal approach

 Draft best practice for use of Tosca for commercial operational and techncial onboarding of the two use cases.

 Orange

BT,

TIM

 

 

6.05.4

Trust and Traceability in Digital Ecosystems

IG1175

 Study of trust and traceability needs in a digital ecosystem. The focus of the work concerns license management and problem isolation (both of which rely on metric measurements and events trigger by associated threshold crossings). Other topics may be added as the work progresses.

Distributed ledger / blockchain technology is expected to be one of the major solutions to the problem. However, the intention is not to exclude other solutions, e.g., event logs to track and verify interactions

 Procurement managers, Architects

 Exploratory Report (with IG document number) that use cases and requirements related to the stated problem. The report will make recommendations concerning technologies and approaches in support of the stated requirements. As needed, recommended changes to the TM Forum information model and APIs will be described in the report.

Draft scope and contenet  

 Draft report on turst and traceleablity and next step

Orange

BT

Art of managing things

 

 6.05.5 Inter Provider Interface Study IG

 Proposal is baesd on AW Dallas contribution   ODA-97 Inter Domain - Inter SP Interface.

  • Identify the use case and business scenarios for inter SP interfaces for SDN/NFV, 5G, IoT and analyze the gaps in existing SDOs work.
  • Iidentify opportunities for standardization work in TM Forum in conjunction with other SDOs which have the following characteristics:
    •  interface standadization between SP-Partner independent/irrespective of layer at which partner interacts.
    •  Independent  of internal business process of the partner.
    • Standardizing the payload irrespective of the business  level at which the interface is happening.
    • Standard protocols  and related grammar  for global acceptance. This will play an important role in IoE business models.
    • Interfaces  governed by Policies including those for Security.
 

 Study report covering\;

  •  Use case and business scenario in perspective SDN/NFV, 5G, IoT and analyze the Gaps in existing SDOs work. 
  • Identify opportuntunity for standarding Interoperator interface possibly by enhancing GB980, GB 981 and  TR211
  • Recommendation on next step for Forum actions.

 

 Scoping contribution ODA-97Exploratory reportNetcracker, BT ? 

 


 

6.06. Workstream 6: ODA Components

Workstream Leader: TBD

Ref #Deliverable short nameDeliverable type/numberDescriptionAudienceIntended usePlan for 1st 90 daysPlan for end of cycleSponsor / consumer supportNotes

6.06.1

ODA Component Definition

IG1167

 

 

 

 

 

 

 

6.06.2

Model-Driven Design of Management Interfaces for ODA Components

(prev Composition and Aggregation of ODA Components in a Cloud Native Environment)

IG1174

This document defines common interface elements for the management of ODA components in the context of a platform. The focus is on the management aspects of components and not the core aspect which will vary greatly depending on the type of component. The end goal is to facilitate an ecosystem of components that expose common management interfaces and thus significantly reducing the task of managing components.

Component developers

Input into more detailed API design work for components and/or input to an ODA component lab

The plan is to finish the document early in R18.5 and thus a stable draft is expected in the first 90 days

As noted, the plan is to finish this document well before the deadline for R18.5

The Art of Managing Things

 

6.06.3

 Prov title: Model driven examples of ODA Component Usage

 

 Series of examples of use of ODA components derived from TI example of hierarchy of Orchestrators, Activators, Controllers

 

 

 

 

 

 

6.06.4

 

 

 

 

 

 

 

 

 

7. Member Validation and Feedback Approach

Deliverables require validation and feedback. If the development team has a broad range of Members and Service Providers, validation may be within the team, however if the range of Members and Service Providers is weak, after Team Approval, deliverables must be validated beyond the team. Teams must state their Member & Validation approach here:

Validation Activity Approach

Approach is based on each Theme User groups refining and agreeing user stories for sub-themes which the specification teams implement as part of an Application Note for each of those User stories, and any supporting foundational assets.

Validation Activity Description

Validation of the Application Notes is done by the User Groups setting the User Stories / requirements and reviews will be scheduled at TAW and as appropriate. 

Dependencies

Additionally the project is working closely with catalyst projects to capture the key results and this validates through sponsors and participants that the technical work is relevant timely and adoptable.

Comments

This validation process is augmented by F2F workshops at TM Forum Live! and Action Week/Days, and project meetings to ensure that the deliverables remain are relevant

8. Project Tooling

Indicate the tooling required for project success.

Product

Key Functions

Needed for Project?

Confluence Space

Document creation and publishing

Provided by default

JIRA Space

Contribution and feedback management

Provided by default

9. Liaison Relationships

Please indicate if this project has or plans to have a relationship with other External Standards Organizations (SDOs).

Name of Organization

Is this a New or Existing relationship?

Linkages and/or Scope of work

Contact person

Comments

 

 

 

 

 

10. Charter History

Version Date Comment
Current Version (v. 26) Oct 15, 2018 13:36 Stephen Fratini
v. 35 Nov 08, 2018 18:31 Alan Pope
v. 34 Oct 31, 2018 11:00 Alan Pope:
Moved IG1177 from SRM workstream to OLM workstream
v. 33 Oct 29, 2018 13:00 Johan Vandenberghe
v. 32 Oct 29, 2018 13:00 Johan Vandenberghe
v. 31 Oct 22, 2018 17:15 Johan Vandenberghe
v. 30 Oct 22, 2018 17:11 Johan Vandenberghe
v. 29 Oct 21, 2018 16:10 Avi Talmor
v. 28 Oct 16, 2018 10:46 Paul Jordan
v. 27 Oct 16, 2018 09:57 Johan Vandenberghe
v. 26 Oct 15, 2018 13:36 Stephen Fratini
v. 25 Oct 15, 2018 12:19 Dave Milham
v. 24 Oct 15, 2018 11:22 Dave Milham
v. 23 Oct 15, 2018 04:37 Dave Milham
v. 22 Oct 14, 2018 18:15 Dave Milham
v. 21 Oct 12, 2018 11:37 Dave Milham
v. 20 Oct 12, 2018 11:27 Dave Milham
v. 19 Oct 12, 2018 11:21 Dave Milham
v. 18 Oct 12, 2018 11:18 Dave Milham
v. 17 Oct 12, 2018 11:12 Dave Milham
v. 16 Oct 12, 2018 10:52 Dave Milham
v. 15 Oct 12, 2018 07:22 Dave Milham
v. 14 Oct 11, 2018 18:29 Dave Milham
v. 13 Oct 11, 2018 18:15 Dave Milham
v. 12 Oct 11, 2018 18:11 Dave Milham
v. 11 Oct 10, 2018 16:36 Alan Pope
v. 10 Oct 10, 2018 11:38 Dave Milham
v. 9 Oct 10, 2018 09:39 Dave Milham
v. 8 Oct 10, 2018 06:05 Dave Milham
v. 7 Oct 10, 2018 05:49 Dave Milham
v. 6 Sep 04, 2018 10:00 Alan Pope
v. 5 Aug 17, 2018 09:37 Derek Flexer
v. 4 Aug 17, 2018 09:35 Derek Flexer
v. 3 Aug 17, 2018 09:01 Derek Flexer
v. 2 Jul 22, 2018 16:31 Alan Pope
v. 1 Jul 22, 2018 09:20 Alan Pope

11. Role Definition & Responsibilities

 Role Descriptions & Responsibilities

Project Team Lead:

  • Ensure project is developed in line with TM Forum IPR policy
  • Encourage all participants to take an active role in the project
  • Ensure participants have a clear understanding of what they need to complete and when
  • Drive the project team for on time delivery
  • Lead the design, planning and execution validation activities
  • Identify key companies required to position for industry adoption

Mentor:

  • Aid the team to maintain focus on delivery
  • Act as a source of expertise for the team
  • Join project calls to assist with blockages
  • Seek out expert resource to help as required
  • Be a guide and link to the wider Program

Sponsor:

  • Articulate the Industry User Story
  • Act as a Champion for the team
  • Review progress at six weekly intervals to ensure relevance
  • Champion final deliverables at Nice/San Jose
  • Drive Adoption in own organization by championing deliverables as beta versions of solutions to be developed

Participant:

  • Develop collaborative solutions as in accordance with the developed charter and inline with Collaboration process
  • Participate actively in team working meetings / sessions
  • Complete tasks as agreed with the team or workstream leader

Observer:

  • Choose to observe and monitor the progress of a project team
  • Use the insights gained to share observed advancements within your organization
  • Ensure planned deliveries are aligned with product roadmap in your organization to gain maximum R&D acceleration value
  • Align training and education within your organization to gain maximum value of cost & risk reduction and future proofing your organization

Reviewer:

  • All activities of observer plus…
  • Review all outputs from team and provide quality timely feedback ensuring output aligns with business and technology requirements of your organization
  • Participate in validation activities, these may be online or face to face.
  • Monitor Collaboration Events & Activities page for all latest review activities

Subject Matter Expert:

  • Provide support and guidance to a project team in your particular area of expertise

Workstream Lead:

  • For your agreed workstream;
  • Ensure project is developed in line with TM Forum IPR policy
  • Encourage all participants to take an active role in the project
  • Ensure participants have a clear understanding of what they need to complete and when
  • Drive the project team for on time delivery
  • Lead the design, planning and execution validation activities
  • Identify key companies required to position for industry adoption

12. Legal Notice

Copyright © TM Forum 2018. 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.

This document and the information contained herein is provided on an "AS IS" basis and TM FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Direct inquiries to the TM Forum office:

4 Century Drive, Suite 100
Parsippany, NJ 07054 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org

  • No labels