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

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).

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]).

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.

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.

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.

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.

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.

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).