jNetX copyright 2001 - 2008

S ERVICE D ELIVERY F RAMEW ORK (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.

I NTRODUCTION
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 indepth 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 worlds leading, multinational 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.

jNetX copyright 2001 - 2008 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 operators 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 & K EY F UNCTIONAL E LEMENTS T he list of challenges that needs to be addressed in order to build a harmonized SDF architecture is substantial.
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. Below is a

Service Logic Execution Service Creation Service Exposure

Service & User Data

Services Delivery Framework

Service Management & Provisioning

Service Composition & Interaction Service Metering & Monitoring

(Charging, Accounting, Billing, Reporting)

Service Policy Security, AAA, SLA Mgt

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).

jNetX copyright 2001 - 2008

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 marketing@jnetx.com.

S ERVICE E XECUTI ON E NVIRONMENTS

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.

IT domain

SOA
Portal Layer

Flow/Process-Driven , Bus./Enterprise Execution Environments IT Services & Enablers Web Services BPM Service Bus (ESB)

Telco AS
Telecom Services & Enablers NGIN IMS Apps

Event-Driven, Low Latency Telecom Execution Environments

Telecom domain

jNetX copyright 2001 - 2008 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

jNetX copyright 2001 - 2008 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.

S ERVICE C OMPOSI TI ON
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 providers 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.

jNetX copyright 2001 - 2008 For an IT engineer, Service Composition often refers to the so-called Service Orchestration mechanism that consists of invoking and Portal Layer composing independent services called Flow/Process-Driven , Bus./Enterprise Execution Environments business processes to create a new composite Web Services IT Services Orchestration service. These business processes expose a & Enablers BPM (BPM/ BPEL/ BizTalk) well defined interface (described with a Service Bus (ESB) WSDL document). Languages like BPEL and BizTalk have emerged to organize and to SCIM describe IT service orchestration, which IMS APPs Telecom Services NGIN & Enablers follows a process-driven approach. On the IN Service other hand, Telecom engineers, in order to Event-Driven, Real Time Telecom Execution Environments Mediation 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.

IT Telecom

For SIP-initiated service composition, the main technologies available on the market are shown in the figure below: 1. 2. 3. 4. S-CSCF iFC initial Filter Criteria based mechanism jNetX Service Brokering (SCIM part) SIP Servlet Application Router (SIP Servlet 1.1) 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.

jNetX copyright 2001 - 2008 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 IPPBX 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.
Logic Logic Logic Logic Logic Logic

IN AS 1

IN AS 2
CAP2, 3 SINAP INAP CS1+

SIP AS 1
SIP IETF

SIP AS 2
ISC 3GPP

WS AS 1
Web Services Microsoft WES

WS AS 2

Facilities
- DBs (HSS, HLR, LDAP servers, ) - VAS (LBS, SMSC, MMSC, WAP GW, etc)

jNetX

Logic

IN Mediation / SCIM

INAP CS1, CS2 CAP v1 to v4 INAP CS1+, SINAP, CS1R, etc. AIN, WIN

SIP (IETF, ISC)

Legacy CS
Logic

= Service/Application Logic

IMS/SIP

jNetX copyright 2001 - 2008 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 marketing@jnetx.com.

O THER F UNCTI ONAL E LEMENTS

S E R VI C E U S AG E M ET ER I N G & C H AR G I N G
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 Usage Metering run on proprietary, standalone environments. BSS
Off-Line Charging This element typically contains (Mediation, Rating, ABMF) functions such as the BSS ones, Invoicing Portal Layer pertaining to the IT environment (and more particularly to the SOA Data Warehouse Flow/Process-Driven , Bus./Enterprise Execution Environments environment as suggested by the IT Services ERP & Enablers TeleManagementForum). Nevertheless, a SOA environment is Resource Management Service Bus (ESB) nowadays unable to handle the session Mediation control functions required for Online Telecom Services Campaign Mgt Charging. This task is typically & Enablers achieved by pure Telecom Application Event-Driven, Low Latency Telecom Execution Environments Servers (such as jNetX) and requires carrier gradeness, low latency and very high throughput capabilities. The Online Charging 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).

S ER V I C E S & C AP AB I L I T I E S E XP O S U R E
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

Rating

ABMF

Portal Layer

Flow/Process-Driven , Bus./Enterprise Execution Environments IT Services & Enablers Web Services BPM Service Bus (ESB)

General WebServ

Parlay X

Telecom Services & Enablers

NGIN IMS Apps

OSA/Parlay API / GW

Event-Driven, Real Time Telecom Execution Environments

JAIN APIs

jNetX copyright 2001 - 2008 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).

S E R VI C E P O LI C Y & S E C U R I T Y
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.

Portal Layer

3 rd Party SLA Mgt

Flow/Process-Driven , Bus./Enterprise Execution Environments IT Services & Enablers Web Services BPM Service Bus (ESB)

SOA
Governance

OSA GW Framework AAA

NGIN IMS Apps

Telecom Services & Enablers

Event-Driven, Real Time Telecom Execution Environments

PDF

S E R V I C E M AN AG E M E N T & P R O V I S I O N I N G
Management OSS
Provisioning Activation Capacity, Fulfillment Assurance Inventory Fraud Control
Portal Layer

OAM
Configuration, Reporting Deployment, Upgrade

Relationship
CRM, PRM Self-Care

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.

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

NMS
Supervision

IT Services & Enablers Service Bus (ESB)

Planning, Backup Trouble Tickets

Telecom Services & Enablers Event-Driven, Real Time Telecom Execution Environments

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.
Device Mgt

jNetX copyright 2001 - 2008

S ER V I C E & U S ER D AT A
Data User Data
Portal Layer

Identity Mgt / Federation

Flow/Process-Driven , Bus./Enterprise Execution Environments Web Services BPM IT Services & Enablers Service Bus (ESB)

Profile, Subscriptions Account Balance, Flags, Lists Personal Data (community, buddy list, content)

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.

IMS APPs NGIN

Telecom Services & Enablers

Service Data
Event-Driven, Real Time Telecom Execution Environments

Catalogue

Configuration
HSS

Discovery

HLR

C O N T EN T M AN AG E M E N T & D E L I V E R Y
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.

Content Management
Discovery

Acquisition, Update, Sync Aggregation (ex: Adv insertion) Access Control (Parental, Anti-Spam) DRM, Royalties

Portal Layer

Flow/Process-Driven , Bus./Enterprise Execution Environments IT Services & Enablers Service Bus (ESB)

Rendering
Telecom Services & Enablers Event-Driven, Real Time Telecom Execution Environments

Delivery
Media Reserv., QoS

S ER V I C E C R E AT I O N
Icons Service Logic

Navigator

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.

Errors

Properties

10

jNetX copyright 2001 - 2008

W HICH S ERVICES FOR W HICH SDF ENVIRONMENT ? O ne 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.
SL

= Service Logic EJB or .NET

SL

EJB or .NET
SL

EJB or .NET
SL

EJB or .NET
SL

SIP Servlet
SL

JSLEE
SL

Parlay X GW

SIP Servlet
SL

JSLEE
SL

Internet 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 Telecom Prepaid
= Possible but with Limitations = Not Recommended = Recommended

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

11

jNetX copyright 2001 - 2008

J N ET X POSITIONING

& C ONCLUSION

A s 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.

SOA

Service Management (OSS,BSS, SLAs, etc.) Non time critical and non protocol dependent end-user services (find closest restaurant, click-to-dial, etc.)

SDF
WS/SOA GW NGIN, IMS

Telco AS Legacy & IMS Core Any Access

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 marketing@jnetx.com.

12