Slashdot Mirror
Cable Industry to Standardize Under Tru2Way
smooth wombat writes "In a move to stave off the FCC, cable operators have now agreed upon one standard to allow TVs and other gear that will work regardless of cable provider. This standard should allow the development of new services and features that rely on two-way communication over the cable network. The core of the matter is this: there are tvs and other devices which can receive digital programming but cannot talk back to the network. As a result, subscribers must rent out boxes from cable companies. This new standard should, in theory, do away with having to rent a box. There are two downsides to this standard. First, Sony has not signed onto the cable industry's idea and second, FCC Chairman Kevin Martin wants to put forth a proposal for a more open and competitive environment using a completely different standard."
Tru2Way is the new name for what was formerly "OpenCable," the standard which is not open as you need to register with CableLabs and sign an NDA just to see many of the specifications.
The protocol involves a sophisticated DRM system which can allow content providers to dictate which content you are allowed to move or copy and when (see section 6, Security, of the OpenCable Unidirectional Reciever Specification, OC-SP-OCUR-I04-060622).
I'm guessing "Tru2Rape" was just too truthful of a name for them to use.
What existing European standard? ATSC and DVB were developed at around the same time. Arguably, those involved should have worked together, but to claim there was an existing European standard the industry could have adopted is completely wrong.
You are not alone. This is not normal. None of this is normal.
I actually work for one of the major US cable companies (not gonna say which cause it honestly doesn't matter), in the department that controls the overall "brains" of the cable video network in our region. As such, I tend to see some of the issues, and can maybe hopefully contribute to the back-end knowledge of the cable video platform for the /. users.
First off, in direct response to your question. To the best of my knowledge, currently most set top boxes in use are made by 1 of 2 companies. Scientific Atlanta, or Motorola. These are also the companies who pretty much are the 2 "big boys" in the Cable headend game. Our region actually has systems which run on both platforms (they are not interchangeable since both companies do things on the backend differently.
In order to kind of understand the way the cable-cards work, you kind of need to know the way the entire system works...sorta. So let me try and explain the makeup of the cable headend. I deal primarily with the Scientific Atlanta systems in our area, so I'm more familiar with it (and where to find the references online which I can share.). Keep in mind that both systems do the same thing, the way in which they do it is just a little different. http://www.cisco.com/en/US/netsol/ns457/networking_solutions_solution_category.html the figure here is kinda basic, and includes stuff not really needed...but may help as a visual aid.
In the Scientific Atlanta platform, you have your primary controller. This system, running off Solaris, Pretty much "controls" the entire cable video network. It contains the configuration information for all the modulators which send the video over RF to your home. It also contains all the conguration information for your settop box, package information, security information, Channel Map configurations, etc. When the video source is configured on the QAM (Modulator) it can be encrypted. On the SA system, there is a special server connected directly to the DNCS responsible for maintaining the encryption keys and information. This encryption helps to prevent unauthorized access to the digital signal. The most obvious (without getting into conspiracys or opinions on greed and whatnot) reasoning for encrypting a channel is so that little johnny doesn't stumble across hardcore sex in the clear with his QAM tuner TV.
In the Cable-Card enviroment, the cablecard is responsible for the decryption of this signal. The encryption is done via a public/private key system. When a cablecard is loaded on the controller initially, the DNCS at this point knows the Secure Micro of the cablecard. When the card then gets authorized for the encrypted feed, it at that point is sent the information it will need to be able to decrypt the video feed. This process tends to work without many problems. The REAL complication with cable-cards tends to be a bit more involved with the pairing process.
From what I understand.... the pairing tends to be pretty much the DRM of whole mess. no wonder it causes so many problems. But then again, nobody can avoid it these days it seems. Anyways, there are primarily 2 Id's that come into play here. The CableCard's ID, and the Host device ID. This is pretty much where you are pairing up the 2 devices and getting them to play nice to each other and know who the other person is. It's this item that pretty much tends to be the real pain in getting a cablecard working. (personally.. I hate TIVO's.. ). The unfortunately thing about standards, is while they are there to tell you how things are supposed to work, talk, and act together. They don't always go into the nitty-gritty of how to implement those standards, user interfaces, or procedures. For instance, especcially in a dual-turner TIVO, they can be a bastard to set up. Why? First you must make sure that just the primary card is