Panel briefing by Nitin Patel, VP Strategic Marketing, Telenity

Q.1. How important is the SDP definition in achieving clarity in a complex environment?

Today each vendor's SDP definition and implementation vary. A standards based SDP environment will eliminate confusion in the market.

SDP's create the foundation for rapid service deployment. An SDP provides a complete ecosystem for the rapid deployment, provisioning, execution, management and billing of value-added services for both mobile and fixed networks.

Vagueness of SDP definition allows vendors to provide solution that address individual market segments (e.g. point solution). As a result, instead of a broad range of operator-hosted and third party services, only a limited number of vendor-specific services will be commercially deployed, severely limiting potential revenues, flexibility, market share and competitive agility.

SDP in the past used to be IT focused. With the new evolving SDP, IT and Network boundaries are merging thus generating need for end to end service architecture that addresses 1) Mobility, 2) New Technologies IMS/3G, 3) Security 4) Convergence and 5) Intelligent Terminals

It is very important that operator make the right SDP decisions. Adding more service silos will only result in a service architecture that is even more complex. On the other hand one large SDP which has pre defined services and features by definition has to be over engineered and therefore incorporate functionality that may not be required. SDP should meet operator business requirement and enable re-use solution components across multiple applications/services (both existing and new) on a common infrastructure.

Q.2. Where do current definitions reside, and how is uncertainty over them affecting the market?

There is no generally accepted definition of SDP. SDP is an evolving part of network architecture that has not been fully defined. In fact the term SDP is miss-leading because the features and functionality do not reside on a single platform, but rather constitute a whole service creation, deployment and delivery environment. In this context SDP must interface with

1. OSS/BSS
2. Value Added Service Enablers
3. Service/Applications both inside and outside the service providers environment

An SDP is an environment or framework that is blend of components to create, delivery, provision, personalize, charge/bill and manage services independent of the network technology.

Vendors SDP strategy depend on the SDP definition. General consensus is to provide an end-to-end SDP framework along with partner ecosystem components.

IT and application server vendors such as IBM, Oracle, BEA, SUN, HP, Microsoft tend to bring IT integration and development tools into network service delivery environment.

IBM regards SDP as very important part of a successful next generation strategy and key foundation upon which to adopt emerging architecture such as IMS. The SDP is comprised of three primary environments.

1. Service Creation Environment (comprised of integrated set of tools for defining, developing and testing of service lifecycle.
2. Service Deployment Environment (comprised of Service Execution (Service Brokerage) and User Service Domain)
3. Service Delivery Environment (comprised of Network Delivery Domain – Access Network connection (GSM, CDMA, WiFi, DSL, Cable) and Transport network provides resource for the transport of payload

Oracle launched its SDP strategy. It is built on the foundation of its Fusion middleware and comprises of following main components:

1. Parlay and SLEE interfaces to communicate with legacy network – provided with acquisition of Net4Call
2. SIP interfaces to communicate with NGN SIP/IMS network – provided with acquisition of HotSIP
3. Network Adaptors
4. An Enabler framework – with set of out-of-box common components – includes SIP servlet container, Presence and Location Server
5. Roadmap includes – Call Control, Charging Enabler, Device Management, and a set of out-of-box services.

Network equipment vendors tend to bring tighter SDP integration with IMS and embed with its core network equipment to sell.

For example, Nokia's SDP is based on the definitions proposed by Moriano Group.
An SDP provides a complete ecosystem for the rapid deployment, provisioning, execution, management and billing of value-added-services.
Nokia' SDP framework is derived from the Value Chain (used to define operators business requirements). It is comprised of:

1. Terminal or End User
2. Delivery Channel
3. Service Logic – service process flow whereby facility is provided for the external 3 rd party service provider to seamlessly integrate with OSS/BSS.
4. Value Chain Management provides functionality to manage the relationships between the end-users, operators, content providers and service providers
5. Customer Care & Billing
6. Service Integration – (Service Integration and Exposure) – that binds everything together

Telenity plays a key role in shortening SDP deployment cycle by providing pre-integrated SDP components in the partner eco-system. This SDP components enable 3^rd party application development for both legacy and next-gen IMS/3G networks : -

1. Out-of-box value added services for real-time (e.g., VoIP, video) and non-real-time (e.g., messaging, location-based)
2. A service creation and execution environment
3. A content management and delivery system
4. A location gateway
5. A network interface gateway (Parlay/X)
6. A messaging gateway
7. Integration with partner service orchestration (SO)
8. Common OSS/BSS framework integration
9. Open standard compliance such as BPEL, SIP, OSA/Parlay, and OMA OSE

Q.3. What are the business drivers for Service Delivery Platforms?

The primary business driver of the SDP is to help operators increase ARPU and lower CAPEX/OPEX associated with value-added services. Some key drivers are as follows:

1. Extend the life of existing services
2. Lower the cost of introducing new services to almost 50% cost reduction
3. Extend services across network and devices
4. Improve the profitability of niche services

Q.4. How can the environment be simplified and what roles to the links in the value chain need to play?

What is clearly needed is the means to do more with less. Pre-integration of SDP components is key as it will simplify the overall roles in the value chain.

Service Orchestration Architecture (SOA) closes the gap between the technical and business requirements. By exposing the application service data as standardized and open interface format- XML, Web Services. SO offers level of service interoperability across different applications and data sources. e.g. Single Sign On (SSO) and common security features. This will also aid in breaking down the Sileod deployment of infrastructure.

Q.5. How is the lack of standards in the SDP space impacting on operators?

Although there are areas that lack standards such as interface to OSS/BSS and customer care, we have seen good progress in the development of key standards according to Mr. Gurol Akman, Chief Architect at Telenity and they are good enough for SDP implementation today.

Standards of prime interest to 3rd-party developers are as follows:

Web Services (WS) technologies (WSDL, SOAP, UDDI) in general. Latest stable releases are as follows: WSDL v2.0, SOAP v1.2, UDDI v3.0.x (although v2.0 is more commonly deployed), Parlay X WS v2.0, and Parlay WS v5.0. Parlay X WS v2.0 represents a significant upgrade to v1.0 and it introduces several new categories of interfaces in the areas of presence, multimedia conf, address list mgmt, and call handling.

Standards for service execution areas follows:

J2EE based AS (and its derivatives) seems to be dominating the market. J2EE is no longer considered to be an enterprise-only technology -- thanks to advancements in J2EE 1.4 and JCA 1.5 specs. SIP-servlet based AS (which is usually built upon J2EE) seems to have a great chance of success in the IMS market. JSR 116 spec is what drives the SIP-servlets and it's modeled after the HTTP specs. SIP servlet and JAIN SIP API standards are considered to be complementary, meaning that it is possible to build a SIP servlet model using JAIN SIP API underneath.

Standards for service orchestration are as follows:

Flexible workflow management tool and a run-time environment (a.k.a. workflow engine) for business process mgmt are essential for a successful SDP deployment. BPEL seems to be the most talked about and widely used standard here. Note however many AS vendors seem to be involved in building proprietary BPM frameworks/tools of their own.

OSS/J initiative (which provides a suite of Java, XML, and WS APIs that are aligned with the next-gen OSS standards) seems to be most notable one in this area. It's supported by the TMF (Tele Mgmt Forum).

Q. 6. 'Operator's won't implement any SDP until the standards are in place, will they?'

Operators have to understand their architectural needs. Also they must decide what legacy services needs to be supported with SDP environment. Operators are deploying SDP today. However, we most will take the evolutionary approach to full SDP deployment until full standards are in place.

Because current offering vary broadly, operators need to prioritize their selection criteria but should seek flexible solution with strong integration partner.

• Organize a strategic application/services planning group
• Establish an initial application set- this will help create a strong business case and accelerate ROI.
• Recognize the magnitude of integration
• Get to know SOA/Web Services that enable new business model. SOA also helps extend lifecycle of existing services
• Seek solution that integrate with legacy ecosystem environment and support services.