Leslie Ellis's blog

SCTE's Top Tech Trends: Broadband Bonanza

ATLANTA - No shortage of data and deep-dive at the recent SCTE Cable-Tec Expo, held here the week before Thanksgiving.

In no particular order, the highlights from my notes: Objects that need or want an Internet connection will number 15 billion worldwide by 2015; Comcast alone anticipates that more than 250 million Internet protocolconnected things will hang off its cable modems within the same timeframe. That means not just PCs, laptops and tablets, but things like refrigerators and the machine-to-machine scene.

Speaking of refrigerators: Samsung’s Eric Anderson said during an Expo general session that people are using the Internet part of its connected fridges for 1.6 hours per day on average. No, really: Apps like weather and Pandora top the list.

As for machine-to-machine and talk about things getting chatty: Your smartphone receives something like 1,200 maintenance pings per day from your carrier, for “keep alive” activities, as well as to track state - online or not; keeping streaming activites smooth as you move from one cell-tower footprint to another.

Put it all together: Broadband capacity is going to need a lot of attention for the next bit of … forever. That’s why “CCAP” - tech-speak for “Converged Cable Access Platform” - was also high on the to-do list at Expo, as a way to collapse costs out of broadband gear at a rate hopefully faster than the unprecedented growth broadband usage.

As for all that growth: In hallway discussions, engineers are already mulling whether there needs to be some kind of Energy Star-type program for apps and bandwidth usage.

All in: It’s a broadband bonanza out there. The good news is, your tech brothers and sisters are all over it.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at www.translation-please.com or multichannel.com/blog.

Your SCTE Cable-Tec Expo Jargon Descrambler, 2011

The industry’s technical ranks descend upon Atlanta today, and by the looks of the sessions, workshops and meeting requests, this year’s SCTE Cable-Tec Expo is going to be another jargon doozy.

Starting with other current events: If you happened to catch last Wednesday’s test of the national Emergency Alert System (hint: pretty glitchy), and wondered how that whole thing gets fixed to work correctly, details will abound in a Thursday session entitled “EAS Using CAP: IPAWS From End-to-End.”

Translation: EAS, obviously, is the Emergency Alert System. “CAP” stands for “Common Alerting Protocol” and “IPAWS” has nothing to do with the what’s at the end of the appendages of your cat, dog or ferret. (Although the inventors could get credit for almost anthropomorphizing a term.)

“IPAWS” stands for “Integrated Public Alert and Warning System” and is the new way of handling national emergency alerts. Equipment manufacturers are under mandate from the Federal Communications Commission to get their stuff in shape by the end of June 2012.

As for vendor fare: The term that cropped up with the most frequency in a happy barrage of jargon-studded meeting requests from vendors is CDN — content distribution networks. (Some people say “content delivery networks.” Same thing.) Here’s such a missive: “The product suite includes a unified origin server and unified edge server … and transmuxing capabilities to reduce the complexities of delivering multiscreen video.”

CDNs are all about finding efficient ways to deliver live and linear video using HTTP (Hypertext Transfer Protocol) streaming – think Apple HLS, Adobe HDS and Microsoft Smooth Streaming. They work by plucking requested content from the server that’s geographically closest to the viewer. And they’re big, big, big, in terms of cable engineering to-do lists.

Also on the docket: “FTTT,” for “fiber to the tower,” a critical component for those MSOs dabbling in the lucrative and growing work of hauling cellular traffic for carriers; “DASH,” an MPEG suffix that stands for “Dynamic Adaptive Streaming over HTTP”; and “layer one multicast over DWDM,” where “DWDM” stands for “dense wave-division multiplexing.”

And that’s just a tiny sampling of what’s floating in the tech soup this week in Atlanta. Ahh, can’t you just taste it? (Don’t answer that.)

The great thing about Cable-Tec Expo is that everything is a deep dive, so if you’re going, be ready to take really good notes. And if you’re not going, fear not — technology editor Todd Spangler and I are, and we’ll be translating the scene back to you in the days and weeks to come.

Reviewing the NCTA's Technical Papers

No shortage of deep-dive in this year’s collection of technical papers, organized by the National Cable & Telecommunications Association, with contributions from CableLabs and the Society of Cable Telecommunications Engineers.

The two I went so far as to print out to read on the plane: “Considerations When Delivering Cable TV to IP Connected Consumer Electronics,” by Comcast engineering fellow Mark Francisco; and “Evaluating Best-of-Class Web Service APIs for Today’s Multiplatform Video Management Solutions,” by thePlatform’s Alan Ramaley, CTO, and Nick Rossi, VP of engineering.

The latter caught my eye because of that term - “Web service” - which tends to pop up at every intersection of old and new; now and next. Usually the words “you just” are nearby, just to make sure you’re feeling stupid: “You just do it as a Web-service interface.” (Duh!)

If you’ve been feeling the need to take a deep soak in the language of web services, or if you’ve wondered about how application program interfaces (APIs) work, this one’s for you. Example terminology: SOAP, and why it’s a “heavy protocol” to work with; the verbs of REST. (Verbs! Writers love verbs! There’s hope!)

Francisco’s paper details the technical options associated with transforming TV into an app, from a service. If you’ve ever wondered about the similarities and differences between HTTP live streaming, DLNA, Flash streaming, MPEG-DASH, and Microsoft Smooth Streaming, read it.

Other notables: “Adapting Adaptive Streaming to Cable Access,” by Comcast’s Xiaomei Liu, because of the byline (Liu is one of Comcast’s first engineering fellows, and a lauded Big Thinker); “Will HTTP Adaptive Streaming Become the Dominant Mode of Video Delivery in Cable Networks,” by Ericsson’s Michael Adams, because it’s a perfectly phrased question for these times; and “Approaches to Integrating CDN Technologies into Classical Cable VOD Platforms,” by Time Warner Cable’s Chuck Hasek and Verivue’s Santosh Krishnan, because content-delivery networks (CDNs) are also a big part of the new vogue in cable’s engine-room discussions.

For this year’s nod for the geekiest paper title - notably, either this year’s batch is more approachable, or we’re getting geekier, because nothing popped out as shamelessly geek - we’ll go with “Evolving Optical Transport Networks to 100G Lambdas and Beyond,” by optics veteran Gaylord Hart of Infinera and HBO’s stalwart technologist Craig Cuttner.

You can buy the whole set for $50, a price that hasn’t changed in a very long time. I highly recommend the CD-ROM (no printed book this year), but only if you’re into immersion learning.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog

The Technologies of Ultraviolet

Just about a year ago, word emerged of a way to buy and play movies electronically - but as effortlessly as we do DVDs, and before them, VCR tapes. Buy it, put it in the machine, play it.

The reason it’s simple to play a videotape in any VCR or any DVD in any DVD player - no matter what - is that the war about how it works happened ahead of time, and ended in standards. Beta vs. VHS; HD-DVD vs. Blu-ray. In each case, one way of displaying copyright-protected video titles became the way.

Standards didn’t happen in the digital marketplace for video. No standards means no effortless way for consumers to buy digital video. It means fragmentation, which creates confusion, which smites the digital video marketplace.

Think about it: You or your family might have accounts with iTunes, Netflix, Hulu Plus, and maybe an Amazon locker for the DVDs you bought there. It’s a lot of logins to remember, just to get at a video you bought.

Fast forward to last July, when a consortium emerged, seeking to fix the problem: the Digital Entertainment Content Ecosystem (DECE). In it are the majors in retailers (electronic and tactile), movie studios (all but Disney still), gadget makers (all but Apple) and service providers (cable, satellite, telco.)

Their answer is the consumer-facing brand that is Ultra- Violet. The first major phase of it came out this month.

What’s in it: A digital rights locker, protected by five flavors of DRM (digital rights management). Also: More than 75 APIs (application program interfaces) for use to develop video storefronts, and to handle interoperability between the DRMs. It’s all managed by Neustar.

Let’s start with the digital rights locker itself. It’s nothing like Davey Jones’ locker, or anything big and heavy with a brass padlock. (Sigh.) It’s a room full of specialized servers somewhere in Virginia. It’s a cloud, in that sense, where Neustar manages rights and licenses. It doesn’t hold content.

The digital rights locker - called The Coordinator, in DECE-speak - is SAML-based. “SAML” stands for Security Assertion Markup Language, and is the login part: Are you who you say you are? (Prove it.) Are you authorized and is your credit good? If you login to your bank, it’s likely that SAML is behind it. People tend to say it as a word - rhymes with trammel.

As Neustar opens the doors of its digital locker, it’s the five DRMs that are the big deal, technologically. Until now, there’s been no “DRMs ‘R’ Us” way to accommodate the different choices already playing out in the marketplace.

The APIs, released by Neustar to UltraViolet and its 70-plus member constituents on June 27, are aimed at a major blemish of open standards: stifled innovation. If everyone uses the same ingredients and recipe, how do they innovate?

That’s why there are about 80, at launch, so as to satisfy the initial needs of the DECE ecosystem.

Watch next for that gray-and-purple UVVU logo to enter your digital world. Also, more licenses and specs. Ultimately, it’s one login, for all your digital stuff, to use whenever and wherever you are.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at www.translationplease.com or multichannel.com/blog.

Snapshot in Time: IP Home Networking

Nine months ago, I put out a call-for-tally amongst my Facebook pals: Count the things in your place that have (and use) an IP (Internet Protocol) connection, either wired or wireless. The high at press time, back in October 2010, was Steve R., with 33.

Since then, I took on a summer intern, Kirsten, to build out an over-the-top video lab of sorts. This means we tricked out a back room of the office with the following: Comcast box, Xbox, Boxee box, Roku, Apple TV, GoogleTV. Panasonic-connected TV, Samsung-connected Blu-ray player, TiVo Premiere box, iPad.

Prior to this exercise, my tally of things that needed an IP address at work was six. Post-lab? Sixteen.

Granted, this is a corner case. Everything in the lab will be used to simulate recreational use, to see why it is that consumers will go to the “connected” side of the connected TV.

One thing is clear so far: Some things just work better with a wire. Big screens (HDTVs), certain “connected” things - the best in the digital garden.

Case in point: In getting this set up, we moved the combo cable modem/VoIP box from my desk to the lab, to get at the extra Ethernet connectors on its back panel.

We lugged the Wi-Fi router in there, too, so we could still have a signal on our laptops; it all worked in the new location. Thrilling! Not so thrilling: Dust bunnies the size of small dogs, hiding behind the heavy objects that needed to be moved, to get to the wires that needed to be moved.

Then I went back to the desk to make a call. (Yes, I still use a wired desk phone.) No signal. No fax. Scoff if you will that these are archaic devices - most of us still use them.

This began an investigation of whether we needed a second cable modem, and how that would work, or whether the structured wiring in the building is sufficient to connect up the phones and fax without additional gear.

If you like puzzles, home networking is kind of fun. In a dusty, sneezy, geez-I-hopethis- works-because-I-really-need-signaltoday way.

The point is this: As everyday consumers knowingly or unknowingly increase the number of things in their lives that need an IP connection, it’s probably good to be ready to solve the many use cases that will invariably pop up. Headless gateways that can plunk onto a shelf in the garage are great, in some ways, but … the wire is still best, here in the summer of 2011.

Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog

Behind The Buzz About 'Federation'

These days, in the world on online things, it seems that everything wants to “federate.” Federated authentication; federated social networking; federated encoding. Clouds, apps, domains; libraries, servers, databases. All are apparent candidates for federation.

Try it yourself. Do an online dictionary lookup of the term (or any other). What pops up? In my case, a definition, and, to my slightly creeped-out surprise, a thumbnail-sized photo of my dog, Stella. Huh?

This is federation in action, as it turns out: Stella turned seven this month, so I set her photo as my Facebook profile picture. Apparently, Merriam-Webster.com and Facebook are “federated” - look up a term, get the definition, and the option to post it and a comment to your status.

To federate, then, in an online sense, is to pool certain resources - either to make a more tricked-out, unified consumer experience, or to make it more efficient for the underlying piece parts to unify into a whole.

Obviously, this is not a new concept. In the tactile, nondigital world, we’ve seen this before. Individual states federated into the United States. Before that, individual colonies federated into states.

In cable, the newest addition to the “federation” buzz is the content-delivery network, or CDN. CDNs come from the language set that is the industry’s transition to Internet protocol as a delivery environment for video.

In a big oversimplification, CDNs use fiber backbones and video-size (read: big) servers to ingest and hierarchically distribute streams of video to the mass of things in our lives that don’t necessarily get signal through a set-top box, but can connect to video signals over an Internet connection - PCs, laptops, tablets, phones.

Comcast built its own CDN; Time Warner Cable currently outsources its CDN activities. The rest of the industry, right now, in mid-summer 2011, is examining its options.

For small to midsized operators, it’s a real conundrum: Local and regional fiber rings are justifiable to consolidate headends and increase reliability. But augmenting them with a national web of video-centric servers and software, when signal collection is already working just fine the old way (satellite)? Last I checked, money still didn’t grow on trees. Which is why there’s so much buzz - mostly from vendors, so far - about finding ways to link regionally, pool networks and federate into a national CDN. An ambitious concept, to be sure.

So far, it’s just buzz. But it’s a buzz that grows louder day by day, just like when you take the lid off a beehive.

Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

The Language of CDNs

Lots of follow-on questions in the mail about content-delivery networks, starting with this plum from reader Dan: “I’ve seen my company put in fiber rings, regional fiber rings and, more recently, a fiber backbone. How is that different than a CDN?”

Also this, from reader Chris: “Ingest, multicast, transcoding, adaptive streaming, MPEG DASH - the CDN jargon is intense. Help.”

Welcome to the trove of terms that describe what it takes to get video content to Internetconnected screens, beyond and including the television. Laptops, tablets, game consoles, PCs, smart phones.

Let’s start with you, Dan. If fiber is the physical conduit over which IP (Internet protocol) video packets flow, CDN is everything else: how those packets are collected, stored and packaged for receipt by all the screens we’re watching.

A brief history of CDNs: In one sense, they’re the older sibling of the technologies of video-ondemand. Remember back when VOD meant a few thousand hours of storage, mostly movies? These days, operators are gearing up for 20,000 or more hours of storage, for episodic TV and movies.

That storage happens hierarchically, in CDNs - one or two big library servers (think “long tail”), with caching servers closer to consumers for popularly viewed titles.

Remember “pitchers and catchers” as the way to move video assets from source to destination? CDNs change that. Instead of pitching up to satellite and catching down on the ground, CDNs use fiber backbones, linked to regional fiber rings and linked to hybrid-fiber coax, to move content.

CDNs are in vogue right now because of the desire to use them for live and linear content, too, especially for channels that are nationally available (as in, not local broadcasters).

Which brings us to your laundry list of CDN curiosities, Chris. “Ingest,” as the name implies, is the process of feeding titles into the hierarchical storage. “Multicast” optimizes bandwidth for delivery - you want to see something, you put the flag up on your mailbox, so to speak. So does everyone else who wants to see it. The show moves down the CDN once, then you join the stream.

“Transcoding” formats video streams for receipt by the varying screen sizes and resolutions available - what goes to tablet doesn’t need to be as large as what goes to an HDTV, for instance.

Adaptive streaming, or “fragmented MPEG-4,” is the slicing of a piece of content into different sizes. It’s a way to suit what’s best for the end screen, as a function of available bandwidth - if there’s not enough, then downshift to a smaller slice.

The “DASH” part of “MPEG DASH” stands for “Dynamic Adaptive Streaming over HTTP,” and is a hopefully harmonized way for content owners and service providers to stripe content for display on different screens.

That’s a quick look at CDN lingo. It’s a big part of the whole transition to IP (Internet protocol) video, and likely a big topic of engine-room talk for the foreseeable future.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

What Puts the 'Velocity' In 'Service Velocity'?

One of the big-three reasons commonly cited as cause for going “more IP,” and eventually “all-IP,” is the notion of “service velocity” — new-tech talk for getting more stuff to market more quickly. As in, ditching the time-tested “one new thing every 18 months” plan, long an unfortunate shackle of the set-top-based digital video world.

Rather than trudge yet again through the depressing realities about why things take so long in today’s world, let’s look at what puts the “velocity” into new-service rollouts.

This probably doesn’t come as a big surprise: Turns out it has a lot to do with the tsunami of software-based everything that’s making the workplace, and people, more efficient.

Talk to the people whose work it is to bridge between now and next, and specifically service velocity. They’re almost always IT/information technology people. Chances are high that you’ll hear two terms pop up again and again: Agile programming, and waterfall programming. “Waterfall” is old world; “agile” is new world. Proponents on each side tend to snark on the other.

Here’s some examples, from recent notes: “Waterfall is a disaster … you get these designs that aren’t influenced by reality.” And (puffed out with pride): “We run an agile development shop.”

My personal favorites: “Agile is the only way you can keep track of all the sh#t that’s going on in the network and at the end points,” counterpointed by “Agile, tiger-teams, it’s all a bunch of crap.”

“Waterfall” coding goes like this: You need to roll out a new video feature. After it’s designed, by the design team, it goes to the quality assurance team. Then to the solutions, integration and test team. If that’s all good, it gets released. Waterfall time is measured in double-digit months - and heaven forbid something changes along the way.

(Things that take a long time always remind me of a favorite joke. MSO to vendor: “Great! When can I have it!” Vendor: “In six months.” MSO: “Six months from when?” Vendor: “From every time you ask.”)

Agile programming is different. It splits the coding workload into chunks, which are constantly shipping, written by small teams that work in twoweek “sprints.” Changes are assumed, meaning that time is reserved to add stuff in, if requested.

None of this is new, by the way. In the world of computer science, it’s an old saga. A Google search on “agile v. waterfall programming” returned 540,000 results. Books are written on it; seminars are taught about it. It’s new to us because software is eating the world - and to survive and thrive, we need to know what and how software eats.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.

I'm Johnny Cache

Few tech terms can instantly generate so many groaner-twists on clichés: The cache cow. Cache in your chips. His mouth is writing checks that his body can’t cache. (OK, OK, I’ll stop.)

Nonetheless, in the language set of the content-delivery network - the CDN - “caches” are a big part of the scene.

The purpose of a cache, in a CDN, is to temporarily store the most popularly viewed content so that it’s readily available to lots of people using lots of different devices (not just the television). It’s all part of this shift toward distributed storage - gigantic servers in the center, linked to regional servers, linked to caching serves at the edge (headend or hub).

Caching is buffering. You’ve seen it dozens of times, especially when video streaming first began. It’s the little animated circle that spins around on the screen when you’re watching something over the Internet. Caching reloads more bits to your screen. As cable operators continue architecting their CDNs this summer, caches matter for local content - stuff that can’t easily be encoded nationally, like cable channels - HGTV, ESPN, Discovery. Big cities can host more than 100 local TV stations. The MSO encoding 500 national channels at a centralized facility (the “origin server,” in CDN speak), and 100 channels locally, may need to cache a million or more file chunks, switched out several times per hour.

An HDTV title, for instance, may get compressed and encoded into eight different stream sizes, ranging from 1 Megabit per second up to 10 Megabits per second, to be adaptively streamed to suit the different screen sizes at the end points - the more bandwidth, the bigger the chunk.

As a direct result, caches can fill up real fast, especially if you’re a service provider tasked with serving up movies and TV at scale, to millions of viewers on dozens of different screen sizes.

Part of the caching equation is figuring out what can and can’t be cached. Some stuff doesn’t lend itself well to caching, like file segments that are “stateful” - meaning they’re tied to something you’re doing, like pausing to resume in another room on a different screen.

As a European cable technologist reminded me last week, all operators delivering VOD already have a CDN, or the beginnings of it. The difference: When VOD began, it was cheaper to store the same title once, at hundreds of edge points, than it was to store everything centrally, then ship it out over satellite or fiber.

These days, both storage and transport is cheap, comparatively. So why not store the hot stuff at the edge, as needed, and keep everything else deeper in the network, to stream as requested?

If you’re a cable operator planning your CDN, chances are high that a big part of the discussion is edge caching: How many servers, at what size, where, with what local encoding to handle off-airs, encryption and ad insertion. It’s the perennial tradeoff between the economics of storage and transport.

Cache out.

________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog

Back to School on DRM

In the world of professional writing, there exists a pecking order when it comes to assignments. In mainstream newspapers, cub reporters get the fire beat.

In tech writing, it varies. I worked next to a guy in the early ’90s who took on “why are pedestals green?” to avoid the annual fleet-management roundup.Likewise for test equipment, and, since digital, DRM - digital rights management. Why? High volumes of multisyllabic jargon; triply nested acronyms; religious wars about software-based cryptography. All that, and for years, nobody really was using it.

That’s about to change. DirecTV announced its plan to use DRM made by NDS on Aug. 31. MSO technologists readying their Internet-protocol video strategies count the transition from conditional access to DRM as part of what they need to plan, build and provision.

It all feels rather cusp-ish, here on the brink between summer and fall of 2011.

For that reason, here’s a lay of the land, in these calm-before-the-storm DRM days:

DRM is about controlling more than one state. Digital set-tops, in a security sense, are one-trick ponies: On the condition that you’re a subscriber, you get access to the programming. Encryption is applied to protect stuff in transit. DRM, by contrast, wraps protection around the video asset, to serve multiple business cases - not just transit.

For MSOs, it’s about picking a system to protect content transmitted in IP, while figuring out how to deal with assets that get their DRM wrappers elsewhere. Say you’ve bonded a dozen or so DOCSIS channels, planks for a simulcast of your linear and on-demand lineups, in IP. That’s when you pick your DRM. At the same time, content will come inevitably in a format that’s been “DRM’d” elsewhere, earlier in the path.

What you buy are key management services and keep-it-fresh services. Surprise, surprise: DRM is a software thing. Buying it means buying the servers that manage the keys back and forth, to unlock the assets. Or, as one DRM tech friend says, “You buy the thing that runs the filter and flips the bits.”

It’s a pretty crowded vendor community. Surprisingly or not, the two biggies of the conditional access “duopoly” - Cisco Systems and Motorola - aren’t high on the buzz meter that is DRM. It’s super-crowded, though, with at least a half dozen big contenders. Welcome to the open-source world. Speaking of which, one of the questions about what will happen in the looming DRM heyday is what Google will do with its December 2010 acquisition of Widevine. Making its DRM open and free would have a predictable affect on the DRM marketplace.

Revocation’s still a bitch. Ask anyone involved in conditional access what the biggest hurdle was in getting those foundational security technologies deployed. Much like now, the muck of it was in the contracts, not in the actual technology - meaning figuring out who finally agrees to provide indemnification in the event of a security breach.

If history repeats, this is precisely when it goes from “fun” to “everything’s fun - until someone loses an eye!”

________________________________________

Stumped by gibberish? Visit Leslie Ellis at translationplease.com or multichannel.com/blog.

Syndicate content