Case Study: Simulcrypting with PowerVu

DigitalGlue was awarded a contract to both modernize and standardize the compression/stat-muxing and modulation networks at the AFN-BC in Riverside, CA, which distributes AFRTS to servicemen, retirees and their families worldwide.

The Issue: AFN had been locked into a single specific vendor for years whose systems were architected and implemented in a proprietary silo manner. Even their products, which adhered to an open-system DVB- compliant standard as stand-alone devices, did not interface well with other vendors’ products, making replacement through attrition difficult. This resulted in the vendor’s ability to leverage its monopoly on the customer. The more receivers that were purchased and deployed, the more entrenched the vendor became, and the more expensive it would be to do a forklift upgrade.

The Complexity: The new system was required to be fully DVB-Compliant, but also had to be backwards compatible with up to 65,000 receivers that were in the field. The requirement was to create an open-system environment so that any future DVB-Compliant STB could be added to the network, relieving the monopoly situation and allowing flexibility and competition. What made this difficult was the need to provide a solution that supported DVB-Simulcrypting with PowerVu to support existing and future STBs.

To ensure we weren’t biting off more than we could chew, we researched thoroughly first and developed a technically viable solution.

The Solution: One of the advantages of DigitalGlue being both a distributor and integrator is that it allows us to fully understand a wide variety of products and obtain distributor pricing on systems that we provide to our customers. Being able to leverage both aspects enabled us to design a system that incorporated best-of-breed products at a reasonable price. With interfacing and interoperability being paramount, this design also provided the ability to replace any single vendor’s product with a different vendor’s product in the future, without having to do forklift upgrades.

We selected Harmonic for the video encoders and statmuxing, IDC for high-density audio encoding with RDS data, Verimatrix for DVB CAS, Nevion for routing and switching, and Newtec for DVB-S2 modulation. At the receive end, we used Harmonic IRDs and ended up designing our own consumer STB with DVR and embedded Verimatrix decryption.

The Details: Multicrypt wasn’t an option because it requires each elementary stream to be scrambled twice; once by each vendor thus doubling the bandwidth requirements. Simulcrypting only requires the content to be scrambled once, but the key to be encrypted twice; once by CA each vendor, therefore only adding the additional ECM bandwidth to each transport stream.

Anyone who has ever attempted to do so can tell you that interfacing anyone’s CA system with anyone else’s mux/scrambler is not for the faint-hearted. It requires a lot of research, lab experimentation, and tweaking to get it right, and running optimally. Between protocol versions and a variety of interpretation/implementation of specifications that don’t necessarily match 100% between vendors, details matter and drove architecture approaches. Then there’s setting up the EMMg and ECMg interfaces of both sets of equipment and for the opposing pieces. Redundancy complexity also comes into play, as this vendor uses both sets of IP addresses, and the other vendor uses a common virtual IP address. And I’m just scratching the surface.

We knew going into it that we would have to upgrade the STBs, and then switch from AES encryption to DVB- CSA. Luckily this upgrade can be done on the fly with Cisco equipment. We also knew that Cisco would not support our efforts. When they told us that it couldn’t be done, that challenged us. One of the things we discovered was that even when attempting to do a DVB deployment, the Cisco CAS system as a standalone is still NOT compatible with any other standalone mux. You must use their DCM 9200 in MetroMux mode in order to simulcrypt. You also have to use their PCAM, PNC and ROSA, because their processes and functionality are spread across multiple devices. That’s the penalty of complexity you have to pay in order to get out of their stranglehold. Where we were going to use the Harmonic ProStream 9000 for both statmuxing and DVB scrambling, we had to back off and use it just for statmuxing and the MetroMux for scrambling both PowerVu and Verimatrix. In the future, we can migrate the Verimatrix back into the ProStream once the PowerVu receivers have been replaced in the field and remove the MetroMux altogether. This transition plan meets the immediate need and sets the stage for a simpler future configuration.

SMS: With two different CAS solutions simulcrypting at the headend and two different populations of STBs, requiring two different sets of commands to do the same thing presented operations with some interesting challenges. We re-wrote our Subscriber Management System (PriSMS) to operate with both CAS systems, but using the same operator GUIs, and also did some customization specifically for the customer. In this approach, the SMS has to know what type of CAS/STB it is commanding, but the operator doesn’t.

The Results: AFN now has a modern, reliable, flexible, resilient system, simulcrypting with PowerVu and Verimatrix for DVB, with an SMS that has a common GUI for both systems. They have the luxury of time for decommissioning the old STBs, or they could choose to replace them all in bulk whenever they desire. After the last Cisco box has been removed, the Verimatrix can be ported back into the ProStream mux for scrambling – and say goodbye to Cisco for good.

‍