The figure depicts a broad standardization context. The concept embodied by the term Information Model (of Managed Elements etc.), abbreviated as IM, is separable from the concept of Process and Operation Model (covering definitions of activities). Clearly the Process and Operation Model influences and is influenced by the IM. Encoding in general (of information defined in IM Process and operation model) to achieve an Interface Implementation is also separable and is not considered further here. Each aspect of the problem is guided and constrained by an appropriate Architecture (e.g. Metamodel) that defines the breadth and scope of the aspect. The things in the IM are relevant to some activity identified in the Process and Operation Model. That relevance is necessary in order to fulfil some purpose of the system. The things in the IM are in many cases relevant to expose at some Interface in which case they will dictate some aspects of structure of information defined in IM and Process and Operation Model. The IM can be broken down into two parts:

• Broad conceptual model that articulates the concepts of the problem space (alternative names are purpose neutral, implementation neutral views)
• Specific purpose models that each articulate the solution to a specific problem (alternative names are purpose specific, implementation neutral views)

In summary, the following definitions apply to terms of the above Figure:

• Information Model (IM): The representation of things, their properties and their relationships. Example: TopologicalLink and TerminationPointEncapsulation are things that are interrelated and have properties represented via attributes.
• Process and Operation Model: The representation of the relevant activities required to facilitate the running of the business including the flows and interactions. Example: "IsolateCustomerProblem" and "Track&ManageCustomerProblem" are relevant activities that are interrelated by flows of control and information. "getAlarmList", "getAttribute" and "createFlowDomainFragment" are examples of operations.
• Solution Component Structure: The representation of the units of functionality assembled to support the information defined in the IM and in the Process and Operations Model. Example: NMS and EMS are solution components that support various process activities and maintain information. The two are interconnected as part of the structure of the management solution.
• Interface specification: The definition of the interactions between the solution components supporting the exchange of information and control associated with running of the business. This interaction is in terms of the information defined in the IM and in the Process and Operations Model.
• Interface implementation: The implementation form of the interfaces appropriate for the runtime environment.
• Architecture: The patterns, rules, metamodels and structures derived from the fundamental properties of the problem space that guide and constrain the development of the model of each aspect of the problem space.

This context describes how 3GPP/SA5 would use the FNIM to produce its specifications that would be used for FMC network management purpose. This context only refers to the model part. Note that the FNIM is not related to the design of any network management protocol. The FNIM has multiple components. Two such components are the Umbrella Information Model (UIM) and a number of concrete models (see definition of FNIM in section 0). The right-most box of the following diagram depicts the classes of the UIM. The middle box depicts one of the concrete models, i.e. the 3GPP IRP NRM concrete model. The concrete classes are designed as extension of UIM and must use the appropriate relations defined (see clause 6.1). Using the concrete classes (of the concrete model) as input, 3GPP/SA5 uses appropriate tools to generate and publish the various specifications.

This context describes how TM Forum would use the FNIM for FMC network management purpose.

The Federated Information Model (FIM) is a subset of the IM. It relies on a coherent Information Architecture (including meta-model to ensure integrity and coherence). The FIM focuses on IM relevant to the generation of interface specifications but does not cover the specific encoding. The positioning of interfaces is essentially dictated by the Solution Component Structure that defines boundaries. The following definitions apply to the figure:

• Information Model: See definition in section 4.2.1 "A broad standardization context".
• Federated Information Model (FIM): The parts of the IM that are being developed collaboratively or have been developed collaboratively and agreed by two or more standards bodies. Some of these parts will be found in the specific SDO or standard organization including expert group models.
• Federated Network Information Model (FNIM): The part of the FNIM that deals with Network domain considerations. There will be other domain models in future (F*IM).
• Umbrella Information Model (UIM): The parts of the FNIM that represent the agreed model structures that various SDOs or standard organizations including expert groups will use (via "specific linkages" including inheritance, mappings and other derivations Note 1) for their definitions of their respective Domain/Technology-specific concrete classes. The use of UIM maximizes the probability of the Domain/Technology-specific concrete classes being semantically consistent, a necessary characteristic for FMC NM purposes.
• 3GPP IM, TM Forum IM: The IM of all things relevant to the specific SDO or standard organization including expert group including elements that are federated and elements that are not. The federated elements are related to and/or derived from the UIM in the area of the FNIM.