Target WG Title

WiMAX Forum Service Provider Working Group Recommending the Delta-to-3GPP 32series Telecommunication Management Specifications approach for WiMAX NMR Baseline Document (v0.2.0) Contribution number (try to match the number assigned by autonumbering)
Nokia Nokia Siemens Networks

Submission Date: [2008-02-05] (show new date for later revisions)

Contribution Number Source(s)

Revision Number: (try to match the autonumbered filename revision)

ming-shou.gung@nokia.com ray.jong-a-kiem@nsn.com

Membership Document for Document Type:

Are all contributing companies members of WiMAX Forum? Yes [X] No [ ] Insert one of the following: {Approval } Insert one of the following: {Input Contribution}

Agenda Topic

WiMAX Network Management

Document Summary of Contribution Notice

SPWG Document or Specification This contribution proposes a Delta-to-3GPP 32-series telecommunication management specifications approach for the continued development of the WiMAX NMR baseline document. The proposed new text and comments are indicated by change marks as well as in comment boxes. This document is submitted to the WiMAX Forum as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Each contributor grants a free, irrevocable license to the WiMAX Forum to incorporate material contained in this contribution, and any modifications thereof, in the creation of a WiMAX Forum publication and at the WiMAX Forums sole discretion to permit others to reproduce in whole or in part the resulting WIMAX Forum publication. The contributor also acknowledges and accepts that this contribution may be made public by WiMAX Forum. Complete IPR and copyright rules governing contributions submitted to the WiMAX Forum are available from the WiMAX Forum administrator.

Release

1 of 36

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Recommendations and Requirements for WiMAX Network Management

01/31/2008

Version 0.20

2 of 36

1 2 3

Copyright Notice, Use Restrictions, Disclaimer, and Limitation of Liability.

4 5The WiMAX ForumTM owns the copyright in this document and reserves all rights therein. Use of this 6document and any related materials is limited exclusively to WiMAX Forum members for the sole purpose 7of participating in WiMAX Forum activities. Except as expressly authorized by the WiMAX Forum in 8writing, any other use of this document and all duplication and distribution of this document are prohibited. 9The WiMAX Forum regards the unauthorized use, duplication or distribution of this document by a 10member as a material breach of the members obligations under the organizations rules and regulations, 11which may result in the suspension or termination of its WiMAX Forum membership. 12 13Use of this document is subject to the disclaimers and limitations described below. By using this 14document, the member agrees to the following terms and conditions: 15 16THIS DOCUMENT IS PROVIDED AS IS AND WITHOUT WARRANTY OF ANY KIND. TO 17THE GREATEST EXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL 18EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT 19LIMITATION, THE IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, 20MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAX FORUM 21DOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR AND 22DISCLAIMS ANY WARRANTIES TO THE CONTRARY. 23 24Each WiMAX Forum member acknowledges that any products or services provided using technology 25described in or implemented in connection with this document may be subject to various regulatory 26controls under the laws and regulations of various governments worldwide. Each member acknowledges 27that it is solely responsible for the compliance of its products with any such laws and regulations and for 28obtaining any and all required authorizations, permits, or licenses for its products as a result of such 29regulations within the applicable jurisdiction. 30 31NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER 32REGARDING THE APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR 33REGULATIONS OR THE SUITABILITY OR NON-SUITABILITY OF ANY SUCH PRODUCT 34OR SERVICE FOR USE IN ANY JURISDICTION. 35 36NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER 37REGARDING THE SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE 38FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF THE WiMAX FORUM 39OR ANY THIRD PARTY. 40 41Each WiMAX Forum member acknowledges that the WiMAX Forum has not investigated or made an 42independent determination regarding title or noninfringement of any technologies that may be incorporated, 43described or referenced in this document. Use of this document or implementation of any technologies 44described or referenced herein may therefore infringe undisclosed third-party patent rights or other 45intellectual property rights. Each member acknowledges that it is solely responsible for making all 46assessments relating to title and noninfringement of any technology, standard, or specification referenced in 47this document and for obtaining appropriate authorization to use such technologies, technologies, standards, 48and specifications, including through the payment of any required license fees.

3 of 36

1 2NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE OR 3NONINFRINGEMENT WITH RESPECT TO ANY TECHNOLOGIES, STANDARDS OR 4SPECIFICATIONS REFERENCED OR INCORPORATED INTO THIS DOCUMENT. 5 6IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO ANY OTHER 7MEMBER OR TO A THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO 8THE USE OF THIS DOCUMENT, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT 9SUCH USE INFRINGES A THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS OR THAT 10IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS 11DOCUMENT, EACH MEMBER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM 12AND ITS MEMBERS RELATING TO THE USE OF THIS DOCUMENT. 13 14This document is subject to the WiMAX Forum IPR Policy and may contain Necessary Claims that 15are subject to licensing disclosures or other licensing statements as listed in Appendix [IPR]. 16 However, the listed Necessary Claims may not be all Necessary Claims contained in the document. 17Each WiMAX Forum member expressly acknowledges that the WiMAX Forum has not investigated 18or made an independent determination regarding title or noninfringement of any technologies that 19may be incorporated, described or referenced in this document. Use of this document or 20implementation of any technologies described or referenced herein may therefore infringe 21undisclosed third-party patent rights or other intellectual property rights. Each member 22acknowledges that it is solely responsible for making all assessments relating to title and 23noninfringement of any technology, standard, or specification referenced in this document and for 24obtaining appropriate authorization to use such, technologies, standards, and specifications, 25including through the payment of any required license fees. 26 27The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole 28discretion. 29 30WiMAX, WiMAX Forum, WiMAX Certified, and WiMAX Forum Certified are trademarks of the 31WiMAX Forum. Third-party trademarks contained in this document are the property of their respective 32owners. 33

4 of 36

1TABLE OF CONTENTS 21 INTRODUCTION 7 32 OBJECTIVE AND SCOPE 7 4 5 6 7 8 10 11 12 14 15 16 17 18 19 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

2.1 OAM&P OVERVIEW (INFORMATIVE) 8 1.1.1 WIMAX NETWORK ELEMENTS (INFORMATIVE) 10 2.1.1 WiMAX Element Management System (Informative) 11 2.1.2 WiMAX Network Management System (Informative) 11 2.1.3 WiMAX Service and Business Management Systems (Informative) 12 3.1 CONVENTIONS (INFORMATIVE) 13 3.2 ABBREVIATIONS AND ACRONYMS (INFORMATIVE) 13 3.3 DEFINITIONS (INFORMATIVE) 13 4.1 IEEE 14 4.2 ETSI 14 4.3 TMF 14 4.4 ITU 14 4.5 3GPP 14 4.6 IETF 16 5.1 INTRODUCTION (INFORMATIVE) 16 5.1.1 IRP DEFINITIONS PHASES (INFORMATIVE) 17 5.1.2 MANAGEMENT SOLUTIONS INTEGRATION (INFORMATIVE) 18 5.2 REQUIREMENTS DEFINITIONS (INFORMATIVE) 19 5.2.1 FAULT MANAGAMENT (INFORMATIVE) 19 5.2.1 FAULT MANAGEMENT USE CASES (INFORMATIVE) 20 5.2.1.1 FAULT DETECTION USE CASE (INFORMATIVE) 20 5.2.1.2 PERFORMANCE MONITORING USE CASE (INFORMATIVE) 21 5.2.1.3 FAULT RECOVERY USE CASE (INFORMATIVE) 22 5.2.1.4 TESTING USE CASE (INFORMATIVE) 22 5.2.1.5 ALARM SERVER USE CASE (INFORMATIVE) 23 5.2.1.6 NMS COMMANDS USE CASE (INFORMATIVE) 23 5.2.2 CONFIGURATION MANAGAMENT (INFORMATIVE) 24 5.2.3 ACCOUNT MANAGAMENT (INFORMATIVE) 24 5.2.4 SECURITY MANAGAMENT (INFORMATIVE) 24 5.2.5 PERFORMANCE MANAGAMENT (INFORMATIVE) 24 5.3 AUTOMATIC SERVICE DEVELOPMENT USE CASES (INFORMATIVE) 24

93 ABBREVIATIONS, DEFINITIONS, AND CONVENTIONS (INFORMATIVE) 13

134 REFERENCES 14

205 INTEGRATION REFERENCE POINT DEFINITIONS (INFORMATIVE) 16

386 EMS-NMS INTERFACE REQUIREMENTS (NORMATIVE) 25 39 NOTE: IN SOME INSTANCES, EMS IS NOT A SEPARATE ENTITY, AND MAY RESIDE 40INSIDE THE NE. HOWEVER, NMS ALWAYS INTERFACES TO EMS FUNCTIONALITIES. 4127 42

6.1 GENERAL REQUIREMENTS (NORMATIVE) 27

5 of 36

16.1.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 27 2 3 5 7 9

6.2 FAULT MANAGEMENT REQUIREMENTS (NORMATIVE) 29 NMS COMMANDS 31 6.3 PERFORMANCE MANAGEMENT REQUIREMENTS (NORMATIVE) 32 6.4 CONFIGURATION MANAGEMENT REQUIREMENTS (NORMATIVE) 33 6.5 ACCOUNT MANAGEMENT REQUIREMENTS (NORMATIVE) 35

46.2.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 32 66.3.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 32 86.4.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 33 10 TBD 35 116.5.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 35 12

6.6 SECURITY MANAGEMENT REQUIREMENTS (NORMATIVE) 35

136.6.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 35 14 ANNEX A DOCUMENT HISTORY (INFORMATIVE) 36

15

6 of 36

11

Introduction

2IEEE Std 802.16 is an emerging suite of standards for Broadband Wireless Access (BWA). IEEE Std 3802.16e amendment to the IEEE 802.16 base specification enables combined, fixed, and mobile 4operation in licensed and license-exempt frequency bands under 11 GHz. IEEE Std 802.16 defines a high5throughput packet data network radio interface capable of supporting several classes of Internet Protocol 6(IP) applications and services including isochronous applications such as Voice Over IP (VoIP) and 7applications with bursty data access profiles such as TCP applications. 8This is the first of a three-stage, end-to-end network system architecture specification for broadband 9wireless networks based on WiMAX Forum Certified products. This document specifies 10recommendations and requirements for such networks from the perspective of network operators intending 11to deploy WiMAX networks. It describes business and usage scenarios, deployment models, functional 12requirements, and performance guidelines for the end-to-end system. Architecture details shall be specified 13in stage-2 and stage-3 specifications based on requirements outlined in this document. 14During the course of the development of this document, a progressive phased approach to the development 15of the WiMAX network capability was identified to be able to build networks and network components on 16a timely basis, yet ultimately produce a full-featured network. 17This work will be governed by the objectives of the WiMAX Forum. While this work is aligned with the 18IEEE 802.16 suite of standards, there is a need and opportunity to address issues that go beyond the IEEE 19802.16 standards. These issues could be in areas that are covered by other standards, or not covered by any 20other standards. Throughout the rest of this document, the terms WiMAX networks and WiMAX technology 21will be used to loosely refer to the networks and technology that are the focus of this specification. The 22term WiMAX Forum Certified will be used formally to refer to certified products. 23This document captures general assumptions made for the support of MMSC in various roaming and 24interworking scenarios, service requirements on infrastructure, device, performance and others. The 25MMSC feature as specified in this document is expected to deprecate those requirements pertaining to 26sections Level 4 Service Continuity and Level 5 Seamless Services as defined in [1]. 27 28NOTE: upon ballot comment change the is expected to deprecate to deprecates and generate a CR 1) 29delete requirement R-[215], 2) add reference to this document to rel 1.5 level 4 and 5 sections. 30

312

Objective and Scope

32This document is intended to support the following objectives: 33

34 35 36 37
38

To achieve management interoperability among multi-vendor equipment, To define a uniform network management system that operates in a high degree of automation To manage WiMAX networks in an efficient manner. To manage large number of subscribers that may demand a wide variety of services with potentially various QoS characteristics. To safeguard network management information in the Service Provider networks from unauthorized persons. To provide fault mitigation and recovery in the event of impairment.

39
40

41

7 of 36

 To capture performance data that are used to fine-tune WiMAX networks for performance 2 improvement, and customer satisfaction 3 4It is the intent to reuse, where appropriate and applicable, the existing OMA&P standards and/or 5recommendations developed by various SDOs and industry fora, such as IEEE 802.16, WiMAX Forum, 6TMF, 3GPP, etc. This document will focus on the interface between the Service Providers Network 7Management System (NMS) and the Element Management System (EMS) that are typically provided by 8vendors. 9 10The scope of this work includes the following: 11

12
13

Describe an overall WiMAX network management system that covers both BSS (Business Support System) and OSS (Operation Support System). BSS Describe use cases of service deployment that includes, but not limited to, order entry processing, billing, customer care, and trouble ticket management. Define network management requirements to support the user cases so identified. Define service creation and deployment requirements. Define billing policies and accounting practices. Define Fault Management requirements. Define Configuration Management requirements. Define Accounting Management requirements. Define Performance Management requirements. Define Security Management requirements.

14 15
16

17 18 19 20 21 22 23 24 25
26

OSS (Fault/Configuration/Accounting/Provisioning/Security Management (FCAPS))

272.1

OAM&P Overview (Informative)

28OAM&P (Operations, Administration, Maintenance, and Provisioning) is designed to enable the 29automation of network operations and business processes that are critical to the rapid WiMAX deployment. 30OAM&P is also referred as OSS/BSS (Operations Support System / Business Support System). OSS is 31designed to support network operations, while BSS is designed to support business development. 32 33FCAPS (Fault Management, Configuration Management, Accounting Management, Performance 34Management, and Security Management) model that was introduced in ITU-T recommendation M-3400 is 35used to describe the OSS/BSS framework. 36

37 38
39

Fault Management Involve detection and mitigation of problems causing faults Configuration Management Involve the setting and changing of network attributes for proper network operations Account Management Tracks the usages of resources and services by customers Performance Management Include the monitoring of traffic and network performance to insure subscribers SLA (Service Level Agreement) is enforced

40 41
42

8 of 36

Security Management Involve network security and user / device authentication and 2 authorization 3 4A TMN (Telecommunications Management Network) model has been proposed by the ITU and 5TeleManagement Forum (TMF) to structure OSS/BSS management functions and define interfaces 6between these functional entities. An OAM&P reference model based on TMN is shown in Figure 1 TMN 7partitions the OSS management functions into the following layers: 8 Network Element (NE) Communication equipment that is addressable and manageable Element Management Layer (EML) Contain functions to manage network elements directly Include alarm management, handling of information, backup, logging, and maintenance of equipment hardware and software. Network Management Layer (NML) Focus on managing the functions related to the interaction between multiple network elements Perform functions for distribution of network resources: configuration, control and supervision of the network Service Management Layer (SML) Concerned with management of those aspects that may directly be observed by the users Perform functions for the management of services in the network definition, administration and billing of services Business Management Layer (BML) Focus on the management of the whole enterprise (e.g. goal setting, strategically planning) Perform functions related to business aspects, analyzes trends and quality issues, for example, or to provide a basis for billing and other financial reports

9 10 11 12 13
14

15 16 18 20 21 22
23 17 19

24 25 27
26 28 29

9 of 36

Field Managem ent

Order Entry Processing

Custom er Care

BML SML

Device& Service Provisioning

Custom er Interfaces
Trouble Managem ent Billing Processing

NML

NMS

EMS

EML

SS EMS

BS EMS

ASN EMS

CSN EMS

OMA DM or TR69 Server

NEs

SS

BS

ASN G ateway

CSN

OMA DM or TR69 Client

2 3 4

Figure 1 OAM&P Reference Model

5 7
8 9 10

1.1.1

WiMAX Network Elements (Informative)

6WiMAX NEs and their associated management agents are developed by WiMAX equipment vendors.

Subscriber Stations P80216Rev2_D2 wmanIf2SsMib is used to manage the subscriber stations. If a subscriber station does not support IEEE 802.16i MIB, then a proxy in the base station will manage the subscriber station via whatever protocol such subscriber station supports on behalf of the NMS. Base Station P80216Rev2_D2 wmanIf2BsMib, wmanIf2mBsMib, and wmanIf2fBsMib is used to manage the base station. ASN Gateway ASN gateway should support ASN MIB that include RADIUS client MIB and DIAMETER MIB as listed in the following RFC, and other MIB modules to support WiMAX specific features. IETF RFC4668 RADIUS Authentication Client MIB for IPv6 IETF RFC4670 RADIUS Accounting Client MIB for IPv6 IETF RFC4672 RADIUS Dynamic Authorization Client MIB Diameter Base Protocol MIB draft-zorn-dime-diameter-base-protocol-mib-02.txt

11
12

13
14 15

16 17 18 19 20
21 22

CSN CSN gateway should support CSN MIB that include RADIUS server MIB and DIAMETER MIB as listed in the following RFC, and other MIB modules to support WiMAX specific features. IETF RFC 4669 RADIUS Authentication Server MIB for IPv6

23

10 of 36

1 2 3 4
5 6

IETF RFC4671 RADIUS Accounting Server MIB for IPv6 IETF RFC4673 RADIUS Dynamic Authorization Server MIB Diameter Base Protocol MIB draft-zorn-dime-diameter-base-protocol-mib-02.txt

OMA DM or TR69 Clients OMA DM (Device Management) or TR69 clients should be managed by OMA DM or TR69 server for device and service provisioning.

72.1.1

WiMAX Element Management System (Informative)

8The WiMAX EMS is composed of management stations for managing the management agents that reside 9at the network elements.

10 11 12 14 15 16 17 18 19 21 22 23
24 13

Fault management Alarm reporting, cancellation, correlation, and filtering Fault identification, mitigation, and recovery, including rerouting traffic through other network elements, and Initiating diagnostics remotely to avoid truck-rolls Forwarding the events / alarms to NMS via SNMPv3 or CORBA notifications Configuration management Device provisioning Service provisioning Software upgrade management Enabling NMS to to configure network elements in bulk or individually via SOAP/XML, or CORBA Accounting management Track service usage data on per subscriber basis. Accounting records are sent over the RADIUS (NWG Rel. 1.0) or DIAMETER (NWG Rel. 1.5) protocol Performance management Monitor statistics of RSSI/CINR on the air interface, traffic load, and resource utilization Using performance data to determine if system upgrade or maintenance is required before the failures occur. NMS collects PM data via SOAP/XML or flat files that are easily parsed NMS select group of devices for preformance monitoring; and set the performance parametres and time interval, the device collect these parameters . NMS collect periodicaly the PM data. Security management Define the policies for EMS operator access. Note: This is independent of the subscriber authentication. EMS operator login security is validated by RADIUS or DIAMETER.

20

25 26 27 29 30 33 34 36
35 37 28

31 32

382.1.2

WiMAX Network Management System (Informative)

39The WiMAX NMS interface to EMS to perform management functions across multiple NE. OMA DM 40Server is responsible for managing OMA DM clients.

11 of 36

1 2 4 6 7 8 9
10 3 5

Fault management Manage and provide repair or temporarily work-around for faults automatically detected by network elements, or manually reported by subscribers. Includes redundancy management, protection schemes, routine maintenance, trouble tickets and trouble tracking. Configuration management Network resource configuration and provisioning Performance management Gather the performance data that can be used to ensure the QoS as defined in the subscribers service level agreements are being met or to plan network evolution Account management Monitor network resource usage. Security management Provide various levels of control to network resources.

11 12 13 14
15

162.1.3

WiMAX Service and Business Management Systems (Informative)

17SML and BML contain the following functions.

18
19 20

Customer Care Customer care is typically dealing with taking new orders or trouble tickets, and responding to billing questions. It is the entry point for customers via phone or web-based interface to order new services, access billing information, or report trouble tickets. Device / Service Provisioning Device provisioning includes the configuration of SS, BS and other networks elements necessary for bring-up the system. Service provisioning is responsible for bringing up a new subscriber service. Billing Processing The billing system is responsible for processing or creating invoices for subscribers. It interfaces with roaming partners to calculating the roaming charges. It also includes payment processing, pre-payment Processing, debit card processing, credit card processing, electronic banking payment processing, automatic check withdraw processing, invoice adjustment processing, service termination processing, and service resume processing. Trouble Management Trouble management is responsible for customer-reported trouble tickets and issues associated with QoS agreements. It also includes trouble report generation and the interface to customer care. It also generates work orders for field management. Order Entry Processing Order entry processing takes orders from customer care, and interfaces service provisioning to provision the service for a new customer. It also communicates with field management for dispatching a truck-roll if necessary. Field Management Field management coordinates consolidation of multiple orders to effectively and efficiently schedule truck rolls for repairs and new service installations. This function can be performed manually or automatically. If automated systems are being used for field management, the systems must take into account the type of repair or installation being scheduled so that the appropriate type and level of technician is dispatched. The field management system should also recognize when multiple orders for a single location are being processed to ensure that all of the orders will be processed via a single truck roll rather than multiple truck rolls.

21
22 23

24
25 26 27 28

29
30 31

32
33 34

35
36 37 38 39 40 41 42

12 of 36

1 2

33 43.1

Abbreviations, Definitions, and Conventions (Informative) Conventions (Informative)

5The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 6SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 7interpreted as described in Ref [2] RFC 2119.

83.2

Abbreviations and Acronyms (Informative)

Automatically Detected and Automatically Cleared Automatically Detected and Manually Cleared Business Management Systems Business Support Systems Element Management System Integration Reference Point Information Services Network Management System Operations, Administration, Maintenance, and Provisioning Operation Support Systems Service Management System Solution Set TeleManagement Forum Telecommunications Management Network

9ADAC 10 11ADMC 12 13BMS 14 15BSS 16 17EMS 18 19IRP 20 21IS 22 23NMS 24 25OAM&P 26 27OSS 28 29SMS 30 31SS 32 33TMF 34 35TMN 36

373.3
38 39 40

Definitions (Informative)

13 of 36

14
2[1]

References
Recommendations and Requirements for Networks based on WiMAX Forum, Release 1.5

34.1
4[2] 5

IEEE
IEEE P80216Rev2_D2 Part 16: Air Interface for Broadband Wireless Access Systems, December, 2007

64.2
7[3] 8 9[4]

ETSI
ETSI TS 188 003 OSS requirements; OSS definition of requirements and priorities for further network management specifications for NGN ETSI TS 188 001 NGN management; OSS Architecture Release 1

104.3
11[5] 12[6] 13[7]

TMF
TMF NGOSS Suite of specifications (including eTOM, SID and TAM) TMF Service Level Agreement (SLA) Management Handbook TMF OSS through Java (OSS/J) specifications and tools

144.4
15[8] 16 17[9] 18 19[10] 20 21[11] 22[12] 23[13] 24 25[14] 26[15] 27 28[16] 29 30[17] 31 32[18] 33[19] 34[20]

ITU
ITU-T X.733 Information Technology Open System Interconnection System Management: Alarm Reporting Function ITU-T X.735 Information Technology Open System Interconnection System Management: Log Control Function ITU-T X.745 Information Technology Open System Interconnection System Management: Test Manageemnt Function ITU-T M.3050.0 Enhanced Telecom Operations Map (eTOM) Introduction ITU-T M.3050.1 Enhanced Telecom Operations Map (eTOM) The business process framework ITU-T M.3050.2 Enhanced Telecom Operations Map (eTOM) Process decompositions and descriptions ITU-T M.3050.3 Enhanced Telecom Operations Map (eTOM) Representative process flows ITU-T M.3050.4 Enhanced Telecom Operations Map (eTOM) B2B integration: Using B2B inter-enterprise integration with the eTOM ITU-T M.3050 Supplement 1 Enhanced Telecom Operations Map (eTOM) ITIL application note ITU-T M.3050 Supplement 2 Enhanced Telecom Operations Map (eTOM) Public B2B Business Operations Map (BOM) ITU-T M.3050 Supplement 3 Enhanced Telecom Operations Map (eTOM) to M.3400 mapping ITU-T M.3050 Supplement 4 Enhanced Telecom Operations Map (eTOM) An eTOM Primer ITU-T M.3060 Principles for the Management of Next Generation Networks

354.5
36[21] 37[22]

3GPP
3GPP TS 32.101 Telecommunication management; Principles and high level requirements 3GPP TS 32.102 Telecommunication management; Architecture

14 of 36

1[23] 2 3[24] 4[25] 5[26] 6 7[27] 8 9[28] 10 11[29] 12 13[30] 14 15[31] 16 17[32] 18 19[33] 20[34] 21 22[35] 23 24 25[36] 26[37] 27 28[38] 29 30[39] 31 32[40] 33 34[41] 35 36[42] 37 38[43] 39 40[44] 41 42[45] 43[46] 44[47] 45 46[48] 47 48[49] 49

3GPP TS 32.111-1 Fault Management; Part 1: 3G Fault Management Requirements; (Release 7) 3GPP TS 32.111-2 Fault Management; Part 2: Alarm IRP: Information Service; (Release 6) GPP TS 32.111-3 Fault Management; Part 3: Alarm IRP: CORBA Solution Set; (Release 6) 3GPP TS 32.121 Telecommunication management; Advanced alarming on Itf-N Integration Reference Point (IRP); Requirements 3GPP TS 32.122 Telecommunication management; Advanced alarming on Itf-N Integration Reference Point (IRP); Information Service (IS) 3GPP TS 32.123 Telecommunication management; Advanced alarming on Itf-N Integration Reference Point (IRP); Common Object Request Broker Architecture (CORBA) Solution Set (SS) 3GPP TS 32.125 Telecommunication management; Advanced Alarming on Itf-N Integration Reference Point (IRP); eXtensible Markup Language (XML) definitions 3GPP TS 32.150 Telecommunication management; Integration Reference Point (IRP) Concept and definitions 3GPP TS 32.151 Telecommunication management; Integration Reference Point (IRP) Information Service (IS) template 3GPP TS 32.152 Telecommunication management; Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language (UML) repertoire 3GPP TS 32.155 Telecommunication management; Requirements template 3GPP TS 32.172 Telecommunication management; Subscription Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS) 3GPP TS 32.175 Telecommunication management; Subscription Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP): eXtensible Markup Language (XML) definition 3GPP TS 33.203, 3G security; Access security for IP-based services. 3GPP TS 32.240 Telecommunication management; Charging management; Charging architecture and principles 3GPP TS 32.251 Telecommunication management; Charging management; Packet Switched (PS) domain charging 3GPP TS 32.260 Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging 3GPP TS 32.274 Telecommunication management; Charging management; Short Message Service (SMS) charging 3GPP TS 32.296 Telecommunication management; Charging management; Online Charging System (OCS): Applications and interfaces 3GPP TS 32.298 Telecommunication management; Charging management; Charging Data Record (CDR) parameter description 3GPP TS 32.299 Telecommunication management; Charging management; Diameter charging applications 3GPP TS 32.332 Telecommunication management; Notification Log (NL) Integration Reference Point (IRP): Information Service (IS) 3GPP TS 32.333 Notification Log IRP: CORBA Solution Set; (Release 6) 3GPP TS 32.335 Notification Log IRP: XML Definitions ; (Release 6) 3GPP TS 32.362 Telecommunication management; Entry Point (EP) Integration Reference Point (IRP): Information Service (IS) 3GPP TS 32.363 Telecommunication management; Entry Point (EP) Integration Reference Point (IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) 3GPP TS 32.405 Telecommunication management; Performance Management (PM); Performance measurements Universal Terrestrial Radio Access Network (UTRAN)

15 of 36

1[50] 2 3[51] 4 5[52] 6 7[53] 8 9[54] 10 11[55] 12[56] 13 14[57] 15 16[58] 17 18[59] 19 20[60] 21 22[61] 23 24[62] 25 26[63] 27 28[64] 29 30[65]

3GPP TS 32.409 Telecommunication management; Performance Management (PM); Performance measurements IP Multimedia Subsystem (IMS) 3GPP TS 32.421 Telecommunication management; Subscriber and equipment trace; Trace concepts and requirements 3GPP TS 32.602 Telecommunication management; Configuration Management (CM); Basic configuration management Integration Reference Point (IRP): information service 3GPP TS 32.603 Telecommunication management; Configuration Management (CM); Basic configuration management Integration Reference Point (IRP): CORBA solution set. 3GPP TS 32.622 Telecommunication management; Configuration Management (CM); Generic network resources Integration Reference Point (IRP): Network Resource Model (NRM) 3GPP TS 32.623 Telecommunication management; Configuration Management (CM); 21 Generic Network Resources Integration Reference Point (IRP): CORBA Solution Set. 3GPP TS 32.732 Telecommunication management; IP Multimedia Subsystem (IMS) Network Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS) 3GPP TR 32.808 Telecommunication management; Study of Common Profile Storage (CPS) Framework of User Data for network services and management 3GPP TR 32.808 Telecommunication management; Study of Common Profile Storage (CPS) Framework of User Data for network services and management 3GPP TR 32.816 Telecommunication management; Study on management of Long Term Evolution (LTE) and System Architecture Evolution (SAE) 3GPP TR 32.818 Telecommunication management; Study on 3GPP SA5 / MTOSI XML harmonization 3GPP TR 32.819 Telecommunications management; Element management layer - Operation System Function (E-OSF) definition 3GPP TR 32.820 Telecommunication management; Charging management; 3GPP System Architecture Evolution (SAE): Charging aspects 3GPP TR 32.821 Telecommunication management; Study of Self-Organising Networks (SON) related OAM Interfaces for Home NodeB 3GPP TR 32.822 Telecommunication management; Study on System Maintenance by Itf-N

314.6
32[66] 33 34

IETF
IETF http://www.ietf.org/html.charters/isms-charter.html Integrated Security Model for SNMP (isms),

355 365.1

Integration Reference Point Definitions (Informative)

Introduction (Informative)

37The Integration Reference Point (IRP) concept was used to promote the wider adoption of standardized 38Management interfaces in telecommunication networks. Basically, the IRP methodology consists of 39technology neutral modelling and solution sets. The technology neutral modelling is intended to define the 40management requirements, interfaces, and network resource modelling that are common across multiple 41technologies. The solution sets define a set of management protocols that can be used to support technology 42neutral models. 43

16 of 36

1The following sections describe the basic concept of IRP that was derived from 3GPP document TS 232.150 [29]. For additional details of the IRP approach and definitions, readers should refer to the 3GPP 3document.

45.1.1

IRP Definitions Phases (Informative)

5Technologies advances very rapidly by following the trend of Morses law. But the management 6applications tend to stay for long period of time. Therefore, it is important that IRP is designed in ways that 7requirements and the modelling of network resources to be managed are independent of the technology and 8the protocol used in the management system implementation. Figure 2 shows that IRP is defined in three 9phases. 10
Requirements

IS Definitions
Interface IRPs (e.g.) Notification IRP Alarm IRP CM IRP PM IRP etc, ... NRM IRPs (e.g.) BS NRM ASN GW NRM CSN NRM etc, ... Data Definition(e.g.) Service Flow data IRP QoS data IRP etc, ...

SS definitions (e.g. XML, SNMP, CORBA) SS definitions (others / future )

11 13 15

12

Figure 2IRP Definitions Phases

14 16 17 18 19 21

20 22 23

24 25 26

1) Requirements: The IRP process begins with the requirements phase that defines use cases and requirements for a specific management interface. 2) Information Services (IS): This phase defines the following technology independent specifications: - Interface IRPs - providing the definitions for IRP operations and notifications in a network agnostic manner. - NRM IRPs - providing the definitions for the Network Resources Models (NRM). - Data Definition IRPs - providing data definitions associated with network resources defined in NRM that are to be managed via Interface IRPs. 3) Solution Set (SS) Definitions: This phase provides the mapping of IS definitions into one or more protocol-specific Solution Sets (e.g. SNMP, XML, , etc.). This concept provides support for

17 of 36

1 2 3 4

multiple interface technologies as applicable on a per vendor and/or network type basis and also enables accommodation of future interface technologies, without the need to redefine requirements and IS-level definitions.

5This document is intended to cover the Requirements phase, while stage 2 and stage 3 specifications are to 6be developed to support IS and SS Definition phases.

75.1.2

Management Solutions Integration (Informative)

8When an operator acquires equipment from multiple vendors, it is desirable for the operator to use common 9applications in the operators NMS layer to manage these multi-vendor networks. Since each NE will carry 10its own management solution, IRPs are created to assist an operator to integrate multi-vendor management 11solutions into their NMS infrastructure. To insure interoperability between NMS and EMS, an IRP is 12defined between NMS and EMS, 13 14This document standardizes the IRP at NMS EMS interface or EMS north bound interface. Figure 3 is an 15example of IRP definitions at the EMS north bound interface that contains five IRPs:

16 17 18 19 20
21

Alarm IRP support Fault Management CM IRP support Configuration Management AM IRP support Account Management PM IRP support Performance Management SM IRP support Security Management

18 of 36

NMS
Account Management Secirity Management Configuration Management Fault Management Performance Management

AM IRP

SM IRP

CM IRP

Alarm IRP

PM IRP

Vendor B Equipm ent NE

EMS NE NE NE NE

Vendor A Equipm ent EMS

NE NE

NE NE NE

1 3

Figure 3IRP for Management Solutions Integration

55.2

Requirements Definitions (Informative)

6This section describes the use cases that are used to define the requirements.

75.2.1

Fault Managament (Informative)

8Fault Management provides a set of functions that enable detection, reporting, and mitigation of faults. 9Faults that may occur in the network can be grouped into one of the following categories: 10 11 Hardware failures (e.g. the malfunction of some physical resource within a NE). 12 Software problems (e.g. software bugs, database inconsistencies). 13 Communication failures between EMS and NMS. 14 15Figure 4 shows an example of the Fault Management process flow that is used to describe the Fault 16Management use cases. 17

19 of 36

NMS

[AS1]

[FD4]

[FR1]

[C3]

[C2]

[C1]

[T1]

[C4]

EMS
Performance Monitoring [PM1] [FD2] NMS Commands Alarm Server Alarm Correlation [FD3] [FD4] [FR3] [FR2] [T3] Fault Recovery Testing Manager [T2] Admin / Op State

Perform ce an M ag en an am t

[PM2]

[C3]

[C2]

System Log [FD2]

[C3]

NE
Alarm Forwarding / Filtering Fault Detection [FD1] Fault Restoration Testing Agent

Fau lt M ag en an am t

C fig ration on u M ag en an am t

1 3

Figure 4Fault Management Process Flow Fault Management Use Cases (Informative)

55.2.1

6This section describes the fault management use cases shown in Figure 3.

75.2.1.1 Fault Detection Use Case (Informative)

8NE shall have mechanisms to detect faults. This use case deals with faults being detected by Fault 9Management in NE. 10 11[FD1] Fault Management process is started when Fault Detection detects a fault. Each fault should have 12 well-defined conditions on when a fault is declared and cleared. Commands shall be defined to 13 configure alarm severities, and the thresholds for fault declaration or clearance. 14 15 When a fault is detected or cleared, the Fault Detection shall send an alarm notification with the 16 following information to Alarm Forwarding / Filtering:

17 19
18 20

The type of the fault (e.g. communication, quality of service, processing error, equipment, environmental) according to ITU-T Recommendation X.733 [8] The severity of the fault (e.g. cleared, indeterminate, critical, major, minor, warning), as defined in ITU-T Recommendation X.733 [8]

20 of 36

1 2 4 5 6
3

The time when the fault was detected The probable cause of the fault (e.g. transmit failure, receive failure, threshold crossed), as defined in ITU-T Recommendation X.733 [8] The units at fault: - Hardware faults: the smallest replaceable unit at fault - Software faults: the faulty software component (e.g. corrupted files, or software codes) To prevent redundant alarms from flooding the system, Alarm Forwarding / Filtering shall allow or suppress the reporting of alarms based on NE identifiers, unit identifier, alarm severities, and time. The alarm notification shall be forwarded to Alarm Server in EMS as soon as possible, if such alarm is not suppressed. The alarm shall be logged into the System Log. EMS shall detect the communication failures that prevent the reception of alarm notifications, and raise an appropriate alarm to the NMS. When the communication is restored, the alarm notification shall be sent immediately. When EMS receives an alarm notification, the Alarm Server shall store/remove the alarm in/from the active alarm list, and forward it to Alarm Correlation. Commands shall be defined to enable the modification of filtering criteria for alarm notification. Alarm Server enables NMS to access the active alarm list. When a physical fault is detected, multiple notifications may be generated. It is the job of Alarm Correlation is to correlate the alarms, and identify the alarm associated with the root cause of the fault. EMS shall report the alarm to NMS. If EMS has capability to recover the fault locally, it shall initiate Fault Recovery immediately.

7 8[FD2] 9 10 11 12 13 14 15 16 17 18 19 20[FD3] 21 22 23 24[FD4] 25 26

275.2.1.2 Performance Monitoring Use Case (Informative)

28Performance monitoring is intended to capture intermittent errors and troubles, resulting from the gradual 29deterioration of some units in a NE. Performance monitoring is a pro-active maintenance technique to 30enable the operator to detect and correct intermittent troubles and performance degradation before such 31problems result in hard failures. 32 33[PM1] When Performance Monitoring detects the crossing of some observed threshold on performance 34 counters, a notification shall be generated to initiate the fault management actions. The alarm 35 notification shall provide the following information: 36 - Types of performance counters, 37 - Threshold 38 - Crossing event (e.g. above or below th ethreshold) 39 - The time when the threshold crossing occurred. 40 41 Permormance Monitoring shall log the threshold crossing events into System Log. 42 43[PM2] The Alarm Server shall store/remove the threshold crossing alarm in/from the active alarm list. 44 Alarm Correlation identifies the root cause of the fault. 45

21 of 36

1[PM3] 2

EMS shall report the alarm to NMS. If EMS has capability to recover the fault locally, it shall initiate Fault Recovery immediately.

35.2.1.3 Fault Recovery Use Case (Informative)

4Fault Recovery can be initiated automatically by EMS when a fault is detected in NE (see 5.2.1.1), or 5manually by the operator through NMS interface. When the root cause and effect of the fault were 6identified, EMS shall autonomously take fault recovery actions in order to minimize the service 7degradation or disruption. Operator can also initiate recovery actions if the operator deems that NE is not 8able to perform its functions as the result of analysis and correlation of alarm reports and performance data, 9or if the operator wants to verify the newly replaced or repaired unit can provide the service. 10 11[FR1] NMS / EMS initiate the fault recovery actions. 12[FR2] Ask Fault Restoration agent in NE to restore faults. Depending on the severity and redeundancy, the 13 recovery actions shall include the following: 14 - Hardware units: hardware reset, switch to standby copy 15 - Software units: different levels of system initializations; fallback to previous software load, 16 download a software image; 17 18 The recovery actions shall be logged into the system log. 19 20[FR3] Remove the fauly unit, and all other units depending on the faulty unit from services, by asking 21 Admin / Op State the to change the units Administrative and Operation states. 22 23 The Administrative State is used by the Operator to make a resource available for service, or to 24 remove a resource from service. For example: there are four administrative states. 25 26 FAULT: This state indicates the given component is in the faulty mode. 27 STANDBY: In a redundant system, this state indicates the given 28 component is in the standby mode. 29 ACTIVE: This state indicates the given component is in the Active mode. 30 TEST: This state indicates the given component is running a test. 31 32 The Operational state provides the information about whether a component is capable of providing 33 services. For example, there are two operational states. 34 35 IN SERVICE: This state indicates the given component is providing the 36 service. 37 OUT OF SERVICE: This state indicates the given component is not 38 providing service because of a fault or because another resource on which it depends is out 39 of service. 40

415.2.1.4 Testing Use Case (Informative)

42Testing is used in different phases of the Fault Management to assist fault mitigation. For examples: 43

22 of 36

1 3 5
2 4

6 7 8Testing can be initiated automatically by Fault Recovery in EMS (see 5.2.1.3), or manually by the operator 9through NMS. The requirements for the test management service are based on ITU-T Recommendation 10X.745 [10], where the testing description and definitions are specified. 11 12[T1] NMS / EMS initiates the test. 13 14[T2] Ask Admin / Op State to change the Administration states to Test to indicate this unit is not 15 available for service. 16 17[T3] Ask the Test Agent in NE to perform the test. 18

If the root cause of the fault can not be provided by the alarm notification, diagnostics can be executed to help pin pointing the fault location. During the normal operation, periodic diagnostics can be executed to support proactive maintenance. When a faulty unit has been repaired or replaced, before it is restored to service, diagnostics can be executed to verify if the unit is working properly.

195.2.1.5 Alarm Server Use Case (Informative)

20The Alarm Server enables NMS to retrieve the alarms from the active alarm list. It shall be possible to 21apply filters when accessing the active alarm information in the Alarm Server. 22 23[AS1] NMS retrieves the specific alarms or alarms meeting the filtering criteria. The examples of filtering 24 criteria are shown below: 25 - Alarm severity 26 - Time when the alarm notification was received (e.g. latest alarm, alarms reported after certain 27 time) 28 - Unit identifier 29

305.2.1.6 NMS Commands Use Case (Informative)

31NMS shall be able to send commands to EMS to retrieve alarm and event historical information from the 32System Log, modify the alarm forwarding criteria, and configure the alarm thresholds and severities. 33 34[C1] NMS sends commends to Fault Detection to configure the alarm severities or threshold. 35 36[C2] NMS sends commends to Alarm Forwarding / Filtering to configure the alarm filtering criteria. 37 38[C3] NMS sends commends to System Log to retrieve events in the log file independently, or to access the 39 log file in bulk through FTP protocol. 40 41[C4] NMS sends commands to Admin / Op State to retrieve the administrative and operational states. 42 43

23 of 36

15.2.2
2TBD

Configuration Managament (Informative)

35.2.3
4TBD

Account Managament (Informative)

55.2.4
6TBD

Security Managament (Informative)

75.2.5
8TBD 9

Performance Managament (Informative)

105.3

Automatic Service Development Use Cases (Informative)

11WiMAX services can be modeled in terms of bearer channel capabilities and client configuration. Bearer 12channel capabilities include things such as service flow QoS attributes, classifications, and header 13suppression. Client configuration focuses on capabilities of a client that are independent of the bearer 14channels or are above the IP layer. SMS should create service profiles of bearer channel and client 15configuration capabilities that can be used for specific services or applications (e.g. gaming, mobile video). 16Here is the use case of a typical service creation:

17
18

SMS creates a service profile that includes QoS, classification, header suppression, authentication method, billing data collection method, to meet the need of new services. When a request is received to activate a new service for a subscriber, SMS does the following: - Select a service profile that meets the need of such new service - Send the profile to CSN data store (AAA database)

19 20 21

22 23In order to support rapid WiMAX subscribers ramp, SMS should be able to activate subscribers in bulk 24simultaneously. Here is an use case of subscriber activation procedure:

25
26 27

To support self-subscription over the air, the subscriber logs into a web portal via any broadband interface to choose configuration information, such as service flow information, method of payment network ID list and authentication. SMS receives a list of subscriber and its service profile from self configuration SMS updates the CSN data store (AAA database) for each subscribers

28 29
30

24 of 36

26

EMS-NMS Interface Requirements (Normative)

3The requirements specified in this document form an extension of network requirements, per the latest 43GPP 32-series specifications capabilities where applicable, to enable operation in a WiMAX Network 5environment as part of the WIMAX Release 2.0 Network Requirements. 6 7These requirements are expressed as additions to, modifications of, and/or exclusions from the latest 3GPP 832-series specifications. This document is therefore composed in part as a delta document. The 3GPP 329series specifications are included as references, i.e., applicable materials are reused as they are from the 10source document via direct referencing unless otherwise noted in this document. It is intended that all 11revisions to the 32-series specifications will also apply to this delta document unless otherwise specified. 12 13Overview of OAM&P for WiMAX Network (3GPP Delta Specification): The structure of this document is 14aligned with the structure of the 3GPP 32-Series of specifications whose applicability and/or exceptions at 15a high level are described below: 16 17 General Exceptions: 18 19 The terms 3GPP/PLMN (and its associated technology specific terms, such as UMTS, GSM, etc.) are 20 not applicable for the WiMAX Network. Nevertheless the terms 3GPP/PLMN should be interpreted in 21 the broader sense of Wireless Communications Systems including the WiMAX system. If not stated 22 otherwise there are no additions or exclusions required. 23 24 The table below provides a mapping between 3GPP and WiMAX terminology for clarification purpose 25 in other words, where appropriate, the 3GPP term should be interpreted as an equivalent WiMAX 26 term in the referenced text. 27
3GPP Core Network (CN) Itf-N (Northbound Interface) Iub (Interface between RNC and Node B) Node B Radio Network Controller (RNC) Mobile Station (MS) WiMAX Connectivity Service Network (CSN) Itf-N (Northbound Interface) R6 Base Station (BS) Access Service Network (ASN) Subscriber Station (SS)/MS Remarks EMS~NMS BS~ASN-GW

28 29 30 31 32 33 34

The 3GPP architecture and Network Elements should also be interpreted in light of the its equivalents WiMAX counterparts which are illustrated in the below WiMAX Network Reference Model [Ref SPWG R2.0 & NWG spec]. Also 3GPP network resource models are not applicable to WiMAX environment. WiMAX Forum shall specify the WiMAX network resource model.

25 of 36

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

[Temp. Editors Note: Each of the 3GPP 32-series telecommunication management specifications needs to be reviewed (qualified) to determine its applicability to WiMAX OAM&P keep if applicable or partially applicable with exceptions noted. Each of the specifications thus identified will further be used in the delta portion for more detailed description.] 1). TS 32.101 Telecommunication management; Principles and high level requirements 2). TS 32.102 Telecommunication management; Architecture 3). TS 32.111-1 Telecommunication management; Fault Management; Part 1: 3G fault management requirements 4). TS 32.150 Telecommunication management; Integration Reference Point (IRP) Concept and definitions 5). TS 32.301 Telecommunication management; Configuration Management (CM); Notification Integration Reference Point (IRP): Requirements 6). TS 32.311 Telecommunication management; Generic Integration Reference Point (IRP) management; Requirements 7). TS 32.331 Telecommunication management; Notification Log (NL) Integration Reference Point (IRP): Requirements 8). TS 32.341 Telecommunication management; File Transfer (FT) Integration Reference Point (IRP): Requirements 9). TS 32.371 Telecommunication management; Security Management concept and requirements 10). TS 32.401 Telecommunication management; Performance Management (PM); Concept and requirements 11). TS 32.411 Telecommunication management; Performance Management (PM) Integration Reference Point (IRP): Requirements

26 of 36

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

12). TS 32.600 Telecommunication management; Configuration Management (CM); Concept and high-level requirements 13). TS 32.601 Telecommunication management; Configuration Management (CM); Basic CM Integration Reference Point (IRP); Requirements 14). TS 32.611 Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): Requirements 15). TS 32.621 Telecommunication management; Configuration Management (CM); Generic network resources Integration Reference Point (IRP); Requirements 16). TS 32.661 17). TS 32.671 Telecommunication management; Configuration Management (CM); State Management Integration Reference Point (IRP): Requirements

Note: In some instances, EMS is not a separate entity, and may reside inside the NE. However, NMS always interfaces to EMS functionalities.

176.1

General Requirements (Normative)

18R-[262] The WiMAX network supporting Mobility Access SHALL provide for standardized network 19 management functions as Information Services developed using the protocol neutral Integration 20 Reference Point methodology and technology specific solution sets Ref [30 32.150]. 21R-[263] The WiMAX network SHALL support remote monitoring of radio link/MAC, IP traffic statistics, 22 QoS settings, and Network availability (over specific time period). 23R-[271] Information Services, using the protocol neutral Information Reference Point methodology, 24 developed for the WiMAX network SHALL use technology specific solution sets (realizations) 25 for at least the following technologies: SOAP; CORBA/IDL; SNMP. 26R-[273] For WiMAX network supporting Mobility Access, the defined Information Services SHALL 27 support retrieval of any logs maintained using mechanisms appropriate for the technology specific 28 solution set which for particular technology specific solutions sets can be found in Ref [44 29 32.332], Ref [45 32.333], and Ref [46 32.335]. 30R-[270] For WiMAX network supporting Mobility Access, the defined Information Service(s) Ref [52 31 32.602], Ref [53 32.603], Ref [54 32.622], Ref [55 32.623], Ref [24 111.2], and Ref [25 32 111.3] SHALL support the following NMS capabilities: Alarms displaying with filtering 33 capabilities to limit the amount of information, alarms acknowledgement, services provisioning 34 (for end-to-end provisioning), information on WiMAX network elements for network map 35 displaying at NMS level. 36R-[272] The defined Information Services SHALL support interaction between the NMS and the EMS.

37

6.1.1

Relevant 3GPP 32-Series Technical Specifications

383GPP TS 32.101 Telecommunication management; Principles and high level requirements (Release 398) 40 41 General Exceptions: 42

27 of 36

1
2 3 4 6 7 9

The high level OAM architecture is based on WiMAX network architecture not the 3GPP network architecture as shown in Figure 1.

5 8 10 12

11

13 14 153GPP TS 32.102 Telecommunication management; Architecture (Release 8) 16 17 General Exceptions:

Specific Exceptions: Section 4 General (Informative) 4.1.2 3GPP reference model Not applicable. There are no other additions, modifications, or exclusions. Section 5 Architectural framework (Normative) There are no additions, modifications, or exclusions. Section 6 PLMN management processes (Informative) There are no additions, modifications, or exclusions. Section 7 PLMN management functional architecture (Informative) There are no additions, modifications, or exclusions.

18 20 22 24 26
19 21 23 25 27 28 29 31 33 35 37

30 32 34 36 38

39 40 413GPP TS 32.150 Telecommunication management; Integration Reference Point (IRP) Concept and 42definitions (Release 8) 43 44 General Exceptions:

Specific Exceptions: Section 4 General (Informative) There are no additions, modifications, or exclusions. Section 5 General view of PLMN Management Physical architectures (Informative) There are no additions, modifications, or exclusions. Section 6 Basic objectives for PLMN Management Physical Architecture (Informative) There are no additions, modifications, or exclusions. Section 7 TM Architectural aspects (Informative) 7.3.3 Entities of a 3GPP system text in this section should be interpreted in light of the WiMAX Network Reference Model [Ref NWG Spec]. There are no other additions, modifications, or exclusions. Section 8 3GPP Management Physical architectures (Informative) There are no additions, modifications, or exclusions. Section 9 TMN applications (Informative) There are no additions, modifications, or exclusions. Section 12 3GPP TMN Conformance (Normative) There are no additions, modifications, or exclusions. Section 13 TMN planning and design considerations (Informative) There are no additions, modifications, or exclusions. Section 14 Mediation/Integration (Informative) There are no additions, modifications, or exclusions.

45 47
46 48

Special Exceptions: Section 4 Integration Reference Points (IRPs) (Normative) There are no additions, modifications, or exclusions.

28 of 36

1 23GPP TS 32.311 Generic Integration Reference Point (IRP) management: Requirements (Release 7) 3 4 General Exceptions:

5 7
6 8 9 103GPP TS 32.341 File Transfer (FT) Integration Reference Point (IRP): Requirements (Release 7) 11 12 General Exceptions:

Special Exceptions: Section 4 Generic IRP functions over Itf-N (Normative) There are no additions, modifications, or exclusions.

13

14 Special Exceptions: 15 16Section 4 File Transfer IRP concept (Informative) 17 There are no additions, modifications, or exclusions. 18Section 5 File Transfer IRP requirements (Normative) 19 There are no additions, modifications, or exclusions. 20 Section 6 Overview of IRP's related to File Transfer (FT) (Informative) 21 There are no additions, modifications, or exclusions.

226.2

Fault Management Requirements (Normative)

23General 24 25R-[268] For WiMAX network supporting Mobility Access, the Alarm Management Information Service 26 Ref [25 111.3] an Ref [30 32.150] SHALL be the basis for forwarding of alarm notifications 27 from the EMS to the NMS. 28R-[269] The EMS SHALL support the following capabilities: Alarms displaying, alarms 29 acknowledgement, configuration/provisioning of BS and SS/MS, auto-discovery, performances 30 and traffic monitoring, network topology displaying, inventory and status and software 31 downloading. 32R-[264] Local craft interfaces SHOULD be included in every WiMAX network element for installation, 33 commissioning and troubleshooting. 34Fault Detection 35R-[267] Alarm notifications generated as the corresponding network event occurs SHALL be delivered to 36 the NMS and EMS alarm capabilities in a timely and reliable manner. 37R-[xxx] WiMAX EMS SHALL forward alarm notifications to the NMS when a fault is detected or cleared 38 in a NE. 39R-[xxx] There SHALL be mechanisms to detect faults in the NE. 40R-[xxx] The fault detection alarm notification SHALL provide the following information:

41
42

The type of the fault (e.g. communication, quality of service, processing error, equipment, environmental) according to ITU-T Recommendation X.733 [8]

29 of 36

1 3 4 6 7 8
2

The severity of the fault (e.g. cleared, indeterminate, critical, major, minor, warning), as defined in ITU-T Recommendation X.733 [8] The time when the fault was detected The probable cause of the fault (e.g. transmit failure, receive failure, threshold crossing), as defined in ITU-T Recommendation X.733 [8] The units at fault: Hardware faults: the smallest replaceable unit at fault Software faults: the faulty software component (e.g. corrupted files, or software codes)

10R-[xxx] WiMAX EMS SHALL be able to respond to a NMS or local operator request to allow or suppress 11 alarm reporting (i.e. alarm filtering) for each NE, based on the following alarm filtering criteria:

12 13 14 15

Identifier of the NE Identifier of HW or SW component in a NE Alarm severity Time

16R-[xxx] WiMAX EMS SHALL be able to detect the communication failures that prevent the reception of 17 alarms from from NE, and SHALL raise an appropriate alarm to NMS when it happens. 18 19Performance Monitoring 20R-[xxx] WiMAX EMS SHALL forward an alarm notification to the NMS wh.en the crossing of thresholds 21 on performance measurements is detected. 22R-[xxx] There SHALL be performance measurements to capture intermittent errors, resulting from the 23 gradual deterioration of some units in a NE. 24R-[xxx] The performance measuremnts alarm notification shall provide the following information:

25 26 27 28
29

Types of performance counters, Threshold Crossing event (e.g. above or below the threshold) The time when the threshold crossing occurred

30Fault Recovery 31R-[xxx] WiMAX EMS SHALL be able to support a NMS or local operator initiated request to initiate 32 recovery actions on NE, The recovery actions SHALL include the following:

33 34
35 36

Hardware units: hardware reset, switch to standby copy Software units: different levels of system initializations; fallback to previous software load, download a software image; Note: the reasons for the initiation of recovery actions include: The operator declares faulty conditions on units in a NE after analyzing and correlating alarm reports and performance data, or The operator wants to verify if the replaced or repaired unit can provide the service by putting this unit in service

37 39
38 40

30 of 36

1 2Testing 3R-[xxx] WiMAX EMS SHALL be able to support a NMS or local operator initiated request to initiate test 4 on NE for the following reasons:

5 7 9
6 8

10 11

If the root cause of the fault can not be provided by the alarm notification, diagnostics can be executed to help pin pointing the fault location. During the normal operation, periodic diagnostics can be executed to support proactive maintenance. When a faulty unit has been repaired or replaced, before it is restored to service, diagnostics can be executed to verify if the unit is working properly. Note: WiMAX NE SHALL provide diagnostics to support functions described above.

12R-[xxx] WiMAX EMS MAY support the requirements for the test management service, based on ITU-T 13 Recommendation X.745 [10], where the testing description and definitions are specified. 14 Requests can be initiated by local opeartor or NMS. 15R-[xxx] Testing MAY be initiated automatically by Fault Recovery to assist the fault isolation. 16 17Alarm Server 18R-[xxx] WiMAX EMS SHALL provide the local operator or NMS access to active alarms in a EMS 19 either directly or through filters based on criteria shown below:

20 21 23
22 24 25

Alarm severity Time when the alarm notification was received (e.g. latest alarm, alarms reported after certain time) Identifier of HW or SW component in a NE NMS Commands

26R-[xxx] WiMAX EMS SHALL support a NMS or local operator initited request for configuration of 27 thresholds that determine the declaration or clearing of a fault, and modify the alarm severity in 28 EMS. EMS SHALL confirm such alarm configuration commands. 29R-[xxx] WiMAX EMS SHALL support a NMS or local operator initiated request to be able to configure 30 the filtering criteria to be used for alarm notification. 31 32R-[xxx] WiMAX EMS SHALL forward notifications for any modifications to configuration parameters. 33 34R-[xxx] WiMAX NMS SHALL be able to access the Administration and Operational states in EMS. 35 36System Logs 37R-[xxx] WiMAX EMS SHALL support a NMS or local operator initited request to access the historical 38 events or alarms in the system logs in EMS independently, or test access the log file in bulk 39 through FTP protocol. If the SNMP solution set is supported, then the log file mechanism as 40 defined in wmanDevMib in IEEE. P802.16Rev2/D2 SHALL be supported.

31 of 36

6.2.1

Relevant 3GPP 32-Series Technical Specifications

23GPP TS 32.111-1 Fault Management; Part 1: 3G fault management requirements (Release 7) 3 4 General Exceptions:

5 7 9
6 8

10 11 123GPP TS 32.331 Notification Log (NL) Integration Reference Point (IRP): Requirements (Release 7) 13 14 General Exceptions:

Special Exceptions: Section 4 Fault Management concept and requirements (Informative) There are no additions, modifications, or exclusions. Section 5 N interface (Itf-N) (Normative) There are no additions, modifications, or exclusions.

15 17 19
16 18 20 21

Special Exceptions: Section 4 Notification log Management concept (Informative) There are no additions, modifications, or exclusions. Section 5 Notification log IRP requirements (Normative) There are no additions, modifications, or exclusions.

226.3

Performance Management Requirements (Normative)

23R-[265] Management and monitoring of WiMAX network elements SHALL be done through Element 24 Management System (EMS) via NMS-EMS standardized interfaces. 25R-[266] Management and monitoring of SS/MS SHALL be done through Element Management System 26 (EMS) using protocol neutral Integration Reference Point methodology and technology specific 27 solution sets. 28

6.3.1

Relevant 3GPP 32-Series Technical Specifications

293GPP TS 32.401 Performance Management (PM); Concept and requirements (Release 7) 30 31 33 34

General Exceptions: References to 3GPP Performance measurement definitions are not applicable for WiMAX. WiMAX needs to define the performace measurements applicable for WiMAX environment.

32 35 37 39

36 38

Specific Exceptions: Section 4 Concept (Informative) There are no additions, modifications, or exclusions. Section 5 Functional requirements (Normative) There are no additions, modifications, or exclusions.

40

32 of 36

13GPP TS 32.411 Telecommunication management; Performance Management (PM) Integration 2Reference Point (IRP): Requirements (Release 7) 3

General Exceptions: Specific Exceptions: Section 5 Detailed requirements (Normative) There are no additions, modifications, or exclusions. Section 6 Overview of IRPs related to PM (Normative) There are no additions, modifications, or exclusions.

4 6 8
9 10 5 7

116.4

Configuration Management Requirements (Normative)

123rd Party Interoperability 13R-[xxx] WiMAX EMS/NMS SHALL support the configuration of ASN-GW to operate with 3rd party BS 14R-[xxx] WiMAX EMS/NMS SHALL support the configuration of BS to operate with 3rd party ASN-GW 15Editor note: are these requirements applicable to profile B? 16 17

6.4.1

Relevant 3GPP 32-Series Technical Specifications

183GPP TS 32.301 Configuration Management (CM); Notification Integration Reference Point (IRP): 19Requirements (Release 7) 20

General Exceptions: Specific Exceptions: Section 4 Notification management functions over Itf-NXx (Normative) There are no additions, modifications, or exclusions.

21 23
22 24 25

26 273GPP TS 32.600 Telecommunication management; Configuration Management (CM); Concept and 28high-level requirements; (Release 7) 29

General Exceptions: Specific Exceptions: Section 4 Network Configuration Management (CM) (Informative) There are no additions, modifications, or exclusions. Section 5 CM service components (Informative) There are no additions, modifications, or exclusions. Section 6 CM functions (Informative)

30 32 34
35 31 33

36

33 of 36

There are no additions, modifications, or exclusions. Section 7 Itf N Interface (Normative) There are no additions, modifications, or exclusions.

2
3 4

53GPP TS 32.601 Telecommunication management; Configuration Management (CM); Basic CM 6Integration Reference Point (IRP): Requirements; (Release 7) 7

General Exceptions: Specific Exceptions: Section 4 Requirements (Normative) There are no additions, modifications, or exclusions.

8 10
9

11 12

133GPP TS 32.611 Telecommunication management; Configuration Management (CM); Bulk CM 14Integration Reference Point (IRP): Requirements (Release 7) 15

General Exceptions: Specific Exceptions: Section 4 Bulk CM and Itf N Interface (Normative) There are no additions, modifications, or exclusions.

16 18
17 19 20 213GPP TS 32.621 Telecommunication management; Configuration Management (CM); Generic network 22resources Integration Reference Point (IRP); Requirements (Release 7) 23

General Exceptions: Specific Exceptions: Section 4 Requirements (Normative) There are no additions, modifications, or exclusions.

24 26
25 27 28 293GPP TS 32.671 Configuration Management (CM); State Management Integration Reference Point 30(IRP): Requirements (Release 7) 31

General Exceptions: Specific Exceptions: Section 4 Requirements for the State Management IRP (Normative) There are no additions, modifications, or exclusions.

32 34
33 35 36 37

34 of 36

16.5
2 3 4 5TBD 6

Account Management Requirements (Normative)

TBD

6.5.1

Relevant 3GPP 32-Series Technical Specifications

76.6
8TBD 9 10

Security Management Requirements (Normative)

6.6.1

Relevant 3GPP 32-Series Technical Specifications

113GPP TS 32.371 Security Management concept and requirements (Release 7) 12

General Exceptions: Specific Exceptions: Section 4 Security Management background (Informative) There are no additions, modifications, or exclusions. Section 5 Security Management context and architecture (Informative) There are no additions, modifications, or exclusions. Section 6 Security threats in IRP context (Informative) There are no additions, modifications, or exclusions. Section 7 Security requirement of Itf-N (Normative) There are no additions, modifications, or exclusions.

13 15 17
18 14 16

19
20

21
22 23 24

35 of 36

1 Date

Annex A

Document History (Informative) Version

0.1 0.11 0.20

Subject History
Baseline document based on SPWG Rel. 1.5 Changes as per agreements from DEC. 2007 FtF meeting Includes changes from Jan. 2008 Kona meeting

2007-11-27 2007-12-06 2008-01-31

2

36 of 36