SIST ETS 300 617 E1:2003
(Main)Digital cellular telecommunications system (Phase 2) (GSM); GSM network configuration management (GSM 12.06)
Digital cellular telecommunications system (Phase 2) (GSM); GSM network configuration management (GSM 12.06)
This European Telecommunication Standard (ETS) describes the Configuration Management (CM) aspects of Network Elements (NEs) which constitute a PLMN with initial emphasis on the Base Station System (BSS) management. This is described from a management perspective being decomposed into constituent functionalities, which in turn will allow the construction of a management object model using the object oriented paradigm to support open systems management (see GSM 12.20 (ETS 300 622) [14]). The ETS follows the methodology described in GSM 12.00 (ETS 300 612-1)[10]. This ETS defines a set of controls to be employed to effect set-up and changes to a PLMN, in such a way that operational capability, network integrity and inter working co operation are ensured. In this way, this ETS describes the interface behaviour for the management of PLMN NEs in the context of the described management environment. The context is described for both the Operation System (OS) and NE functionality. The standardisation of specific controls is outside of the scope of this ETS.
Digitalni celični telekomunikacijski sistem (faza 2) ¬– Upravljanje konfiguracije omrežja GSM (GSM 12.06)
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHP ID]D ¤±8SUDYOMDQMHNRQILJXUDFLMH
RPUHåMD*60 *60
Digital cellular telecommunications system (Phase 2) (GSM); GSM network configuration
management (GSM 12.06)
Ta slovenski standard je istoveten z: ETS 300 617 Edition 1
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN ETS 300 617
TELECOMMUNICATION June 1996
STANDARD
Source: ETSI TC-SMG Reference: DE/SMG-061206P
ICS: 33.060.50
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
Digital cellular telecommunications system (Phase 2);
GSM Network configuration management
(GSM 12.06)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.fr
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.
Page 2
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.
Page 3
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Contents
Foreword .5
Introduction.5
1 Scope .7
2 Normative references.7
3 Definitions, symbols and abbreviations.8
3.1 Definitions .8
3.2 Symbols .9
3.3 Abbreviations .9
4 Network configuration management .10
4.1 General .10
4.1.1 Installing a PLMN .10
4.1.2 Operating a PLMN.10
4.1.3 Growing/pruning a PLMN .10
4.1.3.1 System up-date.10
4.1.3.2 System up-grade .11
4.2 Operational context for configuration management.11
4.2.1 Administrative aspects of configuration management .11
4.2.1.1 Security aspects .12
4.2.1.2 Data validity .12
4.2.1.3 Data consistency .12
4.2.1.4 Resource administration.14
4.2.2 Configuration management triggers.14
5 Configuration management service components.15
5.1 System modification service component .15
5.2 System monitoring service component.16
6 Configuration management functions .17
6.1 System modification functions .17
6.1.1 Creation of network elements and network resources.17
6.1.2 Deletion of network elements and network resources .18
6.1.3 Conditioning of network elements and network resources.18
6.1.3.1 Considerations on conditioning mechanisms .18
6.1.3.2 Network traffic considerations .19
6.2 System monitoring functions.20
6.2.1 Information request function.20
6.2.2 Information report function .20
6.2.3 Response/report control function .20
7 BSS configuration management .21
7.1 Equipment management.21
7.1.1 Definition of equipment.21
7.1.2 Equipment management functions.21
7.1.2.1 Equipment availability management.22
7.1.2.2 Equipment utilisation management .22
7.1.2.3 Equipment identification.22
7.1.2.4 Equipment redundancy.22
7.1.2.5 Overload protection .22
7.1.2.6 Replaceability.23
7.1.2.7 Compatibility .23
7.2 Software management.23
Page 4
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
7.2.1 Definition of software . 23
7.2.2 Software management functions. 24
7.2.2.1 Receive the software delivery . 24
7.2.2.2 Transfer the software to the network element . 24
7.2.2.3 Identification of the software package. 25
7.2.2.4 Construct a loadable form of the software . 25
7.2.2.5 Load the software and execute. 25
7.2.2.6 Manage the local storage of software . 26
7.3 Logical configuration management . 26
7.3.1 Definition of logical configuration. 26
7.3.2 Logical parameter management requirements. 26
7.3.2.1 Create initial data elements and values . 26
7.3.2.2 Modify data values . 27
7.3.2.3 Delete data elements . 27
7.3.2.4 Read data values . 27
7.3.3 Logical functionality management requirements . 28
7.3.3.1 Enabling functionality . 28
7.3.3.2 Disabling functionality . 28
7.3.3.3 Cell configuration management function. 29
7.3.3.4 Adjacent cell configuration management function . 29
7.3.3.5 Power control management function . 29
7.3.3.6 Handover control management function. 30
7.3.3.7 Frequency control management function. 30
7.3.3.8 Protocol/timer control management function . 30
7.3.3.9 Functional building block management. 31
7.4 Modelling notes . 31
Annex A (informative): Examples of management procedures. 32
A.1 Network element and network resource management examples. 33
A.1.1 Network resource creation scenario (TRX) . 33
A.1.2 Network resource creation scenario (BTS). 36
A.1.3 Network resource deletion scenario (TRX). 37
A.1.4 Network resource deletion scenario (BTS). 38
A.2 Network element and network resource conditioning examples. 39
A.2.1 Network element/network resource conditioning scenario without traffic
impact . 39
A.2.2 Network element/network resource conditioning scenario with capacity
impact . 40
A.2.3 Network element/network resource conditioning scenario with traffic
impact on one network element/network resource. 41
A.2.4 Network element/network resource conditioning scenario with traffic
impact on multiple network elements/network resources. 42
Annex B (informative): Bibliography . 43
Annex C (informative): Register. 44
History. 45
Page 5
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Foreword
This European Telecommunication Standard (ETS) has been produced by the Special Mobile Group
(SMG) Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS describes the Configuration Management (CM) aspects of Network Elements (NEs) within the
Digital cellular telecommunications system. This ETS corresponds to GSM technical specification, GSM
12.06, version 4.1.1.
NOTE: TC-SMG has produced documents which give technical specifications for the
implementation of the Digital cellular telecommunications system. Historically, these
documents have been identified as GSM Technical Specifications (GSM-TSs). These
specifications may subsequently become I-ETSs (Phase 1), or European
Telecommunication Standards (ETSs)(Phase 2), whilst others may become ETSI
Technical Reports (ETRs). These ETSI-GSM Technical Specifications are, for editorial
reasons, still referred to in this ETS.
Transposition dates
Date of adoption of this ETS: 06 June 1996
Date of latest announcement of this ETS (doa): 26 September 1996
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 27 March 1997
Date of withdrawal of any conflicting National Standard (dow): 27 March 1997
Introduction
Configuration Management (CM), in general, provides the operator with the ability to perform effective
network management as the PLMN evolves. CM is initiated by the operator in various network elements of
the PLMN to meet the operator objectives.
CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as
part of an optimisation programme (e.g. modifications), and to maintain the overall Quality of Service. The
CM actions are initiated either as a single action on a network element of the PLMN or as part of a
complex procedure involving actions on many network elements.
Clause 4 provides a brief background of CM while Clause 5 explains CM services available to the
operator. Clause 6 breaks these services down into individual CM functions which will support the defined
services. Clause 7 describes the application of these services and functions to the BSS NE in a GSM
PLMN. In Annex A there are informative examples to illustrate the application of CM functions to complete
scenarios.
Page 6
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Blank page
Page 7
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
1 Scope
This European Telecommunication Standard (ETS) describes the Configuration Management (CM)
aspects of Network Elements (NEs) which constitute a PLMN with initial emphasis on the Base Station
System (BSS) management. This is described from a management perspective being decomposed into
constituent functionalities, which in turn will allow the construction of a management object model using
the object oriented paradigm to support open systems management (see GSM 12.20 (ETS 300 622) [14]).
The ETS follows the methodology described in GSM 12.00 (ETS 300 612-1)[10].
This ETS defines a set of controls to be employed to effect set-up and changes to a PLMN, in such a way
that operational capability, network integrity and inter working co-operation are ensured. In this way, this
ETS describes the interface behaviour for the management of PLMN NEs in the context of the described
management environment. The context is described for both the Operation System (OS) and NE
functionality. The standardisation of specific controls is outside of the scope of this ETS.
2 Normative references
This ETS incorporates by dated or undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references subsequent amendments to, or revisions of, any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1] GSM 01.04 (ETR 100): "Digital cellular telecommunication system (Phase 2);
Abbreviations and acronyms".
[2] GSM 04.06 (ETS 300 555): "Digital cellular telecommunication system
(Phase 2); Mobile Station - Base Station System (MS - BSS) interface Data Link
(DL) layer specification".
[3] GSM 04.08 (ETS 300 557): "Digital cellular telecommunication system
(Phase 2); Mobile radio interface layer 3 specification".
[4] GSM 05.02 (ETS 300 574): "Digital cellular telecommunication system
(Phase 2); Multiplexing and multiple access on the radio path".
[5] GSM 05.05 (ETS 300 577): "Digital cellular telecommunication system
(Phase 2); Radio transmission and reception".
[6] GSM 05.08 (ETS 300 578): "Digital cellular telecommunication system
(Phase 2); Radio subsystem link control".
[7] GSM 08.08 (ETS 300 590): "Digital cellular telecommunication system
(Phase 2); Mobile Switching Centre - Base Station System (MSC - BSS)
interface Layer 3 specification".
[8] GSM 08.52 (ETS 300 593): "Digital cellular telecommunication system
(Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS)
interface Interface principles".
[9] GSM 08.58 (ETS 300 596): "Digital cellular telecommunication system
(Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS)
interface Layer 3 specification".
[10] GSM 12.00 (ETS 300 612-1): "Digital cellular telecommunication system
(Phase 2); Objectives and structure of Network Management (NM)".
[11] GSM 12.01 (ETS 300 612-2): "Digital cellular telecommunication system
(Phase 2); Common aspects of GSM Network Management (NM)".
[12] GSM 12.03 (ETS 300 614): "Digital cellular telecommunication system
(Phase 2); Security management".
Page 8
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
[13] GSM 12.04 (ETS 300 615): "Digital cellular telecommunication system
(Phase 2); Performance data measurements".
[14] GSM 12.20 (ETS 300 622): "Digital cellular telecommunication system
(Phase 2); Base Station System (BSS) Management Information".
[15] CCITT Recommendation X.721 (ISO/IEC 10165-2): "Information technology -
Open Systems Interconnection - Structure of management information:
Definition of management information".
[16] CCITT Recommendation X.731 (ISO/IEC 10164-2): "Information technology -
Open Systems Interconnection - Systems Management: State management
function".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the puposes of this ETS the following definitions apply.
Data: is any information or set of information required to give software or equipment or combinations
thereof a specific state of functionality.
Equipment: is one or more hardware items which correspond to a manageable or supervisable unit or is
described in an equipment model.
Firmware: is a term used in contrast to software to identify the hard-coded program which is not
downloadable on the system.
Hardware: is each and every tangible item.
Network Element: is a discrete telecommunications entity which can be managed over a specific
interface e.g. the BSS.
Network Resource: is a component of a Network Element which can be identified as a discrete separate
unit e.g. BSC, BTS or TRX .
Operator: is either
- a human being controlling and managing the network; or,
- a company running a network (the PLMN operator).
Optimisation: of the network is each up-date or modification to improve the network handling and/or to
enhance subscriber satisfaction. The aim is to maximise the performance of the system.
Re-configuration: is the re-arrangement of the parts, hardware and/or software that make up the PLMN.
A re-configuration can be of the parts of a single NE or can be the re-arrangement of the NEs themselves,
as the parts of the PLMN.
Reversion: is a procedure by which a configuration, which existed before changes were made, is
restored.
Software: is a term used in contrast to firmware to refer to all programs which can be loaded to and used
in a particular system.
Up-Dates: generally consist of software, firmware, equipment and hardware, designed only to consolidate
one or more modifications to counter-act errors. As such, they do not offer new facilities or features and
only apply to existing NEs.
Up-Grades: can be of the following types:
Page 9
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
- enhancement - the addition of new features or facilities to the PLMN;
- extension - the addition of replicas of existing entities.
3.2 Symbols
None
3.3 Abbreviations
For the puposes of this ETS the following abbreviations apply.
Further abbreviations used may be found in ETR 100 [1].
BSIC Base Station Identification Code
BSS Base Station System
CM Configuration Management
FM Fault Management
FW Firmware
HW Hardware
MIB Management Information Base
MOC Managed Object Class
NE Network Element
NR Network Resource
OS Operation System
SW Software
TRX Transceiver
Page 10
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
4 Network configuration management
4.1 General
In the development of a PLMN, 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 PLMN is installed and put into service;
2) the PLMN 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 PLMN cannot be regarded as the final one because each equipment or SW modification
will let the PLMN progress to an unstable state and require optimisation actions again;
3) the PLMN 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 PLMN
When a PLMN is installed and initialised for the first time, all NEs need to be introduced to the OS, 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 PLMN
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 PLMN
As the PLMN 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 PLMN to profit from these changes and to improve subscriber satisfaction.
Additionally, the PLMN 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.
4.1.3.1 System up-date
Whenever the PLMN 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 functionalities 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.
Page 11
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
4.1.3.2 System up-grade
System up-grade may affect all areas of PLMN activities and can be described as enhancements,
whereby either new features or new facilities are implemented. Also extensions, reductions or further
replications of existing facilities are covered by this CM aspect. 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 a BSS 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 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 configuration management
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 telephony-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 configuration management
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.
Page 12
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
4.2.1.1 Security aspects
It is up to the operator to ensure the network security by employing the appropriate mechanisms for
control of logical and physical access.
4.2.1.2 Data validity
It is also up to the operator to ensure that data used in CM is valid given the particular network
configuration. Thus, the operator is responsible for the data setting in a given context.
4.2.1.3 Data consistency
The NE-OS relationship employs an object model abstraction of the NE's physical and logical resources to
be managed by the OS which is the agreed MIB between NE and OS. 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 a pure matter of the NE manufacturer. 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, totally relies on:
−− which information is exchanged between NE and OS; this is mainly a matter for the GSM 12 series,
defining object models for various functional areas and/or of agreements between the network
operator and his manufacturer(s);
−− how such information is exchanged between NE and OS; this is also a matter for other GSM 12
series documents, refer to GSM 12.01 [11];
−− how information is locally represented and treated by an NE and by its associated OS(s); this is left
to the manufacturers of NEs and OSs.
Page 13
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Figure 1: NE - OS data relationship.
A peer-to-peer data consistency between NE and OS does not guarantee overall data consistency from a
network point of view. Consistency between related data is restricted to the information level offered by the
information abstraction common to both the NE and the OS, and thus may be better called consistency on
the MIB level.
While complete data consistency may not be possible, it is up to the operator and manufacturer to define
and support an appropriate set of procedures to ensure that the required Quality of Service is maintained.
In order to promote data consistency, the following operational procedures are recommended:
−− always use confirmed services:
all types of OS-NE information exchange leading or possibly leading to modifications of the NE's
database or the OS's database should be confirmed;
−− control of autonomous NE/NR re-configuration:
local NE/NR re-configuration, for example partial or full reversion mechanisms (either triggered
autonomously or by a local operator), should be reported;
−− define appropriate audit procedures on the NE - OS Interface to support NE - OS data re-
synchronisation, for example:
− the OS shall be able to retrieve all management information from the NE accessible via the
NE - OS management interface by applying appropriate data retrieval methods (periodically
or on request);
− the OS shall be able to compare the retrieved information with its own data;
− the OS shall be able to report any deviations between the NE's view and the OS's view to the
operator;
−− maintain the OS view: As far as possible operational concepts for data manipulation should employ
the OS(s) as the only managing instance(s) for an NE to be managed. If however access to local
NE data is given to maintenance personnel quasi data consistency is achieved by:
− 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) as defined in the appropriate
information model.
Page 14
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
4.2.1.4 Resource administration
Within this document state handling shall follow the rules set by the ISO nomenclature (refer to CCITT
Recommendation X.721 [15]) but this shall not imply any implementation requirements.
Before a resource is re-configured by the operator, it may be necessary that the resource supporting the
service which is being modified, is taken out of service. This is to minimise any difficulties experienced by
subscribers. The means to provide that functionality to the operator is called resource administration.
The operator should be able to take out of service a resource without disrupting the traffic (e.g. if
maintenance needs to be done on the network). This can be achieved by not allowing new traffic on the
resource, but giving the current users the chance to finish their calls. This operator action is called
"SHUT_DOWN" which puts the system into the "SHUTTING_DOWN" state. The SHUTTING_DOWN
state will eventually lead to the "LOCKED" state as soon as the last user has finished the call. It might be
that some resources cannot be SHUT_DOWN and need to be isolated without an intermediate state. This
action is termed "LOCK". Once the configuration is completed by the operator, the "UNLOCK" action is
used to put the resource into the "UNLOCKED" state.
It is common that, within the network, resources have functional inter-dependencies, so that when taking a
resource out of service, some others also should be taken out of service. This process may have several
levels of ripple effects, resulting in a complex procedure. To avoid any mistake, or damage to the
operation of the network, the operator will indicate the major resource to be taken out of service; the state
propagation, and how the subsequent resources will be affected by this, is dependent on the system
architecture.
Additionally, the state of the resource may be qualified with (refer to CCITT Recommendation X.731 [16]):
− Alarm status;
− Procedural status;
− Availability status;
− Control status;
− Standby status;
− Unknown status.
4.2.2 Configuration management triggers
There are various sources which can trigger CM actions. For example an operator may wish to modify the
current structure or to set parameters for quality of service improvements.
Alternatively, the system, or a particular part of it, can automatically trigger system modification actions
because it needs to recover from faults or to escape overload situations (GSM 04.08 [3], GSM 08.08 [7],
GSM 08.58 [9]). This ETS only considers the operator triggered re-configurations. The autonomously
triggered re-configurations are not within the scope of this document, neither are the mechanisms
employed.
An operator initiated re-configuration may be required for the optimisation of the PLMN or NE. This may
result from an analysis of traffic. Under-utilised equipment may be better employed in another way to cater
for extra load, either temporarily or permanently.
Some typical CM triggers are the performance measurement results, obtained from measurements
defined in GSM 12.04 [13]. GSM 12.04 covers not only typical network configuration evaluation related
performance measurements such as hand-over success and failure and the use of power controls on up-
link and down-link connections, but also traffic measurements and measurements concerning resource
access, resource availability and Quality of Service. These measurements support network configuration
evaluation on a short as well as a long term basis.
Other CM triggers may be generated internally to the PLMN administrations which may e.g. determine that
the maximum capacity of an HLR, EIR or AUC is reached.
Page 15
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
5 Configuration management service components
While a GSM network is first installed and brought into service, and following installation the PLMN
operator will enhance and adapt the network to short and long term requirements. In addition, it will be
optimised to satisfy customer needs. To cover these aspects of CM, the system will provide the operator
with the following capabilities:
− initial system installation to establish the network;
− system operation to adapt the system to short term requirements;
− system up-date whenever it is necessary to modify the system to overcome SW bugs or equipment
faults;
− system up-grade to enhance or extend the network by features or equipment respectively.
These capabilities are provided by the management system through its service components:
− system modification to change the network to meet the operators requirements;
− system monitoring to gain an overview on the present SW, equipment and data situation of the
network.
The service components will be explained in more detail in the following subclauses.
5.1 System modification service component
Whenever it is necessary to adapt the system data to a new requirement due to optimisation or new
network configurations, it will require an operator action to introduce new or modified data into the system.
The data will be distributed to:
− either one NE when dealing with a locally limited modification; or,
− to each NE concerned when the change affects multiple NEs; and,
− to the other OSs in the case where multiple OSs exist in the same management domain.
This implies the necessity of mechanisms to ensure data integrity and to maintain system data
consistency.
To be able to control the operation of the network, the OS should have all data for each node it is
controlling. The detailed definitions of these data items are specified in GSM 12.20 [14].
The concept of system modification includes the following aspects:
− normally, before subscriber impacting data modifications are performed, the NEs/NRs concerned
are cleared from traffic in a controlled way;
NOTE: In the case of "frequency re-definition" it is not necessary to clear the affected NRs
from traffic, because a synchronisation mechanism is implemented between MS and
NE to prevent any subscriber impact (refer to GSM 04.06 [2]).
− only once all needed data is given to the system, are the concerned NEs/NRs put back into traffic
again;
− when the data modification is performed, the affected NEs and the controlling OS will up-date their
local data to ensure data consistency within the system;
− safeguards shall be available within the NEs to prevent changes to configuration affecting service(s)
in use. In emergencies, it shall be possible to override these safeguards.
On occasion, modifications may not be stable or not fulfil the operator intentions. In these cases, reversion
to the previous stable configuration may be necessary. Occasionally there will be changes to the network
that create a new configuration which cannot revert to any previous network status for protection. Such
changes may involve major equipment modification to the core elements of the network or re-distribution
of traffic across interconnected nodes to other Operators. In these cases it is necessary to implement the
changes and to manage the consequences of any problems or failures without the protection of
'reversion', as equipment may have been removed or the work programme may be complex, time limited
and expensive.
Page 16
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
Progress of these changes should be sequential through an agreed milestone plan which includes
effective tests to prove network functionality with only one action, or a coherent series of actions,
completed at a time. The decision points, beyond which there is no return, should be clearly identified.
"Automatic re-configuration" shall not be dealt with in this document as it is dependent on the
implementation. However, if an automatic re-configuration occurs, the operator shall be informed of the
result.
5.2 System monitoring service component
The system monitoring service component provides the operator with the ability to receive reports (on
request or spontaneously) on the configuration of the entire network or parts of it from managed NEs.
These consist of structure, states, versions employed and data settings. Spontaneous reports are sent by
the NE if there was an autonomous change of, for example, the states or other values due to fault
management actions. Also, the OS may ask the managed NE to send the information required to the OS
at any time.
For example the following data will be provided by the NE on request:
− structure and state of the equipment managed by the OS:
the information as such is important for the operator to gain a consistent view on the system
availability;
− information about the currently installed equipment, FW, SW versions and which combinations are
compatible with each other;
− frequencies used in each cell;
− performance data related to cell coverage (refer to GSM 12.04 [13]);
− cell configuration data:
such as cell power, protocol timers or cell identity.
Any inconsistencies found during system monitoring by the OS should be reported to the operator, and it
is left to the operator to take appropriate actions.
Page 17
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
6 Configuration management functions
6.1 System modification functions
The requirements of CM and their usage lead to basic CM functions to be defined for the network. These
describe the required actions on managed elements (NEs or NRs) and the expected reactions. The
system modification functions described are:
− Creation of Network Elements and Resources;
− Deletion of Network Elements and Resources;
− Conditioning of Network Elements and Resources.
For each of these areas there are example scenarios given in Annex A to explain the described CM
functions. This illustrates possible ways of combining management functions to achieve the required
processes. They are not intended to represent any specific implementation. The scenarios have been
developed based on the major requirements for the system:
− minimum disturbance of the network by taking the affected resources out of service if needed;
− physical modifications should be independent of the related logical modifications;
− all the required actions to satisfy a defined task should be completed correctly before the resources
can be brought into service;
− data consistency checks shall be performed as described in subclause 4.2.1.3.
There are three aspects of NE and NR management which can be distinguished:
1) Management of the physical aspect (equipment);
2) Management of the executable aspect (SW and FW); and,
3) Management of the logical aspect (data).
All three management aspects are addressed, but not all aspects of equipment and SW management are
covered by this standard because of their implementation dependencies.
6.1.1 Creation of network elements and network resources
The creation of a NE or NR is used to initially set up a PLMN or to extend an already existing network. The
action of creation is a combination of installation, initialisation and introduction of the newly installed
equipment to the network and to the OS which will control it. The creation can affect equipment, SW and
data.
Whenever a PLMN or parts of it are installed, the created NEs/NRs requires to be:
− physically installed and tested and initialised with a possible default configuration;
− logically installed by means of introduction to the network possibly involving changes to existing
NE/NR configurations (e.g. neighbour cell descriptions);
− allowed to be put into service.
The sequence of physical and logical installation may vary depending on the specific PLMN operator
strategy. In case the logical creation takes place before the physical creation no related alarms shall be
reported to the operator.
Page 18
ETS 300 617: June 1996 (GSM 12.06 version 4.1.1)
6.1.2 Deletion of network elements and network resources
If a network is found to be over-equipped, the operator may wish to reduce the scale of the network or to
re-use the spare equipment elsewhere. This can occur when an operator over-estimates the traffic in one
area and, for example, under-estimates the load in a different one.
The deletion of a NE or NR requires:
− taking the affected NEs or NRs out of service;
− logical removal from the network (possibly involving changes to other NE or NR configurations, for
example, neighbour cell description);
− if necessary, the physical dismantling of the equipment;
− return of other affected NEs or NRs to service.
The sequence of logical and physical removal will not matter if the affected NEs are taken out of service
prior to their removal. This will help to protect the network from error situations.
6.1.3 Conditioning of network elements and network resources
There are three categories of modifications to be regarded with respect to N
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...