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: [email protected], 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:[email protected]> 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.
Top Related