Analysis of NGMN Requirements REQ 8 OSS Standard

Analysis of NGMN Requirements REQ 8: OSS Standard Itf-N 1

Specifications Related 3 GPP SA 5 specifications • IRP Methodology specification 32. 15 x • All Interface IRPs and NRM IRPs defined in 3 GPP SA 5 2

IRP Concept – Build to last … and to cope with change 3

IRP Development Principles • NRM IRP Extendibility q q q • vs. Data. Container Rule-based NRM Extensions (e. g. Sub-classing) Enabling: Technology & vendor specific NRM extensions (e. g. 3 GPP 2 NRM’s are technology-specific NRM extensions !!) Interface IRP Flexibility q q q Flexible use of qualifiers “mandatory” and “optional” for operations, notifications and/or parameters allows for simple as well as feature-rich implementations NRM/Technology-neutrality & avoidance of competing procedures Enabling: wide applicability, phased introduction capabilities & broad industry adoption (not just for wireless !!) 4

OSS Standard Itf-N Requirements Existing 3 GPP Standards Status Plug & Play: It must be possible to implement the interfaces between Network and OSS systems easy and efficient by lowest costs and smallest effort (ideally without any development and/or configuration). SA 5 IRPs are fully standardized an allow Plug & Play to the extent possible. It would help the industry if ISVs would get more involved in the work. Useful: It must deliver efficient support for the OSS business processes. The interface must deliver the needed OSS semantics to support the process. IRPs have been designed to deliver the information on the Itf-N. In case anything is missing it is possible to extend IRP’s. Re-useable / Generic: The interface must be generic enough, to enable the re-use in different integration/business scenarios. Interface IRPs are clearly separated from NRM IRPs. Interface IRPs are generic, and therefore reusable to a high degree. Flexible / Extensible: It must be possible to extend the interface capabilities (methods and attributes), without breaking the standard. Mechanisms to add vendor specific extensions to resource models are specified. Interface IRP usage is highly flexible as defined containing necessary mandatory capabilities, while allowing usage of additional optional features Standardized / Open: The interface has to be based on unambiguously standardized specification, which does not allow room for interpretation. The specification and related artifacts must be freely available and useable for everybody. SA 5 IRPs are fully standardized up to the syntax going over the wire. Specifications are available without any restriction. Mature / Stable: The interface must be stable and mature, to avoid expensive changes on implemented interfaces. The majority of the Interface IRPs are mature and stable since several 3 GPP releases De-coupled: Changes in the application or in the interface implementation at one of the communication partners may not lead to the need for changes in the application or in the interface implementation of the other communication partners. The business logic of applications is always independent from the interface as such. More clarification needed for the requirement wrt interface changes. 5

OSS Standard Itf-N Requirements Existing 3 GPP Standards Status Evolutionary: OSS interface shall re-use already existing, widely adopted and mature IT standards (e. g. transport protocols) to avoid “reinventing the wheel”. IRPs use CORBA, SOAP and XML. Independent: The interface specification must be independent from underlying infrastructure. Needs more clarification … but by separating the IS definitions (IF semantics & behavior) from SS definitions (syntax), there is a high degree of independence, and new protocol technologies can be adopted easily, w/o changes to applications Upward-/Downward Compatibility: It must be possible to implement a new version of an interface specification at one of the communication partners, while the other communication partners still use an old version of the interface specification. It is an implementation choice if the IRPManager or IRPAgent supports multiple versions. Nevertheless there is a communication mechanism to retrieve information about what IRP versions are supported by an IRPAgent. Interoperability: The interface implementation shall be based on an interoperable portfolio of interfaces / interface specifications to support different OSS business processes using a common architecture and a common information model. Different Interface and NRM IRPs are available for different business needs. They can be freely combined to cope with any business processes. Scalability: No performance constraints caused by the interface specification or the implementation. IRPs are based on standard IT technology Security: The interface has to be able to ensure confidentiality and availability of the data, which is transferred by the interface. SOAP Solution Sets are based on standard WS, and WS-I Basic Security Profile 1. 0 can be used. See also TS 32. 37 x specification for related security concepts, services & solutions Reliability / Integrity: The interface implementation has to ensure the reliability and the integrity of the data, which is transferred by the interface. CORBA SS is based on OMG specifications. SOAP SS are based on standard WS, and WS-I Basic Security Profile 1. 0 can be used. Adopted & Verified: Widely adopted and verified, so that every vendor supports it. Accepted by 3 GPP community, and adopted by 3 GPP 2 community (considered by Wi. MAX). More involvement of ISVs would be beneficial. 6

Conclusion • 3 GPP SA 5 Interface IRPs and NRM IRPs meet all requirements specified 7