This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 028 HOST-POD Interface Standard (2007).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ENGINEERING COMMITTEE Digital Video Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 28 2007 HOST-POD Interface Standard NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or nonmember of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE assumes no obligations or liability whatsoever to any party who may adopt the Standards. Such adopting party assumes all risks associated with adoption of these Standards or Recommended Practices, and accepts full responsibility for any damage and/or claims arising from the adoption of such Standards or Recommended Practices. Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquires into the legal validity or scope of those patents that are brought to its attention. Patent holders who believe that they hold patents which are essential to the implementation of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 140 Philips Road Exton, PA 19341 Table of Contents 1 Scope ...................................................................................................................................................... 1 2 Overview of HOST-POD Interface ........................................................................................................ 2 2.1 Historical Perspective (INFORMATIVE) ..................................................................................... 2 2.2 Advanced Cable Services (INFORMATIVE) ............................................................................... 2 2.2.1 Interactive Program Guide (IPG)............................................................................................ 2 2.2.2 Impulse Pay-Per-View (IPPV)................................................................................................ 3 2.2.3 Video-on-Demand (VOD) ...................................................................................................... 3 2.2.4 Interactive services ................................................................................................................. 3 2.3 References ...................................................................................................................................... 4 2.3.1 Normative references.............................................................................................................. 4 2.3.2 Informative references ............................................................................................................ 6 3 CEA 679 Part B Compliance.................................................................................................................. 7 3.1 Exceptions to Compliance .............................................................................................................. 7 4 System Architecture (INFORMATIVE) .............................................................................................. 13 4.1 Introduction .................................................................................................................................. 13 4.2 Two-way Networks ...................................................................................................................... 14 4.3 One-way Networks ....................................................................................................................... 15 4.4 Two-way Networks with DOCSIS ............................................................................................... 17 5 Extended channel data flows ................................................................................................................ 18 5.1 Internet Protocol Flows (Informative) .......................................................................................... 18 5.2 Flow Examples—QPSK Modem Case (Informative)................................................................... 19 5.3 Flow Examples— High Speed Host Modem Case DSG Mode.................................................... 20 5.4 Summary of Extended Channel Flow Requirement (Normative)............................................... 22 5.5 System/Service Information Requirements (Normative).............................................................. 22 5.6 Emergency Alert Requirements (Normative) ............................................................................... 22 6 Physical Interface (NORMATIVE)...................................................................................................... 23 6.1 PC Card Compliance .................................................................................................................... 23 6.1.1 POD Module Port Custom Interface (0341h) ....................................................................... 23 6.1.2 Power Management .............................................................................................................. 23 6.1.3 Pin Assignment..................................................................................................................... 24 6.2 POD Module Identification .......................................................................................................... 27 6.3 Card Information Structure........................................................................................................... 27 6.4 Host-POD OOB Interface............................................................................................................. 28 6.4.1 Out of Band (OOB) Mode .................................................................................................... 28 6.4.2 DOCSIS Settop Gateway (DSG Mode ................................................................................. 30 6.4.3 Timing and Voltage Parameters ........................................................................................... 31 6.5 CPU Interface ............................................................................................................................... 33 6.5.1 Control Register Modification .............................................................................................. 35 6.5.2 Status Register Modification ................................................................................................ 36 6.6 Copy Protection on the FAT Channel........................................................................................... 36 6.7 Host-POD Interface Initialization................................................................................................. 36 6.7.1 Descriptions .......................................................................................................................... 36 6.7.2 Configuration Option Register (Normative)......................................................................... 40 6.7.3 Initialization Conditions ....................................................................................................... 40 6.7.4 OOB Connection and Disconnection Behavior .................................................................... 40 6.7.5 Low Level Step by Step POD Personality Change Sequence............................................... 41 6.7.6 Initialization Overview ......................................................................................................... 43 6.7.7 Interrupt Operation ............................................................................................................... 49 6.8 Mechanical Design ....................................................................................................................... 50 7 Link Interface (NORMATIVE)............................................................................................................ 50 7.1 Data Channel ................................................................................................................................ 50 7.2 Extended Channel......................................................................................................................... 50 7.2.1 Maximum PDUs ................................................................................................................... 51 i 8 Application Interface (NORMATIVE)................................................................................................. 52 8.1 Scope Introduction........................................................................................................................ 52 8.2 Resource Manager ........................................................................................................................ 54 8.3 Man Machine Interface................................................................................................................. 54 8.3.1 Introduction .......................................................................................................................... 54 8.3.2 Open_mmi_req() & Open_mmi_cnf().................................................................................. 55 8.3.3 Close_mmi_req() & Close_mmi_cnf() ................................................................................. 57 8.4 Application Information ............................................................................................................... 58 8.4.1 Introduction .......................................................................................................................... 58 8.4.2 Application_info_req() & Application_info_cnf() ............................................................... 59 8.4.3 Server_Query() & Server_Reply()........................................................................................ 66 8.5 Low Speed Communication ()...................................................................................................... 70 8.6 Conditional Access ....................................................................................................................... 71 8.6.1 CA_update() ......................................................................................................................... 71 8.7 Copy Protection ............................................................................................................................ 74 8.8 Host Control ................................................................................................................................. 74 8.8.1 OOB_TX_tune_req() & OOB_TX_tune_cnf()..................................................................... 74 8.8.2 OOB_RX_tune_req() & OOB_RX_tune_cnf() .................................................................... 74 8.8.3 inband_tune_req() (Normative) ............................................................................................ 74 8.8.4 inband_tuning_cnf (Normative) ........................................................................................... 74 8.9 Extended Channel Support ........................................................................................................... 74 8.9.1 New_flow_req() & New_flow_cnf() .................................................................................... 74 8.9.2 Delete_flow_req() & Delete_flow_cnf() .............................................................................. 74 8.9.3 Lost_flow_ind() & Lost_flow_cnf()..................................................................................... 74 8.9.4 inquire_DSG_mode(), set_DSG_mode(), & DSG_packet_error() ....................................... 74 8.10 Generic IPPV Support .................................................................................................................. 74 8.10.1 Program_req() & Program_cnf() .......................................................................................... 74 8.10.2 Purchase_req() & Purchase_cnf()......................................................................................... 74 8.10.3 Cancel_req() & Cancel_cnf() ............................................................................................... 74 8.10.4 History_req() & History_cnf().............................................................................................. 74 8.11 Specific Application Support........................................................................................................ 74 8.11.1 Specific Application Support Connectivity .......................................................................... 74 8.11.2 Resource Identifier ............................................................................................................... 74 8.11.3 Application Objects .............................................................................................................. 74 8.12 Generic Feature Control Support.................................................................................................. 74 8.12.1 Parameter Storage................................................................................................................. 74 8.12.2 Parameter Operation ............................................................................................................. 74 8.12.3 Host to POD Module Transfer.............................................................................................. 74 8.12.4 Resource Identifier ............................................................................................................... 74 8.12.5 Feature ID............................................................................................................................. 74 8.12.6 Application Objects .............................................................................................................. 74 8.12.7 Feature Parameter Definition................................................................................................ 74 8.13 POD Module Firmware Upgrade.................................................................................................. 74 8.13.1 Introduction (Informative) .................................................................................................... 74 8.13.2 Implementation..................................................................................................................... 74 8.13.3 Homing Resource (Normative)............................................................................................. 74 8.14 Generic Diagnostic Support.......................................................................................................... 74 8.14.1 Diagnostic_req() ................................................................................................................... 74 8.14.2 Diagnostic_cnf() ................................................................................................................... 74 8.14.3 Diagnostic Report Definition................................................................................................ 74 8.15 Support for Common Download Specification............................................................................. 74 8.15.1 Overview of Protocol (Informative) ..................................................................................... 74 8.15.2 OPERATIONAL DETAILS (Informative) .......................................................................... 74 8.15.3 System Control Resource (Normative)................................................................................. 74 APPENDIX A. Operational Modes (Informative) ................................................................................. 74 A.1. Data Path Options......................................................................................................................... 74 ii A.2. OOB TX Channel Available......................................................................................................... 74 A.3. High Speed Modem Available...................................................................................................... 74 A.3.1. OOB TX Channel Available................................................................................................. 74 A.3.2. OOB TX Channel Not Available.......................................................................................... 74 APPENDIX B. Glossary ........................................................................................................................ 74 APPENDIX C. Baseline HTML Profile Requirements ......................................................................... 74 C.1. Format .......................................................................................................................................... 74 C.1.1. Display.................................................................................................................................. 74 C.1.2. Font....................................................................................................................................... 74 C.1.3. Text and Background Colors ................................................................................................ 74 C.1.4. Unvisited Link Color ............................................................................................................ 74 C.1.5. Paragraph.............................................................................................................................. 74 C.1.6. Image .................................................................................................................................... 74 C.1.7. Table ..................................................................................................................................... 74 C.1.8. Forms.................................................................................................................................... 74 C.2. Supported User Interactions ......................................................................................................... 74 C.2.1. Navigation and Links............................................................................................................ 74 C.3. HTML Keywords ......................................................................................................................... 74 C.4. Characters ..................................................................................................................................... 74 APPENDIX D. POD Module Attribute and Configuration Registers.................................................... 74 D.1. General ......................................................................................................................................... 74 D.2. Attribute Tuples............................................................................................................................ 74 D.2.1. CISTPL_LINKTARGET...................................................................................................... 74 D.2.2. CISTPL_DEVICE_0A ......................................................................................................... 74 D.2.3. CISTPL_DEVICE_0C.......................................................................................................... 74 D.2.4. CISTPL_VERS_1................................................................................................................. 74 D.2.5. CISTPL_CONFIG ................................................................................................................ 74 D.2.6. CCST_CIF............................................................................................................................ 74 D.2.7. CISTPL_CFTABLE_ENTRY.............................................................................................. 74 D.2.8. CISTPL_END....................................................................................................................... 74 D.2.9. Configuration Option Register ............................................................................................. 74 APPENDIX E. POD Error Handling ..................................................................................................... 74 E.1. Error Handling.............................................................................................................................. 74 iii List of Tables Table 3.1-A CEA 679 Part B Compliance Exceptions ................................................................................... 7 Table 3.1-B Replacement for CEA-679-C Table 87 Resource Identifier Values......................................... 11 Table 3.1-C Replacement for CEA-679-C Table 91 Application Object Tag Values.................................. 11 Table 6.1-A PC Card Signal Definitions ...................................................................................................... 26 Table 6.3-A CIS Minimum Set of Tuples .................................................................................................... 28 Table 6.4-A Transmission Signals for Host-POD Interface ......................................................................... 29 Table 6.5-A Extended Interface Registers.................................................................................................... 34 Table 6.7-A Create Transport Connection.................................................................................................... 44 Table 6.7-B Create Transport Connection Reply ......................................................................................... 45 Table 6.7-C Open Session Request .............................................................................................................. 45 Table 6.7-D Open Session Response............................................................................................................ 45 Table 6.7-E Profile Inquiry........................................................................................................................... 46 Table 6.7-F Profile Reply ............................................................................................................................. 46 Table 6.7-G Profile Changed........................................................................................................................ 47 Table 6.7-H Profile Inquiry .......................................................................................................................... 47 Table 6.7-I Profile Reply.............................................................................................................................. 47 Table 7.2-A Extended Channel Link Layer Packet ...................................................................................... 51 Table 8.1-A Host-POD Interface Resources ................................................................................................ 52 Table 8.1-B Host-POD Interface Resource Loading .................................................................................... 53 Table 8.3-A Man Machine Interface Resource............................................................................................. 55 Table 8.3-B Man Machine Interface Objects ............................................................................................... 55 Table 8.3-C Open MMI Request Object Syntax........................................................................................... 56 Table 8.3-D Open MMI Confirm Object Syntax.......................................................................................... 56 Table 8.3-E Open Status Values................................................................................................................... 57 Table 8.3-F Close MMI Request Object Syntax........................................................................................... 57 Table 8.3-G Close MMI Confirm Object Syntax ......................................................................................... 58 Table 8.4-A Application Information Resource ........................................................................................... 58 Table 8.4-B Table Application Information Objects .................................................................................... 59 Table 8.4-C Application Information Request Object Syntax...................................................................... 60 Table 8.4-D Data Entry Support Values....................................................................................................... 61 Table 8.4-E HTML Support Values ............................................................................................................. 61 Table 8.4-F Link Support Values ................................................................................................................. 62 Table 8.4-G Form Support Values ............................................................................................................... 62 Table 8.4-H Table Support Values ............................................................................................................... 63 Table 8.4-I List Support Values ................................................................................................................... 63 Table 8.4-J Image Support Values ............................................................................................................... 63 Table 8.4-K Application Information Confirm Object Syntax ..................................................................... 64 Table 8.4-L Pod Manufacturer ID Values .................................................................................................... 65 Table 8.4-M Application Type Values ......................................................................................................... 65 Table 8.4-N Server Query Object Syntax..................................................................................................... 67 Table 8.4-O Server Reply Object Syntax ..................................................................................................... 68 Table 8.4-P File Status Values ..................................................................................................................... 69 Table 8.5-A Low Speed Communication Resource ..................................................................................... 70 Table 8.6-A Conditional Access Support Resource ..................................................................................... 71 Table 8.6-B Conditional Access Support Objects ........................................................................................ 71 Table 8.6-C Conditional Access Support CA_update Object Syntax........................................................... 72 Table 8.6-D CA Enable Field Values ........................................................................................................... 73 Table 8.8-A Host Control Resource ............................................................................................................. 74 Table 8.8-B Host Control Objects ................................................................................................................ 74 Table 8.8-C OOB TX Tune Request Object Syntax..................................................................................... 74 Table 8.8-D RF TX Frequency Value .......................................................................................................... 74 Table 8.8-E RF TX Power Level.................................................................................................................. 74 Table 8.8-F RF TX Rate Value .................................................................................................................... 74 iv Table 8.8-G OOB TX Tune Confirm Object Syntax.................................................................................... 74 Table 8.8-H Status Field Values for OOB TX Tune Confirm ...................................................................... 74 Table 8.8-I OOB RX Tune Request Object Syntax...................................................................................... 74 Table 8.8-J RF RX Frequency Value ........................................................................................................... 74 Table 8.8-K RF RX Data Rate...................................................................................................................... 74 Table 8.8-L OOB RX Tune Confirm Object Syntax .................................................................................... 74 Table 8.8-M Status Field Values for OOB RX Tune Confirm ..................................................................... 74 Table 8.8-N Inband Tune Request Object Syntax ........................................................................................ 74 Table 8.8-O Tune Type Values .................................................................................................................... 74 Table 8.8-P Tune Value................................................................................................................................ 74 Table 8.8-Q Modulation Value..................................................................................................................... 74 Table 8.8-R Inband Tuning Confirm Object Syntax .................................................................................... 74 Table 8.8-S Tune Status Values ................................................................................................................... 74 Table 8.9-A Extended Channel Resource..................................................................................................... 74 Table 8.9-B Extended Channel Objects........................................................................................................ 74 Table 8.9-C New Flow Request Object Syntax............................................................................................ 74 Table 8.9-D Service Type Values for New Flow Request............................................................................ 74 Table 8.9-E New Flow Confirm Object Syntax ........................................................................................... 74 Table 8.9-F Status Field Values for New Flow Confirm.............................................................................. 74 Table 8.9-G Flag field definitions ............................................................................................................... 74 Table 8.9-H POD Module DHCP Vendor Specific Information (Option 43) Sub-option Encoding........... 74 Table 8.9-I POD Module DHCP Vendor Class Indentifier (Option 60) Encoding ..................................... 74 Table 8.9-J Delete Flow Request Object Syntax .......................................................................................... 74 Table 8.9-K Delete Flow Confirm Object Syntax ........................................................................................ 74 Table 8.9-L Status Field for Delete Flow ..................................................................................................... 74 Table 8.9-M Lost Flow Indication Object Syntax ........................................................................................ 74 Table 8.9-N Reason Field Values for Lost Flow Indication......................................................................... 74 Table 8.9-O Lost Flow Confirm Object Syntax ........................................................................................... 74 Table 8.9-P Status Field Values for Lost Flow Confirm .............................................................................. 74 Table 8.9-Q Inquire DSG Mode Object Syntax ........................................................................................... 74 Table 8.9-R Set DSG Mode Object Syntax .................................................................................................. 74 Table 8.9-S DSG packet_error Object Syntax.............................................................................................. 74 Table 8.10-A Generic IPPV Support Resources........................................................................................... 74 Table 8.10-B Generic IPPV Support Objects ............................................................................................... 74 Table 8.10-C Program Request Object Syntax............................................................................................. 74 Table 8.10-D Program Confirm Object Syntax ............................................................................................ 74 Table 8.10-E Status Field Values for Program Confirm............................................................................... 74 Table 8.10-F Purchase Type Values for Program Confirm .......................................................................... 74 Table 8.10-G Purchase Price for Program Confirm ..................................................................................... 74 Table 8.10-H Purchase Validation Value for Program Confirm .................................................................. 74 Table 8.10-I Purchase Request Object Syntax.............................................................................................. 74 Table 8.10-J Purchase Confirm Object Syntax............................................................................................. 74 Table 8.10-K Status Field Values for Purchase Confirm ............................................................................. 74 Table 8.10-L Status Register for Purchase Confirm..................................................................................... 74 Table 8.10-M Cancel Request Object Syntax............................................................................................... 74 Table 8.10-N Cancel Confirm Object Syntax............................................................................................... 74 Table 8.10-O Status Field Values for Cancel Confirm................................................................................. 74 Table 8.10-P History Request Object Syntax ............................................................................................... 74 Table 8.10-Q History Confirm Object Syntax.............................................................................................. 74 Table 8.10-R Status Field Values for History Confirm ................................................................................ 74 Table 8.11-A Specific Application Support Resource.................................................................................. 74 Table 8.11-B Specific Application Support Objects .................................................................................... 74 Table 8.11-C sas_connect_rqst Object Syntax ............................................................................................. 74 Table 8.11-D sas_connect_cnf Object Syntax.............................................................................................. 74 Table 8.11-E sas_session_status................................................................................................................... 74 Table 8.11-F sas_data_rqst Object Syntax ................................................................................................... 74 v Table 8.11-G sas_data_av Object Syntax..................................................................................................... 74 Table 8.11-H sas_data_cnf Object Syntax.................................................................................................... 74 Table 8.11-I sas_data_status......................................................................................................................... 74 Table 8.11-J sas_server_query Object Syntax.............................................................................................. 74 Table 8.11-K sas_server_reply Object Syntax ............................................................................................. 74 Table 8.12-A Generic Feature Control Resource ......................................................................................... 74 Table 8.12-B Generic Feature IDs................................................................................................................ 74 Table 8.12-C Generic Feature Control Objects ............................................................................................ 74 Table 8.12-D Feature List Request Object Syntax ....................................................................................... 74 Table 8.12-E Feature List Object Syntax ..................................................................................................... 74 Table 8.12-F Feature List Confirm Object Syntax ....................................................................................... 74 Table 8.12-G Feature List Changed Object Syntax...................................................................................... 74 Table 8.12-H Feature Parameter Request Object Syntax ............................................................................. 74 Table 8.12-I Feature Parameters Object Syntax ........................................................................................... 74 Table 8.12-J Feature Parameters Confirm Object Syntax ............................................................................ 74 Table 8.12-K RF Output Channel Parameters Syntax .................................................................................. 74 Table 8.12-L Parental Control PIN Parameters ............................................................................................ 74 Table 8.12-M Parental Control Settings Parameters ................................................................................... 74 Table 8.12-N IPPV PIN Parameters ............................................................................................................. 74 Table 8.12-O Time Zone Parameters............................................................................................................ 74 Table 8.12-P Daylight Savings Parameters .................................................................................................. 74 Table 8.12-Q AC Outlet Parameters............................................................................................................. 74 Table 8.12-R Language Parameters.............................................................................................................. 74 Table 8.12-S Rating Region Parameters....................................................................................................... 74 Table 8.12-T Reset PIN................................................................................................................................ 74 Table 8.12-U Cable URLs............................................................................................................................ 74 Table 8.12-V Emergency Alert Location Code ............................................................................................ 74 Table 8.13-A Homing Resource................................................................................................................... 74 Table 8.13-B Homing Objects...................................................................................................................... 74 Table 8.13-C Open Homing Object Syntax.................................................................................................. 74 Table 8.13-D Open Homing Reply Object Syntax ....................................................................................... 74 Table 8.13-E Homing Active Object Syntax ................................................................................................ 74 Table 8.13-F Homing Cancelled Object Syntax........................................................................................... 74 Table 8.13-G Homing Complete Object Syntax........................................................................................... 74 Table 8.13-H Firmware Upgrade Object Syntax .......................................................................................... 74 Table 8.13-I Upgrade Sources ...................................................................................................................... 74 Table 8.13-J Timeout Types......................................................................................................................... 74 Table 8.13-K Firmware Upgrade Reply Object Syntax................................................................................ 74 Table 8.13-L Firmware Upgrade Complete Object Syntax .......................................................................... 74 Table 8.13-M Reset Request Status Values.................................................................................................. 74 Table 8.14-A Generic Diagnostic Support Resource.................................................................................... 74 Table 8.14-B Generic Diagnostic Support Objects ...................................................................................... 74 Table 8.14-C Diagnostic Request Object Syntax ......................................................................................... 74 Table 8.14-D Diagnostic ID Values ............................................................................................................. 74 Table 8.14-E Diagnostic Confirm Object Syntax......................................................................................... 74 Table 8.14-F Status Field Values ................................................................................................................. 74 Table 8.14-G Memory Report Syntax .......................................................................................................... 74 Table 8.14-H Memory Type Values............................................................................................................. 74 Table 8.14-I Software Version Report Syntax.............................................................................................. 74 Table 8.14-J Software Status Flag Values.................................................................................................... 74 Table 8.14-K Firmware Version Report Syntax........................................................................................... 74 Table 8.14-L MAC Address Report Syntax ................................................................................................. 74 Table 8.14-M MAC Address Type Values................................................................................................... 74 Table 8.14-N FAT Status Report Syntax...................................................................................................... 74 Table 8.14-O FDC Status Report Syntax ..................................................................................................... 74 Table 8.14-P FDC Center Frequency Value................................................................................................. 74 vi Table 8.14-Q Current Channel Report Syntax.............................................................................................. 74 Table 8.14-R 1394 Report Syntax ................................................................................................................ 74 Table 8.14-S DVI Status Report Syntax....................................................................................................... 74 Table 8.14-T HDMI Status Report Syntax .................................................................................................. 74 Table 8.15-A Code Version Download Table .............................................................................................. 74 Table 8.15-B Resource Identifier ................................................................................................................. 74 Table 8.15-C Table of Application Protocol Data Units .............................................................................. 74 Table 8.15-D host_info_request .................................................................................................................. 74 Table 8.15-E host_info_response ................................................................................................................ 74 Table 8.15-F code version table .................................................................................................................. 74 Table 8.15-G code_version_table_reply...................................................................................................... 74 Table 8.15-H host_download_control table ................................................................................................ 74 Table 8.15-I host_download_command ...................................................................................................... 74 Table A.1-A Table Downstream Data Paths ................................................................................................ 74 Table A.1-B Upstream Data Paths ............................................................................................................... 74 Table C.3-A Keyword List ........................................................................................................................... 74 Table C.4-A Characters ................................................................................................................................ 74 Table D.2-A CISTPL_LINKTARGET ........................................................................................................ 74 Table D.2-B CISTPL_DEVICE_0A ............................................................................................................ 74 Table D.2-C CISTPL_DEVICE_0C............................................................................................................. 74 Table D.2-D CISTPL_VERS_1 ................................................................................................................... 74 Table D.2-E CISTPL_CONFIG ................................................................................................................... 74 Table D.2-F CCST_CIF ............................................................................................................................... 74 Table D.2-G CISTPL_CFTABLE_ENTRY................................................................................................. 74 Table D.2-H CISTPL_END ......................................................................................................................... 74 Table D.2-I Configuration Option Register.................................................................................................. 74 Table E.1-A Error Handling ......................................................................................................................... 74 vii List of Figures Figure 4.2-1 System with Two-way Network .............................................................................................. 15 Figure 4.3-1 System with One-way Network ............................................................................................... 16 Figure 4.4-1 - System with DOCSIS Two-way Network ............................................................................. 17 Figure 5.2-1 Flow Examples - QPSK Modem Case ..................................................................................... 20 Figure 5.3-1 Flow Examples - High Speed Host Modem Case .................................................................... 21 Figure 6.4-1 Host-POD Out-of-Band Interface ............................................................................................ 29 Figure 6.4-2. Phase States for Mapping ITX and QTX OK ........................................................................ 30 Figure 6.4-3 POD Output Timing Diagram.................................................................................................. 32 Figure 6.4-4 POD Input Timing Diagram .................................................................................................... 33 Figure 6.5-1 Modem-in-the-POD Module System Overview ...................................................................... 33 Figure 6.5-2 Modem in-the-Host System View........................................................................................... 34 Figure 6.5-3 Map of Hardware Interface Registers ..................................................................................... 35 Figure 6.7-1 POD RS Operation................................................................................................................... 39 Figure 6.7-2 POD Personality Change Sequence ......................................................................................... 42 Figure 6.7-3 POD Module Interrupt Logical Operation ............................................................................... 49 Figure 8.11-1 ................................................................................................................................................ 74 Figure 8.11-2 ................................................................................................................................................ 74 Figure 8.12-1 Generic Feature List Exchange .............................................................................................. 74 Figure 8.12-2 POD Module Feature List Change......................................................................................... 74 Figure 8.12-3 Host Feature List Change....................................................................................................... 74 Figure 8.12-4 Host to POD Module Feature Parameters.............................................................................. 74 Figure 8.12-5 Host Parameter Update .......................................................................................................... 74 Figure 8.12-6 POD Module to Host Feature Parameters.............................................................................. 74 Figure 8.13-1 Firmware Upgrade Flowchart ................................................................................................ 74 Figure 8.15-1 One-Way Operation............................................................................................................... 74 Figure 8.15-2 One-Way Operation – IB FAT Channel ................................................................................ 74 Figure 8.15-3 Two-Way Operation .............................................................................................................. 74 Figure 8.15-4 Two Way - Command Operation - IB FAT Channel............................................................. 74 Figure 8.15-5 Two Way - Command Operation - IB FAT Channel (continued) ......................................... 74 Figure 8.15-6 Two Way – On-Demand Operation - IB FAT Channel (continued)...................................... 74 Figure 8.15-7 Flow chart summarizing download operations ...................................................................... 74 Figure 8.15-8 Flow chart summarizing download operations for OOB Forward Data Channel method ..... 74 Figure 8.15-9 Flow chart summarizing broadcast download operations ...................................................... 74 Figure A.2-1 OOB TX Channel Available ................................................................................................... 74 Figure A.3-1 High Speed Host Modem and OOB TX Channel Available................................................... 74 Figure A.3-2 High Speed Host Modem Available, OOB TX Channel Not Available ................................. 74 Figure A.3-3 High Speed Host Modem Available, OOB TX Channel Not Available ................................. 74 Figure E.1-1 Error Display ........................................................................................................................... 74 viii Host-POD Interface Specification 1 SCOPE This standard defines the characteristics and normative specifications for the interface between Point of Deployment (POD) security modules owned and distributed by cable operators, and commercially available consumer receivers and set-top terminals (“Host devices”) that are used to access multi-channel television programming carried on North American cable systems. The Point-of-Deployment module is also known as a CableCARD™ device. These Host devices may also be supplied by the cable operators. The combination of a properly-authorized POD module and a Host device permits the unscrambled display of cable programming that is otherwise protected by a conditional access scrambling system. This standard applies extensions, modifications, and constraints to the interface defined in CEA-679B Part B, the National Renewable Security Standard. This standard supports a variety of conditional access scrambling systems. Entitlement management messages (EMMs) for such scrambling systems are carried in the cable out of band channel as defined by ANSI SCTE 55-1 2002 and ANSI/SCTE 55-2 2002. Other data transfer mechanisms such as the signaling methods of the DOCSIS version. 1.1 cable modem standard may be supported in the Host device. A cable operator is able to upgrade security in response to a breach by replacing the POD modules, without requiring any change in the host device. The interface will support Emergency Alert messages transmitted over the out of band channel to the POD module and then delivered by the POD module over the interface to the host device using the format defined in SCTE 18 2002. It may also support Interactive Program Guide services, Impulse Pay Per View services, Video on Demand, and other messaging and interactive services. It supports both one way and two way cable systems, as well as host devices that incorporate DOCSIS modems or telco modems. This standard defines the physical interface, signal timing, the link interface, and the application interface. It includes the extended channel specification, power management specifications, initialization procedures and firmware upgrade methods. 1 2 OVERVIEW OF HOST-POD INTERFACE 2.1 Historical Perspective (INFORMATIVE) This specification has its origins in CEA-679 (formerly EIA-679), the National Renewable Security Standard, which was initially adopted in September 1998. Part B of that standard has the physical size, shape and connector of the computer industry PCMCIA card, and also defines the interface protocols and stack. Part B of that standard was adopted by SCTE DVS as DVS/064. Further extensions and modifications of EIA-679 led to the adoption of EIA-679-B in 2000. Independently, the cable industry prepared a modified version of DVS/064 which was submitted as DVS/131. Revision 7 of that document was adopted by SCTE DVS in early 1999 but never attained the status of a final standard because there were comments and objections that were never resolved. Instead, the cable industry prepared a revised version that was submitted in January 2000 as DVS/295, incorporating many of the comments associated with DVS/131. Work on this document by the cable industry proceeded during the first half of 2000, leading to substantial changes that were embodied in DVS/295r1 (July 2000) and subsequent revisions in the open review process. 2.2 Advanced Cable Services (INFORMATIVE) The POD Module interface specification is designed to support advanced digital cable services by a digital television receiver when a POD Module is inserted. In this case, “Advanced Digital Cable Services” would include support of the following functions: • Emergency Alert System • Interactive Program Guide • Impulse Pay-Per-View (IPPV) • Video On Demand (VOD) • General Messaging • Interactive Services 2.2.1 Interactive Program Guide (IPG) The Host may support an Interactive Program Guide (IPG) to enable the user to navigate to available services. The services supported by the IPG may include basic channel, premium channels, and Impulse Pay-Per-View (IPPV) events. Program 2 guide data may be delivered to the application by means of the in-band (QAM) channel and/or by means of the out-of-band (QPSK) channel: • In-band transmission of program and system information typically describes only the digital multiplex in which it is sent. This means that a single-tuner Host must periodically scan through all channels to receive data for each channel and store this information in memory. • Optionally, at the discretion of the cable operator, the out-of-band channel may be used to deliver guide data. The format of this information over the OOB channel will be defined by the cable operator and may be used to support specific IPG implementations. The Host receives data from the POD that is sent on the out-of-band channel and delivered over the Extended Channel described in Section 5.The guide data typically describes the entire range of services offered by the cable system. 2.2.2 Impulse Pay-Per-View (IPPV) The Host may support the purchase of Impulse Pay-Per-View (IPPV) events. IPPV processing is split as follows: • All security related and billing functions are in the POD Module. • All user-interface functions are in the Host. The IPPV API is specified by “Generic IPPV Support” in section 8.10 and covers all common functions related to (1) IPPV purchase (2) IPPV cancel (3) IPPV purchase review. 2.2.3 Video-on-Demand (VOD) 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. The additional streaming media control functions (i.e. Pause, Play, Fast-Forward, Rewind) may be supported using DSM-CC User-to-User messages. The Extended Channel described in Section 5 may be used as the communication path for VOD signaling, and may also be used for VOD event purchases. After a VOD control session is established via the session creation interface, UDP messages may be exchanged transparently between the Host and the cable system. RFC 1831, 1832 & 1833 may be used as the underlying RPC mechanism for the exchange of DSM-CC UU. 2.2.4 Interactive services Interactive Services may be supported by applications executing on the Host, for example, an email or game application. To advertise interactive services, a mechanism is required to deliver information about applications to the Host and the 3 protocols described in ANSI/SCTE 80 2002 may be used for this purpose. Typically, information about interactive services are not associated with a streaming media service, so information about them is delivered via the out-of-band channel. The service information is passed to the Host via the Extended Channel resource when the POD Module serves as the OOB modem. The Extended Channel may also be used as the communication path for interactive service signaling when the POD Module is serving as the OOB modem. After an interactive service session is established via the session creation interface, UDP messages may be exchanged transparently between the Host and the cable system. RFC 1831, 1832 & 1833 may be used as the underlying RPC mechanism for the exchange of application level messages. 2.3 References 2.3.1 Normative references The following standards contain provisions that, through reference in this text, constitute normative provisions of this Specification. At the time of publication, the editions indicated are current. All standards are subject to revision, and parties to agreements based on this Specification are encouraged to investigate the possibility of applying for the most recent editions of the standards listed in this section. Normative reference list 1. CEA-679-C Part B: National Renewable Security Standard (July 2005) 2. ANSI/SCTE 55-2 2002 (formerly DVS 167), Digital Broadband Delivery System: Out Of Band Transport – Mode B 3. ANSI/SCTE 55-1 2002 (formerly DVS 178), Digital Broadband Delivery System: Out Of Band Transport – Mode A 4. SCTE 18 2002 (formerly DVS 208), Emergency Alert Message for Cable, approved as a joint standard with CEA as ANSI-J-STD-042-2002 5. ANSI/SCTE 65 2002 (formerly DVS 234), Service Information Delivered Out- of-Band for Digital Cable Television (28 March, 2000) 6. ANSI/SCTE 54 2004, Digital Video Service Multiplex and Transport System Standard for Cable Television 7. ISO/IEC 13818-6:1998 (E) Information Technology: Generic coding of moving pictures and associated audio information. Part 6: Extension for DSM-CC 8. ISO 8859-1: 8-Bit Single-Byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1, revised 1987 4 9. PC Card Standard, Volume 2 Electrical Specification, March 1997, Personal Computer Memory Card International Association, Sunnyvale, CA. 10. PC Card Standard, Volume 4 Metaformat Specification, 2001, Personal Computer Memory Card International Association, Sunnyvale, CA 11. RFC 2131, Dynamic Host Configuration Protocol, March 1997. 12. RFC 2132, DHCP Options and BOOTP Vendor Extensions, March 1997. 13. PC Card Standard, Volume 3 Physical Specification, Release 7, February 1999, Personal Computer Memory Card International Association, Sunnyvale, CA. 14. ANSI/SCTE 41 2004, POD Copy Protection System 15. HTML 3.2 Reference Specification: http://www.w3.org/TR/REC-html32.html 16. Hypertext Transfer Protocol – HTTP/1.1: http://www.ietf.org/rfc/rfc2616.txt?number=2616 17. SCTE 23-2 2002, Data-Over-Cable Systems 1.1, Baseline Privacy Plus Interface Specification, 18. DOCSIS Set-top Gateway (DSG) Interface Specification, CM-SP-DSG-I08- 060728 19. ANSI/SCTE 90-1 2004 SCTE Applications Platform Part 1: OCAP 1.0 Profile Normative reference acquisition ANSI/CEA Standards: • American National Standards Institute, Customer Service, 11 West 42nd Street, New York, NY 10036; Telephone 212-642-4900; Facsimile: 212-302-1286; E-mail: sales@ansi.org ; URL:http://www.ansi.org CEA Standards: United States of America • Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood, CO USA 80112-5776; Telephone 800-854-7179; Facsimile: 303-397- 2740; E-mail: global@ihs.commailto:global@ihs.com ; URL: SCTE Standards: United States of America • Society of Cable Telecommunications Engineers Inc., 140 Philips Road, Exton, PA 19341; Telephone 800-542-5040; Facsimile: 610-363-5898; E-mail: standards@scte.org ;URL: ITU Standards: 5 • ITU Sales and Marketing Service, International Telecommunication Union, Place des Nations CH-1211, Geneva 20, Switzerland; Telephone: +41 22 730 6141; Facsimile: +41 22 730 5194; E-mail: sales@itu.int ; URL: ISO/IEC Standards: • Global Engineering Documents, World Headquarters, 15 Inverness Way East, Englewood, CO 80112-5776, USA; Telephone: 800-854-7179; Facsimile: 303-397- 2740; E-mail: global@ihs.commailto:global@ihs.com ; URL: http://global.ihs.com • Internet Specifications: The Internet Engineering Task Force, IETF Secretariat, c/o Corporation for National Research Initiatives, 1895 Preston White Drive, Suite 100, Reston, VA 20101-5434; Telephone 703-620-8990; Facsimile 703-620-9071; E-mail: ietf-secretariat@ietf.org; URL: http://www.ietf.org/rfc PC Card Standards: • Personal Computer Memory Card International Association, 2635 North First Street, Suite 209, San Jose, CA 95134, (Tel) +408-433-CARD (2273), (Fax) +408-433- 9558, (Email) office@pcmcia.org DOCSIS and OpenCable Specifications: • Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027- 9750; URLs: http://cablelabs.com/, http://www.cablemodem.com/, http://www.opencable.com/ 2.3.2 Informative references The following documents contain information that is useful in understanding of this Specification. Some of these documents are drafts of standards or balloted standards with unresolved comments. Informative document list 1. OC-SP-CD-IF-I08-040831 OpenCable Common Download Specification 2. Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification, SP-RFIv1.1-I10-030730. 3. Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification, SP-RFIv2.0-I07-041210 4. Data-Over-Cable Service Interface Specifications, Operations Support System Interface Specification, ANSI/SCTE 23-3 2005. 6 5. Data-Over-Cable Service Interface Specifications, Operations Support System Interface Specification, SP-OSSIv2.0-I07-041210 Informative document acquisition Same as listed under Normative reference acquisition. 3 CEA 679 PART B COMPLIANCE 3.1 Exceptions to Compliance In all aspects not covered in this document, the POD Module interface requires complete CEA-679-Part C compliance with the following exceptions: Table 3.1-A CEA 679 Part B Compliance Exceptions Item Section Issue Comment 1 4.1 Second paragraph states “It also allows SCTE 28 supports only one for multiple instance of CA processes POD Module per POD/Host to exist for the same Host.” Interface. 2 4.1 Third paragraph is a description of SCTE 28 supports only one handling multiple modules. POD Module per POD/Host Interface 3 5.3 First paragraph states “This SCTE 28 supports only one functionality includes: the ability to POD Module per POD/Host support multiple modules on one host, Interface ...”. 4 5.4.1 Item 5 of the requirements and limits SCTE 28 supports only one list is “5) use of multiple modules”. POD Module per POD/Host Interface 5 5.4.2 Item 3 of the transport stream interface Packets arrive synchronously restrictions regarding the use of the with clock but not necessarily word contiguous. continuously 6 5.4.2 Item 5 of the transport stream interface Section 6.1.1 specifies rates specifies the maximum data rate of 58 around 27 and 39 Mbps. Mbps.. 7 5.4.2 Maximum jitter is not defined in the Defined in Section 6.1.1 document. 8 5.4.4 Entire paragraph is about multiple SCTE 28 supports only one modules. POD Module per POD/Host Interface 9 5.5 First paragraph sentence contains “... “NRSS-conformant module” and indicates to the host that it is a should be changed to a POD NRSS-conformant module.” module. 7 Table 3.1-A CEA 679 Part B Compliance Exceptions Item Section Issue Comment 10 7.2.4 Item 2 of the SPDU list states “a Section 8.1 limits the number of conditional body of variable length APDUs in an SPDU to one. which contains an integer number of APDUs belonging to the same session (see application layer).” 11 7.2.6 “... which is always followed by a Section 8.1 limits the number of SPDU body containing one or several APDUs in an SPDU to one. APDUs.” 12 8.2.1 First paragraph contains “Resources All resources that are defined in with higher version number shall be CEA-679-C that are modified backwards compatible with previous in SCTE 28 should have a versions, so that applications different type value or version requesting a previous version will have number. a resource with expected behavior. 13 8.4.1.1 First paragraph contains “When a Section 8.1 limits the number of module is plugged in or the host is transport connections to one. powered up one or perhaps two transport connections are created to the module, ...”. 14 8.4.2 Entire section. Section 8.4 replaces this entire section. 15 8.5 Entire section. Section 8.8 of SCTE 28 replaces Section 8.5 of CEA 679B Part B except for Section 8.5.2 which remains. 16 8.6 Entire section Section 8.3 replaces this entire section. 17 8.7 Entire section. Section 8.5 modifies this operation. 18 8.8 Entire section. Section 8.13 replaces this entire section. 19 8.9 Entire section. This entire section is replaced by ANSI/SCTE 41 2001 20 8.10 Entire section. SCTE 28 does not require this resource. 21 8.11 Table 87 & 91 Table 87 is replaced by Table 3.1-B and Table 91 is replaced by Table 3.1-C. 22 8.11 EIA-679-B Part B contained two sections numbered 8.11. This was corrected in CEA-679-C Part B, where they are now numbered 8.11 and 8.12. The Section formerly numbered 8.12 in EIA-679-B Part B has been renumbered 8.13 in CEA-679-C Part B. 8 Table 3.1-A CEA 679 Part B Compliance Exceptions Item Section Issue Comment 23 8.12.2 Host Control sections Host Control operation in Sections 8.12.1 and 8.12.2 of CEA-679-C is replaced by Section 8.8. 24 8.12.3- Extended Channel Support These sections of CEA-679-C 8.12.6 Part B are replaced by Sections 5 and 8.9 25 8.13 Entire section Section 8.13 of CEA-679-C is replaced by Section 8.10. 26 A.2.2.1 Status register description. IIR flag and operation description is given in Section 6.5.2 of SCTE 28. 27 A.4.1.3 Entire section Removed by section 6.7.6. 28 A.5.5.1 “Hosts shall support 5V working and Section 6.1.2 specifically states may optionally support 3.3V working.” that the POD module is only implemented as a 3.3V device. 29 A.5.5.2 Table 119 1. MCLKO has been moved from pin 57 to pin 14. Pin 14 is shared with A14 and becomes an I/O. Pin 57 shall be VS2# always. 2. Pin 11 Address 9 is also DRX. 3. Pin 12 Address 8 is also CRX. 4. Pin 22 Address 7 is also QTX. It is also changed to an I/O. 5. Pin 23 Address 6 is also ETX. It is also changed to an I/O. 6. Pin 24 Address 5 is also ITX. It is also changed to an I/O. 7. Pin 25 Address 4 is also CTX, 30 A.5.5.10 Item 1 of the power management POD Standby mode is not features list: “Except in standby mode, defined in SCTE 28. ...” 31 A.5.5.10 Item 2 of the power management Section 6.1.2 modifies this to 1 features list. amp. 32 A.5.5.10 Item 4 of the power management Section 6.1.2 modifies this to features list. 250 ma on Vpp. 33 A.5.6 Item 5 of the metaformat list regarding Section 6.1.1 changes this to ID number. 0341h. 9 Table 3.1-A CEA 679 Part B Compliance Exceptions Item Section Issue Comment 34 A.5.6 Item 5 of the metaformat list lists Section 6.2 changes this to STCI_STR as “NRSS_CI_V1.00”. “OPENCABLE_ POD_ MODULE”. 35 A.5.6 Item 7 of the metaformat list lists Change this to “OPENCABLE_ system name as “NRSS_HOST” HOST” 36 A.5.6 Item 8 of the metaformat list lists Section 6.2 changes this to physical device name as “OPENCABLE_ POD_ “NRSS_CI_MODULE”. MODULE”. 37 A.5.6 CISTPL_LINKTARGET is not Section 6.3 requires this tuple included. per PCMCIA recommendations. 38 B Entire appendix Should be replaced by appendix C. 39 C.1 Entire section SCTE 28 does not support this resource. 40 C.2 Entire section SCTE 28 does not support this resource. 41 C.3 Entire section SCTE 28 does not support this resource. 42 D Entire section Homing operation is modified by Section 8.13. 43 E Entire section. SCTE 28 supports only one POD Module per POD/Host Interface 44 F Entire section SCTE 28 does not require smart-card resource. 45 A.2.1.2.2- Single buffer implementation SCTE 28 does not support a A.2.2.2 single buffer implementation in the POD. • The requirement of section 7.2.6.1 of CEA-679-C Part B that the Host or POD module must support earlier versions of a resource shall only apply to versions of resources described in this specification. • Transport layer timeout period shall be modified from 300 ms to 5 seconds. • Hardware Interface Description – The term “command register” is used erroneously. It shall therefore be referred to as “Control Register.” • The requirement of Section 8.3.3 of CEA-679-C Part B to support an integer number of APDUs in a body of a single SPDU shall be changed to only a single APDU shall be supported in the body of a SPDU. • The requirement of Section 8.4.3.5 of CEA-679-B Part B that the POD shall implement its CA application such that when ca_enable is present in ca_pmt_reply() 10 both at program level and elementary stream level, only the ca_enable at ES level applies for that elementary stream shall be applicable to a POD in a network that support different authorization at program level and elementary stream level. • NOTE: Section 8.4.3.5 of CEA-679-C Part B states that the CA PMT Reply "may" also be sent after reception of a CA PMT object. Implementors should be aware that sending a CA_PMT object to the POD with ca_pmt_cmd_id set to 'ok_mmi' is not guaranteed to return a response. • Products compliant with this specification shall provide a double buffer implementation. The single buffer implementation permitted by CEA-679-C shall not be used. Table 3.1-B Replacement for CEA-679-C Table 87 Resource Identifier Values Resource class type Version resource identifier Resource Manager 1 1 1 00010041 Application Information 2 2 1 00020081 Conditional Access Support 3 1 2 00030042 Host Control 32 1 3 00200043 System Time 36 1 1 00240041 MMI 64 2 1 00400081 Low Speed Communication 96 ** 2 0060xxx2 Homing 17 1 2 00110042 Copy Protection 176 3 1 00B000C1 Specific Application 144 1 1 00900041 Generic Feature 42 1 1 002A0041 Extended Channel 160 1 1 00A00041 Generic IPPV Support 128 2 1 00800081 ** - See section 8.5 for details. Table 3.1-C Replacement for CEA-679-C Table 91 Application Object Tag Values apdu_tag tag value (hex) Resource Direction Host ↔ POD Tprofile_inq 9F 80 10 Resource Manager ↔ Tprofile_reply 9F 80 11 Resource Manager ↔ Tprofile_changed 9F 80 12 Resource Manager ↔ Tapplication_info_req 9F 80 20 Application Info → Tapplication_info_cnf 9F 80 21 Application Info ← Tserver_query 9F 80 22 Application Info → Tserver_reply 9F 80 23 Application Info ← Tca_info_inq** 9F 80 30 CA Support → Tca_info** 9F 80 31 CA Support ← 11 Table 3.1-C Replacement for CEA-679-C Table 91 Application Object Tag Values apdu_tag tag value (hex) Resource Direction Host ↔ POD Tca_pmt** 9F 80 32 CA Support → Tca_pmt_reply** 9F 80 33 CA Support ← Tca_update 9F 80 34 CA Support ← TOOB_TX_tune_req 9F 84 04 Host Control ← TOOB_TX_tune_cnf 9F 84 05 Host Control → TOOB_RX_tune_req 9F 84 06 Host Control ← TOOB_RX_tune_cnf 9F 84 07 Host Control → Tinband_tune 9F 84 08 Host Control ← Tinband_tune_cnf 9F 84 09 Host Control → Tsystem_time_inq** 9F 84 42 System Time ← Tsystem_time** 9F 84 43 System Time → Topen_mmi_req 9F 88 20 MMI ← Topen_mmi_cnf 9F 88 21 MMI → Tclose_mmi_req 9F 88 22 MMI ← Tclose_mmi_cnf 9F 88 23 MMI → Tcomms_cmd 9F 8C 00 Low speed comms. ← Tconnection_descriptor 9F 8C 01 Low speed comms. ← Tcomms_reply 9F 8C 02 Low speed comms. → Tcomms_send_last 9F 8C 03 Low speed comms. ← Tcomms_send_more 9F 8C 04 Low speed comms. ← Tcomms_rcv_last 9F 8C 05 Low speed comms. → Tcomms_rcv_more 9F 8C 06 Low speed comms. → Tnew_flow_req 9F 8E 00 Extended Channel ↔* Tnew_flow_cnf 9F 8E 01 Extended Channel ↔* Tdelete_flow_req 9F 8E 02 Extended Channel ↔* Tdelete_flow_cnf 9F 8E 03 Extended Channel ↔* Tlost_flow_ind 9F 8E 04 Extended Channel ↔* Tlost_flow_cnf 9F 8E 05 Extended Channel ↔* Tprogram_req 9F 8F 00 Generic IPPV Support → Tprogram_cnf 9F 8F 01 Generic IPPV Support ← Tpurchase_req 9F 8F 02 Generic IPPV Support → Tpurchase_cnf 9F 8F 03 Generic IPPV Support ← Tcancel_req 9F 8F 04 Generic IPPV Support → Tcancel_cnf 9F 8F 05 Generic IPPV Support ← Thistory_req 9F 8F 06 Generic IPPV Support → Thistory_cnf 9F 8F 07 Generic IPPV Support ← Tfeature_list_req 9F 98 02 Generic Feature Control ↔ Tfeature_list 9F 98 03 Generic Feature Control ↔ Tfeature_list_cnf 9F 98 04 Generic Feature Control ↔ Tfeature_list_changed 9F 98 05 Generic Feature Control ↔ Tfeature_parameters_req 9F 98 06 Generic Feature Control ↔ Tfeature_parameters 9F 98 07 Generic Feature Control ↔ Tfeature_parameters_cnf 9F 98 08 Generic Feature Control ↔ Topen_homing 9F 99 90 Homing → Thoming_cancelled 9F 99 91 Homing → Topen_homing_reply 9F 99 92 Homing ← 12 Table 3.1-C Replacement for CEA-679-C Table 91 Application Object Tag Values apdu_tag tag value (hex) Resource Direction Host ↔ POD Thoming_active 9F 99 93 Homing → Thoming_complete 9F 99 94 Homing ← Tfirmware_upgrade 9F 99 95 Homing ← Tfirmware_upgrade_reply 9F 99 96 Homing → Tfirmware_upgrade_complete 9F 99 97 Homing ← * - Direction depends on if Host has modem. See section 8.9. ** These values are copied directly from Table 91 of CEA-679-C Part B and do not appear explicitly in this document. 4 SYSTEM ARCHITECTURE (INFORMATIVE) 4.1 Introduction At the subscriber premises, a reception system includes a cable navigation device, or Host, and a POD Module. This combination allows the isolation of cable operator hardware specifics into a renewable POD Module and therefore provides the architectural foundation for retail availability of cable navigation devices. The POD Module interface consists of a standardized: • Bi-directional access to the Out-Of-Band RF Front End, or alternatively access to forward Out-Of-Band Messaging supplied by one or more DSG Tunnels via the DOCSIS Set-top Gateway (DSG) [2] • In-band MPEG-2 Transport Stream input and output, and • CPU interface. The Host-POD Interface will operate in one of two modes, a mode using SCTE 55-1 or SCTE 55-2 OOB channels (the OOB mode), or a mode that uses the DOCSIS Set- top Gateway (DSG) for the forward OOB messaging and the normal DOCSIS IP channel for return traffic (the DSG mode). In the first mode of operation, the signaling functions are split between the Host and the POD Module such that only the RF processing and QPSK demodulation and modulation are done in the Host. The Advanced Host will operate in either of these two modes, OOB or DSG, based on network configurations. All other Hosts will operate in the OOB mode. The remainder of the processing, including all of the Data-link and MAC protocols, is implemented in the POD Module. This split was chosen for the following reasons: 13 • SCTE 55-1 and SCTE 55-2 use common modulation (QPSK), but in all other respects are quite different. Only the parts of the protocol stack common to both OOB schemes are included in the Host. • Future development of OOB protocols should not be precluded. By placing the majority of the OOB processing in the POD Module, the OOB can be renewed at a future time by replacement of the POD Module. • It is important to the cable operator that the reverse (upstream) transmissions from any device are correctly controlled, because a single uncontrolled device can impair a significant portion of the shared access network. By implementing the media access control processing in the POD Module, the cable operator can maintain the integrity of the access network. • All processing of conditional access messages is done in the POD Module. This approach is taken to protect from theft-of-service attacks. In the DSG mode of operation, all of the Data-link and MAC level protocols are implemented in the embedded DOCSIS cable modem in the Host. In this case the POD is not responsible for implementing these protocols, since they are provided via the embedded DOCSIS cable modem. The OOB messaging in this case is transported as follows: • The forward OOB messaging is transported via one or more DSG Tunnels to the Host • The Host filters the IP packets on the DSG Tunnels identified by the Ethernet MAC addresses specified by the POD. • The Host optionally removes the IP headers of these packets as instructed by the POD (the POD specifies the number of bytes to be removed from the header of the IP packet). • The resulting data packets are transmitted over the extended channel to the POD module. The POD Module can be used in a number of different networks, as described in the sections below. 4.2 Two-way Networks Figure 4.2-1 gives a schematic view of the system when the cable network includes an OOB return Data Channel based on ANSI/SCTE 55-1 2002 or ANSI/SCTE 55-2 2002. 14 Host TUNER DEMOD DEMUX MPEG Cable QPSK TX CPU RX OOB INB CPU POD Module Figure 4.2-1 System with Two-way Network The QPSK receiver circuit in the Host tunes and demodulates the QPSK Forward Data Channel (FDC). The receiver circuit adapts to the 1.544/3.088 Mbps or 2.048 Mbps FDC bit rate, and delivers the serial bit-stream and clock to the POD Module. (This serial data is used primarily to send conditional access entitlement management messages from the cable system to the POD Module. These messages are beyond the scope of this standard.) Tuning of the QPSK receiver circuit is under control of the POD Module, as explained in Section 8.8.2. The tuning range is between 70 and 130 MHz. In the return path, the POD Module generates QPSK symbols and clock and transfers them to the QPSK transmitter circuit in the Host. The transmitter circuit adapts to the 1.544/3.088 Mbps or 0.256 Mbps RDC bit rate. The QPSK transmitter circuit modulates the QPSK symbols onto a narrow band carrier. Tuning and level control of the QPSK transmitter are under control of the POD Module as explained in Section 8.8.1. The tuning range is between 5 MHz and 42 MHz . 4.3 One-way Networks The configuration shown in Figure 4.3-1 applies where there is a no return channel. 15 The QPSK transmitter in the Host is not active (and it is therefore omitted from the diagram). The receiver circuit operates in the same manner as described in Section 8.8. An optional telephone modem may be used in one-way networks to allow limited interactive services. In this case, the standard telephone modem is incorporated into the Host. The Host may opt to allow the POD to have access to the telephone modem. In the event that the Host permits the POD to have access to the telephone modem, the POD Module may access the telephone modem via the Low Speed Communications Resource defined in CEA 679-C Part B. Support of the Low Speed Communication Resource as defined in CEA 679-C Part B is optional. Host TUNER DEMOD DEMUX MPEG Cable CPU RX OOB INB CPU POD Module Figure 4.3-1 System with One-way Network After POD Module initialization, the Host informs the POD Module about the available Low Speed Communication resources as defined by CEA-679-C Part B (see the Reference List in the Informative Annex). Then, when the POD Module requires setting up a connection with the cable headend, datagrams are sent to the telephone modem via the CPU interface as defined by CEA-679-C Part B. 16 4.4 Two-way Networks with DOCSIS The configuration shown in Figure 4.4-1 applies where a DOCSIS capability exists in the Host. OpenCable Advanced Host TUNER-1 DEMOD DEMUX TUNER-2 CPU DOCSIS Cable DSG Mode QPSK/ QAM 16 TX OOB Mode RX OOB INB CPU POD Module Figure 4.4-1 - System with DOCSIS Two-way Network In this configuration a single upstream transmit path is shared between the POD Module and the DOCSIS modem. In order to prevent conflict between the DOCSIS upstream and the OOB upstream the system will operate in one of two modes. • OOB mode – The downstream Conditional Access Messages and network management messages will be delivered to the POD Module via the QPSK receive interface on the POD Module using, e.g., SCTE 55-1, SCTE 55-2, or other agreed OOB specification. The upstream Conditional Access Messages and network management messages will be transmitted from the POD Module via the QPSK transmit interface on the POD Module using, e.g., SCTE 55-1, SCTE 55-2, or other agreed OOB specification. • DSG mode – The downstream Conditional Access Messages and network management messages will be delivered to the POD Module by the Extended Channel using the DSG Service_type using the DOCSIS downstream in 17 accordance with the DOCSIS Set-top Gateway (DSG) Specification [1]. The upstream Conditional Access Messages and network management messages will be transmitted from the POD module via IP over the DOCSIS upstream channel using the Extended Channel. The DOCSIS bi-directional channel can be used by any applications running in the Host, simultaneously with the POD module’s communication with the headend via the Extended Channel using DOCSIS. The use of the Extended Channel by the POD module for IP flows does not change DSG usage of the DSG Service_type on the Extended Channel. The mode used is based on whether the DOCSIS Set-top Gateway is supported by the network. The POD informs the Host which of these modes is to be used as detailed later in this specification. 5 EXTENDED CHANNEL DATA FLOWS 5.1 Internet Protocol Flows (Informative) The Extended Channel supports delivery of IP packets across the POD interface. Both unicast (point to point) and multicast (point to multipoint) addressing shall be supported by this protocol. If the Host is in OOB mode, then the POD module shall service the IP flow via utilization of the Host’s RDC and shall supply the Host with an IP address. On request of a “new flow request” from the Host, the POD Module shall respond to the request to open the flow by obtaining an IP address for use by the Host. That IP address shall be returned in the “new flow confirmation” message. Informative Note: The POD is not required to grant a request for service type IP Unicast when requested by the Host. In DSG mode, the Card resides at the Network Layer and the Host shall utilize its eCM to provide the Data Link Layer to the underlying DOCSIS network. When the Card wishes to utilize the DOCSIS network to transfer IP datagrams upstream, it shall first submit a “new flow request” to the Host to establish an IP flow to transfer datagrams between the Card and the Host’s eCM interface. The Card shall submit its MAC address in its request to the Host for an IP flow. If the Host grants the new IP flow request, then the Host shall utilizes DHCP to acquire an IP address for the Card, and shall send this information, along with the DOCSIS maximum transmission unit (MTU) (1500 bytes for IP datagrams) to the Card in a new flow confirmation. The Host shall then open an IP flow to the Card over the Extended Data Channel. The Host shall utilize the MAC address provided in the Card’s IP flow request to filter Ethernet frames from the eCM that are intended for the Card. The Host shall extract all unicast IP datagrams from Ethernet frames addressed to the CableCARD’s MAC address and shall forward them over the Extended Data Channel to the CableCARD. 18 The Host shall utilize the Extended Data Channel’s IP flow to forward IP datagrams it receives over the eCM interface on behalf of the Card. The Host shall not forward the Card any datagrams received over other interfaces (e.g. Ethernet port, USB port, etc.). The Host shall forward all IP datagrams received from the Card to the eCM interface. The Host shall not forward any IP datagrams received from the Card to any other interface, including but not limited to: IEEE-1394, Ethernet, USB, 802.11a/b/g/n/x, Multimedia Over Coax Alliance (MoCA), etc. The Host shall resolve the destination MAC address of the IP datagrams that it receives from the Card and shall apply the appropriate MAC addresses to the Ethernet frames it sends upstream. If an established IP type of flow becomes unavailable for any reason, the device that has granted the flow shall report that fact to the one that has requested the flow. The “lost flow indication” transaction shall be used to report this type of event. One example case where a flow may become unavailable is due to a change in the state of the eCM that may have resulted from a change via SNMP to the eCM’s operational state. 5.2 Flow Examples—QPSK Modem Case (Informative) Figure 5.2-1 diagrams a POD-Host interface in which four flows have been set up. In this example case, the POD provides a full-duplex modem function for the benefit of the Host (as well as itself). The rounded rectangle boxes represent applications. In this example, the Host has a Navigation application that receives Service Information data on the Extended Channel via the POD interface (#1). The Host has opened up three flows to receive MPEG data from the POD, and has supplied different PID values for filtering for each. The navigation function (#1) uses two SI flows in the example, and another application (#2) uses the third flow. The Host also has a web browser application (#3) and a Video On Demand (VOD) application (#4). In Figure 5.2-1, the types of services that the POD is required to support are shown with black arrows. As shown in the figure, three flows delivering MPEG table sections are required. Flows that may be available at the option of the supplier of the POD are shaded gray. In the figure, the POD supports an IP flow, but a compliant POD can choose not to support the IP service type. 19 Host Web VOD 3 4 QPSK Nav. (SI) App. Rx 1 2 QPSK Tx IP/Port Routing MPEG_section MPEG_section IP_U POD CA RPT 5 6 Transport Processing, Filtering and Routing Figure 5.2-1 Flow Examples - QPSK Modem Case The POD includes two applications of its own. The Conditional Access process (#5) receives data via downstream QPSK. The POD includes a pay-per-view reportback function (#6). Note that none of these POD applications use flows that travel across the POD interface. 5.3 Flow Examples— High Speed Host Modem Case DSG Mode In the next example case, the Host includes a High Speed Host Modem. Figure 5.3-1 diagrams a POD-Host interface in which five flows have been set up. When a Host includes a High Speed Host Modem, the Host is required to support at least one flow of service type IP Unicast (IP_U). As before, the POD must support three MPEG section flows if the Host requests them. 20 Host High Speed IP/Port Routing Host Modem Web MC Nav (SI) 1 2 3 MPEG_section IP_M IP_U POD IP/Port Routing CA RPT MC 4 5 6 Transport Processing, Filtering, and Routing Figure 5.3-1 Flow Examples - High Speed Host Modem Case In this example, the Host has a web browser application (#1), some application that uses multicast addressed packets (#2) and a Navigation application (#3) that receives Service Information data on the Extended Channel via the POD interface via three separate flows. The Navigation application can open three different simultaneous flows, specifying different PID values for each. For example, it might set one to the base PID that carries SI network data including the Master Guide Table, Virtual Channel Table and System Time. It can set a second one to point to a PID value where Event Information Tables for a specific time slot may be found, and another to collect associated Extended Text Tables (ETTs). The POD includes three applications of its own. The Host routes IP packets to the POD applications based on IP address. For unicast packets, those that match the IP address assigned to the POD will be routed across the interface. For multicast 21 packets, those matching the multicast group address associated with a particular flow will be delivered. The POD includes a pay-per-view reportback function (#5) that uses standard IP packets for data transport. Finally, the POD includes some application (#6) that has registered with the Host to receive multicast-addressed IP packets through the Host modem. 5.4 Summary of Extended Channel Flow Requirement (Normative) Compliance with this standard requires Host and POD devices to support certain flows. Other types of flows may be supported at the discretion of the Host or POD. The following table summarizes the requirements. Table 5.4-A Flow Requirements Requestor Data Direction Service Type Number of Concurrent Flows Host POD → Host MPEG section 6 or more If Host implements High Speed Host Modem or if OCAP is supported: POD Host ↔ POD IP Unicast At least 1 If Host implements DSG: POD Host → POD DSG 1 5.5 System/Service Information Requirements (Normative) The POD module shall supply System and Service Information across the HOST- POD interface, using Service_type MPEG_section, as defined in Section 8.9.1 and ANSI/SCTE 65 2002. The set of MPEG-2 tables provided to support the navigation function in the terminal device shall conform to one or more of the profiles specified in ANSI/SCTE 65 2002. Note: 1 (Informative) Profiles 1 through 5 are compatible with terminal devices deployed as of Jan 1, 2000. Terminal devices that are intended to be portable across the US will need to function with any of the six profiles of ANSI/SCTE 65 2002. For operational considerations of various profiles, see section A.3 in ANSI/SCTE 65 2002 5.6 Emergency Alert Requirements (Normative) The POD module may receive Emergency Alert messaging on either the FAT channels or the Out-of-Band Forward Data channel (OOB FDC). The EAS message syntax is compatible with MPEG-2 transport and is defined in SCTE 18 2002. For 22 FAT channel transmission, the EAS message shall appear in transport packets with the same PID as those used for Service/System Information (SI) and shall be transmitted by the POD to the HOST. The table ID for the EAS message is 0xD8 as defined in SCTE 18 2002. For out-of-band (OOB) transmission, EAS messages shall be processed by the POD module and shall be transmitted over the Extended Channel according to SCTE 18 2002. 6 PHYSICAL INTERFACE (NORMATIVE) 6.1 PC Card Compliance 6.1.1 POD Module Port Custom Interface (0341h) The POD Module interface is registered to the PC Card Standard as the POD Module Custom Interface with the interface ID number (STCI_IFN) allocated to equal hexadecimal 341. In case the Host is not capable of operating with the POD Module, the Host shall ignore the POD Module. The POD Module shall present the 16-bit PC Card memory-only interface following the application of VCC or the RESET signal. When operating in this configuration, D7-D0 are retained as a byte-oriented I/O port, and the capability to read the Attribute Memory is retained. Only two address lines are required for four Bytes of register space. Pin CE2# is assigned to select the Extended Channel function required for the POD Module CPU interface to enable the access to the Extended Channel resource. Pin IOIS16# is never asserted. The Host-POD interface shall be required to support transport stream interface data rates of 26.97035 Mb/s and 38.81070 Mb/s averaged over the period between the sync bytes of successive transport packets with allowable jitter of +/- one MCLKI clock period. 6.1.2 Power Management In order to remain compliant with the PC Card standard and to simplify the Host and POD Module implementations, and regardless of the powering state of the Host (i.e., active or standby), the following power management features are required. • The Host shall permanently supply 3.3V on the VCC pins. The Host shall be capable of supplying up to a maximum of 1 amp total on the VCC pins (500 ma each) at 3.3 VDC per POD Module supported. • The Host shall supply 5V on the VPP pins if requested by the POD Module Card Information Structure. The Host shall be capable of supplying up to 250 ma total on the VPP pins (125 ma each) at 5 VDC per POD Module supported. 23 • The Host shall continuously supply 3.3V on the VPP pins upon Host power-up and also when a POD module is not installed. When a POD module or a PC Card is installed, if the voltage sense pins are set as required per the Host-POD Interface Specification, the Host shall supply 5 V on the VPP pins only if requested by the POD Module Card Information Structure. Otherwise, the Host shall continue to supply 3.3 V on the VPP pins while the POD module/PC Card is installed. Upon removal of a POD module or a PC Card, the Host shall revert to or continue to supply 3.3V on the VPP pins. The Host shall be capable of supplying up to 250 ma total on the VPP pins (125 ma each) at 5 VDC per POD module supported. • The Host shall not be required to support the separate nominal voltage parameter descriptors in the power descriptor structures for VPP1 and/or VPP2. • The POD module shall only support the value of 0x2 in the Power field of the Feature Selection Byte (TPCE_FS) and the associated parameter descriptor according to section 3.3.2.3 of PC Card Standard, Volume 4 if the POD module requires a switched nominal voltage level of +5V on the VPP lines. • There is no standby power mode for the POD module. • The POD Module shall draw no more than 2.5 watts averaged over a period of 10 seconds. • The Host OOB Receive circuitry must continue to operate in all powering states of the Host. • The Host shall support hot insertion and removal of the POD Module. • The POD Module shall implement the mechanical Low Voltage Keying. • The POD Module shall force VS1 (pin 43) to ground and VS2 (pin 57) to high impedance until it switches to the POD Module Custom Interface mode. • The POD Module shall support 3.3V hot insertion. • The POD module does not have to meet the requirement of section 4.12.2 of the PCMCIA Electrical Specification to limit its average current to 70 mA prior to the POD Personality Change (writing to the Configuration Option Register). 6.1.3 Pin Assignment The following table shows the function of various PC Card signals when the POD Module Port custom interface mode is set to active in the Host. Differences between CEA-679-C Part B and this Host-POD Interface Specification affect the A4 to A9 signals, which are now assigned to the OOB RF I/Os, and CE2#, which is used to access the Extended Channel. The MCLKO is provided on pin 14 to be fully PC Card compliant. This is a modification from CEA-679-C (Part B). Pin 57 24 remains the PC Card VS2# signal. Shaded entries in Table 6.1-A highlight the differences between CEA-679-C Part B and this specification. 25 Table 6.1-A PC Card Signal Definitions Pin Signal I/O Comment Pin Signal I/O Comment 1 GND DC Ground 35 GND Ground 2 D3 I/O 36 CD1# O 3 D4 I/O 37 MDO3 I/O (D11) 4 D5 I/O 38 MDO4 I/O (D12) 5 D6 I/O 39 MDO5 I/O (D13) 6 D7 I/O 40 MDO6 I/O (D14) 7 CE1# I 41 MDO7 I/O (D15) 8 A10 I 42 CE2# I Extended Channel 9 OE# I 43 VS1# O 10 A11 I 44 IORD# I (RFU) 11 DRX I (A9) 45 IOWR# I (RFU) 12 CRX I (A8) 46 MISTRT I (A17) 13 A13 I 47 MDI0 I (A18) 14 MCLKO I/O (A14) 48 MDI1 I (A19) 15 WE# I 49 MDI2 I (A20) 16 IREQ# O (READY) 50 MDI3 I (A21) 17 VCC DC 3.3V 51 VCC DC 3.3V 18 VPP-1 DC Switched 5V 52 VPP-2 DC Switched 5V 19 MIVAL I (A16) 53 MDI4 I (A22) 20 MCLKI I (A15) 54 MDI5 I (A23) 21 A12 I 55 MDI6 I (A24) 22 QTX I/O (A7) 56 MDI7 I (A25) 23 ETX I/O (A6) 57 VS2# O 24 ITX I/O (A5) 58 RESET I 25 CTX I (A4) 59 WAIT# O 26 A3 I 60 INPACK# O 27 A2 I 61 REG# I 28 A1 I 62 MOVAL O (BVD2) 29 A0 I 63 MOSTRT O (BVD1) 30 D0 I/O 64 MDO0 I/O (D8) 31 D1 I/O 65 MDO1 I/O (D9) 32 D2 I/O 66 MDO2 I/O (D10) 33 IOIS16# O (WP) 67 CD2# O 34 GND DC Ground 68 GND DC Ground Note: “I” indicates signal is input to POD Module, “O” indicates signal is output from POD Module 26 6.2 POD Module Identification The Host has two different ways to recognize a POD Module: (1) at the application level, using the Application Info CEA-679-C Part B resource, or (2) at the physical level as defined by PCMCIA. . In PCMCIA memory mode, the Host accesses the POD Module’s Attribute Memory to read the Card Information Structure (CIS) on the even addresses (first byte at address 000h, second byte at address 002h, etc.). Since the POD Module interface is a PC Card Custom Interface the CIS must include a custom interface subtuple (CCST_CIF) that provides the interface ID number (STCI_IFN) defined by PCMCIA (hex341). For a more explicit identification, the CIS also includes in the tuple CISTPL_VER_1, the field name of the product of subtuple TPLLV1_INFO defined as “OPENCABLE_POD_MODULE”. This information in the CIS is mandatory to ensure backup operation in case of trouble when the CI stack is lost (e.g., power shut down, POD Module extraction). 6.3 Card Information Structure The Card Information Structure (CIS) shall be readable whenever the SCTE POD module is powered, the SCTE POD module has been reset by the Host in accordance with section 4.12.1 of Volume 2, “Electrical Specification” of the PC Card Standard, the SCTE POD module is asserting the READY signal, and the POD Personality Change has not occurred. The CIS contains the information needed by the Host to verify that a POD module has been installed. . After the POD Personality Change, the CIS shall no longer be available. The following table is the minimum set of tuples required for the POD Module. 27 Table 6.3-A CIS Minimum Set of Tuples CISTPL_LINKTARGET CISTPL_DEVICE_0A CISTPL_DEVICE_0C CISTPL_VERS_1 CISTPL_MANFID CISTPL_CONFIG CISTPL_CFTABLE_ENTRY CISTPL_NO_LINK CISTPL_END 6.4 Host-POD OOB Interface This standard requires support for OOB signaling. This signaling is provided in one of two modes, Out of Band (OOB) Mode and DOCSIS Settop Gateway (DSG) Mode: 6.4.1 Out of Band (OOB) Mode • The Host RF front-end specification provides the QPSK physical layer to support OOB (downstream and upstream) communications according to SCTE 55-1 or SCTE 55-2. The data link and media access control protocols for SCTE 55-1 or SCTE 55-2 are implemented in the POD Module. The interface data rates are: o Forward Receiver: 1.544/3.088 Mbps and 2.048 Mbps o Reverse Transmitter: 772/1544 Ksymbol/s and 128 Ksymbol/s (i.e., 1.544/3.088 Mbps and 256 Kbps) The transmit and receive interfaces for the Host-POD OOB Interface are shown in Figure 6.4-1 below. The receiver interface comprises a serial bit stream and a clock, while the transmitter interface comprises I and Q data, a symbol clock, and a transmit-enable signal. The clock signal should be transferred from the Host to the POD, as shown in Figure 6.4-1. 28 Master QPSK Clock QPSK Demodulator Transmitter Host POD Module DRX CRX ITX QTX ETX CTX Figure 6.4-1 Host-POD Out-of-Band Interface The interface symbols are defined below. Table 6.4-A Transmission Signals for Host-POD Interface Signal Definition Rates Type DRX RX Data 1.544/3.088 and 2.048 Mbps I CRX RX Gapped Clock 1.544/3.088 and 2.048 MHz I ITX TX I Channel 772/1544 and 128 O Ksymbol/s QTX TX Q Channel 772/1544 and 128 O Ksymbol/s ETX TX Enable [ n/a ] O CTX TX Gapped Symbol Clock 772/1544 and 128 KHz I 1. DRX/CRX DRX – The DRX data directly from the Host FDC QPSK receiver. 29 CRX – Gapped clock is a clock signal in which some of the clock cycles are missing, creating an artificial gap in the clock pattern. The clock rate is one of 1.544, 3.088 or 2.048 MHz 2. ITX, QTX – Differential encoding shall take place within the POD module. The Host shall map ITX,QTX directly to the phase states shown in Figure 5.4- 3 below. 3. ETX – ETX is an output from the POD Module and an input to the Host. It is defined to be active high. When ETX is inactive, the values of ITX and QTX are not valid and the upstream transmitter shall not transmit such values. When ETX is active, the values of ITX and QTX are both valid and the upstream transmitter shall transmit these values. Q IQ = 01 11 x x I x x 00 10 Figure 6.4-2. Phase States for Mapping ITX and QTX OK 6.4.2 DOCSIS Settop Gateway (DSG Mode The Host DOCSIS cable modem provides the physical, data link, and media access control protocols. Unlike the OOB mode, the data link and media access control protocols for SCTE 55-1 or SCTE 55-2 are bypassed in the POD Module. The downstream communications are implemented in accordance with the DOCSIS Set- top Gateway (DSG) Specification. The upstream Conditional Access Messages and network management messages will be transmitted from the POD Module via IP over the DOCSIS upstream channel using the Extended Channel. The interface data rates are: o Downstream direction: 2.048 Mbps o Upstream direction: Limited by DOCSIS return channel capacity The first two bytes of the frame are the total number of bytes following in the frame, i.e. they do not include this two-byte length field. There is no CRC check required on 30 the frame, as the interface between the Host and POD is reliable. It is the responsibility of the POD vendor to implement error detection in the DSG encapsulated data. The POD should disregard any invalid packets received from the Host. The Host must provide buffer space for a minimum of two DSG IP packets, one for transmission to the POD and one for receiving from the DOCSIS channel. Informational note: The DSG rate limits the aggregate data rate to 2.048 Mbps to avoid buffer overflow. Figure 5.4-2 below shows how the DSG packets are transported across the POD/Host interface with and without removal of the header bytes. Prior to transmission across the POD/Host interface, the CRC of the DSG packet received from the eCM is removed, then optionally header bytes may be removed in order from the Ethernet header through the IP header and the UDP header resulting in the removal of X header bytes where X is defined by the POD as per the remove_header_bytes of the set_dsg_mode() APDU (note that X may be zero, thus no header bytes are removed). A two byte field containing the DSG byte count of the resulting data payload is prepended to the remaining frame and transmitted across the POD/Host interface. Ethernet Header IP Header Data Payload Ethernet CRC DSG Packet From Embedded DOCSIS CM DSG Byte Count Ethernet IP Header Data Payload HeaderDSG Byte Count DSG Byte Count DSG Packet Across POD/Host Interface (Remove_Header_Bytes = 0) DSG Byte Count Data Payload DSG Packet DSG Byte Count Across POD/Host Interface (Remove_Header_Bytes = Ethernet Header + IP Header Size) Figure 6.4-3. DSG Packet Format Across POD/Host Interface 6.4.3 Timing and Voltage Parameters All POD signal requirements and timing requirements shall comply with Table 6.4-B and Figures 6.4-2 and 6.4-3, and shall be measured with no less than the maximum load of the receiver as defined in table 4-19 of [10]. The PC Card A7, A6, and A5 pin definitions have been modified to QTX, ETX, and ITX. These pins will be driven by the POD and will have Data Signal characteristics per table 4-19 of [10]. Additionally, the signals MOVAL and MOSTRT will be driven by the POD and will have Data Signal characteristics per table 4-19 of [10]. The remaining signals follow the signal type assignments as listed in table 4-19 of [10]. 31 All signal voltage levels are compatible with normal 3.3V CMOS levels. Table 6.4-B POD Signal Parameters Parameter Signal Unit Min Type Max Conditions Frequency CTX kHz 3088 Frequency CRX kHz 3088 Hold (THCTX) CTX ns 250 Note 1,2 Hold (THCRX) CRX ns 250 Note 1,2 Delay (tD) ETX, ITX, QTX ns 5 180 Note 1,2 Set-up (Tsu) DRX ns 10 From time signal reaches 90% of high level (rising) or 10% of high level (falling) until CRX mid-point transition Hold (Th) DRX ns 5 From CRX mid-point transition until signal reaches 10% of high level (rising) or 90% of high level (falling) Note1: Refer to Figure 6.4-2 POD Return Data Channel Timing Diagram. Note2: AC Timing is measured with Input/Output Timing Reference level at 1.5V. POD RDC Timing Diagram tD tD tHCTX tLCTX CTX from Host ETX ITX or QTX Figure 6.4-3 POD Output Timing Diagram 32 POD Input Timing Diagram CRX from Host DRX from Host tH tSU Figure 6.4-4 POD Input Timing Diagram 6.5 CPU Interface With OOB traffic included, the POD Module requires more bandwidth and connections on the CPU Interface than are supported by the Data Channel alone. Two communication paths shall share the same pins on the PC Card connector. Data Channel – This channel is compliant with the Command Interface protocol of CEA-679-C Part B, plus the interrupt mode extension. POD Module applications shall use this path when they require support from Host resources. Extended Channel – This second communication only includes physical and link layers. The purpose of the Extended Channel is to provide a communication path between the POD Module and the Host such that applications in one (e.g. Host, POD Module) can communicate with the headend via a link layer or modem function in the other (POD Module, Host respectively). Whereas the content and format of the messages for the Data Channel are well defined, the content and format of the messages for the Extended Channel are application specific. Depending on whether the POD Module or the Host is acting as the modem (or link device), the Extended Channel has a reversible function as described in figure 6.5-1 and figure 6.5-2. CPU Interface HEADEND POD HOST Extended OOB Channel Interface Data POD APPS Channel Figure 6.5-1 Modem-in-the-POD Module System Overview 33 CPU Interface HEADEND HOST Extended POD Channel Modem Data or OOB HOST APPS Channel Figure 6.5-2 Modem in-the-Host System View When the Data Channel is physically activated by CE1# (Card Enable 1) as defined by CEA-679-C Part B, the Extended Channel is enabled by CE2# (Card Enable 2), which is not used by CEA-679-C Part B. The Extended Channel includes the same type of registers as defined by CEA-679-C Part B for the Command Interface. The POD Module enables access to the Extended Channel after the initialization phase. At this time, the CE2# signal interpretation begins, and the Extended hardware interface registers can be read and written. The signals mentioned in the table below are all inputs for the POD Module. The registers depicted in figure 6.5-3 are part of the POD Module. Table 6.5-A Extended Interface Registers Extended Interface REG# CE2# CE1# A1 A0 IORD# IOWR# Reg. Standby mode X H H X X X X Ext_Data Write L L H L L H L Ext_Data Read L L H L L L H Ext_Command Write L L H L H H L Ext_Status_Reg. Read L L H L H L H Ext_Size (LS) Write L L H H L H L Ext_Size (LS) Read L L H H L L H Ext_Size (MS) Write L L H H H H L Ext_Size (MS) Read L L H H H L H The Extended Channel has its own data buffer that may have a different size than the Data Channel buffer. Since there are two physical channels (data channel and extended channel), the behavior of the interface is defined in such a way that when the Host sets the RS_flag on either channel, the interface is reset for both channels. Therefore, if the Host sets an RS_flag after detection of an error condition, it should set the RS-flag for both channels. 34 CPU Interface CE2# CE1# Ext_Data Register Data Register Ext_Control/Ext_Status Reg. Control/Status Reg. Ext_Size Register (LS) Size Register (LS) Ext_Size Register (MS) Size Register (MS) Ext_buffer Buffer Figure 6.5-3 Map of Hardware Interface Registers 6.5.1 Control Register Modification The following extension to the CEA-679-C Part B Command Interface shall be used in order to facilitate the interrupt mode over the Data Channel and the Extended Channel. The DA & FR bits of the Status Register should be gated onto the IREQ# line by two new Interrupt Enable bits for the Control Register: DAIE (bit 7) and FRIE (bit 6) respectively. The Control register now becomes: Table 6.5-B Control Register Definitions Bit 7 6 5 4 3 2 1 0 DAIE FRIE R R RS SR SW HC RS, SR, SW and HC retain their function, as described in CEA-679-C Part B specification. When set, DAIE allows any assertion of the DA bit in the Status register also to assert IREQ#. When set, FRIE allows any assertion of the FR bit in the Status register also to assert IREQ#. 35 When IREQ# is asserted, the Host shall first check the data channel, and then the extended channel to determine the source of the interrupt. 6.5.2 Status Register Modification The following extension to CEA-679-C Part B Status Interface shall be used in order to allow the POD to request the initialization process to occur. A new status bit called the Initialize Interface Request (IIR) is added to bit 4 of the Status Register to allow the POD Module to request that the interface be re-initialized. This bit exists in both the data channel and extended channel. When the POD module sets the IIR flag, the POD must also reset the IIR flag when the RS flag is set. Table 6.5-C Status Register Definitions bit 7 6 5 4 3 2 1 0 DA FR R IIR R R WE RE 6.6 Copy Protection on the FAT Channel Copy protection shall be provided for ‘high value’ content delivered in MPEG transport streams flowing from the POD to the Host. Such protection, including scrambling of content from POD to Host and authenticated delivery of messages through the CPU interface for permitted use of ‘high value’ content, is defined in the POD Copy Protection System specification (see ANSI/SCTE 41 2001). 6.7 Host-POD Interface Initialization This section defines the interface initialization procedure between the POD module and the Host. 6.7.1 Descriptions Initialization is a very general term. The following are definitions of the how the term initialization is used in this section. 6.7.1.1 Interface Initialization Definition (Informative) Any computing device must go through an initialization phase whenever a reset condition occurs, such as when initial power is applied, manual reset, or an unrecoverable software error condition occurs. What is covered in this section is the initialization of the interface between the host and the POD module. This is defined to be the interface initialization. 36 6.7.1.2 POD Personality Change Definition (Informative) The host and POD module shall initialize to the PCMCIA interface and will, at a particular point in the sequence, change to the POD interface. This point is defined as the POD Personality Change. 6.7.1.3 Reset Definition There are two possible resets that can occur in the POD interface, a hard reset (called PCMCIA reset) and a soft reset (called POD reset). 6.7.1.3.1 PCMCIA Reset The PCMCIA reset is defined to be one in which the Host shall bring the RESET signal to the POD module active. The interface shall revert to the PCMCIA interface including no longer routing the MPEG data stream through the POD module. Obviously this will cause problems to the viewer and should be avoided except in the case that a catastrophic failure has occurred in the POD module or in the interface between the Host and the POD module. 6.7.1.3.2 POD Reset The POD reset is defined to be when Host sets the RS bit in the control register anytime after the POD personality change has occurred. The Host shall set the RS bit in both the data channel and extended channel. The POD module shall detect whether the RS bit has been set in either channel and, if so, shall close all open sessions and transport connections and operation shall revert to that of just after the POD personality change. This reset shall prevent the change of routing of the MPEG data stream, thereby preventing the viewer from noticing any problems unless the video/audio stream being viewed is scrambled. Since the conditional access session is closed, the POD module shall cease descrambling the data stream until a new session is opened and the appropriate APDU transmitted to the POD module. The POD reset should occur when the Host detects an error in the POD module interface or the POD module has set the IIR flag (see below). 6.7.1.3.3 Initialize Interface Request Flag A status bit called the Initialize Interface Request (IIR) flag is included in bit 4 of the status register to allow the POD module to request that the interface be re- initialized. This bit exists in both the data channel and extended channel. When a condition occurs that the POD module needs to request an interface initialization, it shall set both IIR bits. Upon recognition of the IIR flag being set, the Host shall implement a POD reset. The POD module will clear the IIR flag when the RS bit is set. To further ensure reliable interoperability, POD modules shall be prohibited from sending LPDUs to the Host after setting the IIR bit and prior to recognizing an active RS bit. 37 6.7.1.3.4 Detailed POD Reset Operation The following flowchart (POD Reset Sequence) is the required implementation of the POD RS operation. LPDUs shall not be transmitted until the completion of the POD Reset sequence. 38 Host sets RS flag on Data Channel Host clears RS flags on Data Channel after a minimum of 40 usec Host sets RS flag on Extended Channel Host clears RS flags on Extended Channel after a minimum of 40 usec Data Channel No FR flag set? Yes Extended No Channel FR flag set? Yes Host executes Data Channel buffer size negotiation Host executes Extended Channel buffer size negotiation Figure 6.7-1 POD RS Operation 39 6.7.2 Configuration Option Register (Normative) The Configuration Option Register (COR) in the POD module is only accessible prior to the POD Personality Change (see appendix D.2). After the POD personality change, the COR is no longer available. Any relevant configuration data must be transferred via the data or extended channels and is not covered in this document. By writing the COR with the value defined by the Configuration-Table index byte, TPCE_INDX, from the CISTPL_CFTABLE_ENTRY tuple, the Host configures the module into the POD mode, thus causing the POD Personality Change. 6.7.3 Initialization Conditions There are 4 possible conditions that can cause the PCMCIA interface initialization phase. Please see section 6.7.4 of this document for detailed operation. They are: 1. The Host and POD module are powered up at the same time. After both have performed their internal initialization, then the interface initialization will begin. 2. Host has been powered and in a steady state. A POD module is then inserted. After the POD module has performed its internal initialization, the interface initialization phase will begin. 3. The Host has performed a reset operation for some reason (spurious signal, brownout, software problem, etc.) that has not caused the POD module to reset. The Host shall go through its initialization and then shall perform a PCMCIA reset on the POD module. After the POD module has performed its internal initialization, then the interface initialization shall begin. 4. The POD module has performed a reset operation for some reason (spurious signals, software problem, etc.) that has not caused the Host to reset. The Host shall incorporate the timeout detection and will thus detect a timeout and will perform a POD reset. 6.7.4 OOB Connection and Disconnection Behavior If a POD module is not connected to the Host, the OOB transmitter in the Host shall not operate. Upon connection of a POD module, the Host shall initiate, with the POD module, the low-level personality change sequence defined in Section 6.7.5 of this document. If successful, the Host shall then activate the OOB transmitter as instructed by the POD module. The OOB receiver in the Host shall be connected only to the POD module interface. 40 6.7.5 Low Level Step by Step POD Personality Change Sequence The POD Personality Change covers the detection of the POD module and the transition to the POD interface. A step-by-step operation for the interface initialization of the physical layer from the POD module’s viewpoint is defined below. 1. The POD module is inserted or already present in a Host. 2. Please refer to section 4.12.1 of “PC Card Standard, Volume 2 Electrical Specification, March 1997” for timing diagrams and specifications. • Power-up: Power is applied to the POD module with the RESET signal in a high-Z state for a minimum of 1 msec after VCC is valid (section 4.4.20 of the PC Card Electrical Specification). The POD module’s READY signal (pin 16) shall be inactive (logic 0) within 10 usec after the RESET signal goes inactive (logic 0), unless the POD module will be ready for access within 20 msec after RESET goes inactive. Note that at this time the POD module shall only operate as an unconfigured PCMCIA module. • PCMCIA Reset: The RESET signal goes active for a minimum of 10 usec. The POD module’s READY signal (pin 16) shall be inactive (logic 0) within 10 usec after RESET goes inactive (logic 0), unless the POD module will be ready for access within 20 msec after RESET goes inactive. Note that at this time the POD module shall only operate as an unconfigured PCMCIA module. 3. After a minimum of 20 msec after RESET goes inactive (section 4.4.6 of “PC Card Standard, Volume 2 Electrical Specification, March 1997”), the Host shall test the POD module’s READY signal. It shall not attempt to access the POD module until the READY signal is active (logic 1). 4. After the POD module has completed its PCMCIA internal initialization, it shall bring the READY signal active. At this time, all of the interface signals are defined by the PC Card interface standard for Memory Only Card interface (Table 4-1 of “PC Card Standard, Volume 2 Electrical Specification, March 1997”). The POD module must bring READY active within 5 seconds after RESET goes inactive (section 4.4.6 of “PC Card Standard, Volume 2 Electrical Specification, March 1997”). 5. The Host shall read the Configuration Information Structure (CIS) available in the attribute memory to determine that the device is POD module, what version is used, and any other pertinent information. This data is outlined in section A.5.6 of CEA-679-C Part B with the revisions in section 3.1 of this document. 6. The Host shall read all the CCST_CIF subtuples to verify that the SCTE interface ID number (STCI_IFN) is present (0x341). (Informative Note--If it is not present, this means that a different PCMCIA module has been inserted which is not 41 capable of operating with the SCTE format, however, it may be capable of operating as a NRSS-B module (CEA-679-C Part B).) 7. The Host shall then write into the COR the value read in TPCE_INDX. Following this write cycle, the Host shall switch the address signals A4-A8 to the OOB interface signals and the inband transport stream signals. The Host must implement a pull-down resistor on the ETX signal to prevent spurious operation of the transmitter. It must also implement a pull down resistor on the MCLKO signal to prevent invalid inband transport data from being received prior to the POD’s personality change. 8. At a minimum of 10 usec after the COR write signal, the POD module shall switch to the OOB interface signals and the inband transport stream signals. 9. In the event that the POD module requires additional initialization, it shall not bring the FR bit in the status register active until it is ready to begin communications with the Host. 10. This completes the physical link layer initialization. The following diagram helps define this operation. POD Personality Change Sequence Host SCTE POD Module RESET = 0 Host reset SCTE POD module reset Host completes internal initialization READY = 0 SCTE POD module completes internal initialization Waits until READY = 1 to begin POD READY = 1 Personality Change Sequence Read CCST_CIF Host reads CCST_CIF from SCTE Return hex341 POD module's attribute register Host enables POD interface in SCTE POD module by writing TPCE_INDX Write TPCE_INDX value to Configuration Option Register SCTE POD module changes from (COR) PCMCIA interface to POD interface. Host converts to POD interface (A4- Wait 10 usec min. A8 become OOB interface) FR =1 SCTE POD module OOB interface Begin upper layer initialization becomes active End of POD Personality Change Sequence Figure 6.7-2 POD Personality Change Sequence 42 6.7.6 Initialization Overview The following sections provide a description of the initialization procedure that shall occur between the POD module and the Host. 6.7.6.1 Physical Layer Initialization The physical layer initialization covers the buffer size negotiation of both the data and extended channels, and the initialization of the Host-pod transport layer and resource manager. The following shall be implemented in the order listed. 6.7.6.1.1 Data Channel Initialization The data channel is initialized by the Host writing a ‘1’ to the RS bit in the data channel Control/Status Register. After a minimum of 40 usec, the Host will write a ‘0’ to the RS bit in the data channel Control/Status Register. The POD module shall clear out any data in the data channel data buffer and configures the POD interface so it can perform the data channel buffer size negotiation protocol. When the POD module is ready, it sets the data channel FR bit to ‘1’. 6.7.6.1.2 Extended Channel Initialization The extended channel is initialized by the Host writing a ‘1’ to the RS bit in the extended channel Control/Status Register. After a minimum of 40 usec, the Host will write a ‘0’ to the RS bit in the extended channel Control/Status Register. The POD module shall clear out any data in the extended channel data buffer and configures the POD interface so it can perform the extended data channel buffer size negotiation protocol. When the POD module is ready, it sets the extended channel FR bit to ‘1’. 6.7.6.1.3 Data Channel Buffer Size Negotiation The Data Channel buffer size negotiation is covered in sections 5.5 and A.2.2.1.1 of CEA 679 Part B (reference [1]). There are 2 buffers which must be negotiated, the POD buffer for the data channel and the Host buffer for the data channel. According to Section A.2.2.1.1. of [1], the minimum buffer size for the POD module is 16 bytes and the minimum buffer size for the Host is 256 bytes. The maximum size for both is 65,535 bytes. Using the protocol called out in section A.2.2.1.1 of [1], the Host will read the POD module’s data channel buffer size, compare the result to its data channel buffer size, and write the smaller of the two buffer sizes to the POD module’s data channel. All future data channel transaction buffer sizes shall be at most this buffer size. Note that a data channel transaction’s buffer size can be smaller than the negotiated buffer size. 6.7.6.1.4 Extended Channel Buffer Size Negotiation 43 The Extended Channel buffer size negotiation is the same as the data channel. Note that the buffer sizes of the data and extended channels do not have to be the same. The minimum buffer size for the POD module is 16 bytes and the minimum buffer size for the Host is 256 bytes. The maximum size for both is 65,535 bytes. Using the protocol called out in section A.2.2.1.1 of [1], the Host will read the POD module’s extended channel buffer size, compare the result to its extended channel buffer size, and write the smaller of the two buffer sizes to the POD module’s extended channel. All future extended channel transaction buffer sizes shall be at most this buffer size. Note that a extended channel transaction’s buffer size can be smaller than the negotiated buffer size. 6.7.6.2 Link Connection The link connection (LPDU) is covered in section A.3.2 of [1]. No explicit initialization of the Link Layer is required. 6.7.6.3 Host-POD Transport Layer Connection The transport layer (TPDU) connection is covered in sections 7 and A.4.1 of [1]. Section A.4.1.3 of [1] shall be supported with the addition of the following: “TPDU chaining shall not be supported. The maximum length of the transport data shall be limited to 65,534 bytes.” The Host shall request to open a transport connection. The host shall open exactly one transport connection for each POD module. Table 6.7-A Create Transport Connection Syntax Value # of bits Mnemonic Create_T_C() { create_T_C_tag 82 8 uimsbf length_field() 01 8 uimsbf t_c_id XX 8 uimsbf } Where XX is defined by the Host. A transport connection ID (t_c_ID) value of zero is invalid. The POD module shall respond with the following. 44 Table 6.7-B Create Transport Connection Reply Syntax Value # of bits Mnemonic C_T_C_Reply (){ C_T_C_Reply_tag 83 8 Uimsbf length_field() 01 8 Uimsbf t_c_id XX 8 Uimsbf } A transport connection of ID “XX” now exists. 6.7.6.4 Resource Manager Session Initialization The resource manager session initialization is covered in section 7.2.6.1 of [1]. First, the module requests a session to be opened to the Host’s Resource Manager. Table 6.7-C Open Session Request Syntax Value # of bits Mnemonic Open_session_request(){ open_session_request_tag 91 8 uimsbf length_field() 04 8 uimsbf resource_identifier() 00010041 32 uimsbf } The Host shall respond with the following. Table 6.7-D Open Session Response Syntax Value # of bits Mnemonic Open_session_response(){ open_session_response_tag 92 8 uimsbf length_field() 07 8 uimsbf session_status 00* 8 uimsbf resource_identifier() 00010041 32 uimsbf session_nb YYYY 16 uimsbf } * - assumes that the resource manager is always available. 45 The session number for the resource manager is YYYY and is created by the Host. A session number (session_nb) of zero is invalid. The session is now created. 6.7.6.4.1 POD Resource Profile The POD resource profile is obtained by the Host and is covered in section 8.4.1.1 of [1]. Since the POD module is designed to be the only module in a Host, it shall not report any resources to the Host. First the Host’s Resource Manager sends a Profile Inquiry to the module. Table 6.7-E Profile Inquiry Syntax Value (hex) # of bits Mnemonic profile_inq(){ profile_inq_tag 9F8010 24 uimsbf length_field() 00 8 uimsbf } The POD shall respond with Table 6.7-F Profile Reply Syntax Value (hex) # of bits Mnemonic profile_reply(){ profile_reply_tag 9F8011 24 uimsbf length_field() 00 8 uimsbf } 6.7.6.4.2 Host Resource Profile The Host shall send a profile_changed APDU so that the POD module shall then perform a profile_inq APDU to which the Host shall respond with its profile_reply APDU. The Host sends: 46 Table 6.7-G Profile Changed Syntax Value (hex) # of bits Mnemonic profile_changed(){ profile_changed_tag 9F8012 24 uimsbf length_field() 00 8 uimsbf } to which the module replies with: Table 6.7-H Profile Inquiry Syntax Value (hex) # of bits Mnemonic profile_inq(){ profile_inq_tag 9F8010 24 uimsbf length_field() 00 8 uimsbf } to which the Host shall reply with: Table 6.7-I Profile Reply Syntax Value # of bits Mnemonic profile_reply(){ profile_reply_tag 9F8011 24 uimsbf length_field() N*4 8 uimsbf for(i=0; i POD open_mmi_req() 9F8820 MMI open_mmi_cnf() 9F8821 MMI close_mmi_req() 9F8822 MMI close_mmi_cnf() 9F8823 MMI 8.3.2 Open_mmi_req() & Open_mmi_cnf() The POD shall send an Open_mmi_req() APDU to the Host when it wants to initialize an MMI dialog. The Host shall reply with an Open_mmi_cnf() APDU to confirm the status of the request. For Host that supports more than one MMI dialog at the same time (multiple windows), the POD may send another Open_mmi_req() APDU, before it closes the previous one. 55 8.3.2.1 Open_mmi_req() Table 8.3-C Open MMI Request Object Syntax Syntax # of bits Mnemonic open_mmi_req(){ open_mmi_req_tag 24 uimsbf length_field() zero 8 0x00 url_length() 16 uimsbf For (I=0; I < url_length; I++) { url_byte 8 uimsbf } } Where: url_byte Each url_byte is one octet of a parameter that points to a HTML page in the POD and that needs to be queried by the Host display application using the Server_query() APDU when the MMI dialog will be opened 8.3.2.2 Open_mmi_cnf() Table 8.3-D Open MMI Confirm Object Syntax Syntax # of bits Mnemonic Open_mmi_cnf(){ open_mmi_cnf_tag 24 Uimsbf length_field() dialog_number() 8 Uimsbf open_status() 8 Uimsbf } where: open_status The status of the requested MMI dialog as defined in the following table. 56 Table 8.3-E Open Status Values Open_Status Value (hex) OK- Dialog Opened 00 Request Denied – Host Busy 01 Request Denied – Display Type not 02 Supported Request Denied – No Video Signal 03 Request Denied – No more 04 Windows Available Reserved 05-FF dialog_number A number supplied by the Host issued from an 8-bit cyclic counter that identifies each Open_mmi_cnf() APDU and allows the POD to close the MMI dialog. 8.3.3 Close_mmi_req() & Close_mmi_cnf() The POD shall send a Close_mmi_req() APDU to the Host to close the MMI dialog previously opened with an Open_mmi_req() APDU. The Host shall reply with a Close_mmi_cnf() object to report the status of the close operation. The Host may send a Close_mmi_cnf() without the POD having sent a Close_mmi_req() to inform about a close operation performed by the Host. 8.3.3.1 Close_mmi_req() Table 8.3-F Close MMI Request Object Syntax Syntax # of bits Mnemonic close_mmi_req(){ close_mmi_req_tag 24 Uimsbf length_field() dialog_number() 8 Uimsbf } where: dialog_number The number of the MMI dialog provided by the Close_mmi_req(). 57 8.3.3.2 Close_mmi_cnf() Table 8.3-G Close MMI Confirm Object Syntax Syntax # of bits Mnemonic close_mmi_cnf(){ close_mmi_cnf_tag 24 uimsbf length_field() dialog_number() 8 uimsbf } where: dialog_number The number of the MMI dialog provided by the Close_mmi_req(). 8.4 Application Information 8.4.1 Introduction The Application Information resource resides in the Host. The POD shall only open one session to it after it has completed the profile inquiry operation with the Resource Manager resource (see Section 6.7.6.4). The Application Information resource provides: • Support to the Host to expose its display characteristics to the POD • Support to the POD to expose its applications to the Host • Support to the POD to deliver HTML pages to the Host The Application Information resource has been changed to type 2 to reflect the changes listed in this section as compared to CEA-679-C. During initialization, the POD module opens a session to the Application Information resource on the Host. This session shall remain open during normal operation. Table 8.4-A Application Information Resource Resource Class Type Version Identifier (hex) Application_info 2 2 1 00020081 The Application Information resource includes four APDUs as described in the following table: 58 Table 8.4-B Table Application Information Objects Apdu_tag Tag value Resource Direction (hex) Host <-> POD application_info_req() 9F8020 Application Info application_info_cnf() 9F8021 Application Info server_query() 9F8022 Application Info server_reply() 9F8023 Application Info The method for initiating an application is beyond the scope of this document. 8.4.2 Application_info_req() & Application_info_cnf() The Host shall send, as soon as the POD has opened the Application Information resource, an Application_info_req() APDU to the POD to advertise its display capabilities. The POD shall reply with an Application_info_cnf() APDU to describe its supported applications. 59 8.4.2.1 Application_info_req() Table 8.4-C Application Information Request Object Syntax Syntax # of bits Mnemonic Application_info_req() { Application_info_req_tag 24 uimsbf length_field() Display_rows 16 uimsbf Display_columns 16 uimsbf Vertical_scrolling 8 uimsbf Horizonal_scrolling 8 uimsbf Multi_window 8 uimsbf Data_entry_support 8 uimsbf HTML_support 8 uimsbf if (HTML_support==1) then { Link_support 8 uimsbf Form_support 8 uimsbf Table_support 8 uimsbf List_support 8 uimsbf Image_support 8 uimsbf } } Where: Display_rows This field defines the number of rows of the display device. Display_columns This field defines the number of columns of the display device. Columns are one pixel in width. Vertical_scrolling This field defines if the Host display application supports vertical scrolling (Vertical_scrolling = 1), or not (Vertcal_scrolling = 0). Default value is 0. 60 Horizontal_scrolling This field defines if the Host display application supports horizontal scrolling (Horizontal_scrolling = 1), or not (Horizontal_scrolling =0). Default value is 0. Multi_window This field is deprecated and shouldbe set to zero. Data_entry_support This field defines the data entry capability of the Host, according to the following table. The POD may use this information in creating HTML pages. Table 8.4-D Data Entry Support Values Data_entry_support Value (hex) None 0 Last/Next 1 Numeric Pad 2 Alpha Keyboard with Mouse 3 Reserved 4-FF HTML_support This field defines the HTML support capability of the Host display application, according to the following table. All Hosts shall support as a minimum the Baseline HTML profile. The Baseline HTML profile is defined in Appendix C. Table 8.4-E HTML Support Values HTML_support Value (hex) Baseline Profile 0 Custom Profile 1 HTML 3.2 2 XHTML 1.0 3 Reserved 4-FF Link_support This field defines if the Host display application supports single or multiple Links, according to the following table. 61 Table 8.4-F Link Support Values Link_support Value (hex0 One link 0 Multiple links 1 Reserved 2-FF Form_support This field defines if the Host display application supports Forms, according to the following table. Table 8.4-G Form Support Values Form_support Value (hex) None 0 HTML 3.2 w/o POST method 1 HTML 3.2 2 Reserved 3-FF Table_support This field defines if the Host display application supports Tables, according to the following table. 62 Table 8.4-H Table Support Values Table_support Value (hex) None 0 HTML 3.2 1 Reserved 2-FF List_support This field defines if the Host display application supports Lists, according to the following table. Table 8.4-I List Support Values List_support Value (hex) None 0 HTML 3.2 w/o Descriptive Lists 1 HTML 3.2 2 Reserved 3-FF Image_support This field defines if the Host display application supports Images, according to the following table. Table 8.4-J Image Support Values Image_support Value (hex) None 0 HTML 3.2 – PNG Picture under 1 RGB w/o resizing HTML 3.2 2 Reserved 3-FF 63 8.4.2.2 Application_info_cnf() Table 8.4-K Application Information Confirm Object Syntax Syntax # of bits Mnemonic Application_info_cnf() { application_info_cnf_tag 24 uimsbf length_field() pod_manufacturer_id 16 uimsbf pod_version_number 16 uimsbf number_of_applications 8 uimsbf for (I=0; I POD CA_update() 9F8034 Conditional Access Support 8.6.1 CA_update() The POD Module shall use the CA_update() object to inform the Host when CA information for the currently tuned program has changed. Here CA_PMT(query) refers to a CA_PMT APDU with its ca_pmt_cmd_id parameter set to “query”. Note that CA_UPDATE shall always reference the service to which the host is currently tuned. This is the last service for which a CA_PMT() was sent from the Host to the POD. The different APDU tag prevents any confusion between CA_PMT_reply and CA_update APDUs during CA_PMT (query)/CA_PMT_reply exchanges. CEA-679- C Part B states that a CA_PMT (query) is sent by the Host to determine which conditional access resource can decrypt the specified service when more than one 71 conditional access resource is present. The reader should note that some conditional access implementations may send a CA_PMT (query) each time a service is tuned and with only one POD installed in the Host. While this behavior may differ from that defined in CEA-679-C Part B, it is done to determine if the currently tuned service can be descrambled by the POD. The POD may respond with a CA_PMT_reply specifying “descrambling possible” or “descrambling not possible”. The Host would respond to a CA_PMT_reply (descrambling_possible) with a CA_PMT (ok_descrambling) to the POD. Table 8.6-C Conditional Access Support CA_update Object Syntax Syntax # of Mnemonic bits CA_update() { ca_update_tag 24 Uimsbf Length_field() Program_number 16 Uimsbf Reserved 2 Bslbf Version_number 5 Uimsbf Current_next_indicator 1 Bslbf CA_enable_flag 1 Bslbf if (CA_enable_flag==1) CA_enable /* at program level */ 7 Uimsbf else if (CA_enable_flag==0) reserved 7 Bslbf for (i=0; I POD OOB_TX_tune_req() 9F8404 Host Control OOB_TX_tune_cnf() 9F8405 Host Control OOB_RX_tune_req() 9F8406 Host Control OOB_RX_tune_cnf() 9F8407 Host Control inband_tune_req() 9F8408 Host Control inband_tune_cnf() 9F8409 Host Control 8.8.1 OOB_TX_tune_req() & OOB_TX_tune_cnf() The POD Module shall use the OOB_TX_tune_req() object to set up the Host’s RF Transmitter. The Host shall respond with the OOB_TX_tune_cnf() object to the OOB_TX_tune_req() request. Table 8.8-C OOB TX Tune Request Object Syntax Syntax # of bits Mnemonic OOB_TX_tune_req() { OOB_TX_tune_req_tag 24 Uimsbf Length_field() RF_TX_frequency_value 16 Uimsbf RF_TX_power_level 8 Uimsbf RF_TX_rate_value 8 Uimsbf } . 75 Table 8.8-D RF TX Frequency Value Bit 7 6 5 4 3 2 1 0 Frequency (MS) Frequency (LS) RF_TX_frequency_value – This field defines the frequency of the RF Transmitter, in kHz. Table 8.8-E RF TX Power Level Bit 7 6 5 4 3 2 1 0 RF Power Level RF_TX_power_level - Power level of the RF Transmitter, in units of 0.5dBmV. The value 0x00 shall correspond to an output level of 0 dBmV. Table 8.8-F RF TX Rate Value Bit 7 6 5 4 3 2 1 0 Rate Reserved RF_TX_rate_value • Rate – Bit rate. 00 = 256 kbps 01 = 2048 kbps 10 = 1544 kbps 11 = 3088 kbps Table 8.8-G OOB TX Tune Confirm Object Syntax Syntax # of bits Mnemonic OOB_TX_tune_cnf() { OOB_TX_tune_cnf_tag 24 Uimsbf Length_field() Status_field 8 Uimsbf } • Status_field – This field returns that status of the OOB_TX_tune_req(). If the request was granted and the RF Transmitter set up to the desired configuration, Status_field will be set to 0x00. . If the Host is a unidirectional Host, Status_field shall be set to 0x01; the POD shall not attempt to perform RF transmit operations 76 after receiving an OOB_TX_tune_req() with Status_field set to 0x01. If any of the parameters passed to the Host are outside of its capability, then the Host shall transmit the OOB_TX_tune_req() with Status_field set to 0x03. Otherwise it will be set to one of the following values: Table 8.8-H Status Field Values for OOB TX Tune Confirm Status_field Value (hex) Tuning granted 00 Tuning Denied – RF Transmitter not physically available 01 Tuning Denied – RF Transmitter busy 02 Tuning Denied – Invalid Parameters 03 Tuning Denied – Other reasons 04 Reserved 05-FF 8.8.2 OOB_RX_tune_req() & OOB_RX_tune_cnf() The POD Module shall use the OOB_RX_tune_req() object to set up the Host’s RF Receiver. The Host shall respond with the OOB_RX_tune_cnf() object to the OOB_RX_tune_req() request. The OOB_RX_tune_cnf APDU should only be transmitted after either the requested frequency has been tuned and acquired (“tune time”), or 500msec has elapsed since receiving the Request, whichever comes first. Table 8.8-I OOB RX Tune Request Object Syntax Syntax # of bits Mnemonic OOB_RX_tune_req() { OOB_RX_tune_req_tag 24 Uimsbf Length_field() RF_RX_frequency_value 16 Uimsbf RF_RX_data_rate 8 Uimsbf } • RF_RX_frequency_value – This field defines the frequency of the RF Receiver, in MHz. (Frequency = value * 0.05 + 50 MHz.) 77 Table 8.8-J RF RX Frequency Value Bit 7 6 5 4 3 2 1 0 0 0 0 0 0 Value (MS) Value (LS) RF_RX_coding_value – This field defines the RF Receiver characteristics. Table 8.8-K RF RX Data Rate Bit 7-6 5 4 3 2 1 0 Rate 0 0 0 0 0 Spec • Rate – Bit rate = 2048 kbps when Rate = 00 or 01 1544 kbps when Rate = 10 3088 kbps when Rate = 11 • Spec – Spectrum is non-inverted when Spec=0 and inverted when Spec=1 Table 8.8-L OOB RX Tune Confirm Object Syntax Syntax # of bits Mnemonic OOB_RX_tune_cnf() { OOB_TX_tune_cnf_tag 24 Uimsbf Length_field() Status_field 8 Uimsbf } • Status_field – This field returns that status of the OOB_RX_tune_req(). If the request was granted and the RF receiver set up to the desired configuration, Status_field will be set to 0x00. Otherwise it will be set to one of the following values: 78 Table 8.8-M Status Field Values for OOB RX Tune Confirm Status_field Value (hex) Tuning granted 00 Tuning Denied – RF Receiver not physically available 01 Tuning Denied – RF Receiver busy 02 Tuning Denied – Invalid Parameters 03 Tuning Denied – Other reasons 04 Reserved 05-FF 8.8.3 inband_tune_req() (Normative) The inband_tune_req() APDU allows for the POD module to request the Host to tune the inband QAM tuner. The APDU will allow support of tuning to either a source_id or a frequency with the modulation type. Table 8.8-N Inband Tune Request Object Syntax Syntax # of bits Mnemonic Inband_tune_req() { Inband_tune_tag 24 uimsbf length_field() tune_type 8 uimsbf if(tune_type == 0){ source_id 16 uimsbf } else if (tune_type == 1) { tune_frequency_value 16 uimsbf modulation_value 8 uimsbf } } tune_type – Determines the definition of the tune_frequency_value. 79 Table 8.8-O Tune Type Values Value (hex) Type 00 Source ID 01 Frequency 02-FF Reserved source_id – When tune_type = 0, the source_id is a 16 bit unsigned integer in the range of 0x0000 to 0xFFFF that identifies the programming source associated with the virtual channel on a system wide basis. IN this context, a source is one specific source of video, text, data, or audio programming. For the purposes of referencing virtual channels to the program guide database, each such program source is associated with a unique value of source_id. The source_id itself may appear in an IPG database, where it tags entries to associate them with specific services. The value zero for source_id, if used, shall indicate the channel is not associated with a source_id. tune_frequency_value – When tune type = 1, tune_frequency_value contains the frequency for the Host to tune. The frequency is calculated by multiplying tune_frequency_value by 0.05 MHz (50 KHz resolution). Table 8.8-P Tune Value Bit 7 6 5 4 3 2 1 0 MSB Value (MS) LSB Value (LS) modulation_value – When tune type = 1, modulation_value sets the type of modulation for the inband tuner. 80 Table 8.8-Q Modulation Value Value Type (hex) 00 QAM-64 01 QAM-256 02-FF Reserved 8.8.4 inband_tuning_cnf (Normative) After the Host has received the inband_tuning, it will respond with the following APDU. Table 8.8-R Inband Tuning Confirm Object Syntax Syntax # of bits Mnemonic Inband_tuning_cnf() { inband_tuning_cnf_tag 24 uimsbf length_field() tune_status 8 uimsbf } tune_status – The Host response to the inband_tuning APDU. 81 Table 8.8-S Tune Status Values Value Source Comment (hex) 00 Tuning accepted Frequency, modulation type accepted 01 Invalid frequency Host does not support this frequency. 02 Invalid modulation Host does not support this modulation type. 03 Hardware failure Host has hardware failure. 04 Tuner busy Host is not relinquishing control of the tuner. 05-FF Reserved 8.9 Extended Channel Support For purposes of the Extended Channel, the device (POD Module or Host) that provides the physical communications link to the headend is referred to as the “link device.” The POD Module is the link device for the QPSK modem; the Host is the link device for the High Speed Host Modem. The Extended Channel Support resource shall be created to register the interactive applications that expect to send and receive data to and from the Extended Channel. All Hosts are required to provide the hardware necessary to support a QPSK downstream out-of-band channel for the POD. The POD shall forward data received on this channel to the Host as appropriate through one or more data flows requested by the Host. In some cases, the POD will terminate data received on the QPSK downstream OOB channel by using it itself (for example EMMs). In other cases, it may perform a filtering function and discard data known to be of no interest to the Host. Supported system architectures imply two different ways of using the Extended Channel Support resource. • The application is in the Host and the data are transferred to/from the headend via the QPSK modem. • The application is in the POD Module and the data are transferred to/from the headend via the Host’s High Speed Host Modem. This resource has two versions. Version 1 of this resource is required for Hosts that do not have an embedded High Speed Host (DOCSIS) Modem and version 2 of this resource is required for Hosts that do have an embedded High Speed Host (DOCSIS) Modem. Version 2 of this resource includes support for all of the objects defined by version 1. 82 Table 8.9-A Extended Channel Resource Resource Class Type Version Identifier (hex) Extended_Channel 160 1 1 00A00041 Extended_Channel 160 1 2 00A00042 This creation includes the following objects: Table 8.9-B Extended Channel Objects Tag Direction value Host POD Apdu_tag Resource (Version) (hex) Host POD Modem Modem new_flow_req() 9F8E00 Extended Channel Support (1) new_flow_cnf() 9F8E01 Extended Channel Support (1) delete_flow_req() 9F8E02 Extended Channel Support (1) delete_flow_cnf() 9F8E03 Extended Channel Support (1) Lost_flow_ind() 9F8E04 Extended Channel Support (1) Lost_flow_cnf() 9F8E05 Extended Channel Support (1) inquire_DSG_mode() 9F8E06 Extended Channel Support (2) Set_DSG_mode() 9F8E07 Extended Channel Support (2) DSG_packet_error() 9F8E08 Extended Channel Support (2) 8.9.1 New_flow_req() & New_flow_cnf() The application shall use the new_flow_req() object to register a new flow with the link device. The link device shall return a new_flow_cnf() object in response to the new_flow_req() request. 83 Table 8.9-C New Flow Request Object Syntax Syntax # of bits Mnemonic new_flow_req() { new_flow_req_tag 24 uimsbf length_field() service_type 8 uimsbf if (service_type == mpeg_section) { Reserved 3 bslbf Pid 13 uimsbf } if (service_type == ip_u) { mac_address 48 uimsbf option_field_length 8 uimsbf for (i=0; i” The request sub-option vector is a list of sub- options (within option 43) to be returned to client by the server upon reply to the request. None defined. 2 “CARD” Device type of the entity making the DHCP request. 3 “ECM:ESTB:CARD” Indicates that a POD Module is making a request via the eCM’s DOCSIS return channel 4 Serial Number of POD Module. If Serial Number is not available, then other unique “” identifier (other than MAC Address) may be utilized 5 ““ Hardware version number of POD Module 6 ““ Firmware version number of POD Module 7 ““ Boot ROM version number of POD Module 8 A 6-octet, hexadecimal-encoded, vendor- specific Organization Unique Identifier (OUI) e.g. “0204DF” that may match the OUI in the embedded cable modem’s MAC address. 9 e.g. “XYZ-CARD-001” Vendor model number of POD Module 51 e.g. “XYZ Corporation” Vendor name 52 “yyyyyy” POD Module capability using the encoding format per DOCSIS specification. Since there is no standard/required capability identification, Conditional Access vendor must provide documentation on the supported capability. 53 e.g. “000-01234-56789-000” Conditional Access Vendor specific device (example is unit address of identification Motorola POD Module) 54 e.g., “00AA11BB22CC33DD” 64 bit Card_ID as specified in POD Module X.509 certificate 91 Table 8.9-I POD Module DHCP Vendor Class Indentifier (Option 60) Encoding Option Value Description 60 “OpenCable 2.0” OpenCable Version 8.9.2 Delete_flow_req() & Delete_flow_cnf() The interactive application shall use the Delete_flow_req() object to delete a registered data flow. The link device shall respond with the Delete_flow_cnf() object to the Delete_flow_req() request. Table 8.9-J Delete Flow Request Object Syntax Syntax # of bits Mnemonic Delete_flow_req() { Delete_flow_req_tag 24 Uimsbf Length_field() FLOW_ID 24 Uimsbf } Table 8.9-K Delete Flow Confirm Object Syntax Syntax # of bits Mnemonic Delete_flow_cnf() { Delete_flow_cnf_tag 24 Uimsbf Length_field() FLOW_ID 24 Uimsbf Status_field 8 Uimsbf } • Status_field – This field returns the status of the Delete_flow_req(). If the request was granted and the flow deleted, the Status_field will be set to 0x00. Otherwise it will be set to one of the following values: 92 Table 8.9-L Status Field for Delete Flow Status_field Value (hex) Request Granted 0x00 Reserved 0x01-0x02 Request Denied – Network unavailable or not responding 0x03 Request Denied – Network busy 0x04 Request Denied – FLOW_ID does not exist 0x05 Request Denied – Not authorized 0x06 Reserved 0x07-0xFF 8.9.3 Lost_flow_ind() & Lost_flow_cnf() A link device shall indicate that a registered data flow has been lost by issuing the Lost_flow_ind() object. The application shall respond with the Lost_flow_cnf() object in response to the Lost_flow_ind() object. Table 8.9-M Lost Flow Indication Object Syntax Syntax # of bits Mnemonic Lost_flow_ind() { Lost_flow_ind_tag 24 Uimsbf Length_field() FLOW_ID 24 Uimsbf Reason_field 8 Uimsbf } • Reason_field – This field returns the reason the flow was lost. It will be set to one of the following values: 93 Table 8.9-N Reason Field Values for Lost Flow Indication Reason_field Value (hex) Unknown or unspecified reason 0x00 IP address expiration 0x01 Network down or busy 0x02 Lost or revoked authorization 0x03 Reserved 0x04-0xFF Table 8.9-O Lost Flow Confirm Object Syntax Syntax # of bits Mnemonic Lost_flow_cnf() { Lost_flow_cnf_tag 24 Uimsbf Length_field() FLOW_ID 24 Uimsbf Status_field 8 Uimsbf } Status_field – This field returns the status of the Lost_flow_ind(). If the indication was acknowledged, the Status_field will be set to 0x00. Otherwise it will be set to one of the following values: Table 8.9-P Status Field Values for Lost Flow Confirm Status_field Value (hex) Indication Acknowledged 0x00 Reserved 0x01-0xFF 8.9.4 inquire_DSG_mode(), set_DSG_mode(), & DSG_packet_error() Version 2 of the Extended Channel Support Resource adds the following three messages: • inquire_DSG_mode () - The Host can inquire of the POD the preferred operational mode for the network, either OOB mode or DSG mode. • set_DSG_mode () - The POD can inform the Host of the preferred operational mode for the network, either OOB mode or DSG mode. 94 • DSG_packet_error () - The POD can inform the Host of errors that occur in receiving DSG packets. The Host shall use the inquire_DSG_mode () object to inquire the preferred operational mode for the network. Table 8.9-Q Inquire DSG Mode Object Syntax Syntax # of bits Mnemonic inquire_dsg_mode () { inquire_dsg_mode_tag 24 uimsbf length_field() } The POD shall use the set_DSG_mode () object to inform the Host of the preferred operational mode for the network. This message is sent in response to the inquire_DSG_mode () message or it may be sent as an unsolicited message to the Host. The method by which the POD determines the preferred operational mode is proprietary to the CA/POD system vendor. 95 Table 8.9-R Set DSG Mode Object Syntax Syntax # of bits Mnemonic set_dsg_mode () { set_dsg_mode_tag 24 uimsbf length_field() operational_mode 8 uimsbf if (operation_mode==dsg_mode or operation_mode==dsg_one-way_mode) { number_mac_addresses 8 uimsbf for (i=0; i< number_mac_addresses; i++) { dsg_mac_address 48 uimsbf } remove_header_bytes 16 uimsbf } } Operational_Mode – This field defines the preferred operational mode of the network. Operational_mode Value OOB_mode 0x00 DSG_mode 0x01 DSG_One-Way_mode 0x02 Reserved 0x03-FF OOB_mode - In this mode, the reverse transmitter is under the control of the POD module through the use the OOB_TX_tune_req () message. The Host must respond to these messages by tuning the reverse transmitter to the requested frequency and coding value (bit-rate and power level). The POD module uses the OOB-RDC for returning data to the cable headend. DSG_mode - In this mode, the reverse transmitter is under the control of the Host for DOCSIS functionality. If the POD attempts to command the reverse transmitter with the OOB_TX_tune_req() message while the Host is operating in the DSG mode the Host will deny the tune request with a Tuning Denied – RF Transmitter busy status. 96 DSG_One-Way_mode - In this mode, the reverse transmitter must be disabled for both the OOB channel and the DOCSIS return channel. This mode could be used in one-way cable systems and for network diagnosis in two-way cable systems. A default operational mode must be utilized when the Host and/or POD is unable to obtain the preferred operational mode. There are two potential default conditions that must be addressed. In particular: a. Either the Host or the POD may not support the Inquire_DSG_mode () and Set_DSG_mode () messages. b. The POD may not have acquired the preferred operational mode from the network due to possible network errors. To insure backward compatibility in case (a) above, an Advanced Host will initialize in the default operational mode of OOB_mode. In case (b), the POD Module shall instruct the Host that the preferred operational mode of OOB_mode. If the operational mode is either DSG_mode or One-Way_Mode, the POD Module may provide up to eight Ethernet MAC addresses and the number of header bytes to be removed from the DSG tunnel packets. In DSG or one-way mode, the Host must filter IP packets whose Ethernet destination address match any of the DSG_MAC_Adddresses specified, remove the specified number of header bytes from these packets, and generate a serialized bit-stream across the DRX pin. Number_MAC_Addresses – The number of DSG MAC Addresses allocated by the CA/POD provider to carry DSG tunnels. A maximum of eight DSG tunnels per CA/POD provider are allowed. DSG_MAC_Address– The Ethernet MAC addresses allocated by the CA/POD provider to carry the number of DSG tunnels specified by Number_MAC_Addresses. Remove_Header_Bytes – The number of bytes to be removed from the DSG tunnel packets before generating a serial bit-stream. A value of zero implies that no header bytes be removed. 97 Table 8.9-S DSG packet_error Object Syntax Syntax # of bits Mnemonic DSG_packet_error () { DSG_packet_error_tag 24 uimsbf length_field() error_status 8 uimsbf } DSG_packet_error () - The POD can inform the Host of errors that occur in receiving DSG packets. The Error_status indicates the type of error that occurred. Error_status Value Byte_count_error 0x00 Reserved 0x01-FF Byte_count_error – The POD did not receive the same number of bytes in the DSG packet as was signaled by the Host. 8.10 Generic IPPV Support NOTE--The Generic IPPV Support resource is being deprecated, though it may still be in use; the preferred approach for supporting IPPV is to use the appropriate OCAP application. The Generic IPPV Support resource provides Conditional Access information (in the POD Module) to the navigation application (in the Host). This allows subscriber access to Pay Per View functions such as purchase, cancellation and history review. The desired result is better subscriber recognition and increased IPPV usage. If reported by the Host as an available resource and the POD module implements a Generic IPPV application, the POD module application shall create a session to the Generic IPPV resource to allow the Host to receive information on and purchase IPPV events. ISO-8859-1 shall be used for the coding of text. 98 Table 8.10-A Generic IPPV Support Resources Resource Class Type Version Identifier (hex) Generic IPPV Support 128 2 1 00800081 This creation includes the following objects: Table 8.10-B Generic IPPV Support Objects Apdu_tag Tag value Resource Direction (hex) Host <-> POD Program_req() 9F8F00 Generic IPPV Support Program_cnf() 9F8F01 Generic IPPV Support Purchase_req() 9F8F02 Generic IPPV Support Purchase_cnf() 9F8F03 Generic IPPV Support Cancel_req() 9F8F04 Generic IPPV Support Cancel_cnf() 9F8F05 Generic IPPV Support History_req() 9F8F06 Generic IPPV Support History_cnf() 9F8F07 Generic IPPV Support 8.10.1 Program_req() & Program_cnf() The Host’s navigation application shall use the Program_req() object to request the POD Module’s CA information on a particular program. The POD Module shall respond with the Program_cnf() object to the Program_req() request. 99 Table 8.10-C Program Request Object Syntax Syntax # of bits Mnemonic program_req() { program_req_tag 24 uimsbf length_field() transaction_id 8 uimsbf transport_stream_id 16 uimsbf program_number 16 uimsbf source id 16 uimsbf event_id 16 uimsbf current_next indicator 8 uimsbf reserved 7 current_next 1 uimsbf program_info_length 8 for (i=0; i < program_info_length; i++) { ca_descriptor() /* ca descriptor at program level*/ } } transaction_id – This field is a unique number generated by the Host to uniquely identify this transaction. The associated Program_cnf() message will include this Transaction_ID value. Hosts shall maintain a Transaction_ID counter and increment it by 1 (mod 256) for each new transaction. transport_stream_id - A 16-bit unsigned integer field, in the range 0x0000 to 0xFFFF, that represents the MPEG-2 Transport Stream ID associated with the program being requested. program_number - A 16-bit unsigned integer number indicating the program that is being requested. source_id – A 16-bit unsigned integer number indicating the source_id of the program that is being requested. (This text should be inserted after the program_number field description.) event_id – A 16-bit unsigned integer number specifying the event requested on the specified program_number. If the Event_ID is unknown, this field shall be set to all 0s. 100 current_next– Used to specify the current or next event on the specified program_number. Only relevant when Event_ID is set to 0. When not set, indicates that the current event is being requested. When set, indicates that the next event is requested. program_info_length, CA descriptor – These fields shall be used by the Host to provide the POD Module with every program level CA descriptor of this MPEG program. The CA descriptor shall be, extracted from the PMT table by the Host navigation application. 101 Table 8.10-D Program Confirm Object Syntax Syntax # of bits Mnemonic Program_cnf() { Program_cnf_tag 24 Uimsbf Length_field() Transaction_ID 8 Uimsbf Status_field 8 Uimsbf If (Status_field == 0) { Option_nb 8 Uimsbf For (Option_ID=1; I <= Option_nb; Option_ID++) { Purchase_type 8 Uimsbf Purchase_price 16 Uimsbf Purchase_validation 8 Uimsbf Expiration_date 32 Uimsbf Program_start_time 32 Uimsbf Initial_Free_preview_duration 16 Uimsbf Anytime_free_preview_duration 16 Uimsbf Title_length 8 Uimsbf for (J=0; J < Title_length; J++) { Title_txt 8 Uimsbf } Text_length 8 Uimsbf for (J=0; J < Text_length; J++) { Text_txt 8 Uimsbf } Descriptor_length 16 Uimsbf for (K=0; K < Desc_length; K++) { Descriptor() Uimsbf } var } } } 102 Status_field – This field returns the status of the Program_req(). If the POD Module can provide the requested information on the pointed event then Status_field shall be set to 0x00. Otherwise it will be set to one of the following values. Table 8.10-E Status Field Values for Program Confirm Status_field Value (hex) Request Granted 00 Request Denied – POD module busy 01 Request Denied – Unknown Event 02 Reserved 03-FF • Option_nb – This field defines the number of options under which a particular event can be purchased • Purchase_type – This field characterizes how the event may be purchased Table 8.10-F Purchase Type Values for Program Confirm Purchase_type Value (hex) Viewing Only 00 Viewing and Right to Copy Once 01 Viewing and Right to Copy Unlimited 02 Subscription 03 Purchased for Viewing Only 04 Purchased with Viewing and Right to Copy Once 05 Purchased with Viewing and Right to Copy Unlimited 06 Un-purchasable 07 Reserved 08-FF Viewing only - This program may be purchased for viewing only, without the right to make any copies, as defined by the operator. NOTE: Through private agreements between a cable operator and content providers, the cable operator determines the pricing and right to copy options appropriate for his market. Viewing and Right to Tape Copy Once - This program may be purchased for viewing and with the right to copy the analog video output and make one copy as defined by the operator. Viewing and Right to Copy Unlimited - This program may be purchased for viewing and with the right to make unlimited copies as defined by the operator. 103 Subscription - This program is a subscription event, and is not purchasable as an IPPV event. Purchased for Viewing Only -This program has already been purchased with viewing rights only, and without the right to make any copies as defined by the operator. Purchased with Viewing and Right to Tape Copy Once -This program has already been purchased for viewing with the right to tape and right to make one copy as defined by the operator. Purchased with Viewing and Right to Copy Unlimited – This program has already been purchased for viewing with the right to make unlimited copies as defined by the operator. Un-purchasable - This is not a purchasable program. Reserved – These values are currently undefined, but are reserved for future IPPV purchase options, including digital copyrights. These values may be expanded as they are defined. Purchase_price – This 2-byte field provides event pricing information. The event price is given by the Denomination unit multiplied by the Value. For example, if the Denomination unit is 5 cents, and the Value is 79, the price would be $3.95. Table 8.10-G Purchase Price for Program Confirm Bit 7 6 5 4 3 2 1 0 Denomination unit in cents (MS) Value (LS) Purchase_validation – This parameter defines the level of validation the POD Module expects to validate the purchase. 104 Table 8.10-H Purchase Validation Value for Program Confirm Purchase_validation Value (hex) No CA validation required 00 PIN Code required for Purchase transaction 01 PIN Code required for Cancel transaction 02 PIN Code required for History transaction 03 PIN Code required for Purchase and Cancel transactions 04 PIN Code required for Purchase and History transactions 05 PIN Code required for Purchase, Cancel, History transactions 06 Reserved 07-FF • Expiration_date – This field contains the expiration time of the event. It is a 32- bit unsigned integer quantity representing the expiration time as the number of seconds since 12 am, January 6th 1980. • Program_start_time: A 32 bit unsigned integer, defining the start time of the program, in GPS seconds since 12 AM January 6th, 1980. • Initial_free_preview_duration: A 16-bit unsigned integer, defining the duration of the free preview period. The duration is measured from the program_start_time. • Anytime_free_preview duration: A 16-bit unsigned integer, defining the duration of the Anytime_free_preview. • Title_length, Title_txt – These fields allow the POD Module to provide a purchase option title. • Text_length, Text_txt – These fields allow the POD Module to provide a purchase option text. • Desc_length – A 16-bit unsigned integer that indicates the length of the block of optional descriptors to follow. If no descriptors are present, the length shall indicate zero. • Descriptor() – A data structure of the form type-length-data, where type is an 8- bit descriptor type identifier, length is an 8-bit field indicating the number of bytes to follow in the descriptor, and data is arbitrary data. The syntax and semantics of the data are as defined for the particular type of descriptor. The content_advisory_descriptor() (as defined in section 6.7.4 of ATSC A/65) may be used to indicate the rating of the program. The program rating shall be coded according to the MPAA and V-Chip Rating and Content Advisories to be used for parental restrictions on program purchases. 105 8.10.2 Purchase_req() & Purchase_cnf() The Host’s navigation application shall use the Purchase_req() object to request a purchase of a particular program offer. The POD Module shall respond with the Purchase_cnf() object to the Purchase_req() request. Table 8.10-I Purchase Request Object Syntax Syntax # of bits Mnemonic Purchase_req() { Purchase_req_tag 24 Uimsbf Length_field() Transaction_ID 8 Uimsbf Option_ID 8 Uimsbf PINcode_length 8 Uimsbf For (I=0; I<=PINcode_length; I++) { PINcode_byte 8 Uimsbf } } • PINcode_length, PINcode_byte – These fields allow the Host navigation application to pass the requested PIN code to the POD Module. In case no PIN code was requested, the PINcode_length is set to ‘0’. 106 Table 8.10-J Purchase Confirm Object Syntax Syntax # of bits Mnemonic Purchase_cnf() { Purchase_cnf_tag 24 Uimsbf Length_field() Transaction_ID 8 Uimsbf Option_ID 8 Uimsbf Status_field 8 Uimsbf IPPVslot_ID 8 Uimsbf Status_register 8 Uimsbf Comment_length 8 Uimsbf For (I=0; I<= Comment_length; I++) { Comment_txt 8 Uimsbf } } • Status_field – This field returns the status of the Purchase_req(). If the POD has validated the purchase, then Status_field shall be set to 0x00. Otherwise it will be set to one of the following values. When there are more than one reason to deny the purchase, Status_field is set to the lowest applicable value. Table 8.10-K Status Field Values for Purchase Confirm Status_field Value (hex) Purchase Granted 00 Purchase Denied – POD Module busy 01 Purchase Denied – Unknown Transaction_ID or Option_ID 02 Purchase Denied – Invalid PIN code 03 Purchase Denied – Event already purchased 04 Purchase Denied – Blackout is active 05 Purchase Denied - Credit limit is exceeded 06 Purchase Denied - IPPV slot limit is exceeded 07 Purchase Denied – Spending limit is exceeded 08 Purchase Denied – Rating limit is exceeded 09 Purchase Denied – Check Comments 0A 107 Reserved 0B-FF • Purchase Denied: IPPV_slot_limit is exceeded: The POD is unable to make additional IPPV purchases until it has reported all of its unreported purchases to the headend. • IPPVslot_ID - If Status_field is 0x00 (Purchase Granted) then IPPVslot_ID will contain the unique slot identifier that will later identify the purchasing transaction. If Status_field is any other value, IPPVslot_ID is reset to 0. • Comment_length, Comment_txt – These fields allow the POD Module to explain, using plain text, why the purchase request has been granted or denied. • Status_register - This field identifies the CA status of the program event. The designation of each bit is summarized in the following table. Table 8.10-L Status Register for Purchase Confirm Bit 7 6 5 4 3 2 1 0 VPU OPU UPU AUT FRE REP CAN VIE • VPU is set to 1 when the program event has been purchased for viewing once. • OPU is set to 1 when the program event has been purchased for taping once. • UPU is set to 1 when the program event has been purchased for unlimited taping. • AUT is set to 1 when the program event has been authorized. • FRE is set to 1 when the free preview (initial or anytime) of the program event has been viewed. • REP is set to 1 when the program event has been reported. • CAN is set to 1 when the program event has been cancelled. • VIE is set to 1 when the program event has been viewed. 8.10.3 Cancel_req() & Cancel_cnf() The Host’s navigation application shall use the Cancel_req() object to request a Cancellation of a particular purchased program offer. The POD shall respond with the Cancel_cnf() object to the Cancel_req() request. 108 Table 8.10-M Cancel Request Object Syntax Syntax # of bits Mnemonic Cancel_req() { Cancel_req_tag 24 Uimsbf Length_field() IPPVslot_ID 8 Uimsbf PINcode_length 8 Uimsbf For (I=0; I<=PINcode_length; I++) { PINcode_byte 8 Uimsbf } } Table 8.10-N Cancel Confirm Object Syntax Syntax # of bits Mnemonic Cancel_cnf() { Cancel_cnf_tag 24 Uimsbf Length_field() IPPVslot_ID 8 Uimsbf Status_field 8 Uimsbf Status_register 8 Uimsbf Comment_length 8 Uimsbf For (I=0; I<= Comment_length; I++) { Uimsbf Comment_txt 8 Uimsbf } } • Status_field – This field returns the status of the Cancel_req(). If the POD has validated the cancellation, then Status_field shall be set to 0x00. Otherwise it will be set to one of the following values. When there are more than one reason to deny the cancellation, Status_field is set to the lowest applicable value. 109 Table 8.10-O Status Field Values for Cancel Confirm Status_field Value (hex) Cancellation Granted 00 Cancellation Denied – POD Module is busy 01 Cancellation Denied – Unknown IPPVslot_ID 02 Cancellation Denied – Invalid PIN code 03 Cancellation Denied – Program already viewed or in progress 04 Reserved 05-09 Cancellation Denied - Check Comments 0A Reserved 0B-FF 8.10.4 History_req() & History_cnf() The Host’s navigation application shall use the History_req() object to request the history of all purchased and cancelled program events held in POD memory. The POD shall respond with the History_cnf() object to the History_req() request. Table 8.10-P History Request Object Syntax Syntax # of bits Mnemonic History_req() { History_req_tag 24 Uimsbf Length_field() PINcode_length 8 Uimsbf For (I=0; I<=PINcode_length; I++) { Uimsbf PINcode_byte 8 } Uimsbf } • PINcode_length, PINcode_byte – These fields allow the Host navigation application to pass the requested PIN code to get IPPV history on events that required a PIN Code validation for History. In case no PIN code or a wrong PIN code is supplied, only history on events that do not require PIN Code validation for History will be provided. 110 Table 8.10-Q History Confirm Object Syntax Syntax # of bits Mnemonic history_cnf() { history_cnf_tag 24 uimsbf length_field() status_field 8 uimsbf comment_length 8 uimsbf for (i=0; i<= comment_length; i++) { comment_txt 8 uimsbf } ippvslot_nb 8 uimsbf for (i=0; i<= ippvslot_nb; i++) { ippvslot_id 8 uimsbf purchase_type 8 uimsbf purchase_price 16 uimsbf status_register 8 uimsbf purchase_date 32 uimsbf cancel_date 32 uimsbf event_date 32 uimsbf title_length 8 uimsbf for (j=0; j < title_length; j++) { title_txt 8 uimsbf } text_length 8 uimsbf for (j=0; j < text_length; j++) { text_txt 8 uimsbf } descriptor_length 16 uimsbf for (k=0; k < desc_length; k++) { descriptor() var } } } 111 • Status_field – This field returns the status of the History_req(). If the POD has validated the History request, then Status_field shall be set to 0x00. Otherwise it will be set to one of the following values. Table 8.10-R Status Field Values for History Confirm Status_field Value (hex) History Granted 00 History Denied – POD Module is busy 01 Reserved 02 History Denied – Invalid PIN code 03 Reserved 04-09 History Denied - Check Comments 0A Reserved 0B-FF • Purchase_date, Cancel_date, Event_date – These fields contain respectively the purchase time, the cancel time and the starting time of the event. They are 32-bit unsigned integer quantities representing the time as the number of seconds since 12 am, January 6th 1980. • If the Cancel_date field contains all FFFFs, this indicates that no appropriate value is available for this field. 8.11 Specific Application Support The Specific Application Support resource is intended for use when a vendor-specific application, which resides in either the POD or the Host, needs to communicate a private set of objects across the interface. Support for this resource is required in the Host and POD Module. The POD shall establish at least one session for communication with the Specific Application Support Resource. 8.11.1 Specific Application Support Connectivity The POD Module shall open one or more Specific Application Support (SAS) sessions for private communications between vendor-specific POD Module applications and private Host applications, as shown in Figure 8.11-1. The POD Module, as the initiator of the sessions, is responsible for associating each session (by session number) with the appropriate vendor-specific POD Application. When a private Host application is ready to establish a connection with POD Module, an SAS Connect Request (sas_connect_rqst) message is sent to the POD over any opened SAS session. The POD uses the private Host Application ID to identify the specific 112 SAS session that should be used for communication between the identified private Host Application and the appropriate vendor-specific POD Module application. This session number, along with the private Host Application ID is returned to the Host via the SAS Connect Confirm message (sas_connect_cnf). This operation establishes the communication path between a specific pair of applications (vendor-specific POD application, private Host application). POD Module Host Open_Session_Request Open_Session_Response SAS #1 • • • Open_Session_Request SAS #n Open_Session_Response Sas_Connect_Rqst Private App ID #xx App ID #xx, SAS #k Sas_Connect_Cnf App ID #xx, SAS #k Figure 8.11-1 In some instances, the POD Module may receive an sas_connect_rqst before a session has been opened for the associated vendor-specific Application, as shown in Figure 8.11-2. In this case, the Pod Module shall establish the necessary SAS session and then respond with sas_connect_cnf. 113 POD Module Host Open_Session_Request Open_Session_Response SAS #1 Sas_Connect_Rqst Private App ID #xx Open_Session_Request SAS #k Open_Session_Response Sas_Connect_Cnf App ID #xx, SAS #k App ID #xx, SAS #k Figure 8.11-2 8.11.2 Resource Identifier Table 8.11-A Specific Application Support Resource Resource Class Type Version Identifier (hex) Specific Application Support 144 1 1 00900041 8.11.3 Application Objects The Specific Application Support resource includes seven APDU’s as described in the following table: 114 Table 8.11-B Specific Application Support Objects Apdu_tag Tag value Resource Direction (hex) Host <-> POD sas_connect_rqst() 9F9A00 SAS sas_connect_cnf() 9F9A01 SAS sas_data_rqst() 9F9A02 SAS sas_data_av() 9F9A03 SAS sas_data_cnf() 9F9A04 SAS sas_server_query() 9F9A05 SAS sas_server_reply() 9F9A06 SAS 8.11.3.1 sas_connect_cqst() & cas_connect_cnf() The Host shall send a sas_connect_rqst() APDU to the POD Module to establish a connection between a private Host application and the corresponding POD Module vendor-specific application. The Pod shall reply with an sas_connect_cnf() APDU to inform the Host of which SAS session is to be used for this connection. 8.11.3.1.1 sas_connect rqst() Table 8.11-C sas_connect_rqst Object Syntax Syntax # of bits Mnemonic sas_connect_rqst(){ sas_connect_rqst_tag 24 uimsbf Length_field() private_host_application_id 64 } uimsbf 115 8.11.3.1.2 sas_connect_cnf() Table 8.11-D sas_connect_cnf Object Syntax Syntax # of bits Mnemonic sas_connect_cnf(){ sas_connect_cnf_tag 24 uimsbf Length_field() private_host_application_id 64 uimsbf sas_session_status 8 uimsbf reserved 16 uimsbf } where: private_host_application_id This is a unique identifier of the private Host Application. Informative Note: There is no need to register Private_Host_Application_IDs used by different manufacturers. Applications that make use of this resource are downloaded into the Host by the cable operator, and thus the application has knowledge of valid ID values that are expected from operator-supplied POD modules. sas_session_status The status of the requested connection as defined in the following table. Table 8.11-E sas_session_status sas_session_status Value (Hex) Connection established 00 Connection denied – no associated vendor- 01 specific POD application found Connection denied – no more connections 02 available Reserved 03-FF sas_session _nb The session number to be used for the designated Specific Application communications. 116 8.11.3.2 sas_data_rqst(), sas_data_av(), & sas_data_cnf() Once a communication path has been established between the application pair (vendor-specific POD application, private Host application) via an SAS session, each of the applications can utilized the SAS APDUs to communicate with the other. The APDUs defined in this section are bi-directional in that they can originate from either side of the Host-POD Interface. The sas_data_rqst()APDU is used by one application to inform the other application that it is ready to process incoming data. The application which receives this APDU responds with an sas_data_av() APDU. When an application has data to send across the Host-POD Interface, an sas_data_av() APDU is sent. The receiving application responds with an sas_data_cnf() APDU to acknowledge that it is preparing to receive the available data. 8.11.3.2.1 sas_data_rqst() Table 8.11-F sas_data_rqst Object Syntax Syntax # of bits Mnemonic sas_data_rqst(){ sas_data_rqst_tag 24 uimsb Length_field() reserved 16 uimsb } 8.11.3.2.2 sas_data_av() Table 8.11-G sas_data_av Object Syntax Syntax # of bits Mnemonic sas_data_av(){ sas_data_av_tag 24 uimsb Length_field() reserved 16 uimsb sas_data_status 8 uimsb transaction_nb 8 uimsb } 117 8.11.3.2.3 sas_data_av_cnf() Table 8.11-H sas_data_cnf Object Syntax Syntax # of bits Mnemonic sas_data_av_cnf(){ sas_data_av_cnf_tag 24 uimsbf Length_field() reserved 16 uimsbf transaction_nb 8 uimsbf } where: sas_data_status The status of the available data defined in the following table. Table 8.11-I sas_data_status sas_data_status Value (Hex) Data Available 00 Data Not Available 01 Reserved 02-FF Transaction _nb The Transaction number is issued from an 8-bit cyclic counter ( 1 – 255) and is used to identify each data transaction and to gain access to the available data. When data is not available, the transaction_nb will be set to zero. 8.11.3.3 sas_server_query() & sas_server_reply() When data availability has been confirmed, an sas_server_query() APDU is sent to initiate the transfer of Application Specific data. The sas_server_reply() APDU shall be used to respond to the query and transfer data. 118 8.11.3.3.1 sas_server_query() Table 8.11-J sas_server_query Object Syntax Syntax # of bits Mnemonic sas_server_query(){ sas_server_query_tag 24 uimsb Length_field() reserved 16 uimsb transaction_nb 8 uimsb } 8.11.3.3.2 sas_server_reply() Table 8.11-K sas_server_reply Object Syntax Syntax # of bits Mnemonic sas_server_reply(){ sas_server_reply_tag 24 uimsbf Length_field() reserved 16 uimsbf transaction_nb 8 uimsbf Message_length 16 uimsbf for (i =0; i< message_length; i++) { message_byte 8 uimsbf } } 8.12 Generic Feature Control Support The Generic Feature Control resource enables the Host device to receive control of features which are considered generic to Host devices (set-top terminal, television, VCR, etc.). There are three aims to this resource: 1) to provide control of features that subscribers do not desire to set themselves, 2) to provide the ability to inhibit subscriber control and only allow headend control, and 3) to provide a mechanism in which a POD Module or Host device can be staged to a known value. 119 A resource is created which resides in the Host called the Generic Feature Control resource. If the Host reports this resource to the POD module, the POD module shall open only one session to the Host and should never close the session. 8.12.1 Parameter Storage 8.12.1.1 Host The Host may provide non-volatile storage for the parameters associated with generic features on a parameter-by-parameter basis. These parameters shall be stored in the Host. 8.12.1.2 POD There is no requirement for the POD module to store the generic feature’s parameters although there is no requirement that it cannot. 8.12.2 Parameter Operation 8.12.2.1 Feature List Exchange Immediately after the session to the Generic Feature Control resource has been established, the POD module shall query the Host to determine which generic features are supported in the Host (feature_list_req). After the POD module receives the generic feature list from the Host (feature_list), the POD module shall send its confirmation of the feature list to the Host (feature_list_cnf). The Host shall then query the POD module to determine which generic features are supported in the POD module and the headend (feature_list_req). The POD module shall send its feature list to the Host (feature_list) to which the Host shall send its confirmation (feature_list_cnf). This is called the generic feature list exchange. POD Headend Module Host open_session_request open_session_response feature_list_req feature_list feature_list_cnf feature_list_req feature_list feature_list_cnf Figure 8.12-1 Generic Feature List Exchange 120 If the generic feature list on the Host or the POD module changes, then the changed device shall send a generic feature list changed APDU to the other device (feature_list_changed). The other device shall then perform the generic feature list exchange to obtain the new list. POD Headend Module Host feature_list_changed feature_list_req feature_list feature_list_cnf Figure 8.12-2 POD Module Feature List Change POD Headend Module Host feature_list_changed feature_list_req feature_list feature_list_cnf Figure 8.12-3 Host Feature List Change 8.12.3 Host to POD Module Transfer After the feature exchange has occurred, the POD module may request the Host to send its feature parameters (feature_parameters_req). After any request, the Host shall send to the POD module the parameters for all the generic features in the Host’s generic feature list (feature_parameters). The POD module shall reply with the confirmation (feature_parameters_cnf). The POD module may utilize these generic feature parameters, transfer them to the headend, or ignore them. POD Headend Module Host feature_parameters_req feature_parameters feature_parameters_cnf 121 Figure 8.12-4 Host to POD Module Feature Parameters Anytime any of the parameters of the generic features that are in the POD module generic feature list are changed in the Host, for whatever reason, the Host shall transmit these new parameters to the POD module (feature_parameters). The POD module shall reply with the confirmation (feature_parameters_cnf). POD Headend Module Host feature_parameters feature_parameters_cnf Figure 8.12-5 Host Parameter Update The POD module may request, at any time the session is open and the generic feature list exchange has occurred, the current parameters in the Host. The POD module shall do this by sending a feature parameters request (feature_parameters_request) as shown in figure 8.12-4. 8.12.3.1 Headend to Host It is not intended that the headend would transmit all the generic feature’s parameters cyclically. Most of the parameters would only be transmitted once at the request of the user or for staging of the device. The generic feature’s parameters which may need to be sent cyclically are the RF output channel, time zone, daylight savings, and rating region. The headend may send all or just some of the parameters. The method in which the POD module receives the generic feature’s parameters is proprietary to the POD manufacturer. After the session has been established, when the POD module receives a message from the headend containing generic feature parameters, the POD module shall transfer this information to the Host (feature_parameters). The Host shall replace the parameters with the values in the APDU. If the POD module utilizes the parameters, it shall replace its internal parameters with the values in the message from the headend. The Host shall respond with the confirmation (feature_parameters_cnf). The Host may receive parameters for generic features which it does not support. The Host shall ignore any generic feature parameters that it does not implement. 122 POD Headend Module Host proprietary generic feature control message feature_parameters feature_parameters_cnf Figure 8.12-6 POD Module to Host Feature Parameters 8.12.4 Resource Identifier The following resource identifier shall be utilized for the Host to open in the POD module. Table 8.12-A Generic Feature Control Resource Resource Class Type Version Identifier (hex) Generic Feature Control 42 1 1 002A0041 8.12.5 Feature ID Each generic feature shall have a unique ID assigned to it. This ID is the same for all APDUs. The following is a list of the features and their assigned feature ID. 123 Table 8.12-B Generic Feature IDs Feature ID Feature 00 Reserved 01 RF Output Channel 02 Parental Control PIN 03 Parental Control Settings 04 IPPV PIN 05 Time Zone 06 Daylight Savings Control 07 AC Outlet 08 Language 09 Rating Region 0A Reset PIN 0B Cable URLs 0C Emergency Alert Location Code 0D-3F Reserved for future use 70-FF Reserved for proprietary use 8.12.6 Application Objects The following is a list of the application objects (APDUs). Table 8.12-C Generic Feature Control Objects Apdu_tag Tag value Resource Direction (hex) Host <-> POD Feature_list_req 9F 98 02 Generic Feature Control ↔ Feature_list 9F 98 03 Generic Feature Control ↔ Feature_list_cnf 9F 98 04 Generic Feature Control ↔ Feature_list_changed 9F 98 05 Generic Feature Control ↔ Feature_parameters_req 9F 98 06 Generic Feature Control ← Feature_parameters 9F 98 07 Generic Feature Control ↔ Feature_parameters_cnf 9F 98 08 Generic Feature Control ↔ 124 8.12.6.1 Feature List Request Either the Host or POD shall send this APDU to the POD module or the Host to query the generic features that it supports. Table 8.12-D Feature List Request Object Syntax Syntax # of bits Mnemonic feature_list_req() { feature_list_req_tag 24 uimsbf length_field() } • feature_list_req_tag Value = 0x9F9802 8.12.6.2 Feature List After receiving the feature_list_req, the Host or POD module shall transmit this APDU to the POD module or Host which lists the generic features that the POD module and headend support control of. Table 8.12-E Feature List Object Syntax Syntax # of bits Mnemonic Feature_list() { Feature_list_tag 24 uimsbf Length_field() Number_of_features 8 uimsbf For(i=0; i POD open_homing 9F9990 Homing homing_cancelled 9F9991 Homing open_homing_reply 9F9992 Homing homing_active 9F9993 Homing homing_complete 9F9994 Homing firmware_upgrade 9F9995 Homing firmware_upgrade_reply 9F9996 Homing firmware_upgrade_complete 9F9997 Homing 8.13.3.2 open_homing (Normative) The open_homing APDU is transmitted by the Host to the POD module when it enters the standby state, either from power up or from user action. It shall send this independent of whether the Host Control resource has a session active. 142 Table 8.13-C Open Homing Object Syntax Syntax # of bits Mnemonic open_homing() { open_homing_tag 24 uimsbf length_field() } 8.13.3.3 open_homing_reply (Normative) The open_homing_reply APDU is transmitted by the POD module to the Host to acknowledge receipt of the open_homing APDU. Table 8.13-D Open Homing Reply Object Syntax Syntax # of bits Mnemonic open_homing_reply() { open_homing_reply_tag 24 uimsbf length_field() } 8.13.3.4 homing_active (Normative) The homing_active APDU is transmitted by the Host to the POD module to inform the POD module that the homing request has been activated. Table 8.13-E Homing Active Object Syntax Syntax # of bits Mnemonic homing_active() { homing_active_tag 24 uimsbf length_field() } 143 8.13.3.5 homing_cancelled (Normative) If the Host was not informed that a firmware upgrade was in progress, then it shall have the capability to close the homing state. Table 8.13-F Homing Cancelled Object Syntax Syntax # of bits Mnemonic homing_cancelled() { homing_cancelled_tag 24 uimsbf length_field() } 8.13.3.6 homing_complete (Normative) When the POD module no longer needs the homing function, then it can transmit a homing_complete to the Host. Table 8.13-G Homing Complete Object Syntax Syntax # of bits Mnemonic homing_complete() { homing_complete_tag 24 uimsbf length_field() } 8.13.3.7 firmware_upgrade (Normative) If the POD module uses an in-band channel to perform a firmware upgrade, it shall transmit the firmware_upgrade APDU to the Host. If the upgrade_source is equal to the QAM inband channel (01), then the Host shall immediately give access to the inband tuner through the Host Control resource tune APDU. The Host shall not interrupt a firmware upgrade until it receives the firmware_upgrade_complete APDU. If the Host is not in the standby mode, then it shall display the user_notification_text. The user_notification_text shall be in ISO-8859-1. The estimated time to download in download_time shall be in seconds. 144 Table 8.13-H Firmware Upgrade Object Syntax Syntax # of bits Mnemonic firmware_upgrade() { firmware_upgrade_tag 24 uimsbf length_field() upgrade_source 8 uimsbf download_time 16 uimsbf timeout_type 8 uimsbf download_timeout_period 16 uimsbf text_length 8 uimsbf for(i=0; i Host host info request message Download via OOB Forward download YES Data Channel method == 00 method (section 3.3.6.1) NO Download via IB FAT Channel method (section 3.3.6.2) Figure 8.15-7 Flow chart summarizing download operations 8.15.2.4.1 OOB Forward Data Channel Summary 178 Figure 8.15-8 Flow chart summarizing download operations for OOB Forward Data Channel method 179 8.15.2.4.2 IB Forward Application Transport Channel Summary Host -> POD host info message VCT Version Number Change? YES NO POD -> Host Exit from Download host download NO A Protocol command? YES location type == 0 YES Parse VCT NO Extract Multiplex Source ID exists? Frequency and Modulation mode from message YES Extract Program Number Tune to and obtain Multiplex Multiplex Frequency and Modulation mode from VCT Acquire PMT and parse NO stream type(s) Boot from Flash stream type == All stream types NO YES A 0x08 parsed? Flash YES Image NO Parse stream and extract DSM-CC Download Info Indication Message Host -> POD Download YES host download control Complete? (host command = 0x01) NO NO Transaction ID NO A changed? Host -> POD host download control YES On-Demand? (host command = 0x00) YES Extract CVC and Examine contents of Download Acquire DSM--CC Download message and determine YES Applicable that contains code code file if download is applicable. files Figure 8.15-9 Flow chart summarizing broadcast download operations 180 8.15.2.5 Code Authentication After a code image is downloaded into the set top box and before it is placed in permanent storage in non-volatile memory, the image is authenticated using the SCTE 23-2 2002 code authentication process regardless of the method used to download the file. This method specifies a particular structure to the code file (PKCS#7 compliant). The code file consists of the manufacturer’s Code Verification Signature (CVS), and X.509 Code Verification Certificate (CVC) signed by the root CA, and the signed code image that is compatible with the target. 8.15.3 System Control Resource (Normative) This section provides details of Host-POD messages. A new resource, the System Control resource, is introduced for handling revision control and download operations. Applications must exist in the POD to support this resource. New Application Protocol Data Units (APDU) are also introduced. 8.15.3.1 Resource Identifier The following resource identifier associated with the System Control resource shall reside in the Host and is optional for use by the POD module. The POD shall open a session to this resource in the Host and shall never close it. Only one session is supported by the Host. Table 8.15-B Resource Identifier Resource Class Type Version Identifier System Control 43 1 1 0x002B0041* *proposed value 8.15.3.2 Application Objects (APDUs) The following table is a list of the APDUs that are required for this specification. The host_info_request, host_info_response and the host_download_control APDUs are required for both download methods. The code_version_table and code_version_table_reply APDUs are exclusively utilized for the OOB Forward Data Channel download method. The host_download_command APDU is exclusively utilized for the IB FAT Channel download method. 181 Table 8.15-C Table of Application Protocol Data Units Direction APDU_tag Tag value (hex) Resource Host <-> POD Host_info_request 9F9C00 System Control Host_info_response 9F9C01 System Control Code_version_table 9F9C02 System Control Code_version_table_reply 9F9C03 System Control Host_download_control 9F9C04 System Control Host_download_command 9F9C05 System Control 8.15.3.3 host_info_request After the POD module opens a session to the System Control resource, the POD module shall query the Host to determine its vendor ID and hardware version ID and optional additional parameters. The POD also must inform the Host as to what type of download the Headend is going to use to update the Host. The POD module shall use at least the vendor ID and hardware version ID to filter the CVT. If a download is in progress, the Host shall terminate it. Table 8.15-D host_info_request Syntax # of bits Mnemonic host_info_request() { host_info_request_tag 24 Uimsbf length_field() supported_download_type 8 Uimsbf } host_info_request_tag Value = 0x9F9C00 supported_download_type Defines the type of Common Download method utilized by the Headend. 00 OOB Forward Data Channel method 01 IB FAT Channel method 02 DOCSIS only 03 – FF Reserved 182 Note: this document does not define DOCSIS download requirements. A headend need not use this ADPU to inform the Host that updates are performed via a DOCSIS download. 8.15.3.4 host_info_response The Host shall respond to the POD module query with its vendor ID and hardware version ID. Table 8.15-E host_info_response Syntax # of bits Mnemonic Host_info_response() { Host_info_response_tag 24 Uimsbf Length_field() Vendor_id 24 Uimsbf Hardware_version_id 32 Usmsbf Number_of_descriptors 8 Uimsbf for(I=0;i... R Begin and end HTML document ... R Begin and end of the body of the document, optional attributes of the document: • bgcolor: background color, default: light gray (#C0C0C0) • text: color of text, default: black (#000000) O • link: color of unvisited links, default: blue (#0000FF) O O ... R Begin and end an anchor • href: URL targeted by this anchor R Style Element

R Change of paragraph O • align: CENTER, LEFT or RIGHT (default : LEFT)
R Force new line ... ... ... O Character style: bold, italic and underlined C.4. Characters An HTML page can refer to all characters by their numeric value by enclosing them between the & and ; symbols. For example, the quotation mark “ can be expressed as " in an HTML page. The characters also have mnemonic names as well. Thus, the following 3 expressions are interpreted as a character “: " " ” Note: Mnemonic expressions are case sensitive. 207 Table C.5-A defines characters, their numeric and mnemonic expressions that Baseline HTML viewer shall support. Any baseline HTML page shall not use the characters, numeric or mnemonic expressions which are not defined in the table C.5- A. The host device may ignore the characters which are not defined in the table C.5- A. This list is taken from the HTML 4 Character entity references found at: http://www.w3.org/TR/1999/REC-html401-19991224/sgml/entities.html. Table C.4-A Characters Numeric Mnemonic Character Name Expression Expression Horizontal tab Line feed Space ! Exclamation mark ! " Quotation mark " " # Number sign # $ Dollar sign $ % Percent sign % & Ampersand & & ' Apostrophe ' ( Left parenthesis ( ) Right parenthesis ) * Asterisk * + Plus sign + , Comma , - Hyphen - . Period . / Solidus (slash) / 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 : Colon : ; Semicolon ; < Less than < < = Equals sign = > Greater than > > ? Question mark ? @ Commercial at @ A A B B C C 208 Table C.4-A Characters D D E E F F G G H H I I J J K K L L M M N N O O P P Q Q R R S S T T U U V V W W X X Y Y Z Z [ Left square bracket [ \ Reverse solidus \ ] Right square bracket ] ^ Circumflex ^ _ Horizontal bar _ ` Grave accent ` a a b b c c d d e e f f g g h h I i j j k k l l m m n n o o p p q q r r s s t t u u v v w w x x y y 209 Table C.4-A Characters z z { Left curly brace { | Vertical bar | } Right curly brace } ~ Tilde ~ Non-breaking space     ¡ Inverted exclamation ¡ ¡ ¢ Cent ¢ ¢ £ Pound £ £ ¤ Currency ¤ ¤ ¥ Yen ¥ ¥ ¦ Broken vertical ¦ ¦ § Section sign § § ¨ Umlaut/diaeresis ¨ ¨ © Copyright © © ª Feminine ª ª « Left angle quote « « ¬ No sign ¬ ¬ - Hyphen ­ ­ ® Reg. trade mark ® ® ¯ Macron ¯ ¯ ° Degrees ° ° ± Plus/Minus ± ± ² Superscript 2 ² ² ³ Superscript 3 ³ ³ ´ Acute accent ´ ´ µ Micron µ µ ¶ Paragraph sign ¶ ¶ · Middle dot · · ¸ Cedilla ¸ ¸ ¹ Superscript 1 ¹ ¹ º Masculine º º » Right angle quote » » ¼ One quarter ¼ ¼ ½ One half ½ ½ ¾ Three quarters ¾ ¾ ¿ Inverted question mark ¿ ¿ À A Grave À À Á A Acute Á Á  A Circumflex   à A Tilde Ã Ã Ä A Diaeresis Ä Ä Å A Ring Å Å Æ AE Diphthong Æ Æ Ç C Cedilla Ç Ç È E Grave È È É E Acute É É Ê E Circumflex Ê Ê Ë E Diaeresis Ë Ë Ì I Grave Ì Ì Í I Acute Í Í Î I Circumflex Î Î Ï I Diaeresis Ï Ï Ð Icelandic eth Ð Ð 210 Table C.4-A Characters Ñ N Tilde Ñ Ñ Ò O Grave Ò Ò Ó O Acute Ó Ó Ô O Circumflex Ô Ô Õ O Tilde Õ Õ Ö O Diaeresis Ö Ö × Multiplication × × Ø O Slash Ø Ø Ù U Grave Ù Ù Ú U Acute Ú Ú Û U Circumflex Û Û Ü U Diaeresis Ü Ü Ý Y Acute Ý Ý Þ Icelandic Thorn Þ Þ ß Small sharp S ß ß à a Grave à à á a Acute á á â a Circumflex â â ã a Tilde ã ã ä a Diaeresis ä ä å a Ring å å æ ae Diphthong æ æ ç c Cedilla ç ç è e Grave è è é e Acute é é ê e Circumflex ê ê ë e Diaeresis ë ë ì i Grave ì ì í i Acute í í î i Circumflex î î ï i Diaeresis ï ï ð Icenlandic eth ð ð ñ n Tilde ñ ñ ò o Grave ò ò ó o Acute ó ó ô o Circumflex ô ô õ o Tilde õ õ ö o Diaeresis ö ö ÷ Division ÷ ÷ ø o Slash ø ø ù u Grave ù ù ú u Acute ú ú û u Circumflex û û ü u Diaeresis ü ü ý y Acute ý ý þ Icenlandic thorn þ þ ÿ y Diaeresis ÿ ÿ 211 APPENDIX D. POD Module Attribute and Configuration Registers D.1. General This appendix was originally documented in SCTE –DVS/222 and has been included in this document. This appendix is a detailed map of the attribute registers and configuration option register of the SCTE Point of Deployment (POD) module. It is assumed that the reader is familiar with the PC Card tuple arrangement for the attribute registers. D.2. Attribute Tuples The following is a list of the attribute tuples which must be implemented in the POD module. CISTPL_LINKTARGET CISTPL_DEVICE_OA CISTPL_DEVICE_OC CISTPL_VERS_1 CISTPL_MANFID CISTPL_CONFIG CCST_CIF CISTPL_CFTABLE_ENTRY STCE_EV STCE_PD CISTPL_NO_LINK CISTPL_END D.2.1. CISTPL_LINKTARGET Defined in section 3.1.4 of PC Card Metaformat [10], this is recommended by the PC Card standard for low voltage PC Cards for robustness. This would be in addition to the tuples defined in [1] and would be the first tuple. 212 Table D.2-A CISTPL_LINKTARGET Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_LINKTARGET (0x13) 1 02 TPL_LINK = 0x03 2 04 TPL_TAG (3 bytes) = 0x43 (C) 3 06 0x49 (I) 4 08 0x53 (S) D.2.2. CISTPL_DEVICE_0A Defined in section 3.2.3 of PC Card Metaformat [10] , this tuple is used to define the attribute memory operation. Table D.2-B CISTPL_DEVICE_0A Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_DEVICE_0A (0x1D ) 1 02 TPL_LINK = 0x04 2 04 Other_Conditions_Info = 0x02 3 06 Device_ID_1 = 0x08 4 08 Device_Size = 0x00 5 0A 0xFF D.2.3. CISTPL_DEVICE_0C Defined in section 3.2.3 of PC Card Metaformat [10] , this tuple is used to define the common memory operation. Table D.2-C CISTPL_DEVICE_0C Byte Address (hex0 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_DEVICE_0C (0x1C ) 1 02 TPL_LINK = 0x04 2 04 Other_Conditions_Info = 0x02 3 06 Device_ID_1 = 0x08 4 08 Device_Size = 0x00 5 0A TPL_END = 0xFF 213 D.2.4. CISTPL_VERS_1 Defined in section 3.2.10 of PC Card Metaformat [10] . Section A.5.6 of [1] requires that TPLLV1_MAJOR be 0x05 and that TPLLV1_MINOR = 0x00. The field name of the product shall be “OPENCABLE POD Module”. Table D.2-D CISTPL_VERS_1 Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_VERS_1 (0x15) 1 02 TPL_LINK = 26+n+m 2 04 TPLLV1_MAJOR = 0x05 3 06 TPLLV1_MINOR = 0x00 4 08 TPPLV1_INFO = {Name of manufacturer (n bytes) 4+n 08+(2*n) TPLLV1_INFO (multiple bytes) ox00 (Null) 5+n 0A+(2*n) 0x4F (O) 6+n 0C+(2*n) 0x50 (P) 7+n 0E+(2*n) 0x45 (E) 8+n 10+(2*n) 0x4E (N) 9+n 12+(2*n) 0x43 (C) 10+n 14+(2*n) 0x41 (A) 11+n 16+(2*n) 0x42 (B) 12+n 18+(2*n) 0x4C (L) 13+n 1A+(2*n) 0x45 (E) 14+n 1C+(2*n) 0x20 ( ) 15+n 1E+(2*n) 0x50 (P) 16+n 20+(2*n) 0x4F (O) 17+n 22+(2*n) 0x44 (D) 18+n 24+(2*n) 0x20 ( ) 19+n 26+(2*n) 0x4D (M) 20+n 28+(2*n) 0x6F (o) 21+n 2A+(2*n) 0x64 (d) 22+n 2C+(2*n) 0x75 (u) 23+n 2E+(2*n) 0x6C (l) 24+n 30+(2*n) 0x65 (e) 25+n 32+(2*n) 0x00 (Null) 26+n 34+(2*n) Additional Product Information (m bytes) 27+n 36+(2*n) 0x00 (Null)} 27+n+ 36+(2*n)+m TPL_END = 0xFF m 214 D.2.5. CISTPL_CONFIG Defined in section 3.3.4 of PC Card Metaformat [10] with requirements in [1]. Table D.2-E CISTPL_CONFIG Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_CONFIG (0x1A) 1 02 TPL_LINK = 5+n+m+p 2 04 0 TPCC_RMSZ TPCC_RAS Z 3 06 0 TPCC_LAST 4 08 n bytes of TPCC_RADR 5+n 0A+(2*n) m bytes of TPCC_RMSK 6+n+m 0C+(2* 19 bytes of TPCC_SBTPL (n+m)) 25+n+ 32+(2* TPL_END = 0xFF m (n+m+p)) TPCC_RMSZ The number of bytes in the configuration registers Base Address in Attribute Memory Space field (TPCC_RMSK) of this tuple is the value of this field plus 1. For the POD module, this value will depend on the manufacturer. TPCC_RASZ The number of bytes in the Configuration Register presence mask field (TPCC_RADR field) of the tuple is this value plus 1. For the POD module, this value will depend on the manufacturer. TPCC_LAST One byte field which contains the Configuration Index Number of the last configuration described in the Card Configuration Table. Once the Host encounters this configuration, when scanning for valid configurations, it shall have processed all valid configurations. For the POD module, this value will depend on the manufacturer. TPCC_RADR The Base Address of the Configuration Registers, in an even byte of Attribute Memory (address of Configuration Register 0), is given in this field. TPCC_RMSK The presence mask for the Configuration Registers is given in this field. Each bit represents the presence (1) or absence (0) of the corresponding Configuration Register. TPCC_SBTPL The sub-tuple allows for additional configuration sub-tuples. The CCST_CIF sub- tuple must be implemented. D.2.6. CCST_CIF Defined in section 3.3.4.5.1 of PC Card Metaformat [10] . The interface ID number (STCI_IFN) is 0x41. STCI_STR is defined to be ‘POD_V1.00’. 215 Table D.2-F CCST_CIF Byte AddressH 7 6 5 4 3 2 1 0 0 00 ST_CODE = CCST_CIF (0xC0) 1 02 ST_LINK = 0x0B 2 04 STCI_IFN = 0x41 3 06 STCI_IFN_1 = 0x03 4 08 STCI_STR (multiple bytes) 0x50 (P) 5 0A 0x4F (O) 6 0C 0x44 (D) 7 0E 0x5F (_) 8 10 0x56 (V) 9 12 0x31 (1) 10 14 0x2E (.) 11 16 0x30 (0) 12 18 0x30 (0) 13 1A 0x00 (Null) 14 1C TPL_END 0xFF D.2.7. CISTPL_CFTABLE_ENTRY Defined in section 3.3.2 of PC Card Metaformat [10]. For the first entry TPCE_INDX has both bits 6 (Default) and 7 (Intface) set. The Configuration Entry Number is selected by the manufacturer. TPCE_IF = 0x04 – indicating Custom Interface 0. TPCE_FS shall indicate the presence of both I/O and power configuration entries. TPCE_IO is a 1-byte field with the value 0x22. The information means: 2 address lines are decoded by the module and it uses only 8-bit accesses. The power configuration entry – required by this specification, shall follow the PC Card Specification.” Additionally, two sub-tuples, STCE_EV and STCE_PD shall be included. The power descriptor for Vcc is modified to 1 A. 216 Table D.2-G CISTPL_CFTABLE_ENTRY Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_CFTABLE_ENTRY (0x1B) 1 02 TPL_LINK == 0x33 2 04 TPCE_INDX = 0xC0 LOGICAL OR Config. Entry NumberH 3 06 TPCE_IF = 0x04 4 08 TPCE_FS = 0x0A 5 0A TPCE_PD Vcc Parameter Selection Byte = 0x38 6 0C TPCE_PD Vcc Static Current = Manufacturer value 7 0E TPCE_PD Vcc Average Current = 0x07 8 10 TPCE_PD Vcc Peak Current = 0x07 9 12 TPCE_PD Vpp Parameter Selection Byte = 0x78 10 14 TPCE_PD Vpp Static Current = Manufacturer value 11 16 TPCE_PD Vpp Average Current = 0x26 12 18 TPCE_PD Vpp Peak Current = 0x26 13 1A TPCE_PD Vpp Power Down Current = Manufacturer value 14 1C TPCE_IO = 0x22 15 1E ST_CODE = STCE_EV (0xC0) 16 20 ST_LINK = 0x10 17 22 STEV_STRS = “NRSS_HOST” 0x4F (O) 18 24 0x50 (P) 19 26 0x45 (E) 20 28 0x4E (N) 21 2A 0x43 (C) 22 2C 0x41 (A) 23 2E 0x42 (B) 24 30 0x4C (L) 25 32 0x45 (E) 26 34 0x5F (_) 27 36 0x48 (H) 28 38 0x4F (O) 29 3A 0x53 (S) 30 3C 0x54 (T) 31 3E 0x00 (Null) 32 40 0xFF 33 42 ST_CODE = STCE_PD (0xC1) 34 44 ST_LINK = 0x12 35 46 STPD_STRS = “NRSS_CI_MODULE” 0x45 (O) 36 48 0x50 (P) 37 4A 0x45 (E) 38 4C 0x4E (N) 39 4E 0x43 (C) 40 50 0x41 (A) 41 52 0x42 (B) 42 54 0x4C (L) 43 56 0x45 (E) 44 58 0x5F(_) 217 Table D.2-G CISTPL_CFTABLE_ENTRY Byte Address (hex) 7 6 5 4 3 2 1 0 45 5A 0x4D (M) 46 5C 0x4F (O) 47 5E 0x44 (D) 48 60 0x55 (U) 49 62 0x4C (L) 50 64 0x45 (E) 51 66 0x00 (Null) 52 68 0xFF 53 6A 0xFF D.2.8. CISTPL_END Defined in section 3.1.2 of PC Card Metaformat [10] . Table D.2-H CISTPL_END Byte Address (hex) 7 6 5 4 3 2 1 0 0 00 TPL_CODE = CISTPL_END(0xFF) 218 D.2.9. Configuration Option Register Defined in section 4.15.1 of PC Card Electrical [9]. Table D.2-I Configuration Option Register Byte Address 7 6 5 4 3 2 1 0 ,(hex) 0 00 SRESET Levl Function Configuration Index REQ D.2.9.1. Values to Enable POD Personality Change SRESET – 0 (Do not soft reset (POD reset) the POD module) LevIREQ – 1 (POD module generates Level Mode interrupts. Function Configuration Index – Lower 6 bits of TPCE_INDX. D.2.9.2. Operation After Invoking POD Personality Change After the correct value is written into the configuration register, the POD module shall wait a minimum of 10 usec before switching from the PCMCIA to the POD interface. 219 APPENDIX E. POD Error Handling E.1. Error Handling When error handling requires action by both the Host and the POD module, the action by the first is designated with a “(1)”. It is suggested that the POD module create a diagnostic user interface which registers with the application info resource to allow it to report any error conditions, especially in a broadcast (one-way) scenario. Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 1 POD READY signal does not go POD Host either None Host reports error to user. active. 1) reports error using screen in figure ( figure E.1-1), 2) retry PCMCIA resets up to two times and then report error using screen in figure ( figure E-1), or 3) report error but continue to perform PCMCIA resets 2 Host reads incorrect CIS values POD Host reports error using None Host reports error to user.1 screen in figure E.1-1 Error Display 3 Host writes incorrect TPCE_INDX Host None POD cannot perform any action. Host detects as failure #4 and value to POD configuration register reports error to user.1 220 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 4 Host sets data channel RS bit but POD Host either None Host reports error to user.1 POD fails to set FR bit within 5 1) reports error using screen second timeout. in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) reports error and continue to perform PCMCIA resets 5 Host sets extended channel RS bit but POD Host either None Host reports error to user.1 POD fails to set FR bit within 5 1) reports error using screen second timeout. in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) reports error and continue to perform PCMCIA resets 221 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 6 Invalid buffer negotiation - POD data POD Host either None Host reports error to user.1 channel (buffer size < 16) 1) reports error using screen in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) operate with smaller size 7 Invalid buffer negotiation - Host data Host None Minimum – POD sets IIR flag Host reports error to user.1 channel (buffer size < 16 or greater and stops responding to polls. than POD data channel buffer size) Preferred – POD works with Host buffer size 8 Invalid buffer negotiation – POD POD Host either None Host reports error to user.1 extended channel (buffer size < 16) 1) reports error using screen in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) operate with smaller size 9 Invalid buffer negotiation - Host Host None Minimum – POD sets IIR flag Host reports error to user.1 extended channel (buffer size < 16 or and stops responding to polls. greater than POD data channel buffer Preferred – POD works with size) Host buffer size 222 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 10 POD does not respond to Hosts open POD Host either None Host reports error to user.1 transport request within 5 seconds. 1) reports error using screen in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) reports error and continue to perform PCMCIA resets 11 Host does not respond to POD request Host None Minimum – POD sets IIR flag Host reports error to user.1 to open resource manager session and stops responding to polls. within 5 seconds. 12 Host response to open resource Host None Minimum – POD sets IIR flag Host reports error to user.1 manager session response - resource and stops responding to polls. manager non-existent 13 Host response to open resource Host None Minimum – POD sets IIR flag Host reports error to user.1 manager session response - resource and stops responding to polls. manager unavailable 14 Host response to open resource Host None Minimum – POD sets IIR flag Host reports error to user.1 manager session response - incorrect and stops responding to polls. version of resource manager 15 Host response to open resource Host None Minimum – POD sets IIR flag Host reports error to user.1 manager session response - resource and stops responding to polls. manager busy 16 Host response to open resource Host None Minimum – POD sets IIR flag Host reports error to user.1 manager session response - invalid and stops responding to polls. status byte 223 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 17 POD fails to respond to profile_inq POD Host either None Host reports error to user.1 within 5 seconds. 1) reports error using screen in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) reports error and continue to perform PCMCIA resets 18 Host resource response - no Host None Minimum – POD sets IIR flag Minimum – Host reports error to application information resource and stops responding to polls.. user. Preferred - Applications on Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 19 Host resource response - no Host Host None Minimum – POD sets IIR flag POD may not be able to do control resource and stops responding to polls. conditional access properly. NOTE: There is a discussion ongoing about DOCSIS only operation.1 20 Host resource response - no system Host None Minimum – POD continues POD operations which require time resource operation and will not open a system time will not operate.1 session to the system time resource. Preferred – Same as minimum but also reports this in its MMI diagnostics application. 224 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 21 Host resource response - no MMI Host None Minimum – POD continues POD cannot utilize MMI for resource operation and will not open a applications or to report error session to the MMI resource. conditions.1 22 Host resource response - no low speed Host None Minimum – POD continues If OOB reverse path not communications operation and will not open a available, then some applications session to the low speed will be unavailable.1 communication resource. Preferred – Same as minimum but also reports this in its MMI diagnostic application. 23 Host resource response - no homing Host None Minimum – POD continues POD may have some operational resource1 operation and will not open a problems (i.e. downloading session to the homing resource. software).1 Preferred – Same as minimum but also reports this in its MMI diagnostic application. 24 Host resource response - no copy Host None Minimum – POD continues All CA channels will not be protection resource operation, disables descrambling descrambled, only clear channels of all conditional access may be viewed.1 channels, it will not open a session to the copy protection resource, reports to headend if possible, reports error to user, and reports this in its MMI diagnostic application. 25 Host resource response - unknown Host None Minimum – POD continues Not a failure condition resource identifier operation. 26 Host fails to respond to open session Host None Minimum – POD sets IIR flag Host reports error to user.1 request within 5 seconds. and stops responding to polls. 225 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 27 Host response to open application info Host None Minimum – POD sets IIR flag Minimum – Host reports error to resource session - application info and stops responding to polls.. user. Preferred - Applications on non-existent Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 28 Host response to open application info Host None Minimum – POD sets IIR flag Minimum – Host reports error to resource session - application info and stops responding to polls.. user. Preferred - Applications on unavailable Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 29 Host response to open application info Host None Minimum – POD sets IIR flag Minimum – Host reports error to resource session - incorrect version of and stops responding to polls.. user. Preferred - Applications on application info Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 30 Host response to open application info Host None Minimum – POD sets IIR flag Minimum – Host reports error to resource session - application info and stops responding to polls.. user. Preferred - Applications on busy Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 31 Host response to open application info Host None Minimum – POD sets IIR flag Minimum – Host reports error to resource session - invalid status byte and stops responding to polls.. user. Preferred - Applications on Preferred – POD continues the POD may not operate operation and will not open a correctly, including MMI.1 session to the application info resource. 226 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 32 POD module requests to open Host None Minimum – POD sets IIR flag Host reports error to user.1 conditional access session to the Host and stops responding to polls. times out after 5 seconds. 33 POD response to conditional access Host None Minimum – POD sets IIR flag Minimum - Host reports error to resource session - conditional access and stops responding to polls. user. Preferred – Scrambled non-existent Preferred – POD will not channels are not viewed.1 descramble but will continue other operation and reports this in its MMI diagnostic application. 34 POD response to conditional access Host None Minimum – POD sets IIR flag Minimum - Host reports error to resource session - conditional access and stops responding to polls. user. Preferred – Scrambled unavailable Preferred – POD will not channels are not viewed.1 descramble but will continue other operation and reports this in its MMI diagnostic application. 35 POD response to conditional access Host None Minimum – POD sets IIR flag Minimum - Host reports error to resource session - incorrect version of and stops responding to polls. user. Preferred – Scrambled conditional access Preferred – POD will not channels are not viewed.1 descramble but will continue other operation and reports this in its MMI diagnostic application. 36 POD response to conditional access Host None Minimum – POD sets IIR flag Minimum - Host reports error to resource session - conditional access and stops responding to polls. user. Preferred – Scrambled busy Preferred – POD will not channels are not viewed.1 descramble but will continue other operation and reports this in its MMI diagnostic application. 227 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 37 POD response to conditional access Host None Minimum – POD sets IIR flag Minimum - Host reports error to resource session - invalid status byte and stops responding to polls. user. Preferred – Scrambled Preferred – POD will not channels are not viewed.1 descramble but will continue other operation and reports this in its MMI diagnostic application. 38 POD fails to respond to ca_info_inq POD Host either None Host reports error to user.1 within 5 seconds. 1) reports error using screen in figure Figure E.1-1 Error Display 2) retry PCMCIA resets up to two times and then report error using screen in figure Figure E.1-1 Error Display, or 3) reports error and continue to perform PCMCIA resets 39 POD module requests to open copy Host None Minimum – POD continues All CA channels will not be protection resource session to the operation, disables descrambling descrambled, only clear channels Host times out after 5 seconds. of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 228 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 40 Host response to open copy protection Host None Minimum – POD continues All CA channels will not be resource session - copy protection operation, disables descrambling descrambled, only clear channels non-existent of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 41 Host response to open copy protection Host None Minimum – POD continues All CA channels will not be resource session - copy protection operation, disables descrambling descrambled, only clear channels unavailable of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 42 Host response to open copy protection Host None Minimum – POD continues All CA channels will not be resource session - copy protection operation, disables descrambling descrambled, only clear channels busy of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 43 Host response to open copy protection Host None Minimum – POD continues All CA channels will not be resource session - invalid status byte operation, disables descrambling descrambled, only clear channels of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 229 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 44 Host does not support POD's copy Host/POD None Minimum – POD continues All CA channels will not be protection system. incompatibility operation, disables descrambling descrambled, only clear channels of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 45 Host and POD do not mate Host/POD None Minimum – POD continues All CA channels will not be incompatibility operation, disables descrambling descrambled, only clear channels of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 46 Host response to CP_sync - Host Host None Minimum – POD will cease A copy protected channel will busy descrambling of copy protected stop being descrambled. channels. 47 Host response to CP_sync - no CP Host None Minimum – POD will cease A copy protected channel will support descrambling of copy protected stop being descrambled. channels. 48 Host response to CP_sync - invalid Host None Minimum – POD will cease A copy protected channel will status descrambling of copy protected stop being descrambled. channels. 49 Host fails to respond to cp_open_req. Host None Minimum – POD will cease A copy protected channel will descrambling of copy protected stop being descrambled. channels. 230 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 50 Invalid Host certificate Host None Minimum – POD continues All CA channels will not be operation, disables descrambling descrambled, only clear channels of all conditional access may be viewed.1 channels, reports to headend if possible, reports this to user, and reports this in its MMI diagnostic application. 51 Write Error (WE) occurs after POD or Host Host performs POD reset. None User may see frozen picture on completion of any transfer from Host scrambled channels.1 to POD 52 Read Error (RE) occurs after POD or Host Host performs POD reset. None User may see frozen picture on completion of any transfer from POD scrambled channels.1 to Host 53 POD fails to respond to any request POD Host performs PCMCIA None User may see frozen picture on within 5 seconds, other than described reset up to two times and then scrambled channels.1 by error conditions 17 and 38. reports error using screen in figure Figure E.1-1 Error Display. 54 Invalid session APDU from Host Host None No action Not a failure condition 55 Invalid session APDU from POD POD Host ignores invalid None Not a failure condition sessions. 56 Invalid SPDU tag from Host Host None No action Not a failure condition 57 Invalid SPDU tag from POD POD Host ignores invalid SPDU None Not a failure condition tags. 58 Invalid APDU tag from Host Host None No action Not a failure condition 59 Invalid APDU tag from POD POD Host ignores invalid APDU None Not a failure condition tags. 60 Transport ID from Host that has not Host None No action Not a failure condition been created and confirmed by POD 231 Table E.1-A Error Handling Error condition Failure Host action SCTE POD module action Comments mechanism 61 Transport ID from POD that has not POD Host ignores transport ID’s None Not a failure condition been created by Host. that have not been created 62 Session ID from Host that has not Host None No action Not a failure condition been created and confirmed by POD 63 Session ID from POD that has not POD Host ignores session ID’s None Not a failure condition been created by Host. that have not been created NOTE: A POD reset is defined that the Host shall set the RS bit in the command interface control register. A PCMCIA reset is defined that the Host shall set the RESET signal active on the PCMCIA interface. 1 - If the error is caused by an issue with the design of the Host or POD module, this should be detected during certification. In the even that an error occurs in which the Host must display an error message, the following message, or its equivalent, shall be displayed: 232 A technical problem is preventing you from receiving all cable services at this time. Please call your cable operator and report error code 161-xx to have this problem resolved. Figure E.1-1 Error Display The “xx” after the error code 161 shall be the item number of the above table which has failed. 233