 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 90: OSS Quality of Service API
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 2.0 Description: Provide an API that allows telecom management applications to be developed and integrated with Java-enabled Quality of Service systems. Please direct comments on this JSR to the Spec Lead(s) Team
Updates to the Original Java Specification Request (JSR) The following information has been updated from the original JSR. 2005.11.29: Maintenance Lead: Srinivasa Samudrala E-mail Address: srini.samudrala Telephone Number: +1 817 245 6056 Fax Number: +1 817 245 8113 2004.05.25:Maintenance Lead: David Raymer E-mail Address: david.raymer Telephone Number: +1 817 245 6834 Fax Number: +46 31 747 2942 Specification Lead: Stefan Aberg, Ericsson E-mail Address: stefan.aberg Telephone Number: +46 31 747 1997 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: stefan.aberg Telephone Number: +46 31 747 1997 Fax Number: +46 31 747 2942 Specification Lead: Stefan Aberg E-mail Address: stefan.aberg 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: fdpo 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: stefan.vaillant 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: ashford 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: h-kawata 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: Frank.Korinek 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: Philippe.Goujard 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: mkhair 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: bhar Telephone Number: +65 2402608 Fax Number: +65 449 3054 NOTE: this section has been updated from the original submission.Initial Expert Group Membership
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. 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:
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:
The OSS QoS API will be defined on top of J2EE. The most important J2EE APIs for this JCP will be the following:
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:
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:
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 (http://www.3gpp.org) has developed standards for 3G telecom networks. These recommendations can be retrieved from 3GPP web site. The TMF (http://www.tmforum.org) has developed standards for Telecom Management. These recommendations can be retrieved from TMF web site. The ITU-T (http://www.itu.int) 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:
TMF have several documents that will be considered:
From ITU, we will take into account the following documents:
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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
