Wednesday, June 30, 2010

Cellular Design for Applications

I asked the following question the other day at an industry conference, with several carriers in the room: "How will video impact the way you design your cell edge ?" the room went deathly quiet, not the least because it was just after lunch - however, this was my subtle way saying that we have not yet linked our cellular design practices to services other than voice. Yes, cellular data has been deployed, but make no mistake about it, we are still designing our cell edge to correspond to voice throughputs and we are still dimensioning our backhaul networks to correspond to the maximum number of simultaneous voice conversations at a given cell site.

Signal strength affects the coverage as well as the caller capacity. It is relatively easy to prevent signal source hunting and dropped calls - but these values are engineered for voice, which dictates both coverage and capacity. Data introduces new challenges which require both a lower link budget and a higher carrier-to-interference-plus-noise ratio (CINR) the higher the data rate required. In HSPA, these values are based on power and code dynamic (or fixed) allocation, which provides allowance to segregate the resources to avoid starving, say,  voice for data - but the data rewsource analysis is usually no more sophisticated than "what's left over" after voice has been optimized.

There is good reason to oprimize for voice and have only "best effort" data. The economic reality is that, in North America, 70% (or more) of the revenue comes from voice - and this represents only 30% of the operator traffic ! Therefore the revenue per bit of voice is much more precious than for data. This model is not long for the world, given the rising tide of over-the-top solutions driving the "everything is a data application"-future. These trends will force new planning models, and the question of : "what is the data outage criteria ?" will loom large.

Fundamentally, the notion of engineering the network for, say,  "video" versus "voice" will require separation of applications - potentially to separate carriers, or at a minimum some degree of isolation on the RF scheduler. It is simply not pragmatic to engineer for worst case applications uniformly throughout the network (the cost of engineering 2xHD channels at cell edge, when the majority of users are web browsing, doesn't make fiscal sense) - more so, we will need "virtual" cell-edge limits for different application classes - from video, social media and web browsing, each having diffferent handoff thresholds (and associated "virtual layer management"). Each application class will contribute to a new dynamic composite data model which will be needed to evaluate network bottlenecks from social media signalling intensive models to video data path intensive models. The "customer experience" for each application class will also require further definition. For instance, "always on" sessions are important for presence base services - but "internet snacking" may well have looser requirements.

This management has been avoided on the wireline side of the house, as the bandwidth has been ahead of the usage curve - however, the wireless throughput still very much lags the broadband wireline equivalents, and therefore quality of service and traffic management will continue to dominate the conversation in cellular.

Wireless data is really just "coming into its own" - we have spent the past 100 years getting voice figured out, and, while it's not the sexy part, we need to pick up the slack on defining the same for data - data erlang anyone ?

1 comments:

  1. There's no doubt that we need some sort of volume measure for "multimedia" traffic that can apply at the level of a cellsite and it's related backhaul. The challenge of course is that different types of traffic have different latency requirements and this needs to somehow be reflected in the model. As a guy who grew up on the voice side, I was always amazed at the approach to engineering data networks which seems to be basically "suck it and see"...wait to if users complain about latency then add bandwidth. This works OK when everything is email and web browsing in wired configurations that are relatively cheap to expand. It will not be good enough as users demand voice and 2-way video over an expensive, shared link that cannot be quickly augmented (cellular).

    ReplyDelete