4 Network Configuration Management (CM)

32.106-13GPPConfiguration Management (CM)Part 1: Concept and requirementsRelease 4Telecommunication managementTS

4.1 General

In the development of a 3G network, three general phases can be described which represent different degrees of stability. Once the first stage is over, the system will cycle between the second and the third phases. This is known as the network life-cycle and includes:

1) the 3G network is installed and put into service;

2) the 3G network reaches certain stability and is only modified (dynamically) to satisfy short-term requirements. E.g. by (dynamic) re-configuration of resources or parameter modification; this stable state of a 3G network cannot be regarded as the final one because each equipment or SW modification will let the 3G network progress to an unstable state and require optimisation actions again;

3) the 3G network is being adjusted to meet the long-term requirements of the network operator and the customer, e.g. with regard to performance, capacity and customer satisfaction through the enhancement of the network or equipment up-grade.

During these phases, the operators will require adequate management functions to perform the necessary tasks.

4.1.1 Installing a 3G network

When a 3G network is installed and initialised for the first time, all NEs need to be introduced to the NM, the data for initialisation and SW for proper functioning need to be provided. All these actions are carried out to create NEs and to initialise them.

4.1.2 Operating a 3G network

Whilst in service, the operator needs to react to short term incidents such as traffic load requirements, which are different from the current network capabilities, NEs/NRs need to be re-configured and parameters need to be adapted to follow these day-to-day requirements.

4.1.3 Growing/pruning a 3G network

As the 3G network grows and matures new equipment is installed and understanding of system behaviour increases. Subscriber requirements/wishes may demand that operators modify their system. In addition manufacturers improve the infrastructure components and add features to their products hence the operator will start modifying the 3G network to profit from these changes and to improve subscriber satisfaction. Additionally, the 3G network configuration will be modified (i.e. it will be up-dated or up-graded) to cope with a need for increasing or decreasing network capacity. These actions are carried out for the long-term strategy of the operators to optimise the network. System up-date

Whenever the 3G network needs to be improved for reasons of reducing failures, the system will be up-dated. In this case SW or equipment will be replaced without adding new functionality or resources to the network. The basic function required is:

– the modification of existing SW/equipment; it may be necessary to introduce a different set of data to cope with the modified SW/equipment.

For system up-date the network shall not be disturbed in its function until the required modification is activated. This requires mechanisms to:

– do SW/data downloading in parallel with on-going traffic;

– isolate the affected NEs/NRs from traffic before the actual modification is done;

– minimise system outage due to the activation of up-dated components. System up-grade

System up-grade may affect all areas of 3G network activities and can be described as enhancements, whereby either new features or new facilities are implemented. This CM aspect also covers extensions, reductions or further replications of existing facilities. The CM functions employed are:

– Creation of NEs and/or NRs;

– Deletion of NEs and/or NRs; and

– Modification of NEs and/or NRs.

The following requirements are to apply:

– to support expeditious handling of SW and data while minimising impact on ongoing traffic;

– to follow a required sequence of up-grades: e.g. the new SW depends upon the availability of the new equipment functionality;

– to provide the capability to create an additional logical NE/NR without having installed the physical resource supporting it: for example it should be possible to create a cell in an RNC without the physical equipment present or connected. However, additional mechanisms should be in place to prevent any service connection to any physically non-existent NE/NR or reporting failures from non-existing NE/NR;

– to provide the capability to install an additional physical NE/NR without creation of the logical resource managing it (no management functionality) and without impact of the current functionality;

– to provide the capability to prevent the erroneous taking into service of a NE/NR which is not fully installed and initialised: whenever a NE/NR is modified (extension or reduction) it shall be taken out of service until the logical part of the procedure is finished. An extended NE/NR cannot be placed into service until all needed parameters and equipment are initialised. Likewise, a reduced NE/NR cannot be placed back into service until the applicable re‑configuration is performed.

When the network is up-graded by the addition of NEs or NRs or a change in the configuration, it is essential that the NE/NR can be restored to the configuration, which existed before the changes were made. This procedure is called "reversion" and is useful in maintaining service if any difficulty should arise from a network up-grade.

4.2 Operational context for CM

The CM functions available to the operator need to address various aspects beyond that which might strictly be regarded as management of the network. These include:

– assisting the operator in making the most timely and accurate changes thus avoiding lengthy waiting periods or complex scenarios;

– ensuring that CM actions will not have any secondary effects on the network other than the specified ones;

– providing mechanisms to protect the telecommunication-related traffic from effects due to CM actions – it shall be possible to inhibit traffic if a traffic affecting CM action is expected and to gracefully release calls prior to the closure of the resource;

– providing mechanisms to overcome data inconsistency problems by logging the modifications for reversion reasons, or to recover through data update from a second source.

4.2.1 Administrative aspects of CM

When managing the network by creating, deleting or modifying NEs/NRs, the operator should ensure that there is no uncontrolled impact on the network. The network management system therefore needs to support the following set of management functionalities when addressing various administrative aspects:

– Security;

– Data Validity;

– Data Consistency; and

– Resource Administration. Security aspects

It is ultimately up to the operator to ensure the network security by employing the appropriate mechanisms for control of logical and physical access.

Changes of the network configuration shall be possible only for operators with appropriate authorisation profiles. Data validity

It is the responsibility of all management systems and NEs that data input to and transferred between the systems is valid given the particular management context. Data consistency and distribution of the MIB

The Network Manager (NM) and Element Manager (EM) use different object model abstractions of the network’s (NEs’) physical and logical resources to be managed by these systems. This is the agreed Network Resource Model (NRM) between the NM and EM/NEs to be used at the N interface and EM-NE interface (see ref. 3G TS 32.102 [2] for the definition of these interfaces). The NRM of the N interface is fully standardised (see 3G TS 32.106-5 [3]) while the NRM for the EM-NE interface is product-specific and is not standardised in this or related TSs. The NE local representation of those physical and logical instantiated resources to be managed, as well as their accurate mapping onto the agreed object model abstraction, is also product-specific. Thus the consistency between the actual local representation of physical and logical resources to be managed within an NE, and the corresponding view of the OS, relies on:

Which information is exchanged between the NE and the management systems; For the EM-NE interface this is defined in a product-specific NRM, where the actual network infrastructure is modelled. This is internal to a specific development organisation and does not need to be open; thus it is not further discussed in the present document. In fact, by publishing the management information portion of these interfaces, too much of the internal design will be revealed and it may become impossible or at least very expensive and time-consuming to later enhance the systems using the interface. For the Itf‑N between NM and EM/NE, the NRM as mentioned above is defined in 3G TS 32.106-5 [3].

How such information is exchanged between NE and management systems – this is for the Itf‑N fully standardised by the present and related documents, while for the EM-NE interface only the protocol is standardised (cf. Figure 2 in 3G TS 32.102 [2]).

How information is locally represented and treated by an NE and by its associated (OSs); this is a product-specific choice of the manufacturers of NEs and OSs.

Where this information is kept; whether it is kept only at the "origin NEs" where the Managed Object Instances (MOIs) representing the managed NRs are created (NE-local MIB), or if also a copy of that information is kept in one or several of the OSs ("mirrored MIB"). This is again a product-specific choice of the manufacturers of NEs and OSs. If the "NE-local MIB" approach is chosen, the consistency "only" has to be maintained between the NEs, while if the "mirrored MIB" approach is chosen, the consistency has to maintained between the NEs as well as the NM/EM and the NEs.

A peer-to-peer data consistency between NM-EM and EM-NE does not guarantee overall data consistency from a network point of view. It is however possible for the NM to maintain consistency on the network level, as far as the information in the MIB for the Itf‑N is concerned, by comparing related information (MOIs and attributes) in all connected systems (EMs and NEs) in the managed network.

In order to promote data consistency, the following operational procedures are recommended:

Awareness of autonomous NE re-configuration:

local NE re-configuration, for example partial or full reversion mechanisms (either triggered autonomously or by an operator), should always be reported;

Define appropriate audit procedures on the N- and EM-NE- interface to support MIB re-synchronisation:

A. In case the "mirrored MIB" approach is chosen, take the following actions:

1. The NM shall be able to retrieve all management information from the EM and NE accessible via the Itf‑N by applying appropriate data retrieval methods (periodically or on request);

2. The NM shall after the retrieval compare the retrieved information with its own data and if necessary also compare related information between connected NEs (if the MIB stored in the NM already has been checked and found consistent, the latter step is not necessary);

3. The NM shall report any deviations between the NE’s view and the NM’s view, and related NEs’ views, to the operator;

  1. The NM shall automatically, or on operator command, after the check in step 2 above correct the deviating information in either the NM or the NEs (depending on whether the NEs or NM are regarded as "master" for the information; this is manufacturer dependent).

B. In case the "NE-local MIB" approach is chosen the following actions shall be taken:

1. The NM shall be able to retrieve all management information from the EM and NE accessible via the Itf‑N by applying appropriate data retrieval methods (periodically or on request);

2. The NM shall after the retrieval compare the retrieved information between connected NEs;

3. The NM shall report any deviations between the related NEs’ views to the operator;

4. The NM shall automatically, or on operator command, after the check in step 2 above correct the deviating information in the NEs.

– If the "mirrored MIB" approach is chosen, the NM/EM view shall be maintained. As far as possible, operational concepts for data manipulation should employ the NM/EM as the only managing system for an NE.
If however access to local NE data is given to maintenance personnel, the following actions are recommended/ necessary in order to enable the NM/EM to maintain data consistency:

– applying a remote OS terminal for the local access to the NE under consideration rather than directly modifying NE data without any control of the OS;

– changes made locally shall be notified to the managing OS(s).