How NSN Undershot the CDN Opportunity

So near, and yet so far!  How many times have we heard that comment?  In the case of NSN with their recent deal with CDNetworks, we have a current example.  NSN is seeing beyond the present, but they’re not yet seeing the future of content delivery.  That might mean they’re not seeing, or optimizing, their own future.  Let’s look at why that is.

First, you have to look at the deal in context.  NSN previously had a relationship with Verivue, who had a really state-of-the-art cloud-CDN strategy that sadly they never positioned well.  We gave the combination our top spot in a Netwatcher review of CDN strategies last year.  But Verivue, likely in large part because of their positioning issues, ended up selling out to Akamai.  NSN doesn’t really want to partner with a global CDN player to get software for operator CDN deployment—cutting out the middle-man of NSN is too obvious a strategy.  They need something richer, more differentiating.

Second you have to look at the concept.  NSN is trying, with its “Liquid” initiatives, to marry CDN and mobile.  Great idea, but this isn’t the way to do it.  Mobile services are defined by a set of standards most collectively call “IMS”, but which includes the mobility resource function and evolved packet core (MRF and EPC, respectively).  What we need to do is to frame both these functions, and everything else that happens in a metro network, as a set of “infrastructure services” that are exposed through Network Functions Virtualization, implemented using SDN, and used by everything that runs in metro, from mobile to IPTV.  If you propose to solve the problem of mobile content by creating CDN-specific caching near towers, you fly in the face of the move toward creating generalized pools of resources.  CDNs are, after all, one of the NFV use cases.

NSN’s big move has been the shedding of non-mobile assets to focus on mobile, but their focus isn’t the focus of the buyer.  Any redundant parallel set of networks is just a formula for cost multiplication these days.  NSN may want to speak mobile, but buyers want to speak metro, and that means that NSN should be thinking about how “Liquid” talks to these infrastructure services.  And, of course, how those infrastructure services are created, operationalized, and (yes, because what mobile operator is an island?) federated across multiple providers.  CDNetworks is not going to do all of that in a way consistent with other compute/storage applications.  Maybe not at all.

And even if they could, we go back to the middleman positional issues.  NSN can’t be a leader by just gluing other pieces of technology together.  Professional services of that sort demand some product exposure across all the areas being integrated, so you don’t establish your credibility by shedding those areas and focusing only on mobile.  NSN needs to b a CDN giant, a cloud giant, and a mobile giant—and an SDN and NFV giant too—because the current metro market demands a holistic solution or costs will be too high to support continued operator investment.  And, folks, of you can’t make a profitable investment in the metro network, there’s no place on earth left for you to make a buck as a carrier.

So what the heck are “infrastructure services”?  They’re a combination of connectivity and hosted functionality.  IMS is one, so is EPC and MRF.  So is CDN, and cloud connectivity.  So are a bunch of things we’ve probably not though about—the higher-layer glue that makes lower-level connectivity valuable, just like call forwarding and call waiting and voicemail make voice services valuable.  You create infrastructure services by hosting network functions via NFV, combining them with SDN connectivity, and offering them to applications as useful network tools.  Which is what NSN needed, and still needs to do.  Except that they didn’t.

The good news for NSN is that others aren’t doing it either.  Look at SDN today, in a service sense, and you see a technology collection striving for invisibility.  We want…to do what IP or Ethernet did before!  So why migrate at all, except for cost savings?  And cost savings to a vendor means “cutting me out of more of the pie” so why would you want to go that route?  Look at NFV and you get the same thing—host virtual functions on servers instead of running them on purpose-built hardware that vendors are making me pay thought the nose to get.  If you’re a vendor, you’re again on the “cut” side of the picture.  This reality has pushed all the big network vendors into the blow-kisses-at-something-so-I-don’t-look-bad position.  So they’ve blown for all they’re worth.  NSN, who now has less to defend, could make their portfolio poverty into an asset by threatening the network equipment space with a stronger SDN and NFV story.

So could Brocade or Ericsson or Extreme or Juniper.  All these vendors have the risk of narrow product footprints.  Why not turn that into an asset by proposing a revolutionary change, a change that threatens most those who offer most today?  NSN can’t bank on being joined by all its competitors in the stick-your-head-in-the-sand game.  You can see how a metro revolution as a strategy would benefit NSN, but perhaps they can’t see it themselves.  That’s a shame, because the new era of networking, where connectivity and the cloud fuse into a single structure, is on them.  They could lead, and they could have made CDN a showcase for their leadership.  Now they’re following, and the wolves are at their heels.

Leave a Reply