TMN functions can be implemented in a variety of physical configurations (ITU-T Recommendation M.3010 , M3060/Y.2401 ). The relationship of the functional blocks to physical equipment is shown in table A.1 which names the management physical blocks according to the set of function blocks which each is allowed to contain. For each physical block there is a function block which is characteristic of it and is mandatory for it to contain. There also exist other functions, which are optional for the physical blocks to contain. Table A.1 does not imply any restriction of possible implementations. The M/O qualifiers are examples from M3060/Y.2401  and do not have any implication for compliance in the 3GPP PLMN management architecture.
The subclauses below give the definitions for consideration in implementation schemes.
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.184.108.40.206), 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.
Transformation provides conversion between different protocols and data formats for information interchange between physical blocks. There are two types of transformation: adaptation and mediation that can apply at q or b2b/c2b reference points.
An adaptation device (AD), or adapter, provides transformation between a non-compliant physical entity to a NE to OS within an administrative domain. A Q-adapter (QA) is a physical block used to connect NE-like or OS-like physical blocks with non-compatible interfaces to Q interfaces. A B2B/C2B-adapter is a physical block used to connect non-compatible physical entities having a non-compatible communication mechanism in a non-compatible environment to an OS at the edge of an administrative domain.
A mediation device (MD) provides transformation between management physical blocks that incorporate incompatible communication mechanisms. A Q-mediation device (QMD) is a physical block that supports connections within one administrative domain. A B2B/C2B-mediation device is a physical block that supports connections of OSs in different administrative domains
A distributed multi-element structure is an architectural concept that represents a grouping of network elements that must be managed as a single entity for operational efficiency sake. Due to the distributed nature of their blocks and the complexity of their internal make up, it is sometimes difficult to distinguish between Distributed multi-element structures and a sub-network.
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:
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.
Management standard interfaces are realizations of specific reference points. The classes of references points correspond to the classes of interfaces.
Figure A.2 shows an example of a simplified physical view for a management implementation. This example is provided to assist in understanding the management physical blocks described in clause A.1.
(not reproduced yet)
Figure A.2: Example of a physical view M.3060/Y.2401