white paper service broker

8/10/2019 White Paper Service Broker

1/12

Deutsche Telekom LaboratoriesAn-Institut der Technischen Universitt Berlin

Service Broker for 3rd

Party Enabling

Horst Stein, Niklas Blum (FhG Fokus)

White Paper No. 5

August 2009


2/12

Service Broker for 3rd Party Enabling Abstract and Keywords

Page 2

Abstract and Keywords

This whitepaper describes our approach to include telecommunications service enablers into WWW mash-ups or other 3rd

party applica-

tions by defining a policy-based service broker that mediates between the 3rd

party applications and real-time communication service

enablers. Furthermore, defined policies serve besides service access definitions as a flexible expression for user/service-specific capabili-ties.

Index Terms:

Enabler, 3rd

Party enabling, mash-up, brokering, authorisation, delegation

Status Participants

Public Not restricted.


3/12

Service Broker for 3rd Party Enabling Table of contents

Page 3

Table of contents

Abstract and Keywords .............................................................................................................. 2

1 Introduction....................................................................................................................... 4

2 Architecture....................................................................................................................... 5

3 Use Cases.......................................................................................................................... 7

4 Outlook.............................................................................................................................. 9

5 References ...................................................................................................................... 10

6 Table of figures ............................................................................................................... 11


4/12

Service Broker for 3rd Party Enabling Introduction

Page 4

1 Introduction

The emerging Web 2.0 digital marketplace presents an important

opportunity for telecommunications operators to offer their own

capabilities as services. Besides communication services like

short message service (SMS), voice-call or location, further capa-

bilities like billing, identity management, authentication or control

of Quality of Service (QoS) are candidates as telecommunications

enablers for the development of new applications.

Deutsche Telekom AG has launched its open development portal

called Developer Garden [1] in November 2008 with some com-

munications related enablers like SMS and voice call. The target

of the portal is to expose simple interfaces for developers, who

can combine these services to create web applications and new

products. Via the open development portal, the 3rd party service

developer becomes part of the community and gets access to

core network functionalities using Web Services and the open

programming interfaces via the software development kit. Compa-rable activities are performed in British Telecom's Ribbit [2] and in

the Orange Partner program [3].

If the telecommunications operator exposes valuable sources of

functionality and content to a wider audience, it is necessary to

underpin the service delivery platform with certain security and

management mechanisms. A set of technologies must be pro-

vided in order to control the access of the service, manage the

impact of executing the service usage or apportion this payment

according to revenue sharing rules if the service is partly or wholly

owned by a 3rd party provider. Figure 1 provides an overview of

the role of the service broker as part of the emerging web / telco

service sphere.

Figure 1 Enabler Environment for 3rd Parties

The Service Broker realises technical mechanisms for brokering

between telecommunications and 3rd party service (e.g. Web 2 .0

mash-ups, enterprise services) environments. Our approach is a

policy-based service broker allowing the definition of request- and

service-specific policies serving as Service Level A greements

(SLAs) between a service access gateway to service enablers in

an operator environment and applications in 3rd party domains.

The project is organized by Deutsche Telekom Laboratories in

cooperation with the Fraunhofer Institute for Open Communica-

tion Systems (FOKUS).


5/12

Service Broker for 3rd Party Enabling Architecture

Page 5

2 Architecture

The Service Broker is designed as several independent modules

which are accessible through Open Mobile Alliance (OMA) Ser-

vice Environment (OSE) [4] compliant interfaces.

OMA defines several application service enablers and specifiesgeneral access functions for 3rd party service access in OSE as a

common abstraction layer for IP Multimedia Subsystem (IMS)-

based NGNs. Central element in OSE is the Policy Evaluation,

Enforcement and Management (PEEM) component which inter-

cepts service requests from a foreign domain as well as from any

other service requestors and applies certain rules (policies).

PEEM may be used for the authorizations of requests or to define

enabler capabilities for exposure based on request policies. OMA

has specified two interfaces PEM-1 [5] to trigger policy evaluation

requests for intercepted service requests and PEM-2 [6] for policy

retrieval from the policy repository.

Our architecture of the Service Broker (figure 2) comprises Mes-sage Interceptor(s), Callable Interface PEM-1, Policy Evaluation

Engine, Policy Enforcement Engine, Service Capability Manager, a

workflow engine and the Policy Management Engine.

Figure 2 Architecture of the Service Broker


6/12

Service Broker for 3rd Party Enabling Architecture

Page 6

In our experimental environment the Service Broker delegates

service requests which address enabler services from Developer

Garden, FOKUS Open IMS, and SOA Telco Playground based on

policy definitions hold in a Policy repository (figure 2).

Figure 3 illustrates a flow of service usage, i.e. from a service

request to the service enabler using the evaluation mechanisms ofthe Service Broker.

A policy is a formalism to manage resources, to provide controlla-

ble 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. Actions may

be either identifiers for responses of the Policy Enforcement En-

gine to allow or deny a certain request or the definition of a target

in case of a defined delegation to a different service (e.g. an or-

chestrated service).

Figure 3 Flow of Service Usage

The Policy Management Engine provides the mechanism for

policy repository management and implements common opera-

tions such as uploading a policy, modifying it or deleting it. The

underlying protocol is based on XML Configuration Access Proto-

col (XCAP) [7]. As an example to incorporate more complex ser-

vices we make use of a Business Process Execution Language

(BPEL)-based work-flow engine [8] which is targeted for delega-

tion as defined within a specific policy. This mechanism allows

that the original exposed service interface remains the same from

a 3rd party service perspective, while the ex ecuted service that

will be called through a defined action as part of the policy never-

theless provides a specific business logic, defined by the opera-

tor policy for a specific (3rd party) service or u ser.

Service(Consumer)

Service(Resource)

Interceptor

CallableInterface

PE request PE response

Policy Evaluation

EnginePolicy Repository

PolicyEnforcement

Engine

PEv request

PEv result

PEn decision

Service request

DelegatedServiceDelegated

ServiceDelegatedServiceDelegated

Service

PE responses:

allow

deny

delegated services resp.


7/12

Service Broker for 3rd Party Enabling Use Cases

Page 7

3 Use Cases

One major use case of the Service Broker is authorization and

delegation of service requests from a 3rd party service provider

towards the operator domain (Figure 4). As the Service Broker is

stateless, authorization is performed for every request. For each

service enabler, an XSLT file has to be created for the interceptor

providing the transformation according to OMA PEM-1 of the

service request for policy evaluation [9].

Figure 4 Message flow for request authorisation

Authorisation and delegation criteria are described in the policies

e.g. related to request originator (e.g. domain, IP address, identity

like SIP URI, tel URI, MSISDN) or request target (service identifier,

identity like domain range, number scheme). This allows for in-

stance to route an SMS request targeted for a customer from a

specific country-provider (e.g. T-Mobile UK) to the related country

specific resource (SMS Center of T-Mobile UK) based on a spe-

cific policy, without changing the call parameters.

A second use case is the delegation to an additional service en-

abler in dependence of a special service con tract (e.g. low budget

service with advertisement vs. premium service without adver-

tisement) through policies. The advantage using such a mecha-

nism is that the functional (exposed) interface remains the same

from the perspective of the service dev eloper but the executed

application logic may include certain business logics as adver-

tisement enriched services.


8/12

Service Broker for 3rd Party Enabling Use Cases

Figure 5 Service Delegation to additional advertisement

enabler

Further use cases (e.g. handling events - incoming call or mes-

sages - from the network based on policies, exposure of allowed

enabler) are realised in the experimental setup.

Page 8


9/12

Service Broker for 3rd Party Enabling Outlook

Page 9

4 Outlook

This whitepaper desribes the design for a service broker compo-

nent based on state-of-the art SOA principles that take the latest

standards and concepts in telecommunications into account. Thework is based on a policy evaluation and enforcement engine that

provides the capability to match service requests to operator

defined policies. The policies allow a fine-grained service usage

as a mapping of service contracts between service enablers, 3rd

party services and users. From the presented perspective the

unique approach is to provide one single standardized interface

and policy expression format to evaluate service access, service

usage as well as serv ice capability information defined by the

operator. Future work will concentrate on the dynamic service

discovery, orchestration, and composition based on semantics, to

allow the combination of many (operator-specific) service en-

ablers automatically for more complex services.


10/12

Service Broker for 3rd Party Enabling References

Page 10

5 References

[1] http://www.developergarden.com

[2 ] http: //ww w.ri bbit.co m

[3] http://www.orangepartner.com

[4] Open Mobile Alliance (OMA). OMA Service Environment. Approved Version 1.0.4 01 Feb 2007. 2007

[5] Open Mobile Alliance (OMA).Policy Evaluation, Enforcement and Management Callable Interface (PEM1). 2008.

http://www.openmobilealliance.org

[6] J. Rosenberg. RFC4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP). May 2007

[7] IPsphere Framework Technical Specification (Release1) IPsphere 1.0. June 2007. IPsphere Forum

[8] ActiveBPEL. http://sourceforge.net/projects/activebpel

[9] N. Blum, I. Boldea, T. Magedanz, U. Staiger, H. Stein, "A Service Broker providing Real-time Telecommunications Services for 3r d

Party Services", Proc. of 33rd Annual IEEE International Computer Software and Applications Conference (COMPSAC), Seattle, July

2009, ISBN 978-0-7695-3726-9, DOI 10.1109/COMPSAC.2009.202
http://sourceforge.net/projects/activebpelhttp://sourceforge.net/projects/activebpel


11/12

Service Broker for 3rd Party Enabling Table of figures

Page 11

6 Table of figures

Figure 1 Enabler Environment for 3rd Parties .................................................................................................................................................4

Figure 2 Architecture of the Service Broker ....................................................................................................................................................5

Figure 3 Flow of Service Usage .........................................................................................................................................................................6

Figure 4 Message flow for request authorisation ............................................................................................................................................7

Figure 5 Service Delegation to additional advertisement enabler ...............................................................................................................8


12/12

Service Broker for 3rd Party Enabling Table of figures

Page 12

Publisher:

Deutsche Telekom AG

Laboratories

Ernst-Reuter -Platz 7

D-10587 BerlinTelefon: +49 30 8353-58555

www.laboratories.telekom.com

Authors: Dr. Horst Stein (Deutsche Telekom Laboratories)

Niklas Blum (Fraunhofer Institut fr Offene Kommunikationssystem FOKUS)

2009 Deutsche Telekom Laboratories

The information contained in this document represents the current view of the authors on the issues discussed as of the date of publica-

tion. This document should not be interpreted to be a commitment on the part of Deutsche Telekom Laboratories, and Deutsche TelekomLaboratories cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. Deutsche Telekom Laboratories makes no warranties - express, implied, or statutory -

as to the information in this document.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this

document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, me-

chanical, photocopying, recording or otherwise), or for any purpose, without the express written permission of Deutsche Telekom

Laboratories.

Deutsche Telekom Laboratories may have patents, patent applications, trademarks, copyrights or other intellectual property rights cover-

ing the subject matter in this document. Except as expressly provided in any written license agreement from Deutsche Telekom

Laboratories, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual

property.
http://www.laboratories.telekom.com/http://www.laboratories.telekom.com/

white paper service broker

Documents