Child pages
  • Contributions



STUDY PERIOD 2017-2020

SG15-TD 163R1/Plen


Original: English




Geneva, 29 Jan. – 9 Feb. 2018

Study Group:

Study Group 15

Working Party:



Editors G.7711/Y.1702


Draft revised Recommendation ITU-T G.7711/Y.1702 (Editor version v2.02) Generic protocol-neutral information model for transport resources (for consent)


[Choose a purpose from the dropdown list]


Hing-Kam LAM
P.R. China

Tel: +1 732 275 4646
Fax: +xx


Xiang YUN



Tel: +86.135.1720.3187


Scott Mansfield



Tel: +1 724-931-9316






The document contains the editor version of G.7711 “Generic protocol-neutral information model for transport resources”.  The document will be used for preparing the future Amendment or Revision of the Recommendation.



  • TD163R1/PLEN contains the text of G.7711 v2.02 for consent.
  • Due to the large file size of G.7711 v2.02, TD163R1/PLEN is contained in three (3) files.
    1. “TD163r1.PLEN_g7711_v2.02_ PART-1 _Body.docx”
    2. “TD163r1.PLEN_g7711_v2.02_ PART-2 _Annex.docx”
    3. “TD163r1.PLEN_g7711_v2.02_ PART-3 _Appendix.docx”
  • This document is PART-1 containing the main body part of the Recommendation.


Document history :





WD35 (2/2017) Beijing

Initial version created by taking the in-force (pre-published) G.7711 (12/2016) as the base and incorporating the following updates

  • Update Appendix IV.6 per the agreement of the WD21 discussion

Model development environment

  • Eclipse: Mars.3 (4.5.3)
  • Papyrus: 1.1.0
  • Open Model Profile: 0.2.0


WD091014-28 (4/2017 Tokyo)

Update clause 8, Appendix IV, and add bibliography for pointing to the software repository of the UML model files, profile files, and data dictionary.

No update to the UML model.

To do in June regarding the environment: Update the profile for all models together


TD163/PLEN (2/2018)

     Align the text with the 12/2016 in-force published version

     Update the G.7711 UML model to align the Core Model with ONF TR-512 v1.3.1

     Add description text:

-           New Annex H, I, J, K

-           New Appendix V, VI, VII, VIII, IX, X, XI, XII, XIII, XIV

-           Update main clause and other annexes & appendixes

     Update the document structure as agreed at the 12/2017 London Interim meeting (see Annex 7 of the London meeting report TD144/WP3)



NOTE: For the editor draft of G.8052, a 2-field or 3-field version numbering convention is used.

-           The first field indicates the public publication revision number.

-           The second field indicates the editor version of the UML model (and base document). This field is incremented when the UML model, and thus the base document too, are updated.

-           The third field is used to indicate only the base document is updated and there is no update to the UML model.




International Telecommunication Union









Data over Transport – Generic aspects   – Transport network control aspects


Internet protocol aspects   – Operation, administration and maintenance


Generic protocol-neutral information model for transport resources


Recommendation  ITU T  G.7711/Y.1702

































Transport network control aspects








For further details, please refer to the list of ITU-T Recommendations.



Recommendation ITU-T G.7711/Y.1702

Generic protocol-neutral information model for transport resources





Recommendation ITU-T G.7711/Y.1702 specifies a core information model (IM) of transport resources. The IM is applicable to the management and control of transport networks regardless of whether they utilize traditional operation support system (OSS) management, an automatically switched optical network (ASON) control plane or a software-defined networking (SDN) controller to configure transport connectivity. The model is also applicable regardless of the technology of the underlying transport network. Furthermore, the applicability of the IM is independent of the ultimate protocols that will be used in the management and control interfaces.

The 2016 edition of this Recommendation has changed the document structure, added an « experimental » address structure to the foundation model, changed the name of TopologicalEntity to ForwardingEntity, incorporated ForwardingConstruct (FC) under ForwardingEntity and considers FC as closely related to topology, added the resilience model, added the equipment model and added the Specification model.

The 2018 edition of this Recommendation has enhanced the Forwarding & Termination, Foundation, Topology, Resilence, Equipment, and Specification models, and added the Control, Operations Pattern, Processing Construct, Constraint Domain models , and also updated the model description Appendixes.   Appendix IV.6 “Synchronization management model ” and IV.7 “Media management model” have been remove from this edition as they are being covered by separate Recommendations .







Study Group

Unique ID [*]


ITU-T G.7711/Y.1702





ITU-T G.7711/Y.1702







Information model, protocol-neutral, transport resource, UML .



The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of tele ­ com ­ mu ­ ni ­ ca ­ tions , information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.

The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU T study groups which, in turn, produce Recommendations on these topics.

The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution   1 .

In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.





In this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.

Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party .






ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.

As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at .




  ITU   2017

All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.

Table of Contents


Document history:

1 Scope

2 References

3 Definitions

3.1 Terms defined elsewhere

3.2 Terms defined in this Recommendation

4 Abbreviations and acronyms

5 Conventions

5.1 UML modelling conventions

5.2 Model artefact lifecycle stereotype conventions

5.3 Forwarding entity terminology conventions

5.4 Conditional package conventions

5.5 Pictorial diagram conventions

6 Model overview

6.1 Development and use of the ITU-T G.7711/Y.1702 Generic Information Model

6.2 Core Network Model – Forwarding and Termination Model

6.3 Core Foundation Model

6.4 Core Network Model – Topology Model

6.5 Core Network Model – Resilience Model

6.6 Core Physical Model

6.7 Core Specification Model

7 Other aspects

7.1 Key reference materials

7.2 Data dictionary

7.3 Terminology mapping

7.4 Core Model enhancement

7.5 Future Core Model work areas

8 UML model Papyrus files

Annex A  Modelling principles and guidelines, and tooling

A.1 UML modelling guidelines

A.2 Papyrus and Github guidelines

Annex B  Forwarding and Termination model

B.1 Forwarding and Termination Model detail

B.2 Explanatory figures

B.3 Work in progress

Annex C  Foundation – Identifiers, naming and states

C.1 Naming and identifiers

C.2 States

Annex D  Topology model

D.1 Topology model

D.2 Explanatory figures

Annex E  Resilience Model

E.1 Resilience model detail

E.2 Explanatory figures

E.3 Protection of other functions of physical things

E.4 Work in progress related to resilience

Annex F  Physical model

F.1 Physical model detail

F.2 Work in progress related to the physical model

Annex G  Specification model

G.1 Purpose of the specification model

G.2 Dedicated specification structures

Annex H  Control model

H.1 Model of control component and views

H.2 Understanding the control component and view model

Annex I  OAM model

Annex J  Operation Patterns

J.1 Introduction to the Operation Patterns

J.2 Purpose and essentials of the Operation Patterns

J.3 Future work

Annex K  Processing Construct

K.1 Purpose and essentials of Processing Construct

K.2 Explanatory Figures

K.3 Further considerations

Appendix I  Mapping of ITU-T G.7711/Y.1702 to ONF technical recommendations

I.1 Model Structural Patterns and Architecture (Appendix V)

I.2 Rationale Behind the CIM (Appendix VI)

I.3 Analogue and Media (L0) examples (Appendix VII)

I.4 Circuit Switched (L1 & L2) examples (Appendix VIII)

I.5 Packet Switched (L2 & L3) examples (Appendix IX)

I.6 Control and Signaling examples (Appendix X)

I.7 Timing & Synchronization examples (Appendix XI)

I.8 Processing Construct examples (Appendix XII)

I.9 Specification examples (Appendix XIII)

I.10 Resilience examples (XIV)

I.11 Application (L4 and above) examples (Appendix XV)

Appendix II  Data dictionary

Appendix III  Terminology mapping

III.1 Terminology mapping table

III.2 Detailed view of transport application programming interface to core model mapping

III.3 Model evolution

Appendix IV  Core model enhancement

IV.1 Controller model

IV.2 State extensions

IV.3 Model structure rules

IV.4 Strict Composition

IV.5 Multiplicity restrictions

IV.6 Synchronization management model sketch

IV.7 Media management model sketch

Appendix V  Model Structure, Patterns and Architecture

V.1 A progression patterns – intertwining and unfolding

Appendix VI  Model Rationale

VI.1 Business need

VI.2 Benefit of the CIM

VI.3 Model evolution

Appendix VII  Analogue and Media (Layer 0) Examples

VII.1 Optical Media

VII.2 For further study

Appendix VIII  Circuit Switched (L1 & L2) Examples

Appendix IX  Packet Switched (L2 & L3) Examples

Appendix X  Control and Signalling Examples

Appendix XI  Timing and Synchronization Examples

XI.1 Network synchronization overview

XI.2 Processing of timing information in a node

XI.3 Synchronization model attributes

Appendix XII  Processing Construct Examples

XII.1 General examples

Appendix XIII  Specification Examples

XIII.1 General examples

Appendix XIV  Resilience Examples

XIV.1 Linear protection schemes

XIV.2 Mesh Network cases

XIV.3 Ethernet Ring Protection [ITU-T G.8032]

XIV.4 Other protected ring schemes

Appendix XV  Application (L4 and above) examples



Recommendation ITU-T G.7711/Y.1702

Generic protocol-neutral information model for transport resources

1 Scope

This Recommendation describes a core information model (IM) of transport resources. An IM describes the things in a domain in terms of objects, their properties (represented as attributes) and their relationships. This IM is intended to be applicable to the management and control of the transport network regardless of whether the transport networks utilize traditional operation support system (OSS) management [ITU-T G.7710], an automatically switched optical network (ASON) control plane [ITU-T G.8080] or a software-defined networking (SDN) controller to configure transport connectivity. The model is also applicable regardless of the technology of the underlying transport network. Furthermore, the applicability of the IM is independent of the ultimate protocols that will be used in the management and control interfaces.

The core IM defined in this Recommendation can be used as a basis for the extension of transport/control-technology-specific IMs. Such extension will be specified in technology-specific Recommendations, such as those shown in Figure 1-1: [ITU-T G.874.1] for optical transport network (OTN) management; [ITU-T G.8052] for Carrier Ethernet management; [ITU-T G.8152] for multiprotocol label switching -transport profile (MPLS-TP) management; and [ITU-T G.7718.1] for ASON control management.

Figure 1-1 – Example information model extension

A uniform management/control-protocol-neutral core IM for traditional management, ASON control, and SDN control will ensure consistent operation, administration, maintenance and provisioning (OAM&P) of the transport network. This will benefit network operators and system/equipment vendors by enabling interoperability between SDN-controlled and traditionally managed network domains and future migration from traditional management to SDN control.

Furthermore, it is essential that the IM be applicable to complex network elements (NEs) that may be deployed in current networks, which requires support of more than a simple nodal view. Examples of such NEs follow.

Multi-layer NEs with subnetworks at each layer with transitional links between the subnetworks.

NEs that have their matrix partitioned [e.g., to model multiple MSPRING terminations or to model connectivity restrictions] with "internal" links between the subnetworks.

Distributed NEs [e.g., a passive optical network (PON)] with a mediation function to allow management visibility of each of the "encapsulated" NEs.

The complexity of these NEs makes it difficult to distinguish between the NE/nodal view and what is traditionally called the network view. The core IM thus encompasses both nodal and network views of transport resources.

2 References

The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.

[ITU-T G.78 0 ] Recommendation ITU-T G.780/Y.1351 (07/10), Terms and definitions for synchronous digital hierarchy (SDH) networks .

[ITU-T G. 694.1 ] Recommendation ITU-T G. 694.1 ( 02/2012 ), Spectral grids for WDM applications: DWDM frequency grid .

[ITU-T G.781] Recommendation ITU-T G.781 (2008), Synchronization layer functions .

[ITU-T G.798] Recommendation ITU-T G.798 (2012), Characteristics of optical transport network hierarchy equipment functional blocks .

[ITU-T G.800] Recommendation ITU-T G.800 (2016), Unified functional architecture of transport networks .

[ITU-T G.805] Recommendation ITU-T G.805 (2000), Generic functional architecture of transport networks .

[ITU-T G.808.1] Recommendation ITU-T G.808.1 (2014), Generic protection switching – Linear trail and subnetwork protection .

[ITU-T G.874.1] Recommendation ITU-T G.874.1 (2016), Optical transport network: Protocol-neutral management information model for the network element view .

[ITU-T G.77 02 ] Recommendation ITU-T G.77 02 (201 8 ), Architecture for SDN control of transport networks .

  [ITU-T G.7710] Recommendation ITU-T G.7710/Y.1701 (2012), Common equipment management function requirements.

[ITU-T G.7718.1] Recommendation ITU-T G.7718.1/Y.1709.1 (2006), Protocol-neutral management information model for the control plane view .

[ITU-T G.8021] Recommendation ITU-T G.8021/Y.1341 (2016), Characteristics of Ethernet transport network equipment functional blocks .

[ITU-T G.8032] Recommendation ITU-T G.8032/Y.1344 (2015), Ethernet ring protection switching .

[ITU-T G.8080] Recommendation ITU-T G.8080/Y.1304 (2012), Architecture for the automatically switched optical network .

[ITU-T G.8081] Recommendation ITU-T G.8081/Y.1353 (2012), Terms and definitions for automatically switched optical networks .

[ITU-T G.8052] Recommendation ITU-T G.8052/Y.1346 (2016), Protocol-neutral management information model for the Ethernet Transport capable network element .

[ITU-T G.8152] Recommendation ITU-T G.8152/Y.1375 (2016), Protocol-neutral management information model for the MPLS-TP network element .

[ITU-T Q.1741.9 ] Recommendation ITU-T Q.1741.9 (06/15), IMT-2000 references to Release 11 of GSM evolved UMTS core network .

[ITU-T X.731] Recommendation ITU-T X.731 (1992), Information technology – Open Systems Interconnection – Systems management: State management function .

[ITU-T X.1036] Recommendation ITU-T X.1036 (2007), Framework for creation, storage, distribution and enforcement of policies for network security .

[ISO/IEC 19505-1] ISO/IEC 19505-1:2012, Information technology – Object Management Group Unified Modelling Language (OMG UML) – Part 1: Infrastructure .

3 Definitions

3.1 Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:

3.1.1 access point [ITU-T G.805]

3.1.2 connection point [ITU-T G.805]

3.1.3 connection termination point [ITU-T G.8081]

3.1.4 information model [ITU-T X.1036]

3.1.5 link [ITU-T G.805]

3.1.6 link connection [ITU-T G.805]

3.1.7 matrix [ITU-T G.805]

3.1.8 port [ITU-T G.805]

3.1.9 subnetwork [ITU-T G.805]

3.1.10 subnetwork connection [ITU-T G.805]

3.1.11 termination connection point [ITU-T G.8081]

3.1.12 trail termination [ITU-T G.805]

3.1.13 trail termination point [ITU-T G.8081]

3.2 Terms defined in this Recommendation


4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:

AP Access Point

API Application Programming Interface

ASON Automatically Switched Optical Network

BMCA Best Master Clock Algorithm

C&SC Configuration and Switch Controller

CIM Common Information Model

CP Connection Point

CRUD Create Read Update Delete

CTP Connection Termination Point

DSGL Domain Specific Graphical Language

DS Data Schema

ECC Embedded Communication Channel

EMS Element Management System

E-NNI External Network to Network Interface

FC Forwarding Construct

FD Forwarding Domain

FDFr Forwarding Domain Fragment

FPGA Field Programmable Gate Array

FRE Frame Reference Event

FRU Field Replaceable Unit

FTP Floating Termination Point

GUID Globally Unique Identifier

IM Information Model

IMP Inverse Multiplexing

LP Layer Protocol

LT Layer Termination

LTP Logical Termination Point

MAC Media Access Control

ME Maintenance Entity

MEP Maintenance Entity group end Point

MFDFr Matrix Forwarding Domain Fragment

MPLS-TP Multiprotocol Label Switching-Transport Profile

MSPRING Multiplex Section share Protection Ring

NE Network Element

NFRU Non-Field Replaceable Unit

OAM Operation, Administration and Maintenance

OAM&P Operation, Administration, Maintenance and Provisioning

OCL Object Constraint Language

OS Operation System

OSS Operation Support System

OTN Optical Transport Network

PON Passive Optical Network

PTP Precision Time Protocol

Rx Receiver

SASE Stand Alone Synchronization Equipment

SDN Software-Defined Networking

SDO Standards Development Organization

SNC Subnetwork Connection

SNP Subnetwork Point

SSM Synchronization Status Message

TAPI Transport API

TCP Termination Connection Point

TPE Transmission Path Endpoint

TRI Transport Resource Identifier

TTP Trail Termination Point

Tx Transmitter

UML Unified Modelling Language

UUID Universally Unique Identifier [1]

VCAT Virtual Concatenation

XC Cross-Connection

XML Extensible Markup Language

This Recommendation also uses the following abbreviations and acronyms. These abbreviations are for the name of the model constructs, such as object class. These names follow the Unified Modelling Language (UML) naming convention, i.e., UpperCamelCase.

FC ForwardingConstruct

FD ForwardingDomain

LP LayerProtocol

LTP LogicalTerminationPoint

MLSN MultiLayerSubnetwork

NCD NetworkControlDomain

NE NetworkElement

5 Conventions

5.1 UML modelling conventions

The information model (IM) defined in this Recommendation is expressed in a formal language called UML, which was developed by the Object Management Group (OMG). It is a general purpose modelling language in the field of software engineering. In 2000, the UML also became subject to [ISO/IEC 19505-1].

UML defines a number of basic model elements, called UML artefacts. In order to ensure consistent modelling, only a selected subset of these artefacts is used in the development of the ITU T   G.7711/Y.1702 IM. The selected subset of UML artefacts is documented in Annex A.

5.1.1 Note on reading UML diagrams

The UML diagram convention is provided in Annex A. There are some key aspects of the diagrams that need to be emphasized.

Association end attribute (the name of which always starts with "_") highlighted in the diagrams by the navigable end of the association (arrow head) is an attribute of the class at the non-navigable end of the association. It is the convention not to show the attribute in the class in the diagrams. The attributes for non-navigable ends (owned by the association) are not shown.

On some occasions, other properties of the association end attribute are also shown.

In Figure 5-1, the text at the arrow head end _lp… is an attribute of the Logical Termination Point (LTP).

Figure 5-1 – Illustrating navigable association end attributes

This attribute is shown in the fragment of abbreviated data dictionary in Table 5-1 for LogicalTerminationPoint (LTP).

Table 5-1 – Attributes for LogicalTerminationPoint

Attribute name

Lifecycle stereotype
(empty = Mature)




Ordered list of LayerProtocols that this LTP is comprised of where the first entry in the list is the lowest server layer (e.g., physical)

This sort of table is used in each of the Recommendations on a section of the model. Such tables only provide summary information. For full information, the reader should refer to the data dictionary (see   Appendix   II).

5.2 Model artefact lifecycle stereotype conventions

Stereotypes are applied to entities in the model to indicate the degree of maturity. These are made visible in many of the figures.

The following stereotypes appear in this Recommendation:


Indicates that the entity is at a very early stage of development and will almost certainly change. The entity is NOT mature enough to be used in implementation.


Indicates that the entity is at a relatively early stage of development and is likely to change, but is mature enough to be used in implementation.

If no stereotype is shown, the entity is mature. See clause A.2 for more details.

5.3 Forwarding entity terminology conventions

In this Recommendation, the terms Forwarding Domain (FD) and Forwarding Construct (FC) have been used in place of the traditional terms SubNetwork (SN) and SubNetwork-Connection (SNC), respectively.

5.4 Conditional package conventions

Conditional packages are used to enhance (core) object classes/interfaces with additional attributes/operations on a conditional basis. The attributes/operations are defined in special object classes called packages. In this Recommendation, package names follow the same rules as defined for object classes. The name ends with the suffix "_Pac".

5.5 Pictorial diagram conventions

This Recommendation includes a number of UML diagrams. The UML symbol set is suitably explained in Annex A, which includes guidelines on the usage of UML diagrams.

This Recommendation also contains a number of non-UML diagrams, which use the symbols listed in Figure 5-2 in pictorial representations of network examples.

EDITORIAL NOTE – The UML figures contained in this Recommendation are also available in png format here .

Figure 5-2 – Network diagram symbol key

In addition, in the diagrams related to media the following symbols and labels are used.

Figure 5- 3 Additional media diagram symbol set

6 Model overview

This clause provides an overview of the Core Model of the Common Information Model (CIM) and also the structure of the model description documentation.

In addition, there are UML modelling guidelines and tooling for model generation and usage. Pointers to these guidelines are provided in Annex A.

The description of the model is broken down into a set of annexes progressing through the model, from the basics of transport forwarding and termination to a description of the augmentation mechanism of the specification model.

Clauses 6.1 to 6.7 provide some brief highlights from the associated annexes.

6.1 Development and use of the ITU-T G.7711/Y.1702 Generic Information Model

Figure 6-1 provides an overview of the CIM and how the purpose specific information model (IM) views and data schema (DS) [2] are related to it. The term DS in this Recommendation is used in the context of either (1) a specific protocol that is used to implement a purpose specific interface or (2) a programming language that is used to invoke a purpose specific application programming interface (API). Guidelines for the use of UML in the CIM, pruning and refactoring the CIM to provide a purpose specific view, and ultimately mapping to a DS will also be provided.

Figure 6-1 − Methodology of information model and data schema development

6.1.1 Common Information Model

An information model describes the things in a domain in terms of objects, their properties (represented as attributes), and their relationships. The CIM should be expressed in UML and include all of the artefacts (object classes, attributes, relationships, etc.) that are necessary to describe the generic and domains for the technologies/applications being developed.

It will be necessary to continually expand and refine the CIM over time as new forwarding technologies, capabilities and applications are encompassed, and new insights are gained.

To allow these extensions to be made in a seamless manner, the CIM will be structured into a generic core model (known by the number of this Recommendation, i.e., ITU-T G.7711//Y.1702) and a number of models which are specific to the forwarding technologies (such as OTN in [ITU T   G.874.1], Ethernet in [ITU-T G.8052], etc.) and applications (such as ASON control plane management in [ITU-T G.7718.1]). This modelling process is intended to allow these extensions to be developed with as much independence as possible.

Generic Core Model

The artefacts in the generic core model (ITU-T G.7711/Y.1702) will be used as a core model by the technology/application specific models either directly or with extension. The generic model will be constructed as a set of sub-models each addressing a specific topic to allow for easier navigation. This Recommendation is responsible for specifying and maintaining the generic model.

As a result of advancements in the industry, it may be recognized that some parts of the generic model may need to be augmented or changed. This Recommendation will ensure that any such areas are clearly identified using lifecycle stereotypes. The older model forms will be maintained to ensure ongoing compatibility and to ease migration.

Technology/Application Models

It is expected that the transport forwarding technology or application specific domains will develop the appropriate models which contain objects, attributes and associations that relate solely to that respective domains. In some cases, an application or forwarding technology addition will also require enhancement of the generic model.

In some cases, an artefact in a model initially considered to be purely for a single forwarding technology or application may be subsequently recognized as common across several technologies or applications and hence there will be a need to migrate (promote) this artefact to the generic model.

To ensure coherence, any artefacts, attributes or associations that might be identified during the development of forwarding technology or application models should be included in the appropriate fragment of the CIM. Only those properties that relate to the specific encoding or style of interaction of an interface may be added outside the CIM.

6.1.2 Purpose specific information model view

An interface-purpose-specific information model view is a subset of the CIM and should be expressed in UML. A purpose specific information model view is typically much smaller than the entire CIM. If additional artefacts (objects, packages, attributes or associations) are identified while establishing a specific view, these should be added to the appropriate fragment of the CIM so that they are available for future use.

To provide maximum reuse, a purpose specific view should be developed in two steps.

Prune and refactor the artefacts of the CIM to provide a model of the network to be managed. Only those artefacts that represent the capabilities that are both in scope and supported are include in the purpose specific IM.

Define the access rights for the various groups of users that will manage that network.

Pruning and refactoring provides a purpose specific IM that represents the capabilities of the network of interest. The definition of access rights provides the ability to limit the actions that can be taken by the various user groups that will use that IM. For example, a user group responsible for network configuration could be provided with full read/write access and the ability to create or delete object instances; while a user group responsible for inventory may only be allowed read access (i.e., can see the network, but cannot make changes).

Pruning, i.e., remove the objects/packages/attributes that are not required:

Select the required object classes from the common IM

All mandatory (non-optional) attributes and packages must be included

Select the required conditional packages and optional attributes

Where appropriate conditional packages and optional attributes may be declared mandatory

Remove any optional associations that are not required

Refactoring, i.e., reduce association flexibility:

Reducing multiplicity (e.g., from [1..*] to [1])

When this results in a composition association of multiplicity [1] between a subordinate and a superior object class, they can be combined into a single object class by pulling the attributes of the subordinate class into the superior class

Where possible reducing the depth of the inheritance (i.e., by combining object classes by moving the attributes of the super class into the subclass)

Add reverse navigation (if useful for the client)

The common IM only supports navigation from a subordinate object class to a superior object class. This allows new subordinate object classes to be added without any impact on the superior object class. In a purpose specific implementation, it is frequently useful to be able to navigate the relationship between superior and subordinate object classes in both directions

Constraining attribute definitions

Reducing legal value ranges

Defining which (if any) attributes should be read only (for all users)

Defining constraints between attributes

Definition of access rights:

If only one group will use the network specific IM, then this step is not required. If more than one group will use the network specific IM, this optional step provides a profile for each user group to:

Convert some attributes defined as read/write in the network specific IM to read only

Remove the rights to create/delete some or all object instances.

6.1.3 Data schema

A DS is developed in the context of either (1) a specific protocol that is used to implement a purpose specific interface or (2) a programming language that is used to invoke a purpose specific API. Note that it is possible to map directly from the purpose specific information model to interface encoding. The DS is constructed by mapping of the purpose specific information model into the DS together with the operations patterns from the CIM to provide the interface protocol specific operations and notifications. The operations should include data structures taken directly from the purpose specific information model view with no further adjustment.

The development of the DS should consider the following:

The operations should act on the information in a way consistent with the modelled object lifecycle interdependency rules

Use lifecycle dependencies to ensure a sensible interface operation structuring and interface flow rule

Use a transaction approach style of interface to account for lifecycle dependencies of the model

The operations should abide by the attribute properties

Read only attributes (except those which are defined as setByCreate) should not be included in data related to creation of an object (e.g., not in createData) or in a specification of a desired object outcome

Use of attribute value ranges, etc. to allow "effort" statement, optionality and negotiation to be supported by the interface.

6.1.4 Interface encoding

This step encodes either the purpose specific DS or a purpose specific IM into either a specific protocol that is used to implement a purpose specific interface or a programming language that is used to invoke a purpose specific API. If the interface is encoded directly from the purpose specific information model, then the interface operations must be added as described in clause   6.1.3.

6.2 Core Network Model – Forwarding and Termination Model

This clause provides a high-level overview of the T ermination and F orwarding aspects of the C ore N etwork M odel . Details of the model are provided in Annex B. This model is a canoni cal model of networking from a management- control perspective. F igure   6-2 is a skeleton class diagram illustrating the interrelationships of key object classes defined in the C ore N etwork M odel of the C ore M odel . The classes are colo u red to identify key groupings in the model. The colo u rs are chosen to match the key entity colo u rs in Figure 5 - 2 (with the L i nk in the alternative colo u r for clarity). This colo u r scheme for class diagrams is used in some of the figures in the associated annexes .

The Forwarding and Termination document provides a high-level overview of the Termination and Forwarding aspects of the CoreNetworkModel. This model is essentially a canonical model of networking from a management-control perspective. The figure below is a skeleton class diagram illustrating the interrelationships between key object classes defined in the CoreNetworkModel of the CoreModel. The classes are colored to help recognize key groupings in the model. The colors are chosen to match the key entity colors in Figure 5 - 2   Network Diagram Symbol Key (with the Link in the alternative color for clarity). This color scheme for class diagrams is used in some of the figures in the associated documents.


Source Papyrus CoreModel diagram: Forwarding-LtpInterLayerSkeletonOverview

Figure 6-2 – Skeleton class diagram of key object classes

EDITORIAL NOTE – The UML figures contained in this Recommendation are also available in png format here .

6.3 Core Foundation Model

The Core Foundation Model in Annex C provides a detailed view of all aspects of the Core Model that are relevant to all other parts of the CIM. Currently this model includes coverage of naming and identifiers as well as states.

6.3.1 Naming and identifiers

Rationalizing the approach to naming, identification and addressing of entities described in the CIM.

6.3.2 States

Basic states applicable to a majority of entities in the CIM. See Figure 6-3.


Source Papyrus CoreModel diagram: GeneralizedStates

Figure 6-3 – States for all objects

6.4 Core Network Model – Topology Model

The Topology Model in Annex D provides a detailed view of the topology model covering both the basic topology pattern with detailed attributes as well as the combination of layered topology and topology views. See Figure 6-4 and Figure 6-5.


Source Papyrus CoreModel diagram: Topology-HighLevelOverviewOfStructureAndPacs-LargeText

Figure 6-4 – Key classes that form the network topology

Figure 6-5 ForwardingDomain recursion with Link [3]

6.5 Core Network Model – Resilience Model

The Resilience Model in Annex E provides a view of the model for resilience (including protection and restoration) and encompasses:

The basic resilience model structure.

The key attributes relevant to resilience.

The application of the resilience model to various cases.

See Figure 6-6.



Source Papyrus CoreModel diagram: Resilience-Pattern

Figure 6-6 – Basic resilience pattern

6.6 Core Physical Model

The Core Physical Model in Annex F provides a view of the model for physical objects (including equipment, holders and connectors) and encompasses:

Introduces the Physical model structure

Describes the key classes of the Physical model

Explains the attributes of the Physical model

Describes the relationship between the connector and the LTP

Shows how the model deals with the relationship between physical and functional views

Explains how the Specification model describes equipment schemes (e.g., rules)

Highlights work in progress to further advance the Equipment model.

See Figure 6-7.


Source Papyrus CoreModel diagram: Equipment-Pattern

Figure 6-7 – Basic equipment pattern

6.7 Core Specification Model

This clause provides a high-level overview of the Core Specification Model. Details of the model are provided in Annex G. There are several related needs that have given rise to the Specification model:

Provide machine readable form of specific localized behaviour:

Representing rules related to restrictions of specific cases of use of the model

Representing capabilities of specific cases of use

Enable the introduction of run time schema where the essential structure of the model is known up front (at compile time), but the details are not

Reduce the clutter in a representation where a set of details takes the same values for all instances that related to a specific case

Allow leverage of existing standards definitions (e.g., technology/application specific) in a machine readable language.

The combination of these needs resulted in a separation in the model of definitions of structure and content, such that an instance of classes from one model fragment could point to another model fragment to enable the provision of a fragment of definition of the class and of subordinates.

The aim of all specification definitions is that they be rigorous definitions of specific cases of usage and enable machine interpretation where traditional interface designs would only allow human interpretation.

The following dedicated spec structures have been considered:

FC spec: Main focus is to provide a representation of the effective internal structure of an FC

LTP and LP spec: Main focus is to provide a representation of Layer Protocol (LP) specific parameters for the LTP

FD and Link spec: Main focus is on capacity and forwarding enablement restrictions

Equipment spec: Main focus is to provide a representation of equipping constraints.

Scheme spec: Main focus is to provide a mechanism to describe any pattern (arrangement) of entities from the model for some specific purpose (e.g. to describe the structure of a [ITU-T G.8032] protection scheme.

See Figure 6-8.

Source Papyrus CoreModel diagram: Spec-LtpCapabilitySpec WithLtp

Figure 6-8 – Class diagram of the spec model of LTP and LP

In addition, there is work on a generalized spec pattern with the main focus to provide a common representation of the mechanism for relating a class to its spec, accounting for implementation needs.

6. 8 Control Model

The ONF Architecture [b-ONF TR-521] talks of a recursion of control aligning well with the more general concept of the Management-Control Continuum from [b-TMF IG1118 ] . The control model in Version 2   of the Core Mod el showed a traditional hierarchy rather than a generalized recursion.

Over many years it has become apparent that the traditional representation of the Network Element and of the Managed Element was not correct. It is clear that from one perspective the Network Element is simply a lower level member of the Management-Control Continuum (MCC) . It is also apparent that all other aspects of the NE are covered by other parts of the model.

It was concluded that the NE should be re - modeled as simply a control capability and that that capability should be generalized so that it could handle all aspects of the Management Control Continuum.

Source Papyrus CoreModel diagram: Control-ControlComponentAndControlViewCore

Figure 6- 9 Core Control Model

As explained in version 2 of the Core Model, the classes SdnController, NetworkControlDomain and NetworkElement [4] have been reassessed and deprecated and new classes have been developed in this release to replace them. It has been recognized that a uniform recursive model of control can be developed that provides a consistent treatment of what were previously seen as completely different things .

6. 10 OAM Model

For further study

6. 11 Operation Pattern Model

The work has been carried out with the assumption that the future is cloud oriented such that the controllers are an interconnected system of cloud-based components. It is assumed that in a cloud environment the operations will be "outcome-oriented" interaction [5] where the focus is on stating the constraints that form a boundary that defines the desired target. In outcome-oriented interaction the operations/methods/activities/tasks used to achieve the desired outcome are firmly in the domain of the provider. The client simply provides information about the desired outcome in the context of what has been agreed as possible. Hence the essential need of any interaction is the provision of information about the desired outcome in terms of constraints and potentially in the context of some expected initial system state . Whilst the content of any message may differ per interaction the structure will be consistent [6] .

  • The Operations Pattern M odel is intended to provide a dynamic sophisticated structure that has “foldaway” parts
  • The aim is to provide one structure :
    • For all outcome-oriented constraint- based forms including intent
    • Supports traditional Verb driven forms
      • with constrained valued
      • with absolute values
    • Enables operations that:
      • Act on multiple separate independent things
      • Have sequence and interdependency between parts and with other separate interactions
      • Are long lived or short lived (where the life may depend upon the case and may not be knowable before the request
  • The aim is that the model will be used to generate schema where there is a continuum of compatible schema from the most basic simple CRUD (Create/Read/Update/Delete) forms to the most sophisticated forms such that t he CRUD form can be seen as a tiny subset of the sophisticated form

The following figure shows the model of the request.

Source Papyrus CoreModel diagram: Operation-Structure

Figure 6- 10 The Structure of an operation (request)

6. 12 Processing Construct Model

The ProcessingConstruct (PC) represents generalized functionality. The PC is used in conjunction with the ConstraintDomain (CD) that groups PCs and constrains their usage. In addition to being general applicable to represent functionality that is not being modeled in detail the PC and CD form the fundamental pattern that allows an important transition in the representation of a ‘device’ [7] .

In the CIM there are already separate classes for special types of functions:

  • ForwardingConstruct to represent forwarding functionality
  • LogicalTerminationPoint to represent termination, and
  • ForwardingDomain to represent forwarding scope constraints.

ProcessingConstruct is in addition to these concepts and is to be used where the major function of interest is related to processing rather than forwarding of information.

While there are a number of grey areas between processing and forwarding, there are a few ‘pure’ ProcessingConstructs:

  • Memory
  • CPU
  • Storage

Another use for ProcessingConstruct is for representing control plane processes such as packet routing processes. Packet routers commonly run many routing protocols and may also run many instances of each routing protocol. Each routing process instance peers independently and using ProcessingConstruct we can show the actual control plane topologies .

Source Papyrus CoreModel diagram: ProcessingConstruct-Core

Figure 6- 1 1 Processing Construct and Constraint Domain core model


7 Other aspects

This clause provides an overview of other critical supporting material of the CIM. These materials are further detailed in Appendix I V .

7.1 Key reference material s

In the development of the Core Model of the CIM, IM works have been shared among standards development organizations (SDOs), including [b-ONF TR-512], [b-TMF TR215], [b-TMF TR225], and [b-TMF GB922]. The Core Model has also been published as [b-ONF   TR-512]. It is also being shared with other bodies via various mechanisms including publication of a view of the model as [b IETF draft-lam].

Appendix I provides a mapping between the documentation structure of this Recommendation and [b-ONF TR-512].

7.2 Data dictionary

The data dictionary provides details of the classes, attributes and data types (i.e., syntax) that are used in the model. The individual annexes on model focuses provide details on key classes and attributes but do not provide all details to avoid clutter and replication.

An extract from the data dictionary is shown in Figure 7.1.

C:\Users\ndavis\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Word\New Picture (1).bmp

Figure 7-1 – Extract from data dictionary

7.3 Terminology mapping

Table III.1 provides overview translations from classes in the CIM to classes (and concepts) in other models. It will be helpful for someone who is familiar with one of the other industry standard terminology sets when working through the CIM.

7.4 Core Model enhancement

Appendix IV provides fragments of ongoing work. The data dictionary document (see Appendix II) does NOT include entities from Appendix IV. All the work in Appendix IV is experimental.

Appendix IV covers:

Modelling enhancements including adding rules to the core model (loop and spiral)

Management-Control-Component model including a Processing Construct

Operations model patterns

Information architecture and patterns

Additional inter-view interrelationship considerations

Further Resilience model enhancements (including details of the support for [ITU-T G.8032].

7.5 Future Core Model work areas

Potential future areas of work in the Core Model include, not in any particular order:

Policy Model

Embedded communication channel (ECC) subset

Ensurance Module

Management-Control Components

Development of the Controller model [including NE, NetworkControlDomain (NCD), Controller component, Network core control]

Profiles, Templates and Specifications

Completion of spec model and addition of profiles model in the spec context

Further development of constraint models (also covering policy)


Developing models for signalling in the context of ECC and protection

Operation, administration and maintenance (OAM) functions

Generalization of OAM functions, e.g., generalized MEPs


Modelling of events and their reporting

Dependency graph representation of telecommunications technology (including flow semantics)

For expression of detailed processes of a telecommunications technology to enable interpretation of a new technology


Validation of the protection model for support of [ITU-T G.8032] and for other ring schemes not yet covered

Development of protection scheme specifications and generalization of these to deal with any network structure specification

Add details from resilience spreadsheet to the documentation (and model comments where appropriate)

Timing and Synchronization model (frequency and time/phase)

Construction and development of a model of synchronization based on the FC and LTP derived from work in ITU-T

Physical Equipment Module

Completion of the equipment model

Expectation vs. actual

Attribute details

Rationalize attribute groupings

Look for source for physical properties

Separate out functional work into other work areas (ProcessingConstruct and OAM functions)

Separate out Management-Control parts into Management-Control model

Refine and move specification model detail from the Physical model document to the Specification model document (and move model as appropriate)


Complete pattern and migrate model to use pattern

Develop class based rule mechanism and consider more fluid approach to Core model

Provide further examples of usage

Develop detailed rules

Refine model to deal with rule interaction

Consider FD/FC spec convergence

FD ports would be necessary, but these have essentially been subsumed by the LTP (this relates to the general component system pattern)

When dealing with Compound Links, consideration of whether rules are necessary for Link is required (the same structure will apply, but an additional association from Link to FD will be necessary)

Development of a specification toolkit including standardized rules and structures

DSGL (Domain Specific Graphical Language to ease spec construction)

Model vs. specification:

Implication of the work so far is that the specification structure is the model structure and that the schema for any particular case has some parts of the structure in compile time form and other parts in run time only form where the run time form may have static parts only in the spec form

Is a replication of the model structure in formal model, but that formal model should be decoupled at various points and extensible in a constrained way at various points

Considerations of "model viscosity" (all models are fluid over some timeframe)

Dealing with LTP and LP formal sub-structuring challenge

Related to the previous bullet should the LP sub structuring of the spec model be part of the LP model

Migration of operations from non-spec to spec

Continuum of usage approaches from "phrase book user" to "orator"

General processing construct model (and the component system-pattern)

Developing the model of the recursion of function abstractions from the base equipment through functional protection to the supporting of LTPs, etc.

Patterns and architectures

Construction of models that explore the pattern underlying Link/FC/FD and minimally represent that pattern and show derivation of Link/FC/FD from that pattern

Link and Topology

Various detailed enhancements including considerations of merging of FC and Link

Further clarification of off-network "things" (could be a link topology)

Serial compound link

View abstraction

Enhancements to view abstraction examples and cases, including FD view, FC view, Call view, Service view, Connection view

Further work on rules for virtualization (e.g., what from one view can be grouped in the same link from another view)

Mapping to other models

Enhancements to the mapping to OpenFlow

Development of mappings to IETF models

Interface patterns

Completion of the generalized operations pattern covering a range of cases including intend and create read update delete (CRUD)

Support for specific interface development

Transport application programming interface (TAPI)

Intent model


Enhancement to UML YANG to cover Specification models

Enhancements to pruning and refactoring process and tooling

Minor enhancements

Rename the LayerProtocol class


Ongoing improvements

8 UML model Papyrus files

The ITU-T G.7711 /Y.1702 model is contained in a repository website. The following links provide the pointers to the ITU-T G.7711 /Y.1702 UML model files and supporting materials.

G.7711 <<Editor Note: link to be updated>>

This contains the ten ITU-T G.7711 /Y.1702 model files, i.e., the .project, .di, .notation, and .uml files model files :

.project ,









OpenModel_Profile.profile.uml   <<Editor Note: link to be updated>>

This is the data dictionary. See Appendix II.

G.7711_v2.00_ FIG .zip   <<Editor Note: link to be updated>>

This is the figure files .


The OpenModelProfile defines the UML model meta constructs ( i.e., basic building blocks, such class, attribute, association, etc.) to be used to build information models. Using the same OpenModelProfile is essential step before achieving common IM.

NOTE –   The ITU-T G.7711/Y.1702 UML information models and the Open Model Profile are specified using the Papyrus open source modelling tool. In order to view and further extend or modify the information model, the user needs to install the open source Eclipse software and the Papyrus tool, which is available at [b-Eclipse-Papyrus]. The installation guide for Eclipse and Papyrus can be found in [b- ONF TR-515 ].

Annex A through Annex K


Editor Note: See the companion file “ TD163r1.PLEN_g7711_v2.02_ PART-2 _Annex.docx ” for the text of Annex A through Annex K.


Appendix I through Appendix XV


Editor Note: See the companion file “ TD163r1.PLEN_g7711_v2.02_ PART-3 _Appendix.docx ” for the text of Appendix I through Appendix XV.






[b-Eclipse-Papyrus] Papyrus Eclipse UML Modelling Tool.
< >

[b-IETF draft-lam] IETF draft-lam-teas-usage-info-model-net-topology-04 (2016) , Usage of IM for network topology to support TE topology YANG module development.

[b-IETF RFC 4122] IETF RFC 4122 (2005), A Universally Unique Identifier (UUID) URN Namespace .


[b- ONF-TMF-MEF ] MEF ONF TMF Collaboration Agreement (see .

[b-ONF TR-512] ONF TR-512 (2015), Core Information Model (CoreModel) .

[b-ONF TR-513] ONF TR-513 (2016), Common Information Model: Overview .

[b-ONF TR-514] IISOMI 514 (2016), UML modeling guidelines.

[b-ONF TR-515] IISOMI 515 (2016), ONF Papyrus guidelines .

[b- ONF TR-521 ] ONF TR-521 (V1.1):: ONF SDN Architecture 1.1, February 2016 ( .

[b-ONF TS-025] ONF TS-025 (2015), OpenFlow switch specification , Version 1.5.1.

[b-OSSDN-EAGLE, 2017] Open source SDN.
< >

[b-ONF/Snowmass] Open Networking Foundation/Snowmass ONFOpen Transport.
Repository for Open Transport API Project .
< >
         and Open Source SDN . < >

[b- ONF TAPI ] ONF Transport API (see [ b- ONF/Snowm ass ]) .  

[b-TMF GB922] TM Forum GB922 (2017) Information framework (SID) . .

[b-TMF IG1118 ] TM Forum IG1118 OSS/BSS Futures – Architecture R15.5.1 .

[b-TMF MTOSI] TM Forum MTOSI (4.0), Multi-Technology OS Interface .

[b-TMF TR215] TM Forum TR215 (2014), Logical resource-network model advancements and insights.

[b-TMF TR225] TM Forum TR225 (2016), Logical resource: Network function model.

[b-TMF MTOSI] TM Forum MTOSI (4.0), Multi-Technology OS Interface .

[b- UML-YANG GUIDE ] UML- YANG Mapping Guidelines .

[b- UML-YANG TOOL ] UML- YANG Mapping Tooling Navigate via .

[b-UUID, 2017] Universally_unique_identifier . < >

[b- Eclipse-Papyrus ] Papyrus Eclipse UML Modelling Tool ( )

[b-IISOMI-515] IISOMI-515_Papyrus-Guidelines.docx ( )












Services, applications and middleware


Network aspects


Interfaces and protocols


Numbering, addressing and naming


Operation, administration and maintenance










Services and applications


Architecture, access, network capabilities and resource management






Quality of service and network performance




Operation, administration and maintenance








Frameworks and functional architecture models


Quality of Service and performance


Service aspects: Service capabilities and service architecture


Service aspects: Interoperability of services and networks in NGN


Enhancements to NGN


Network management


Network control architectures and protocols


Packet-based Networks




Generalized mobility


Carrier grade open environment










Definitions and terminologies


Requirements and use cases


Infrastructure, connectivity and networks


Frameworks, architectures and protocols


Services, applications, computation and data processing


Management, control and performance


Identification and security


Evaluation and assessment




For further details, please refer to the list of ITU-T Recommendations.





Series A

Organization of the work of ITU-T

Series D

Tariff and accounting principles and international telecommunication/ICT economic and policy issues

Series E

Overall network operation, telephone service, service operation and human factors

Series F

Non-telephone telecommunication services

Series G

Transmission systems and media, digital systems and networks

Series H

Audiovisual and multimedia systems

Series I

Integrated services digital network

Series J

Cable networks and transmission of television, sound programme and other multimedia signals

Series K

Protection against interference

Series L

Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation and protection of cables and other elements of outside plant

Series M

Telecommunication management, including TMN and network maintenance

Series N

Maintenance: international sound programme and television transmission circuits

Series O

Specifications of measuring equipment

Series P

Telephone transmission quality, telephone installations, local line networks

Series Q

Switching and signalling, and associated measurements and tests

Series R

Telegraph transmission

Series S

Telegraph services terminal equipment

Series T

Terminals for telematic services

Series U

Telegraph switching

Series V

Data communication over the telephone network

Series X

Data networks, open system communications and security

Series Y

Global information infrastructure, Internet protocol aspects, next-generation networks, Internet of Things and smart cities

Series Z

Languages and general software aspects for telecommunication systems




[*] To access the Recommendation, type the URL in the address field of your web browser,   followed   by   the   Recommendation's   unique   ID.   For   example, .

[1] See [b-UUID, 2017].

[2] The term data schema is used instead of data model, since the term data model is also used in a wider context.

[3] The numbering of the FDs on the figure implies a strict and fixed hierarchy. It should be noted that the association is aggregation and hence the hierarchy can change and an FD may move from being encompassed by one FD to being encompassed by another. Consider the numbering as simply a view of the current structure.

[4]   The Network Element scope of the direct inter face from a SDN controller to a Network Element in the infrastructure layer is similar to the EMS-to-NE management interface defined in the information models [ ITU-T G.874.1 ] (OTN), [ ITU-T G.8052 ] (Ethernet), and [ ITU-T G.8152 ] (MPLS-TP).

[5] Intent is an outcome-oriented form of interaction.

[6] Again, human language is a good analogy. The grammar remains constant, simple and repeating but the vocabulary is broad and changes/grows often rapidly.

[7]   Here we will use the term ‘device’ in a loose and undefined manner to aid in the discussion. The term is not defined because it is not important for our discussion, the generally understood concept is sufficient.