1 Introduction

Telecommunications is at crossroads, the convergence of fixed and mobile telecommunications, cable networks, as well as the Internet leads into a global all-IP-based Next Generation Network (NGN). Through this ongoing process of convergence of access networks and the existence of new players in the telecommunications market, traditional operators and carriers are seeking for new business models to increase their revenue.

The reuse of an extensible set of existing service components to create rapidly new market driven applications is a key aspect of telecommunications platforms since many years and gains a new momentum with the definition of dedicated application enablers for NGNs.

Some telecommunications operators ([1], [2], and [3]) have opened their networks through dedicated developer gateways providing high level Web Services or REpresentation State Transfer (REST)-based APIs with communication related enabler like SMS and voice call. The target of these portals is to expose simple interfaces to developers who can combine these services to create web applications and new products.

On the one hand the depicted characteristics impose special requirements on Service Creation Environments (SCEs) as the created applications need to be network agnostic, interact with many different platforms and technologies, and the SCE needs to provide the possibility to adjust existing applications to fast changing needs of an evolving market. On the other hand, an evolving market of 3rd party applications creates challenges and risks for the operator as the creation and execution of services is not anymore under the control of the network owner. Therefore, telecommunications service exposure mechanisms and access policies serving as Service Level Agreements (SLA) need to be defined during the service creation and deployment process as well.

The easier it is for developers to create services for a given platform, the greater will be the number of available services, and thus the acceptance of the platform by the broader telecommunications market. Therefore, a telecommunications infrastructure provider can gain significant advantage with a Service Delivery Platform (SDP) that provides anchor points for rapid service creation, deployment, and execution. Figure 1 provides an overview of the scope of this article, platforms and concerns that service designers, application developers, and network providers need to cope with.

Fig. 1
figure 1

Scope of this report

Full size image

This article describes our approach of the realization of a policy-based service broker allowing the definition of request- and service-specific policies serving as service contracts for a service and network access gateway to applications enablers in an operator environment.

The paper is structured as follows: Section 2 provides a brief state of the art overview of the NGN functionality namely the IP Multimedia Subsystem (IMS) with focus on application enablers, the OMA Service Environment (OSE), and related service creation principles. Section 3 describes our concept of the policy-based service broker as an enabler access gateway for 3rd party services and service creation environments. We end the paper with a conclusion and outlook in Section 4.

2 Related standards and technology overview

The following subsections describe emerging standards as the IMS, IMS enablers and the OMA Service Environment.

2.1 The IP multimedia subsystem

The 3GPP IP Multimedia Subsystem (IMS) provides the interfaces for interaction and underlying communication control infrastructure. The IP Multimedia Subsystem [4] is defined from 3GPP Release 5 specifications on as overlay architecture on top of the 3GPP Packet Switched (PS) Core Network for the provision of real time multi-media services.

Due to the fact that the IMS overlay architecture is widely abstracted from their interfaces, the IMS can be used for any mobile access network technology as well as for fixed line access technology as currently promoted by the European Telecommunications Standards Institute’s (ETSI) Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) [5] within the Next Generation Network reference architecture definition.

The central session control protocols are the Session Initiation Protocol (SIP) [6] and Diameter [7]. The SIP Application Server (AS) is the service relevant part in the IMS. The SIP AS needs to support well defined signaling and administration interfaces (3GPP ISC and Sh-interfaces) to connect to the standardized network architecture. The following Fig. 2 depicts the simplified IMS architecture.

Fig. 2
figure 2

Basic IMS architecture

Full size image

The particular techniques and methodologies that are required to gain the advantages of these key functionalities are not completely new, but the IMS provides the first major integration and the interaction of all key functionalities.

2.2 IMS service enabler

Similar to service independent building blocks which form part of the conceptual model for Intelligent Networks, the Open Mobile Alliance (OMA) has defined service enablers for the IP Multimedia Subsystem. The idea was initially born during the specification of a Push-to-Talk over Cellular (PoC) [8] service, a walkie-talkie like communication service between several mobile peers. PoC uses Presence, Group Management and Instant Messaging as enablers to provide information to the users as well as to the PoC service. This lead alongside the standardization of PoC to the definition of Presence SIMPLE [9] for Presence and Instant Messaging and XML Documents Management (XDM) [10] for group and list management.

The definitions of several application service enablers by the OMA and the need for a general access function for 3rd party service access led to the specification of the OMA Service Environment (OSE) [11] as a common abstraction layer for IMS-based NGNs.

It defines an enabler layer which incorporates specific enabler components that offer northbound interfaces to services that implement certain application logic. These applications either reside at the operator domain or are hosted at a 3rd party domain. Basically, an OSE incorporates Web Services interfaces and translates Web Services requests either directly into enabler logic or to an enabler specific protocol (Fig. 3).

Fig. 3
figure 3

OSE architecture

Full size image

The Policy Enforcer or Policy Evaluation, Enforcement and Management (PEEM) component as the function has been named officially by the OMA can be used to intercept service requests from a foreign domain as well as from any other service requestor and apply certain rules (policies) on them that are stored at a policy repository. A PEEM function forms the main integral component of an OMA Service Environment and provides additional functionality based on the definitions of policies for the OMA enabler concept. A PEEM may serve as an access gateway authentication function but its capabilities are much greater in regard of the orchestration and manipulation of enabler capabilities. The OMA names two different Policy Expression languages, Common Policy by the Internet Engineering Task Force (IETF) [12] for authorization policies and Business Process Execution Language (for Web Services) WSBPEL 2.0 defined by Advancing Open Standards for the Information Society (OASIS) [13] for the orchestration of enablers.

2.3 Service creation

The one thing approach [14] is designed to overcome the classical communication hurdles between application experts and the various levels of IT experts. Technically, it is realized in terms of eXtreme Model Driven Design (XMDD) [15], a technique that puts the user-level process in the center of the development. It enables customers/users to design, animate, validate, and control their processes throughout the whole life cycle, starting with the first requirement analysis, and ending with the demand-driven process evolution over its entire life span. This strict way of top-down thinking emphasizes the primary goal of every development: customer satisfaction.

The jABC realisation [16] of the XMDD approach bridges the IT thinking with the management and userlevel perspective with the aim of overcoming the capability and perspective gap between the two worlds. It offers a fine granular, feature-oriented service paradigm of modeling processes. We challenge the conventional service definition practice in the telecommunications sector: the pluralistic and interface supporting jABC approach contrasts with the logic of traditional tight telecommunications service definition, which—paradoxically—enhances organizational inertia, static routines, and inefficient path dependencies.

Figure 4 illustrates the structure of an XMDD-oriented SCE, and jABC provides exactly this same structure:

Fig. 4
figure 4

XMDD principles in jABC

Full size image

Atomic entities, here called Service Independent Building Blocks (SIB), as an analogie to Intelligent Network (IN) that is modeled into a series of SIBs, where jABC has its root, are grounded to services, like the telecommunications-specific Parlay X [17] library, Web services (as e.g. in the bioinformatics application in Bio-jETI [18]), CORBA components, or any other software components via APIs. User-level service aggregations are called features; they are useful and flexible units of reusal of purpose-specific orchestrations and modeled as Feature Logic Graphs (FLG). Applications are service orchestrations realized in terms of features and of SIBs, and they are modeled as Service Logic Graphs (SLGs). The temporal constraints are declarative process-level business rules, that can be defined independently of the concrete service and serve as a background knowledge basis against which services can be validated. In jABC, this validation is automatic and happens by model checking. The SLG of an application is therefore built as a service and feature orchestration and it can be easily validated for conformance through a library of temporal logic constraints that are typically application domain specific. The SLGs are, in the presence of implemented SIBs, immediately executable with the jABC tracer, which is an interpreter for SLGs. Via code generation with the GeneSys plugin [19] it is also possible to transform the SLGs into other models, like Business Process Execution Languate (BPEL), or code, e.g. Java for a variety of execution engines.

3 Service broker design

In this section we describe our design and implementation of a service broker to enable telecommunications specific service access for service developer and 3rd party services using policies for service contract definition.

The concept of a service broker is not new and a well-known entity of general Service Oriented Architecture (SOA) design patterns. From an operator perspective, the following strategic aspects of such a function are most relevant for exposing services:

  1. 1)

    strong enforcement of flexible operator policies for service enabler usage

  2. 2)

    support for service discovery during the creation process

  3. 3)

    support of comprehensive security measures

We focus in our design especially on 1) and 2) as we consider 3) as an objective for a session border controller. OMA defines its service environment (OSE) for generic NGN application enablers as described above. We extended the concept of policy enforcement for event-driven service request also to dynamic service capability description for developers [20]. The following Fig. 5 provides an overview of the broker architecture and its relation to service creation, service execution and service enablers:

Fig. 5
figure 5

Broker architecture

Full size image

We have built our service broker on top for the FOKUS’ Open Service Environment (OpenSE) [21], a network abstraction layer based on Parlay X Web providing bindings towards several telecommunication networks. The OpenSE uses the current Parlay X Version 2.2. and 3.0. Parlay X defines a set of powerful, highly abstracted building blocks of telecommunications capabilities that developers and the IT community can both quickly comprehend and use to generate new applications.

Each Parlay X building block is abstracted from the set of telecom capabilities exposed by the Parlay X APIs. The capabilities offered by a building block may be homogeneous (e.g. call control, conferencing) or heterogeneous (e.g. mobility and presence).

3.1 Policy-based service broker

Policy-based service access and execution of the Service Broker is implemented as several independent modules that are accessible through OMA compliant interfaces, especially the PEM1 [22] interfaces to trigger policy evaluation requests for incoming service requests and and PEM2 [23] interface for policy management.

The most important components of the policy-based Service Broker architecture are Policy Evaluation Engine, Policy Enforcement Engine, Service Registry and Service Capability Manager, a workflow engine, and Policy Management.

A policy is a formalism used to describe how to manage resources, to provide a controllable access and to reuse the existing resources exposed by an operator or 3rd party provider. Each policy is defined as a rule set and each rule is composed of conditions and actions. The policy format used complies to [12]. A rule example can be depicted in the Fig. 6:

Fig. 6
figure 6

Rule listing

Full size image

The above rule applies for sip:alice@open-ims.org message originator, for any target of the message, for operation inviteParticipant and for the processing time between 2008-05-27T14:11:00.943Z and 2010-05-27T14:11:00.943Z. The rule allows only if the value of participant does not match sip:00[0-9]*@open-ims.org. Otherwise it will deny the processed message. The actions define the invocation of a delegated service ConferenceServiceWithAd using the original message of a service exposed by a 3rd party service provider which provides a conference service.

Upon intercepted requests from a service intending to use specific network service enablers, a specific template will be applied in order to identify the necessary information which will be sent for evaluation to the Policy Evaluation Engine. It represents the main component of the service broker as it identifies the associated policies of the processed message, evaluates their rules conditions, and initiates the execution, if needed as defined by the related actions. The Policy Evaluation Engine identifies the policies based on a predefined application identifier and a combination of the policy identifiers provided by the processed message.

The evaluation result of conditions translates into a possible decisions of allow, deny or forward. In case one rule evaluates as true, the evaluation process will continue with the evaluation of the other associated rules and furthermore with the rules’ actions execution. Otherwise, the message is denied and the evaluation of further rules’ conditions is abandoned.

Relevant actions set execution consists mostly in delegation of processing responsibility to other resources and transformations of the processed message requests or its response. As the service broker was designed for access control, each delegation action will be evaluated before being sent to destination. This operation mode also ensures that the SLA (specified as a policy) defined between the (mobile) operator and the 3rd party will be respected.

The Policy Enforcement Engine overtakes the responsibility of actions execution from the Policy Evaluation Engine but it may as well be involved during the evaluation process when policy-based processing of requests is demanded, e.g. modification of location information, due to privacy rules within a policy. Policy enforcement refers to either denying a request, changing specific parameters of a request to meet the policy conditions or forwarding a request to a specified target. This might be either a specific service endpoint as part of the service enabler layer or an orchestrated complex service executed by a workflow engine.

The Policy Management Engine provides access to the policy repository allowing modification and deleting of policies. The underlying protocol is based on the XML Configuration Access Protocol (XCAP) [24].

3.2 Service discovery

The Service Capability Manager allows the discovery of services based on user, service or network/domain identifiers. The following Fig. 7 provides a flow chart for this functionality:

Fig. 7
figure 7

Service capability manager work flow

Full size image

A policy defines all services that are authorized for usage and mapped versus the available services at a service registry. An application or SCE may actively query the broker for allowed services through the PEM-1 interface to retrieve a list of services. Is mechanism my also be applied during service execution time, depending on the implementation of a service for self-adaptation of the user interface.

3.3 Service creation / composition

We have implemented a Parlay X-based service integration for jABC [25]. Each Parlay X based building block (interface) comprises operations for a specific telecommunications related functionality and consists of several operations that are available through a Web Service and each Parlay X building block is represented by one or more SIBs that provide the underlying enabler functionality in an abstract manner for service modeling inside jABC. The communication between jABC-based SIBs and the operator exposure layer (Parlay X gateway) is based on SOAP. As depicted above in Fig. 5, each SOAP request towards the service provider / operator infrastructure is intercepted by the Service Broker.

The interfaces of the Service Broker are generic from a usage perspective meaning that the broker does not differentiate within its execution states between a service developer and an actual service being executed. We imposed a role-based system through applying different service scope policies that are evaluated by the Service Capability Manager. Services as well as developers get their usage scope associated through policy evaluation. A usage scope from a developer perspective results in a listed of available services. Depending on the result of a Service Capability Manager query, the list of available services for the service developer is generated as part of a personalised workspace inside jABC. The following Fig. 8 depicts this functionality:

Fig. 8
figure 8

Personalized service portfolio provided by service broker

Full size image

Therefore a developer has only access to the services granted by the operator or service provider for service creation. The role of the service provider / operate can be considered as a super user role, that has access to all services, but furthermore also to the policy repository. A defined action as part of a policy may also include the invocation of a delegated service. The SCE allows as part of the service provider role also the creation of complex orchestrated services targeted as delegated services that can be deployed as Web Services. Figure 9 illustrates the modeling of a complex service for conferencing. Based on the Presence information of an invited participant different channels for conference establishment (either VoIP or GSM/PSTN) are used. In the case of ‘busy’ presence state, a message is sent to inform the participant with the conference number/URI for dial-in.

Fig. 9
figure 9

Creation of complex services for conferencing based on presence information

Full size image

The modeled services might either be directly exposed to 3rd parties through a Web Services interface described in Web Services Description Language (WSDL) or being called within a policy as a delegated service providing a specific business logic to alter a service behavior.

4 Conclusions

SOA principles have been used inside the telecommunications domain for many years, although different terms have been used over the last decades to describe the idea of realizing a programmable network to provide an open market of services. Today, Web Services-based APIs including emerging Web 2.0 interfaces represent the state of the art in SOA-based telecommunications, which are going to be integrated with the emerging IMS-based NGN.

We have depicted in this report our blueprint for service broker component based on SOA principles that takes the latest standards and concepts in telecommunications into account. The major work is based on a policy evaluation and enforcement engine that provides the capability to match service requests to operator defined policies to allow fine granulated service usage policies to which we refer as SLAs between service enablers, 3rd party services, users, and developers.

The policy-based definition of user/developer roles has been mapped for service developers and service provider inside an XMDD-based Service Creation Environment.

From our perspective the unique approach is to provide one single standardized interface and policy expression format to evaluate service access, service usage as well as service capability information as service contracts defined by the operator / service provider. jABC provides the environment for service creation by applying model-checking and the verification of temporal constraints. It also allows the management of exposure of services for other service providers and developers.

The system has been prototyped within the Open SOA Telco Playground at Fraunhofer Institute FOKUS [26].

Future work will concentrate on the dynamic orchestration and composition using State Chart XML (SCXML) as a standardized SLG to integrate services with many different service end points (e.g. SOAP, REST, CORBA, RPC) from different domains to create heterogeneous mash-ups.