ETSI TS 132 572-2017 Universal Mobile Telecommunications System (UMTS) LTE Telecommunication management Home Node B (HNB) and Home eNode B (HeNB) management Type 2 interface models.pdf

1、 ETSI TS 132 572 V14.0.0 (2017-04) Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Home Node B (HNB) and Home eNode B (HeNB) management; Type 2 interface models and mapping functions (3GPP TS 32.572 version 14.0.0 Release 14) TECHNICAL SPECIFICATION ETSI ETSI TS

2、 132 572 V14.0.0 (2017-04)13GPP TS 32.572 version 14.0.0 Release 14Reference RTS/TSGS-0532572ve00 Keywords LTE,UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif en

3、registre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present

4、document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive

5、within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the p

6、resent document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as autho

7、rized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2017. All rights reserved. DECTTM, PLU

8、GTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members GSM and the GSM logo

9、are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 132 572 V14.0.0 (2017-04)23GPP TS 32.572 version 14.0.0 Release 14Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these

10、 essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest u

11、pdates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web s

12、erver) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS ident

13、ities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In the present document “shall“, “shall

14、 not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct

15、citation. ETSI ETSI TS 132 572 V14.0.0 (2017-04)33GPP TS 32.572 version 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 4g3Introduction 4g31 Scope 5g32 References 5g33 Definitions and abbreviations . 5g33.1 Definitions 6g33.2 Abbreviation

16、s . 6g34 Basic Aspects . 6g34.1 General . 6g34.2 System context . 6g35 Information Object Classes 6g36 Interface Definition 7g37 Mapping Function 7g37.1 General . 7g37.2 Configuration management 7g37.2.1 HNB provisioning support (O) . 7g37.2.2 HeNB provisioning support (O) 8g37.3 Fault management 8g

17、37.3.1 Handling of “Expedited handling” and “Queued handling” alarms 8g3Annex A (informative): Change history . 10g3History 11g3ETSI ETSI TS 132 572 V14.0.0 (2017-04)43GPP TS 32.572 version 14.0.0 Release 14Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Proj

18、ect (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 ver

19、sion 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, correct

20、ions, 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 3rdGeneration Partnership Project Technical Specification Group Services and System Aspects, Telecommunicatio

21、n 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

22、functions” ETSI ETSI TS 132 572 V14.0.0 (2017-04)53GPP TS 32.572 version 14.0.0 Release 141 Scope The present document describes requirements and concepts including architecture supporting Home NB and Home eNB OAM Principles and high level requirements“. 3 3GPP TS 32.102: “Telecommunication manageme

23、nt; Architecture“. 4 3GPP TS 32.622: “Generic network resources Integration Reference Point (IRP); Network Resource Model (NRM)“. 5 3GPP TS 32.583 Procedure flows for Type 1 interface HNB to HMS 6 3GPP TS 32.602 Basic CM Integration Reference Point (IRP); Information Service (IS) 7 3GPP TS 32.602 Bu

24、lk CM Integration Reference Point (IRP); Information Service (IS) 8 3GPP TS 32.593 Procedure flows for Type 1 interface HeNB to HeNB Management System 9 3GPP TS 32.584 XML definitions for Type 1 interface HNB to HNB Management System 10 3GPP TS 32.594 XML definitions for Type 1 interface HeNB to HeN

25、B Management System 11 3GPP TS 32.111-2: “Telecommunication management; Fault Management; Part 2: Alarm Integration Reference Point (IRP): Information Service (IS)” 12 3GPP TS 32.582: “Telecommunications management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM Info

26、rmation model for Type 1 interface HNB to HNB Management System (HMS)“. 13 3GPP TS 32.342 File Transfer (FT) Integration Reference Point (IRP): Information Service (IS) 14 3GPP TS 32.772 Home Node B Subsystem (HNS); Network Resource Model (NRM); Integration Reference Point (IRP); Information Service

27、 (IS). 15 3GPP TS 32.150 Integration Reference Point(IRP) Concept and definitions 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 diff

28、erent 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. ETSI ETSI TS 132 572 V14.0.0 (2017-04)63GPP TS 32.572 version 14.0.0 Release 143.1 Definitions There is no additional definition defined in this subclause. 3.2

29、 Abbreviations For the purposes of the present document, the following abbreviations apply: FT File Transfer HNB Home Node B HeNB Home eNode B HMS HNB Management System HeMS HeNB Management System HNS Home Node B Subsystem IOCs Information Object Classes IRP Integration Reference Point NRM Network R

30、esource Model 4 Basic Aspects 4.1 General 4.2 System context The general definition of the System Context for the present IRP is found in 3GPP TS 32.150 15 subclause 4.7. Only System Context A applies to this document. In addition, the IRP(s) relevant to the present document are shown. HNBs HeNBs EM

31、 IRPAgent IRPManager NM Itf-N Notification IRP Alarm IRP Bulk CM IRP Basic CM IRP FT IRP Figure 1: System Context 5 Information Object Classes This specification does not define its own classes. It uses those defined in Home Node B Subsystem (HNS) 14. ETSI ETSI TS 132 572 V14.0.0 (2017-04)73GPP TS 3

32、2.572 version 14.0.0 Release 146 Interface Definition This document does not define its own Interface definition. It re-uses Alarm IRP 11, FT IRP 13, Basic CM IRP 6 and Bulk CM IRP 7. 7 Mapping Function 7.1 General 7.2 Configuration management 7.2.1 HNB provisioning support (O) This subclause applie

33、s to HNB case. c: HNBb: IRPAgent/HMS Servinga: IRPManager1. Manage pr ofile instanc es2. Registration procedure3. Initial configuration4. Measur ement, Etc.Parameter autogeneratedBy the HMSParameter autogeneratedby the HMS5. Subsequent configur ationIRPManager needs to create an HNBProfile instance.

34、 Before doing so, IRPManager a) Creates a dataset holding information that will be referred to by the to-be-created HNBProfile.configuration. IRPManager names this dataset using the File Naming Convention of Annex A of 13. The file name shall contain the specificIRP_extension field which is set to “

35、HNB”. The file schema is defined in subclause 4.2.2 of 9. b) Prepares the value of the attribute criterion and attribute userLabel of the to-be-created HNBProfile. c) Creates the HNBProfile instance using Basic CM IRP IS createMO of 6 or using Bulk CM IRP IS BulkCmCreateMo (Create MO Sub-operation)

36、of 7 In case Basic CM IRP is used for the instance creation, IRPManager reception of: head2right A createMO positive response or a notifyObjectCreation means: square4 The instance has been created successfully; head2right A createMO negative response means: square4 The instance has not been created

37、and the response can include the failure reason. In case Bulk CM IRP is used for the instance creation, IRPManager reception of: ETSI ETSI TS 132 572 V14.0.0 (2017-04)83GPP TS 32.572 version 14.0.0 Release 14head2right A notifyObjectCreation means: square4 The instance has been created successfully;

38、 It is noted that in case Bulk CM IRP is used for the instance creation, the BulkCMIRP can record the outcome of the instance creation attempt in the session log. The IRPManager can obtain the session log (see clause 7.3.6 of 7) if it wants to determine if the instance is created successfully or not

39、. The above description is part of interaction 1. IRPManager should not remove the dataset referred to by HNBProfile.configuration as long as the HNBProfile instance exists. This is because an IRPAgent may not make a local copy of the dataset during HNBProfile instance creation and therefore needs t

40、o read the dataset during the HNB registration. IRPManager should not modify the dataset referred to by HNBProfile.configuration as long as the HNBProfile instance exists. This is to guarantee an IRPAgent behaviour that is independent of the IRPAgent implemention choices, such as: 1) IRPAgent create

41、s its local copy of the dataset when the HNBProfile is in existence and uses the local copy during HNB registration; 2) IRPAgent does not make a local copy of the dataset but reads the dataset during HNB registration. Interaction 2 is the interactions 5.1, 5.2, 5.3, 5.4, 5.3-bis and 5.4-bis of Claus

42、e 5.2.1 of 5. Via interaction 5.1 (see Clause 5.2.1 of 5), HNB informs IRPAgent- Serving HMS of the HNB location, the HNB ID, etc, called (in the context of this document) the registration information. IRPAgent- Serving HMS identifies a stored HNBProfile.criterion that corresponds to the registratio

43、n information. It then identifies the corresponding HNBProfile.configuration. In case IRPAgent- Serving HMS identifies more than one stored HNBProfile.criterion that corresponds to the registration information. It then identifies the corresponding HNBProfile.configuration, IRPAgent- Serving HMS woul

44、d decide which HNBProfile.configuration would be used. Via interaction 5.3 or 5.4-bis (see Clause 5.2.1 of 5), IRPAgent Serving HMS configures the HNB using the identified HNBProfile.configuration. 7.2.2 HeNB provisioning support (O) This subclause applies to HeNB case. This subclause is identical t

45、o 7.2.1 except: - HNB is replaced by HeNB - HMS is replaced by HeMS - References 5 and 9 are replaced by 8 and 10. 7.3 Fault management 7.3.1 Handling of “Expedited handling” and “Queued handling” alarms HNB raises alarms of various categories, two of which are called “Expedited handling” and “Queue

46、d handling”. HNB uses TR-069 RPC Methods to send the “Expedited handling” and “Queue handling” categories of alarms (see Clause 6.2.4 of 12). HNB does not use TR-069 RPC Methods to send other categories of alarms. On reception of the HNB alarms sent by TR-069 RPC Methods, the mapping function (F) sh

47、all process the alarm and decide if ETSI ETSI TS 132 572 V14.0.0 (2017-04)93GPP TS 32.572 version 14.0.0 Release 14a) There exists no AlarmInformation 11 in AlarmList 11 corresponding to the newly received alarm or b) There exists an AlarmInformation in AlarmList corresponding to the newly received

48、alarm. There is a difference in value of perceivedSeverity of the newly received alarm and that of the corresponding AlarmInformation and the former value is not Cleared. c) There exists an AlarmInformation in AlarmList corresponding to the newly received alarm. There is a difference in value of per

49、ceivedSeverity of the newly received alarm and that of the corresponding AlarmInformation and the former value is Cleared. In case of a), a new AlarmInformation is added in the AlarmList. The IRPManager, who has a subscription with NotificationIRP, is notified via notifyNewAlarm if the added AlarmInformation satisfies the subscription filter constraint. In case of b), the corresponding AlarmInformation perceivedSeverity is changed. The IRPManager, who has a subscription with Notificat