May 2008 Archives
I would like to thank Jeroen Visser from BT for his suggestion of this article to explain SOA, SDP and IMS; and then explain how they fit together.
Service Oriented Architecture Defined
SOA (Service Oriented Architecture) has emerged as a successful integration framework for BOSS (Business and Operational Support Systems) within operators. We are now witnesses that success driving SOA into the services layer of operators. But what is SOA?
SOA is just an evolution of distributed computing and modular programming. It's an IT (Information Technology) architecture (note, it does not specify the technology for its implementation) enabling the creation and execution of business processes, packaged as services, throughout their lifecycle. The promise of SOA is that the marginal cost of creating the nth application is near zero, as all of the software required exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application. From a telco perspective it's a flexible architecture that enables service innovation, mass customization and leverages an IT standard, avoiding yet another expensive 'telco-special.'
SOA defines the IT infrastructure to allow different applications to exchange data to form business processes, e.g. a "new employee set-up process" that could require services from multiple IT platforms, ordering of equipment (e.g. phone, mobile and PC), etc. SOA separates these functions into distinct units "services," which can be distributed over a network and can be combined and reused to create new business applications, e.g. "temporary employee set-up process." These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
Services are unassociated units of functionality, which have no calls to each other embedded in them. This causes some confusion from a telco perspective as services are what customers pay for, so the term SOA services is often used to differentiate from end-customer services. SOA services typically implement functions such as filling out an online application for an account, viewing an online bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.
Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. Generally web services are used to implement the SOA. A web service refers to clients and servers that communicate using XML messages that follow the SOAP standard. In such systems, there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI) is used to discover those services. In SOA's implementation XML has been used extensively to create data which is wrapped in a description container. The services themselves are typically described by WSDL, and communications protocols by SOAP, with UDDI being used to discover those services.
However, SOA is not tied to a specific technology. It can be implemented using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having fore-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.
Of course nothing stays the same. Advanced SOA or SOA 2.0 is the "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture (EDA). An event is simple a change of state, e.g. new employee contract signed, which then triggers an business process. Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates responsiveness, because event-driven systems are, by design, able to cope with unpredictable and asynchronous environments. EDA is complementary to SOA as its just adding the triggers to start processes and enable processes to adapt to changing circumstance, i.e. exist in the real world.
And finally on the practical application of these concepts, some of the issues are:
Service Delivery Platform Defined
What is a 'service delivery platform'? It really depends upon with whom you are talking. Are they a vendor trying to sell IMS (IP Multimedia Subsystem); or a Java games download platform; or an operator responsible for value-added communication services, IPTV, or content service? Each will likely give quite different answers. Service delivery platforms have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T (International Telecommunications Union) back in the 1980s. In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.
This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components, that good old chestnut of 'remove the service silos to save money.' The benefits of taking a horizontal (layered) approach versus a vertical (stove-pipe) are: faster and cheaper time to market, and enabling service innovation independent of switch vendor. Most operators have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring-back tone or prepay billing. The IN SDP has not achieved the ubiquity of deployment as a re-usable layer within the telecommunication software stack; rather it is a component of a vertical application. The barrier remains 'incrementalism', that is, it is cheaper to deploy service X as a vertical than incur the additional costs of deploying an SDP.
As networks have evolved from circuit-centric to packet-centric, the SDP has extended its reach beyond communication services, to include content services, streaming services, and even broadcast services. So the SDP is now positioning across all services and access, an "all-encompassing service delivery architecture". But the challenge of 'incrementalism' remains. In addition, there is no one standards body leading the creation of reference SDP architectures or implementation norms. Currently, we're seeing initiatives for vendor-specific frameworks, or common application-network interfaces within an operator group.
There are a number of standards bodies working in the SDP space including Parlay, Open Mobile Alliance (OMA) Service Environment (OSE) and the TMF's SDF TeleManagement Forum's (TMF) Service Delivery Framework (SDF). There are many other service layer initiatives including Product and Service Assembly Initiative (PSA) which are not covered in this article. OSA Parlay is part of the 3GPP IMS, and exposes enablers such as presence and call control to applications. The OSE is as architecture that provides a common structure and rule set for specifying enablers, e.g. presence, location, etc. The TMF SDF definition provides the terminology and concepts needed to reference the various components involved, such as applications and enablers, network and service exposure, and orchestration. The TMF uses these in the definition of the processes and entities needed for managing the SDF components.
A service delivery platform (SDP) is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This need comes from two major trends: The need to cut costs in the service creation process, in saturated markets service providers want to differentiate through their service offerings; and the need to enable third-party companies to provision services through the service provider environment. Typically, most SDPs include: service creation environment, service orchestration environment, service execution environment and third-party management.
I abstract this a little further and think of the SDP as having 3 main systems:
I find the above definition helps in understanding where a supplier is coming from in their definition of and SDP. Stepping back from the definitions and functions, as discussed in the article "An Industry At The Crossroads," the SDP will be the innovation engine in operators. It will have multiple elements for multiple suppliers, what is critical is not the architecture (as this article shows, we have more than enough of those). Rather we must focus on the business requirements of service innovation to drive a lean implementation that's going to evolve far faster than any previous operator platform.
IP Multimedia Subsystem Defined
I've talked about the IP Multimedia Subsystem (IMS) in several other articles such as SofNet Day 3, The Divergence of CDMA and UMTS Operators on IMS, SCIM: Its time for operators to sort out the services layer mess, Critical Gap in IMS/SDP business cases. Simply IMS is an architecture for delivering internet protocol (IP) multimedia sessions (e.g. voice and video) across multiple access networks. This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer. Hence why I focus on the IP session control capabilities within IMS and the relevance to operators such as Verizon and Sprint in supporting voice over their EVDO network.
So How Do SOA, SDP and IMS Fit Together?
After that lengthy definition section, summing up how these acronyms fit together:
Service Oriented Architecture Defined
SOA (Service Oriented Architecture) has emerged as a successful integration framework for BOSS (Business and Operational Support Systems) within operators. We are now witnesses that success driving SOA into the services layer of operators. But what is SOA?
SOA is just an evolution of distributed computing and modular programming. It's an IT (Information Technology) architecture (note, it does not specify the technology for its implementation) enabling the creation and execution of business processes, packaged as services, throughout their lifecycle. The promise of SOA is that the marginal cost of creating the nth application is near zero, as all of the software required exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application. From a telco perspective it's a flexible architecture that enables service innovation, mass customization and leverages an IT standard, avoiding yet another expensive 'telco-special.'
SOA defines the IT infrastructure to allow different applications to exchange data to form business processes, e.g. a "new employee set-up process" that could require services from multiple IT platforms, ordering of equipment (e.g. phone, mobile and PC), etc. SOA separates these functions into distinct units "services," which can be distributed over a network and can be combined and reused to create new business applications, e.g. "temporary employee set-up process." These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following:
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
Services are unassociated units of functionality, which have no calls to each other embedded in them. This causes some confusion from a telco perspective as services are what customers pay for, so the term SOA services is often used to differentiate from end-customer services. SOA services typically implement functions such as filling out an online application for an account, viewing an online bank statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.
Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. Generally web services are used to implement the SOA. A web service refers to clients and servers that communicate using XML messages that follow the SOAP standard. In such systems, there is often machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL), and Universal Description, Discovery and Integration (UDDI) is used to discover those services. In SOA's implementation XML has been used extensively to create data which is wrapped in a description container. The services themselves are typically described by WSDL, and communications protocols by SOAP, with UDDI being used to discover those services.
However, SOA is not tied to a specific technology. It can be implemented using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having fore-knowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.
Of course nothing stays the same. Advanced SOA or SOA 2.0 is the "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture (EDA). An event is simple a change of state, e.g. new employee contract signed, which then triggers an business process. Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates responsiveness, because event-driven systems are, by design, able to cope with unpredictable and asynchronous environments. EDA is complementary to SOA as its just adding the triggers to start processes and enable processes to adapt to changing circumstance, i.e. exist in the real world.
And finally on the practical application of these concepts, some of the issues are:
- Complexity - SOA is very flexible, perhaps too flexible, SOA service definitions do result in capabilities being misinterpreted.
- Security - security at the service level is not appropriate; it must be managed at the network level.
- Interoperability - as it's an architecture the implementation allows lots of opportunities for many incompatibilities between vendor implementations. So when a vendor claims SOA compliance, the response is 'So what!' SOA compliance does not guarantee interoperability of services between operators, or even interoperability between SOA-based functions within an operator.
- Processing power - its important to implement what is necessary, do not build a 'Grand Architecture,' build lean.
- Hype - the standards are still evolving, and will continue to do so. Hence build lean as next year or within 18 months the implementation will need to evolve to remain competitive.
Service Delivery Platform Defined
What is a 'service delivery platform'? It really depends upon with whom you are talking. Are they a vendor trying to sell IMS (IP Multimedia Subsystem); or a Java games download platform; or an operator responsible for value-added communication services, IPTV, or content service? Each will likely give quite different answers. Service delivery platforms have a long history; their roots can be traces to the FN (Feature Node) that emerged in the intelligent network (IN) concept defined by the ITU-T (International Telecommunications Union) back in the 1980s. In the FN a SCE (Service Creation Environment) enabled operators to create new communication services without the need to change the software in the exchanges.
This evolved into the IN SDP (Service Delivery Platform), an architecture that enables re-use of service components, that good old chestnut of 'remove the service silos to save money.' The benefits of taking a horizontal (layered) approach versus a vertical (stove-pipe) are: faster and cheaper time to market, and enabling service innovation independent of switch vendor. Most operators have IN implemented in their networks, though most of the SDP implementations tend to be bundled into a specific service implementation, for example caller ring-back tone or prepay billing. The IN SDP has not achieved the ubiquity of deployment as a re-usable layer within the telecommunication software stack; rather it is a component of a vertical application. The barrier remains 'incrementalism', that is, it is cheaper to deploy service X as a vertical than incur the additional costs of deploying an SDP.
As networks have evolved from circuit-centric to packet-centric, the SDP has extended its reach beyond communication services, to include content services, streaming services, and even broadcast services. So the SDP is now positioning across all services and access, an "all-encompassing service delivery architecture". But the challenge of 'incrementalism' remains. In addition, there is no one standards body leading the creation of reference SDP architectures or implementation norms. Currently, we're seeing initiatives for vendor-specific frameworks, or common application-network interfaces within an operator group.
There are a number of standards bodies working in the SDP space including Parlay, Open Mobile Alliance (OMA) Service Environment (OSE) and the TMF's SDF TeleManagement Forum's (TMF) Service Delivery Framework (SDF). There are many other service layer initiatives including Product and Service Assembly Initiative (PSA) which are not covered in this article. OSA Parlay is part of the 3GPP IMS, and exposes enablers such as presence and call control to applications. The OSE is as architecture that provides a common structure and rule set for specifying enablers, e.g. presence, location, etc. The TMF SDF definition provides the terminology and concepts needed to reference the various components involved, such as applications and enablers, network and service exposure, and orchestration. The TMF uses these in the definition of the processes and entities needed for managing the SDF components.
A service delivery platform (SDP) is an IT-based environment, enabling service creation in an environment that does not rely on a specific network element enabler. This need comes from two major trends: The need to cut costs in the service creation process, in saturated markets service providers want to differentiate through their service offerings; and the need to enable third-party companies to provision services through the service provider environment. Typically, most SDPs include: service creation environment, service orchestration environment, service execution environment and third-party management.
I abstract this a little further and think of the SDP as having 3 main systems:
- Content Delivery Management: System that ingests, presents and delivers content to customers on their mobiles, STBs (Set Top Boxes), PCs or other devices.
- BOSS integration: Processes associated with service creation, delivery and life-cycling.
- Telco API: Exposing capabilities from the network to operator services, partner/co-branded applications and 3rd party applications.
I find the above definition helps in understanding where a supplier is coming from in their definition of and SDP. Stepping back from the definitions and functions, as discussed in the article "An Industry At The Crossroads," the SDP will be the innovation engine in operators. It will have multiple elements for multiple suppliers, what is critical is not the architecture (as this article shows, we have more than enough of those). Rather we must focus on the business requirements of service innovation to drive a lean implementation that's going to evolve far faster than any previous operator platform.
IP Multimedia Subsystem Defined
I've talked about the IP Multimedia Subsystem (IMS) in several other articles such as SofNet Day 3, The Divergence of CDMA and UMTS Operators on IMS, SCIM: Its time for operators to sort out the services layer mess, Critical Gap in IMS/SDP business cases. Simply IMS is an architecture for delivering internet protocol (IP) multimedia sessions (e.g. voice and video) across multiple access networks. This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer. Hence why I focus on the IP session control capabilities within IMS and the relevance to operators such as Verizon and Sprint in supporting voice over their EVDO network.
So How Do SOA, SDP and IMS Fit Together?
After that lengthy definition section, summing up how these acronyms fit together:
- IMS is service control for IP multimedia sessions; it sits between the network (transport) and the SDP, think of it being within the control layer of the network. An operator does not require IMS, but they need IP session control whether it be SIP/soft-switch based or IMS based.
- SDP is service management across content-based and session-based services; think of it as the services layer of the network. Most operators have SDP components in their network already, they're just not integrated into a coherent services layer.
- SOA is an architecture the SDP can be based upon that leverages IT volumes. But as discussed in the definition of SOA, being 'SOA compliant' is a bit like saying 'based on modular software programming techniques.'
The title is a bit of an oxymoron, how can a 'start-up' also be the largest inter-operator mobile community in the World? I'm being a little loose in the definition of 'start-up' as airG is really a profitable, established business. However, they still have the entrepreneurial zeal of a fresh-face start-up, and being secreted in Vancouver has enabled them to achieve something quite remarkable with little fanfare.
While Bay Area mobile community start-ups struggle with triple digit churn, struggle to break passed the 1M customer mark, and raise tens of millions in VC cash due to the perceived value of the passing 'eyeballs'. airG's mobile community has more than 20 million unique users worldwide and is interconnected to more than 100 mobile operators and media companies globally including Sprint Nextel, AT&T, Rogers, TELUS, Virgin Mobile, Orange, Boost Mobile, Vodafone and MTV Asia. And most importantly is making a profit. Yes! a Mobile 2.0 community that's making a profit rather than burning investor cash in the hope that advertisers do not wake up to the fact that they're being used by the rest of the value chain, i.e. some social networks are seeing click-through rates of 2-4 per 10,000 impressions; that's not an advertising campaign, that's an accident!
airG was founded in 2000 by Frederick Ghahramani, Vincent Yen and Bryce Pasechnik, originally called AirGames, they focused upon WAP games. They quickly discovered that game-play on WAP isn't much fun. However, they had a lobby and chat function, then soon discovered that people didn't logon to AirGames to play WAP games, rather to chat. Hence the name change and focus on community services.
airG highlights an important point that I touched upon when I reviewed Miniweb, just as Miniweb is not putting the web on a TV, its creating interactive TV. airG is not putting a web-based community on the phone, its enabling a mobile community. The user experience is different. In North America and Western Europe, broadband internet access has a high penetration, most people access their web services (e.g. communities) through a PC, and some treat the mobile as an 'always-on' connection to their communities when they're not in front on the PC. This clouds the perception of most in the industry as the vast majority of people in the world do not access the internet through a PC, they access it through a mobile phone. For example, there is over 20 times the number of mobile customers to broadband customers in India, here community is accessed through the mobile. airG has demonstrated the use case is significantly different, even in countries with high broadband internet penetration.
A critical issue with mobile communities is interoperability across network 'islands'. We'll be discussing in the panel session "Telco 2.0 and Web 2.0: Making Money Together?" at the The Voice Peering Forum (June 23-24th, San Francisco). airG has shown the power of enabling inter-operator mobile communities, and built a profitable business. Its good to see a Mobile 2.0 business being built on sound commercial principles, rather than the usual Bay Area process of "burn the VC cash giving stuff away for free to get as many eye-balls to your site/application as possible, create a monetization story, find a buyer, and exit on an inflated multiple before the business model needs to be really proven out."
While Bay Area mobile community start-ups struggle with triple digit churn, struggle to break passed the 1M customer mark, and raise tens of millions in VC cash due to the perceived value of the passing 'eyeballs'. airG's mobile community has more than 20 million unique users worldwide and is interconnected to more than 100 mobile operators and media companies globally including Sprint Nextel, AT&T, Rogers, TELUS, Virgin Mobile, Orange, Boost Mobile, Vodafone and MTV Asia. And most importantly is making a profit. Yes! a Mobile 2.0 community that's making a profit rather than burning investor cash in the hope that advertisers do not wake up to the fact that they're being used by the rest of the value chain, i.e. some social networks are seeing click-through rates of 2-4 per 10,000 impressions; that's not an advertising campaign, that's an accident!
airG was founded in 2000 by Frederick Ghahramani, Vincent Yen and Bryce Pasechnik, originally called AirGames, they focused upon WAP games. They quickly discovered that game-play on WAP isn't much fun. However, they had a lobby and chat function, then soon discovered that people didn't logon to AirGames to play WAP games, rather to chat. Hence the name change and focus on community services.
airG highlights an important point that I touched upon when I reviewed Miniweb, just as Miniweb is not putting the web on a TV, its creating interactive TV. airG is not putting a web-based community on the phone, its enabling a mobile community. The user experience is different. In North America and Western Europe, broadband internet access has a high penetration, most people access their web services (e.g. communities) through a PC, and some treat the mobile as an 'always-on' connection to their communities when they're not in front on the PC. This clouds the perception of most in the industry as the vast majority of people in the world do not access the internet through a PC, they access it through a mobile phone. For example, there is over 20 times the number of mobile customers to broadband customers in India, here community is accessed through the mobile. airG has demonstrated the use case is significantly different, even in countries with high broadband internet penetration.
A critical issue with mobile communities is interoperability across network 'islands'. We'll be discussing in the panel session "Telco 2.0 and Web 2.0: Making Money Together?" at the The Voice Peering Forum (June 23-24th, San Francisco). airG has shown the power of enabling inter-operator mobile communities, and built a profitable business. Its good to see a Mobile 2.0 business being built on sound commercial principles, rather than the usual Bay Area process of "burn the VC cash giving stuff away for free to get as many eye-balls to your site/application as possible, create a monetization story, find a buyer, and exit on an inflated multiple before the business model needs to be really proven out."
As requested by reader feedback, I'm providing some foresight on up-coming conferences I'm attending, rather than just reviewing conferences I've attended. For June I'll be running panel sessions at Sigma Systems's first user conference and at the Voice Peering Forum.
Sigma Systems's first user conference (June 4th-6th, Barton Creek Resort, registration is free), will explore the next generation of consumer and business oriented services, including insight and discussion around emerging trends and technology developments in the following areas: targeted advertising, evolution of commercial VoIP & data services, global deployments in mobile broadband services, evolution to on-demand services, converged applications over video networks, data and multimedia services and IT back-office transformation. In the OSS Consolidation article article I included Sigma Systems in the Service Fulfillment Landscape.
At the user conference I'm running the panel session "Where's the Mobile Industry Going?" with John Namovic, Managing Partner at Deloitte; and Wedge Greene, Industry Guru. The session's objective is to help the audience understand how mobile is going broadband from those working on the 'bleeding edge' of the mobile industry. Providing a comprehensive global overview of the mobile operator's evolution to broadband; including network evolution, new services and applications, emerging business models (MNO vs. MVNO), and review of important lessons learned. In particular we'll be reviewing mobile broadband services, evolution to LTE (Long Term Evolution), xVNO economics (Virtual Network Operator (where x = mobile, fixed, converged and possibly even cable)), and FMC (Fixed Mobile Convergence) successes and failures.
The Voice Peering Forum (June 23-24th, San Francisco), a biannual conference, brings together over one hundred unique organizations from all segments of the information technology and telecommunications industry to network and discuss the latest in peering, routing and interconnection of networks and the applications they support. A good overview of the event is provided in this video. I'm running a panel session on the first day entitled, "Telco 2.0 and Web 2.0: Making Money Together?" This session will examine how the Web 2.0 paradigm is impacting telcos and how they are adapting to co-opt this paradigm to maintain service relevance in the IP-centric world.
Some of the questions we'll be discussing in the panel are: What is meant by Telco / Web 2.0? What is the state of current service provider Telco 2.0 / Web 2.0 activities? What capabilities can telcos expose that Web 2.0 companies need? What are Web 2.0 companies doing today to bypass the telcos for various service enablers? Where is the money to be made by the telcos and saved by the third party entities? How are operator's going to make these capabilities inter-operable across their network 'islands?' Peering 2.0!
On the panel are Mike Lee, CSO Rogers; Francesco Fraccalvieri, Head of Innovation Telecom Italia; Stefan Kuentz, Swisscom; Asha Vellaikal, Orange; and T. Ty Wang, Senior Director, Oracle. The objective in bringing together such a senior and diverse range of panel members is to generate a diversity of insights from people at the bleeding edge of service innovation, but link it back to the brutal simplicity that for such innovation to be successful it's got to work between operators.
I hope both panel sessions will provide some unique insights and through bringing together such senior practitioners in the industry provide an opportunity to share best practices.
Sigma Systems's first user conference (June 4th-6th, Barton Creek Resort, registration is free), will explore the next generation of consumer and business oriented services, including insight and discussion around emerging trends and technology developments in the following areas: targeted advertising, evolution of commercial VoIP & data services, global deployments in mobile broadband services, evolution to on-demand services, converged applications over video networks, data and multimedia services and IT back-office transformation. In the OSS Consolidation article article I included Sigma Systems in the Service Fulfillment Landscape.
At the user conference I'm running the panel session "Where's the Mobile Industry Going?" with John Namovic, Managing Partner at Deloitte; and Wedge Greene, Industry Guru. The session's objective is to help the audience understand how mobile is going broadband from those working on the 'bleeding edge' of the mobile industry. Providing a comprehensive global overview of the mobile operator's evolution to broadband; including network evolution, new services and applications, emerging business models (MNO vs. MVNO), and review of important lessons learned. In particular we'll be reviewing mobile broadband services, evolution to LTE (Long Term Evolution), xVNO economics (Virtual Network Operator (where x = mobile, fixed, converged and possibly even cable)), and FMC (Fixed Mobile Convergence) successes and failures.
The Voice Peering Forum (June 23-24th, San Francisco), a biannual conference, brings together over one hundred unique organizations from all segments of the information technology and telecommunications industry to network and discuss the latest in peering, routing and interconnection of networks and the applications they support. A good overview of the event is provided in this video. I'm running a panel session on the first day entitled, "Telco 2.0 and Web 2.0: Making Money Together?" This session will examine how the Web 2.0 paradigm is impacting telcos and how they are adapting to co-opt this paradigm to maintain service relevance in the IP-centric world.
Some of the questions we'll be discussing in the panel are: What is meant by Telco / Web 2.0? What is the state of current service provider Telco 2.0 / Web 2.0 activities? What capabilities can telcos expose that Web 2.0 companies need? What are Web 2.0 companies doing today to bypass the telcos for various service enablers? Where is the money to be made by the telcos and saved by the third party entities? How are operator's going to make these capabilities inter-operable across their network 'islands?' Peering 2.0!
On the panel are Mike Lee, CSO Rogers; Francesco Fraccalvieri, Head of Innovation Telecom Italia; Stefan Kuentz, Swisscom; Asha Vellaikal, Orange; and T. Ty Wang, Senior Director, Oracle. The objective in bringing together such a senior and diverse range of panel members is to generate a diversity of insights from people at the bleeding edge of service innovation, but link it back to the brutal simplicity that for such innovation to be successful it's got to work between operators.
I hope both panel sessions will provide some unique insights and through bringing together such senior practitioners in the industry provide an opportunity to share best practices.
Just summarizing my panel session speech on day 3 of SofNet, "A Pragmatic Approach to Developing IMS-Services." I addressed two questions I'm often asked.
"Is IMS dead?" Both Sprint and Verizon are deploying their flavors of IMS for the simple reason they decided voice over EVDO (the CDMA version of 3G) will be supported by VoIP, so they needed a standard IP session control layer, to which IMS provides a solution. I discussed this previously in the "The Divergence of CDMA and UMTS Operators on IMS" weblog entry. By 'flavor,' I mean they are using some of the specifications within IMS as a guide, its not a 'soup-to-nuts' implementation of the current IMS specifications. Now NTT and SKT have taken an aggressive approach to deploying IMS, with a number of services including PTT (Push To Talk) and virtual PBX, but they traditionally adopt technologies early to give their national suppliers an international competitive edge with early reference customers and accelerating their national suppliers' position on the learning-curve.
For UMTS operators voice is supported as a circuit over the RAN (Radio Access Network), so there is no need for an IP session control layer, yet. Hence most UMTS operators have not deployed IMS. On the fixed side, most operators have implemented softswitch solutions, and in some cases there are scalability issues, there they are evaluating whether IMS provides a more scalable solution, but the key word is evaluating. So IMS has not failed, rather its core capability of IP session control is seeing pragmatic deployment, where it makes business sense. Now, standards bodies as always tend to go beyond their initial scope, so the standards engineers can maintain the frequent flyer status, and IMS has moved into service management aspects.
This leads to the second question I'm often asked, "Are IMS and SDP in competition?" Immediately we have the problem of definition, what is an SDP? Paraphrasing what Humpty Dumpty said to Alice, "It means whatever I chose it to mean." In practice there are three main elements, BOSS (Business and Operational Support Systems), Content Delivery and the Telco API (checkout this entry for more info "The Telco API: Potential to raise ARPU by up to 36%"). Here we have lots of deployment examples such as Sprint's business mobility framework, AT&T's U-Verse, Airtel's managed SDP, Vodafone Live! etc. So the SDP is happening, and is more successful than IMS. Its focus is service management, not IP session control. So at present they are not competing, and if the focus of IMS remains IP session control then they will not compete.
But back to the topic of the panel, IMS-Services. If someone starts talking about IMS or SDP-Services, they have an agenda, they're trying to sell or promote a network technology, and making a fundamental error in looking at the problem from the wrong-end. Services are supported by capabilities, and those capabilities are implemented with network technologies. Services come become technology, as technology enables implementation. Of course user experience comes first, and then services fulfill the experience, but that's covered in the "A Critical Gap that Means most Service Platform (IMS/SDP) Business Cases Keep Failing" entry.
Overall the conference was worth attending, though there was a significant gap around specific enabled services. To claim the conference is focused on Software and Networks will require much greater participation from the other members of the value chain, including media, web 2.0 companies, and internet application developers.
"Is IMS dead?" Both Sprint and Verizon are deploying their flavors of IMS for the simple reason they decided voice over EVDO (the CDMA version of 3G) will be supported by VoIP, so they needed a standard IP session control layer, to which IMS provides a solution. I discussed this previously in the "The Divergence of CDMA and UMTS Operators on IMS" weblog entry. By 'flavor,' I mean they are using some of the specifications within IMS as a guide, its not a 'soup-to-nuts' implementation of the current IMS specifications. Now NTT and SKT have taken an aggressive approach to deploying IMS, with a number of services including PTT (Push To Talk) and virtual PBX, but they traditionally adopt technologies early to give their national suppliers an international competitive edge with early reference customers and accelerating their national suppliers' position on the learning-curve.
For UMTS operators voice is supported as a circuit over the RAN (Radio Access Network), so there is no need for an IP session control layer, yet. Hence most UMTS operators have not deployed IMS. On the fixed side, most operators have implemented softswitch solutions, and in some cases there are scalability issues, there they are evaluating whether IMS provides a more scalable solution, but the key word is evaluating. So IMS has not failed, rather its core capability of IP session control is seeing pragmatic deployment, where it makes business sense. Now, standards bodies as always tend to go beyond their initial scope, so the standards engineers can maintain the frequent flyer status, and IMS has moved into service management aspects.
This leads to the second question I'm often asked, "Are IMS and SDP in competition?" Immediately we have the problem of definition, what is an SDP? Paraphrasing what Humpty Dumpty said to Alice, "It means whatever I chose it to mean." In practice there are three main elements, BOSS (Business and Operational Support Systems), Content Delivery and the Telco API (checkout this entry for more info "The Telco API: Potential to raise ARPU by up to 36%"). Here we have lots of deployment examples such as Sprint's business mobility framework, AT&T's U-Verse, Airtel's managed SDP, Vodafone Live! etc. So the SDP is happening, and is more successful than IMS. Its focus is service management, not IP session control. So at present they are not competing, and if the focus of IMS remains IP session control then they will not compete.
But back to the topic of the panel, IMS-Services. If someone starts talking about IMS or SDP-Services, they have an agenda, they're trying to sell or promote a network technology, and making a fundamental error in looking at the problem from the wrong-end. Services are supported by capabilities, and those capabilities are implemented with network technologies. Services come become technology, as technology enables implementation. Of course user experience comes first, and then services fulfill the experience, but that's covered in the "A Critical Gap that Means most Service Platform (IMS/SDP) Business Cases Keep Failing" entry.
Overall the conference was worth attending, though there was a significant gap around specific enabled services. To claim the conference is focused on Software and Networks will require much greater participation from the other members of the value chain, including media, web 2.0 companies, and internet application developers.
