August 2008 Archives
Following in the series of market landscapes such as On Device Portal, Fixed Mobile Convergence, Service Management, and a very high level one on Service Delivery Platform (SDP). I'm presenting a richer SDP landscape, however, it is challenging to compare SDPs because of the vast scope of functionality and the numerous definitions that exist.
A definition I generally use is: a service delivery platform (SDP) is an IT-based environment enabling service creation 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; and the need to enable third-party companies to provision services through the service provider environment. Typically, most SDPs include: a service creation environment, a service orchestration environment, a service execution environment and third-party management. These definitions work well with architects, but for rest of us in the industry, it's still a little too abstract.
In the old SDP landscape I divided the suppliers according to their backgrounds, Network Equipment Providers, System Integrators or IT Vendors. This is useful in understanding where a supplier is coming from in their SDP proposition, but it does not help in understanding what's out their and who's suppling what. So to that end, I have a new SDP landscape. This breaks down the landscape across the main suppliers and what types of delivery platform they supply. There are many more than in this list, my objective here is to show a representative sample. Now the delivery platforms break down into two main segments content delivery (CDP) and service delivery (SDP), think of CDP as a subset of SDP.
The types of CDP are:
The types of SDP are:
A definition I generally use is: a service delivery platform (SDP) is an IT-based environment enabling service creation 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; and the need to enable third-party companies to provision services through the service provider environment. Typically, most SDPs include: a service creation environment, a service orchestration environment, a service execution environment and third-party management. These definitions work well with architects, but for rest of us in the industry, it's still a little too abstract.
In the old SDP landscape I divided the suppliers according to their backgrounds, Network Equipment Providers, System Integrators or IT Vendors. This is useful in understanding where a supplier is coming from in their SDP proposition, but it does not help in understanding what's out their and who's suppling what. So to that end, I have a new SDP landscape. This breaks down the landscape across the main suppliers and what types of delivery platform they supply. There are many more than in this list, my objective here is to show a representative sample. Now the delivery platforms break down into two main segments content delivery (CDP) and service delivery (SDP), think of CDP as a subset of SDP.
The types of CDP are:
- Managed Mobile Content: a CDP run and possibly hosted by the supplier on behalf operator which suppliers ring tones, wall papers, music, videos, games etc. to customers' mobile phones.
- Mobile Content: a CDP that is supplied to the operator who installs and runs the platform which suppliers ring tones, wall papers, music, videos, games etc. to customers' mobile phones.
- IPTV: a CDP for the STB (Set Top Box) over a broadband network.
The types of SDP are:
- Messaging: SDP focused upon premium messaging services.
- SIP application server: SDP focused on voice applications
- Business: SDP focused on business services and integrating into business processes.
- Real-Time charging: SDP component that enables real-time charging for services.
- 3rd Party Communications and Messaging: The OSA OSE, Parlay, JAIN SLEE, platforms.
- Service Creation /Management: SDP component focused on the operation processes for creating and managing services
- Unified SDP: An SDP created specifically to unify all the previous categories including CDP into a consistent framework. Critical features include being standards based, unified policy management, and extensive pre-integration.
Secure User Plane Location (SUPL, pronounced supple) in essence enables applications to directly talk to the AGPS (Assisted Global Positioning System) unit on the mobile phone, without the need to pay the operator for a location dip. SUPL potentially side-lines the operator out of providing location information; without the need for a costly, complex and power-draining full GPS (Global Positioning System) unit on the phone. From an operator's perspective, SUPL is a simple way to avoid the expense of a control plane location solution, instead using user data (IP) so it's part of the IP stack in the phone, provided they are able to control access to the SUPL API (Application Program Interface) on the phone.
Generally operators view SUPL with suspicion because AGPS chip-sets on the market lack a common SUPL API. Many AGPS phones lack a SUPL API, one large mobile operator estimates less than one third of their AGPS handset has a usable SUPL API. The method for an operator to ensure privacy management of SUPL when a customer is using a third party application remains unclear as its a handset issue not network PCE (Privacy Control Entity) issue. When customers click "yes' when a widget asks to use their AGPS unit, do they realize that widget is now tracking them? And when they find out they're being tracked, who do they complain to? How do they stop the tracking? The call will likely be to the operator to whom they're paying that monthly phone bill, so its' going to end up being an operator problem.
There is also a lack of agreement on handset APIs for autonomous AGPS, handset initiated AGPS and network initiated AGPS - a major gap. In some cases the API is chipset defined, in others its handset manufacturer defined, with generally no operator or operator group taking control of the current situation. Many operators are worried about privacy with SUPL, and many are waiting for the large operators in their market to define the standard. Hence we have a 'chicken and egg' situation with everyone looking at everyone else to solve the problem. Now with that said, SUPL has had some success in Japan and Korea; however, operators there tend to have far greater control over the value chain, especially handsets. Also some vertical solutions have appeared, such as the TCS Navigator which uses their own SUPL server, and is described in my Mobile World Congress 2008 Summary weblog article.
It's also important to realize there is no definitive location technology that works throughout an operator's network. GPS and AGPS do not well indoors, hence there is interest in handset based triangulation technologies such as A-FLT (Advanced Forward Link Trilateration) to provide enhanced location information indoors. So we're seeing hybrid location technology solutions across CellID, enhanced CellID, AGPS, SUPL, and handset based triangulation. This complexity in both the handset and network is delaying operators' decision making on advanced location infrastructure. So even through LBS services have been a potential for over a decade, we're still waiting to see them take off.
The problem I've described above is similar to that faced by the On Device Portal, discussed in these articles on ODP Evolution and ODP Landscape. And the solution to both these problems is likely the same. If operators define a standard secure API for mobile phone browsers to access capabilities on the phone such as the SUPL API, address book, or the many other goodies isolated on the phone (just like you can do with your PC web browser today), then many of these problems would go away. And it would go a long way down the road in operators opening their networks to the innovation made possible by the millions of developers on the internet, which brings me back to my favorite topic of the Telco API - think of this as the Telco Handset API, the complement of the Telco Network API.
Generally operators view SUPL with suspicion because AGPS chip-sets on the market lack a common SUPL API. Many AGPS phones lack a SUPL API, one large mobile operator estimates less than one third of their AGPS handset has a usable SUPL API. The method for an operator to ensure privacy management of SUPL when a customer is using a third party application remains unclear as its a handset issue not network PCE (Privacy Control Entity) issue. When customers click "yes' when a widget asks to use their AGPS unit, do they realize that widget is now tracking them? And when they find out they're being tracked, who do they complain to? How do they stop the tracking? The call will likely be to the operator to whom they're paying that monthly phone bill, so its' going to end up being an operator problem.
There is also a lack of agreement on handset APIs for autonomous AGPS, handset initiated AGPS and network initiated AGPS - a major gap. In some cases the API is chipset defined, in others its handset manufacturer defined, with generally no operator or operator group taking control of the current situation. Many operators are worried about privacy with SUPL, and many are waiting for the large operators in their market to define the standard. Hence we have a 'chicken and egg' situation with everyone looking at everyone else to solve the problem. Now with that said, SUPL has had some success in Japan and Korea; however, operators there tend to have far greater control over the value chain, especially handsets. Also some vertical solutions have appeared, such as the TCS Navigator which uses their own SUPL server, and is described in my Mobile World Congress 2008 Summary weblog article.
It's also important to realize there is no definitive location technology that works throughout an operator's network. GPS and AGPS do not well indoors, hence there is interest in handset based triangulation technologies such as A-FLT (Advanced Forward Link Trilateration) to provide enhanced location information indoors. So we're seeing hybrid location technology solutions across CellID, enhanced CellID, AGPS, SUPL, and handset based triangulation. This complexity in both the handset and network is delaying operators' decision making on advanced location infrastructure. So even through LBS services have been a potential for over a decade, we're still waiting to see them take off.
The problem I've described above is similar to that faced by the On Device Portal, discussed in these articles on ODP Evolution and ODP Landscape. And the solution to both these problems is likely the same. If operators define a standard secure API for mobile phone browsers to access capabilities on the phone such as the SUPL API, address book, or the many other goodies isolated on the phone (just like you can do with your PC web browser today), then many of these problems would go away. And it would go a long way down the road in operators opening their networks to the innovation made possible by the millions of developers on the internet, which brings me back to my favorite topic of the Telco API - think of this as the Telco Handset API, the complement of the Telco Network API.
The GSMA reported in August there are now 4 million new HSPA (High Speed Packet Access) subscribers a month. The total number of HSPA users has passed the 50 million mark globally from 11 million a year ago. Mobile Broadband is definitely taking off, as discussed in this previous weblog article.
When I was in the UK in July, I was chatting with a UK Operator's sales person as I installed a pay-as-you-go mobile broadband card in my laptop in their store. I was asking about the types of customers using the service, how long they'd been sold-out of the ZTE modems, and what returns they see. An interesting comment was the only returns are when the 3G service does not work at the customer's home, it shows there's a strong fixed to mobile substitution taking place for broadband.
But will mobile broadband provide the same experience as DSL broadband? Taking a typical 3G roll-out architecture of 3 E1s from a cellsite, which given the recent upgrades in HSDPA to 14.4 Mbit/s means the capacity problem isn't over the air, its on the backhaul, as I've discussed in this previous weblog article. Given the ATM cell tax, and other framing overheads, the maximum capacity available for the customers' broadband data is about 4.6 Mbit/s.
Now looking at the figure from a simple MB (megabyte) per month perspective, that gives 1.5 TB (terabytes) available over the month. Given an urban macro-cell covers between 1200 to 2000 connected customers, assuming 1500 customers means an average 1GB limit. Which at first glance would appear to provide adequate capacity even if 100% of the customer base were using mobile broadband.
However, the term I used in the title was customer experience. The key experience is the many customers watching YouTube or BBC iplayer. The video you see in the BBC iplayer today is encoded using the On2 VP6 codec at a bitrate of 500Kbps, though they've recently announced encoding using H.264 at 800 kbit/s. YouTube is a little more sedate 300 kbit/s.
So this means that one cell-site can only support 9 simultaneous On2 VP6 BBC iplayer streams, or 5 simultaneous H.264 streams, or 15 streams of the more sedate YouTube streams. And that's ignoring all the other browsing traffic (which increasingly includes annoying streaming video adverts rather than easy to ignore banner adverts) and P2P (peer to peer) traffic. Remember when Tiscali launched in the UK and struggled through inadequate backhaul, even today Tiscali still struggles with customer service.
A critical issue is what are the chances of within a cell-site 10 customers (0.66% penetration) watching a streaming video at the same time during that critical 6PM-11PM period? Unfortunately the statistics coming from the DSL ISPs (Internet Service Providers) appear to show that chance as significant today.
Some ISPs use GE (Gigabit Ethernet) from their DSLAMs into their metro/core networks today. Compare this to the 3E1s in the example above, which is 0.45% of the capacity of a GE. To maintain the same experience mobile operators are going to require lots of capacity deep in their network fast, and become more sophisticated than the DSL ISPs in managing the traffic over their 'longer access networks.' Especially in managing the highly visible streaming video traffic which customers will likely use as a yard-stick to compare ISPs performance in the near future.
When I was in the UK in July, I was chatting with a UK Operator's sales person as I installed a pay-as-you-go mobile broadband card in my laptop in their store. I was asking about the types of customers using the service, how long they'd been sold-out of the ZTE modems, and what returns they see. An interesting comment was the only returns are when the 3G service does not work at the customer's home, it shows there's a strong fixed to mobile substitution taking place for broadband.
But will mobile broadband provide the same experience as DSL broadband? Taking a typical 3G roll-out architecture of 3 E1s from a cellsite, which given the recent upgrades in HSDPA to 14.4 Mbit/s means the capacity problem isn't over the air, its on the backhaul, as I've discussed in this previous weblog article. Given the ATM cell tax, and other framing overheads, the maximum capacity available for the customers' broadband data is about 4.6 Mbit/s.
Now looking at the figure from a simple MB (megabyte) per month perspective, that gives 1.5 TB (terabytes) available over the month. Given an urban macro-cell covers between 1200 to 2000 connected customers, assuming 1500 customers means an average 1GB limit. Which at first glance would appear to provide adequate capacity even if 100% of the customer base were using mobile broadband.
However, the term I used in the title was customer experience. The key experience is the many customers watching YouTube or BBC iplayer. The video you see in the BBC iplayer today is encoded using the On2 VP6 codec at a bitrate of 500Kbps, though they've recently announced encoding using H.264 at 800 kbit/s. YouTube is a little more sedate 300 kbit/s.
So this means that one cell-site can only support 9 simultaneous On2 VP6 BBC iplayer streams, or 5 simultaneous H.264 streams, or 15 streams of the more sedate YouTube streams. And that's ignoring all the other browsing traffic (which increasingly includes annoying streaming video adverts rather than easy to ignore banner adverts) and P2P (peer to peer) traffic. Remember when Tiscali launched in the UK and struggled through inadequate backhaul, even today Tiscali still struggles with customer service.
A critical issue is what are the chances of within a cell-site 10 customers (0.66% penetration) watching a streaming video at the same time during that critical 6PM-11PM period? Unfortunately the statistics coming from the DSL ISPs (Internet Service Providers) appear to show that chance as significant today.
Some ISPs use GE (Gigabit Ethernet) from their DSLAMs into their metro/core networks today. Compare this to the 3E1s in the example above, which is 0.45% of the capacity of a GE. To maintain the same experience mobile operators are going to require lots of capacity deep in their network fast, and become more sophisticated than the DSL ISPs in managing the traffic over their 'longer access networks.' Especially in managing the highly visible streaming video traffic which customers will likely use as a yard-stick to compare ISPs performance in the near future.
Femtocell can be thought of as the "son of FMC," rather than using a Bluetooth or WiFi air interface and a specialized phone; it re-uses the GSM or CDMA air interface and potentially your existing mobile phone. But given FMC's (Fixed Mobile Convergence) poor market acceptance; why should femtocell be any different? Reviewing femtocell against the FMC service models discussed in this previous weblog article on FMC, it can be thought of as a hybrid of the dual mode and substitution models. In that, a short-range wireless system is used in the office/home, however, that interface is the same as the wide area network (GSM/CDMA). It enables all communications to be managed by one converged operator and hence does not require the enterprise to maintain existing PBX equipment.
Examining some of the FMC failures we've seen in the market. Both Deutsche Telekom (DT) and Korea Telecom withdrew their FMC services, blaming poor service take-up. A critical issue was the price paid for the service was not significantly lower than the savings incurred by the customer. This was then compounded by the usability issues around calls being made at home or in the office and not being charged at the cheaper FMC rates; as well as the teething battery life issues. There was a period in 2006 when it appeared every DT employee was looking for a power socket to recharge their T-One phone.
When T-One was launched a T-One customer paid about €70 per month to get the full range of services, after having paid connection charges of €185. The absolute minimum spent, forgoing the DSL connection, came to about €55. But even this was expensive compared to E-Plus' flat rate charge of €25 per month with unlimited calls to national fixed and E-Plus numbers (calls to other operators cost 25 cents) - and hence Fixed Mobile Conversion won out!
BT Fusion Plus's old pricing was 12.50GBP per month plus call charges, so for calls to a UK landline, standard pricing was 80p for one hour, with BT Fusion Plus that dropped to 10p for one hour. Definitely cheaper, but to recoup the 12.50 per month fixed fee, required about 18 hours of calls (over 1000 minutes). It didn't take customers long to work out that wasn't entirely a good deal. Today BT bundles the Fusion cost into the minutes plans.
However, a notable exception to these failures is Orange Unik. France Telecom benefited from a large retail base of broadband customers, and was able to exploit the success of its home gateway, Livebox, which supported Unik (avoiding multiple boxes). When launched the Unik service offered unlimited, flat-rate calling to all national PSTN numbers for €10 per month, or unlimited calling to all national PSTN numbers and Orange mobile numbers for €22 per month. Which is a significant value given the penetration of Orange customers for fixed, mobile and broadband is significant in France. It was also a fraction of the cost of Deutsche Telekom's T-One service. This enabled Unik to achieve a penetration of 500k customers in Feb '08, see this weblog article from SofNet. Though this remains a small percentage of FT's total 25.3M customer base; and even in this success-case, the business case is slight as it relies heavily upon the inclusion of savings in retention and acquisition costs.
The critical lessons are: keep the service as transparent as possible with respect to user experience; keep the saving as simple to understand and as significant as possible for the customer.
So now let's examine some of the hurdles femtocell is climbing:
So femtocell will need to be integrated into the broadband modem provided by the converged operator, and its cost will likely need to be borne by the operator not the customer, else the customer will choose a cheaper service. The proposition needs to be very simple, e.g. unlimited calling at home for all your phones and 80% off international calls for only 10 GBP per month. The user experience must also be simple; when the customer is at home they just call like anywhere else, the calls are just cheaper; no checking for signal levels or listening for multiple tones when dialing.
Femtocell enables mobile broadband traffic to be off-loaded in the home and office, this is an important benefit for the operator not the customer. Operational and commercial issues need to be resolved, as described above. But once solved, and its operation is transparent to the customer, we will likely see femtocell bundled in all converged operator broadband modems. The main challenge facing femocell technology is the timing of when the operational and commercial issues can be solved to meet the conditions necessary for market success not technology trial success.
Examining some of the FMC failures we've seen in the market. Both Deutsche Telekom (DT) and Korea Telecom withdrew their FMC services, blaming poor service take-up. A critical issue was the price paid for the service was not significantly lower than the savings incurred by the customer. This was then compounded by the usability issues around calls being made at home or in the office and not being charged at the cheaper FMC rates; as well as the teething battery life issues. There was a period in 2006 when it appeared every DT employee was looking for a power socket to recharge their T-One phone.
When T-One was launched a T-One customer paid about €70 per month to get the full range of services, after having paid connection charges of €185. The absolute minimum spent, forgoing the DSL connection, came to about €55. But even this was expensive compared to E-Plus' flat rate charge of €25 per month with unlimited calls to national fixed and E-Plus numbers (calls to other operators cost 25 cents) - and hence Fixed Mobile Conversion won out!
BT Fusion Plus's old pricing was 12.50GBP per month plus call charges, so for calls to a UK landline, standard pricing was 80p for one hour, with BT Fusion Plus that dropped to 10p for one hour. Definitely cheaper, but to recoup the 12.50 per month fixed fee, required about 18 hours of calls (over 1000 minutes). It didn't take customers long to work out that wasn't entirely a good deal. Today BT bundles the Fusion cost into the minutes plans.
However, a notable exception to these failures is Orange Unik. France Telecom benefited from a large retail base of broadband customers, and was able to exploit the success of its home gateway, Livebox, which supported Unik (avoiding multiple boxes). When launched the Unik service offered unlimited, flat-rate calling to all national PSTN numbers for €10 per month, or unlimited calling to all national PSTN numbers and Orange mobile numbers for €22 per month. Which is a significant value given the penetration of Orange customers for fixed, mobile and broadband is significant in France. It was also a fraction of the cost of Deutsche Telekom's T-One service. This enabled Unik to achieve a penetration of 500k customers in Feb '08, see this weblog article from SofNet. Though this remains a small percentage of FT's total 25.3M customer base; and even in this success-case, the business case is slight as it relies heavily upon the inclusion of savings in retention and acquisition costs.
The critical lessons are: keep the service as transparent as possible with respect to user experience; keep the saving as simple to understand and as significant as possible for the customer.
So now let's examine some of the hurdles femtocell is climbing:
- Interference between with macrocell and with neighbouring femtocells (especially in flats/condos/apartments) in real-world deployments.
- Quality and range. If a femtocell operates at the same frequency as the macrocell, the range could be as low as 10-20m. If on clear spectrum, the range can be as great as 150m. But many operators are not in a position to offer clear spectrum.
- Network management. A similar problem to DSL modems or VoIP terminal adapters, which has recently been addressed by the adoption of the TR-069 family of specifications.
- Handover. Macro-to-femto handover is tough (Sprint's AIRAVE femtocell trial does not do such handover). Femto-to-macro handover is easy, perhaps too easy; if there is a charging difference the FMC billing problems previously described may recur.
- Tolerance to broadband backhaul limitations. Latency, synchronization, and limited uplink, especially in rural locations where customers may be inclined to adopt femto to improve their in-home mobile performance. It likely requires the femtocell provider to also provide broadband to ensure end-to-end quality of service.
- Billing. Critical issue for previous FMC services, as it resulted in many complaints and high churn
- Security. Opportunities for fraud increase as the operator extends their mobile network into the public domain.
- Network integration and evolution. Operators will likely use the Iub interface, other approaches are also possible but costs/performance/evolution complicates the decision (e.g. just voice support, or voice and data).
So femtocell will need to be integrated into the broadband modem provided by the converged operator, and its cost will likely need to be borne by the operator not the customer, else the customer will choose a cheaper service. The proposition needs to be very simple, e.g. unlimited calling at home for all your phones and 80% off international calls for only 10 GBP per month. The user experience must also be simple; when the customer is at home they just call like anywhere else, the calls are just cheaper; no checking for signal levels or listening for multiple tones when dialing.
Femtocell enables mobile broadband traffic to be off-loaded in the home and office, this is an important benefit for the operator not the customer. Operational and commercial issues need to be resolved, as described above. But once solved, and its operation is transparent to the customer, we will likely see femtocell bundled in all converged operator broadband modems. The main challenge facing femocell technology is the timing of when the operational and commercial issues can be solved to meet the conditions necessary for market success not technology trial success.
This article follows on from a previous article that reviewed LTE (Long Term Evolution, also know as 4G). Several people asked why I had not included a fuller discussion on the 4G core in that article. It is because LTE is an access technology; my focus of the article was on the access where there is a lot of hype at the moment. However, to support LTE a new core is required, as specified by the SAE (System Architecture Evolution).
In the standards community the names have now become E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) for LTE, and EPS (Evolved Packet System) for SAE. Think of the SAE as a pure IP core without RNCs (Radio Network Controller) or SGSNs (Serving GPRS Support Node). So in principle an operator would need to run two core networks to support the existing 3G network and the new 4G network. Given the slight benefits of LTE compared to HSPA+, as discussed in a previous article, this would appear to be a significant barrier for LTE adoption.
However, the NEPs (Network Equipment Providers) are providing a range of solutions that enable the existing 3G core to evolve towards the SAE vision such as:
The 3GPP core market is roughly $1B in size, and the top three suppliers in this market are: Ericsson (34%), NSN (33%), Huawei (15%). Who unsurprisingly are the three players behind the three different solutions that evolve the core towards the SAE vision. Given we're likely to see the number of mobile broadband customers worldwide explode to over 1B over the next 4 years, mobile core costs could potential to explode as well. Hence the immediate focus on moving the RNC and SGSN out of the data path and into the control plane, to better manage broadband growth.
Specifically the motivations for this early transition are:
In the standards community the names have now become E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) for LTE, and EPS (Evolved Packet System) for SAE. Think of the SAE as a pure IP core without RNCs (Radio Network Controller) or SGSNs (Serving GPRS Support Node). So in principle an operator would need to run two core networks to support the existing 3G network and the new 4G network. Given the slight benefits of LTE compared to HSPA+, as discussed in a previous article, this would appear to be a significant barrier for LTE adoption.
However, the NEPs (Network Equipment Providers) are providing a range of solutions that enable the existing 3G core to evolve towards the SAE vision such as:
- One Tunnel, moving the SGSN into the control plane;
- Direct Tunnel, moving the SGSN and RNC into the control plane; and
- Internet HSPA: control-plane SGSN and RNC is integrated into the NodeB.
The 3GPP core market is roughly $1B in size, and the top three suppliers in this market are: Ericsson (34%), NSN (33%), Huawei (15%). Who unsurprisingly are the three players behind the three different solutions that evolve the core towards the SAE vision. Given we're likely to see the number of mobile broadband customers worldwide explode to over 1B over the next 4 years, mobile core costs could potential to explode as well. Hence the immediate focus on moving the RNC and SGSN out of the data path and into the control plane, to better manage broadband growth.
Specifically the motivations for this early transition are:
- Lower cost/bit - depending on the architecture it has the potential to reduce equipment costs by 80%;
- Preparation for 4G - in other words avoid a dual core situation which would delay operators buying LTE BSRs (Base Station Routers). Note the base stations are where NEPs make their money, so they're keen to remove any barriers; and
- Ease of integration of non-3GPP access (i.e. network convergence, avoiding multiple cores and service platforms).
