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]{.underline}

July 7, 2000

#### TABLE OF CONTENTS

SUMMARY [ii](#summary)

BACKGROUND [2](#background)

THE DIGITAL SECURITY MODULE AND ITS INTERFACE
[4](#the-digital-security-module-and-its-interface)

the Analog POD MODULE REQUIREMENT FOR HYBRID BOXES
[13](#the-analog-pod-module-requirement-for-hybrid-boxes)

CONCLUSION [19](#conclusion)

# [SUMMARY]{.underline}

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]{.underline}. 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]{.underline}**

Pursuant to the Commission\'s [Report and Order]{.underline} 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]{.underline}.[^1]

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]{.underline}. 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]{.underline}.

# [BACKGROUND]{.underline}

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]{.underline}.

On June 24, 1998, the Commission released its [Report and
Order]{.underline} 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]{.underline}, 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]{.underline} 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.[^2]

In the course of the [Navigation Devices]{.underline} 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]{.underline} boxes, but also to
[analog]{.underline} and [hybrid boxes]{.underline} ([i.e.]{.underline},
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]{.underline} also included (without change)
the industry-provided schedule of interim milestones for development of
the digital separate security module and specifications for its
interface.[^3]

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.[^4] 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\]."[^5] This is the fourth of those
status reports.

# [THE DIGITAL SECURITY MODULE AND ITS INTERFACE]{.underline}

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."[^6] [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]{.underline}.

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,[^7] 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.[^8]

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."[^9]

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.[^10] 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."[^11] 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 CableNET®, 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.[^12]

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.[^13] 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]{.underline} order. It must be remembered that, if
the retailers' argument is accepted -- [i.e.]{.underline}, 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.]{.underline}, 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.[^14] 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.]{.underline}, 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]{.underline}, 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."[^15]

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.[^16] 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]{.underline} orders or rules and certainly was not required to
be achieved by July 1, 2000.

# [the Analog POD MODULE REQUIREMENT FOR HYBRID BOXES]{.underline}

In addition to requiring the separation of security from non-security
functions in [digital]{.underline} navigation devices, the Commission
initially ordered that the separation requirement also be applied to the
[analog]{.underline} 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]{.underline}, 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]{.underline}, 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.]{.underline}, to eliminate any disincentive a consumer
might have to obtain a digital set-top

box at retail.[^17]

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]{.underline} 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.[^18] 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.[^19] 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[^20] 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."[^21]

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]{.underline} Order.[^22] 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.[^23] 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.[^24]

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]{.underline}
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.[^25] In no event can it
be said that these [de]{.underline} [minimis]{.underline} waiver
requests were not filed in "good faith."[^26]

Finally, we note that the Commission has already indicated flexibility
with respect to the July 1, 2000, deadline for availability of the
separate [analog]{.underline} POD module. In its brief in the
consolidated appeals of the FCC's [Navigation Devices]{.underline}
orders, the Commission specifically addressed the argument that applying
the July 1, 2000, deadline to [analog]{.underline} POD modules was
arbitrary since that date was based upon an industry-supplied deadline
for [digital]{.underline} 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]{.underline}.

\* \* \*

> [\[N\]othing is set in stone]{.underline}. The Commission made
> abundantly clear that it would monitor industry progress and market
> conditions to evaluate the appropriateness of retaining its compliance
> deadlines.[^27]

# [CONCLUSION]{.underline}

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:

[^1]: In the Matter of Implementation of Section 304 of the
    Telecommunications Act of 1996, Commercial Availability of
    Navigation Devices, [Report and Order]{.underline}, CS Docket No.
    97-80, 13 FCC Rcd 14775 (1998)("[Report and Order]{.underline}").
    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.

[^2]: 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.]{.underline} 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.]{.underline} equipment
    could be used with both a cable operator and DBS provider. [Report
    and Order]{.underline}, 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]{.underline} page 5, [infra]{.underline}.

[^3]: [Report and Order]{.underline}, 13 FCC Rcd at 14806-07(¶77).

[^4]: [Id]{.underline}. at 14808-09(¶81), 14827-28(¶139).

[^5]: [Id]{.underline}.

[^6]: Status Report, filed in CS Docket No. 97-80, at 1-2 (Jan. 7, 2000)
    ("January 2000 Status Report").

[^7]: [See]{.underline} [Report and Order]{.underline}, 13 FCC Rcd at
    14806 (¶77).

[^8]: January 2000 Status Report at 6-7.

[^9]: Comments of Circuit City Stores, Inc., in PP Docket No. 00-67,
    filed May 24, 2000 at 3 ("Circuit City Comments").

[^10]: 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]{.underline}*.*

[^11]: [Id]{.underline}*.* 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.

[^12]: 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.

[^13]: "Scientific-Atlanta readies for retail of set-top boxes,"
    [The]{.underline} [Atlanta]{.underline} [Constitution]{.underline},
    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\].")

[^14]: [See]{.underline} [Report and Order]{.underline}, 13 FCC Rcd at
    14823 (¶126)("\[W\]e have not adopted specific rules to mandate
    portability or interoperability.")

[^15]: "MSOs Tread Carefully Into Retail World: Retailers Want Piece of
    the Profits, Too," [Multichannel News]{.underline}, May 1, 2000 at
    121. [See]{.underline} [also]{.underline}, "Scientific-Atlanta
    readies for retail of set-top boxes," [The Atlanta
    Constitution]{.underline}, 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.").

[^16]: [See]{.underline} [id]{.underline}. 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\].")

[^17]: [See]{.underline} In Re Implementation of Section 304 of the
    Telecommunications Act of 1996, Commercial Availability of
    Navigation Devices, [Order on Reconsideration]{.underline}, 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]{.underline} [Order]{.underline}").

[^18]: \<http://www.opencable.com/(visited July 6, 2000).

[^19]: [See]{.underline} NCTA Comments in Support of Waiver Requests,
    CSR 5545-Z, 5548-Z, filed May 22, 2000, at 8.

[^20]: It should be noted that these observations are consistent with
    the Commission\'s own conclusions with respect to the demand for
    "analog-only" devices. [Reconsideration Order]{.underline}, 14 FCC
    Rcd at 7602 (¶13) ("We believe that the perceived lack of consumer
    demand would make manufacturers unlikely to manufacture and
    retailers unlikely to carry analog navigation devices even if the
    Commission denied rehearing on this issue.")

[^21]: Circuit City Stores, Inc. Opposition to Petitions for
    Reconsideration, CS Docket No. 97-80, September 23, 1998, at 18.

[^22]: [Report and Order]{.underline}, 13 FCC Rcd at 14795 (¶52). [See
    also]{.underline}, Brief For Respondents, [General Instrument
    Corporation, et al. v. FCC]{.underline}, Case No. 98-1420, filed
    December 1, 1999 at 39 ("\[D\]evelopments in the analog environment
    were more advanced \[than in the digital environment\]. Thus, the
    agency noted that the EIA-105 decoder interface standard -- which
    provides a possible means of separating security in the analog
    environment -- already was complete and had been approved as an
    Electronics Industry Association standard.... The decision to base
    the deadline for \[analog\] separated security on the digital
    schedule, where less progress had been made, was entirely
    justified.")

[^23]: [See]{.underline}, [e.g.,]{.underline} Charter Communications,
    Inc., Request for Waiver of 47 U.S. §76.1204, CSR 5545-Z, filed
    April 26, 2000; AT&T Broadband, L.C., Petition for Special Relief
    Under 47 C.F. §76.7, CSR 5548-Z, filed May 5, 2000.

[^24]: ^?^ The report was also published on the NCTA Website at
    \<http://[www.ncta.com](http://www.ncta.com/)/(visited July 6,
    2000).

[^25]: [Reconsideration Order]{.underline}, 14 FCC Rcd at 7603(¶16).

[^26]: [See]{.underline}, In the Matter of Charter Communications, Inc.,
    et al., Petitions for Waiver of the Requirement to Provide Point of
    Deployment Modules in Section 76.1204 of the Communication's Rules,
    CSR Nos. 5545-Z, et al., [Order]{.underline}, DA 00-1483, released
    June 30, 2000, at ¶4. It can be assumed that if the waiver requests
    had been filed earlier, as upgrades were in process, waivers for a
    greater number of subscribers would have had to have been requested,
    and changes to the requests would have had to be made as upgrades
    progressed prior to July 1, 2000. In fact, MediaOne recently
    withdrew its petition for special relief because it had completed
    the upgrades discussed in its petition prior to July 1, 2000.
    [See]{.underline} Letter from Susan M. Eid, Vice President, Federal
    Relations, MediaOne, to Deborah Lathen, Chief, Cable Services
    Bureau, in CSR 5560-Z, June 24, 2000.

[^27]: Brief for Respondents, [General Instrument Corporation, et al. v.
    FCC]{.underline}, Case No. 98-1420, filed December 1, 1999 at 19, 39
    (emphasis added).