Name of Contact Person: Stefan Vaillant

E-Mail Address: stefan.vaillant@nokia.com

Telephone Number: +49 211 9412 3973

Fax Number: +49 211 9412 3988

Co-submitting Participant: Cygent, Inc.

Name of Contact Person: David Hom

E-Mail Address: david.hom@cygent.com

Telephone Number: +1 415 913 3000

Fax Number: +1 415 913 3001

Co-submitting Participant: Ericsson

Name of Contact Person: Stefan ?erg

E-Mail Address: stefan.aberg@emw.ericsson.se

Telephone Number: +46 31 747 1997

Fax Number: +46 31 747 2942

Co-submitting Participant: NEC

Name of Contact Person: Hiroya Kawata

E-Mail Address: h-kawata@bq.jp.nec.com

Telephone Number: +81 45 939 2450

Fax Number: +81 45 939 2487

Co-submitting Participant: Nortel Networks

Name of Contact Person: Colin Ashford

E-Mail Address: ashford@nortelnetworks.com

Telephone Number: +1 613 765 4929

Fax Number: +1 613 765 7387

Co-submitting Participant: Motorola

Name of Contact Person: Frank Korinek

E-Mail Address: frank.korinek@motorola.com

Telephone Number: +1 847 576 1643

Fax Number: +1 847 538 5564

Co-submitting Participant: OSI

Name of Contact Person: Ahmed Saleh

E-Mail Address: ams1@osi.com

Telephone Number: +1 905 282 1356 x1519

Fax Number: +1 905 282 9961

Co-submitting Participant: Sun Microsystems Inc.

Name of Contact Person: Philippe Goujard

E-Mail Address: philippe.goujard@uk.sun.com

Telephone Number: +44 1276 689 414

Fax Number: +44 1276 677 121

Co-submitting Participant: Telcordia

Name of Contact Person: Melbourne Barton

E-Mail Address: mbarton@research.telcordia.com

Telephone Number: +1 732 758 3081

Fax Number: +1 732 758 4372

Initial Expert Group Membership

• CISCO
• Cygent
• Ericsson
• NEC
• Nokia
• Nortel
• Motorola
• OSI
• Sun Microsystems Inc.
• Telcordia

Section 2: Request

2.1 Please describe the proposed Specification:

In Operation Support Systems, the area of Service Provisioning is vast, and complete standards or even de-facto standards in this area are lacking. Several products manage specific parts of Service Provisioning. They can be integrated into an end-to-end solution, but these one-shot integrated solutions are extremely complex, 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 Service Activation API is an API that is essential to build total OSS solutions by assembling commercial-off-the-shelf components.

As the first step in the Service Provisioning area, this JCP defines the API to Service Activation products. By using the API, one can for example create, amend and cancel orders. These orders initiate the desired changes to the service, including activation, deactivation or configuration changes of the service.

The terms used in the previous paragraph --- service and order --- will be the main abstractions for the API. While modelling services and orders in the API is neccessary to achieve integration, it might not be sufficient. To define a complete plug and play API for OSS Service Activation, it might be neccessary to include definitions for specific services to the API. In this case, the API will concentrate on 3G wireless services.

The API is used (called) by order entry products, order manager products or workflow management products. The API is implemented by service activation products, which are often specially customised for certain network technologies (GSM, GRPS, ATM, IP, SDH, ). The API can also be implemented directly by subnetwork management systems or even by element management systems.

If the API is implemented by the above mentioned products, the system integrator and service provider can buy products from different sources and integrate them with no or minimal effort to an end-to-end OSS solution.

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

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 OSS Service Activation 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, the expert group 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 will be used.
• JNDI (Java Naming and Directory Interface):
  The specification will include standards for JNDI names.
• XML:
  The definitions for orders and services will make use of XML.

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. The following are some of the proposed names:

• javax.oss
• javax.oss.order
• javax.oss.orderevent
• javax.oss.service

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 on 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?

None anticipated.

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: March 2001
• Spec Public Draft: April 2001
• Spec Proposed Final Draft: 3Q2001
• Spec Final Release: 3/4Q2001

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/) is developing standards for 3G telecommunication 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 Telecom Management. The M-Series recommendation 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 service activation, there are no standards that can be used directly as a basis for the Java API. However, some existing standards can guide the development and provide a vocabulary for the API. Among theses are the documents TMF 504 and TMF 603.