Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D.C. 20554 In the Matter of ) ) Implementation of Section 304 of the ) CS Docket No. 97-80 Telecommunications Act of 1996 ) ) Commercial Availability of ) Navigation Devices ) STATUS REPORT July 7, 200 TABLE OF CONTENTS SUMMARY ii BACKGROUND 1 THE DIGITAL SECURITY MODULE AND ITS INTERFACE 1 THE ANALOG POD MODULE REQUIREMENT FOR HYBRID BOXES 1 CONCLUSION 1 SUMMARY As a result of CableLabs' successful efforts in developing specifications to enable manufacturers to build digital Point-of-Deployment ("POD") separate security modules and in assisting manufacturers in developing products compliant with those specifications, cable operators met the Commission's July 1, 2000, deadline to have digital separate security modules available for customers who obtain their digital "host" set-top boxes at retail stores. In addition, manufacturers of retailer-supplied boxes have all of the "build-to" specifications they need to build a first generation, OpenCable-compliant set-top box although apparently no retailer has placed orders for such boxes. CableLabs is continuing its efforts, in conjunction with cable operators, consumer electronics equipment manufacturers and retailers, to develop next generation navigation devices with "middleware" to foster the portability of navigation devices. While the FCC has made clear it wants to promote nationwide portability, that goal is not one that was subject to the July 1, 2000, (or any other) FCC deadline or rule. As for the requirement for an analog separate security module for use in hybrid boxes sold at retail, no manufacturer has come forward to build an analog separate security module based on the Decoder Interface specification published by CableLabs, and, to our knowledge, no retailer has ordered a hybrid host device based on those specifications. Nevertheless, cable operators have taken a number of approaches to satisfy the FCC's analog separate security rule in light of these facts. In particular, at the cost of scarce channel space, they have duplicated their scrambled analog programming on digital tiers so that consumers will have no disincentive - based on the lack of an analog POD module - to purchase digital boxes at retail. And, in fact, because no retailers appear to have placed orders for digital set-top boxes, the absence of an analog separate security module - or even the inability of a cable operator to upgrade its system to permit duplication of its scrambled analog programming - will have no effect on subscribers' incentives to obtain digital boxes at retail. In any event, for the small percentage of subscribers covered by pending "analog POD" waiver requests, as soon as their systems are upgraded or other steps are taken, they too will be unaffected by the absence of an analog separate security module. Before the FEDERAL COMMUNICATIONS COMMISSION Washington, D.C. 20554 In the Matter of ) ) Implementation of Section 304 of the ) CS Docket No. 97-80 Telecommunications Act of 1996 ) ) Commercial Availability of ) Navigation Devices ) STATUS REPORT Pursuant to the Commission's Report and Order in the above-captioned proceeding, the undersigned multiple system operators ("MSOs") and the National Cable Television Association ("NCTA") hereby submit the fourth semiannual progress report called for in the Report and Order. As we report herein, cable operators met the Commission's July 1, 2000 deadline to have digital separate security modules available for customers who obtain digital "host" set-top boxes at retail stores. Specifications for digital set-top boxes were released in October 1999, and at least two manufacturers have approached retailers offering to build such boxes. However, to our knowledge, no retailer has placed an order for digital set-top boxes which will accommodate the digital security modules now available from cable operators. BACKGROUND The Commission ordered the filing of semiannual status reports to assure itself that the cable industry, through Cable Television Laboratories, Inc. ("CableLabs"), was making steady progress in the development of specifications for a digital security "Point of Deployment" ("POD") module and for a digital security module interface as well as to apprise it of other industry efforts to foster the availability of navigation devices as required by the Report and Order. On June 24, 1998, the Commission released its Report and Order in this proceeding implementing Section 304 of the Telecommunications Act of 1996. Section 304 calls upon the Commission to adopt rules to ensure the commercial availability of navigation devices, while not jeopardizing the signal security of an affected multichannel video programming distributor ("MVPD"). As part of that Report and Order, the Commission determined that one means of implementing these twin goals was to separate security functions from non-security functions and to require that only the non-security functions be made commercially available in equipment provided by entities unaffiliated with the MVPD. The security functions would reside in a separate security module to be obtained from the MVPD. In its decision, the Commission referenced the ongoing effort of CableLabs, a research and development consortium of cable television system operators representing both North and South America, to develop specifications for both a digital security module and a digital security module interface. The OpenCable effort was focused on cable's digital set-top boxes. It was envisioned that once such specifications were developed and the interface was adopted as an industry standard, manufacturers could produce digital navigation devices (such as digital cable set-top boxes) with the standardized digital security module interface and make such equipment available at retail. Cable operators would then supply a compatible digital security module to the customer. Significantly, the Commission expressly declined to require that either the POD module or the host devices be portable or interoperable. In the course of the Navigation Devices proceeding, the Commission requested from the cable industry a schedule of milestones for meeting the OpenCable forecast of September 2000 for having digital security modules available from cable operators. The schedule submitted to the Commission included milestones for the development of specifications for the digital security module and the digital security module interface. It also included a post-specification time-line for development and production of the digital security module. The Commission adopted a more aggressive schedule than the existing CableLabs schedule and ordered that digital security modules be available from cable operators by July (not September) 2000 and applied that deadline not only to digital boxes, but also to analog and hybrid boxes (i.e., those that descramble both analog and digital signals). On reconsideration, the Commission concluded that the analog separate security requirement would not apply to "analog-only" boxes but would still apply to "hybrid" boxes if a cable operator deployed hybrid boxes and its subscribers used the analog descrambling capabilities of those boxes. The Report and Order also included (without change) the industry-provided schedule of interim milestones for development of the digital separate security module and specifications for its interface. Eight multiple system operators involved in the OpenCable project, as well as Motorola (then General Instrument Corporation) and Scientific-Atlanta, had made commitments to that project in a letter to NCTA, which was submitted for the record in this proceeding. To "assure itself that the schedule was being met," the Commission ordered the MSOs to file semiannual progress reports with the Commission. In those reports, the MSOs were asked to detail "the progress of their efforts and the efforts of CableLabs to assure the commercial availability to consumers [of navigation devices]." This is the fourth of those status reports. THE DIGITAL SECURITY MODULE AND ITS INTERFACE As we have been reporting, CableLabs has been "on track in developing and delivering the information necessary so that manufacturers can build digital security modules and host devices with a digital security module interface." Because digital separate security or "POD" modules from two manufacturers were verified as interoperable by CableLabs, cable operators were able to have them available for their customers by the Commission's July 1, 2000 deadline. The milestones specified in the initial CableLabs/OpenCable work plan, employed by the Commission as the framework for establishing the accelerated timetable for implementation of the digital separation requirement, have been achieved through the efforts of CableLabs and industry participants, including members of the consumer electronics industry. These efforts included completion of Phase I testing for the preliminary digital security module prototype, construction of a prototype for the final digital POD module form-factor, together with Phase II testing for the final form-factor prototype. Since the beginning of this year, several prospective digital POD module vendors completed the final form-factor work, as well as full product demonstrations, and two - Motorola and Scientific Atlanta - submitted digital POD modules to the CableLabs Review Board for testing during the six-week CableLabs review process which began on May 22, 2000. On June 29, 2000, CableLabs completed its first OpenCable test wave and verified the interoperability of the digital removable security devices submitted by Motorola and Scientific- Atlanta. In so doing, the Review Board verified that the removable POD modules were able to support analog video and audio and digital video and audio, and were able to decrypt digital video and audio in both manufacturers' host devices. Accordingly, cable operators were able to take delivery of digital POD modules by July 1, 2000 to meet consumer demand. As might be expected with the roll-out of new equipment, some software bugs have been found with POD modules and host devices of one manufacturer when they were tested in the field with an MSO's specific system configuration. Work is underway to correct these problems where they occur. In addition, the other manufacturer has provided working POD modules and headend software to all of its customers to demonstrate compliance with the FCC requirements and it has begun providing software upgrades to headends. The minor debugging of some POD module software and the software upgrading of certain headends to fully support the digital POD modules should have no negative effect on the commercial availability of navigation devices. This is so because, to our knowledge, no retailer has placed an order for compatible "host" set-top boxes, despite the fact that the specifications for both unidirectional and bi-directional set-top boxes were completed in October, 1999 when they were released to the public. Some retailers have defended their failure to order host devices built to OpenCable specifications by claiming that specifications for "unidirectional" (non-interactive) devices have been "late and incomplete" and that specifications for "bi-directional" (interactive) devices will be "at least a year behind schedule" and "at least a year away from reaching consumers." But these assertions ignore the fact that CableLabs has worked tirelessly to facilitate the design and introduction of host devices that operate in conjunction with OpenCable-compliant POD modules. Most notably, in October 1999, OpenCable publicly released complete specifications for "interactive" and "non-interactive" host devices that can operate on bi- directional and unidirectional cable systems, respectively. These specifications, which were the product of a two-year effort by CableLabs - and included a rigorous review process - spell out for suppliers and others how to build products compatible with the OpenCable architecture. With the release of these specifications, the January 2000 Status Report noted, "manufacturers could begin building first generation OpenCable-compliant digital set-top boxes for delivery by July 2000 that will work with cable-operator supplied OpenCable-compliant POD modules." And, indeed that is what some manufacturers did. At the Western Cable Show this past December, CableLabs and the California Cable Television Association co-sponsored CableNETr, an educational forum demonstrating the potential of the cable industry's hybrid fiber/coaxial systems. As a part of CableNET, numerous companies teamed together to demonstrate the progress they had made in achieving interoperability. CableLabs conducted interoperability tests involving nine major consumer electronics manufacturers, five conditional access suppliers, and three headend suppliers. Among the OpenCable interoperability host device providers at CableNET were General Instrument, Microsoft, Panasonic, Philips, Samsung, Scientific-Atlanta and Zenith. POD module manufacturers included: General Instrument, Mindport, NDS, Nagravision, Scientific Atlanta and SCM Microsystems. In addition, headend equipment providers for OpenCable were DiviCom, General Instrument and Scientific-Atlanta. Retail participants included Microsoft, Pioneer, and Sony. Those tests demonstrated a significant level of interoperability between various removable security or POD modules and host devices. Further interoperability tests were held in March - involving many of the same vendors - in which significant progress in the development of POD modules and host devices was demonstrated. In April, CableLabs sponsored a hardware developers' conference, which was designed to bring together companies that provide components or technology sub-systems with manufacturers of host devices to help them build to OpenCable specifications. Finally, two vendors submitted digital host devices to the CableLabs Review Board for testing in the six- week OpenCable test wave that began May 22, 2000. While neither vendor's host device passed the rigorous OpenCable testing process, it is expected that those vendors - and perhaps others - will submit host devices for testing in the next test wave beginning July 10, 2000. In addition to OpenCable interoperability events, considerable bilateral activity has occurred and is occurring between individual vendors in preparation for the interoperability events. Companies can learn - and have learned - a great deal from these joint efforts to get two manufacturers' products working together. This kind of intensive effort greatly increases the value of the formal interoperability events conducted by CableLabs. These efforts by CableLabs (with the significant input of consumer electronics manufacturers) make plain that the specifications released by CableLabs for unidirectional set- tops were neither "late and incomplete" nor were the bi-directional specifications "at least a year behind schedule." In fact, manufacturers have the information available to build unidirectional and bi-directional set-top boxes comparable to the digital boxes cable operators deployed when the Commission set the July 1, 2000, deadline. Nevertheless, while apparently conceding that the specifications released are sufficient to build host devices, some assert that the bi-directional specifications will not produce a set-top box equal to those cable operators currently provide. In fact, manufacturers of set-top boxes are free to incorporate their own unique features in those boxes, as do existing set-top box manufacturers, as long as the boxes work with the services, features, and functions offered by the purchaser's cable system and do not jeopardize signal security or cause harm to the network. Boxes built to the OpenCable bi-directional specifications will indeed be a platform comparable to the bi-directional boxes cable operators deploy - or at least those deployed when the Commission issued its Navigation Devices order. It must be remembered that, if the retailers' argument is accepted - i.e., that OpenCable must immediately produce set-top box specifications identical to those used in boxes newly-introduced by any cable operator - it would be an impossible task. CableLabs would constantly be shooting at a moving target, as new services are introduced by operators across the country - services which vary widely from operator to operator and system to system. In this regard, CableLabs is developing further extensions to the current specifications, which will include specifications for standardized Application Programming Interfaces ("APIs") or "middleware," designed to enhance the portability of OpenCable products across brands and operating systems. As a result, set-top boxes will be upgradable with a software download to support all of the services offered on any cable system. Given that the initial implementation of innovative services such as VOD and web-like TV services will vary widely, the only practical solution to providing portability of navigation devices is the OpenCable middleware initiative. Contrary to some retailers' assertions, this middleware initiative is not "behind schedule," because there was no FCC requirement that OpenCable develop specifications to assure portability of navigation devices - i.e., the ability of one set-top box to be used on any cable system. In fact, the Commission specifically disclaimed any requirement that navigation devices be portable. The middleware initiative is just one of many CableLabs' projects which further demonstrates the industry's commitment to work with vendors and other interested parties to achieve the goals of retail availability - and eventually portability - of navigation devices. In addition, some retailers argue that they refuse to place orders for unidirectional or bi- directional set-top boxes because they are waiting for specifications for a bi-directional integrated digital television ("DTV") set, i.e., a DTV set with bi-directional set-top box functionality built into the set, specifications which some retailers claim are "at least a year behind schedule." Those who make this argument ignore the fact that it is unlikely the FCC envisioned the July 1, 2000, deadline as encompassing a requirement that CableLabs and the cable industry develop specifications for an integrated DTV set. This is because (1) the OpenCable effort upon which the FCC said it would rely for the development of specifications was at that time only addressing separation of security from non-security functions in set-top boxes, not in integrated DTV sets, and (2) there were no such sets available when the July 1 deadline was imposed. In any event, an integrated bi-directional DTV set can be developed based on the specifications for the bi-directional set-top box which are available. Despite the fact that integrated DTV sets were not the subject of the OpenCable project - which, after all, delivered on its commitment to develop specifications so that a digital separate security module and host set-top box could be produced three months earlier than anticipated - CableLabs and the cable industry have cooperated with the Consumer Electronics Association to clarify specifications needed to build integrated DTV sets. Most notably, last February, the cable and consumer electronics industries reached two agreements on the compatibility of cable systems and digital television sets. The first agreement clarifies a portion of the technical specifications necessary for set manufacturers to build DTV receivers that will connect directly to cable systems to receive digital cable signals. The second agreement details the means to carry Program and System Information Protocol (PSIP) data on cable systems, including virtual channel tables and event information data, to support the navigation function in digital receivers. These specifications have been incorporated into the OpenCable specifications and have been adopted as an SCTE standard (DVS-313r2). Further discussions are expected between the two industries on developing the specifications for the bi-directional (interactive) DTV sets which retailers are justifiably eager to sell. A final word must be said about the absence, on retailers' shelves, of host set-top boxes built to the OpenCable specification. As noted above, retailers make a series of arguments about why they have not placed orders for digital set-top boxes which will accommodate the digital POD modules now available from cable operators. These arguments range from dissatisfaction with the specifications for the set-top boxes to a desire to await the development of the more profitable integrated DTV sets. In reality, it appears the retailers want more out of "commercial availability" then merely being able to sell set-top boxes or even integrated DTV sets. This fact is demonstrated by the unsuccessful efforts of at least one vendor - Motorola - who approached at least two retailers and offered to manufacture for those retailers digital set-top boxes built to OpenCable specifications for July, 2000 delivery. Motorola's presentations were made to one retailer on February 2, 2000 and to the other retailer on March 21, 2000 - both at each retailer's home offices. In essence, the retailers' responses indicated that, while they were interested in selling digital set-top boxes, they would do so only if a satisfactory business model existed that made it financially viable to sell such boxes - they were not interested in selling "just boxes." That reaction is consistent with trade press articles which describe how "[a] few large national retailers hope to hold out for a share of on-going service revenues before they'll market cable modems or digital-cable boxes." While there certainly is nothing wrong with retailers negotiating with cable operators over the terms governing the sale of set-top boxes which will generate revenues for cable operators, it is disingenuous for retailers to assert that the sole reason they have refused to place orders for set-top boxes is because of deficiencies in the specifications. By the same token, as they have done with other retailers, Scientific-Atlanta representatives have met with, and offered to sell digital set-top boxes to, four major retailers. In one meeting with a large retailer on August 18, 1999, Scientific-Atlanta offered to supply that retailer with digital set-top boxes built to OpenCable specifications. While meetings between the two parties continue, the retailer expressed concerns about the absence of "middleware" specifications. Again, there is nothing wrong with a retailer declining to stock one product because a better product is on the horizon. What is wrong, however, is asserting that the cable industry and the OpenCable effort have not developed workable host device specifications. Even more egregious is the claim that the cable industry did not develop middleware specifications "on time" when the portability which those specifications facilitate was not required by the FCC's Navigation Devices orders or rules and certainly was not required to be achieved by July 1, 2000. THE ANALOG POD MODULE REQUIREMENT FOR HYBRID BOXES In addition to requiring the separation of security from non-security functions in digital navigation devices, the Commission initially ordered that the separation requirement also be applied to the analog portion of both analog-only set-top boxes and hybrid boxes with analog and digital descrambling functions. The deadline by which time cable operators had to have available security modules to descramble analog programming in either analog-only or hybrid boxes sold at retail was also set at July 1, 2000. Just over one year ago, in its May 14, 1999, Reconsideration Order, the Commission ruled that the separate security requirement would not apply to operators who deployed analog-only set-top boxes, but it retained the requirement if the operator deployed hybrid boxes and the operator's subscribers used the analog portion of those boxes to descramble analog programming. Despite the fact that some cable operators have filed for waivers of the hybrid box-analog POD module requirement, over 95% of cable subscribers will not be affected by the absence of analog POD modules or hybrid boxes sold at retail, either because the rule does not apply to their cable operator or because the operator has taken other steps - such as duplicating any scrambled analog programming on a digital tier - to achieve the very result for which the rule was adopted, i.e., to eliminate any disincentive a consumer might have to obtain a digital set-top box at retail. As discussed in our earlier Status Reports, CableLabs concluded that the only potentially feasible approach to separating analog security and non-security functions in hybrid boxes was to use either the existing Electronics Industry Association ("EIA") standard EIA-105 "Decoder Interface" or an abridged version of the standard. Including such an interface on hybrid set-top boxes provided at retail would accommodate a connection for an external analog separate security module. This module would be provided by the cable operator and would perform the analog descrambling function. Even before CableLabs proposed this approach to separating analog security from non- security functions, the cable industry recognized the challenges to developing both hybrid set-top boxes to be sold at retail and operator-supplied analog separate security modules for those hybrid boxes. First, the analog modules are not needed in all-digital or all-analog systems. Second, even if an operator deploys hybrid boxes, it need not make available analog POD modules for hybrid boxes sold at retail if its subscribers do not use the analog descrambling portion of the operator's hybrid boxes. That would be the case where, for instance, the operator duplicates its scrambled analog programming on its digital tier(s). A significant number of cable operators who have deployed hybrid boxes have opted to provide just such "duplicated scrambled analog" programming to obviate the need to use the analog descrambling function of the hybrid box. In such circumstances, although the operator must use precious channel space to duplicate its scrambled analog programming on a digital tier, subscribers who obtain a digital set-top box at a retail store will not need to lease an analog or hybrid set-top box with analog descrambling capabilities from his or her cable operator because all programming which is available in the scrambled analog format will also be duplicated in digital form. The only instance where a hybrid digital/analog set-top box may have any utility - and where operators would have had to have available analog POD modules in case a subscriber obtained a hybrid box at retail - is where an operator does not duplicate its scrambled analog programming on a digital tier and where subscribers take both digital services and scrambled analog services. But this is expected to be a very small and rapidly shrinking market segment and production of hybrid boxes which accommodate a separable analog security module - as well as production of analog POD modules themselves - is not likely to be economically feasible. No commenters in any of the related FCC proceedings has disagreed with this assessment. As we said in our earlier reports, it is indeed arguable that this market segment by itself cannot justify the costs to design and build a hybrid digital/analog set-top box to accommodate a separate analog security POD module. In any event, as noted above, CableLabs determined that the only potentially feasible approach for a separate analog security POD module was to use the existing EIA-105 Decoder Interface Standard as a basis for an optional OpenCable specification. In December 1999, OpenCable published optional specifications for an analog interface based on the Decoder Interface standard. That specification - IS-APOD-WD1-991208 - was made available on the OpenCable website. As a result, manufacturers who were asked to build "hybrid" set-top boxes with an interface for an analog POD module and manufacturers who were asked to build analog POD modules could do so if demand were sufficient to build such uneconomic devices. Even with its adoption as an optional OpenCable specification, the Decoder Interface required additional work before commercial production was possible. That work included construction and testing of a prototype as well as interoperability testing as was done with the digital POD modules. CableLabs announced that it stood ready to assist any vendors who requested assistance with design or interoperability testing for such devices. However, responses to RFIs subsequently issued by CableLabs indicated that there is no manufacturer interest in building analog POD modules or hybrid host devices using the OpenCable specifications. Given the economic reality discussed above, this is quite understandable, particularly because such efforts would have diverted essential resources from the development of digital POD modules and host devices. Finally, to our knowledge, no retailer has expressed any interest in selling hybrid host devices and Circuit City, for one, is already on the record as saying the Decoder Interface was "fast becoming an orphan in terms of potential implementation [and] should be put to rest insofar as this [Navigation Devices] proceeding is concerned." While consumer electronics manufacturers and retailers showed no interest in pursuing the production or sale of hybrid host devices, the cable industry made - and continues to make - good faith efforts at substantial cost in time and resources to satisfy the Commission's analog separate security requirement. First, through CableLabs, the cable industry attempted to resurrect the Decoder Interface to use as a basis for the analog POD module and host interface, a course of action strongly - if implicitly - suggested by the Commission's Navigation Devices Order. Second, in January, when it became clear based on responses to the CableLabs RFIs, that no manufacturer intended to build analog POD modules or hybrid boxes based on the Decoder Interface approach, operators examined other options, particularly the duplication of analog scrambled programming on digital tiers. Third, in March, NCTA published a Report entitled "Set-Top Boxes: Are You Ready for J2K (July 2000)?" which described some of the options open to cable operators in the absence of an analog POD module. Operators implemented these approaches and, as a result, over 95% of cable subscribers will not be affected by the absence of analog POD modules and will have no disincentive - based on the absence of such POD modules - to purchase digital boxes at retail. In fact, because apparently no retailer has ordered any host digital set-top boxes, the absence of an analog POD module - or even the inability of a cable operator to complete upgrades to permit duplication of its scrambled analog programming - will have no effect whatsoever on subscribers' incentives to obtain such digital boxes at retail. The analog POD module waiver requests put out for comment by the FCC affect, at most, approximately 5% of cable subscribers; the requests are limited in time; operators filing the requests are committed to instituting measures, primarily upgrading systems to enable duplication of their scrambled analog programming on digital tiers, so that their subscribers will get the benefits intended by the Commission when it adopted the hybrid box-analog POD module rule. In no event can it be said that these de minimis waiver requests were not filed in "good faith." Finally, we note that the Commission has already indicated flexibility with respect to the July 1, 2000, deadline for availability of the separate analog POD module. In its brief in the consolidated appeals of the FCC's Navigation Devices orders, the Commission specifically addressed the argument that applying the July 1, 2000, deadline to analog POD modules was arbitrary since that date was based upon an industry-supplied deadline for digital POD modules. As part of its response to that argument, the Commission and the Department of Justice represented to the Court that: [T]he Commission is monitoring [the] industry's progress toward complying with the July 1, 2000, deadline and has indicated that it will continue to assess the propriety of the deadline based on the semi-annual reports it receives from the industry. * * * [N]othing is set in stone. The Commission made abundantly clear that it would monitor industry progress and market conditions to evaluate the appropriateness of retaining its compliance deadlines. CONCLUSION As a result of CableLabs' successful efforts in developing specifications to enable manufacturers to build digital POD modules and in assisting manufacturers in developing products compliant with those specifications, cable operators had digital POD modules to make available to customers by the July 1, 2000, FCC deadline. In addition, manufacturers of retailer- supplied boxes have all of the "build-to" specifications they need to build a first generation, OpenCable-compliant set-top box although apparently no retailer has placed orders for such boxes. And CableLabs is continuing its efforts, in conjunction with cable operators, consumer electronics equipment manufacturers and retailers, to develop next generation navigation devices with "middleware" to foster the portability of navigation devices. As for hybrid boxes, no manufacturer has come forward to build an analog POD module based on the Decoder Interface specification published by CableLabs, and to our knowledge, no retailer has ordered a hybrid host device based on those specifications. Nevertheless, cable operators have taken a number of approaches to satisfy the FCC's "analog POD module" rule in light of these facts. In particular, at the cost of scarce channel space, they have duplicated their analog scrambled programming on digital tiers so that consumers will have no disincentive - based on the lack of an analog POD module - to purchase digital boxes at retail. And for the small percentage of subscribers covered by pending waiver requests, as soon as their systems are upgraded or other steps are taken, they too will be unaffected by the absence of an analog POD module. In sum, CableLabs and the cable industry have met the Commission's July 1, 2000 deadline for having digital POD modules available for cable customers and for developing specifications for digital set-top boxes. Both the cable industry and CableLabs intend to continue the work they are doing to develop specifications which will provide for the portability of navigation devices (including integrated DTV sets) and which will permit the consumer to receive all of the features and services that their cable operators offer. Respectfully submitted, AT&T BROADBAND & INTERNET TIME WARNER CABLE SERVICES (formerly TCI COMMUNICATIONS) By:_________________________ By:_________________________ JONES INTERCABLE MEDIAONE GROUP By: _________________________ By:_________________________ CHARTER COMMUNICATIONS, INC. ADVANCE/NEWHOUSE COMMUNICATIONS (formerly MARCUS CABLE) By:__________________________ By:_________________________ COX COMMUNICATIONS COMCAST CABLE COMMUNICATIONS By:__________________________ By:_________________________ NATIONAL CABLE TELEVISION ASSOCIATION By:_________________________ July 7, 2000 MOTOROLA BROADBAND SCIENTIFIC-ATLANTA, INC. COMMUNICATIONS SECTOR By: By: In the Matter of Implementation of Section 304 of the Telecommunications Act of 1996, Commercial Availability of Navigation Devices, Report and Order, CS Docket No. 97-80, 13 FCC Rcd 14775 (1998)("Report and Order"). While only the undersigned MSOs were ordered to submit semiannual status reports, Motorola Broadband Communications Sector ("Motorola") (then General Instrument Corporation) and Scientific-Atlanta, Inc. ("S-A") had also signed the letter which was sent to NCTA's president, was submitted for the record in this proceeding, and gave rise to the MSO reporting requirement. For that reason, and because of their contributions to the successful CableLabs effort, Motorola and SA are also signing this Status Report to reflect their continuing commitments to the OpenCable project. As the Commission said: "[W]e have not adopted specific rules to mandate portability or interoperability.. [P]ortability refers to being able to move a device from one geographic area to another and have it able to function with the same type of service provider, e.g. equipment could be used with different cable operators in different parts of the country. Interoperability refers to the ability to operate across different multichannel video programming services interchangeably, e.g. equipment could be used with both a cable operator and DBS provider. Report and Order, 13 FCC Rcd at 14823(126). When CableLabs and we use the term "interoperable" it does not mean the ability of equipment to operate across different MVPD systems as it means in FCC parlance. See page 5, infra. Report and Order, 13 FCC Rcd at 14806-07(77). Id. at 14808-09(81), 14827-28(139). Id. Status Report, filed in CS Docket No. 97-80, at 1-2 (Jan. 7, 2000) ("January 2000 Status Report"). See Report and Order, 13 FCC Rcd at 14806 (77). January 2000 Status Report at 6-7. Comments of Circuit City Stores, Inc., in PP Docket No. 00-67, filed May 24, 2000 at 3 ("Circuit City Comments"). January 7, 2000 Status Report at 7. The October 1999 release included "specifications for hardware elements including the unidirectional functional requirements, the bi-directional functional requirements, the unidirectional terminal requirements, the OpenCable network interface and the host POD module interface," and, while labeled "interim" specifications, "they are essentially final in all respects." Id. Id. at 8. The POD technology supports both unidirectional and bi-directional applications. As currently configured, the POD technology includes the architecture and platform to deploy advanced services. Additional functionality can be deployed through software upgrades to the host. To date, CableLabs has conducted three formal interoperability events, in which twenty manufacturers of digital POD modules and host devices have participated. In addition to these events, POD module and host manufacturers' equipment has been tested at CableLabs, as well as in one-on-one sessions at various manufacturers' sites. "Scientific-Atlanta readies for retail of set-top boxes," The Atlanta Constitution, June 28, 2000, at E-1 (quoting Circuit City spokesman as saying, "Our company's waiting at this time for the evolution of the product. We are hesitant about selling a product that doesn't have the same functionality as boxes leased from [cable companies].") See Report and Order, 13 FCC Rcd at 14823 (126)("[W]e have not adopted specific rules to mandate portability or interoperability.") "MSOs Tread Carefully Into Retail World: Retailers Want Piece of the Profits, Too," Multichannel News, May 1, 2000 at 121. See also, "Scientific-Atlanta readies for retail of set-top boxes," The Atlanta Constitution, June 28, 2000, at E-1, 9 (quoting Wachovia Securities industry analyst George Hunt as saying: "The first thing Circuit City wanted was a portion of the monthly cable bill."). See id. at E-1 (quoting Circuit City spokesman as saying, "Our company's waiting at this time for the evolution of the product. We are hesitant about selling a product that doesn't have the same functionality as boxes leased from [cable companies].") See In Re Implementation of Section 304 of the Telecommunications Act of 1996, Commercial Availability of Navigation Devices, Order on Reconsideration, 14 FCC Rcd. 7596, 7603(16) ("If hybrid boxes were included in the deferral, it is more likely that subscribers would lack incentives to look to the marketplace for a digital navigation device if their equipment choice to receive all services was either to lease a box from the MVPD, or purchase a digital box at retail and obtain a separate analog box and a digital security module from the MVPD.") ("Reconsideration Order").