Study on System Maintenance over Itf-N

3GPP TR 32.822 V9.0.0 (2009-09)
Technical Report
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
Telecommunication management;
Study on System Maintenance over Itf-N
(Release 9)
	 EMBED Word.Picture.8  

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.



Keywords
UMTS, management


3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

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.

© 2009, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc242186554 \h 4
Introduction	 PAGEREF _Toc242186555 \h 4
1	Scope	 PAGEREF _Toc242186556 \h 5
2	References	 PAGEREF _Toc242186557 \h 5
3	Definitions, symbols and abbreviations	 PAGEREF _Toc242186558 \h 5
3.1	Definitions	 PAGEREF _Toc242186559 \h 5
3.2	Symbols	 PAGEREF _Toc242186560 \h 5
3.3	Abbreviations	 PAGEREF _Toc242186561 \h 5
4	Concepts and background	 PAGEREF _Toc242186562 \h 5
5	Requirements of system maintenance over Itf-N	 PAGEREF _Toc242186563 \h 6
5.1	Business level requirements	 PAGEREF _Toc242186564 \h 6
5.1.1	High-level use case	 PAGEREF _Toc242186565 \h 6
5.1.2	EMS maintenance over Itf-N	 PAGEREF _Toc242186566 \h 6
5.2	Specification level requirements	 PAGEREF _Toc242186567 \h 6
5.2.1	Use cases	 PAGEREF _Toc242186568 \h 6
5.2.1.2	Time synchronization between IRPManager and IRPAgent	 PAGEREF _Toc242186569 \h 6
5.2.1.3	Resources monitoring on EMS	 PAGEREF _Toc242186570 \h 8
5.2.1.4	Software management of EMS	 PAGEREF _Toc242186571 \h 8
5.2.2	Requirements	 PAGEREF _Toc242186572 \h 9
5.2.2.1	 PAGEREF _Toc242186573 \h 9
5.2.2.2	Time synchronization between IRPManager and IRPAgent	 PAGEREF _Toc242186574 \h 9
5.2.2.3	Resources monitoring on EMS	 PAGEREF _Toc242186575 \h 9
5.2.2.4	Software version management of EMS	 PAGEREF _Toc242186576 \h 9
6	Solution for system maintenance over Itf-N	 PAGEREF _Toc242186577 \h 10
6.1	Existing standards or de-facto standards	 PAGEREF _Toc242186578 \h 10
6.2	Detailed proposal	 PAGEREF _Toc242186579 \h 10
6.2.1	Resources monitoring on EMS	 PAGEREF _Toc242186580 \h 10
6.2.2	Software management of EMS	 PAGEREF _Toc242186581 \h 11
6.3.3	Time synchronization between IRPManager and IRPAgent	 PAGEREF _Toc242186582 \h 11
7	Conclusions	 PAGEREF _Toc242186583 \h 11
Annex A:	Change history	 PAGEREF _Toc242186584 \h 12

Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x	the first digit:
1	presented to TSG for information;
2	presented to TSG for approval;
3	or greater indicates TSG approved document under change control.
y	the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc.
z	the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
The EMS (Element Management System) plays an important role in network management architecture. In general, the EMS is provided by vendors of the nodes and operators, using IRPManager, can manage the nodes through the EMS. This study is to evaluate if some key or core EMS management functions can be standardized to support a better (most cost/effective) management paradigm in a multi-vendor network environment.

1	Scope
The present document studies key maintenance functions of element management system (EMS) in order to decide which one is necessary and could be managed over Itf-N, and makes a set of recommendations.
2	References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[ seq reference 1]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2]	ITU-T M.3020-2000: "TMN interface specification methodology".
3	Definitions, symbols and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. 
A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
(void)
3.2	Symbols
For the purposes of the present document, the following symbols apply:
(void)

3.3	Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. 
An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1].
EMS	Element Management System

4	Concepts and background
The EMS plays an important role in network management architecture. In general, the EMS is provided by vendors of the nodes and operators, using IRPManager, can manage the nodes through the EMS. Therefore, when EMS is unavailable or down, the operator, using IRPManager, would not be able to manage the nodes. Vendors of EMS supply proprietary interface via which the EMS itself can be managed and maintained. 
This study is to evaluate if some key or core EMS management functions can be standardized to support a better (most cost/effective) management paradigm in a multi-vendor network environment.
5	Requirements of system maintenance over Itf-N
5.1	Business level requirements
For production of the contents of this subclause, follow the instructions in M.3020 [2] subclause “A.2.2.1”.
5.1.1	High-level use case
5.1.2	EMS maintenance over Itf-N
Manager directs agent to maintain the EMS in multi-vendor environment.
5.2	Specification level requirements
For production of the contents of this subclause, follow the instructions in M.3020 [2] subclause “A.2.2.2”.
5.2.1	Use cases
5.2.1.2	Time synchronization between IRPManager and IRPAgent
Time synchronization between IRPManager and IRPAgent is necessary in many occasions, especially in performance management and notification log management. 
The time difference between IRPManager and IRPAgent would lead to pontential problems in the following use cases, which clearly show that it is necessary to study the time synchronization solutions in the scope of SA5 in order to ensure the correct implementation of the SA5 specifications.
Use case1:	When parameter stopTime in the operation createMeasurementJob is earlier than the current time in IRPAgent present time, the performance Measurement Job can not be performed successfully.

For example, the time of IRPManager is 4 hours later than IRPAgent, and IRPManager wants to create a measurement job that should finish in 3 hours. This operation would fail as depicted in the below figure:
 EMBED Visio.Drawing.11   
Note:	Because of the time difference, the IRPAgent would mistakenly consider  the stoptime parameter in operation as illegal and return a failure message.

Figure: Use case1:	
  
Use case2:	IRPManager can not obtain the performance measurement data file because the IRPAgent removed the files according to its fileExpirationTime before the IRPManager could get it.

For example: the time of IRPManager is 4 hours later than IRPAgent. 
The IRPAgent plans to remove the data file 1 hour later., 
If the IRPManager has not obtained the file in time, the file would not be available when an 
"ftp get" operation begin as in the below figure:
 EMBED Visio.Drawing.11  
Figure: Use case2:	

Use case3:	IRPManager can not obtain the notification log (it has subscribed for) when the parameter loggingEndTime in the operation subScribeLog is equal or earlier than the present time in IRPAgent.

This case is similar to Use case 1.
5.2.1.3	Resources monitoring on EMS
The resources which should be (or are) monitored include: CPU usage ratio, memory, hard disk and the status of processes on the EMS.
Use case 1: getting the resource information and related notification
Sometimes, failures are the result of lack of system resources on the EMS. For example, the clear alarm operation would fail if the IRPManager tries to clear an alarm through Itf-N while the hard disk of the EMS is full, because the cleared alarm can not be written into the database of the EMS. And, there is no detailed reason in the output parameter of the operation. In this case, the resources monitoring on EMS would help to find out if the hard disk of the EMS is full.
Furthermore, if the IRPManager can set the use ratio threshold of the resources on the EMS, and can receive corresponding notifications when the use ratio of the resources exceed the threshold, then the operator can be aware of the lack of the resources on the EMS and do appropriate operation in advance to avoid some problems. 
For example, when the use ratio of the hard disk exceeds the threshold (e.g. 95%), the IRPManager would receive the alarm notification, and then the operator may decide to remove some log data to reduce the use ratio of the Hard disk.
Use case 2: the resource information report of the EMS
To keep the performance capability of the EMS and find potential problems, it is useful for the IRPManager to know the usage of the resources on the EMS. One method is to let the EMS report the information of the resources regularly. 
For example, if the operator reads the resource information report and finds that the average usage ratios of the resources (e.g. CPU, memory, hard disk, etc.) on the EMS are usually high, then the operator might consider upgrading the hardware of the EMS.
Use case 3: monitoring the status of processes on the EMS
Sometimes, some functionality on the EMS is not available, and this problem might be caused by the fact that one or more processes on the EMS are not active. Consequently, in such a case, the operator could get the status of the processes on the EMS. Subsequently, the operator could find which processes are inactive and give the vendor more detailed information which might contribute to fast/rapid troubleshooting.
5.2.1.4	Software management of EMS
 EMSs become more and more powerful nodes. With the latest hardware it is possible to manage major parts of the network with one EMS. This increases the vulnerability of the operator.

The management of the software of EMS provides the operators a feature which they can manage EMSs more effectively.   
Use case 1: Software version management of EMS
Software version data of EMS is information pertaining to software version of EMS, and shall be manageable.  
Inaccurate software version data of EMS can impede daily network management. It would be helpful for the operator if they can get the exact software version data of EMS. For example, in software update procedure, the operator need to know the correct software version number of EMS in advance, otherwise the update may fail if the software version does not match the patch version. 
Especially in a multiple-vendor environment, how to manage software version data of different EMSs effectively is important for operators. Log into different EMSs one by one to query each one’s software version data is lengthy and costly.
The software data may include software vendor name, software version number, software filename, software file time, software upgrade history info, etc. 
Use case 2: Software upgrade of EMS 
Software upgrade procedure of EMS usually includes software download, installation and activation. Traditionally, the EMS software upgrade has to be done locally when it is confirmed by the operators. Quite often manual work is necessary in the software upgrade procedure, which make it very complex and time consuming.
It will be helpful for operators to manage the upgrade over Itf-N.
In a multiple-vendor environment, different EMS software upgrade procedures need more different EMS vendor involved in, which means more time, money and resources are needed. Automated update trigger would be very helpful for the successful implementation of these updates.
There are some common operations among these upgrade procedures. It will reduce costs and simplify upgrade procedure if the IRPManager can manage the EMS software upgrade in a centralized way. 
5.2.2	Requirements
5.2.2.1	
(void)
5.2.2.2	Time synchronization between IRPManager and IRPAgent
For the purpose of keeping the time synchronized between IRPManager(s) and IRPAgent(s) and provide accurate time in data transferred over Itf-N, the IRPManager(s) and IRPAgent(s) should synchronize their clocks against a time reference, for example with the use of NTP [IETF RFC 1305]. 
5.2.2.3	Resources monitoring on EMS
The IRPManager  shall be able to manage the resources (CPU, memory, hard disk,  etc.) monitoring on EMS, the management include:
Start and stop the resources monitor on EMS
Setting the schedule of the reporting
Setting the thresholds of the resources
The IRPManager shall be able to request the IRPAgent to report the usage information of the resources. 
The IRPAgent shall report the usage information of the resources according to the schedule or the request from the IRPManager.
The IRPAgent shall emit alarm notifications (including clearing) when the usage of resources (CPU, memory, hard disk, etc.) is beyond the threshold (additional constraints may apply for different resources).

5.2.2.4	Software version management of EMS
The IRP manager shall be able to request the current active software version information of EMS.
The IRP manager shall be able to initiate the download and activation of the EMS software. 
The IRP agent should be able to initiate the software download and activation according to the policy of software version management.
All the IRP managers shall be notified by IRP agent after the software activation or upgrade of EMS. i.e., when new software is active in EMS, all the IRP managers shall be notified.
Editor’s notes:	The IRP agent notifies the IRP managers after software activation of EMS may lead to a self-discovered solution.
6	Solution for system maintenance over Itf-N
6.1	Existing standards or de-facto standards
There are no existing standards or de facto standards for resources monitoring on EMS currently.
There are no existing standards or de facto standards for time synchronization between IRPManager and IRPAgent currently.
There are no existing standards or de facto standards for software management of EMS currently.
6.2	Detailed proposal
6.2.1	Resources monitoring on EMS
For resources monitoring on EMS, there can be two solutions. One is to define a new IRP for resources monitoring on EMS, the other is to re-use performance management (PM) IRP.
Solutions 1: Define a new IRP to get the usage information of the resources on EMS
The IRPManager  shall be able to configure the resources (CPU, memory, hard disk,  etc.) monitoring on the IRPAgent, the configurations should include:
Setting the schedule of the reporting
Setting the thresholds of the resources
Detailed configuration parameters’ data structure FFS
The IRPManager shall be able to request the IRPAgent to start the resources monitoring.
The IRPManager shall be able to request the IRPAgent to stop the resources monitoring.
The IRPManager shall be able to request the IRPAgent to report the usage information of the resources in real time manner or in schedule manner.
The IRPAgent shall gather and report the usage information of the resources according to the schedule or the request from the IRPManager. The detailed data structure of usage information FFS.
The IRPAgent shall emit alarm notifications (including clearing) when the usage of resources (CPU, memory, hard disk, etc.) beyond the threshold.
The IRP Agent shall fulfil the requirement of resource monitoring on EMSs in real time.
Advantage: The IRPManager can get the usage information of the resources in real time manner and schedule manner.
Disadvantage: Partly reduplicate with performance management (PM) IRP.
Solution 2: Re-use the Performance Management (PM) IRP
Add a new performance measurement family type for the EMS resources 
Use the performance management (PM)  IRP to get the usage information of the resources according to the schedule
Advantage: Reduce costs and minimise both the standardisation and product development efforts.
Disadvantage:   The IRPManager can not get the usage information of the resources in real time manner.
6.2.2	Software management of EMS
The software management of EMS can be implemented by using operations initiated by IRPManager over Itf-N. It is proposed to add software management related operations/notification in Itf-N to support software management of EMS. The following operations/notification shall be included:
1) GetSWversion, which allows the IRPManager to get the software version information of EMS
2) DownloadSW, which allows the IRPManager to download the software of EMS.
3) ActivateSW, which allows the IRPManager to activate the software of EMS.
The above operations can be defined by enhancing the existing interface IRPs or by introducing new interface IRP.
6.3.3	Time synchronization between IRPManager and IRPAgent
The time synchronization between IRPManager and IRPAgent can be implemented by using existing time synchronization protocol. It is vendor specific to make necessary configuration to support the time synchronization. 
7	Conclusions
The study has been conducted in order of the key management functions of EMS. For each management function, use case, requirement and solution has been provided. It has been acknowledged that there is no general consensus for the EMS maintenance over Itf-N. For each management functions, recommendations have been provided as:
Resource monitoring: reuse/adapt the existing PM IRP to include the resource monitoring of EMS
Time synchronization: no standardization over Itf-N needed.
Software management: reuse/adapt the existing SWM IRP.
Annex A:
Change history

Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNewJun 2009SA#44SP-090298Presentation to SA for information---1.0.0Sep 2009SA#45SP-090545----Presentation to SA for approval2.0.09.0.0









 STYLEREF ZA 3GPP TR 32.822 V9.0.0 (2009-09)
 PAGE 12
 STYLEREF ZGSM Release 9


3GPP