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}

#####  

January 7, 2000

**TABLE OF CONTENTS**

SUMMARY [1](#summary)

BACKGROUND [3](#background)

SPECIFICATIONS FOR THE DIGITAL SECURITY MODULE AND ITS INTERFACE
[5](#security-module-and-its-interface)

ANALOG SEPARATION SPECIFICATIONS [9](#analog-separation-specifications)

CONCLUSION [13](#conclusion)

**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 third semiannual progress report called for in the
[Report and Order]{.underline}.[^1]

# SUMMARY

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}.

[We are pleased to report herein that, as was the case with the Status
Reports filed in January and July, 1999, CableLabs is once again 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]{.underline}. As a result,
manufacturers should be able to supply cable operators with digital POD
modules by the Commission's July 1, 2000, deadline.

We also report that work has continued on developing a means to separate
[analog]{.underline} security from non-security functions -- a
requirement imposed by the Commission and vigorously opposed by the
cable industry for a number of reasons. As we detailed in our July 1999
report, developing an analog version of the digital POD module would be
costly to consumers, as well as uneconomic, particularly as the
transition to a digital communications environment is well underway.
Moreover, as the Commission knows, the OpenCable effort was focused on
[digital]{.underline} equipment and the Commission\'s July 2000 deadline
for separation of security from non-security functions in all digital
and hybrid set-tops was based on a cable industry timetable for the
[digital]{.underline} POD module only.[^2]

The market for analog POD modules will be limited. Indeed, they are only
necessary for use in the analog component of "hybrid" analog/digital
boxes made available at retail stores. Under the Commission's Rules,
operators need not have analog POD modules available if they do not
deploy "hybrid" boxes or, even if they do, if their subscribers do not
use the analog descrambling functions of the hybrid boxes the cable
operator offers. Nevertheless, as we describe herein, CableLabs has
adopted an optional OpenCable architecture for an analog POD module and
published an analog host interface specification -- both based on the

EIA 105.1 (Decoder Interface) standard. But, based on what we know
today, even under the best case scenario, a reasonably aggressive
product development plan will not result in the availability of analog
POD modules by July 1, 2000.

# BACKGROUND

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
([i.e]{.underline}., conditional access) 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. As the Commission was well aware, 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.

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]{.underline} for having
[digital]{.underline} security modules available from cable operators.
The schedule submitted to the Commission included milestones for the
development of specifications for the [digital]{.underline} security
module and the [digital]{.underline} security module interface. It also
included a post-specification time-line for development and production
of the [digital]{.underline} security module.

The Commission adopted a more aggressive schedule than had CableLabs 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. 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 his
subscribers used the analog descrambling capabilities of those boxes.
[The Report and Order]{.underline} also had included (without change)
the industry-provided schedule of interim milestones for development of
the [digital]{.underline} separate security module and specifications
for its interface.[^3]

Eight multiple system operators involved in the OpenCable project 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 those MSOs to file
semiannual progress reports with the Commission.[^4] The Commission
established filing dates of January 7, 1999, July 7, 1999, January 7,
2000, and July 7, 2000, for the MSOs 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
third of such status reports.

# SPECIFICATIONS FOR THE DIGITAL 

# SECURITY MODULE AND ITS INTERFACE

[We are pleased to inform the Commission that CableLabs is on track for
developing and delivering the information necessary so that
manufacturers can build digital security modules and host devices with
the digital security module interface by July 2000.]{.underline}

As for the development of specifications for the digital security module
(the POD module), the schedule called for the completion of a
specification by December 1998 and, as reported in our first Status
Report, that has been accomplished.

With respect to the development of specifications for the digital
security module interface, the schedule called for a recommended
specification to have been made publicly available and released to the
Society of Cable Telecommunications Engineers (\"SCTE\") for adoption as
a U.S. standard by December, 1998. As we previously reported, the
digital security module interface specification not only was submitted
to SCTE by year-end, 1998, but it was also [approved]{.underline} by
SCTE as a U.S. standard in December 1998.

In our first report, we cited concerns expressed by the Motion Picture
Association of America ("MPAA") and others that a copy protection scheme
should be adopted to provide protection of digital content across the
interface between the module and the host device. Since the filing of
the last report, such a specification was agreed upon by MPAA and the
cable industry, and that specification has been advanced within a
working group of the SCTE Digital Video Subcommittee (\"DVS\"). This
specification has been subject to continuing review and comment by the
MPAA, the cable industry, the consumer electronics industry and the
companies owning the selected copy protection technology, to ensure that
the specification, which involved new technology, is workable. Of
course, the use of content protection technology is subject to
developing an acceptable licensing program and appropriate licensing
agreements.

The cable industry has adopted a suitable copy protection solution as an
OpenCable specification and vendors have signaled their intent to build
to this specification for the development of the POD module in order to
meet the July 1, 2000, Commission requirement. In parallel, the cable
industry will work with SCTE and its members to secure the
standardization of this specification.

With respect to milestones occurring between our July Status Report and
this filing, we are pleased to report that (1) OpenCable has completed
Interoperability Testing for a preliminary digital security module; and
(2) a prototype for the final digital security module form-factor has
been completed -- events that were scheduled to be accomplished by (1)
July 17, 1999 and (2) December 1, 1999, respectively. By form factor we
mean the final physical shape which the security module will take. In
this case, that shape is the PCMCIA standard for PC cards.

In addition, OpenCable has completed the first round of Interoperability
Testing for the final digital security module form factor.
Interoperability testing is important because, initially, PODs are built
with no constraints as to size in order to demonstrate that they can
carry out their functional rule. Then vendors proceed to "shrink" the
POD into a package required to meet the form factor requirements.
Vendors are in the process of doing the size reduction for the
interoperability tests and the results look promising.

We must note, however, that while a form factor for the POD module has
been completed, only two companies have done so, potentially limiting
the supply of such modules by the July 1, 2000, deadline. The two
companies are General Instrument and Scientific-Atlanta, two key
vendors. Other companies are attempting to transition from their
existing products which were designed to a European, DVB specification.
While these companies have not completed the final form factor work,
form factors are not the only measure of progress, and all
interoperability event participants had made significant progress that
allowed them to participate in the December interoperability event.
Although completion of such testing was to have been accomplished by
January 1, 2000, additional testing has been scheduled to assure even
wider interoperability.

In October 1999, CableLabs publicly released the final five POD-related
OpenCable 1.0 Interim 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. These
five Interim specifications completed all major hardware elements of the
OpenCable specifications. While labeled "Interim" specifications, they
are essentially final in all major respects. In fact, CableLabs defines
"Interim Specification" as "a document which has undergone rigorous
\[MSO\] and vendor review, suitable for use by vendors to design in
conformance to and for field testing."

The FCC's rules do not require cable operators to have host devices with
interfaces for PODs (at least until January 1, 2005). Nevertheless,
CableLabs has been conducting interoperability tests to assist
manufacturers of such host devices in making sure those devices work
with the POD. In this regard, based on draft specifications published in
August, nine manufacturers had completed sufficient development to bring
host devices to the interoperability

testing event in December. The purpose of the Interim specifications was
to spell out for suppliers and others how to build products compatible
with the OpenCable architecture for digital video systems, which will
interoperate across the majority of cable systems. With their release,
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.[^6]

Other activities demonstrate the steady progress being made by the
OpenCable effort. For example, 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 show their work
achieving interoperability. CableLabs and the undersigned MSOs are
working with the rest of the cable industry through these events and
others which will foster the commercial availability of digital set-top
boxes.

Among the OpenCable interoperability host device (set-top) 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,
head-end equipment providers for

OpenCable were DiviCom, General Instrument and Scientific-Atlanta.
Retail participants included Microsoft, Pioneer, and Sony.

In addition to OpenCable interoperability events, considerable bilateral
activity has occurred and is occurring between individual vendors in
preparation for the interoperability

events. For example, a number of companies have also worked together in
a group, calling

themselves the POD Interoperability Forum. 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.

One last note: While the OpenCable effort has met virtually all of the
milestones that were submitted to the FCC in the [Navigation
Devices]{.underline} proceeding, it must be remembered that those
milestones were established in the context of a [September]{.underline}
2000 date for the availability of digital POD modules, not the
accelerated [July]{.underline} 2000 date ultimately established by the
FCC. While the cable industry intends and expects to have digital POD
modules available by July 2000, it will take the continued efforts of
OpenCable staff, CableLabs personnel, cable operators, and particularly
cable equipment manufacturers, to make that FCC deadline a reality.
Indeed, while the FCC rules will hold cable operators accountable if
digital POD modules are not available by July 1, 2000, those operators
must rely upon the efforts of cable equipment manufacturers and others
to provide those modules to them by July 1, 2000.

# ANALOG SEPARATION SPECIFICATIONS

In addition to requiring the separation of security from non-security
functions in [digital]{.underline} navigation devices, the Commission,
over the objection of the cable industry and others, 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. On reconsideration,
the Commission ruled that the separate security requirement would not
apply to operators who deployed analog-only set-top boxes, but 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.

Because the OpenCable project had not addressed the separation of analog
security functions or perhaps because of the practical, technical and
legal complications associated with achieving such a result, no interim
milestones were included in the [Report and Order]{.underline} regarding
the development of specifications for an analog security module to
unscramble analog programming. As the Commission was aware when it
adopted the [Report and Order]{.underline}, the OpenCable effort had
been focused on [digital]{.underline} set-top boxes, consistent with the
Commission goal to foster migration from analog to digital services.

As discussed in our July 1999 Status Report, CableLabs has concluded
that the only potentially feasible approach to separating analog
security and non-security functions in hybrid boxes is 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.

We observed in our July 1999 report that there will be a negligible
market -- if that -- for hybrid set-top boxes sold at retail or for
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 his analog scrambled programming on his digital
tier(s).

A significant number of cable operators who have deployed hybrid boxes
intend to provide just such \"duplicated analog\" programming and
therefore will not need to use the analog descrambling function of the
hybrid box. In such circumstances, if a cable operator has sufficient
capacity to duplicate its scrambled analog programming on a digital
tier, subscribers who have a digital set-top box will not need a hybrid
set-top box with analog descrambling capabilities 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 to have
available analog POD modules in case a subscriber obtained a hybrid box
at retail -- is where an operator does not duplicate his scrambled
analog programming on a digital tier and where subscribers take both
digital services and scrambled analog services. Since this is expected
to be a very small market segment, 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. As we said in our July 1999 report, it is indeed arguable that
this market segment by itself cannot justify the non-recurring
engineering costs to design a hybrid digital/analog set-top box to
accommodate a separate analog security POD module.

As described in our last report, CableLabs has been working to develop a
means to satisfy the FCC\'s analog separation requirement. It determined
that the only potentially feasible approach for accomplishing this is to
use the existing EIA-105 Decoder Interface Standard as a basis for an
optional OpenCable specification, which was accomplished with the
publishing of the optional specification in December 1999. To comply
with the FCC's requirements, OpenCable has published optional
specifications for an analog interface based on the EIA 105.1 (Decoder
Interface) standard. That specification -- IS-APOD-WD1-991208 -- is
available on the OpenCable website.[^7] Now manufacturers who are asked
to build "hybrid" set-top boxes with an interface for an analog POD and
manufacturers who are asked to build analog POD modules may do so if
demand is sufficient to build such uneconomic devices.

However, as stated in our July 7, 1999, [Status Report]{.underline}
(incorporated by reference herein),[^8] even with its adoption as an
optional OpenCable standard, the Decoder Interface requires additional
work before commercial production is possible. That work includes
construction and testing of a prototype as well as interoperability
testing as was done with the digital POD modules. CableLabs stands ready
to assist any vendors who request assistance with design or
interoperability testing for such devices. Nevertheless, even under the
best of scenarios, based on what we know today, analog POD modules will
not be available for cable operators to provide to subscribers by July
1, 2000.

In this regard, 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 appeal of the FCC's [Navigation Devices]{.underline}
Orders, the Commission addressed the argument that applying the July 1,
2000, deadline to [analog]{.underline} security POD modules was
arbitrary since that date was based upon an industry-supplied deadline
for [digital]{.underline} security 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.[^9]

# 

# CONCLUSION

The CableLabs effort is on track in providing information manufacturers
need to build digital POD modules by the July 1, 2000, FCC deadline. The
milestones submitted to the FCC addressed only the [digital]{.underline}
POD module and host interface, and were keyed to a September 2000 date
for the availability of digital POD modules. Nevertheless, manufacturers
of retailer-supplied boxes now have all of the "build-to" specifications
they need to build a first generation, OpenCable-compliant host
interface (set-top box). And manufacturers of cable operator-supplied
POD modules also have virtually all of the information they need to
build the OpenCable-compliant digital POD module.

The [analog]{.underline} POD module is a different story. Despite
publication of an optional OpenCable analog specification, because of
the construction and testing which still needs to be

done, it does not appear that manufacturers can have analog POD modules
available to operators by July 2000. CableLabs and cable operators will
continue to examine alternative means of achieving the goals of
commercial availability in situations where operators provide to their
customers hybrid boxes which are used to descramble analog programming
and where retailers wish to offer hybrid boxes.

We will keep the Commission appraised of the progress of the industry's
efforts on these issues in the coming months as the July, 2000 deadline
approaches.

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

January 7, 2000 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).

[^2]: [See]{.underline} NCTA Petition for Expedited Reconsideration in
    CS Docket No. 97-80, filed August 14, 1998, at n.37; Letter from
    Neal M. Goldberg, NCTA General Counsel, to William F. Johnson,
    Deputy Chief, Cable Services Bureau, FCC, in CS Docket No. 97-80,
    June 3, 1998, at 2. ("The attached timetable applies only to the
    [digital]{.underline} security module and [digital]{.underline} host
    box interface -- it does not apply to analog security modules and
    interfaces for an analog or hybrid box. The applicability of a
    commercial availability rule to an analog or hybrid box may well, at
    a minimum, result in further delays in the attached timetable, and,
    in any event, creates a myriad of practical implementation
    problems.")(emphasis in original).

[^3]: [Report and Order]{.underline} at para. 77.

[^4]: [Id]{.underline}. at paras. 81, 139.

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

[^6]: There are some minor unresolved issues, such as how much power
    will be required by the POD module for it to operate properly and
    how much heat the POD module will generate. These issues are being
    resolved through an Engineering Change Request/Engineering Change
    Order Process that has been used successfully by cable companies and
    manufacturers participating in the DOCSIS cable modem program.

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

[^8]: [Status Report]{.underline}, filed in CS Docket No. 97-80, July 7,
    1999.

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