ATTACHMENT A Access to Basic Interactive Services: Technical Requirements This document explains the technology by which cable providers could allow competitive devices to access “basic” interactive services (i.e., switched digital (“SD”), video on demand (“VOD”), and impulse pay per view (“IPPV”) content) without requiring that such devices include the OpenCable Application Platform (“OCAP”) middleware. It also describes the technology by which the proprietary metadata or navigation data, delivered by the cable provider in conjunction with its video content, could be translated into a common format that could be understood and used by the competitive device. We propose that the method described herein be implemented for all current separable security technologies prescribed by FCC regulations and any subsequent replacement technologies. 1 In addition, to ensure the consumer benefits of common reliance, cable providers should be required to use this same schema and interface in a substantial proportion of any devices they lease or otherwise provide to subscribers. UDCR Preservation At the outset, we wish to make clear that this proposal encompasses, and does not supersede or replace, the technical requirements currently in place in the Commission’s rules that allow competitive devices to access unidirectional cable services. Accordingly, we propose that the Commission clarify that Section 76.640 of the Commission’s rules requires that: 1. Cable operators shall support Unidirectional Digital Cable Receiver (“UDCR”) and Open Cable Unidirectional Receiver (“OCUR") (together, “Unidirectional Devices”), by maintaining access to all linear broadcast digital cable audio/video content and services in parity with the availability of those same services on leased devices. 2. Cable providers shall not, by contract, agreement, patent right, intellectual property right or otherwise, prevent Unidirectional Devices compliant with both Section 76.1203 (incidence of harm) and Section 76.1209 (theft of service) of the Commission’s Rules from accessing the same linear broadcast digital cable audio/video content offering available to subscribers having cable provider leased devices. 1 The technologies described in this document could be implemented in either hardware or software. Accordingly, references herein to “conditional access technologies” should be read to include either a future, modified version of the soon-be-released multistream (MS) CableCARD, or some future software-based approach. 1 UDCR Evolution Further, we wish to stress that the technological changes necessary to allow Unidirectional Devices to allow consumers access to basic interactive services are evolutionary, and not revolutionary, in nature. This approach requires no changes to the interface between the cable provider distribution network and its client-side conditional access technology. It does require additions to the currently implemented interface between the conditional access technology and the host device. The conditional access technology itself would handle translation between the network-side interface and the host-side interface. Accordingly, we propose that the Commission amend its rules to provide that: 1. Manufacturers of Unidirectional Devices are permitted to create new navigation devices that, while remaining compliant with both Section 76.1203 and Section 76.1209, have upstream transmission capability. This upstream transmission capability would permit limited interaction with the cable provider distribution network to allow the host device to provide access to SD, VOD, and IPPV content. Interaction with the cable network would occur via either hardware- or software-based conditional access. Interaction between the conditional access implementation and the host device would occur through published application programming interfaces (APIs) adopted and issued through an ANSI-accredited standards body and approved by the Commission. 2. Cable providers are prohibited from, by contract, agreement, patent right, intellectual property right or otherwise, imposing a requirement that a manufacturer implement in any hardware or software specific to any one particular network vendor. If network-specific hardware or software is necessary for attachment, navigation and reception of digital audio/video programming, it should be incorporated and confined within the cable provider conditional access technology. Dynamic Content Support – Overview Delivery of SD and VOD content requires dynamic allocation of network bandwidth to content based on user requests. Therefore a common underlying protocol is possible, based on a user request being relayed to the conditional access technology, and a corresponding response from the conditional access technology indicating the status of the request and information on how to tune to the requested service. The existing SCTE 28 interface specification and SCTE 65 channel map specification can be used to enable these different services. Switched Digital Video Support 1. Indication of SD services in tuning tables Linear broadcast digital cable audio/video content delivered using switched broadcast technology shall be distinguished in the virtual channel map structures received by the host device as specified in the SCTE 65 standard. The indication of switched broadcast carriage shall be by marking such services as channel_type 2. 2 2. Host device request for SD content A host device shall indicate to the cable provider the subscriber’s intent to access content marked as being distributed through SD technology by use of the syntax for IPPV access provided in the SCTE-28 standard, program_req() API call. SD channels are accessed by first issuing a program_req() with suitable parameters (e.g. channel number and transaction id) to establish a session with the cable provider headend. The program_req() shall be processed by the conditional access technology and transmitted as so processed to the cable headend using a format of the cable provider’s choosing. Similarly, the cable provider headend may generate a response and send it the conditional access technology in any proprietary format. If the request is granted, a session is established, and channel information needed to tune to the SD channel in question is returned in a program_cnf() APDU structure from the conditional access technology to the host device. This channel information includes frequency, transport id and program number. During the processing of the program_req(), if needed, a frequency may be assigned to an SD channel. The status field of the program_cnf() contains data indicating request grant (0x00) or deny (0x02). The channel information returned in the program_cnf() would be generated inside the conditional access technology from the cable provider’s proprietary out of band communications data. If access is denied, the host device can suitably inform the subscriber through on-screen display or other means that the desired service is not available. SD uses the Generic IPPV Support resource to support communication with programs in the conditional access technology that implement protocols with the headend. VOD makes similar use of the Generic IPPV Support resource. Depending upon the service accessed, the program_req() and program_cnf() APDUs may have different parameters. 3. Determination of continued service use Once a host device has requested and received access to SD-delivered video/audio content, such connectivity shall be preserved by the cable provider until the device tunes away or until the cable provider determines that there has been no subscriber activity for a certain period of time. The existing SCTE-28 cancel_req() APDU with suitable parameters (e.g. channel number and transaction id) can be used for this function. If there are no other host devices on a given network node accessing that particular SD channel, the headend may deallocate the frequency associated with the channel making the frequency available for other channel assignments. The conditional access technology may report to the headend that the SD content is no longer being accessed by the device. The format and means for reporting this status to the headend shall left to the discretion of the cable provider but shall be consistent with other headend communications methods already implemented. Either the host device can indicate to the conditional access technology that it no longer needs access to the SD content, or the conditional access technology can poll the device for this information. 3 The industry bodies representing the cable providers and consumer electronics shall meet and jointly develop extensions to the SCTE-28 protocol specification for submission and consideration by the SCTE. These extensions shall implement new APIs to allow for the detection of subscriber interaction with the host device indicating active use of the device and will consist of indicating whether any remote control key press has occurred since the last polling period. There shall also be provisions made to indicate whether there is an active recording session, which shall be considered equivalent to subscriber intervention with the device, since such recording is a proxy interaction with the network on the subscriber’s behalf. SD Tuning Procedure Review 1. A channel map is sent to the Host device with some channels indicated as part of the SD service via channel_type = 2 2. The consumer makes a channel change request. 3. The Host finds the channel in the channel map and determines that it is a type 2 entry – an SD channel. 4. A program_req() APDU with suitable parameters (e.g. channel number and transaction id) is formatted and sent to the CableCARD to open an SD session. 5. The CableCARD uses a protocol of the cable provider’s choosing to the network to determine the current channel allocation. 6. The CableCARD sends a program_cnf() APDU with suitable parameters (e.g. channel number and transaction id) to the host device. Contained in the program_cnf() is channel map information including frequency,transport id and program number, allowing the host device to tune and receive the requested channel. 7. The host device tunes to the channel and obtains the PMT associated with the desired program. 8. The host device embeds the PMT in a ca_pmt() and sends the APDU to the conditional access technology. 9. The host device sends a cancel_req() APDU with suitable parameters (e.g. channel number and transaction id) to the conditional access technology when it has determined that the user no longer needs the channel. This information can then be conveyed to the network to close the SD session. IPPV Support 1. IPPV Support as defined in SCTE 28 Cable providers will implement the Generic IPPV Support resource defined in SCTE 28. Conditional access technologies on systems where the cable provider offers IPPV service will make this resource available to Host devices. The host device will create user interface screens for purchase, confirmation, and canceling of IPPV events 4 2. IPPV PIN reset Conditional access technologies and host devices will support the Generic Feature Support resource as defined in SCTE 28, in particular the IPPV purchase PIN and IPPV PIN reset functions. The latter allows the cable provider to reset the PIN for IPPV purchases if the subscriber has forgotten their PIN. VOD Support 1. VOD Support SCTE 28 states that “Video-on-Demand (VOD) may be modeled as an IPPV event where the program stream is dedicated to an individual subscriber. The VOD application executes in the Host and supports all of the User Interface (UI) functions.” cable providers will make VOD content available to host devices via existing standards (SCTE 28 and other), and without requiring that the host device include OCAP. 2. Browsing VOD titles In systems with VOD service, the conditional access technology will provide the host device a URL (uniform resource locator) pointing to the top of the directory tree of the VOD title list. The conditional access technology and host devices will support the Generic Feature Support resource as defined in SCTE 28, which already defines how the VOD URL parameter is delivered to the host device. The URL will present a folder-based hierarchy of VOD titles currently offered to the subscriber by the cable provider. The top level of the directory tree will contain a list of folders. The client can navigate the list and request the contents of a folder. Each folder can contain additional folders, or a list of assets. Each asset is a VOD program and associated metadata describing the program. HTTP shall be used to navigate the folder structure starting at the top-level URL in a request-response fashion. The folder hierarchy shall be delivered in XML format. The conditional access technology must support an IP flow for the host device to access the VOD navigation information. The host device will present the folder hierarchy to the viewer as delivered by the cable provider. The host device will not modify or delete VOD folder information, unless that content is blocked by the user’s assertion of parental controls. 3. Title descriptions as defined in CableLabs VOD metadata Programs will be described using the CableLabs Video On-Demand Content Specification version 2.0, Title Asset data structure. This structure must contain the mandatory fields as well as Rating Information for parental controls. Each program must also have an associated Terms Asset, modified from the CableLabs specification to a format suitable for consumers. A program may have an associated Preview Asset and Poster Asset. An associated Chapter List Asset is optional. 5 4. Purchasing VOD titles Purchasing VOD assets for viewing will use the Generic IPPV Support resource defined in SCTE 28. On systems where the cable provider offers IPPV service, the conditional access technology will make this resource available to host devices. 5. Session Setup and Management VOD session setup and management shall be handled by the conditional access technology as directed by the host device. Proprietary methods for session creation, management and teardown need not be exposed to the host device. Once a VOD asset has been selected, the host will use the Generic IPPV resource program_req() APDU to indicate the intent to purchase (or view if free) the asset. Session creation and teardown is similar to the solution for access to SD content support The program_cnf() APDU will return channel information including the QAM frequency, transport stream id and program number to tune to the session. . The program_req() and program_cnf() APDUs shall be used to create a VOD session. The cancel_req() APDU will be used to indicate that viewing is complete or has been cancelled. The conditional access can use this information to indicate to the cable provider headend the VOD session resources can be freed. Alternatively, the Host device can manage sessions using the Session Setup Protocol (SSP) as defined by Time Warner Cable in its Pegasus project. 6. Stream Control Stream control may be based on the Lightweight Stream Control Protocol (LSC) version as defined by Time Warner Cable in its Pegasus project. The specific communication protocol used for stream control within the cable provider network shall be abstracted at the conditional access technology interface. A series of common VOD stream control APDUs shall be defined for trickplay (play, fast-forward, rewind, pause) functions. These APDUs will be translated into the protocol used within the cable provider network by the conditional access technology. EPG Support 1. SCTE 65 Profile 4 Cable providers must provide sufficient program data information for host devices to be able to provide a basic program guide with title information on current and upcoming programs. Program information as defined in SCTE 65 Profile 4 will be delivered as defined in SCTE 28 from the conditional access technology to the host device. Profile 4 data shall include at least as many Aggregate Event Information Tables (AEIT) as necessary to cover a 24 hour period. 6