Content for  TS 32.107  Word version:  16.1.0

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


6  Elements of the FNIMWord‑p. 15

6.1  FNIM components

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.

6.2  Relations between model components (including UIM)

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.
[not reproduced yet]
Figure 4: Relation between UIM model component and other model components
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.

6.3  Relations among pairs of model componentsWord‑p. 16
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.
[not reproduced yet]
Figure 5: Relation between pairs of model components (not involving UIM model component)
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]).

6.4  Production of solutions re FNIM

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.
[not reproduced yet]
Figure 6: (Model) Solution production related to FNIM

7  Name Convention for class instances (managed objects)Word‑p. 18

7.1  Background

FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard organizations including expert groups. The model(s) contain classes of managed resources. Instances of these classes are identified by an identifier (called name in this document).
To maintain integrity of the class instances of the federated model, the names of all instances, whose classes are defined under the federated model, must be unambiguous, i.e. an (unambiguous) name can only refer to one instance and an instance may have more than one (unambiguous) name.
For simplicity, FMC NM employs unique names, i.e. one name can only refer to one instance and one instance have at most one name.

7.1.1  Name

A name is a unique identification of an FMC FNIM specified managed resource instance.

7.1.2  Name space

A name space (NS) is a collection of names. This name convention uses a hierarchical containment structure, including its simplest form - the one-level, flat NS (the rightmost NS of Figure 7). This name convention does not support an arbitrarily connected NS, or graph structure, in which a named managed resource can be both child and parent of another named managed resource.
The Figure below shows some examples of supported NSs.
[not reproduced yet]
Figure 7: Examples of supported name spaces

7.1.3  Unique namesWord‑p. 19
Names in a NS can be organised as one or more inverted tree hierarchies (see the left-most two NSs of Figure 7). A managed resource instance that contains another one is referred to as the superior (parent), whereas the contained managed resource instance is referred to as the subordinate (child).
FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard organizations including expert groups technology-domain-specific-models. The model(s) contain classes of managed resources. Each instance has a name.
From the perspective of FMC NM, the FMC NS is partitioned into various (sub) NSs. Each (sub) NS is a collection of names of instances, whose classes are defined by the corresponding technology-domain-specific-model.
For illustration, suppose the following Figure 8 shows the (sub) NSs for names of instances whose classes are defined by, say 3GPP/SA5 [4] (the one on the left) and MEF [5] (the one on the right of the figure).
[not reproduced yet]
Figure 8: Two (sub) name spaces
This document does not specify the following, since they are specified already by specifications of various technology-domain-specific-models:
  • The method by which the names within a (sub) NS can be made unique;
This document specifies the method by which names among all (sub) NSs of the FNIM can be made unique.
The following procedural steps apply for operators involved:
  • Register itself with a domain name (e.g. "") with a domain name registrar that is accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and number systems of the Internet.
  • For each (sub) NS it manages, construct a naming-path using the two domain components (dc=acme, dc=com) from its registered domain name.
    • The name-path may contain just the two domain components from its registered domain name. It may also contain more domain components such as organization units, e.g. (dc=FixedNetwork, dc=acme, dc=com; dc=mobileNetwork, dc=acme, dc=com) or localities, e.g. (dc=montreal, dc=acme, dc=com; dc=Sorrento, dc=acme, dc=com).
  • Use name-path as the root of its (sub) NSs.
The following Figure 9 illustrates the use of two name-paths, where one has three and the other has two domain components, as the name-paths for the two (sub) NSs.
[not reproduced yet]
Figure 9: Use of two name-paths

Up   Top   ToC