This section describes the two key elements of FNIM (UIM and Domain/Technology-specific Concrete Models) in terms of model component relations (6.1/6.2) and production of model definitions specifications (6.3). The Umbrella Information Model (UIM) provides abstract definitions applicable across Domain/Technology-specific Concrete Models to enable end-to-end consistency of such definitions (it is described as 'abstract' in the sense that its components are used via "special linkages" by Domain/Technology-specific Concrete Models, and that it is not designed for the purpose of partial or full instantiation of its components and is not sufficient to provide meaningful network management service). Domain/Technology-specific Concrete Models are described as 'concrete models' in the sense that their instantiation is necessary to provide meaningful management services. These Domain/Technology-specific Concrete Models uses "special linkages" with the common definitions of the Umbrella Information Model (UIM) for the purpose of end-to-end consistency of management information semantics. In addition, these Domain/Technology-specific Concrete Models have specified relationships between each other to enable end-to-end monitoring and management of a converged network.

This section is a graphical representation of the FNIM in terms of relation between model components. There are two areas considered:

• The definitions of the classes inside the UIM model component.
• The definitions of relation (R0 in Figure 4) used between various classes in UIM model component and other model components.

The aim is to have identical R0 for use between the UIM model component and other model components while the UIM model component need to have no knowledge of its usage by classes of other model components. This will ensure consistency (e.g. resource management style, paradigm) for managing mobile managed resources, as well as other managed resources such as transport managed resources.

Taking the example of "3GPP wireless network classes" and the UIM, 3GPP model components (e.g. TS 32.622 [4]) would import relevant UIM classes and make derivatives for their use. R0 in this case is an inheritance relation. There are other forms of relations that could be defined.

This section is a graphical representation of the FNIM in terms of bilateral relation between each pair of model component, neither of which is a UIM model component. The relation between pairs of model components may not be same. Each relation may or may not be symmetrical. UIM may not be involved in such pair-wise relations.

Taking the example of a relation between 3GPP model components and BBF ATM model components (i.e. R3): the 3GPP model components would create necessary 3GPP defined ExternalIOC representing one of the classes of "BBF ATM network and device classes". This type of relation is used extensively in the 3GPP IRP framework for the purpose of navigation from one managed domain to another. In the case of the relationship between MTOSI and MEF there is an association where MEF does not provide a concrete model but instead a detailed abstract model. The MTOSI concrete model is mapped to the MEF 7 model (see [9]).

This section is a graphical representation of the FNIM in relation to tools that generate machine-readable model forms in various languages such as XSD, CORBA IDL, GDMO, etc. In the context of this document, The "Solution specifications" refers to only the model part and not the Operations/Notifications part (e.g. encoding of the managed resource modelled constructs over the wire). Examples of such are the various 3GPP NRM IRP SSs. They do not refer to the Interface specifications such as the 3GPP Interface IRP SSs. This document does not deal with the question if the Tool generates the Interface specifications. No single physical Repository is required to hold FNIM.