At last week’s SCTE Cable-Tec Expo in Denver, the OpenCable Application Platform (OCAP) may have lacked some sizzle when compared to other hot topics such as switched digital video, but while OCAP may have not been center stage, it was still on the minds of many attendees as evidenced by the large turnout for Friday afternoon’s OCAP session.
Time Warner Cable‘s Sherisse Hawkins, senior director, set-top box development, advanced technology group, and Charter‘s Don Watson, director, advanced engineering, digital video, outlined some of their lessons learned in preparing for OCAP deployments. OCAP, which was developed by cable operators and CableLabs, includes a middleware stack of software that resides between applications and the operating system within a consumer electronics device such as a set-top box or OCAP-compliant TV set. OCAP falls within the broader OpenCable initiative, which CableLabs launched in 1997 to promote the deployment of interactive services over cable. OpenCable efforts have ranged beyond OCAP and its several extensions to encompass specifications that advance CableLabs’ stated goals of defining next-generation digital consumer devices, encouraging supplier competition and creating a retail hardware platform. Hawkins’ presentation drew upon TWC’s work in its Westminster, CO, lab and its trial in Gastonia, NC, on Scientific Atlanta‘s DNCS 4.0 version, the latter of which used Samsung‘s OCAP-compliant high definition TV set. According to Hawkins, the seven keys areas that have the most impact and take the most time to integrate for OCAP are: the OCAP compliant host and remote; the separable security component, i.e. CableCards; OCAP middleware platform; the monitor application; other OCAP applications; the object carousel; and XAIT signaling. "The monitor application is the highest priority, and that means it’s loaded first, and it’s in residence all of the time," Hawkins said. "It does resource management. For example, when there are multiple applications on the network it determines who goes next and manages the lifecycle of each application." The monitor application is signaled via XAIT (extended application information table). Headend systems need to support the XAIT signaling prior to OCAP deployment. "There are a number of different signaling components within OCAP, but XAIT is especially important because it’s the first thing that needs to happen for applications to run, and it triggers all of the other events in OCAP," Hawkins explained. As far as the CableCards go, "friendlies" obtained the cards in the Gastonia trial and installed the CableCards themselves, so there wasn’t an issue of customers pulling them out of the Samsung TV sets. The trial didn’t test downloads because it wasn’t implemented in that version of the OCAP stack, but Hawkins said downloads were slated to take place in TWC’s lab by the end of the month. Some of the other challenges in the lab included many vendors being integrated for the first time, which required updating the middleware. A "small surprise" in the lab included the OCAP remote control devices, which didn’t include settings and DVR keys. Hawkins also talked about the colors of the keys on the remotes themselves. "I was just illustrating the point that the remotes, their keys, button color variation, and location will be at the discretion of an OCAP host provider," she wrote via email earlier this week. "Any references to specific keys in an application that the customer uses should be carefully evaluated. If you assume the ‘red key’ is a very specific color, and put a graphic/picture of that key on the screen as a reminder to the user, they may become confused if their specific remote has a key which is not the same shade of red. "Perhaps that was too subtle of an example, but my point was the cable provider will need to deal with a much wider variability in remote control types than ever before, and the remote is a key tool we give each of our customers." Hawkins also said she searched the Expo show floor looking for diagnostic tools to help test elements in the OCAP environment, but was unable to find any. Having a good "canary" set-top box on hand helps because if it’s working, then the problem can be traced to other elements that may have changed. With so many components in the OCAP environment, good engineering practices such as isolating problems in one area, such as the monitor application, before moving to another is a good idea, according to Hawkins. Charter builds OCAP headends in lab Watson showed some slides about his company’s two OCAP headends in St. Louis during his presentation. The Motorola 3.1 and Scientific Atlanta SR4.0 headends take up three racks, along with a work desk that includes an S-A DNCS Sun V880 server, and an extension of the out-of-band signaling data network was configured to the Charter OCAP development lab in Denver. On the technology side, Watson said DOCSIS Set-Top Gateway (DSG) was critical for Charter’s OCAP architecture, which includes a separate RADD for DSG boxes in the Motorola headend. With "a significant amount of headend work for OCAP," Watson said the criteria for identifying initial deployment markets includes the strength of the engineering team, diverse vendors for conditional access and VOD, a completed telephony launch and retail relationships. "Program management is essential for getting OCAP deployed," he said. "We’re focusing on integration requirements for vendors. We’re making sure as we deploy we can monitor."