ETSI TS 132 500-2017 Universal Mobile Telecommunications System (UMTS) LTE Telecommunication management Self-Organizing Networks (SON) Concepts and requirements (V14 0 0 3GPP TS 32.pdf

1、 ETSI TS 132 500 V14.0.0 (2017-04) Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements (3GPP TS 32.500 version 14.0.0 Release 14) TECHNICAL SPECIFICATION ETSI ETSI TS 132 500 V14.0.0 (2017-04)13GPP TS 32.500

2、version 14.0.0 Release 14Reference RTS/TSGS-0532500ve00 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 enregistre la Sous-Prfecture de Grasse (06)

3、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 document shall not be modified without the

4、 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 within ETSI Secretariat. Users of the pres

5、ent 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 present document, please send your comment

6、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 authorized by written permission of ETSI. The c

7、ontent 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, PLUGTESTSTM, UMTSTMand the ETSI logo are Trad

8、e 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 are Trade Marks registered and owned by th

9、e GSM Association. ETSI ETSI TS 132 500 V14.0.0 (2017-04)23GPP TS 32.500 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 essential IPRs, if any, is publicly avail

10、able 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 updates are available on the ETSI Web serve

11、r (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 server) which are, or may be, or may become

12、, 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 identities or GSM identities. These should be i

13、nterpreted 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 not“, “should“, “should not“, “may“, “nee

14、d 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 citation. ETSI ETSI TS 132 500 V14.0.0 (20

15、17-04)33GPP TS 32.500 version 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 4g31 Scope 5g32 References 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 Concepts and background 6g34.1 SON concepts . 6g3

16、5 Business Level Requirements 7g35.1 Requirements 7g35.1.1 General 7g35.2 Actor roles 7g35.3 Telecommunications resources 7g35.4 High-level use cases . 7g35.4.1 e-NodeB Sharing Use Case . 8g35.4.2 Transition from Open Loop to Closed Loop Use Case . 9g36 Specification level requirements 10g36.1 Requi

17、rements 10g36.1.1 General 10g36.1.2 SON in a Multi-Vendor network 10g36.1.3 Self-Establishment of a new eNodeB . 10g36.1.4 Automatic Neighbour Relation Management . 10g36.1.5 Self-Optimisation, Self-Healing . 10g36.1.6 Continuous Optimisation due to Dynamic Changes in the Network 10g36.2 Actor roles

18、 11g36.3 Telecommunications resources 11g36.4 Use cases 12g36.4.1 SON in a Multi-Vendor network 12g36.4.1.1 Use Case Replacement of eNodeB of Vendor A with one of Vendor B. 12g36.4.2 Self-Establishment of a new eNodeB . 12g36.4.3 Automatic Neighbour Relation Management . 12g36.4.4 Self-Optimisation,

19、Self-Healing 12g36.4.5 Continuous Optimisation due to Dynamic Changes in the Network 12g3Annex A (informative): Change history . 13g3History 14g3ETSI ETSI TS 132 500 V14.0.0 (2017-04)43GPP TS 32.500 version 14.0.0 Release 14Foreword This Technical Specification has been produced by the 3rdGeneration

20、 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 a

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

22、ncements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI ETSI TS 132 500 V14.0.0 (2017-04)53GPP TS 32.500 version 14.0.0 Release 141 Scope The present document describes the requirements and architecture for the Se

23、lf Organizing Network (SON) functions within the OAM system. SON includes: Provision of infrastructure for SON, in the OAM system - Enabling SON operations; - Provide SON capabilities (each of which can either be distributed or centralised) within the OAM infrastructure, including their management;

24、- Access to SON relevant attributes; - Identification of SON relevant Measurements; - Access to and transfer of SON relevant measurements; - Transfer of SON relevant alarms. Define necessary Interface IRPs the automation of neighbour relation lists in E-UTRAN, UTRAN and between different 3GPP Radio

25、Access Technologies, self establishment of a new eNodeB in the network, self-configuration and self-healing of eNodeBs, automated coverage and capacity optimisation, optimisation of parameters due to troubleshooting, continuous optimisation due to dynamic changes in the network, automated handover o

26、ptimisation, optimisation of QoS related radio parameters. The SON concept and architecture are described in clause 4. The high-level requirements for SON are defined in clause 5. Use cases for SON are described in clause 5. 2 References The following documents contain provisions which, through refe

27、rence 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 ver

28、sion 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.501: “Telecommun

29、ication management; Self-Configuration of Network Elements; Concepts and Integration Reference Point (IRP) Requirements“. 3 3GPP TS 32.511: “Telecommunication management; Automatic Neighbour Relation (ANR) management; Concepts and requirements“. ETSI ETSI TS 132 500 V14.0.0 (2017-04)63GPP TS 32.500

30、version 14.0.0 Release 144 3GPP TS 32.521: “Telecommunication management; Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP); Requirements“. 5 3GPP TS 32.541: “Telecommunications Management; Self-Organizing Networks (SON); Self-healing concepts and r

31、equirements“. 6 3GPP TS 32.130: “Telecommunication management; Network sharing; Concepts and requirements“. 3 Definitions 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

32、document takes precedence over the definition of the same term, if any, in TR 21.905 1. Centralised SON: SON solution where SON algorithms are executed in the OAM system. Centralised SON has two variants: - NM-Centralised SON: SON solution where SON algorithms are executed at the Network Management

33、level. - EM-Centralised SON: SON solution where SON algorithms are executed at the Element Management level. Distributed SON: SON solution where SON algorithms are executed at the Network Element level. Hybrid SON: SON solution where SON algorithms are executed at two or more of the following levels

34、: NE or EM or NM. 3.2 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. 4 Concepts and backgrou

35、nd 4.1 SON concepts In order to reduce the operating expenditure (OPEX) associated with the management of this larger number of nodes from more than one vendor the concept of the Self-Organizing Network (SON) is introduced. Automation of some network planning, configuration and optimisation processe

36、s via the use of SON functions can help the network operator to reduce OPEX by reducing manual involvement in such tasks. There are four different architectures that are possible for implementing various SON use cases as defined in clause 3. The architecture is selected depending on the needs of the

37、 SON use cases. SON algorithms themselves will not be standardised in 3GPP. ETSI ETSI TS 132 500 V14.0.0 (2017-04)73GPP TS 32.500 version 14.0.0 Release 145 Business Level Requirements 5.1 Requirements 5.1.1 General REQ-SON-CON-01 SON solutions shall provide an easy transition from operator controll

38、ed (open loop) to autonomous (closed loop) operation, as the network operator gains more trust in the reliability of the SON. REQ-SON-CON-02 The SON Architecture and implementation should support network sharing between network operators. The impact of individual shared network topographies on propo

39、sed SON solutions shall be decided on a case-by-case basis. REQ-SON-CON-05 For operator controlled (open loop) SON function, the implementation of any update proposed by the SON function shall take effect only after a response by the Operator. REQ-SON-CON-06 For closed loop SON function, the impleme

40、ntation of any update proposed by the SON function shall take effect without the need for response by the Operator. REQ-SON-CON-07 An NE can operate with SON function or without SON function and can easily be transferred between these two modes. The ability to suspend/ resume/ enable/ disable the SO

41、N function shall be determined on a case by case basis. REQ-SON-CON-08 An IRPManager shall be able to monitor the specific results of each particular SON function. REQ-SON-CON-09 SON solutions should prevent or minimize negative influences between SON functions. 5.2 Actor roles IRP Agent. The entity

42、 performing the agent role. IRP Manager. The entity performing the manager role. Network Operations Staff. During open loop operation, personnel who manually review the results of the SON function at intermediate steps in the particular SON process. The network operations staff decide upon and manua

43、lly initiate the appropriate next step in the SON process. 5.3 Telecommunications resources The managed network equipment. The particular equipment and the need for any SON function(s) within it will be specific to each individual use case. The OAM system. The location of any SON function(s) within

44、the OAM system will also be specific to each individual use case. SON Function. The SON algorithm and associated processes that automatically determines the optimum configuration, connectivity, or installation parameters for a network element. 5.4 High-level use cases A high-level use case diagram m

45、ay be presented. In order to understand the use case by subject matter experts, they should be augmented with a textual description for each use case. The description should serve two purposes: to capture the domain experts knowledge and to validate the models in analysis and design phases with resp

46、ect to the requirements. An example of a high- level use case diagram is given in Appendix I of M.3020. ETSI ETSI TS 132 500 V14.0.0 (2017-04)83GPP TS 32.500 version 14.0.0 Release 145.4.1 e-NodeB Sharing Use Case e-NodeB Sharing Use Case Use case stage Evolution/Specification Related use Goal A new

47、 eNodeB shared by Participating Operators (see TS 32.130 6) is successfully taken into service. The MME or MME Pool to which it is attached is aware that this eNodeB serves more than one operator. Actors and Roles Master Operator (see TS 32.130 6) provisions the eNodeB. Participating Operator A prov

48、ides MCC/MNC information and gives provisioning information to Master Operator. Participating Operator B provides MCC/MNC information and gives provisioning information to Master Operator. See TS 32.130 6 for the definition of roles. Telecom resources Planning tool of Master Operator. Shared eNodeB.

49、 Shared MME. Assumptions A commercial relationship exists between the Master Operator and the Participating Operators. Pre-conditions Combined provisioning information from Master Operator and Participating Operators is available to be downloaded to the new eNodeB. Begins when The Participating Operators agree to share an eNodeB. Step 1 (M) The Participating Operators exchange provisioning data with the Master Operator. Step 2 (M) Master Operator loads both sets of provisioning data into his Planning tool. Step 3 (M) The self-establishment pro