In the past five plus years that I've been working with mobile SPs, traffic has grown, then grown some more, and now is exploding. While that's a better business problem to have than the alternative (!), it does have its own little headaches.
The one that's on my mind the most these days is the problem of scale. In an ideal SP's data center, all the nodes supporting customer traffic would be big enough, fast enough, and have enough headroom to absorb the slings and arrows of outrageous outages elsewhere. Likewise the nodes supporting the nodes carrying (paying) customer traffic would also be big/fast/headroom enough, too.
The problem I keep seeing, though, is the inevitable mismatch of capacity among the nodes leads to network designs which attempt to minimize the stranded capacity. That makes sense, in a static universe, because it minimizes the excess expense to build and operate the data center. Unfortunately, the mobile SP's universe is anything but static these days. Mobile devices are becoming more capable, subscribers are more willing to use them for new services, and there's a growing use of the mobile network for machine-to-machine communications.
That last item is invisible to most folks - it's not exciting, it's not dramatic, and it sure isn't sexy. But let me give you a couple of examples, just from the universe I've been working in lately:
A field (obviously with high value crops!) has sensors embedded in the soil which report moisture and pH levels to the irrigation controller. No farmer intervention is required to know when to turn on or off the irrigation system.
A vending machine company operates smart machines, which report their consumption/inventory levels before the truck rolls out on its resupply run - saving the operator time, money, and also (incidentally) enabling very powerful tracking of customer consumption trends.
Alarm systems which don't depend on the "phone line" are less likely to be disrupted by the clever thief who first cuts the phone line before breaking his way in.
Gas meters for larger operations should be read daily (think plastic manufacturing) - and they are, on a cron job, over the cellular network. That's happening today (and has been, for several years) - imagine that expanding to Smart Grid.
When the mobile wireless is more about “wireless” than it is about “mobile” – the possibilities grow enormously. But that means the SP serving those customers needs to be able to grow the data center capacity, too. And fast.
That’s the problem I see. Datacenters that are “just right” today are woefully inadequate six months from now. The needs will morph from today’s capacity mix to something different. Nodes/services which were the choke point last year will not be the critical point next year. Adding capacity becomes a fundamental network redesign effort – and it happens every time you need to increase capacity.
What seems to work, though it is admittedly not as efficient as we’d like in a perfect world, is to change the fundamental principle behind how we design the SP’s data center. We need to go from a “big enough” mindset to a “fast enough” one. The fastest way to increase network capacity is to make the underlying design modular. Instead of increasing capacity in the current pain point, only to create a new one a few months from now, establish capacity sets. If I need more WAP capacity, I add these nodes, in this standard arrangement, with these standardized connection points into the existing network. If I need laptop connect (aircard) capacity, the nodes/arrangement/connection point set will be different, but it can still be standardized and known in advance.
The modular design will result in somewhat more stranded capacity in each module (or zone … or set … or whatever you choose to call it). However, with the standardization of the hardware/software/connections/etc. in the design, you quite possibly gain enough in speed to be able to deploy capacity increases in a more timely fashion. Instead of having to build the data center today to carry the capacity you need in 18 months, if you can add capacity with 3 month lead times, you can stage in the increases, spreading capex over time instead of in massive surges.
Obviously, the fundamental data center design must be made to accommodate these “drop in” modules. But that’s a design which can scale – and do so in the timelines SPs are dealing with now.
Imagine what it will be like when we come out on the other side of the current economic slowdown, and everyone tries to catch up?
Scale matters – and especially the ability to scale.
Hi,Previous we were using Cisco 7606 as BRAS and the issue was Router keeps on rebooted automatically.OLD Details about Cisco 7606Router 7606 #show versionCisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVENTERPRISEK9-M), Version 15.2(2)S...
I have successfully registered my SIP endpoints (which we have developed) with Broadsoft sandbox environment. I can make basic calls without problems. When I try to conduct feature tests like Call Waiting (CW), Call Hold (CH), and Call Transfer (CT)...
I am trying to find if there is any Pros or Cons in deploying MPLS with separate customer AS for each site as opposed to one AS. The end goal is to be able to inject default routes from two DCs and be able to make a subset of sites follow one default rout...
So I have attempted the below config: l2vpn
backup disable never
xconnect group Xconns