s50-20080218-018__080218-spwg_nmr_v0.20_clean (+deltaapproachtext)-nnsn

8/4/2019 S50-20080218-018__080218-SPWG_NMR_v0.20_Clean (+DeltaApproachText)-NNSN

http://slidepdf.com/reader/full/s50-20080218-018080218-spwgnmrv020clean-deltaapproachtext-nnsn 1/36

Target WG WiMAX Forum Service Provider Working Group

Title Recommending the Delta-to-3GPP 32-

series Telecommunication Management

Specifications approach for WiMAX NMR

Baseline Document (v0.2.0)

Submission Date: [2008-02-05]

(show new date for later revisions)

Contribution

Number

Contribution number (try to match thenumber assigned by autonumbering)

Revision Number: (try to match the

autonumbered filename revision)

Source(s) Nokia

Nokia Siemens Networks

[email protected]

[email protected]

Membership Are all contributing companies members of WiMAX Forum? Yes [X] No [ ]

Document for Insert one of the following: {Approval }

Document Type: Insert one of the following: {Input Contribution}

Agenda Topic WiMAX Network Management

Document SPWG Document or Specification

Summary of

Contribution

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.

NoticeThis 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 thisdocument 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.

ReleaseEach 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 Forum’s 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 theWiMAX Forum administrator.

1 of 361

mailto:[email protected]







Recommendations and Requirements for

WiMAX Network Management

01/31/2008

Version 0.20

2 of 36

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

1



Copyright Notice, Use Restrictions, Disclaimer,

and Limitation of Liability.The WiMAX ForumTM owns the copyright in this document and reserves all rights therein. Use of thisdocument and any related materials is limited exclusively to WiMAX Forum members for the sole purpose

of participating in WiMAX Forum activities. Except as expressly authorized by the WiMAX Forum in

writing, any other use of this document and all duplication and distribution of this document are prohibited.

The WiMAX Forum regards the unauthorized use, duplication or distribution of this document by a

member as a material breach of the member’s obligations under the organization’s rules and regulations,

which may result in the suspension or termination of its WiMAX Forum membership.

Use of this document is subject to the disclaimers and limitations described below. By using thisdocument, the member agrees to the following terms and conditions:

THIS DOCUMENT IS PROVIDED “AS IS” AND WITHOUT WARRANTY OF ANY KIND. TO

THE GREATEST EXTENT PERMITTED BY LAW, THE WiMAX FORUM DISCLAIMS ALL

EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT

LIMITATION, THE IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT,

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE WiMAX FORUM

DOES NOT WARRANT THAT THIS DOCUMENT IS COMPLETE OR WITHOUT ERROR AND

DISCLAIMS ANY WARRANTIES TO THE CONTRARY.

Each WiMAX Forum member acknowledges that any products or services provided using technology

described in or implemented in connection with this document may be subject to various regulatory

controls under the laws and regulations of various governments worldwide. Each member acknowledges

that it is solely responsible for the compliance of its products with any such laws and regulations and for

obtaining any and all required authorizations, permits, or licenses for its products as a result of such

regulations within the applicable jurisdiction.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER

REGARDING THE APPLICABILITY OR NON-APPLICABILITY OF ANY SUCH LAWS OR

REGULATIONS OR THE SUITABILITY OR NON-SUITABILITY OF ANY SUCH PRODUCT

OR SERVICE FOR USE IN ANY JURISDICTION.

NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES WHATSOEVER

REGARDING THE SUITABILITY OR NON-SUITABILITY OF A PRODUCT OR A SERVICE

FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF THE WiMAX FORUM

OR ANY THIRD PARTY.

Each WiMAX Forum member acknowledges that the WiMAX Forum has not investigated or made an

independent determination regarding title or noninfringement of any technologies that may be incorporated,

described or referenced in this document. Use of this document or implementation of any technologiesdescribed or referenced herein may therefore infringe undisclosed third-party patent rights or other

intellectual property rights. Each member acknowledges that it is solely responsible for making all

assessments relating to title and noninfringement of any technology, standard, or specification referenced in

this document and for obtaining appropriate authorization to use such technologies, technologies, standards,and specifications, including through the payment of any required license fees.

3 of 36

1

2

345

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

3031

32

33

34

35

36

37

38

39

40

41

42

4344

45

46

47

48

1



NOTHING IN THIS DOCUMENT CREATES ANY WARRANTIES OF TITLE OR

NONINFRINGEMENT WITH RESPECT TO ANY TECHNOLOGIES, STANDARDS OR

SPECIFICATIONS REFERENCED OR INCORPORATED INTO THIS DOCUMENT.

IN NO EVENT SHALL THE WiMAX FORUM OR ANY MEMBER BE LIABLE TO ANY OTHER

MEMBER OR TO A THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO

THE USE OF THIS DOCUMENT, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT

SUCH USE INFRINGES A THIRD PARTY’S INTELLECTUAL PROPERTY RIGHTS OR THAT

IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS

DOCUMENT, EACH MEMBER WAIVES ANY SUCH CLAIM AGAINST THE WiMAX FORUM

AND ITS MEMBERS RELATING TO THE USE OF THIS DOCUMENT.

This document is subject to the WiMAX Forum IPR Policy and may contain Necessary Claims that

are subject to licensing disclosures or other licensing statements as listed in Appendix [IPR].

However, the listed Necessary Claims may not be all Necessary Claims contained in the document.

Each WiMAX Forum member expressly acknowledges that the WiMAX Forum has not investigated

or made an independent determination regarding title or noninfringement of any technologies that

may be incorporated, described or referenced in this document. Use of this document or

implementation of any technologies described or referenced herein may therefore infringe

undisclosed third-party patent rights or other intellectual property rights. Each member

acknowledges that it is solely responsible for making all assessments relating to title and

noninfringement of any technology, standard, or specification referenced in this document and for

obtaining appropriate authorization to use such, technologies, standards, and specifications,

including through the payment of any required license fees.

The WiMAX Forum reserves the right to modify or amend this document without notice and in its sole

discretion.

“WiMAX,” “WiMAX Forum,” “WiMAX Certified,” and “WiMAX Forum Certified” are trademarks of the

WiMAX Forum. Third-party trademarks contained in this document are the property of their respectiveowners.

4 of 36

1

2

3

45

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

3132

33

1



TABLE OF CONTENTS

1 INTRODUCTION 7

2 OBJECTIVE AND SCOPE 7

2.1 OAM&P OVERVIEW (I NFORMATIVE) 8

1.1.1 WIMAX NETWORK ELEMENTS (I NFORMATIVE) 102.1.1 WiMAX Element Management System (Informative) 11

2.1.2 WiMAX Network Management System (Informative) 112.1.3 WiMAX Service and Business Management Systems (Informative) 12

3 ABBREVIATIONS, DEFINITIONS, AND CONVENTIONS (INFORMATIVE) 13

3.1 CONVENTIONS (I NFORMATIVE) 13

3.2 ABBREVIATIONS AND ACRONYMS (I NFORMATIVE) 13

3.3 DEFINITIONS (I NFORMATIVE) 13

4 REFERENCES 14

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 INTEGRATION REFERENCE POINT DEFINITIONS (INFORMATIVE) 16

5.1 I NTRODUCTION (I NFORMATIVE) 16

5.1.1 IRP DEFINITIONS PHASES (I NFORMATIVE) 17

5.1.2 MANAGEMENT SOLUTIONS I NTEGRATION (I NFORMATIVE) 18

5.2 R EQUIREMENTS DEFINITIONS (I NFORMATIVE) 19

5.2.1 FAULT MANAGAMENT (I NFORMATIVE) 19

5.2.1 FAULT MANAGEMENT USE CASES (I NFORMATIVE) 20

5.2.1.1 FAULT DETECTION USE CASE (I NFORMATIVE) 205.2.1.2 PERFORMANCE MONITORING USE CASE (I NFORMATIVE) 21

5.2.1.3 FAULT R ECOVERY USE CASE (I NFORMATIVE) 22

5.2.1.4 TESTING USE CASE (I NFORMATIVE) 22

5.2.1.5 ALARM SERVER USE CASE (I NFORMATIVE) 23

5.2.1.6 NMS COMMANDS USE CASE (I NFORMATIVE) 23

5.2.2 CONFIGURATION MANAGAMENT (I NFORMATIVE) 24

5.2.3 ACCOUNT MANAGAMENT (I NFORMATIVE) 24

5.2.4 SECURITY MANAGAMENT (I NFORMATIVE) 245.2.5 PERFORMANCE MANAGAMENT (I NFORMATIVE) 24

5.3 AUTOMATIC SERVICE DEVELOPMENT USE CASES (I NFORMATIVE) 24

6 EMS-NMS INTERFACE REQUIREMENTS (NORMATIVE) 25NOTE: IN SOME INSTANCES, EMS IS NOT A SEPARATE ENTITY, AND MAY RESIDE

INSIDE THE NE. HOWEVER, NMS ALWAYS INTERFACES TO EMS FUNCTIONALITIES.

27

6.1 GENERAL R EQUIREMENTS (NORMATIVE) 27

5 of 36

1

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

28

29

30

31

32

33

34

35

36

37

3839

40

41

42

1



6.1.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 27

6.2 FAULT MANAGEMENT R EQUIREMENTS (NORMATIVE) 29

NMS COMMANDS 31


6.3 PERFORMANCE MANAGEMENT R EQUIREMENTS (NORMATIVE) 32


6.4 CONFIGURATION MANAGEMENT R EQUIREMENTS (NORMATIVE) 33


6.5 ACCOUNT MANAGEMENT R EQUIREMENTS (NORMATIVE) 35

TBD 35


6.6 SECURITY MANAGEMENT R EQUIREMENTS (NORMATIVE) 356.6.1 RELEVANT 3GPP 32-SERIES TECHNICAL SPECIFICATIONS 35

ANNEX A DOCUMENT HISTORY (INFORMATIVE) 36

6 of 36

1

2

3

4

5

6

7

8

9

10

11

1213

14

15

1



1 Introduction

IEEE Std 802.16™ is an emerging suite of standards for Broadband Wireless Access (BWA). IEEE Std802.16e™ amendment to the IEEE 802.16 base specification enables combined, fixed, and mobile

operation in licensed and license-exempt frequency bands under 11 GHz. IEEE Std 802.16 defines a high-

throughput packet data network radio interface capable of supporting several classes of Internet Protocol

(IP) applications and services including isochronous applications such as Voice Over IP (VoIP) andapplications with bursty data access profiles such as TCP applications.

This is the first of a three-stage, end-to-end network system architecture specification for broadband

wireless networks based on WiMAX Forum Certified™ products. This document specifies

recommendations and requirements for such networks from the perspective of network operators intending

to deploy WiMAX networks. It describes business and usage scenarios, deployment models, functional

requirements, and performance guidelines for the end-to-end system. Architecture details shall be specifiedin stage-2 and stage-3 specifications based on requirements outlined in this document.

During the course of the development of this document, a progressive phased approach to the developmentof the WiMAX network capability was identified to be able to build networks and network components on

a timely basis, yet ultimately produce a full-featured network.

This work will be governed by the objectives of the WiMAX Forum™. While this work is aligned with the

IEEE 802.16 suite of standards, there is a need and opportunity to address issues that go beyond the IEEE802.16 standards. These issues could be in areas that are covered by other standards, or not covered by any

other standards. Throughout the rest of this document, the terms WiMAX networks and WiMAX technology

will be used to loosely refer to the networks and technology that are the focus of this specification. The

term WiMAX Forum Certified will be used formally to refer to certified products.

This document captures general assumptions made for the support of MMSC in various roaming and

interworking scenarios, service requirements on infrastructure, device, performance and others. TheMMSC feature as specified in this document is expected to deprecate those requirements pertaining to

sections “Level – 4 Service Continuity” and “Level – 5 Seamless Services” as defined in [1].

NOTE: upon ballot comment change the “is expected to deprecate” to “deprecates” and generate a CR 1)

delete requirement R-[215], 2) add reference to this document to rel 1.5 level 4 and 5 sections.

2 Objective and Scope

This document is intended to support the following objectives:

• 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.

7 of 36

1

23

4

5

6

7

8

9

10

11

12

13

1415

16

17

18

19

20

21

22

23

24

25

2627

28

29

30

31

32

33

34

35

363738

3940

41

1



• To capture performance data that are used to fine-tune WiMAX networks for performance

improvement, and customer satisfaction

It is the intent to reuse, where appropriate and applicable, the existing OMA&P standards and/or recommendations developed by various SDOs and industry fora, such as IEEE 802.16, WiMAX Forum,

TMF, 3GPP, etc. This document will focus on the interface between the Service Provider’s Network

Management System (NMS) and the Element Management System (EMS) that are typically provided by

vendors.

The scope of this work includes the following:

• 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.

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

• Define Fault Management requirements.

• Define Configuration Management requirements.

• Define Accounting Management requirements.

• Define Performance Management requirements.

• Define Security Management requirements.

2.1 OAM&P Overview (Informative)

OAM&P (Operations, Administration, Maintenance, and Provisioning) is designed to enable the

automation of network operations and business processes that are critical to the rapid WiMAX deployment.

OAM&P is also referred as OSS/BSS (Operations Support System / Business Support System). OSS is

designed to support network operations, while BSS is designed to support business development.

FCAPS (Fault Management, Configuration Management, Accounting Management, Performance

Management, and Security Management) model that was introduced in ITU-T recommendation M-3400 is

used to describe the OSS/BSS framework.

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 toinsure subscriber’s SLA (Service Level Agreement) is enforced

8 of 36

12

3

45

6

7

8

9

10

11

1213

14

1516

17

18

19

20

21

22

23

24

2526

27

28

29

30

31

32

33

34

35

36

373839

40

4142

1



Security Management – Involve network security and user / device authentication and

authorization

A TMN (Telecommunications Management Network) model has been proposed by the ITU andTeleManagement Forum (TMF) to structure OSS/BSS management functions and define interfaces

between these functional entities. An OAM&P reference model based on TMN is shown in Figure 1 TMN

partitions the OSS management functions into the following layers:

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 of 36

12

3

45

6

7

8

910

11121314

15

1617

1819

20212223

242526

27

2829

1



FieldManagement

NEs

TroubleManagement

CustomerCare

Order EntryProcessing

NMS

BillingProcessing

Device &Service

Provisioning

OMA DM or TR69ServerSS

EMSEML

NML

SMLBML

Customer

Interfaces

SS BS ASNGateway CSN

OMA DM or TR69Client

BSEMS

ASNEMS

CSNEMS

EMS

Figure 1— OAM&P Reference Model

1.1.1 WiMAX Network Elements (Informative)

WiMAX 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

CSN – CSN gateway should support CSN MIB that include RADIUS server MIB andDIAMETER 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”

10 of 36

12

3

4

5

6

78

9

10

1112

1314

15

16

17

18

19

2021

22

23

1



• 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.

2.1.1 WiMAX Element Management System (Informative)

The WiMAX EMS is composed of management stations for managing the management agents that reside

at the network elements.

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.

2.1.2 WiMAX Network Management System (Informative)

The WiMAX NMS interface to EMS to perform management functions across multiple NE. OMA DM

Server is responsible for managing OMA DM clients.

11 of 36

1

2

3

45

6

7

8

9

101112

1314

151617181920

21222324

25262728

293031

32

333435

36

37

38

39

40

1



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 ticketsand 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 subscriber’s

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.

2.1.3 WiMAX Service and Business Management Systems (Informative)

SML and BML contain the following functions.

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.

12 of 36

123

45

67

89

10

1112

131415

16

17

1819

20

2122

23

242526

27

28

2930

31

3233

34

3536

3738

39

40

41

42

1



3 Abbreviations, Definitions, and Conventions (Informative)

3.1 Conventions (Informative)

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be

interpreted as described in Ref [2] RFC 2119.

3.2 Abbreviations and Acronyms (Informative)

ADAC Automatically Detected and Automatically Cleared

ADMC Automatically Detected and Manually Cleared

BMS Business Management Systems

BSS Business Support Systems

EMS Element Management System

IRP Integration Reference Point

IS Information Services

NMS Network Management System

OAM&P Operations, Administration, Maintenance, and Provisioning

OSS Operation Support Systems

SMS Service Management System

SS Solution Set

TMF TeleManagement Forum

TMN Telecommunications Management Network

3.3 Definitions (Informative)

13 of 36

1

2

3

4

5

6

7

8

9

10

11

1213

14

15

16

17

18

19

20

21

22

23

24

2526

27

28

29

30

31

32

33

34

35

36

37

38

39

40

1



4 References

[1] Recommendations and Requirements for Networks based on WiMAX Forum, Release 1.5

4.1 IEEE

[2] IEEE P80216Rev2_D2 “Part 16: Air Interface for Broadband Wireless Access Systems”, December,

2007

4.2 ETSI

[3] ETSI TS 188 003 “OSS requirements; OSS definition of requirements and priorities for further

network management specifications for NGN”

[4] ETSI TS 188 001 “NGN management; OSS Architecture Release 1”

4.3 TMF

[5] TMF NGOSS Suite of specifications (including eTOM, SID and TAM)

[6] TMF Service Level Agreement (SLA) Management Handbook

[7] TMF OSS through Java (OSS/J) specifications and tools

4.4 ITU

[8] ITU-T X.733 “Information Technology – Open System Interconnection – System Management:

Alarm Reporting Function”

[9] ITU-T X.735 “Information Technology – Open System Interconnection – System Management: Log

Control Function”

[10] ITU-T X.745 “Information Technology – Open System Interconnection – System Management:

Test Manageemnt Function”[11] ITU-T M.3050.0 “Enhanced Telecom Operations Map (eTOM)” – Introduction

[12] ITU-T M.3050.1 “Enhanced Telecom Operations Map (eTOM)” – The business process framework

[13] ITU-T M.3050.2 “Enhanced Telecom Operations Map (eTOM)” – Process decompositions and

descriptions

[14] ITU-T M.3050.3 “Enhanced Telecom Operations Map (eTOM)” – Representative process flows

[15] ITU-T M.3050.4 “Enhanced Telecom Operations Map (eTOM)” – B2B integration: Using B2B

inter-enterprise integration with the eTOM

[16] ITU-T M.3050 Supplement 1 “Enhanced Telecom Operations Map (eTOM)” – ITIL applicationnote

[17] ITU-T M.3050 Supplement 2 “Enhanced Telecom Operations Map (eTOM)” – Public B2B

Business Operations Map (BOM)

[18] ITU-T M.3050 Supplement 3 “Enhanced Telecom Operations Map (eTOM)” – to M.3400 mapping

[19] ITU-T M.3050 Supplement 4 “Enhanced Telecom Operations Map (eTOM)” – An eTOM Primer

[20] ITU-T M.3060 “Principles for the Management of Next Generation Networks”

4.5 3GPP

[21] 3GPP TS 32.101 Telecommunication management; Principles and high level requirements”

[22] 3GPP TS 32.102 “Telecommunication management; Architecture”

14 of 36

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

2021

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

1



[23] 3GPP TS 32.111-1 “Fault Management; Part 1: 3G Fault Management Requirements”; (Release

7)[24] 3GPP TS 32.111-2 “Fault Management; Part 2: Alarm IRP: Information Service”; (Release 6)

[25] GPP TS 32.111-3 “Fault Management; Part 3: Alarm IRP: CORBA Solution Set”; (Release 6)[26] 3GPP TS 32.121 “Telecommunication management; Advanced alarming on Itf-N Integration

Reference Point (IRP); Requirements”

[27] 3GPP TS 32.122 “Telecommunication management; Advanced alarming on Itf-N Integration

Reference Point (IRP); Information Service (IS)”

[28] 3GPP TS 32.123 “Telecommunication management; Advanced alarming on Itf-N Integration

Reference Point (IRP); Common Object Request Broker Architecture (CORBA) Solution Set (SS)”[29] 3GPP TS 32.125 “Telecommunication management; Advanced Alarming on Itf-N Integration

Reference Point (IRP); eXtensible Markup Language (XML) definitions”

[30] 3GPP TS 32.150 “Telecommunication management; Integration Reference Point (IRP) Concept and

definitions”

[31] 3GPP TS 32.151 “Telecommunication management; Integration Reference Point (IRP) Information

Service (IS) template”

[32] 3GPP TS 32.152 “Telecommunication management; Integration Reference Point (IRP) Information

Service (IS) Unified Modelling Language (UML) repertoire”

[33] 3GPP TS 32.155 “Telecommunication management; Requirements template”

[34] 3GPP TS 32.172 “Telecommunication management; Subscription Management (SuM) Network Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS)”

[35] 3GPP TS 32.175 “Telecommunication management; Subscription Management (SuM) Network

Resource Model (NRM) Integration Reference Point (IRP): eXtensible Markup Language (XML)

definition”

[36] 3GPP TS 33.203, “3G security; Access security for IP-based services.”[37] 3GPP TS 32.240 “Telecommunication management; Charging management; Charging architecture

and principles”[38] 3GPP TS 32.251 “Telecommunication management; Charging management; Packet Switched (PS)

domain charging”

[39] 3GPP TS 32.260 “Telecommunication management; Charging management; IP Multimedia

Subsystem (IMS) charging”[40] 3GPP TS 32.274 “Telecommunication management; Charging management; Short Message Service

(SMS) charging”

[41] 3GPP TS 32.296 “Telecommunication management; Charging management; Online Charging

System (OCS): Applications and interfaces”[42] 3GPP TS 32.298 “Telecommunication management; Charging management; Charging Data Record

(CDR) parameter description”

[43] 3GPP TS 32.299 “Telecommunication management; Charging management; Diameter charging

applications”

[44] 3GPP TS 32.332 “Telecommunication management; Notification Log (NL) Integration Reference

Point (IRP): Information Service (IS)”

[45] 3GPP TS 32.333 “Notification Log IRP: CORBA Solution Set”; (Release 6)

[46] 3GPP TS 32.335 “Notification Log IRP: XML Definitions “; (Release 6)

[47] 3GPP TS 32.362 “Telecommunication management; Entry Point (EP) Integration Reference Point(IRP): Information Service (IS)”

[48] 3GPP TS 32.363 “Telecommunication management; Entry Point (EP) Integration Reference Point

(IRP): Common Object Request Broker Architecture (CORBA) Solution Set (SS) “

[49] 3GPP TS 32.405 “Telecommunication management; Performance Management (PM); Performance

measurements Universal Terrestrial Radio Access Network (UTRAN)”

15 of 36

1

2

3

45

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

3132

33

34

35

36

37

38

39

40

41

42

43

4445

46

47

48

49

1



[50] 3GPP TS 32.409 “Telecommunication management; Performance Management (PM); Performance

measurements IP Multimedia Subsystem (IMS)”

[51] 3GPP TS 32.421 “Telecommunication management; Subscriber and equipment trace; Trace

concepts and requirements”[52] 3GPP TS 32.602 Telecommunication management; Configuration Management (CM); Basic

configuration management Integration Reference Point (IRP): information service

[53] 3GPP TS 32.603 Telecommunication management; Configuration Management (CM); Basic

configuration management Integration Reference Point (IRP): CORBA solution set.

[54] 3GPP TS 32.622 “Telecommunication management; Configuration Management (CM); Genericnetwork resources Integration Reference Point (IRP): Network Resource Model (NRM)”

[55] 3GPP TS 32.623 Telecommunication management; Configuration Management (CM);

[56] 21 Generic Network Resources Integration Reference Point (IRP): CORBASolution Set.

[57] 3GPP TS 32.732 “Telecommunication management; IP Multimedia Subsystem (IMS) Network

Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS)”

[58] 3GPP TR 32.808 “Telecommunication management; Study of Common Profile Storage (CPS)

Framework of User Data for network services and management”

[59] 3GPP TR 32.808 “Telecommunication management; Study of Common Profile Storage (CPS)

Framework of User Data for network services and management”[60] 3GPP TR 32.816 “Telecommunication management; Study on management of Long Term

Evolution (LTE) and System Architecture Evolution (SAE)”

[61] 3GPP TR 32.818 “Telecommunication management; Study on 3GPP SA5 / MTOSI XML

harmonization”

[62] 3GPP TR 32.819 “Telecommunications management; Element management layer - Operation

System Function (E-OSF) definition”

[63] 3GPP TR 32.820 “Telecommunication management; Charging management; 3GPP System

Architecture Evolution (SAE): Charging aspects”[64] 3GPP TR 32.821 “Telecommunication management; Study of Self-Organising Networks (SON)

related OAM Interfaces for Home NodeB”

[65] 3GPP TR 32.822 “Telecommunication management; Study on System Maintenance by Itf-N”

4.6 IETF

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

5 Integration Reference Point Definitions (Informative)

5.1 Introduction (Informative)

The Integration Reference Point (IRP) concept was used to promote the wider adoption of standardized

Management interfaces in telecommunication networks. Basically, the IRP methodology consists of technology neutral modelling and solution sets. The technology neutral modelling is intended to define the

management requirements, interfaces, and network resource modelling that are common across multipletechnologies. The solution sets define a set of management protocols that can be used to support technology

neutral models.

16 of 36

1

2

3

45

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

3839

40

41

42

43

1



The following sections describe the basic concept of IRP that was derived from 3GPP document – TS

32.150 [29]. For additional details of the IRP approach and definitions, readers should refer to the 3GPP

document.

5.1.1 IRP Definitions Phases ( Informative)

Technologies advances very rapidly by following the trend of Morse’s law. But the management

applications tend to stay for long period of time. Therefore, it is important that IRP is designed in ways thatrequirements and the modelling of network resources to be managed are independent of the technology and

the protocol used in the management system implementation. Figure 2 shows that IRP is defined in three phases.

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)

Figure 2—IRP Definitions Phases

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

5

6

7

8

9

10

1112

1314

15

16

17

18

19

20

21222324

25

26

1



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.

This document is intended to cover the Requirements phase, while stage 2 and stage 3 specifications are to

be developed to support IS and SS Definition phases.

5.1.2 Management Solutions Integration ( Informative)

When an operator acquires equipment from multiple vendors, it is desirable for the operator to use common

applications in the operator’s NMS layer to manage these multi-vendor networks. Since each NE will carry

its own management solution, IRPs are created to assist an operator to integrate multi-vendor management

solutions into their NMS infrastructure. To insure interoperability between NMS and EMS, an IRP is

defined between NMS and EMS,

This document standardizes the IRP at NMS – EMS interface or EMS north bound interface. Figure 3 is anexample of IRP definitions at the EMS north bound interface that contains five IRPs:

• 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

1

2

3

45

6

7

8

9

10

11

12

13

1415

16

17

18

19

20

21

1



NENENE

PerformanceManagement

FaultManagement

ConfigurationManagement

SecirityManagement

AccountManagement

AMIRP

SMIRP

CMIRP

AlarmIRP

PMIRP

NMS

NENE

EMS

Vendor A EquipmentVendor B Equipment

NENE

NE

NENEEMS

Figure 3—IRP for Management Solutions Integration

5.2 Requirements Definitions (Informative)

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

5.2.1 Fault Managament (Informative)

Fault Management provides a set of functions that enable detection, reporting, and mitigation of faults.

Faults that may occur in the network can be grouped into one of the following categories:

• Hardware failures (e.g. the malfunction of some physical resource within a NE).

• Software problems (e.g. software bugs, database inconsistencies).

• Communication failures between EMS and NMS.

Figure 4 shows an example of the Fault Management process flow that is used to describe the Fault

Management use cases.

19 of 36

12

3

4

5

6

7

8

9

10

11121314

15

1617

1



FaultRecovery

PerformanceMonitoring

AlarmForwarding /

Filtering

AlarmServer

AlarmCorrelation

TestingManager

Testing

Agent

Fault

Restoration

[ F D2 ]

[ F D4 ]

[ C 2 ]

[ F R1 ]

[ F R2 ]

[ T 3 ]

[ T 1 ]

NE

EMS

NMS

System Log

Admin / OpState

[FR3]

[ C 4 ]

[ C 3 ]

FaultManagament

ConfigurationManagament

PerformanceManagament

Fault

Detection

[ C 1 ]

[ C 2 ’ ]

[FD4]

[FD1]

[FD3]

NMSCommands

[ P M1 ]

[ C 3 ’ ] [ C

3 ’ ]

[ A S 1 ]

[ P M2 ]

[FD2]

[T2]

Figure 4—Fault Management Process Flow

5.2.1 Fault Management Use Cases (Informative)

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

5.2.1.1 Fault Detection Use Case (Informative)

NE shall have mechanisms to detect faults. This use case deals with faults being detected by Fault

Management in NE.

[FD1] Fault Management process is started when Fault Detection detects a fault. Each fault should have

well-defined conditions on when a fault is declared and cleared. Commands shall be defined to

configure alarm severities, and the thresholds for fault declaration or clearance.

When a fault is detected or cleared, the Fault Detection shall send an alarm notification with thefollowing information to Alarm Forwarding / Filtering:

• 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

12

34

5

6

7

8

9

10

11

12

13

14

1516

1718

1920

1



• The time when the fault was detected

• The probable cause of the fault (e.g. transmit failure, receive failure, threshold crossed), as


• 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)

[FD2] 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.

[FD3] 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.

[FD4] EMS shall report the alarm to NMS. If EMS has capability to recover the fault locally, it shall

initiate Fault Recovery immediately.

5.2.1.2 Performance Monitoring Use Case (Informative)

Performance monitoring is intended to capture intermittent errors and troubles, resulting from the gradualdeterioration of some units in a NE. Performance monitoring is a pro-active maintenance technique to

enable the operator to detect and correct intermittent troubles and performance degradation before such

problems result in hard failures.

[PM1] When Performance Monitoring detects the crossing of some observed threshold on performance

counters, a notification shall be generated to initiate the fault management actions. The alarm

notification shall provide the following information:-Types of performance counters,

-Threshold

-Crossing event (e.g. above or below th ethreshold)

-The time when the threshold crossing occurred.

Permormance Monitoring shall log the threshold crossing events into System Log.

[PM2] The Alarm Server shall store/remove the threshold crossing alarm in/from the active alarm list.

Alarm Correlation identifies the root cause of the fault.

21 of 36

123

4567

8

9

10

11

12

13

14

15

16

1718

19

20

21

22

23

24

25

26

27

2829

30

31

32

33

34

35

3637383940

4142

43

44

45

1



[PM3] EMS shall report the alarm to NMS. If EMS has capability to recover the fault locally, it shall

initiate Fault Recovery immediately.

5.2.1.3 Fault Recovery Use Case (Informative)

Fault Recovery can be initiated automatically by EMS when a fault is detected in NE (see 5.2.1.1), or

manually by the operator through NMS interface. When the root cause and effect of the fault were

identified, EMS shall autonomously take fault recovery actions in order to minimize the servicedegradation or disruption. Operator can also initiate recovery actions if the operator deems that NE is not

able to perform its functions as the result of analysis and correlation of alarm reports and performance data,or if the operator wants to verify the newly replaced or repaired unit can provide the service.

[FR1] NMS / EMS initiate the fault recovery actions.

[FR2] Ask Fault Restoration agent in NE to restore faults. Depending on the severity and redeundancy, the

recovery actions shall include the following:

- Hardware units: hardware reset, switch to standby copy

-Software units: different levels of system initializations; fallback to previous software load,

download a software image;

The recovery actions shall be logged into the system log.

[FR3] Remove the fauly unit, and all other units depending on the faulty unit from services, by asking

Admin / Op State the to change the unit’s Administrative and Operation states.

The Administrative State is used by the Operator to make a resource available for service, or to

remove a resource from service. For example: there are four administrative states.

• FAULT : This state indicates the given component is in the faulty mode.

• STANDBY : In a redundant system, this state indicates the given

component is in the standby mode.

• ACTIVE : This state indicates the given component is in the Active mode.

• TEST : This state indicates the given component is running a test.

The Operational state provides the information about whether a component is capable of providingservices. For example, there are two operational states.

• IN SERVICE : This state indicates the given component is providing the

service.

• OUT OF SERVICE : This state indicates the given component is not

providing service because of a fault or because another resource on which it depends is out

of service.

5.2.1.4 Testing Use Case (Informative)

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

22 of 36

1

2

3

4

5

6

7

8

9

10

11

12

13

14

1516

17

18

19

20

21

22

23

24

25

262728

293031

32

33

34

3536

3738

39

40

41

42

43

1



• 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.

Testing can be initiated automatically by Fault Recovery in EMS (see 5.2.1.3), or manually by the operator

through NMS. The requirements for the test management service are based on ITU-T Recommendation

X.745 [10], where the testing description and definitions are specified.

[T1] NMS / EMS initiates the test.

[T2] Ask Admin / Op State to change the Administration states to Test to indicate this unit is not

available for service.

[T3] Ask the Test Agent in NE to perform the test.

5.2.1.5 Alarm Server Use Case (Informative)

The Alarm Server enables NMS to retrieve the alarms from the active alarm list. It shall be possible to

apply filters when accessing the active alarm information in the Alarm Server.

[AS1] NMS retrieves the specific alarms or alarms meeting the filtering criteria. The examples of filtering

criteria are shown below:

- Alarm severity

- Time when the alarm notification was received (e.g. latest alarm, alarms reported after certain

time)

-Unit identifier

5.2.1.6 NMS Commands Use Case (Informative)

NMS shall be able to send commands to EMS to retrieve alarm and event historical information from the

System Log, modify the alarm forwarding criteria, and configure the alarm thresholds and severities.

[C1] NMS sends commends to Fault Detection to configure the alarm severities or threshold.

[C2] NMS sends commends to Alarm Forwarding / Filtering to configure the alarm filtering criteria.

[C3] NMS sends commends to System Log to retrieve events in the log file independently, or to access the

log file in bulk through FTP protocol.

[C4] NMS sends commands to Admin / Op State to retrieve the administrative and operational states.

23 of 36

12

3

456

7

8

9

10

11

12

13

14

15

16

1718

19

20

21

22

23

24

252627

2829

30

31

32

33

34

35

36

37

38

3940

41

42

43

1



5.2.2 Configuration Managament (Informative)

TBD

5.2.3 Account Managament (Informative)

TBD

5.2.4 Security Managament (Informative)

TBD

5.2.5 Performance Managament (Informative)

TBD

5.3 Automatic Service Development Use Cases (Informative)

WiMAX services can be modeled in terms of bearer channel capabilities and client configuration. Bearer

channel capabilities include things such as service flow QoS attributes, classifications, and header

suppression. Client configuration focuses on capabilities of a client that are independent of the bearer

channels or are above the IP layer. SMS should create service profiles of bearer channel and client

configuration capabilities that can be used for specific services or applications (e.g. gaming, mobile video).

Here is the use case of a typical service creation:

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)

In order to support rapid WiMAX subscriber’s ramp, SMS should be able to activate subscribers in bulk

simultaneously. Here is an use case of subscriber activation procedure:

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 it’s service profile from self configuration

SMS updates the CSN data store (AAA database) for each subscribers

24 of 36

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1718

19202122

23

24

2526

27

28

2930

1



6 EMS-NMS Interface Requirements (Normative)

The requirements specified in this document form an extension of network requirements, per the latest3GPP 32-series specifications capabilities where applicable, to enable operation in a WiMAX Network

environment as part of the WIMAX Release 2.0 Network Requirements.

These requirements are expressed as additions to, modifications of, and/or exclusions from the latest 3GPP

32-series specifications. This document is therefore composed in part as a “delta” document. The 3GPP 32-series specifications are included as references, i.e., applicable materials are reused as they are from the

source document via direct referencing unless otherwise noted in this document. It is intended that allrevisions to the 32-series specifications will also apply to this “delta” document unless otherwise specified.

Overview of OAM&P for WiMAX Network (3GPP Delta Specification): The structure of this document is

aligned with the structure of the 3GPP 32-Series of specifications whose applicability and/or exceptions at

a high level are described below:

General Exceptions:

The terms 3GPP/PLMN (and its associated technology specific terms, such as UMTS, GSM, etc.) are

not applicable for the WiMAX Network. Nevertheless the terms 3GPP/PLMN should be interpreted in

the broader sense of “Wireless Communications Systems” including the WiMAX system. If not stated

otherwise there are no additions or exclusions required.

The table below provides a mapping between 3GPP and WiMAX terminology for clarification purpose

– in other words, where appropriate, the 3GPP term should be interpreted as an equivalent WiMAX

term in the referenced text.

3GPP WiMAX Remarks

Core Network (CN) Connectivity Service Network (CSN)

Itf-N (“Northbound” Interface) Itf-N (“Northbound” Interface) EMS~NMS

Iub (Interface between RNC and Node B) R6 BS~ASN-GW

Node B Base Station (BS)

Radio Network Controller (RNC) Access Service Network (ASN)

Mobile Station (MS) Subscriber Station (SS)/MS

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

1

2

34

5

6

7

8

9

10

11

12

13

14

15

1617

1819

20

21

22

2324

25

26

27

2829

30

31

32

33

34

1



[ Temp. Editor’s 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 requirements2). 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) Conceptand 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): Requirements9). 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

123

4

5

6

7

89

10

11

12

13

14

15

16

17

18

19

20

2122

23

24

25

26

27

1



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); Requirements14). 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.

6.1 General Requirements (Normative)

R-[262] The WiMAX network supporting Mobility Access SHALL provide for standardized network

management functions as Information Services developed using the protocol neutral Integration

Reference Point methodology and technology specific solution sets Ref [30 – 32.150].

R-[263] The WiMAX network SHALL support remote monitoring of radio link/MAC, IP traffic statistics,

QoS settings, and Network availability (over specific time period).

R-[271] Information Services, using the protocol neutral Information Reference Point methodology,

developed for the WiMAX network SHALL use technology specific solution sets (realizations)

for at least the following technologies: SOAP; CORBA/IDL; SNMP.

R-[273] For WiMAX network supporting Mobility Access, the defined Information Services SHALL

support retrieval of any logs maintained using mechanisms appropriate for the technology specificsolution set which for particular technology specific solutions sets can be found in Ref [44 –

32.332], Ref [45 – 32.333], and Ref [46 – 32.335].

R-[270] For WiMAX network supporting Mobility Access, the defined Information Service(s) Ref [52 – 32.602], Ref [53 – 32.603], Ref [54 – 32.622], Ref [55 – 32.623], Ref [24 – 111.2], and Ref [25 –

111.3] SHALL support the following NMS capabilities: Alarms displaying with filteringcapabilities to limit the amount of information, alarms acknowledgement, services provisioning

(for end-to-end provisioning), information on WiMAX network elements for network map

displaying at NMS level.

R-[272] The defined Information Services SHALL support interaction between the NMS and the EMS.

6.1.1 Relevant 3GPP 32-Series Technical Specifications

3GPP TS 32.101 Telecommunication management; Principles and high level requirements (Release

8)

General Exceptions:

27 of 36

1

2

3

45

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

2728

29

30

31

32

33

34

35

36

37

38

39

40

41

42

1



The high level OAM architecture is based on WiMAX network architecture not the 3GPP

network architecture as shown in Figure 1.

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)


Section 7 PLMN management functional architecture (Informative)


3GPP TS 32.102 Telecommunication management; Architecture (Release 8)

General Exceptions:

Specific Exceptions:

Section 4 General (Informative)There are no additions, modifications, or exclusions.

Section 5 General view of PLMN Management Physical architectures ( Infor mative)


Section 6 Basic objectives for PLMN Management Physical Architecture (Informative)


Section 7 TM Architectural aspects (Informative)

7.3.3 Entities of a 3GPP system – text in this section should be interpreted in light of theWiMAX 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 )


Section 12 3GPP TMN Conformance (Normative)


Section 13 TMN planning and design considerations (Informative)


Section 14 Mediation/Integration (Informative)


3GPP TS 32.150 Telecommunication management; Integration Reference Point (IRP) Concept and

definitions (Release 8)

General Exceptions:

Special Exceptions:

Section 4 Integration Reference Points (IRPs) (Normative)


28 of 36

12

3

456

7

89

1011

1213

14

15

16

171819

2021

2223

2425

2627

28

29

3031

3233

3435

3637

3839

40

41

42

43

44

4546

4748

1



3GPP TS 32.311 Generic Integration Reference Point (IRP) management: Requirements (Release 7)

General Exceptions:

Special Exceptions:

Section 4 Generic IRP functions over Itf-N (Normative)


3GPP TS 32.341 File Transfer (FT) Integration Reference Point (IRP): Requirements (Release 7)

General Exceptions:

Special Exceptions:

Section 4 File Transfer IRP concept (Informative)

There are no additions, modifications, or exclusions. Section 5 File Transfer IRP requirements (Normative)


Section 6 Overview of IRP's related to File Transfer (FT) (Informative)


6.2 Fault Management Requirements (Normative)

General

R-[268] For WiMAX network supporting Mobility Access, the Alarm Management Information Service

Ref [25 – 111.3] an Ref [30 – 32.150] SHALL be the basis for forwarding of alarm notifications

from the EMS to the NMS.

R-[269] The EMS SHALL support the following capabilities: Alarms displaying, alarms

acknowledgement, configuration/provisioning of BS and SS/MS, auto-discovery, performances

and traffic monitoring, network topology displaying, inventory and status and software

downloading.

R-[264] Local craft interfaces SHOULD be included in every WiMAX network element for installation,

commissioning and troubleshooting.

Fault Detection

R-[267] Alarm notifications generated as the corresponding network event occurs SHALL be delivered to

the NMS and EMS alarm capabilities in a timely and reliable manner.

R-[xxx] WiMAX EMS SHALL forward alarm notifications to the NMS when a fault is detected or cleared

in a NE.

R-[xxx] There SHALL be mechanisms to detect faults in the NE.

R-[xxx] The fault detection alarm notification SHALL provide the following information:

• 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

2

3

456

78

9

10

11

12

1314

15

16

171819

2021

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

4142

1



• The severity of the fault (e.g. cleared, indeterminate, critical, major, minor, warning), as


• The time when the fault was detected

• The probable cause of the fault (e.g. transmit failure, receive failure, threshold crossing), asdefined 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)

R-[xxx] WiMAX EMS SHALL be able to respond to a NMS or local operator request to allow or suppress

alarm reporting (i.e. alarm filtering) for each NE, based on the following alarm filtering criteria:

• Identifier of the NE

• Identifier of HW or SW component in a NE

• Alarm severity

• Time

R-[xxx] WiMAX EMS SHALL be able to detect the communication failures that prevent the reception of

alarms from from NE, and SHALL raise an appropriate alarm to NMS when it happens.

Performance Monitoring

R-[xxx] WiMAX EMS SHALL forward an alarm notification to the NMS wh.en the crossing of thresholds

on performance measurements is detected.

R-[xxx] There SHALL be performance measurements to capture intermittent errors, resulting from the

gradual deterioration of some units in a NE.

R-[xxx] The performance measuremnts alarm notification shall provide the following information:

• Types of performance counters,

• Threshold

• Crossing event (e.g. above or below the threshold)

• The time when the threshold crossing occurred

Fault Recovery

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

• 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

30 of 36

12

3

45

6789

10

11

12131415

16

17

18

19

20

21

22

23

24

25

262728

29

30

31

32

333435

36

3738

3940

1



Testing

R-[xxx] WiMAX EMS SHALL be able to support a NMS or local operator initiated request to initiate teston NE for the following reasons:

• 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.

R-[xxx] WiMAX EMS MAY support the requirements for the test management service, based on ITU-T

Recommendation X.745 [10], where the testing description and definitions are specified.

Requests can be initiated by local opeartor or NMS.

R-[xxx] Testing MAY be initiated automatically by Fault Recovery to assist the fault isolation.

Alarm Server

R-[xxx] WiMAX EMS SHALL provide the local operator or NMS access to active alarms in a EMS

either directly or through filters based on criteria shown below:

• 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

R-[xxx] WiMAX EMS SHALL support a NMS or local operator initited request for configuration of

thresholds that determine the declaration or clearing of a fault, and modify the alarm severity in

EMS. EMS SHALL confirm such alarm configuration commands.

R-[xxx] WiMAX EMS SHALL support a NMS or local operator initiated request to be able to configurethe filtering criteria to be used for alarm notification.

R-[xxx] WiMAX EMS SHALL forward notifications for any modifications to configuration parameters.

R-[xxx] WiMAX NMS SHALL be able to access the Administration and Operational states in EMS.

System Logs

R-[xxx] WiMAX EMS SHALL support a NMS or local operator initited request to access the historical

events or alarms in the system logs in EMS independently, or test access the log file in bulk through FTP protocol. If the SNMP solution set is supported, then the log file mechanism as

defined in wmanDevMib in IEEE. P802.16Rev2/D2 SHALL be supported.

31 of 36

1

2

34

56

78

910

11

12

13

14

15

16

17

18

19

202122

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

1




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

General Exceptions:

Special Exceptions:

Section 4 Fault Management concept and requirements (Informative)


Section 5 N interface (Itf-N) (Normative)There are no additions, modifications, or exclusions.

3GPP TS 32.331 Notification Log (NL) Integration Reference Point (IRP): Requirements (Release 7)

General Exceptions:

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

Section 5 Notification log IRP requirements (Normative)


6.3 Performance Management Requirements (Normative)

R-[265] Management and monitoring of WiMAX network elements SHALL be done through Element

Management System (EMS) via NMS-EMS standardized interfaces.

R-[266] Management and monitoring of SS/MS SHALL be done through Element Management System

(EMS) using protocol neutral Integration Reference Point methodology and technology specificsolution sets.


3GPP TS 32.401 Performance Management (PM); Concept and requirements (Release 7)

General Exceptions:

References to 3GPP Performance measurement definitions are not applicable for

WiMAX. WiMAX needs to define the performace measurements applicable for WiMAX

environment.


Section 4 Concept (Informative)


Section 5 Functional requirements (Normative)


32 of 36

1

2

34

56

78

910

1112

13

14

15

161718

1920

21

22

23

24

25

2627

28

29

30

313233

34

3536

3738

39

40

1



3GPP TS 32.411 Telecommunication management; Performance Management (PM) Integration

Reference Point (IRP): Requirements (Release 7)

General Exceptions:


Section 5 Detailed requirements ( Nor mative)


Section 6 Overview of IRPs related to PM (Normative)


6.4 Configuration Management Requirements (Normative)

3

rd

Party InteroperabilityR-[xxx] WiMAX EMS/NMS SHALL support the configuration of ASN-GW to operate with 3rd party BS

R-[xxx] WiMAX EMS/NMS SHALL support the configuration of BS to operate with 3rd party ASN-GW

Editor note: are these requirements applicable to profile B?


3GPP TS 32.301 Configuration Management (CM); Notification Integration Reference Point (IRP):

Requirements (Release 7)

General Exceptions:


Section 4 Notification management functions over Itf-NXx (Normative)


3GPP TS 32.600 Telecommunication management; Configuration Management (CM); Concept and

high-level requirements; (Release 7)

General Exceptions:


Section 4 Network Configuration Management (CM) (Informative)


Section 5 CM service components ( Info rmative)


Section 6 CM functions (Informative)

33 of 36

1

2

3

45

6

7

8

9

10

11

1213

14

15

16

17

18

19

20

2122

23

24

25

2627

28

29

3031

32

33

34

35

36

1




Section 7 Itf N Interface ( Nor mative)


3GPP TS 32.601 Telecommunication management; Configuration Management (CM); Basic CM

Integration Reference Point (IRP): Requirements; (Release 7)

General Exceptions:


Section 4 Requirements (Normative)


3GPP TS 32.611 Telecommunication management; Configuration Management (CM); Bulk CMIntegration Reference Point (IRP): Requirements (Release 7)

General Exceptions:


Section 4 Bulk CM and Itf N Interface (Normative)


3GPP TS 32.621 Telecommunication management; Configuration Management (CM); Generic network

resources Integration Reference Point (IRP); Requirements (Release 7)

General Exceptions:


Section 4 Requirements (Normative)


3GPP TS 32.671 Configuration Management (CM); State Management Integration Reference Point

(IRP): Requirements (Release 7)

General Exceptions:


Section 4 Requirements for the State Management IRP (Normative)


34 of 36

1

2

3

4

5

6

7

89

10

11

12

1314

15

1617

18

19

20

21

22

232425

26

27

28

29

30

31

3233

3435

36

37

1



6.5 Account Management Requirements (Normative)

TBD


TBD

6.6 Security Management Requirements (Normative)

TBD


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

General Exceptions:


Section 4 Security Management background (Informative)


Section 5 Security Management context and architecture (Informative)


Section 6 Security threats in IRP context (Informative)


Section 7 Security requirement of Itf-N (Normative)


35 of 36

1

2

3

4

5

6

7

8

9

10

11

12

1314

15

16

17

18

19

20

21

22

23

24

1



Annex A Document History (Informative)

Date Subject History Version

2007-11-27 Baseline document based on SPWG Rel. 1.5 0.1

2007-12-06 Changes as per agreements from DEC. 2007 FtF meeting 0.11

2008-01-31 Includes changes from Jan. 2008 Kona meeting 0.20

1

2

s50-20080218-018__080218-spwg_nmr_v0.20_clean (+deltaapproachtext)-nnsn

Documents