Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 90: OSS Quality of Service API

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original JSR.


Maintenance Lead: Srinivasa Samudrala

E-mail Address:

Telephone Number: +1 817 245 6056

Fax Number: +1 817 245 8113


Maintenance Lead: David Raymer

E-mail Address:

Telephone Number: +1 817 245 6834

Fax Number: +46 31 747 2942

Specification Lead: Stefan Aberg, Ericsson
Rick Porter, Telcordia

E-mail Address:

Telephone Number: +46 31 747 1997
+1 973 829 4490

Fax Number: +46 31 747 2942

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Ericsson

Name of Contact Person: Stefan Aberg

E-mail Address:

Telephone Number: +46 31 747 1997

Fax Number: +46 31 747 2942

NOTE: this section has been updated from the original submission.

Specification Lead: Stefan Aberg

E-mail Address:

Telephone Number: +46 31 747 1997

Fax Number: +46 31 747 2942

Co-Submitting Member: Telcordia

Name of Contact Person: Rick Porter

E-mail Address:

Telephone Number: +1 973 829 4490

Fax Number: +1 973 829 5981

Co-Submitting Member: Nokia

Name of Contact Person: Stefan Vaillant

E-mail Address:

Telephone Number: +49 211 9412 3973

Fax Number: +49 211 9412 3988

Co-Submitting Member: Nortel Networks

Name of Contact Person: Colin Ashford

E-mail Address:

Telephone Number: +1 613 765 4929

Fax Number: +1 613 765 7387

Co-Submitting Member: NEC

Name of Contact Person: Hiroya Kawata

E-mail Address:

Telephone Number: +81 45 939 2450

Fax Number: +81 45 939 2487

Co-Submitting Member: Motorola

Name of Contact Person: Frank Korinek

E-mail Address:

Telephone Number: +1 847 576 1643

Fax Number: +1 847 538 5564

Co-Submitting Member: Sun Microsystems

Name of Contact Person: Philippe Goujard

E-mail Address:

Telephone Number: +44 1276 689 414

Fax Number: +44 1276 677 121

Co-Submitting Member: CrossKeys

Name of Contact Person: Melody Fallah-Khair

E-mail Address:

Telephone Number: +1 613 591 1600

Fax Number: +1 613 599 2320

Co-Submitting Member: Infovista

Name of Contact Person: Benjamin Har

E-mail Address:

Telephone Number: +65 2402608

Fax Number: +65 449 3054

NOTE: this section has been updated from the original submission.

Initial Expert Group Membership

  • Ericsson
  • Telcordia
  • Nokia
  • Nortel
  • NEC
  • Sun Microsystems
  • CrossKeys
  • InfoVista
  • Cisco
  • Motorola

Section 2: Request

2.1 Please describe the proposed Specification:

In Operation Support Systems (OSS), the area of Quality of Service (QoS) is vast and complete standards or even de-facto standards in this area are lacking. Several products manage specific parts of Quality of Service. They can be integrated into an end-to-end solution, but these custom integrated solutions are tremendously complex and difficult to achieve, due to the lack of integration standards.

Therefore, the ability to reduce the integration effort via a set of standard, reusable software components to assemble OSS applications in a much shorter time is an appealing prospect for all players in the OSS marketplace.

The OSS Quality of Service API specification will define an API that enables construction of total OSS solutions for QoS by assembling commercial-of-the-shelf components.

QoS definition

The ITU-T E.800 recommendation defines QoS and areas that affect the QoS. This recommendation describes factors that contribute collectively to the overall quality of service as perceived by the user of a telecommunication service.

The users degree of satisfaction of the quality of service can be divided into four service performance areas:

  • support;
  • operability;
  • serveability;
  • security.

API positioning

Service providers that offer services with a guaranteed quality require management systems that can retrieve, calculate and present QoS data from the four performance areas. These management systems have to control the Service Level Agreements (SLA), between the customers and the service provider, and react on service quality violations according to business rules. Today there exist products to manage this, but no standards or de-facto standards exist to facilitate the integration of a QoS management system with other management systems such as mediation, billing and service activation as part of a total management solution.

To make it easier to develop and integrate total solutions for QoS a number of interfaces must be agreed upon. These interfaces will be defined within the OSS QoS API specification. QoS solutions require the specification of many interfaces. The first priority of the OSS QoS API specification is the network-facing API. The network-facing QoS API will interface sub-network managers and/or element management systems that provide QoS information.

As an example, the OSS QoS API is used (called) by SLA applications and implemented by performance management products.

If the OSS QoS API is implemented by the previously mentioned products, system integrators and service providers can buy products from different sources and integrate them with no or minimal effort to build an end-to-end OSS solution for QoS.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target platform is Java 2 Platform, Enterprise Edition.

2.3 What need of the Java community will be addressed by the proposed specification?

A number of software developers in the telecommunication industry are already using EJB components for their next-generation OSS software. Without some standardization conventions for these components, the industry runs the risk of proliferating similar components with slightly different APIs. Hence, standardizing these component APIs through a Java community process is an attractive proposition.

2.4 Why isn't this need met by existing specifications?

Currently, no existing Java platform specification provides a standard API for OSS components. Existing APIs are generally vendor-proprietary.

2.5 Please give a short description of the underlying technology or technologies:

The purpose of the OSS QoS API specification is to define a standard QoS API for Telecom Management applications, as described above. The API is considered to be independent of the network technology and will utilise existing standards as much as possible. The following standard bodies will be considered when the API is defined and others may be added:

  • 3GPP
  • ITU
  • TMF

The OSS QoS API will be defined on top of J2EE. The most important J2EE APIs for this JCP will be the following:

  • EJB (Enterprise JavaBeans):
    To facilitate the integration of OSS components, OSS will define standard EJB interfaces.
  • JMS (Java Message Service):
    Besides the ability to execute synchronous (EJB) methods calls, there is also a need to send asynchronous messages. For this, JMS is being considered to be most viable.
  • JNDI (Java Naming and Directory Interface):
    The specification will include standards for JNDI names.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The API will have one or several packages and the prefix for all packages is "javax.oss". The remaining part of the package name will be defined according to a logical name for different parts of the API. Following are some proposals of names:

  • javax.oss.qos

The prefix "javax.oss" will be used in all OSS JSRs, including those recently submitted, namely:, "OSS Trouble Ticket API" and "OSS Service Activation API". Package names of all OSS JSRs will be co-ordinated to avoid ambiguous use.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

The specification has no dependency to operating systems, CPUs, or I/O devices.

2.8 Are there any security issues that cannot be addressed by the current security model?

None anticipated.

2.9 Are there any internationalization or localization issues?

None anticipated.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

The OSS Quality of Service API specification will addresses how Quality of Service data shall be transported between OSS applications. The traditional way of transporting this data is either with notifications or by using FTAM or (T)FTP protocols. In the OSS QoS API we need to define how this data shall be transported and JMS is one potential mechanism. Dependent on the design choices in the OSS Quality of Service API and the scalability of the available techniques, we may require revisions of some specifications. However, no limitations are currently known.

2.11 Please describe the anticipated schedule for the development of this specification.

The expected schedule for this specification is about 9 months and the major milestones in the project are listed below:

  • Spec Community Draft: 02.2001
  • Spec Public Draft: 03.2001
  • Spec Proposed Final Draft: 05.2001
  • Spec Final Release: 06.2001

These are subject for change based on the defined feature set.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The 3GPP ( has developed standards for 3G telecom networks. These recommendations can be retrieved from 3GPP web site.

The TMF ( has developed standards for Telecom Management. These recommendations can be retrieved from TMF web site.

The ITU-T ( has developed standards concerning QoS. The Q.800 and the X.700 recommendation and subsequent recommendations have some relevant information. These recommendations can be bought from ITU-T web site.

3.2 Explanation of how these items might be used as a starting point for the work.

In the area of Quality of Service, there are no standards that can be used directly as a basis for the Java API. However, some existing standards should guide the development and provide a framework for the functional objectives of the API.

From 3GPP, we will take into account the following documents:

  • 3G Telecom Management architecture, 3G TS 32.102,
  • 3G Telecom Management principles and high level requirements, 3G TS 32.101,
  • 3G Performance Management, 3G TS 32.104,
  • 3G Charging and Billing, 3G TS 32.015,
  • 3G Fault Management, 3G TS 32.111 and
  • 3G Configuration Management, 3G TS 32.106-5.

TMF have several documents that will be considered:

  • Telecom Operation Map (TOM) GB910,
  • Performance Reporting Concepts & Definitions TMF 701,
  • SLA Management Catalyst Project Interface Implementation Specification TMF 804,
  • Service Quality Management for IMT 2000 Catalyst Interface Implementation Specification TMF 803,
  • Service Provider To Customer Performance Business Agreement NMF 503 and
  • System Integration Map (SIM) GB914.

From ITU, we will take into account the following documents:

  • Quality of Service, Network Management and Traffic Engineering, E.800,
  • Definition of Management Information, X.721,
  • Data Networks and Open System communications OSI management, X.739 and
  • Performance Management, Q.822.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

The OSS QoS API needs to be defined by experts with different experiences. Experts are required in the following areas: Traditional PM, Probe, Billing mediation, IP standards for QoS, 3G standards for QoS, ISV applications (user of the API), EMS applications (provider of the API), J2EE.