The OS is the system, which performs OSFs.An OS may conceptually be considered as part of the NGN transport stratum, the NGN service stratum, both, or neither, depending on the OSFs that it realizes.

The NE is comprised of telecommunication equipment (or groups/parts of telecommunication equipment) and support equipment or any item or groups of items considered belonging to the telecommunications environment that performs NEFs. The NE may optionally contain any of the other management function blocks according to its implementation requirements. The NE has one or more standard Q-type interfaces and may optionally have B2B/C2B interfaces. An NE performs at least one of transport element functions (TEFs) or service element functions (SEFs), and so can be deployed in an NGN transport stratum or in an NGN service stratum or in both. Existing NE-like equipment that does not possess a standard management interface will gain access to the management infrastructure via a Q adapter (see A.1.9.1.1), which will provide the necessary functionality to convert between a non-standard and standard management interface. A Transport Network Element is an NE that performs only TEFs. A Service Network Element is an NE that performs only SEFs.

The DCN is a support service that provides the capability to establish paths for information flow between physical blocks in a management environment. The DCN may consist of a number of interconnected subnetworks of different types. The DCN may be a local path or a wide-area connection among distributed physical blocks. The DCN is technology-independent and may employ any single or combination of transmission technologies. In order for two or more physical blocks to exchange management information, they must be connected by a communications path and each element must support the same interface onto that communications path. Physical blocks communicate using a common communication mechanism which provides a set of Application Programming Interfaces (APIs) that include the services of the upper three protocol layers of the OSI Reference Model. Some of these API services expose the communications capabilities of the DCN and others expose common platform functions (e.g., Directory Services, Time Services, Security, etc.). Refer to ITU-T Recs Q.811 and Q.812 for specific interface protocols for information transfer through a DCN.

Several specializations of the OS physical block can be defined to support a physical realization of function blocks in logical layers (see Figures 9.1). The variety of types of management functionality is reflected in a corresponding flexibility for the mapping of OSFs to Operations Systems so that, in principle, any combination of specialized OSFs can map to an Operations System. As a result, the interfaces offered by an Operations System may include functionality from various OSF specializations (e.g., service management, service resource management and transport resource management functions). Such a flexible transition from the functional view to a physical view (subject to constraints from the information architecture as outlined in clause 14) allows for different types of OS interactions and corresponding Operations Systems Interface design patterns:

• Provider/consumer;
• Peer-to-peer.

As a result, a physical architecture may flatten the functional Management Layers described in 11.6 into a single, unified management layer for the co-management of several functional Management Layers. Examples of this layer co-management paradigm are shown in Figures 9.2-1 and 9.2-2. The unified management layer is opaque, i.e., the interworking of the functional Management Layers is invisible to the user of the Interface.

Management interface is an architectural concept that provides interconnection between physical blocks at reference points. Management interfaces provide, via specific communication protocols, for the interconnection of NEs and OSs through the DCN. Interactions between physical blocks, to exchange management information, are established dynamically at run time and are usually not defined statically at design time. In order for such dynamic interactions to occur, physical blocks must be connected by a communications path and each element must support compatible interfaces. It is useful to use the concept of an interface to simplify the communications problems arising from a multi-vendor, multi-capability network. The interface defines the specific protocols, commands, procedures, message formats and semantics used for the management communications between physical blocks. The goal of an interface specification is to ensure compatibility of devices interconnected to accomplish a given management function independent of the type of device or of the supplier. Figure A.2 shows the interconnection of the various management physical blocks by a set of standard interoperable interfaces. Management standard interfaces are defined corresponding to the reference points and are classified in two types:

• Provider interfaces: physical realizations of one or more provider reference points; each provider interface is depicted with a white lollipop or ball icon.
• Consumer interfaces: physical realizations of one or more consumer reference points; each consumer interface is depicted with a white crescent or socket icon.

An interface contains the mapping from the protocol-neutral reference point specifications to a protocol-specific specification. An interface consists of one or more reference points together with a single communication protocol binding, which is a protocol suite used to realize a communications path at these reference points.