Home Node B (HNB) and Home eNode B (HeNB) management; Type 2 interface concepts and requirements

3GPP TS 32.571 V9.0.0 (2010-03)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Telecommunication Management;
Home Node B (HNB) and Home eNode B (HeNB) management; Type 2 interface concepts and requirements
(Release 9)


	



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
3GPP, 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.

© 2010, 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 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 _Toc257720700 \h 4
Introduction	 PAGEREF _Toc257720701 \h 4
1	Scope	 PAGEREF _Toc257720702 \h 5
2	References	 PAGEREF _Toc257720703 \h 5
3	Definitions and abbreviations	 PAGEREF _Toc257720704 \h 5
3.1	Definitions	 PAGEREF _Toc257720705 \h 5
3.2	Abbreviations	 PAGEREF _Toc257720706 \h 6
4	Concepts and background	 PAGEREF _Toc257720707 \h 6
4.1	Overview	 PAGEREF _Toc257720708 \h 6
4.2	Architecture	 PAGEREF _Toc257720709 \h 6
4.2.1	Mapping Function	 PAGEREF _Toc257720710 \h 7
5	Business Level Requirements	 PAGEREF _Toc257720711 \h 8
5.1	Requirements	 PAGEREF _Toc257720712 \h 8
5.2	Actor roles	 PAGEREF _Toc257720713 \h 8
5.3	Telecommunications resources	 PAGEREF _Toc257720714 \h 8
5.4	High-level use cases	 PAGEREF _Toc257720715 \h 8
6	Specification level requirements	 PAGEREF _Toc257720716 \h 9
6.1	Requirements	 PAGEREF _Toc257720717 \h 9
6.1.1	Configuration management	 PAGEREF _Toc257720718 \h 9
6.1.2	Fault management	 PAGEREF _Toc257720719 \h 9
Annex A (informative):	Change history	 PAGEREF _Toc257720720 \h 10

Foreword
This Technical Specification 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 present document is part of a TS-family covering the 3rd Generation Partnership Project Technical Specification Group Services and System Aspects, Telecommunication management; as identified below:
32.571	“Telecommunication management; Home Node B (HNB) and Home eNode B (HeNB) management; Type 2 interface concepts and requirements”
32.572:	“Telecommunication management; Home Node B (HNB) and Home eNode B (HeNB) management; Type 2 interface models and mapping functions”

1	Scope
The present document describes requirements and concepts including architecture supporting Home Node B and Home eNode B OAM&P for interface Type 2.
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.
[1]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2]	3GPP TS 32.101: "Telecommunication management; Principles and high level requirements".
[3]	3GPP TS 32.102: "Telecommunication management; Architecture".
[4]	3GPP TS 32.581: “Telecommunications management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and requirements for Type 1 interface HNB to HNB Management System (HMS)".
[5]	3GPP TS 32.591: “Telecommunications management; Home eNode B (HeNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and requirements for Type 1 interface HeNB to HeNB Management System (HMS)".
[6]	3GPP TS 22.220: Service Requirements for Home NodeBs and Home eNodeBs
[7]	3GPP TS 32.111-2: “Telecommunications management; Fault Management; Part 2: Alarm Integration Reference Point (IRP): Information Service (IS)
[8]	3GPP TS 32.583: Telecommunications management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure flows for Type 1 interface HNB to HNB Management System (HMS)

3	Definitions and abbreviations
For the purposes of this document, the terms and definitions given in TS 21.905 [1], TS 32.101 [2] and TS 32.102 [3] and in the following sub-clause 3.1 apply.  Same term may be defined in different documents.  The precedence rule, applicable to this document, is in the order of: this document, TS 32.101 [2], TS 32.102 [3], TS 21.905 [1].
3.1	Definitions
There is no additional definition defined in this subclause.
3.2	Abbreviations
For the purposes of the present document, the following abbreviations apply:
DM	Domain Manager
EM	Element Manager
HeNB	Home eNode B
HMS	HNB Management System
HeMS	HeNB Management System
HNB	Home Node B
NM	Network Manager
OAM	Operations, Administrator and Maintenance

4	Concepts and background
4.1	Overview
This clause lays out the logical system architecture for the support of HNB and HeNB management via Type 2 interface.
The architecture here takes into consideration of the Type 1 interface for HNB and Type 1 interface for HeNB.
4.2	Architecture
This clause describes the logical system architecture.
EMBED Visio.Drawing.11
Figure 1: System context of HNB and HeNB management
The ‘A’ denotes the network management protocols (and associated network management data) whose characteristics are to be defined by this TS series.  
The ‘B’ denotes the network management protocols (and associated network management data) whose characteristics are defined in TS series of [4].
The ‘C’ denotes the network management protocols (and associated network management data) whose characteristics are defined in TS series of [5].
The YyyIRPs of the IRPAgent:YyyIRP(s) box denotes the various IRPs such as AlarmIRP, BasicCMIRP, PMIRP, etc.
The triangle boxes represent managed devices such as HeNB and HNB.
IRPManager uses ‘A’ to manage all managed devices.
In this configuration, IRPAgent:YyyIRP(s) plays the role of network management service provider for IRPManager and the role of consumer for HMS and HeMS.  Similarly, HMS and HeMS play the role of service provider for IRPAgent:YyyIRP(s) and the role of device management service consumer for HNB(s) and HeNB(s).
The boxes are logical functional entities.  Their physical locations and their realization inphysical processors cannot be deduced or implied.  For example, an implementation can have IRPAgent:YyyIRP(s) and “HMS and/or HeMS” implemented in one physical processor.
The interaction between IRPAgent:YyyIRP(s) and “HMS and/or HeMS” is not visible from the perspective of this specification.  
4.2.1	Mapping Function
IRPManager manages HNB(s) and HNB(s) using ‘A’.  This management activities would trigger (result in) interactions between “HMS and/or HeMS” and HNB(s) and HeNB(s), using ‘B’ and ‘C’.  The trigger(s) that relates interactions of ‘A’ and interactions of ‘B’/’C’ is denoted by ‘F1’ and ‘F2’, the Mediation function. 
Because the interaction between IRPAgent:YyyIRP(s) and “HMS and/or HeMS” is not visible, it is of no relevance if ‘F’ should be placed inside one box or another.  This document chooses to place ‘F1’ and ‘F2’ arbitrary but embedded within IRPAgent:YyyIRP(s) and “HMS and/or HeMS” boundaries.
 EMBED Visio.Drawing.11  
Figure 2: Mapping (or Mediation) functions
The F1 is the mapping (or mediation) function for network management data exchanged via Type 2 interface and NM data exchanged via Type 1 interface with HNB. 
The F2 is the mapping (or mediation) function for network management data exchanged via Type 2 interface and NM data exchanged via Type 1 interface with HeNB. 
5	Business Level Requirements
5.1	Requirements
[REQ-HBT2-FUN-1]	The IRPAgent shall have the capability allowing IRPManager to manage HNB and HeNB using existing Interface IRPs. 
[REQ-HBT2-FUN-2]	The IRPAgent should have the capability to provide a single point of access allowing IRPManager to manage HNBs, HeNBs and other types of managed entity such as macro eNBs.  For example, the IRPAgent could have a single AlarmIRP that holds active alarms from HNBs and HeNBs as well as active alarms from other managed entities such as macro eNBs, etc.
[REQ-HBT2-FUN-3]  Operator shall be able to manage the following deployment scenarios in the most efficient manner:
Deployment of HNBs only;
Deployment of HeNBs only;
Mixed deployment of the two scenarios above.
[REQ-HBT2-FUN-4]  In order to provide efficient management of mixed HNB/HeNB device deployment scenarios, management over Type-2 interface should be as integrated as possible.
[REQ-HBT2-FUN-5]  For mixed deployment scenarios with a single IRPAgent, the IRPAgent shall provide a capability allowing IRPManager to issue a single network management request to manage HNB(s) and HeNB(s).
5.2	Actor roles
IRPManager plays the Actor role.
5.3	Telecommunications resources
OAM network.
5.4	High-level use cases
There is no high-level use case defined.

6	Specification level requirements
6.1	Requirements
6.1.1	Configuration management
[REQ- HBT2-FUN-100]		The IRPAgent shall support a capability allowing IRPManager to create and manage profiles of HNB and HeNB configuration parameters; in order to allow HNB and HeNB to complete the registration procedure when turned on (see Registration procedure in TS 32.583 [8]).  
 [REQ- HBT2-FUN-101]		The IRPAgent shall support a capability allowing IRPManager to install software on a large number of HNB and HeNB.
6.1.2	Fault management
[REQ- HBT2-FUN-200] The IRPAgent shall support a capability allowing IRPManager to use existing network management services provided by AlarmIRP to manage alarms categorized as “Expedited handling” (see REQ-OAMP_FM-FUN-005 of [4]) or categorized as “Queued handling” (see REQ-OAMP_FM-FUN-005 of [4]).‬

Annex A (informative):
Change history
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNewDec 2009SA#46SP-090731----Presentation to SA for information.---1.0.0Mar 2010SA#47SP-100055----Presentation to SA for approval1.0.02.0.0Mar 2010--------Publication of SA approved version2.0.09.0.0




















 STYLEREF ZA 3GPP TS 32.571 V9.0.0 (2010-03)
 PAGE 10
 STYLEREF ZGSM Release 9


3GPP