ieee p802.16g broadband wirelessaccess working group … · an architecture to develop network...
TRANSCRIPT
2005-09-09 IEEE C802.16g-05/042
An Architecture to Develop Network ManagementStandards
Abstract: IEEE802.16 networks are likely to be deployed by operators who already ownand operate other (wireline and wireless) telecommunications networks. This results in amulti-access network or ‘heterogeneous’ network environments. In heterogeneousnetworks depending on the vendor, type of network, or level of software employed by anoperator, different network management protocols could be employed. Therefore, thedevelopment of protocol neutral information for network management is the consideredthe best approach to specifying network management systems. While SNMP is still
1
Project IEEE P802.16g Broadband Wireless Access Working Group <http://ieee802.org/16>Title AnArchitecture to Develop Network Management StandardsDateSubmitted
9 September 2005
Source(s) Scott F. MigaldiJörg SchmidtMichael Truss
Tel:+1.847.576.0574, [email protected]:+1.480.732.6493, [email protected]:+353(0)214511327, [email protected]
Re: Call for contributionsAbstract A protocol neutral approach to the development of Network Management standardsPurpose In light of the potential new PAR for Network Management and the task to create a Mobile MIB it is
appropriate to review this previously accepted contribution.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 this document is subject tochange in form and content after further study. The contributor(s) reserve(s) the right to add, amend orwithdraw material contained herein.
Release The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in thiscontribution, and any modifications thereof, in the creation of an IEEE Standards publication; tocopyright in the IEEE’s name any IEEE Standards publication even though it may include portions ofthis contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part theresulting IEEE Standards publication. The contributor also acknowledges and accepts that thiscontribution may be made public by IEEE 802.16.
Patent PolicyandProcedures
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 thepatent holder or applicant with respect to patents essential for compliance with both mandatory andoptional portions of the standard." Early disclosure to the Working Group of patent information thatmight be relevant to the standard is essential to reduce the possibility for delays in the developmentprocess and increase the likelihood that the draft publication will be approved for publication. Pleasenotify the Chair <mailto:[email protected]> as early as possible, in written or electronic form, ifpatented technology (or technology under patent application) might be incorporated into a draft standardbeing developed within the IEEE 802.16 Working Group. The Chair will disclose this notification via theIEEE 802.16 web site<http://ieee802.org/16/ipr/patents/notices>.
2005-09-09 IEEE C802.16g-05/042
utilized by some operators it is a protocol that has limited capabilities and lacks thegranularity of some newer protocols, in some cases requires pre-configuration of thenetwork entities. If a protocol neutral approach is used, the implementer of the networkmanagement system has the choice as to whether they desire to use SNMP, XML, SOAP,HTTP, CORBA, JAVA, etc. based on their particular need. Furthermore, the operatorfinds protocol neutral network management interfaces easier to integrate with theiralready existing networks. The benefit to both systems developers and standards writersis that as new protocols are added the protocol neutral part of the standard would notneed to be updated and revised.
1. INTRODUCTION
Current operators with legacy as well as 802.16 access networks to manage will want a single, integratedmanagement system. This integrated network management system is one of several steps required toestablish viable business models for new services and capabilities. Management Interfaces in 2G/3Gcellular systems have been developed to achieve this based on well-established TMN principles. Vendorsand operators agreed that the most immediate opportunities and benefits for standardization existed onthe interfaces between Network Managers (NM) and Element Managers (EM). This interface, labelledItf-N for Network Management, has been the focus of initial standardization activities in cellularstandards. Many perceive the initial deployments to be stand-alone data networks. One reality that hasbeen identified by industry groups such as the Wireless Data Research Group is that “cell-phonecompanies could use WiMax to "backhaul" their wireless Internet service from a cell tower to a centraloffice”1. Furthermore, the WiMax Forum has stated “in a metro area, it is desirable to install a sufficientnumber of base stations to cover an addressable market large enough to quickly recover the fixedinfrastructure costs.”2 To achieve this, operators will face the issue of real-estate for base station andantenna or tower locations, the leading cost in any new wireless deployment. Since current wirelessoperators already have acquired and zoning approved location for base stations, it is very likely that theywill be the first to market in metro areas. Current wireline operators are also likely to add a wireless tailto their data networks to enter the lucrative wireless business, that tail could be 802.16. When either orboth of these scenarios occurs the current operator will desire a single system to manage the differentnetworks. Figure 1 illustrates an example of the mixed or “heterogeneous” network that can result. Theexample in the Figure incorporates cellular voice, cellular data, broadcast, and IEEE 802 Wi-Fi andWiMax technologies. This single network management system is of several required steps to establishviable business models for new services and capabilities.
1 From http://www.rockymountainnews.com/drmn/technology/article/0,1299,DRMN_49_3080674,00.html2WiMax Forum, ‘Business Case Models for Fixed Broadband Wireless Access based on WiMAX Technology and the 802.16Standard’, October 10, 2004 page 11
2
2005-09-09 IEEE C802.16g-05/042
APAP
LMA SGSN SGSN
GGSN
BTSBTS BTSBTS
FA FA
FA
IMS
PSTN /SS7
GMSC
DVB-GW
AP DVB-TX
WLAN /WiMAX DVB / ISDB-T GPRS/UMTSData
CellularVoice
IPv4 MS
HA
AP
MSCLMA
IPv6 MS+ CCoA
AP
IPv4 MS+ CCoA
PDG
ESS ESS
RNC/BSC RNC/BSC
RNC/BSC
Figure 1. Example of a Heterogeneous Network
Management interfaces other than Itf-N have not been ignored by cellular SDOs but they are most likelyout of the scope of 802.16NETMAN. These other interfaces have been labelled and categorized for youreference (see Figure 3 from [1]).It is not the approach to define the complete management of all the technologies that might be used in theprovision of a broadband wireless network. It is, however, the intention to identify and define what willbe needed from the perspective of management. Figure 2. also does not imply any physical architecturein the routing of management information.
3
2005-09-09 IEEE C802.16g-05/042
Organization A
Enterprise Systems
EM
2
2
4
311
3
EM
21
UMTSOpsSystems
EM
NMNM4 4
1
NE NENENENE
EM
EM
2
5
6
Organization BOrganization A
Enterprise Systems
4
EM
1
OperationsSystems
EM
NMNM
NE NENENENE
EM
EM
5
6
EM
1 1 1
2
2 2 2 2
3 3
5
Itf-N
Figure 2: Management Interfaces and Information Architecture
A number of management interfaces in a broadband wireless network are identified in figure 2, namely:1. between the Network Elements (NEs) and the Element Manager (EM) of a single broadbandwireless network;
2. between the Element Manager (EM) and the Network Manager (NM) of a single broadbandwireless network;
NOTE: In certain cases the Element Manager functionality may reside in the NE in which casethis interface is directly from NE to Network Manager). These management interfaces are alsogiven the reference name Itf-N.
3. between the Network Managers and the Enterprise Systems of a single broadband wirelessnetwork;
4. between the Network Managers (NMs) of a single broadband wireless network;5. between Enterprise Systems & Network Managers of different broadband wireless network;6. between Network Elements (NEs).
2. INTEGRATION REFERENCE POINTS (IRP)
For the purpose of Management Interface development an Interface Methodology known asIntegration Reference Point (IRP) was developed to promote the wider adoption of standardizedManagement interfaces in telecommunication networks. The IRP methodology employs Protocol& Technology Neutral modeling methods as well as protocol specific solution sets to helpachieve its goals. The Integration Reference Point is a methodology to aid a modular approach tothe development of standards interfaces.
There are three cornerstones to the IRP approach:
1. Top-down, process-driven modeling approachThe process begins with a requirements phase, the aim at this step is to provide
4
2005-09-09 IEEE C802.16g-05/042
conceptual and use case definitions for a specific interface aspect as well as definingsubsequent requirements for this IRP.
2. Technology-independent modelingThe second phase of the process is the development of a protocol independent model ofthe interface. This protocol independent model is specified in the IRP InformationService.
3. Standards-based technology-dependent modelingThe third phase of the process is to create one or more interface technology and protocoldependent models from the Information Service model. This is specified in the IRPSolution Set(s).
This modular three-step approach is depicted in figure 2, which also outlines some further detailsand advantages of the IRP approach.
SolutionSet Definitions (other/future e.g. SNMP, SOAP,HTTP,JAVA, etc.)
Requirements / Use Cases
ISDefinition (UML)
SolutionSet Definitions (CORBA,XML,CMIP)
Relative stableover long
period of time
Changeswithnew/ betterTechnologies
Changes onlywi threspect to additionand extensions
InterfaceIRP’s• Notification IRP• Alarm IRP• BulkCM IRP• KernelCM IRP• BasicCM IRP• etc
NRMIRP’s• GenericNRM• CoreNWNRM• UMTSNRM’s• CDMANRM’s• InventoryNRM• etc
DataDefinitionIRP’s• State Management IRP• etc
Figure 3: The IRPApproach
IRP Types: Figure 3 shows that at the Information Service modeling stage IRP’s are categorizedinto one of three types:
Interface IRPs – These typically provide the definitions for IRP operations andnotifications in a network agnostic manner. These enable independent development aswell as reusable across the industryNRM IRPs – providing the definitions for the Network Resources to be managed(commonly named "Network Resources IRPs"). These enable technology & vendorspecific NRM extensionsData Definition IRPs – provide data definitions applicable to specific managementaspects to be managed via reusing available Interface IRPs and application to NRM IRPsas applicable. These enable a wide applicability, phased introduction capabilities & broadindustry adoption.
5
2005-09-09 IEEE C802.16g-05/042
IRP Advantages: The modular aspect of the IRP approach divides the Interface specificationinto pieces that are:
Relatively stable typically over long periods of time (the requirements).
Change more frequently but normally limited to additions and extensions of the Model(the information Service)Change frequently as new and better interface technologies become available
IRP Development Principles: For the purpose of making the IRP-based management interfacesopen for wide-spread adoption, the following principles were adopted:
NRM IRP Extendibility: through adoption of the vs. DataContainer construct as well asrule-based NRM ExtensionsInterface IRP Flexibility: through NRM/Technology-neutrality as well as the flexible useof qualifiers (mandatory, optional, visibility) for operation, notifications and/orparameters
The development of IRP’s is supported by the availability of an IRP IS Template, as well as anUML Repertoire, both defined in 32.102 [2].
3. IRP’s FORAPPLICATION INTEGRATION
The IRP specifications and solution sets that have been developed or are under development by otherSDOs cover a broad variety of Network and Service Management function, for example:
Alarm Management
Configuration Management
Performance Management
State Management
Inventory Management
Test Management
Log Management
Security Management
Subscription Management
Solutions sets currently available cover CORBA, XML and CMIP technologies, though expansion intofor example SNMP or JAVA solution sets is also possible, these could be discussed and may developsubject to contribution and participation by interested organizations in 802.16NETMAN. See Annex Afor a more complete listing and categorization.
On a macro view of a network the IRPs are developed to ensure interoperability between Product-Specific Applications (PSA) and the Network & System Management Processes of the Network Manageras shown conceptually in Figure 4. Although for the purposes of the work in 802.6NETMAN the focuswould be on those parts of the process that focus on communication between the element manager andthe network element. But this diagram shows why an approach that is interoperable to other management
6
2005-09-09 IEEE C802.16g-05/042
standards is important.
NetworkInventory
Management
NetworkMaintenance& Restoration
Network DataManagement
PSA = Product Specific Application
NE = Network Element
FM IRPs(Alarm ,Test..)
PM IRPs
Network Manager
NE
Element Manager
PSAPSA
NE
Element Manager
PSAPSAPSA
PSA
NE
Element Manager
PSAPSAPSA
PSA
NE
Element Manager
PSAPSAPSA
PSA
NetworkProvisioning
CM IRPs(Bulk, Inventory,
State ….)
NetworkPlanning &Development
ServiceIRPs
Network & System Management Processes
Common IRPs(Notification, FileXfer, Log…)
PSAPSAPSA
PSA
NetworkProvisioning
CM IRPs(Bulk, Inventory,
State ….)
NetworkPlanning &Development
ServiceIRPs
Network & System Management Processes
Common IRPs(Notification, FileXfer, Log…)
Figure 4: IRPs for Application Integration
4. AN INTERFACE IRP EXAMPLE
To more fully explain how the IRP works in application this section, by way of example and illustration,will show the how the IRP Methodology is applied to the Basic Configuration Management IRP. TheBasic Configuration Management IRP is an Interface IRP and consists of a requirements part, an ISdefinition part and currently two Solution Sets, the CORBA SS and the CMIP SS.
Basic CM IRP IS: The IRP Information Service [3] specifies a number of protocol-independentoperations that are needed by an IRPManager to retrieve CM information from an IRPAgent as well as toenable provisioning of network resources (note that related CM notifications are provided by another IRP,namely the Kernel CM IRP).
7
2005-09-09 IEEE C802.16g-05/042
Pass iveCmOperations#1
+ getMoAttributes()
<< Interface>>
Pass iveCmOperations#2
+ getContainment()
<< Interface>>
ActiveCmOperations
+ createMo()+ deleteMo()+ setMoAttribute()
<< Interface>>
ManagedEntity<<ProxyClass>>
<<may realize>>
<<may realize>>
BasicCmOperations
+ cancelOperation()
<< Interface>>
BasicCm IRP<<InfomationObjectClass>> <<may realize>>
Figure 5: Basic CM IRP Operations
Figure 5 shows how the operations of the Basic Configuration Management IRP are modeled using UMLnotations as defined in the IRP UML Repertoire [2].The information service specification goes on to detail each of the operations in detail in a tabular formatlisting input and output parameters, pre and post conditions and exceptions – based on the IRP ISTemplate defined in 32.102 [2].
The generic rules for CM IRP operations that are defined in IRP Information Service [3] are:
Rule 1: Each operation with at least one input parameter supports a pre-conditionvalid_input_parameter which indicates that all input parameters shall be valid with regards totheir information type. Additionally, each such operation supports an exceptionoperation_failed_invalid_input_parameter which is raised when pre-conditionvalid_input_parameter is false. The exception has the same entry and exit state.
Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditionssupported_optional_input_parameter_xxx where "xxx" is the name of the optional inputparameter and the pre-condition indicates that the operation supports the named optional inputparameter. Additionally, each such operation supports an exceptionoperation_failed_unsupported_optional_input_parameter_xxx which is raised when (a) the pre-condition supported_optional_input_parameter_xxx is false and (b) the named optional inputparameter is carrying information. The exception has the same entry and exit state.
Rule 3: Each operation shall support a generic exception operation_failed_internal_problem that
8
2005-09-09 IEEE C802.16g-05/042
is raised when an internal problem occurs and that the operation cannot be completed. Theexception has the same entry and exit state.
Basic CM IRP SS: The Solution Sets will implement the Basic CM IRP IS operations by mapping themto standard operations that are applicable in the corresponding protocol environment.A CMIP Solution Set will for instance map the operations to the more generic operations defined inCMIS, a CORBA Solution Set [4] will map the operations to applicable OMG/CORBA services, and apotential SNMP Solution Set would map the operations to applicable SNMP operations.
5. AN NRM IRP EXAMPLE
In this section we will by way of example and illustration of the IRP Methodology take a closer look atthe Core Network NRM IRP. This IRP is an NRM IRP and consists, as all IRP’s, of a requirements part,an IS definition part and currently two Solution Sets, the CORBA SS and the CMIP SS.
Core Network NRM IRP IS: The Basic CM Interface IRP described above specifies the operationsneeded by an IRPManager to retrieve information from an IRPAgent as well as to provision networkresources. These operations are generic across all network types and so have been separated from the datamodel to which the operations are applied, however various Network Resource Models are required tomodel the information to be operated upon, A typical example of such a resource model specified by3GPP SA5 is the Core Network (CN) Network Resource Model [5].
9
2005-09-09 IEEE C802.16g-05/042
ManagedElement(from 32.622)
0..*
ALink
0..*
BssFunction(from 32.652)
0..1
ConnectedTo
ExternalGSMCell
0..1
0..*
Associatedwith
+MscFunction-ExternalGSMCell
+ExternalGSMCell-MscFunction
+ConnectedBss
ExternalBssFunction
+ConnectedBss 0..1
ConnectedTo
(from 32.652)
IucsLink
0..1+ConnectedBss+ConnectedBss
0..1
ConnectedToConnectedTo
0..10..1 0..1
0..1
MscServerFunction
0..1
CsMgwFunction
ConnectedTo
0..*
0..10..1
(from 32.652)
GSMCell(from 32.652)
0..*
0..1
0..1
Figure 6: Part of the CN-GERAN NRM Containment/Naming and Association diagram
Figure 6 shows how the NRM again uses the IRP UML Repertoire to model the Core Network Entities ina protocol neutral fashion. The NRM specification goes on to detail attributes and notifications associatedwith each of the modeled entities.
10
2005-09-09 IEEE C802.16g-05/042
6. 3GPP/3GPP2 CO-OPERATION
• 3GPP defines standard NBIs
• 3GPP2 re-uses 3GPP’s NBI specifications
• One set of NBI standards for all 2G, 2.5G and3G wireless technologies!
Figure 7: 3GPP/3GPP2 Co-operation
As described in paragraph 4 the IRP specifications are divided mainly into Interface and NetworkResource Model IRPs. The Interface IRPs describe Management operations common across all networks,for example creating, deleting and changing data.
The Network Resource Model (NRM) on the other hand describes the specifics of the network to bemanaged. This modular approach has enabled other organizations such as 3GPP and 3GPP2 (Figure 6) tore-use the Interface IRP’s, and even some of the high-level, network-technology independent NRM IRP's,and extending those models based on set rules to create 3GPP2 NRM IRP’s for their specific needs.
The 802.16NETMAN group could also benefit from this approach by working with both groups toestablish common and unique Interface IRP’s that would be used by a particular NRM.
7. CONCLUSIONS
The IRP Interface Methodology give a standards developer, vendor, and operator through the modular, re-usable and protocol neutral aspects of specifications the ability to quickly change protocols whennecessary, take technology and adopt into different deployed networks and have it interoperateseamlessly.There has also been example on how SDOs may re-use extension of one specifications by another. Thesere-use advantages available by adopting the 3GPP IRP management interface development methodology.Once this is accomplished it is possible to use a protocol neutral approach to develop managementstandards an implementer of the network management systems will have the choice as to whether theydesire to use SNMP, XML, SOAP, HTTP, CORBA, JAVA, etc. based on their particular need. The benefitto developers of both the systems and the standards are that as protocols are revised the informationcontained in a standard would not need to concurrently updated and revised.
11
2005-09-09 IEEE C802.16g-05/042
REFERENCES
Note: All 3GPP specifications are available at www.3gpp.org
[1] 3GPP TS 32.101 Telecommunication management; Principles and high-level requirements
[2] 3GPP TS 32.102 Telecommunication management; Architecture
[3] 3GPP TS 32.602 Telecommunication management; Configuration Management (CM); Basicconfiguration management Integration Reference Point (IRP): information service
[4] 3GPP TS 32.603 Telecommunication management; Configuration Management (CM); Basicconfiguration management Integration Reference Point (IRP): CORBA solution set.
[5] 3GPP TS 32.632 Telecommunication management; Configuration Management (CM); CoreNetwork Resources Integration Reference Point (IRP): Network Resource Model (NRM).
ANNEXA: 3GPP IRP’s
Interface IRP’so Alarm IRP (32.111-x)o Notification IRP (32.30x)o Generic IRP (32.31x)o Test Management IRP (32.32x)o Notification Log IRP (32.33x)o File Transfer IRP (32.34x)o Performance Management IRP (32.41x)o Basic CM IRP (32.60x)o Bulk CM IRP (32.61x)o Kernel CM IRP (32.66x)o Entry Point IRP (32.xxx)
NRM IRP’so Generic NRM IRP (32.62x)o Core Network NRM IRP (32.63x)o UTRAN NRM IRP (32.64x)o GERAN NRM IRP (32.65x)o Inventory NRM IRP (32.69x)o Subscription Management NRM IRP (32.xxx)
Data Definition IRP’so State Management IRP (32.67x)
Note: IRPs in italics above are in the early stages of development.
12
2005-09-09 IEEE C802.16g-05/042
ANNEX B: SOLUTION SET EXTRACT
This Annex shows an extract from a solution set specification [4] showing the mapping from anInformation Service Operation to a solution set method (In this case a CORBA IDL method) as shown inFigure B1
IS Operation(3GPP TS 32.602)
SS Method Qualifier
getIRPVersion get_basicCm_IRP_version McancelOperation BasicCmInformationIterator::destroy OcreateMo BasicCmIrpOperations::create_managed_object OdeleteMo BasicCmIrpOperations::delete_managed_objects OsetMoAttributes BasicCmIrpOperations::modify_managed_objects O
Figure B1: Solution Set Extract - Mapping Table
In figure B2 an extract from the Solution Set CORBA IDL code is shown
13
2005-09-09 IEEE C802.16g-05/042
/*** Performs the creation of a MO instance in the MIB maintained* by the IRPAgent.** @parm objectName: the distinguished name of the MO to create.* @parm referenceObject: the distinguished name of a reference MO.* @parm attributes: in input, initial attribute values for the MO to* create; in output, actual attribute values of the created MO.* @parm attributeErrors: errors, related to attributes, that caused the* creation of the MO to fail.** @raises ManagedGenericIRPSystem::OperationNotSupported: The operation* is not supported.* @raises ManagedGenericIRPSystem::ParameterNotSupported: An optional* parameter is not supported.* @raises ManagedGenericIRPSystem::InvalidParameter: An invalid* parameter value has been provided.* @raises UndefinedMOException: The MO does not exist.* @raises IllegalDNFormatException: The DN syntax string is malformed.* @raises DuplicateMO: A MO already exist with the same DN as the one* to create.* @raises CreateNotAllowed: The creation of the MO is not allowed.* @raises ObjectClassMismatch: The object class of the MO to create does* not match with the object class of the provided reference MO.* @raises NoSuchObjectClass: The class of the object to create is not* recognized.*/void create_managed_object (
in DN objectName,in DN referenceObject,inout MOAttributeSet attributes,out AttributeErrorSeq attributeErrors
)raises (CreateManagedObject,
ManagedGenericIRPSystem::OperationNotSupported,ManagedGenericIRPSystem::ParameterNotSupported,ManagedGenericIRPSystem::InvalidParameter,UndefinedMOException,IllegalDNFormatException,DuplicateMO,CreateNotAllowed,ObjectClassMismatch,
NoSuchObjectClass);
Figure B2: Solution Set Extract - CORBA IDLCode
14