|
Does switching append to my existing VOD
configuration, or do I blend it in to my system elsewhere? How hard is
it to install?
It doesn’t append to it, per se, but it works together with existing VOD
systems to share bandwidth resources. In the S-A digital video headend
architecture, there’s an existing function called Session Resource
Management (SRM). SRM is a part of our Digital Network Control System (DNCS).
What happens is, the switch requests resources from that SRM, and
borrows them, and uses them for switching. As it doesn’t need them, it
returns them to the SRM, to make them available for VOD.
As for installation – you need the software in the DNCS that supports
switching. Then it’s a matter of installing the switch servers, and
installing the QAM resources. By that I mean you mark QAMs –maybe there
are 8 for the switching, and 6 for VOD and SVOD -- and you determine
what programs are going to be switched. You enter the configuration for
the switched channels once, and the DNCS then provisions those SDV
servers.
As for the SDV servers: They were built to be very fast, and to have
very high availability, by using redundancy. It’s always-on, very easy
to upgrade, and it has a feature I call the “non-service-affecting
upgrade.” What that means is, when you upgrade the software on your SDV,
we have a backup computer to provide switched services while you’re
upgrading the primary. So you never bring it down.
I’ve heard that while switching is a low-cost method
for bandwidth preservation/expansion, it is operationally a very
difficult installation. Is that so, and if so, why?
When you implement a switching fabric, you generally do need to re-wire
your hubs. You’re typically adding new QAMs, which have to be wired into
your physical plant. Then you also need a switch router that is IGMP-capable,
which goes directly in front of the QAMs in a hub site. ‘IGMP” stands
for Internet Group Multicast Protocol. It’s the Internet’s way of
broadcasting signals, and letting users “join” the programs of interest
to them.
The way it works is, you distribute all the programs, all the way to the
hub site. They’re all delivered there as Single Program Transport
Streams (SPTS), with multicast addresses. When the switch wants to add a
new program on a QAM channel, it sends a command to the QAM: Activate
this program.
Are you switching in the MPEG domain, or the IP
domain?
In our system, everything is IP all the way to the edge resource – in
this case, the QAM. In MPEG delivery, you usually deliver programs in
Multiple Program Transport Streams (MPTS). With switching, you want to
use a Single Program Transport Stream. The reason is, you’ve got this
QAM receiving the signal that it wants to transmit. It joins only those
programs it is actually going to transmit. So if you use multiple
program streams, you’d be joining these large groups of programs, when
you really only need that one requested by someone.
To boil it down: With switching, you distribute all your programs as
SPTS, encapsulated in IP, with a multicast address. Then the QAM joins
only those streams it activates on its outputs.
It’s low cost IP transport all the way to the last device, which in this
case is the QAM. There, you convert it back to MPEG and put it into RF,
where it is received by the set-top.
What is unique about your switching solution, vs. your
competitors?
Probably the key thing is the high availability, combined with ease of
use.
When you decide to switch video, one of the downsides is that you have
this extra computer, this server, which must always be on, to provide
switching services. If you’re the person in charge of the network,
you’ve just added one more component that could lower the reliability of
your network. Because of that, we designed our switch with an always-on
mentality. There’s always backup, ready to provide service, if the
primary fails.
At the same time, we realize that there will always be software
upgrades. There’s no way to deliver perfect software and every desired
feature on day one. Most of the time, you don’t even know all of the
features you’ll need, on day one! Software upgrades are a fact of life.
Because of that, we made it so that software upgrades can be
accomplished in two easy and foolproof steps.
Step 1 is to use the backup server to carry out switching services,
while you’re upgrading the primary.
Step 2 is to switch the primary back online, using the updated version.
Its instruction is to activate itself with the new software version,
then to check in with an internal “watch dog,” to report that it’s
alive, ok, and running the new version properly. If anything goes wrong,
it knows to switch back to its last known version of software.
That way, you never take services down, and it’s foolproof. We really
focused on building our switch server to never need care and feeding.
It’s a black box, in a sense, that sits in the rack. It runs all the
time. You don’t have to do much to keep it operational.
What’s next in switching?
Our customers are telling us that they like the high availability and
easy upgrade features we’ve put into our switch. They’re asking why
those features can’t be used for their VOD platforms. To service that
need, we’re working on a platform we call “Universal Session Resource
Manager,” or “USRM.”
The idea is to build a universal software chassis. With a hardware
chassis, you plug cards into the front, for specific applications or
transport. You plug I/O cards in the back. The USRM would be that same
idea, but for software. So on the bottom, we’ll use what we call
“resource adapters.” Their role is to adapt, in software, to a
particular kind of edge resource and signaling protocol. One might do
the switching protocols; another may do IMS, or any of the PacketCable
Multimedia Protocols that provide video over DOCSIS. We’ll make them in
the form of plug-ins.
On the top of the USRM are the plug-in applications: switched video, VOD,
IMS, and whatever else comes along. This is the product that sits in the
middle and lets you use any protocol for any end device.
To do that, we need to be “client aware.” When a client device requests
something, we need to know: How big is your screen? How big of an
encoded stream can you accept? Do you need this in MPEG-2 or MPEG-4? By
having this device in the control center, you’re aware of what needs to
happen at the ends of your network.
|
