jNetX SDF White Paper

jNetX copyright 2001 - 2008

1

SERVICE DELIVERY FRAMEWORK (SDF): FINALLY TAKING SHAPE

THANKS TO – NOT IN SPITE OF – VENDOR DIFFERENCES

Now that the clouds are clearing and the functional lines are being drawn around who does what in an SDF,

Vendors and Operators can now get to work on the original task – getting services to market.

INTRODUCTION

With the continuing advance of IP broadband access technologies, basic voice and messaging services are increasingly under

threat of becoming a commodity. To prevent loss of revenue and to face new competition from Internet service providers,

network operators are reacting by unlocking their service plane to deliver new and innovative, feature-rich communication and

content-based services. End-user service personalization and short time-to-market are crucial characteristics for operators to

succeed as value-added service providers.

IT technologies have impressively progressed during the last five years and, as a result, have gradually started to break into the

traditional “rigid” telecom environment, introducing flexibility in the communications service plane. The merging of the IT and

telecommunications domains has naturally generated some confusion and “claim-staking” in the marketplace. The term “SDP”

(Service Delivery Platform) was coined to describe this new service environment and quickly became a buzzword.

At a high level, SDP can be defined as a standards-based framework that facilitates and optimizes all aspects of service delivery:

service design, development, deployment, provisioning, and management. Unfortunately, when trying to enter into a more in-

depth definition of SDP, every vendor has its own approach. One of the main reasons for the many diverse SDP definitions is

that there are many different classifications of a service. As the SDP market definition has matured, the vendors and operators

have agreed that all SDP functionalities cannot actually be covered by a single “Platform” or vendor. Hence, the term “SDF” for

Service Delivery Framework has taken precedence to illustrate that such an environment is composed of many functional

elements working in a collaborative manner – some from the IT domain and others from the Telecom side. Nevertheless, IT and

Telecom engineers have been largely unable to conceptualize an SDF as a whole, and as a result have entered into a series of

conflicts and misunderstandings.

Fortunately, things are now stabilizing. On one hand, the IT community has understood that Telecom requirements are more

complex than they initially thought. On the other hand, Telecom engineers have accepted that reusability, openness, and shorter

development timeframes require additional efforts and expertise over and above what was required for building a traditional,

monolithic and specialized application server.

jNetX has pioneered the use of carrier-class Java technologies in the Telecom domain and is recognized as one of the few IT

companies positioned at the crossroads of Telecom and IT. Through endorsements by some of the world’s leading, multi-

national operating companies, jNetX has proven that an open, standards-based Java service delivery environment is the right

approach for running mission-critical voice and data applications.

During Summer 2007, jNetX was invited by a global leading operator to a series of workshops to share its experience related to

both the IT and Telecom domains. The purpose of these workshops was to define the architecture of an ideal service delivery

environment with three of the major Network Equipment Providers, three major IT players, and four leading independent ISVs.

After several months the vendors were surprisingly able to agree on a common reference SDF architecture.

Following these workshops, jNetX took the initiative to invite several companies (such as Nokia Siemens Networks, Motorola,

SUN Microsystems and Microsoft) to a full day public debate in order to demonstrate how their views on SDF architecture and

corresponding technologies were actually converging. This debate took place at the SDP Global Summit pre-workshop during

September 2007 in Frankfurt, Germany - please contact jNetX or one of the involved companies for more information and

material on this full day activity.

This whitepaper seeks to build upon this activity and highlights the basic functional elements composing a modern SDF. It also

explains the origins of common misunderstandings and has an emphasis on Service Execution and Service Composition.


2

It is important to note that this is a high level technology paper. However, equally or more important are the benefits that an

SDF brings to the operator in terms of a new business model, whereby the:

• SDF is supplied by a trusted Systems Integrator or Network Integrator but if the operator so wishes, this integrator can be

replaced by another integrator as the operator’s needs evolve; and

• The applications running in the SDF can be sourced from a wide range of ISVs that bring innovation and competition into

the service plane, allowing operators to reuse commodity, best-in-class service and service components to get to market

much faster.

In short, an SDF business model breaks the traditional vendor lock-in which has historically stymied innovation and driven up

costs. Now operators have leverage and choice, allowing them to roll out their services roadmap much more effectively.

SDF REQUIREMENTS & KEY FUNCTIONAL ELEMENTS

The list of challenges that needs to be addressed in order to build a harmonized SDF architecture is substantial. Below is a

summary of the key requirements to take into consideration while architecting an SDF.

Hence, an SDF shall:

1) Allow to deliver ANY type of service (a click-to-dial application does not require the same environment as a virtual PBX).

2) Address each aspect of service delivery, from service creation to service management as shown in the figure below.

3) Follow open standards in order to

enable application portability, to

facilitate inter-operability and finally

to federate a developer communities

able to create and deploy new

services in the SDF environment.

4) Minimize the duplicated functions in

order to keep the architecture as

simple as possible.

5) Minimize the infrastructure costs by

federating, leveraging, and reusing

existing assets while progressively

and smoothly moving towards a

comprehensive target architecture

(over the years). An SDF shall not

represent a new silo.

6) Finally, a network centric SDF

(as described in this document) shall work in cooperation with device-based service delivery environments (such as J2ME,

Google Android, and so on).

The figure below represents an SDF functional architecture and shows how the major functional elements are spread across the

IT and Telecom domains. As stated above, a large part of the market confusion comes from the fact that people – depending on

their respective IT or Telecom backgrounds – interpret these major functional elements differently. For example, Service Policy

can be understood by some IT experts as Service Level Agreements for 3rd

parties to access network capabilities or as a SOA

governance mechanism, whereas Telecom engineers would primarily think about a Policy Decision Function (PDF) as defined

by 3GPP for the IMS or as a Radius Server performing user authentication and authorization (i.e. low-level policy mechanisms).

4

Services

Delivery

Framework

Service Logic

Execution

Service

& User Data

Service Policy

Security, AAA, SLA MgtService Metering

& Monitoring (Charging, Accounting,

Billing, Reporting)

Service

Creation

Service

Management & Provisioning

Service

Exposure

Service

Composition & Interaction


3

The following two sections of this document highlight two functional elements that are known for generating an important part

of the confusion in the market: Service Execution and Service Composition. Other functional elements of the SDF are only

referenced for information. If you wish to get deeper information on any of these elements, please contact your jNetX

representative or send an email to [email protected].

SERVICE EXECUTION ENVIRONMENTS

As services intrinsically differ from each other, they are required to be hosted in an appropriate Execution Environment in order

to run efficiently. Specific execution environments have been designed by IT and Telecom application server vendors to cater

for the different kinds of services and their associated characteristics.

To date, there is no magic container able to handle all types

of service logic. Instead, there is a need to have two

complementing and smoothly integrated environments: an

IT/SOA and a Telecom one. These environments are very

different by nature and have specific characteristics.

Within an operator, the SOA environment typically supports

functions like the OSS, the BSS, and possibly some end-user

services that are not time-critical and that do not require

access to network protocol specific information (for example,

a “Weather forecast service” over SMS could be running in a

Web Services environment). The Telco AS domain is in

charge of complex network protocol handling.

It is used to run mission critical applications such as Prepaid,

VPN or Conferencing and to do the conversion between

business interfaces exposed to the SOA domain and network

low-level corresponding execution.

Flow/Process-Driven , Bus./Enterprise Execution Environments

Event-Driven, Low Latency Telecom Execution Environments

Portal Layer

Service Bus (ESB)

IT domain

Telecom domain

Telecom Services & Enablers

IT Services & Enablers

SOA

Web ServicesBPM

NGINIMS Apps

Telco AS


4

SOA Layer (in green)

The Portal Layer (that handles functions like Self-Care, Customer and Partner Requests Management - PRM/CRM) is typically

supported by HTTP Servlet technology and can be complemented by a Flow/Process-Driven Business Execution

Environment that mostly handles enterprise application, business processes such as executed in the OSS and BSS domains.

This execution environment is typically implemented by an EJB or a Microsoft .NET container.

When solely based on Java, a SOA can be

supported by a global Java EE environment.

Java EE™ (Java Platform, Enterprise Edition)

is the name of the 5th

release of J2EE. Java EE

5, the current release to date, is defined by JCP

JSR 244. It succeeds the J2EE 1.4 version

defined by the JSR 151. Java EE (sometimes

noted JEE) has been designed to support heavy

enterprise applications and to combine existing

enterprise information systems (EISs) with new

business functions. It has nevertheless evolved

over the years, getting more and more

components and functionality.

In its 5th

version, Java EE defines a set of

containers, as shown in the picture on the right,

extracted from JSR 244. These containers

make use of a list of Java services (e.g.: Java

Persistence API, JDBC API, Java Message

Service (JMS), Java Naming and Directory Interface (JNDI), Java API for XML Web Services (JAX-WS), and so on). Some of

them are actually provided by J2SE and are being used by other standards-based Java containers like SIP Servlet or JAIN SLEE.

SIP Servlet and JAIN SLEE are defined by their own JSR specifications and are not part of the JSR 244 specification. As an

example, the word SIP is not mentioned a single time in the JavaEE JSR244 in which the Servlet container actually refers to

HTTP Servlet. Nevertheless, as mentioned later in this document, vendors can integrate Telecom containers such as JAIN SLEE

or SIP Servlet into a broader JavaEE environment in order to share and reuse services across the SOA and Telecom domains (see

NB. below).

Telco AS Layer (in blue)

The Event-Driven, Low-Latency Execution Environments have been designed to deliver applications/services running on top

of complex network protocols with complex state-machines, and typically with event driven asynchronous invocations. Many

legacy IN systems, using such an environment, are based on vendor-specific proprietary solutions. There are only two

standards-based Java solutions in the industry. One of these is devoted to SIP: the SIP Servlet; whereas the other – the JAIN

SLEE (SBB container) – is more generic and relates to telecom services as a whole.

SIP Servlet overview

SIP Servlet is defined by JCP under the JSR specification number 116 (SIP Servlet 1.0). Its future release, planned for next year

(2008), will be specified under JSR 289 (SIP Servlet 1.1). SIP Servlet can be viewed as an extension to a SIP stack. It is

intrinsically linked to the SIP protocol but as it inherits from the generic Servlet API, some of the Servlet vendors have

implemented a convergent SIP/HTTP Servlet solution. Such a solution provides a limited degree of convergence, allowing to

run applications that extend the usage of SIP to HTTP. SIP Servlets are quite intuitive for the important developer community

already familiar with Java Servlet (at least at programming level). Nevertheless, these developers are used to a request/response

type of invocation for which the Servlets have been optimized; but SIP also brings some complex session-based types of

invocations, more complex to manage with Servlets. This results in SIP Servlet being easy to use for creating simple

applications, but actually rather complex when developing session-based and elaborated applications. In SIP Servlets, it is

required to build extensions for support of programming paradigms, such as event driven concurrency model or SIP Back to


5

Back User Agent constructs. Finally, any integration of SIP Servlet applications with non-SIP environments (such as SS7

CAP/INAP or internet XMPP) requires complex and proprietary integration with (sometimes proprietary-based) gateways.

JAIN SLEE / SBB container overview

JAIN SLEE is defined by JCP under the specifications JSR 22 (JSLEE 1.0) and JSR 240 (JSLEE 1.1). Compared to SIP Servlet,

JAIN SLEE is based on a protocol agnostic container that allows it to run services on top of any network protocols such as those

for the IN (CAP, INAP, WIN, AIN), IMS (SIP, Diameter), as well as many other major ones (such as MAP, LDAP, HTTP,

SMPP, MM7, MLP/LIF, XMPP and so on). This container is especially designed for asynchronous event-driven applications

such as the ones in Telecom. Today, JAIN SLEE remains the unique standards-based Java environment which is able to handle

IN, IMS, and Intranet/Internet based services on the same container. It allows Operators to ensure a seamless transition from

their legacy infrastructure to their Next Generation Network when deploying their SDF. The price to pay for such convergence

and feature richness is a relatively significant learning curve (compared to Servlet). Nevertheless, service creation tools like the

jNetX Telecom Services Studio abstract such complexity to the developers and allow them to design complex telecom

applications in a very short time frame. Applications as complex as Online Charging Front-End on top of CAMEL ph2 have

been developed by jNetX partners in a matter of weeks before going live.

NB: Even if they have been designed for different purposes, it remains possible to compare, in some degrees, SIP Servlet

container, SBB container (JAIN SLEE) and EJB container since they are all Java based containers. It nevertheless makes no

sense to compare them with JavaEE as a whole. It is always possible to have a SIP Servlet or an SBB container tightly coupled /

part of a JavaEE environment. Both are Java containers that can easily share JavaEE services and foundations. As an

example, jNetX Telecom Application server can be tightly coupled with a JavaEE server with which it is already sharing some

parts of the framework. Many services such as JNDI, JDBC, JMS, JMX, and so on are also used by both the JavaEE

environment and the jNetX solution. Additionally, jNetX telecom-specific elements such as its overload control mechanism, the

fault management components, the network-specific service enablers and so on, can be exposed to a larger JavaEE environment

to be directly accessed by other elements external to jNetX, including a SIP Servlet.

SERVICE COMPOSITION

The generic principle behind Service Composition is to create new services by simply combining/reusing individual and

independent existing services. As an example, charging in real time for calls made by business users who already subscribed to

a VPN service should simply be realized by reusing existing VPN and Prepaid applications and platforms. Service Composition

allows service providers to rapidly launch new applications while minimizing the investment needed. It allows to fine-grain user

segmentation by addressing new niche markets in a more focused manner. This greatly leverages the service provider’s revenue

and increases customer satisfaction.

Because there are many different types of services, this domain has also led to a large amount of market confusion regarding the

best technology capable of supporting such functionality.


6

For an IT engineer, Service Composition often

refers to the so-called Service Orchestration

mechanism that consists of invoking and

composing independent services called

business processes to create a new composite

service. These business processes expose a

well defined interface (described with a

WSDL document). Languages like BPEL and

BizTalk have emerged to organize and to

describe IT service orchestration, which

follows a process-driven approach. On the

other hand, Telecom engineers, in order to

compose network services (ex: Prepaid and

VPN), often refer to IN Mediation for IN-types

of service composition and SCIM when handling SIP/IMS protocols. In contrast to IT Service Orchestration, the

implementation algorithm is event-based and data-driven. It acts directly on the top of the network protocol signaling, handling

complex protocol state machines. jNetX covers both the IN Mediation and SCIM functions with its Service Brokering solution.

For SIP-initiated service composition, the main technologies available on the market are shown in the figure below:

1. S-CSCF iFC – initial Filter Criteria based mechanism

2. jNetX Service Brokering (SCIM part)

3. SIP Servlet Application Router (SIP Servlet 1.1)

4. Web Services

Orchestration

iFC mechanism

This solution, defined by 3GPP, provides a basic mechanism for chaining the invocation of applications only within an IMS

environment. The sequence of service invocations is static and pre-defined (previously provisioned in HSS). There is no

runtime decision as well as no Service Interaction capabilities (i.e. if two services are in conflict, there is no entity able to

arbitrate between them). jNetX believes that service interaction needs a higher degree of programmability. The interaction

mechanism could be impacted depending on conditions such as, the subscriber location, server overload situation, or the time of

day. iFC does not provide operators with such capabilities, therefore making this solution rather limited and incomplete. Such a

solution is also obviously inappropriate to MVNE/MVNO that would not host any S-CSCF.


Service Bus (ESB)

Portal Layer


Event-Driven, Real Time Telecom Execution Environments

ITTe

leco

m


Orchestration (BPM/ BPEL/

BizTalk)

SCIM

IN ServiceMediation

Web ServicesBPM

IMS APPsNGIN


7

SIP Servlet mechanism

The first SIP Servlet specification that will introduce capabilities to chain applications is SIP Servlet 1.1 (JSR 289). This

specification is expected to be completed (Final Release) in the first quarter of 2008. Vendor implementations will follow;

however, these solutions will take several iterations in the network to reach acceptable reliability and performance. SIP Servlet

1.1 brings a new application Selection and Composition model. It introduces the ability to “chain” the invocation of multiple

SIP applications in a logical path for a given SIP request. This is done

by routing the initial request to a new component called the Application

Router which has the role of inserting specific route headers into the SIP

message in order to re-route it to an appropriate (list of) SIP

application(s). Hence, with this future release of SIP Servlet, it will be

possible to make a runtime decision in order to chain the invocation of

SIP-based applications. Nevertheless, this solution has many limitations.

First, the Application Router does not have a standard mechanism to

trigger external elements when making runtime service chaining

decisions. For example, such a decision could depend on a user profile or location (retrieved over external protocols such as

LDAP, MAP, Diameter and MLP/LIF for example). Retrieving such information from a SIP Servlet might require the use of

additional protocols such as HTTP or JMS and as such impact the latency. It might also end-up with a synchronous invocation

that would decrease the overall performance. Additionally, SIP Servlet defines some system Headers that should not be

modified and that can complicate the service interaction when some applications are conflicting. Finally, SIP Servlet mechanism

does not provide any elegant capability to compose applications that would not be SIP-based (IN or Web based for example). In

conclusion, the future SIP Servlet JSR 289 service composition mechanism only brings a few improvements compared to iFC

but remains dedicated to SIP with several limitations.

Web Services Orchestration

As mentioned earlier, Web Services Orchestration, when described by languages such as BPEL or BizTalk, is very suitable for

orchestrating process-driven and web-specific technologies (pertaining to the enterprise, OSS, and BSS spaces). It is

nevertheless not adapted for composing low level SIP or IN-based services and more generally, services where complex protocol

state-machines are involved. As a consequence, such technology would not be suitable for orchestrating services such as IP-

PBX and Online Charging. Nevertheless, it can still be used for non time-critical and non session-oriented service composition.

For example, a SIP MESSAGE request, received over Parlay X by a BPEL engine could instantiate a business process to

update a statistics service and an independent bonus & promotion (Web) service. As a conclusion, in a full SDF architecture,

such technology needs to be complemented by a network-based service composition solution such as the one provided by jNetX.

jNetX Convergent Service Brokering (IN Mediation and SIP/IMS SCIM)

The jNetX solution is closer to Service Brokering as defined by 3GPP and benefits from all the JCP JSLEE capabilities to

provide a fully featured Convergent Service Brokering Solution that includes both IN and SIP based service composition.

jNetXIN Mediation / SCIM

IMS/SIPLegacy CS

INAP CS1, CS2CAP v1 to v4INAP CS1+, SINAP, CS1R, etc.

AIN, WIN

SIP (IETF, ISC)

IN AS 1

SINAPINAP CS1+

CAP2, 3 SIP IETF

Web Services

ISC 3GPP

Microsoft WES

Facilities

- DBs (HSS, HLR, LDAP servers, …)

- VAS (LBS, SMSC, MMSC, WAP GW, etc…)

Logic

Logic

IN AS 2

Logic

SIP AS 1

Logic

SIP AS 2

Logic

WS AS 1

Logic

WS AS 2

Logic

Logic = Service/Application Logic


8

jNetX solution takes advantage from its multi-protocols nature and from its access to low-level protocol details to solve the

problems referred above. For more information on jNetX Service Brokering and to get the full description and technology

comparison document, please contact your jNetX Account Manager or send an email to [email protected].

OTHER FUNCTIONAL ELEMENTS

SERVICE USAGE METERING & CHARGING

One of the very important functions of an SDF is to offer the capability to measure and subsequently to charge for the usage of

the services it delivers. There is no

reason why charging functions should

run on proprietary, standalone

environments.

This element typically contains

functions such as the BSS ones,

pertaining to the IT environment (and

more particularly to the SOA

environment as suggested by the

TeleManagementForum).

Nevertheless, a SOA environment is

nowadays unable to handle the session

control functions required for Online

Charging. This task is typically

achieved by pure Telecom Application

Servers (such as jNetX) and requires

carrier gradeness, low latency and very

high throughput capabilities. The

Rating and Account Balance

Management functions are currently

often replicated both on the Billing and

on the telecom IN Prepaid systems. Over time, these two features should also be centralized (instead of being replicated).

SERVICES & CAP ABILIT IES EXPOSURE

An end-user application, running into a specific execution

environment, delivers its services by invoking some interfaces,

APIs, which are sometimes called enablers or capabilities.

Telecom and IT service logic do not generally make use of the

same interfaces. The type of service logic running in the

Telecom environment requires access to low-level information

transported by the network protocol itself. Hence, Telecom

applications make use of low-level APIs such as defined by JCP

(JAIN APIs) or, possibly by OSA/Parlay that provide a higher

level of abstraction. The capabilities exposed by OSA/Parlay

APIs are nevertheless too complex and too low-level for the

large IT Web Services developer community. To address this

problem, Parlay and 3GPP have defined a specific set of Web

Event-Driven, Low Latency Telecom Execution Environments

Telecom Services

& Enablers


Service Bus (ESB)

Portal Layer


Usage Metering

BSS

Off-Line Charging(Mediation, Rating, ABMF)

Invoicing

Data Warehouse

ERP

Resource Management

Online Charging

Ra

ting

AB

MF

Mediation

Campaign Mgt



Portal Layer

Service Bus (ESB)



Parlay X

General WebServ

OSA/ParlayAPI / GW

Web ServicesBPM

NGINIMS Apps

JAIN APIs


9

Services interfaces, highly abstracted, that encapsulate network capabilities. These specifications are named Parlay X and are

exposed to the Web Services /SOA environment. These Web Services interfaces are so abstracted that they highly limit the

scope of services deliverable. The optimum configuration is to complement the SOA environment with a fully programmable

Web Services Gateway, not limited to a static protocol converter. As an example, when a simple “MakeACall” request is

received by the jNetX telecom application server over its Web Services interface, a fully programmable logic is instantiated into

the telecom SLEE. This logic defines how the call should be initiated. First, the logic could trigger the HSS (over Diameter) to

know if the subscriber has an IMS subscription. If yes, the call can be initiated directly using SIP. If not, the call could be

initiated directly over the legacy environment, using protocols such as INAP (and proprietary versions) or CAMEL (v4).

Alternatively, the call could be instantiated by triggering an IVR or using XMPP/Jingle (IETF protocol used by Softphone

providers such as GoogleTalk).

SERVICE POLICY & SECURITY

Service Policy & Security is an additional domain that

includes some IT and some Telecom functions. These

functions are different, sometimes complementary, but all

address a different type of service policy and security. As

an example, IT people would include functions like SOA

governance and 3rd

Party Service Level Agreement

Management while Telecom experts could typically refer to

the Policy Decision Function (PDF), to some Authorization

and Authentication functions or even to an OSA/Parlay

gateway framework.

SERVICE MANAGEMENT & PROVISIONING

One of the crucial tasks when building an SDF capable of

delivering a myriad of services is to create a layer that

will properly and efficiently manage these services.

There is no need to optimize functions like service

creation, service execution, service composition and so on

if at the end, all the benefits accumulated are lost due to a

slow, rigid and ineffective Management system.

Many Service Management & Provisioning tasks are

supported by IT technologies. OSS for example, as

stipulated by the TeleManagementForum can highly

benefit from a SOA architecture. CRM and PRM can be

easily supported by Java EE and its associated HTTP

Servlet and EJB containers elements.

Nevertheless, delivering the Operation, Administration &

Maintenance functions required for the Telecom space

remains very specific and is one of the most complex and

challenging tasks to achieve. IT companies entering into

this space have realized it the hard way. Delivering a switch-grade OA&M system for managing Telecom application servers

takes several years to tune in order to achieve a sufficient level of maturity acceptable by network operations engineers. jNetX

has dedicated a considerable amount of work over the last years to make its OA&M components compliant to such Telecom

environment.



Portal Layer

Service Bus (ESB)



Web ServicesBPM

NGINIMS Apps

PDF

SOAGovernance

OSA GWFramework

AAA

3rd PartySLA Mgt




Service Bus (ESB)

Portal Layer


Management

OSS

Provisioning

Activation

Capacity, Fulfillment

Assurance

Fraud Control

NMS

Supervision

Planning, Backup

Trouble Tickets

Relationship

CRM, PRM

Self-Care

OAM

Configuration, Reporting

Deployment, Upgrade

Device Mgt

Inventory


10

SERVICE & USER DATA

In most of existing networks infrastructure, user and

services data are spread across the network. As an

example, one subscriber may have data populated in

the HLR, HSS, Voicemail, Prepaid system, MMSC

and so on. This distribution increases the level of

complexity for many SDF functions such as

Provisioning, CRM, user authentication, etc.

Some operators have already started to concentrate

these data in some centralized User data repository.

The performance of the databases & directory

servers is significantly improving and standards from

3GPP and Liberty Alliance are getting more mature.

This shall allow, over time, an SDF to provide, a

seamless access to user and services data.

CONTENT MANAGEMENT & DELIVERY

Content Management and Delivery is becoming an

increasingly important part of an SDF. Functions

pertaining to the Management part like service

discovery, Digital Rights Management, content

acquisition, update, synchronization, aggregation

or access control are typically supported by IT

technologies. On the other hand, Content Delivery

requires low access to the network elements and

their appropriate protocols in order to control

media servers, to manage the quality of service or

to handle the proper media negotiation.

Both environments and types of functions are

required to finalize the delivery of the appropriate

and final content to the consumer.

SERVICE CREATION

Finally, the Service Creation function remains a key part of an end to

end SDF solution. Several operators and SDF vendors have started

initiatives in order to consolidate service creation across the different IT

and Telecom environments. The first integrated solutions are soon to

enter into the market and will have to mature across initial deployments.

jNetX is actively involved in these initiatives in a number of customer

and partner engagements.


Telecom Services

& Enablers


Service Bus (ESB)

Portal Layer


Content

Management

Discovery

Acquisition, Update, Sync

Aggregation(ex: Adv insertion)

Access Control(Parental, Anti-Spam)

DRM, Royalties

Rendering

Delivery

Media Reserv., QoS




Service Bus (ESB)

Portal Layer


Web ServicesBPM

IMS APPsNGIN

HLR

HSS

Data

User Data

Identity Mgt / Federation

Profile, Subscriptions

Account Balance,Flags, Lists

Personal Data (community, buddy list, content)

Service Data

Catalogue

Configuration

Discovery

Navigator

Service Logic

Properties

Icons

Errors


11

WHICH SERVICES FOR WHICH SDF ENVIRONMENT?

One of the obvious sources of confusion, when addressing Service Delivery Framework emanates from the type of services this

framework is actually intended to deliver. Historically, voice services ran on top of very robust, complicated and inflexible

black-box Intelligent Network platforms. It was so complex that many people started to assimilate IN systems to a core network

element (such as an MSC or an HLR). As a result, several IT-vendors have concentrated their efforts on building environments

for hosting services that do not require such a level of network complexity. Services typically addressed by these environments

are: SMS News, streaming of movie tracks, ringtone delivery, TV on mobile; find the closest restaurant, click-to-dial from a web

pages, etc. Fortunately, telecom technologies have also evolved and companies like jNetX have proven that complex telecom

applications around rich voice and messaging can now be delivered with an SDF that includes the proper Telecom Application

Service layer. Mission critical telecom services can now be designed and successfully delivered by a wide range of systems and

network integrators on top of flexible Java platforms. The range of services delivered will nevertheless highly depend on the

selected SDF architecture and supporting technologies as well as the business model that the operator embraces to decouple the

technology from the suppliers – offering the operator choices and competition for the development of new services. As

mentioned before, different services will have different requirements – for example, a “Prepaid” service would not have the

same requirements and constraints as a “News/Weather Forecast” service.

The first figure below highlights possible service architectures and associated containers/technologies used in SDF, while the

second figure illustrates which of these architectures (labeled 1 to 6) are suitable for running the corresponding services.

SIP Servlet

�

SL

JSLEE

�

SL

EJB or .NET

�

SL

Parlay X GW

EJB or .NET

�

SL

SIP Servlet

EJB or .NET

�

SL

SL

JSLEE

EJB or .NET

�

SL

SL

SL = Service Logic

Second Life

YouTube

SalesForce

News/Weather Forecast

Price Check

Find Closest Restaurant

Buddy Finder

Missed Call Alert

Virtual Receptionist

IP-PBX / IP Centrex

Pers.Ring Back Tone

Ring Back When Free

VPN / Wireless Office

Prepaid

= Not Recommended

= Possible but withLimitations

= Recommended

Telecom

Internet

Depending on the services that shall be running on the SDF, different containers should be used or associated.


12

JNETX POSITIONING & CONCLUSION

As explained in this document, disparate concepts of SDF are now progressively converging to a much more clearly defined set

of components that, working together, constitute an overall functional architecture. Telecom & IT components are more

precisely identified and the respective vendor products need to collaborate in order to optimize the delivery of the many different

types of services on the market: from IN services to pure Web-based applications.

Such a recognized SDF architecture clearly incorporates an IT (SOA) and a Telecom environment. jNetX is positioned as the

leader in the Telecom layer hosting mission-critical applications and exposing telecom abstracted assets to the IT Web Services

environment.

Legacy & IMS Core Any Access

SD

F

Telco AS

WS/SOA GWNGIN, IMS

SOA

Service Management (OSS,BSS, SLAs, etc.)

Non time critical and non protocol dependent end-user services

(find closest restaurant, click-to-dial, etc.)

Time-critical and possibly protocol dependent end-user services

(IN and IMS)

Telecom Gateway (capabilities exposure to WS/SOA domain)

jNetX positioning within an SDF

jNetX is an open, standards-based Java Telecom service platform that can run as a stand-alone solution or, when sharing

common services, be an integral part of a larger JavaEE environment (representing the Telecom layer).

jNetX network technology unlocks the Telecom space and enables operators to deploy a wide array of new revenue generating

applications on top of legacy and IP infrastructures. New service introduction models, inherited from the internet (like Beta

version) are now being adopted by operators to facilitate rapid and ongoing service delivery.

The flexibility of the jNetX platform and its traction on the market has led to the fostering of a rich ecosystem of partners – the

jNetX Developer Network Area (DNA) – offering operators worldwide a broad portfolio of network services. More than a

hundred network services are described in the jNetX DNA 100+ Network Service Catalogue to help Operators develop new

ideas, new business models and market strategies. This catalogue demonstrates how the telecom space can continue to produce

revenue generating services and expand its potential to deliver rich voice and messaging services across an evolving and

converging network infrastructure.

To learn how jNetX can help service providers run their business more efficiently and optimize their service delivery

infrastructure, please contact your jNetX representative or send an email to [email protected].

Documents

jNetX SDF White Paper