White Paper Service Broker

Deutsche Telekom Laboratories
An-Institut der Technischen Universität Berlin
Service Broker for 3
rd
Party Enabling

Horst Stein, Niklas Blum (FhG Fokus)
White Paper No. 5
August 2009






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 3
rd
party applica-
tions by defining a policy-based service broker that mediates between the 3
rd
party applications and real-time communication service
enablers. Furthermore, defined policies serve besides service access definitions as a fl exible expression for user/service-specific capabili-
ties.

Index Terms:
Enabler, 3
rd
Party enabling, mash-up, brokering, authorisation, delegation

Status Participants

Public Not restricted.


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
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 defini tion of request- and
service-specific policies serving as Service Level Agreements
(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 Insti tute for Open Communica-
tion Systems (FOKUS).


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 specifies
general 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



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 of
the 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 executed service that
will be called through a defined action as part of the policy never-
theless provides a specific busi ness logic, defined by the opera-
tor policy for a specific (3rd party) service or user.


Service
(Consumer)
Service
(Resource)
Interceptor
Callable
Interface
PE request PE response
Policy Evaluation
Engine
Policy Repository
Policy
Enforcement
Engine
PEv request
PEv result
PEn decision
Service request
Delegated
Service
Delegated
Service
Delegated
Service
Delegated
Service
PE responses:
• allow
• deny
• delegated services resp.
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 contract (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 developer but the executed
application logic may include certain business logics as adver-
tisement enriched services.


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

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. The
work 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 service 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.


Service Broker for 3rd Party Enabling References


Page 10

5 References
[1] http://www.developergarden.com
[2] http://www.ribbit.com
[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


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

Service Broker for 3rd Party Enabling Table of figures


Page 12
Publisher:
Deutsche Telekom AG
Laboratories
Ernst-Reuter -Platz 7
D-10587 Berlin
Telefon: +49 30 8353-58555
www.laboratories.telekom.com

Authors: Dr. Horst Stein (Deutsche Telekom Laboratories)
Niklas Blum (Fraunhofer Institut für 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 Telekom
Laboratories 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.