OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Proposed Charter for OASIS SOA for Telecom TC

To OASIS Members:

  A draft TC charter has been submitted to establish the SOA for Telecom
Technical Committee (below). In accordance with the OASIS TC Process Policy
section 2.2: 
(http://www.oasis-open.org/committees/process-2008-06-19.php#formation) the
proposed charter is hereby submitted for comment. The comment period shall
remain open until 11:45 pm ET on 5 November 2008. 

  OASIS maintains a mailing list for the purpose of submitting comments on
proposed charters. Any OASIS member may post to this list by sending email
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will be
publicly archived at: 
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who
wish to receive emails must join the group by selecting "join group" on the
group home page:
Employees of organizational members do not require primary representative
approval to subscribe to the oasis-charter-discuss e-mail.

  A telephone conference will be held among the Convener, the OASIS TC
Administrator, and those proposers who wish to attend within four days of
the close of the comment period. The announcement and call-in information
will be noted on the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the proposed
TC (SOA-TEL) in the subject line of your email message. 


Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org  
web: www.oasis-open.org
phone: 1.603.232.9090 


OASIS SOA for Telecom (SOA-TEL) Technical Committee

1) The Charter of the TC, which includes only the following items: 
(1)(a) The name of the TC
SOA for Telecom (SOA-TEL) Technical Committee

(1)(b) A statement of purpose, including a definition of the problem to be
This TC plans to identify gaps in standards coverage for using Service
Oriented Architecture (SOA) techniques in a telecom environment;
particularly for Telecom operators/providers. The combined term
"provider/operator" means a company that utilizes a telecoms network to
provide service to the subscriber community, and they may or may not own the
network assets or services they are providing.

Applicability of IT-based SOA techniques is much more complex in the Telecom
world, where services and network features are often tightly coupled and
vertically integrated. 

* Tight coupling tends to limit the ability of Telecom operators to develop
new composite services that span heterogeneous telecommunications networks.
These limitations include the use of Operational Support Systems (OSS) and
Business Support Systems (BSS) services in particular when used to support
information services, (and associated content types) of which IT services
are a subset.

* Vertical integration reduces visibility and access to services management
functions making difficult the automation of operations and business
processes across stacks or organizations. Furthermore there are difficulties
to integrate or support process automation across the OSS, BSS, services and
network domain and the related challenges with customizing these processes. 

As Telecom operators transform into broader-based service oriented
providers, the task of service management becomes more complicated,
* Legacy and next-generation telecommunications services, 
* Information services, 
* Associated in-house and third-party content, 
* Diverse internal and external networks, 
* A multitude of end-user device types, and 
* Associated partner and supplier organizations. 

This complexity hinders the ability of Telecom operators/providers to offer
their clients converged, identity based services that are available at any
time and secure across any access network and that are operating system,
device and location independent. 

Telecom providers/operators want to rapidly create and deploy new services
that leverage their infrastructure and give them the ability to generate new
revenue streams. Telecom providers/operators need to leverage their
infrastructure to better compete in a Web 2.0 environment and
service-oriented IT world. Current SOA technologies were designed mostly for
IT use cases, and it is feared that they may not be able to support the
requirements of Telecom use cases. 

This work focuses on identifying gaps and generates requirements to identify
how existing standards can help Telecom providers/operators better compete
in this new environment. 

In Web 2.0 and SOA environments, there are mismatches between the
requirements of new kinds of experiences (whether enterprise/business or
social/personal) and those of the Telecom world. The mismatches include
questions such as 
* What is a service? 
* How is a service defined?
* What is real-time service composition"
* What is security; 
* What is raw performance? and 
* What is service availability? 

Answers are needed to the above questions in order not to impede the
adoption and use of conventional SOA technologies in Telecoms. At a minimum
there is a need to harmonize the "vocabulary" of telecoms (notably around
raw performance requirements) with a more generic framework of service
description that leverages current SOA technologies.

The adoption of service orientation also places a burden on Telecom
providers/operators to analyze the suitability of adopting such an IT born
approach within Telecom providers. In general there may be mismatches
between information services developers' and IT technology requirements and
capabilities and the Telecomm world as it relates to important
characteristic of Telecom services; such as Service Level Agreements (SLAs)
where the Telecom service provider guarantees the customer a certain level
of service in return for a specified payment. 

In OASIS, the Service Component Assembly (SCA) TC is working on the
componentization and assembly/composition of services, both from functional
and management perspectives and the automation of operations and business
processes.  Telecom specific metadata, if and where required, may be
expressed as extensions to the policies associated to SCA assemblies and
shall be considered as part of this TC work.

Limitations exist in other areas also, for example in area such as: 

* SOA across administrative domains, 
* Multiple interfaces for a service,  and
* Traceability of service and components dependencies. 

The TC will focus on generating use cases that covers these topics as well.

It is important for the Telecom industry to identify where and why SOA can
be applied in telecommunication, and the potential gaps and limitations of
using Web 2.0, SOA, Web Services and/or REST in supporting the unique
requirements of integrating telecommunication services within business

There is a need to understand and identify what SOA specifications can meet
the many Telecom requirements. For example, for the Telecom service layer:
  o SOA is a possible way to develop many new IT/Web / web 2.0 applications.

  o The Open Mobile Alliance (OMA) has standardized the service layer with a
SOA blueprint (OMA Service Enablers (OSE)), for the service layer
    * SOA and Policies become key service layer aspects (3rd party exposure,
policy enforcement and management, even in network or edge of network
    * Parlay (which started WS interest for Telecom's with Parlay X) and the
3rd Generation Partnership Project (3GPP) have now consolidated their
interest on SOA for Telecom's in OMA.
  o Some industry products are evolving the Telecom programming model closer
to SOA and Service Component Architecture (SCA).
  o SOA for OSS/BSS/SDP integration:
    * Telemanagement Forum (TM Forum) Service Delivery Framework (SDF) work
in collaboration with OMA, OASIS and other bodies to standardize an end to
end OSS/BSS/SDP integration based on SOA.
  o SOA Telecom solutions on boarding authoring, deployment, execution and
management as these are considered by Telecom providers/operators as new
possible business opportunities and business models:
    * IEEE NGSON focus on such SOA aspects
    * TM Forum SDF targets among other things management of the  resulting
    * SOA and Web 2.0 are the underlying approaches.

(1)(c) The scope of the work of the TC.
The purpose of this TC is to identify the standards consistent with Web 2.0
and SOA principles that may be more useful to Telecom providers/operators as
a means of leveraging Telecom Services in business applications, and to
assess whether there are inherent limitations in such use.

The work will generate requirements that help to address any identified
limitations or gaps in current existing standards that the TC identifies as
possible candidates in support of Telecom operators in terms of testability,
scalability, Service Level Agreements (SLA), reliability, support for
session interactions, event based interactions, service ontologies, service
failure modes, and the marrying of Web 2.0 and SOA technologies. Doing so,
it will take inspiration from the work done in other telecom oriented
organizations (for example OMA and the TM Forum) to derive requirements that
are generic and essential to the Telecom industry.

The TC output will focus on the development of a use case document that
illustrates possible gaps of Web 2.0 and SOA technologies in support of
Telecom needs. The TC will develop a requirements document for extending the
current core SOA enabling stack (Web Services and/or REST) in support of
Telecom needs.

Scope of the work

1. Analysis, Use Cases Gathering and Gap Document

a. Collect use cases to pin point limitations and current mismatches between
Telecom services technologies (including Parlay-X) and Web 2.0/SOA
implementation technologies. Example of uses cases include:
  1. Investigate needed enhancements that session oriented capabilities to
be made available to business level services, using industry accepted
interfaces and techniques.  
  2. Investigate the use and alignment with TM Forum specification regarding
service management of composite services in order to incorporate
abstractions of composite services management models, covering such aspects
as configuration, event collection, and performance monitoring. Basically
provide Telecom the ability to create new services based on business
  3. Illustrate needed information and behavior models that should be
expressed in WSDL to enable the formal expression of semantic information
relating to a service. Investigate the mapping of semantic information into
syntax using languages such as the Web Ontology Language (OWL).
  4. Investigate the need for extensions to WSDL to allow the testing of
composite services.
  5. Investigate the need of a common modeling scheme to express service
failure modes. The approach should also allow individual bodies (OASIS in
the case of WSDL) the responsibility to map those in their domain specific
  6. Investigate the need for extensions to BPEL to address specific
synchronous requirements for telecommunications.
  7. Investigate the need for extensions to UDDI to allow the discovery of
services based on their semantics such as failure mode, testability,
reliability and composability.
  8. Investigate performance requirements, high availability, predictable
and low latencies, and optimization schema domains.
  9. Investigate the need to extend standards for service contracts with
consideration of the NGOSS contracts work in TM Forum.
  10. Investigate the needed enhancements and extensions to existing
identity management systems to interface Web 2.0 / SOA to Telecom services
and networks including mobile networks and their SUM/USIM systems. Such
extensions need to encompass security and privacy concerns, and exchange of
user profile data.
  11. Identification of gaps-use cases whose full implementation is not
covered by existing standards or models.

2. Develop a requirement document for recommended Web Services (and REST)
extensions to address the Gaps that have been identified in the use case and
Gap analysis document. The TC will also collect requirements through
liaisons with other SDO such as OMA, TM Forum, 3GPP and ITU-T in addition to
the possible requirements that will emerge from item 1.

3. Perform an analysis of existing solutions with respect to the Gaps
identified in the previous steps. Identify what level of requirements is
needed, and create a road map of needed requirements and extensions
including the best SDO for specifying these requirements and the potential
extensions to address them.

4. Security, threats and Risk analysis

* Perform Security Risk analysis and determine needed profiles for best
practice. Identify technology Gaps in this area.

5. Out of Scope 

Development of specific solutions to identified Gaps in this TC. 

(1)(d) A list of deliverables, with projected completion dates.

1. Use Cases and Gap Analysis document; July 2009
2. Security, threats and Risk analysis; November 2009
3. Requirements document that addresses the issues that are identified in
item 1; November 2009.

(1)(e) Specification of the IPR Mode under which the TC will operate.
The TC shall operate under: RAND 

(1)(f) The anticipated audience or users of the work.
The output of this work will have direct benefits for the use of the Web 2.0
and SOA in Telecom.  

(1)(g) The language in which the TC shall conduct business.
This TC will use English as the language for conducting its operations.

(2) Non-normative information regarding the startup of the TC: 
(2)(a) Identification of similar or applicable work that is being done in
other OASIS TCs or by other organizations, why there is a need for another
effort in this area and how this proposed TC will be different, and what
level of liaison will be pursued with these other organizations.

The TC will be performing new work activities that are currently not covered
by any other OASIS TC.

The TC will coordinate closely with other bodies in order to inform them
about the progress of the work and also in order to count on their expertise
in the development of the work.

(2)(b) The date, time, and location of the first meeting, whether it will be
held in person or by phone, and who will sponsor this first meeting. The
first meeting of a TC shall occur no less than 30 days after the
announcement of its formation in the case of a telephone or other electronic
meeting, and no less than 45 days after the announcement of its formation in
the case of a face-to-face meeting.

The First meeting of this TC will occur on Monday, 12 January 2009 from 9am
- 5pm. Meeting will be hosted by Nortel, 3500 Carling Avenue, Ottawa,
Ontario, Canada. Call-in information will be provided for those unable to
attend in person.
(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.

The TC will conduct its business via weekly teleconference call. The time of
the call will be determined during the first meeting of the TC. The TC will
conduct F2F meeting on as needed basis. Teleconference facilities and F2F
meetings will initially be sponsored by Nortel. 

(2)(d) The names, electronic mail addresses and membership affiliations of
at least Minimum Membership who support this proposal and are committed to
the Charter and projected meeting schedule.
1. Abbie Barbir, Nortel, abbieb@nortel.com
2. Enrico RONCO, Telecom Italia, enrico.ronco@telecomitalia.it
3. Hanane Becha, Nortel, Hanane.Becha@nortel.com
4. Ian Jones, BT ian.c.jones@bt.com
5. Li Li, Avaya, lli5@avaya.com
6. Luciano Resende, IBM, luciano_resende@us.ibm.com
7. Anthony Nadalin, IBM, drsecure@us.ibm.com
8. Marc Brandt, HP marc.brandt@hp.com
9. Marco Carugi, Nortel marco.carugi@nortel.com
10. Mike Edwards, IBM, mike_edwards@uk.ibm.com
11. Orit Levin, Microsft, oritl@microsoft.com
12. Paul Fremantle, WSO2, paul@wso2.com
13. John Storrie, Nortel, STORRIE@nortel.com
14. Piere Tane, Nortel, PTANE@nortel.com
15. Bob Natale, Mitre, RNATALE@mitre.org
16. Amardeo Sarma, NEC, Sarma@nw.neclab.eu
17. Stephane Maes, Oracle, stephane.maes@oracle.com
18. Lucia Gradinariu, Lggsolutions.com, lucia.gradinariu@lggsolutions.com
19. Michael Giordano, Avaya, giordano@avaya.com

(2)(e) The name of the Convener who must be an Eligible Person.
Abbie Barbir (abbieb@nortel.com) Nortel

(2)(f) The name of the Member Section with which the TC intends to affiliate
The TC intends to affiliate with the Telecom Member Section.

(2)(g) Optionally, a list of contributions of existing technical work that
the proposers anticipate will be made to this TC.

(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document
regarding the planned scope of the TC, for posting on the TC's website.

(2)(i) Optionally, a proposed working title and acronym for the
specification(s) to be developed by the TC. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]