Surya \’s Blog

… ever streaming tools and technologies….!!!

Archive for October, 2007


Posted by kathayat on October 13, 2007

The provision of value-added telephony services is by now mainly in the hands of network operators. This might change soon: OSA and Parlay specify an open, secure interface to the telephony network, which can open the telephony network to 3rd party service providers.

20 years ago, the implementation and deployment of value-added telephony services was the domain of manufacturers of telecom equipment. Telecom services of these days were, for example, call forwarding or televoting. Manufacturers were implementing the services according to the requirements from the network operator. Later, in the early nineties, the concept of Intelligent Networks (IN) was introduced and deployed in the networks. By this, network operators were getting the means to develop and deploy value-added services on their own. The creation of services is done with a Service Creation Environment (SCE). Services are created graphically by putting single service building blocks together to form the service logic chain, and by customising these building blocks. This is still the current method of how most of the value added services are created, both in fixed and mobile networks. Examples of such services are Freephone, Split Charging or Premium Rate services, Televoting, and also the Universal Personal Number.

Parlay: API for new service providers

The Intelligent Networks technology does not allow external service providers to create and deploy services on their own through the network of a network operator. The main reason is the missing security features in IN – a Service Creation Environment has full access to the network operator’s signalling network SS7. Moreover, the third party service provider would have to invest millions into the necessary equipment. To solve these issues, the Parlay group was founded in 1998 by BT, DGM&S (today: Ulticom), Microsoft, Nortel Networks, and Siemens. The goal of Parlay is the specification and realisation of an open, technology-independent Application Programming Interface (API) in telecommunication networks. The Parlay API shall enable network operators, independent software manufacturers and service providers to offer products and services, which use the functionality of existing networks. This should not be restricted to one network type, but comprise various networks (see figure 1).

Standardisation of the API

The efforts of the Parlay group to bring the API specification into standardisation bodies succeeded already one year later. The 3rd Generation Partnership Project (3GPP), in charge of specifying 3G mobile networks, adapted Parlay as the method for creating services in UMTS. 3GPP introduced this API under the abbreviation OSA – Open Service Architecture – which recently was renamed to Open Service Access. The API thus is nowadays referred to as OSA/Parlay API (or vice versa). Meanwhile, the API has also been adapted by ETSI in order to cover the fixed network side. All three bodies jointly develop the standard. Although these bodies partly publish their own specifications, they are all aligned and compatible. In the second quarter of 2002, the most recent version was subject to approval: Parlay 3.1, and OSA 1.1 / 3GPP Rel. 4 in ETSI / 3GPP respectively (1), (2), (3).

Structure of the API

The OSA/Parlay API consists of two groups of interfaces: ‘Framework Interfaces’ and ‘Service Interfaces’ (see figure 2).

The Framework Interfaces provide basic mechanisms prior to the usage of actual network functions. They comprise, for instance, Authentication and Authorisation to identify the application that wants to access the API. After successful authentication, the Discovery function can be used to query information about availability of network functions. Further functions comprise Online Subscription of service features or network functions, and further contractual service usage agreements. The access to the Framework is always the first step for the use of the OSA/Parlay API. Following this, the Service Interfaces can be used, as far as the application is authorised.

The Service Interfaces enable client applications to access the so-called ‘Service Capability Features’ (SCF). They represent the available network functions that can be used to implement telecommunication services for the end-customer. The following list gives an overview of the components contained in Parlay version 3.0, approved in December 2001:

  • Call Control: Setup and control of connections
  • User Interaction: playing announcements, DTMF recognition, Sending of SMS etc.
  • User Status / User Location: e.g. phone switched on/off?, Localisation of the phone
  • Data Session Control: e.g. for volume-based tariffing in GPRS
  • Terminal Capabilities: to query to terminal capabilities
  • Generic Messaging: converting messages, connection to mailbox etc.
  • Connectivity Management: Realising QoS etc.
  • Content based charging: tariffing based on the content of the transmitted data
  • Account Management: Management of prepaid cards in mobile networks

Posted in Network Convergence | 2 Comments »

My Appartment No. Steinan 35-26: (+47) 73 888 990

Posted by kathayat on October 13, 2007

Posted in Phone Numbers | 5 Comments »

Prakash mobile >> 9841794233

Posted by kathayat on October 13, 2007

Posted in Phone Numbers | Leave a Comment »

Dynamic Service Compositons

Posted by kathayat on October 9, 2007

Service Compositions Approaches – Static/Dynamic, Automatic/Manual, model-driven, declarative, context-based

Static – allowing the user to build an abstract model of the tasks that should be carried-out during the execution of the web service (in brief services are specified), at design time or compile time. Usually implemented through graphs. Number of services provided to the end users is limited.

Dynamic – composing services on demand, composing a service upon receiving a request from user, composing a service at runtime..etc. Capabilities of the application can be extended at runtime. Customisation of the services based on the individual needs of the user can be made dynamic. Seamless upgrading of application or composite services.

Dynamic Approaches – Predefined workflow and AI planning (Declarative, Semantic, Context-Aware, Workflow-driven, etc)

  • Requires creating a service template may not be trivial or intuitive to users. (Declarative-Based, Workflow-driven)

Choosing or creating a service template (flowchart like) that describe the structure of the composite service and then discovering the components necessary to convert (instantiate) the template into an executable workflow. SELF-SERV, eFLOW are examples.

  • Requires a user to specify inputs/outputs of the service he/she requests. User may have difficulty to specify (Declarative-Based)

Composing the requested service through connecting the inputs and outputs of the components such that the execution of the components accepts the user-specified inputs and generates user specified outputs. Examples BU-Grid, NinjaWorkflow etc

  • Requires a user to request service using a logic language for example SWORD requires a user to request a service by specifying pre/post conditions of the service using the first-order logics. Ok..user have to understand the logic prog. (Semantic-Based, Declarative-Based)

Composing a service requested in the logic language through some form of planning techniques. Examples SHOP2, SWORD etc

Rao et al 2003. Use of Linear Logic for the Service Composition. Available services are specified in the form of LL formulae (from DAML-S profile to LL axioms), then LL theorem proving is used to determine whether the requested service (composite) can be composed or not. If a proof of the theorem exists then composed service is exxtracted from the proof (ie. process model). Resulting dataflow of the selected of selected atomic services is presented to the user for inspection via GUI. Since is the composed service is guaranteed to meet the specification (available services and inference rules), no further verification is needed.

  • Requires the users request the service in intuitive manner (in natural language). Semantics of the requested service(which is express in intuitive form) is converted into machine-understandable format (semantic graph) through existing technologies (natural language sentence to semantic graph) (Semantic-Based, Ontology-driven)

Composes the service through discovering the components necessary to compose the requested service based on the semantics of the requested service, creating workflow of the requested service using discovered components and executing the workflow. Example Fujii and Suda (2007) Semantic based dynamic service composition. In order to support discovering components based on semantic of requested service, they propose CoSMoS (component service model with semantic) and middleware named CoRE(component runtime environment). In order to support creating and executing an workflow of the requested service, they propose semantic graph-based service composition(SeGSeC). SeGSec first istructs CoRE to discover components based on semantic of the requested service, next, SeGSeC creates a workflow using the discovered components such that workshow satisfies the semantic of the requested services, then, SeGSeC instructs core to execute the workflow.

  • OWL, DAML-S or other formal languages provides the semantics for the web service composition and ontology representation(ontology-driven)
  • Extending WSDL like adding QoS information, WSTL for adding transaction information etc

Challenges – Severals

  • Service modeling (description) and discovery
  • Service analysis and selection
  • Service composition and execution
  • Execution monitoring

Posted in Paper Summaries, Uncategorized | Leave a Comment »

Protected: Using UML 2.0 Collaborations for the compositional Service Specification

Posted by kathayat on October 3, 2007

This content is password protected. To view it please enter your password below:

Posted in Paper Summaries | Enter your password to view comments.

Protected: A Model-Driven Developement Approach to Creating Service-Oriented Solutions

Posted by kathayat on October 2, 2007

This content is password protected. To view it please enter your password below:

Posted in Paper Summaries | Enter your password to view comments.