Telecoms Evolution from "Silo" to "Application Converged"

Telecom convergence had became a very popular and common words in telecoms industry. Service providers, vendors and standardization body had always coming out with various suggestion and solution to reduce the CAPEX ( capital expenditure) and also OPEX ( operational expenditure ) . Telecoms technology continuously changing and evolving everyday in the area of transport approach (TDM, VoIP) , protocol handshake (H.323, IS41, MAP, SIP) and etc.

Why Silo based deployment model exist?

3 separate silo application of different type of network

There is various type of telecoms network exist in current telecom eco-systems such as wireline network, wireless network (GSM, CDMA) and IP Network ( IMS, NGN ). Each of them having thier own predefine protocol hand-shake and transportation medium, thus each service creation or application deployment consist of the detail network protocol handling to ensure the functionality of the service across the network. No doubts, the cost of maintaining various service creation and application will be increase and become expensive when come to customization The result of the silo based deployment will increase the operators or service providers CAPEX and OPEX .

Towards Application and Service Converged ( Parlay or ASC )?

When Telecoms meet IT, this is where the convergence come in and few infrastructure concept had been adopted such as SDP ( Server Delivery Platform ) and IMS ( IP Multimedia Subsystems ). The emerge of SDP is to cut down the complexity of service creation and application to various type of network by providing the network abstraction without knowing the details of the core networks flow and functionality.

Parlay Gateway in the position of Service Delivery Platform

Parlay / Parlay X gateway came in to serve the central point of network resource management as well as network abstraction to the service creation and application that deployed in the SDP systems.

The maturity of the Parlay Gateway deployment is still on the evaluation by the community. On the other hands, some may think that the deployment of Parlay Gateway will incurre another silo and add on CAPEX at the network layer. Another party may think Parlay Gateway doesn't address the legacy IN ( Intelligent Network) application.

ASC as the ultimate solutions?

AppTrigger Application Session Controller for the support of legacy network

AppTrigger, a telecoms solution company had come out the idea of Application Session Controller (ASC). The ASC will be sitting in the middle of application and the core network layer by providing a unified data session controller across various network e.g. TCAP ( wireless network), SIP ( IP-Network ) and INAP ( wired line network ) as well as other legacy network.

Similarity and Conclusion
Both Parlay and ASC serve the similarly which to provide the network abstraction to the applications and services creation. In order to converge various network systems would need some time and redefine the standard API, besides the practicality and business use case would also need to be considered.

One things for sure for telecoms service provider and vendor would need to find their way to maintain single service creations logic e.g. (Location Base Services as well as Caller RingTone) regardless GSM networks, IMS based SIP network or fix line network.

Thus a unified session application handshake protocol would be needed and network specific enabler (plugin model) need to exist to achieve the real convergence environment.


resources and link:-
AppTrigger Application Session Controller
App Trigger 1st IN based systems intergrate with IMS implementation
Parlay Group

OMA Open Service Environemnt and J2EE Realization

After working few years as J2EE Developer in mobile content provider company specialist in location based services, I had jump to an organization that focusing on core network development or integrations (SS7, IN, MAP, TCAP etc...) using C/C++. I would say there is some big gap in terms of mindset/knowledge/skill when you development mobile application (e.g. televotes, value added SMS) and the core network infrastructure development (SMSC, Virutal HLR for Prefered Roaming etc). This is pretty much like jumping from IT worlds into Telecomms world.

Fews year ago, operators already stared to have content provider arggregation platform like (MSDP in Maxis, CPA in DiGi) which provide the API of performing some SMS, MMS, WAP Push, Charging without understanding the low-level of core-network functionality. At that time, those platform are useful and increase the ARPU of the operator by allowing more content providers to join in the telco world with more valued added services.

With the emerge of 3G, LTE or NGN, telco industry is going to transform from old days TDM E1 to Ethernet based IP (SIGTRAN, SIP based) networks for the upcoming IMS(IP Multimedia Subsystems) or other SDP platform etc. Parlay group and OMA(Open Mobile Alliance) had come out lots of concept, framework to link this two world IT and Telecomms. The Open Service Environment (OSE) that been proposed by OMA are here to further define the framework for Service Delivery irregarless of legacy GSM Network (SS7, PSTN, ISUP,MAP) and the new emerging IMS (SIP, Diameter etc).

The OMA OSE Framework:- (source from Parlay Group Publishcation)

• IO : The interface that expose to Application (3rd Party or Internal) to communicate with the Enabler (Service Capable Server e.g. Call Control, Location Function, Messenging etc.)
• IO+P: Same as IO but with the extra parameter that required for the Policy Enforcer to perform soem execution
• I1: Interface to of the Enbaler to the OnM, Monitoring, Load Balancing Execution Environment
• I2: Interface to the network resources here can be Parlay X, to the Parlay Gateway or propietory implementation using JCA. (Java Connector Architecture)

The J2EE Realization of OSE with Oracle SDP Framework: (Source from Oracle Publication)-

• Enabler Framework can be as simple as a Java Bean of POJO or EJB Container that act as the Service Capable Server with the help of the Network Adapter.
• ESB (Enterprise Service Bus) as a back-bond messenging infrastructure in the Open Service Environment.It enable the communication between the BSS (Execution Environement for monitoring, version control, load balance, availibility status), Enabler component and the policy enforcer here by the SGW (Service Gateway) in Oracle SDP Architecture.
• BPEL(Business Processing Execution Language) ussage also enhance the work flow of the Service Gateway.
• JCA 1.5, SIP Servlet Container will be the network adapter to the SIP protocol for IMS implementation or legacy network protocol liked MAP, CAMEL etc. depending on the propietory implementation to the network resources.
• The Oracle SDP Architecture can be achieve using JBoss J2EE Application Server or Oracle Application Server. With the help of the load balancer to front the 3rd party application (HTTP, SOAP) traffic, scalabiliy of the Open Service Environment / Service Delivery Platform can be achieved.
  

The Enabler Framework to be intergrate into J2EE (Source from Oracle Publication):-

The sample of the Enabler Framework that can be an J2EE Application component or as small as the EJB comprise in the EJB container.

Hope with this post will give an ideal on how the Service Delivery Framework should be designed so that it is fully plugable and the scalability of the feature can be added by additonal Enabler component for different network to achieve a Service Gateway that transparent to the underlaying network no matter is (GSM, 3G IMS, NGN for Fix Line etc). Telecomms world and technology is changing fast, a good designed of platform can promise fast deployment and compete in the challenging and fast changing industry.


Material Source From:-