Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 130: OSS Billing Mediation API

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original JSR.

Specification Lead: James Jouett

E-Mail Address:

Telephone Number: +1 214 262 3214

Fax Number: +1 214 272 3225

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: NEC

Name of Contact Person: Ken Dilbeck

E-Mail Address:

Telephone Number: +1 214 262 3250

Fax Number: +1 214 262 3250

Specification Lead: Ken Dilbeck

E-Mail Address:

Telephone Number: +1 214 262 3250

Fax Number: +1 978 262 3225

NOTE: This information has been updated from the original JSR.

Co-Submitting Member: Ericsson

Name of Contact Person: Lars Tenf?

E-mail Address:

Telephone Number: +46 31 747 1974

Fax Number: tbd

Co-Submitting Member: Motorola

Name of Contact Person: Eric Coleman

E-mail Address:

Telephone Number: +1 480 732 3743

Fax Number: +1 480 732 5117

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: Peter Gorecki

E-mail Address:

Telephone Number: +1 613 765-5165

Fax Number: NA

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: Telcordia Technologies

Name of Contact Person: B.Dasarathy

E-mail Address:

Telephone Number: +1 973 829 5038

Fax Number: +1 973 829 2645

Initial Expert Group Membership:

  • Ericsson
  • Motorola
  • NEC
  • Nokia
  • Nortel Networks
  • Sun Microsystems
  • Telcordia

  • Section 2: Request

    2.1 Please describe the proposed Specification:

    In Operation Support Systems (OSS), the area of IP Billing is vast and complete standards or even de-facto standards in this area are lacking. Several products manage specific parts of Billing. 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 IP Billing API specification will define an API via the OSS through Java initiative that enables construction of total OSS solutions for IP Billing by assembling commercial-of-the-shelf components.

    API positioning

    The OSS IP Billing API will provide an interface between the billing data sources and the billing applications, i.e., the network charging elements, the mediation function and the billing system. The API will provide a standard interface between application components, so different vendors products can be easily combined. The API will therefore simplify data routing between components, for all types of billing records (CDRs, SDRs, IPDRs).

    The OSS IP Billing API will be applicable to data transmission initially and then for voice. It will apply to both 2.5 and 3G networks. The focus for the API will be wireless, but it is not wireless specific.

    As the market place and customer demands change, Service Providers who can quickly roll-out new services and actively bill for them, will find themselves in a very strong and competitive position. Being able to effectively bill for new services may require additional billing applications from one or more vendors. The IP Billing API will help reduce the time to market for these services and provide a faster time to revenue.

    The IP Billing API allows billing ISVs to focus on features and capabilities as discriminators, not integration and compatibility issues. This also allows Network Equipment Providers some measure of compatibility with a standard data format. Data format and protocol translations between equipment vendors are reduced.

    If the OSS IP Billing 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 IP Billing.

    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. Specifically, no IP billing API exists that is defined within the OSS through Java Initiative. Existing APIs are generally vendor-proprietary.

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

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

    • 3GPP & 3GPP2
    • IPDR
    • Parlay
    • TMF

    The OSS IP Billing 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.ipbilling

      The prefix "javax.oss" will be used in all OSS JSRs, including those recently submitted, namely: "OSS Trouble Ticket API", "OSS Service Activation API" and ?Quality of Service API?. Package names of all OSS JSRs will be coordinated 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 IP Billing API specification will address how IP based billing data shall be transported between OSS applications and/or network elements. The traditional way of transporting this data is either with notifications or by using FTAM or (T)FTP protocols. In the OSS IP Billing API we need to define how this data shall be transported. Dependent on the design choices in the OSS IP Billing API and the scalability of the available techniques, we may require revisions of some specifications.

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

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

      • Spec Community Draft: October 2001
      • Spec Public Draft: December 2001
      • Final Draft Proposal: 1st Qtr 2002
      • Final Release: 2nd Qtr 2002

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

      2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.


      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 & 3GPP2 ( & have developed standards for 3G telecom networks. These recommendations can be retrieved from 3GPP & 3GPP2 web sites.

      The IPDR ( has developed standards for data exchange between IP network elements and OSS systems for 3G telecom networks. These recommendations can be retrieved from IPDR web site.

      Parlay ( has developed open APIs that intimately link IT applications with the capabilities of the communications world. The recommendations can be retrieved from Parlay web site.

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

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

      In the area of IP Billing, there may not be standards that can be used directly as a basis for the IP Billing API. However, some existing standards should guide the development and provide a framework for the functional objectives of the API.

      From IPDR, we will take into account at least the following documents:

      • Network Data Management - Usage (NDM-U) for IP-Based Services Version 2.0

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

      • 3G Telecom Management architecture, 3G TS 32.102,
      • 3G Telecom Management principles and high level requirements, 3G TS 32.101,
      • 3G Charging and Billing, 3G TS 32.015,

      From TMF, we will take into account at least the following documents:

      • Telecom Operation Map (TOM), GB910,
      • New Generation OSS (NGOSS) Requirements, TMF052,
      • New Generation OSS (NGOSS) Architecture, TMF053

      • 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 IP Billing API needs to be defined by experts with different experiences. Experts are required in the following areas: Traditional billing, Billing mediation, IP standards for billing, 3G standards for billing, ISV applications (user of the API), EMS applications (provider of the API), J2EE.