Content for  TS 32.107  Word version:  16.1.0

Top   Top   Up   Prev   Next
1…   4…   6…   A…


4  Characteristics and context of FNIMWord‑p. 8

4.1  Characteristics

The FNIM is "large scale" in the following sense:
  • Different authorities (SDOs or standard organizations including expert group) are responsible for the development, maintenance and evolution of their own domain specific models.
  • Operators may use the whole or part of the FNIM depending on their own business cases.
  • Vendors can supply products using part of the FNIM depending on their own business cases.
  • The FNIM needs to hold thousands of inter-related modelled entities. Different versions of modelled entities can co-exist in FNIM.

4.2  Contexts of FNIM

4.2.1  A broad standardization context

[not reproduced yet]
Figure 1: Broad standardization context
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.

4.2.2  Integration with 3GPP/SA5 standard production processesWord‑p. 9
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.
[not reproduced yet]
Figure 2: Context of 3GPP/SA5 usage of FNIM

4.2.3  Integration with TM Forum's universe of discourseWord‑p. 10
This context describes how TM Forum would use the FNIM for FMC network management purpose.
[not reproduced yet]
Figure 3: Context of TM Forum usage of various Models
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.

5  Features of FNIMWord‑p. 12

5.1  Introduction

This section describes FNIM features that are essential for the maintenance of the integrity of a large and scalable FMC network model.

5.2  Model components

The FMC network model is partitioned into model components. Clear rules are defined for inter-relationship of model components. The rules should be simple and stable (not changing frequently).
Use of model components and adherence of the simple model component inter-relationship has the following advantages.
  • It removes the need to keep the evolution of various model components in synchrony (see more on 5.6). For example, it is a valid implementation where one model component has evolved (requiring new solution) while other model component remained unchanged (does not require new solution).
  • Domain experts (e.g. radio experts) can focus their design on their model components and (can, if they want to) be ignorant of contents of other model components (e.g., mobile backhaul networks experts).

5.3  UIM Model component partition

The UIM model component is further partitioned. The partitioning of the UIM model component supports the following:
  • A body (e.g. SDO or standard organization including expert group) adoption/use of UIM specification releases/versions need not be lockstep with the availability of the UIM specification releases/versions.
  • A body adopting/using a UIM specification may or may not use a particular UIM partition, as long as the partition in question is not classified as essential or mandatory for adoption/usage.
  • A vendor's implementation needs not have lockstep with UIM specification releases/versions.
  • A vendor may or may not implement a specified UIM partition, as long as the partition in question is not classified as essential or mandatory by the body that governs solutions in that part of the problem space.
  • A solution, an assembly of capabilities specified by UIM partitions of the UIM model components and other model components, must be such that mixed versions of UIM partitions and their asynchronous upgrades are achievable (Lifecycle Compatibility [13]).

5.4  Ability to navigate among instances of different model components

This ability allows an instance (source instance) of a class defined in one model component (source model component) to relate (navigate) to another instance (target instance) whose class is defined in another model component (called target model component).
Two mechanisms are recommended.
  • The source model component uses a class called ExternalIOC. An instance of this ExternalIOC is a representation of the target instance (which in turn, is the representation of a function under management). In the source model component, the source instance is related (can navigate) to this ExternalIOC instance. ExternalIOC instance captures some information of the target instance such as the DN of the target instance. How this information is kept in synchrony with that of the target instance is case dependent.
  • The source instance is related (enables navigation) to the target instance, i.e. the source instance would capture the unique name by which the target instance is known, such as the DN of the target instance. How this information is kept in synchrony with that of the target instance is case dependent.
The source and target instances may be managed by different Domain Managers.
This source and target model components may be defined by different SDOs or standard organizations including expert groups.
Note that the use of these two mechanisms is well known.

5.5  Ability to import model elements designed elsewhereWord‑p. 13
Use of this feature is for model component-A to include model elements (e.g. classes) defined in another model component, say model component-B.
This feature can also be used, say by a 3GPP specified model component-A, to include model elements (e.g. classes for transport managed resources, TM Forum defined classes) defined in another model component, say component-B, specified by other organizations (e.g. TM Forum, BBF, etc.)
This feature is essentially a copy and paste procedure with a clear indication of the 'source' or design authority of the imported model elements.
Note that the concept of Import is well known in software and modelling design work.

5.6  Independence of tool and platform

Use of FNIM does not require nor mandate the use of a specific tool. Tool and model are evolving at their own paces and decoupling them allows standard authors to choose the best tool for the job (e.g., validation model design, generation of solution).
Decoupling model design from specific platform (e.g. development platform, testing platform) is a necessary condition since it is unrealistic to assume a particular platform for all products in compliance to FMC NM standards.

5.7  Independence of solution technology and access protocol design

This does not imply nor mandate the use of a specific machine-readable language, e.g. XSD, CORBA IDL, GDMO, etc, to express the designed model elements.
This does not imply nor mandate the use of a specific access protocol (e.g. to manipulate or query the parameter values of a class instance). It ensures no dependency can exist between model design and access protocol design.

5.8  Experience

The FNIM concept has been used successfully, albeit in a much smaller scale than FMC network model, in the following cases.
  • 3GPP2 develop/maintain/evolve the model component(s) related to CDMA2000 technologies, while 3GPP does similar work related to GSM/UTRAN/EUTRAN technologies plus the GENERIC NRM IRP model component. Vendors can implement standard network management solutions for these technologies and operators' IRPManagers (a 3GPP IRP Framework conceptual object) can use these solutions in a unified way.
  • BBF/Home develop/maintain/evolve the H(e)NB network resource models. Relevant IRP Framework model components makes references to those H(e)NB network resource models allowing, for example, an IRPManager to download configuration files to, upload PM counters from and receive alarm notifications from H(e)NBs. Vendors can implement standard network management solutions for these technologies and operators' IRPManagers can use these solutions in a unified way.

5.9  Model components release handlingWord‑p. 14
Each SDO or standard organization including expert group has its own well understood and maintained specifications release mechanism. Each release will have some definition of features that need to be covered and some timeframe for that coverage. There is clearly a time gap between the completion of a new feature and its availability of the management solution for that new feature. Some vendor/operator organizations may choose to intercept developing work (early adopters) whilst others may chose to wait until the solution is complete and has been field proven for several releases (laggards). It is critical that the mechanisms and structures put in place to enable the development and use of a converged model do not disrupt any standards body's ability to deliver to its committed schedule.
Having said that, it is also clear that to move to a more coherent standardization environment that supports the converged network, rather than siloed and inefficiently managed network fragments, will require investment and will require changes in approach by all concerned.
Recognizing that a change of approach will only be applied where there is a suitable business driver, it is expected that the industry business case will be needed to justify any specific deployment impacts to ease the perception of cost (see [16] for examples of industry business cases).

Up   Top   ToC