Last week I chaired sessions at two co-located conference in Berlin - Policy Control, and Mobile Broadband. Some of the sessions involved the usual handwringing about data "explosions" and so-called OTT providers, but others posed some really interesting issues about how and where control over mobile broadband gets instantiated in operators' infrastructure and businesses.
I was particularly struck by a couple of operator speakers coming from very different perspectives - the IT and Network sides of two telcos. It is no news that there is still something of a gulf between these these two worlds, but I hadn't realised quite how vigorously that plays out in the policy management space - and by extension, in congestion/traffic management as well. Together with a very detailed interview I did with a vendor, it's led me to a few observations and conclusions.
In a nutshell, network-oriented policy is about controlling costs, while IT-based policy is about revenues. Yes, there are many nuances and shades of grey, but that simple observation has helped clarify a lot in my mind.
In particular, it encapsulates why I find it hard to buy into the "monetisation" stories from many of the network-side vendors: in general, those pitches involve trying to define plans and tariffs based on what the network can see on its own, with minimal integration into the billing/charging side of the house. This is why so many network vendors are adamant about application-based charging - their boxes have visibility of packets, flows and so forth, and they are looking for a reason to extend from basic control (eg throttling P2P) to more value-added capabilities, such as driving tariffs. But many of those processes have unacceptably high levels of false-positives and false-negatives, and are at the mercy of shifts in application structure and user behaviour that are hard to discern from inside the network. (For example, the mashup phenomena I've discussed many times before). This means that superficially good ideas have a credibility gap when viewed through the lens of practicality.
Conversely, the IT-integrated policy functions are much more oriented around users - who the subscriber is and what they're entitled to, rather than trying to decode what they're doing on an instantaneous basis. And in that circumstance, there is much less vagueness to contend with. If data consumption is associated with me or you, there's no 95% confidence interval - it's known to 100% accuracy.
Now obviously the network-side policy & DPI infrastructure still has to be the measurement and enforcement point - for example ensuring that traffic is counted and caps or tiers are enacted - but that's driven by the user and data-plan, rather than a complex internal feedback loop based on realtime interpretation of the user's activities.
I agree with the vendor I spoke to that this will change over time - but the key dimension will be around the network identifying when there is actual congestion occurring. "If a cell is actually full with data traffic, then take actions XYZ, starting with those subscribers that are both lower priority and who are doing something like video streaming". This will need to come from the radio as well - simply looking at TCP from back on the Gi interface by the gateway won't cut it.
In a way, I suppose you could rephrase the cost/revenue description above as being: "Charging-based policy is about prevention. Network-based policy is about cure". In other words, the IT-based approach attempts to moderate users' behaviour in advance, through segmentation and templating. The network-based approach is there to fix things, when problems occur - especially congestion. Over time, the cures will become much more granular and targetted, while the prevention strategies will become more subtle and sophisticated.
Related to this is the observation that IT departments are often more responsive to the needs to operators' marketing functions than networking groups. Rather than forever trying to standardise, they tend to have a more pragmatic view towards customisation and flexibility - something that is much-needed with controlling mobile data. There is also much more likely to be a willingness to involve the end-user in the process, for example through a trend towards on-device self-care portals for visibility and tariff upsell.
I'm still trying to get my head fully around all this - but distilling all the conversations I've had recently I am moving to the view that charging-driven policy use cases are, on the whole, more plausible and workable than those that are purely driven by the network. This is also true of issues around dealing with mobile video - transparent "optimisation" of content, without reference to user details is only ever going to be a partial (and often unsatisfactory) solution.
EDIT - within hours of posting this piece, I saw this news item about Verizon, which seems to underscore my point. Although implementation details are thin, it sounds like the company is using a combination of network-based congestion detection, plus subscriber records to pick out the "usual culprits" as warranting throttling. Being in the US, Net Neutrality obviously plays an important part in the approach, and this appears neutral in terms of content/service differentiation.
I was particularly struck by a couple of operator speakers coming from very different perspectives - the IT and Network sides of two telcos. It is no news that there is still something of a gulf between these these two worlds, but I hadn't realised quite how vigorously that plays out in the policy management space - and by extension, in congestion/traffic management as well. Together with a very detailed interview I did with a vendor, it's led me to a few observations and conclusions.
In a nutshell, network-oriented policy is about controlling costs, while IT-based policy is about revenues. Yes, there are many nuances and shades of grey, but that simple observation has helped clarify a lot in my mind.
In particular, it encapsulates why I find it hard to buy into the "monetisation" stories from many of the network-side vendors: in general, those pitches involve trying to define plans and tariffs based on what the network can see on its own, with minimal integration into the billing/charging side of the house. This is why so many network vendors are adamant about application-based charging - their boxes have visibility of packets, flows and so forth, and they are looking for a reason to extend from basic control (eg throttling P2P) to more value-added capabilities, such as driving tariffs. But many of those processes have unacceptably high levels of false-positives and false-negatives, and are at the mercy of shifts in application structure and user behaviour that are hard to discern from inside the network. (For example, the mashup phenomena I've discussed many times before). This means that superficially good ideas have a credibility gap when viewed through the lens of practicality.
Conversely, the IT-integrated policy functions are much more oriented around users - who the subscriber is and what they're entitled to, rather than trying to decode what they're doing on an instantaneous basis. And in that circumstance, there is much less vagueness to contend with. If data consumption is associated with me or you, there's no 95% confidence interval - it's known to 100% accuracy.
Now obviously the network-side policy & DPI infrastructure still has to be the measurement and enforcement point - for example ensuring that traffic is counted and caps or tiers are enacted - but that's driven by the user and data-plan, rather than a complex internal feedback loop based on realtime interpretation of the user's activities.
I agree with the vendor I spoke to that this will change over time - but the key dimension will be around the network identifying when there is actual congestion occurring. "If a cell is actually full with data traffic, then take actions XYZ, starting with those subscribers that are both lower priority and who are doing something like video streaming". This will need to come from the radio as well - simply looking at TCP from back on the Gi interface by the gateway won't cut it.
In a way, I suppose you could rephrase the cost/revenue description above as being: "Charging-based policy is about prevention. Network-based policy is about cure". In other words, the IT-based approach attempts to moderate users' behaviour in advance, through segmentation and templating. The network-based approach is there to fix things, when problems occur - especially congestion. Over time, the cures will become much more granular and targetted, while the prevention strategies will become more subtle and sophisticated.
Related to this is the observation that IT departments are often more responsive to the needs to operators' marketing functions than networking groups. Rather than forever trying to standardise, they tend to have a more pragmatic view towards customisation and flexibility - something that is much-needed with controlling mobile data. There is also much more likely to be a willingness to involve the end-user in the process, for example through a trend towards on-device self-care portals for visibility and tariff upsell.
I'm still trying to get my head fully around all this - but distilling all the conversations I've had recently I am moving to the view that charging-driven policy use cases are, on the whole, more plausible and workable than those that are purely driven by the network. This is also true of issues around dealing with mobile video - transparent "optimisation" of content, without reference to user details is only ever going to be a partial (and often unsatisfactory) solution.
EDIT - within hours of posting this piece, I saw this news item about Verizon, which seems to underscore my point. Although implementation details are thin, it sounds like the company is using a combination of network-based congestion detection, plus subscriber records to pick out the "usual culprits" as warranting throttling. Being in the US, Net Neutrality obviously plays an important part in the approach, and this appears neutral in terms of content/service differentiation.
0 comments:
Post a Comment