An Architecture to Develop Network Management Standards

Document Number: IEEE S802.16g-04/08r1Date Submitted: 3 November 2004

Source:Scott F. Migaldi & Joerg Schmidt Voice: +1.847.576.0574Motorola Fax: +1.847.576.67581303 East Algonquin Rd E-mail: w10265@motorola.comSchaumburg, IL. 60194

Venue:IEEE 802 Plenary, San Antonio, Texas

Base Document:C802.16g-04/08r1

Purpose:This presentation outlines an architecture for developing protocol neutral network management standards

Notice:This document has been prepared to assist IEEE 802.16. It is offered 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.

Release:The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standardspublication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others toreproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16.

IEEE 802.16 Patent Policy:The contributor is familiar with the IEEE 802.16 Patent Policy and Procedures <http://ieee802.org/16/ipr/patents/policy.html>, including the statement "IEEE standards may include theknown use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with bothmandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibilityfor delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <mailto:chair@wirelessman.org> asearly as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE802.16 Working Group. The Chair will disclose this notification via the IEEE 802.16 web site <http://ieee802.org/16/ipr/patents/notices>.

Operators

2 types of likely IEEE 802.16 Operators1. Incumbent Wireless

• The operators already have at least one type ofwireless technology e.g. cellular, 802.16a, DVB, etc.

2. New Wireless, Incumbent Wired• These operators have networks but are adding new

wireless access nodes such as IEEE802.16

Operators will desire a single system tomanage their different networks

AP AP

LMA SGSN SGSN

GGSN

BTS BTS BTS BTS

FA FA

FA

IMS

PSTN / SS7

GMSC

DVB-GW

AP DVB-TX

WLAN / WiMAX DVB / ISDB-T GPRS/UMTS Data

Cellular Voice

IPv4 MS

HA

AP

MSC LMA

IPv6 MS + CCoA

AP

IPv4 MS + CCoA

PDG

ESS ESS

RNC/BSC RNC/BSC

RNC/BSC

Architectural View of Management Systems

• Contextual view– This view describes why

• Conceptual view– This view describes what functions are needed

• Logical view– This view describes how functional realization of what is needed

Physical viewPhysical view

Logical viewLogical view

Conceptual viewConceptual view

Contextual viewContextual view

Bus

ines

s as

pect

ar

ea

Bus

ines

s as

pect

ar

eaIn

form

atio

n as

pect

ar

ea

Info

rmat

ion

aspe

ct

area

Info

rmat

ion

syst

em a

spec

t

area

Info

rmat

ion

syst

em a

spec

t

area

Secu

rity

aspe

ct

area

Secu

rity

aspe

ct

area

What?

How?

With what?

Requirements

LZBA 506 477

Physical viewPhysical view

Logical viewLogical view

Conceptual viewConceptual view

Contextual viewContextual view

Bus

ines

s as

pect

ar

ea

Bus

ines

s as

pect

ar

eaIn

form

atio

n as

pect

ar

ea

Info

rmat

ion

aspe

ct

area

Info

rmat

ion

syst

em a

spec

t

area

Info

rmat

ion

syst

em a

spec

t ar

eaSe

curit

y as

pect

area

Secu

rity

aspe

ct a

rea

What?

How?

With what?

Requirements

Conceptual View of the Management Plane

In the management plane we can subdivide theorganizational part into three distant stratums that802.16 access networks will have to interoperate

with

CPE /NetworkCustomer

Access control network

Access network

Service Plane

Control Plane

Core network (s)

Core control network (s)

NGN service

Transport Plane

Management Plane

Access network

Advantages of this Architectural Approach1. Hide complexity

– By decoupling specification from implementation, the attention can be put on onesubject independent from the other. Using this approach, the “what” problem canbe solved without having to define “how” the eventual implementation will bedone.

2. Enhance reuse– Because of the reduction in complexity it will be easier to get a clear picture of

the overall functionality. The overall functionality can then easier be separatedinto potential reusable parts. As a result, reuse of existing parts will becomeeasier.

3. Increase flexibility– Separation of functional areas allows for more flexibility. The implementation of

the functionality can be modified (provided that the functionality itself does notchange) without having any impact on applications that are dependent on thefunctionality. By modifying one part at a time, migrations to new technicalstandards can be achieved step-by-step.

4. Isolate changes– By separating specification from implementation, the implementer is able to

change the implementation with minimal impact on other users/organizations.

Types of Network Management Interfaces

Organization A

Enterprise Systems

EM

2

2

4

311

3

EM

21

UM

TS

Op

s S

yste

ms

EM

NMNM4 4

1

NE NENENENE

EM

EM

2

5

6

Organization BOrganization A

Enterprise Systems

4

EM

1

Op

era

tio

ns

Sy

ste

ms

EM

NMNM

NE NENENENE

EM

EM

5

6

EM

1 1 1

2

2 2 2 2

3 3

5

Itf-N

1. between the Network Elements (NEs)and the Element Manager (EM) of asingle broadband wireless network;

2. between the Element Manager (EM)and the Network Manager (NM) of asingle broadband wireless network;

3. between the Network Managers and theEnterprise Systems of a singlebroadband wireless network;

4. between the Network Managers (NMs)of a single broadband wirelessnetwork;

5. between Enterprise Systems &Network Managers of differentbroadband wireless network;

6. between Network Elements (NEs).

NETMANs Focus

Information Reference Point (IRP) ApproachMethodology

1. Top-down, process-driven modeling approach• The process begins with a requirements phase, the aim at this step is to

provide conceptual and use case definitions for a specific interfaceaspect as well as defining subsequent requirements for this IRP.

2. Technology-independent modeling• The second phase of the process is the development of a protocol

independent model of the interface. This protocol independent model isspecified in the IRP Information Service.

3. Standards-based technology-dependent modeling• The third phase of the process is to create one or more interface

technology and protocol dependent models from the Information Servicemodel. This is specified in the IRP Solution Set(s).

Three Types of IRPs

1. Interface IRPs – These typically provide the definitions for IRP operationsand notifications in a network agnostic manner. These enable independentdevelopment as well as reusable across the industry

2. NRM IRPs – providing the definitions for the Network Resources to bemanaged (commonly named "Network Resources IRPs"). These enabletechnology & vendor specific NRM extensions

3. Data Definition IRPs – provide data definitions applicable to specificmanagement aspects to be managed via reusing available Interface IRPs andapplication to NRM IRPs as applicable. These enable a wide applicability,phased introduction capabilities & broad industry adoption.

Solution Set Definitions (other/future e.g. SNMP, SOAP, HTTP, JAVA, etc.)

Requirements / Use Cases

IS Definition (UML)

Solution Set Definitions (CORBA, XML, CMIP)

Relative stable over long

period of time

Changes with new/better

Technologies

Changes only with respect to addition

and extensions

Interface IRP’s • Notification IRP • Alarm IRP • BulkCM IRP • KernelCM IRP • BasicCM IRP • etc

NRM IRP’s • Generic NRM • CoreNW NRM • UMTS NRM’s • CDMA NRM’s • Inventory NRM • etc

Data Definition IRP’s • State Management IRP • etc

IRP’s FOR APPLICATION INTEGRATION

· Alarm Management· Configuration Management· Performance Management· State Management· Inventory Management· Test Management· Log Management· Security Management· Subscription Management

Network Inventory

Management

Network Maintenance & Restoration

Network Data Management

PSA = Product Specific Application

NE = Network Element

FM IRPs(Alarm ,Test..)

PM IRPs

Network Manager

NE

Element Manager

PSAPSA

NE

Element Manager

PSAPSA

PSAPSA

NE

Element Manager

PSAPSA

PSAPSA

NE

Element Manager

PSAPSA

PSAPSA

Network Provisioning

CM IRPs(Bulk, Inventory,

State ….)

Network Planning &

Development

Service IRPs

Network & System Management Processes

Common IRPs(Notification, File Xfer, Log…)

PSAPSA

PSAPSA

Network Provisioning

CM IRPs(Bulk, Inventory,

State ….)

Network Planning &

Development

Service IRPs

Network & System Management Processes

Common IRPs(Notification, File Xfer, Log…)

Basic CM IRP Information Service (IS)

1. IRP IS specifies a number of protocol-independent operations that areneeded by an IRPManager to retrieve CM information from an IRPAgent aswell as to enable provisioning of network resources

2. Once Defined object definitions can be developed and then mapped to aprotocol

PassiveCmOperations#1

+ getMoAttributes()

<< Interface>>

PassiveCmOperations#2

+ getContainment()

<< Interface>>

ActiveCmOperations

+ createMo()+ deleteMo()+ setMoAttribute()

<< Interface>>

ManagedEntity<<ProxyClass>>

<<may realize>>

<<may realize>>

BasicCmOperations

+ cancelOperation()

<< Interface>>

BasicCmIRP<<InfomationObjectClass>> <<may realize>>

Sample NRM IRP For 802.16f

ManagedElement(from TS32.622)

<<IOC>>

SubNetwork(from TS32.622)

<<IOC>>

0..*

1

0..*

1

ServFlowDb<<IOC>>

0..*

1 <<names>>

<<names>>

1

0..*

WmanBsSystem<<IOC>>

WmanBsPacket<<IOC>>

WmanBsPkm<<IOC>>

WmanBsCps<<IOC>>

WmanSsSystem<<IOC>> WmanSsCps

<<IOC>>

WmanSsPkm<<IOC>>

WmanBsFunction<<IOC>>

0..*

1

0..*

1<<names>>

1

1

1

1

<<names>>1

1

1

1

<<names>>

1

1

1

1

<<names>>

1

1

1

1

<<names>>

WmanSsFunction<<IOC>>

0..*

1

0..*

1<<names>>

1

1

1

1

<<names>> 1

1

1

1

<<names>>

1

1

1

1

<<names>>

0..*11 0..*

CooperationThe NRM describes the specifics of the network to be managed. This

modular approach has enabled different organizations to re-use theInterface IRP’s, and even some of the high-level, network-technology

independent NRM IRP's

Conclusions• The IRP Interface Methodology give a standards developer, vendor,

and operator:– modular, re-usable, protocol neutral NM specifications

• ability to quickly change protocols when necessary,• take technology and adopt into different deployed networks and• have it interoperate seamlessly.

• Advantages– Hide complexity– Enhance reuse– Increase flexibility– Isolate changes

• Implementers of the network management systems will have thechoice as to whether they desire to use SNMP, XML, SOAP, HTTP,CORBA, JAVA, etc. based on their particular need.

• The benefit to developers of both the systems and the standards arethat as protocols are revised the information contained in a standardwould not need to concurrently updated and revised.