CS-1000 User's Guide

Broadband Communications Sector
Copyright 2000 Motorola, Inc. All rights reserved.
Security Level 1
CS-1000 User's Guide
Document Number: Revision: Author: Revision Date:
365-095-1578 X.11 Pat O'Connell-Racicot 11/27/02
Broadband Communication Sector 101 Tournament Drive Horsham, PA 19044
Rev X.1 X.2 x.3 X.4
Number 365-095-1578 365-095-1578 365-095-1578 365-095-1578
Description - CS-1000 User's Guide - Updated to reflect changes made to the CS-1000 in software release 3.2.0 - Updated to reflect corrections made to the CDG section of the document. - Updated to reflect new CDG utility functionality that will allow use of CDG with DCT5xxxs. - Incorporated changes for Release 3.3.0 - Added a section describing how to manage StagingAreas and FTP User Logins - Added all necessary text describing new import
Incorporated By
Pat O'Connell-Racicot Pat O'Connell-Racicot Pat O'Connell-Racicot Pat O'Connell-Racicot
Date 1/15/01 3/30/01 4/16/01 6/6/01
X.5
365-095-1578
and export tools.

- Changed ConfigFile section to reflect new
Todd Fisher
9/25/01
enhancements.
- Replaced figure 4.8-1 to reflect changes to the
GUI window.
X.6 365-095-1578 - Added a note to the Add a Carousel section describing carousel behavior when a CS-1000 is powered on from a powered off state. - Added in the Content Management descriptions to the Status and Control section and the DMG tag descriptions to the PDCS carousel section. - Added in the description of Content Management and PID MUX features. Updated GUI screen captures. - Added description of the EDSC carousel type in Section 1.1 - Added a new section to the Introduction for DMG - Added a new section for the Edit Stream Data Source window. - Performed a general review and update of entire guide, - Added notes about the importance of setting the time and timezone correctly on both the server machine and the GUI machine. - Corrected XML format for ASTB_TUNE and BOOT_CODE CONTROL messages. - Modified Figure 4.1-1 CS Graphical User Interface Add CFS Stream Output Directories section to CS GUI. Todd Fisher 11/15/01
X.7
365-095-1578
Pat OConnell-Racicot
1/2/02
X.8
365-095-1578
Todd Fisher
4/23/02
X.9
365-095-1578
Todd Fisher
5/16/02
X.10 X.11
365-095-1578 365-095-1578
Bing Mu Todd Fisher
8/26/02 11/27/02
Date 11/27/02
Document Title
Document Number:
Broadband Communications Sector 101 Tournament Drive Horsham PA 19044
365-095-1578 X.11
Revision Number:
Motorola Security Level 1
Page 2 of 87
Document Number: 365-095-1578 Rev: X.11
Table of Contents
1
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8
Introduction _______________________________________________________ 6
Types of Carousels____________________________________________________________ CS-1000 ____________________________________________________________________ CFS API ____________________________________________________________________ CS GUI _____________________________________________________________________ Communication Interfaces ______________________________________________________ Code Download Generator (CDG) ________________________________________________ DCII Message Generator (DMG) _________________________________________________ SNMP Support _______________________________________________________________ 6 7 7 7 8 8 8 8
2 3
Scope ____________________________________________________________ 9 CS Concepts ______________________________________________________ 9

CS Network Interfaces _________________________________________________________ 9 CS Configuration ____________________________________________________________ 10 CFS Stream Set/Stream Configuration__________________________________________ 11 PDCS Stream Set/Stream Configuration ________________________________________ 11 CFS_______________________________________________________________________ 12 File Systems ______________________________________________________________ 12 Staging Areas _____________________________________________________________ 14 Types of Data _____________________________________________________________ 15 PDCS _____________________________________________________________________ 16 Code Download Generator (CDG) _____________________________________________ 16 DCII Message Generator (DMG) ______________________________________________ 16 PID Multiplexing _____________________________________________________________ 18 External Data Source Carousel (EDSC) _________________________________________ 18 Data Sources _____________________________________________________________ 18
3.1 3.2 3.2.1 3.2.2 3.3 3.3.1 3.3.2 3.3.3 3.4 3.4.1 3.4.2 3.5 3.5.1 3.5.2
CS GUI__________________________________________________________ 19
19 20 21 22 23 24 25 26 27 28 29 31 33 34 35 36 38 39 40 41 42
4.1 CS-1000 Menu Structure ______________________________________________________ 4.2 CS GUI Startup______________________________________________________________ 4.2.1 CS GUI Login _____________________________________________________________ 4.3 CS GUI Main Menu___________________________________________________________ 4.3.1 System Menu _____________________________________________________________ 4.3.2 Configure Menu____________________________________________________________ 4.3.3 Window and Help Menus ____________________________________________________ 4.4 System Users____________________________________________________________ 4.4.1 User Privileges ____________________________________________________________ 4.5 System Status and Control _________________________________________________ 4.5.1 Manage Content ___________________________________________________________ 4.5.2 Stream Set Status __________________________________________________________ 4.6 System Export ___________________________________________________________ 4.7 System Import ___________________________________________________________ 4.8 Configure - CFSOOBTAB Maintenance. ________________________________________ 4.8.1 OOBTAB Entries ___________________________________________________________ 4.9 Configure Interfaces_______________________________________________________ 4.9.1 Add an IP Interface _________________________________________________________ 4.10 Configure Data Sources____________________________________________________ 4.10.1 Add an IP Data Source ______________________________________________________ 4.10.2 Add an IP Data Source Address _______________________________________________
Page 3 of 87
CS-1000 User's Guide 4.11 Configure Carousels ______________________________________________________ 4.11.1 Add a Carousel ____________________________________________________________ 4.11.2 CFS Directory _____________________________________________________________ 4.11.3 Add a Stream Set __________________________________________________________ 4.11.4 Add a Stream _____________________________________________________________ 4.11.5 Output Directories __________________________________________________________ 4.11.6 Edit an EDCS Stream _______________________________________________________ 4.11.7 Edit Stream_Interface _______________________________________________________ 4.11.8 Edit Stream_DataSource ____________________________________________________ 43 43 46 47 48 52 53 53 54
CFS Content Management___________________________________________ 55

Managing StagingAreas and FTP User Logins _____________________________________ Add an ISV User ___________________________________________________________ Delete an ISV User _________________________________________________________ Metadata File Format _________________________________________________________ Rules for using Metadata Files __________________________________________________ CFS OOBTAB Metadata File ___________________________________________________ 55 55 55 56 57 58
5.1 5.1.1 5.1.2 5.2 5.3 5.4
6 7
PDCS Content Management _________________________________________ 58 Code Download Generator (CDG) and DCII Message Generator (DMG) _______ 58
CDG XML File Format ________________________________________________________ DMG XML File Format ________________________________________________________ DCII Message Generator (DMG) Tags __________________________________________ PDCS Streams ______________________________________________________________ Control Stream Message ____________________________________________________ Code Download Message____________________________________________________ DCT5xxx Specific Subcommands and Messages ___________________________________ Boot Code Control _________________________________________________________ ASTB Tune _______________________________________________________________ Object Conditional Access ___________________________________________________ Preambles__________________________________________________________________ Creating the DCII Download/Message File ________________________________________ Downloading Code Objects ____________________________________________________ Clearing a DCII Message from the Carousel _______________________________________ 59 61 61 63 64 64 66 67 68 71 72 73 73 74
7.1 7.2 7.2.1 7.3 7.3.1 7.3.2 7.4 7.4.1 7.4.2 7.4.3 7.5 7.6 7.7 7.8
8
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9
CS-1000 Setup in a Local Headend ____________________________________ 75

Define Source _______________________________________________________________ Define a Digital (Download) Service______________________________________________ Define Service in Channel Map (Adding Channel Map Assignments) ____________________ Obtain the application PID _____________________________________________________ Define Multicast 16 Address Set ________________________________________________ Add Multicast 16 Address for CS Server __________________________________________ Update the DAC Database for Multicast 16 Address _________________________________ Obtain IP Addresses of Headend Network_________________________________________ Define the UDP Port within the OM 1000 __________________________________________ 75 76 78 78 79 80 81 82 83
CS File Maintenance _______________________________________________ 84

84 84 84 85
9.1 Persistent Data Store _________________________________________________________ 9.2 Log Files ___________________________________________________________________ 9.2.1 Log File Trace Settings ______________________________________________________ 9.2.2 Log File Naming Conventions_________________________________________________
10 Acronyms ________________________________________________________ 87
Page 4 of 87
List of Figures and Tables

FIGURE 3.1-1 - CS CONFIGURATION IN A HEADEND ___________________________________________ 10 FIGURE 3.2-1 - CS SERVER COMPONENTS ___________________________________________________ 11 FIGURE 3.3-1 - CFS VIRTUAL FILE SYSTEM ___________________________________________________ 12 FIGURE 3.3-2 - CFS OOBTAB _______________________________________________________________ 13 FIGURE 3.3-3 - CFS OVERALL VIRTUAL FILE SYSTEM __________________________________________ 14 FIGURE 3.3-4 - CFS STAGING AREA _________________________________________________________ 15 FIGURE 3.4-1 - CODE DOWNLOAD GENERATOR (CDG) PROCESS _______________________________ 17 FIGURE 4.1-1 - CS GRAPHICAL USER INTERFACE _____________________________________________ 19 FIGURE 4.2-1 - CONNECTION WINDOW ______________________________________________________ 20 FIGURE 4.2-2 - INCOMPATIBLE VERSION MESSAGE ___________________________________________ 21 FIGURE 4.2-3 - LOGIN WINDOW _____________________________________________________________ 21 FIGURE 4.3-1 - CS GUI MAIN MENU __________________________________________________________ 22 FIGURE 4.3-2 - SYSTEM MENU______________________________________________________________ 23 FIGURE 4.3-3 - CONFIGURE MENU __________________________________________________________ 24 FIGURE 4.3-4 - WINDOW MENU _____________________________________________________________ 25 FIGURE 4.4-1 - USER LIST _________________________________________________________________ 26 FIGURE 4.4-2 - ADD USER__________________________________________________________________ 27 FIGURE 4.5-1 - CAROUSEL STATUS AND CONTROL____________________________________________ 28 FIGURE 4.5-2 - CFS CAROUSEL MANAGEMENT _______________________________________________ 29 FIGURE 4.5-3 - STREAM SET STATUS-VERSION TABLE_________________________________________ 31 FIGURE 4.5-4 - STREAM SET STATUS-STREAM TABLE _________________________________________ 31 FIGURE 4.5-5 - STREAM SET STATUS-DIRECTORY TABLE ______________________________________ 31 FIGURE 4.5-6 - STREAM SET STATUS-FILE TABLE _____________________________________________ 31 FIGURE 4.6-1 - EXPORT ___________________________________________________________________ 33 FIGURE 4.7-1 - IMPORT ____________________________________________________________________ 34 FIGURE 4.8-1 - ADD CFS OOBTAB ___________________________________________________________ 35 FIGURE 4.8-2 - ADD OOBTAB ENTRY ________________________________________________________ 36 FIGURE 4.9-1 - INTERFACES _______________________________________________________________ 38 FIGURE 4.9-2 - ADD IP INTERFACE __________________________________________________________ 39 FIGURE 4.10-1 - DATA SOURCES____________________________________________________________ 40 FIGURE 4.10-2 - EDIT IP DATA SOURCE ______________________________________________________ 41 FIGURE 4.11-1 - CAROUSELS _______________________________________________________________ 43 FIGURE 4.11-2 - ADD/EDIT CAROUSEL _______________________________________________________ 44 FIGURE 4.11-3 - CFS DIRECTORY ___________________________________________________________ 46 FIGURE 4.11-4 - ADD/EDIT STREAM SET _____________________________________________________ 47 FIGURE 4.11-5 - ADD/EDIT STREAM _________________________________________________________ 48 FIGURE 4.11-6 - SELECT A PROTOCOL ______________________________________________________ 50 FIGURE 4.11-7 - SELECT AN ADDRESS TYPE _________________________________________________ 50 FIGURE 4.11-8 - OUTPUT CONFIGURATION ___________________________________________________ 51 FIGURE 4.11-9 - OUTPUT DIRECTORIES______________________________________________________ 52 FIGURE 4.11-9 - EDCS STREAM CONFIGURATION _____________________________________________ 53 FIGURE 4.11-10 - EDIT STREAM INTERFACE __________________________________________________ 54 FIGURE 4.11-11 - EDIT STREAM DATA SOURCE _______________________________________________ 54 TABLE 5.2-1 - CFS METADATA FILE FORMAT__________________________________________________ 56 FIGURE 5.2-1 - CFS METADATA FILE FORMAT ILLUSTRATION ___________________________________ 57 FIGURE 8.1-1 - DAC - DEFINE SOURCE_______________________________________________________ 75 FIGURE 8.2-1 - DAC - DEFINE DIGITAL SERVICE _______________________________________________ 76 FIGURE 8.2-2 - DAC - SOURCE NAME AND PROVIDER__________________________________________ 77 FIGURE 8.3-1 - DAC - EDIT VIRTUAL CHANNEL MAP ROW _______________________________________ 78 FIGURE 8.4-1 - DAC - DISPLAY OM DEVICE STATUS ___________________________________________ 79
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
Page 5 of 87
CS-1000 User's Guide FIGURE 8.5-1 FIGURE 8.6-1 FIGURE 8.7-1 FIGURE 8.8-1 FIGURE 9.2-1 FIGURE 9.2-2 - DAC - DEFINE MULTICAST 16 ADDRESS SET ____________________________________ 80 - DAC - EDIT DOWNSTREAM PLANT _____________________________________________ 81 - DAC - UPDATE THE DAC DATABASE FOR MULTICAST 16 ADDRESS_________________ 82 - DAC - OBTAIN IP ADDRESS OF HEADEND NETWORK _____________________________ 83 - TRACE PARAMETERS ________________________________________________________ 85 - ARCHIVED LOG FILE NAME SYNTAX ___________________________________________ 86
1 Introduction
The Carousel System (CS) is a Motorola product that provides a generic means of transmitting data from a head-end to a population of DCTs. The CS implements several subsystems or types of carousels: Carousel File System (CFS) - Consists of client and server side components that work together to present a virtual file system to DCT client applications. Private Data Carousel System (PDCS) - Used to transmit any arbitrary DCII message set. External Data Source Carousel (EDSC) - Used to multiplex data from multiple sources, either internal or external.
In general, the CS consists of: The Carousel Server 1000 (CS-1000) for transmitting data to a population of DCTs. A client-side (DCT) API for accessing data delivered by the CS-1000 (CFS). A Graphical User Interface (GUI) for configuring and managing carousels. Communication Interfaces between the CS-1000 and the API client. A Code Download Generator (CDG) tool for creating DCII download messages from raw code objects. A DCII Message Generator (DMG) tool for creating a DCII Message file from payload data input file(s). SNMP support, including creation of a MIB for the SNMP agent which reports status information to a network manager.
1.1
Types of Carousels
The differences between the CFS and PDCS are illustrated below: Carousel File System (CFS) Presents a virtual file system to the DCT client application Allows ISV definition of the file system structure Supports content management via simple file transfer mechanisms Allows flexible partitioning of file system data across multiple streams to support prioritized file delivery Streams can be configured to utilize Multicast 16 addressing allowing multiple virtual streams to be carried on a single Service (PID) Requires the CFS API to be Private Data Carousel System (PDCS) Transmits any arbitrary set of DCII compatible messages Provides MPEG packetization of DCII messages Supports code downloads using the Code Download Generator (CDG)
External Data Source Carousel (EDSC) Transmits any arbitrary set of DCII compatible messages Provides MPEG packetization of DCII
Page 6 of 87
CS-1000 User's Guide downloaded to the DCT Allows client applications to obtain their content data through the use of API calls to the CFS API CFS API tunes to the proper streams based on ISV application requests messages Multiplexes data from multiple external data source addresses and outputs on a single PID. Outputs data at the same rate that the data is received.
1.2
CS-1000
The CS-1000 is the production server hardware and software system that transmits data to a population of DCTs. Processes and streams files onto the network. Data within the file system is transmitted repeatedly (carouselled). Stream configurations are modifiable at the server level via the CS GUI to support client application needs. Supports broadcast and multicast-16 addressed messages. Provides a simple mechanism for adding, updating and deleting content. Files are placed in a staging area, with associated metadata. The CS-1000 periodically polls the directory and adds files to the carousel according to the metadata information. Simultaneously targets multiple downstream plants. Supports multiple independent file systems with distinct stream configurations and output behaviors (CFS). Streams can be configured to output time-sensitive and/or non time-sensitive files. Timesensitive files contain data relevant to a particular time window (CFS). Transmits DCII private messages as part of the PDCS subsystem. Supports multiplexing data from external sources to be output on a single PID (EDSC).
1.3
CFS API
The CFS API works with the CS-1000 to present a virtual file system to DCT client applications. Allows a DCT application to access files via the CFS API. Hides complex implementation details and requires no knowledge of proprietary protocols, hardware or interfaces. The CFS API consists of calls to log in, obtain directory listings and access files or portions of files. ISV applications can also preallocate a buffer for the CFS API to use when assembling files. Downloaded and enabled as a separate DCT object.
1.4
CS GUI
The CS GUI is a Java-based application that runs on the CS Windows NT/2000 workstation. Add, edit and delete carousels, stream sets, streams, interfaces, data sources, CFS OOBTABs. Import and export carousels (stream sets and streams) interfaces, data sources and CFS OOBTAB configurations. Monitor system status, start and stop carousels, manage and clear content. Create CFS OOBTAB files Manage users
Page 7 of 87
1.5
Communication Interfaces
The CFS Carousel and CFS APIs communicate via a network protocol. CS Network provides the formats/protocols to deliver the file information from the server to the client. Allows for automatic and transparent adaptation to new stream configurations. Data delivered over Ethernet/UDP through the OOB channel.
1.6
Code Download Generator (CDG)
The CDG is a utility for creating code objects in DCII message format to be loaded on the DCT. Generates a DCII Code Download File from a Code Download Metadata File. The DCII Code Download File consists of DCII Download messages created using the DCII Segmentation Overlay Protocol. Uses existing PDCS functionality to support code downloads through one or more OM-1000s. The CS can deliver multiple code objects over one or more PID streams. Creates download commands that will ENABLE, DISABLE, DELETE or PURGE objects from the set top box. CDG supports DCII message creation for all types of tunes, including conditional tunes. Code download messages may be addressed to specific sets of terminals through the use of an optional message preamble. The preamble contains an expression consisting of decoder conditional terms and logical operators. Supports both DCII message type versions 0 and 2, allowing objects of any size to be downloaded.
1.7
DCII Message Generator (DMG)
The DCII Message Generator is a utility for creating DCII message file from generic payload data file(s). Like CDG, the parameters of the DCII message are included in an XML formatted file that is processed and staged to a PDCS carousel. Multiple payload input files can be combined together and processed into a single DCII message file. DCII messages can be broadcast or singlecast addressed. In the case of singlecast, either one address or a group of specified addresses can be applied to messages. An external address file can be used to hold a group of DCT unit addresses. Certain rules about preambles and address tags can be applied when generating DCII messages. A PDCS carousel compatible output file(.dat file), along with a .trg file will be automatically generated by the DMG batch file. These two files will be placed in the staging area to be carouselled to the DCT(s).
1.8
SNMP Support
The Simple Network Management Protocol (SNMP) support consists of a server program known as a SNMP agent that provides device status information to a client application known as a network manager. The SNMP agent controls a database referred to as the Management Information Base (MIB), and is a standard set of statistical and control values.
Page 8 of 87
CS-1000 User's Guide The CS-1000 contains an SNMP agent that reports status information to a network manager. The MIB contains machine, network and CS configuration information.
2 Scope
The Carousel System User's Guide describes how to use the various capabilities of the CS. CS installation is covered in CS-1000 Sun Netra Installation Guide and CS-1000 Windows Installation Guide. The CFS API is described in CFS API Reference Guide. This document covers the following: CS Concepts (CFS, PDCS and EDSC) CS GUI o Adding users o Adding interfaces o Creating and configuring carousels, stream sets and streams o Content management o Status and control o Starting and stopping carousels Using the Code Download Generator (CDG) tool Using the DCII Message Generator (DMG) tool CS configuration in a local headend CFS and PDCS Content Management CS File Maintenance
3 CS Concepts
3.1 CS Network Interfaces
The CS-1000 is part of the Motorola headend. It has two network interfaces. One network interface is for the OAM&P (headend) network. The other network interface is the application server network. This network allows third party application servers to deliver content and application objects to the CS-1000 for delivery to DCTs.
Page 9 of 87
CS-1000 User's Guide Note: Figure 3.1-1 depicts inband data delivery as a CS option. Inband data delivery is scheduled for a future CS release.
Figure 3.1-1 - CS Configuration in a Headend
Content Creation
Headend
Conte nt Del iver
Inband Data Delivery
nt nte Co
li De
r ve
Interactive Interactive Application Server Server Server
Carousel Server
OOB Data Delivery
Application Server Network
DAC6000
NC1500
OAM&P Network
64QAM modulator (IM-1000)
IRT IRT IRT
C6U C6U C8U
OM1000
RPD-2000
HFC
DCT
3.2
CS Configuration
As shown in Figure 3.2-1 below, the CS Server (CS-1000) is configured as a hierarchy of Carousels, Stream Sets, Streams, Interfaces and Data Sources. Configuration is performed to suit the data delivery needs of individual applications, and can be changed at any time without impacting client (DCT) applications. Carousels are defined on a per application or per content provider basis, and hold the virtual directory structure (CFS Carousels only) as well as manage content for the application. The content maintained by the Carousel is utilized by the subordinate Stream Sets. Although Stream Sets share the content maintained by the parent Carousel, their individual Stream settings determine how much of that content they output. Interfaces provide for the actual delivery of streamed data across the physical network. Once defined, interfaces can be accessed by multiple streams to effect transmission. Data Sources provide for a definition of external sources that the CS may obtain data from. These data sources define a live feed that the CS will gather from and multiplex with other feeds for transmmision over a configured interface.
Page 10 of 87
Figure 3.2-1 - CS Server Components

Interface 1 (e.g. OM-1000 ethernet) Port, IP Address 192.168.10.32, UDP port 6557
Interfaces 2 thru N
Interface 1 Interfaces are referenced by streams and are accessed to provide physical transport of data. A single stream may be sent to multiple physical destinations simultaneously.
Interfaces 2 thru N
Stream 1 Each stream is used to deliver data in a format appropriate to the carousel. The parent Stream Set prevents duplication of data across streams to prevent wasted bandwidth.
Streams 2 thru N
Stream Set 1 (e.g. OOB Streams) Each CFS Stream Set acts as a distinct virtual file system that delivers data over its subordinate streams. The subordinate streams act as a cohesive unit to transmit the file system over the network. Within the CFS, the Stream Set tracks the configuration of its subordinate streams to produce operations data that enables the CFS API to locate and reassemble files operations data is part of the CFS network protocol. Carousel 1 (e.g., ISV carousel)
Stream Sets 2 thru N
Carousels 2 thru N
Carousel Server
3.2.1 CFS Stream Set/Stream Configuration

Each CFS Stream Set comprises a virtual file system that consists of one or more Streams that work as a unit to deliver the contents of the file system. A single CFS Carousel can contain multiple Stream Sets, and each Stream Set can contain multiple Streams. Each Stream can output to multiple interfaces. The configuration of its individual streams determines how the file system is partitioned across the streams. Each Stream can be given its own file selection algorithm that produces a view onto the content contained in the carousel. For example, Streams can be configured to output files within all or only particular virtual directories. They can also be configured to output time sensitive files and/or non-time sensitive files; time sensitive files contain data relevant to a particular time window (e.g. today, tomorrow, 8:00AM-9:00AM today, etc.). When configured for time sensitive output, Streams are given sliding time window definitions that limit the number of files eligible for output based on the applicability of their data to the time window. Streams are responsible for forwarding their data, at a defined bit rate, to one or more Interfaces for actual transmission. Streams can be configured to take advantage of Motorola Multicast addressing in order to allow the creation of multiple virtual streams within a single MPEG PID stream. This capability takes advantage of DCT hardware filtering capabilities in order to simplify service provisioning.
3.2.2 PDCS Stream Set/Stream Configuration

Like the CFS, the PDCS also allows for flexible configuration of Carousels, Stream Sets, Streams and Interfaces. A single PDCS Carousel can contain multiple Stream Sets, and each Stream Set can contain multiple Streams. Each Stream can output to multiple interfaces. Creating a single Carousel, Stream Set and Stream outputting to one or more Interfaces is the most practical configuration, and suitable for most needs. This will also achieve better performance on the CS server.
Page 11 of 87
3.3
CFS
The CFS presents a virtual file system to DCT client applications. Third party developers create this virtual file system via the CS GUI. Files are loaded onto carousels via a staging area located on the CS1000 physical file system. A metadata file accompanies the content files loaded into the staging area. The metadata file contains information about the file (e.g., date created, file size, etc.) and where the file should be placed within the virtual directory structure. There must be a separate staging area for each carousel configured into the CS-1000 via the GUI. This staging area must also be created on the CS1000 physical file system, using the isv_user_add script. Once the carousel has been entered into the system and is started, the data is transmitted repeatedly (carouselled) by the CS-1000 through the OOB channel. A DCT client application makes calls to the CFS API to obtain directory listings and get files.
3.3.1 File Systems

The virtual file system presented by the CFS API contains one or more independent virtual file systems output from CS Server. A file system can be viewed conceptually as a "virtual disk" each of which can be mounted at a given directory. Figure 3.3-1 illustrates this concept. ISV virtual disks are mounted under "/usr/XXX", where XXX is a user name which typically identifies the particular ISV or application. In this illustration, there are three virtual disks for ISV use, /usr/ISV_A, /usr/ISV_B, and /usr/ISV_C.
Figure 3.3-1 - CFS Virtual File System
/ (contains /etc/cfsoobtab)
/usr/ISV_A
Virtual File System
/usr/ISV_B
/usr/ISV_C
Each virtual file system should have a virtual disk mounted at "/" and containing "/etc/". This file system, known as the root file system, carries a file used by the CFS API known as CFS Out-of-Band Table (CFS OOBTAB), which is created using the CS GUI. This file contains a map to other CFS virtual file systems. Each record in the file contains three pieces of information: the user name, and the service name and MCA-16 address that correspond to the stream carrying "operations data". Operations data is information about the files, directories, streams and versions for a particular file system. It is needed by the CFS API to perform all of the work necessary to service requests from third party applications.
Page 12 of 87
CS-1000 User's Guide The CFS API predefines the /usr directory while the CFS OOBTAB file defines the subdirectories for ISV_A, ISV_B, etc. The subdirectories under each ISV directory are defined in the CS GUI Carousel screen. Figure 3.3-2 illustrates this concept. Note: An ISV is not restricted to the "/usr/XXX" directory; subdirectories can be created below "/usr/XXX".
Figure 3.3-2 - CFS OOBTAB
The CFS OOBTAB file is always transmitted on CFS_MAIN/1 /etc cfsoobtab
User
Service ISVA ISVB ISVC
MCA 65535 65535 65535
/usr/ISV_A
ISV_A ISV_B ISV_C
/usr/ISV_B /usr/ISV_C
Services may be broadcast addressed or MCA-16 addressed. If broadcast addressed, the MCA-16 value must be 65535. In this example, each of the three services are broadcast-based. This would require that each service by configured in the headend controller, and each service would be assigned its own PID. An alternative is for each entry to have a common service name (one PID), but a different MCA value between 1 and 65534. User ISV_A ISV_B ISV_C Service ISVCOMMON ISVCOMMON ISVCOMMON MCA 10 20 30
In this case, only one service is configured in the controller. The advantages to this are (1) simplifies provisioning of services in the controller, (2) does not require changes in the controller if another virtual file system is added to the CFS OOBTAB, (3) uses only one PMT (the OM-1000 is limited to 49 simultaneous PMTs). Note: Service/MCA-16 must be unique. All ISVs MCA-16 addresses within the CFS_MAIN service are assigned to ISVs by Acadia Application Integration Center. This is important since no two streams can be sending data on the same service/MCA-16 stream.
Page 13 of 87
In order to establish the root file system, a carousel is created containing a single stream. The service name for this stream is CFS_MAIN, and its MCA-16 address is 1. Using the CS GUI, a CFS directory is created for the carousel named "etc". As with any carousel, there is a separate staging area created on the CS-1000. The staging area is a physical directory located on the CS-1000. The CFS OOBTAB file is placed into the CFS_MAIN staging area. The metadata file instructs the CS-1000 to place the file in the "/etc" virtual directory. The CS-1000 periodically polls the staging area, processes and carousels the file. The CFS API downloads this file, processes it and creates the overall virtual file system as shown below. ISV applications perform directory listings and can get files placed within these virtual directories. Security measures ensure that an ISV application cannot access another ISV's virtual directory. The virtual directory structure is a construct known only to the CFS API. The directories do not correspond to physical directories located anywhere on a disk.
Figure 3.3-3 - CFS Overall Virtual File System
etc
usr
ISV_A
ISV_B
ISV_C
3.3.2 Staging Areas

Each carousel created through the CS GUI must be assigned a single staging area, which is a physical directory on the CS-1000. Content can be added, modified and deleted through this interface. In the example shown in Figure 3.3-2, there would be four carousels, and therefore four staging areas. By convention, the staging area corresponding to the carousel containing CFS OOBTAB is named CFS_MAIN, but staging areas can be named any valid directory name.
Page 14 of 87

Figure 3.3-4 - CFS Staging Area
StagingArea
CFS_MAIN
cfsoobtab is placed in a staging area corresponding to the carousel defined with a service name = CFS_MAIN and an MCA16 = 1. The metadata file instructs the CS-1000 to place the file in "/etc"
ISV_A_StagingArea
ISV_B_StagingArea
ISV_C_StagingArea
ISV content is placed in these staging areas. The metadata file instructs the CS-1000 to place these files in a valid subdirectory of "/usr/XXX". The CFS Directory Path should specify "/" for the file to appear in "/usr/XXX" on the API side (see Section 5)
3.3.3 Types of Data

There are three types of data that can be sent on a CFS carousel: Operations Data System specific data transmitted from the CS-1000 to the CFS API (non-ISV related). Every stream set must have at least one stream outputting operations data and that streams Service/MCA16 address must match an entry in the OOBTAB. There is no need for content to be loaded for operations data to be sent on a stream. Non-time Sensitive Data The data is carouselled immediately until its expiration date is reached or it is forcibly expired using the CS GUI Clear Content option on the Status and Control screen. Time Sensitive Data The data is carouselled during a specific period of time (once the file date range in the content metadata file and the time window behavior configured in the CS GUI coincide). A separate CFS stream may be configured for each type of data, or data types can be combined on a single stream, provided the Output Data Type does not conflict with the type of data loaded on the carousel.
3.3.3.1 Time Sensitive Data Streams

When configuring a time sensitive data stream, there are three fields that define the characteristics and behavior of the time "window": Time sensitive behavior (time window type): defines the basis for the start of a time window. Discrete: based on 00:00:00 of the current day. Continuous: based on the current time. Time Window Size the number of seconds that make up the time window For example: a Discrete time window with a window size of 25200 (7 hours) and time window offset of 0 would output files containing a metadata date range that falls between 12am and 7am.
Page 15 of 87
CS-1000 User's Guide Time window offset the time (in seconds, either plus or minus) from 00:00:00 of the current day (for a discrete window) or from the current time (for a continuous window) that the start of a time sensitive window will be shifted. For example: a Discrete time window with an offset of 14400 (4 hours) and a window size of 36000 (10 hours) means that files containing a metadata date range that falls between 4am and 2pm are carouselled.
3.4
PDCS
The PDCS transmits DCII private messages verbatim to DCTs. The PDCS provides MPEG encapsulation of these messages and delivers them to the appropriate interfaces as defined in the CS GUI, but it does not generate these DCII messages. Valid DCII messages must be provided from an external source, such as CDG or DMG. Like the CFS, content management is provided via a staging area, but the contents of the files must be in DCII format, whereas the CFS delivers any arbitrary file. Unlike the CFS, the PDCS does not present a virtual file system to a DCT client application, and the CFS API does not apply to PDCS carousels.
3.4.1 Code Download Generator (CDG)

The CDG is a tool that takes a raw code object and turns it into a DCII Code Download File that can be loaded on a PDCS carousel. This file is generated using an XML file that contains information about the raw code object. The XML file is also used to specify download commands that will ENABLE, DISABLE, DELETE or PURGE a specified object, tune the DCT for download, as well as send preamble information that provide for conditional message execution on the DCT. The DCII Code Download File is placed in the staging area corresponding to the PDCS carousel created with the CS GUI. This carousel is configured with one or more PID streams that will carousel the code object in the OOB transport. Two streams are needed to download a code object. One stream needs to be configured with an interface that is configured with the EMM PID for the tune command. A second stream needs to be configured for an interface that is configured with the MPEG PID for the download channel that the code object is being sent on. When a DCT is tuned to a valid download channel, the code object will begin downloading to the DCT. The PDCS can deliver multiple code objects over one or more PID streams via one or more OM1000s.
3.4.2 DCII Message Generator (DMG)

The DMG is a tool that takes an arbitrary payload and wraps it into a DCII stream file. This file is generated using an XML file that contains information about the DCII messages and DCT addresses you wish have the messages sent to. The input message can consist of either single or multiple payload files. Multiple input files will be processed in the specified order into a single DCII stream file. DCT unit addresses can be specified either in the address tag or from an external address file which contains a group of DCT unit addresses. Since the stream output file is compatible with the PDCS carousel protocol, a PDCS carousel can be utilized to carousel the data to a population of set-top boxes.
Page 16 of 87

Figure 3.4-1 - Code Download Generator (CDG) Process
Code Object
XML File
CDG
DCII Code Download File
File is copied to the applicable staging area with a trigger file
/StagingArea/PDCS_01 (example)
CS-1000
Page 17 of 87
3.5
PID Multiplexing
The CS has the capability to multiplex streams from several sources and create a single stream on a single PID. This multiplexing of PID streams is referred to as PID MUX. The CS has always had the capability to multiplex data onto a single PID; it does so when multiple streams are going to the same interface for a given carousel. The new capability involves taking external sources and multiplexing the PIDs. The general requirement is to multiplex N data PID streams from N distinct sources into a single resultant PID stream. PID streams can arrive via UDP/IP Singlecast, Multicast, or Broadcast sources, or from CS-1000 CFS/PDCS carousels. The sources can be either internal or external. The resultant PID stream can be sent to M destinations (via UDP/IP), on a distinct PID per destination. The mechanism that enables PID MUX is the use of the External Data Source Carousel (EDSC). An EDSC can support a single Data Source and multiple Interfaces. The Data Source provides the input and the Interfaces specify the output.
3.5.1 External Data Source Carousel (EDSC)

The EDSC is a carousel type that enables the multiplexing of multiple streams on different PIDs into a single stream with the same PID. The resultant Stream can be sent to multiple Interfaces. Like other types of carousels, an EDSC can specify multiple Stream Sets. Each Stream Set can specify multiple Streams. Each EDSC Stream can specify a Data Source. Data Sources are configured separately and are the source for the input streams that are to be multiplexed. Each EDSC Stream can also specify multiple Interfaces, in the same way that Interfaces are specified for other carousel streams. Multiple Data Sources can be multiplexed onto a common PID in one of two ways. The first uses a single EDSC with multiple streams, with each stream configured with a unique Data Source and a common Interface. The second method involves using separate EDSCs each with Streams configured with a unique Data Source and a common Interface. In this case specifying the same Interface (and PID value) causes all associated Streams to be multiplexed.
3.5.2 Data Sources

Data Sources are used as the input medium to EDSC carousels. When a Data Source is configured the following parameters are specified: Name, Type (currently limited to UDP/IP), Description, Port (on which the data is expected), and list of Multicast Groups. The list of multicast groups is optional and specifies which groups the EDSC can receive data from and on which network interface the data is present. The multicast group is specified using a valid multicast IP address. (224.0.0.0 239.256.256.256) For each multicast group a valid network interface is also specified. The network interface can be either the network interface IP address or the network interface name corresponding to the entry in the hosts file.
Page 18 of 87
4 CS GUI
The CS GUI allows you to configure users, create carousels, stream sets and streams, interfaces, data sources and CFS OOBTABs. You can also view system status, manage content and start and stop carousels. Note: There are two screen conventions that are used consistently throughout the CS: greyed fields and astericked fields (*). When a field is greyed out, it means it is read only and cannot be edited. A field with an * means that it is a required field and must be completed in order to save the screens contents.
4.1
CS-1000 Menu Structure
The CS-1000 graphical user interface (GUI) consists of a Multiple Document Interface (MDI) frame, MDI child and modal window structure. After logging into the CS GUI, only the MDI frame is open. The MDI frame contains pull down menus at the top of the frame. These menus are used to open various MDI child and modal windows within the MDI frame. You may have more than one MDI child window open at the same time and may minimize, cascade, close and restore these windows using the Window menu. However, when a modal window is opened, no other windows may be opened or accessed until the action on the modal window is complete (saved/canceled) and the window is closed. Figure 4.1-1 illustrates the windowing structure.
Figure 4.1-1 - CS Graphical User Interface
Connect Login
System
Configure
Help
Users
Carousels
Interfaces
Data Sources
CFSOOBTab Maintenance CFSOOBTab Add/Edit CFSOOBTab Entry Add/Edit
About
User Add/Edit
Carousel Add/Edit Stream Set Add/Edit Stream Add/Edit Stream Interface EDSC Stream Data Source
Interfaces Add/Edit
IP Data Source Add/Edit IP Data Source Address Add/Edit
Status and Control Manage Content Stream Set Status
Window Type
Menu choice MDI Child Modal
Export
Import
Page 19 of 87
4.2
CS GUI Startup
Please refer to the CS-1000 Sun Netra Installation Guide for information on setting the Sun Netras system time, date and time zone. Note: You must verify that the system time, date and time zone are correct on both the machine that is running the CS server and the machine that is running the CS GUI. Time sensitive data attributes will be incorrect if these times, dates, and time zones are incorrect. To start the CS GUI, you need to double click the Run_CS_GUI.bat file located in the CS directory of your Windows NT/2000 PC or double click a shortcut icon you may have setup on your desktop. The CS GUI then starts by presenting the Connect window, as shown in Figure 4.2-1. When running the CS using a Sun Netra server, the IP address for the server needs to be entered. The port setting should remain the default value - 1701.
Figure 4.2-1 - Connection Window
Field Name
IP Address
Description
The IP address for the CS-1000 server on the Sun Netra. In the case of an CS NT installation for a development environment, the IP address should remain as the default - 127.0.0.1 indicating the local machine. The port designation should remain as the default - 1701.
Port
Note: For quick reference, your connection information (IP address and port) is displayed in the title banner at the top of the main screen. (see Figure 4.3-1) The default values that appear in this window are set in the <drive>:\CS\ConfigFiles\CarouselManagerGUI.cfg file. If you are running GUI and server software that is incompatible, you are presented with the following message and you will be prevented from logging in.
Page 20 of 87

Figure 4.2-2 - Incompatible Version Message
The latest CS GUI software can be downloaded from the CS-1000 webpage. Point a web browser to the IP address of the CS-1000 server and download a compatible version of the CS GUI software.
4.2.1 CS GUI Login

After connecting to the server, you must then log into the CS GUI. Your login information will determine what your privileges are on the CS server (read only, control, edit, add, delete, and/or administrator). Note: All privileges are cumulative meaning a person with control privilege also has read, a person with add has read, control and edit privilege and so on.
Figure 4.2-3 - Login Window
Field Name
Username
Description
Once an Administrator has entered users into the system, their name will be included in the Username list. Users should contact their system administrator for their user name when signing into the CS-1000 for the first time. The Administrator creates passwords when a user is entered into the system. Users can then edit their password. All users should change their password upon first login to the system.
Password
Page 21 of 87
4.3
CS GUI Main Menu
The CS GUI Main Menu window contains drop down menus that spawn and control the windows in the GUI. The contents of these menus are described below.
Figure 4.3-1 - CS GUI Main Menu
Menu Choice System
Description Contains the menu items that pertain to the CS-1000 system including User configuration that allows you to add or delete users, edit user privileges. Status and Control allows you to manually start and stop carousels, and manually poll a carousels staging area, manage content and view Stream Set status. A system tool to import and export configurations is also available. Contains the menu choices that allow you to create and configure carousels (stream sets, streams), interfaces, data sources and CFS OOBTABs including PIDs, IP addresses, stream bit rates, and ports. Contains the menu choices that allow you to manage the main CS GUI windows including Cascade, Restore All, Minimize All and Close All. Contains an about screen that lists the version of the currently installed CS Server and GUI.
Configure
Window Help
Page 22 of 87
4.3.1 System Menu

The System Menu contains options for User Management, System Status and Control, and the configuration Import/Export tools.
Figure 4.3-2 - System Menu
Menu Choice Users
Description Allows Administrators to add and delete users on the system and to change their privileges. Allows all other uses to change their own password. Allows users to manually start and stop individual carousels, force poll a carousels Staging Area, manage and clear content on the carousel as well as view a carousels stream set status. Allows users to export a selection of configured carousels, interfaces, data sources and CFS OOBTABs to an external file in XML format. Allows users to select an XML file for import which is then inserted into the CS database. Log out and exit the CS GUI.
Status and Control
Export Import Exit
Page 23 of 87
4.3.2 Configure Menu

The Configure menu accesses the windows that allow for configuration of the Carousels (Stream Sets and Streams), Interfaces and Data Sources. Maintenance of the CFS OOBTAB is also part of the Configure menu. The CFS OOBTAB file defines the virtual file system mount points and tuning information. An OOBTAB acts as a roadmap that enables the CFS API to locate virtual file systems and retrieve data from them.
Figure 4.3-3 - Configure Menu
Menu Choice Carousels
Description Allows users to add, edit and delete Carousels, Streams Sets, Streams, Stream_Interface and Stream_DataSource associations. It is also possible to add a new Interface or Data Source from the Stream configuration window. Allows users to add, edit and delete IP Interfaces. Allows users to add, edit and delete Data Sources. Allows users to add, edit and delete CFS OOBTABs and create CFS OOBTAB files.
Interfaces Data Sources CFS OOBTAB Maintenance
Page 24 of 87
4.3.3 Window and Help Menus

Figure 4.3-4 - Window Menu
Menu Choice Cascade Restore All Minimize All Close All
Description Positions open windows so you may view the title banner of each open window. Displays all minimized windows. Minimizes all windows and displays a tab for each window at the bottom of the main window. Closes all open windows.
Help Menu Menu Choice About Description Displays the current version of the CS Server and GUI as well as developer information.
Page 25 of 87
4.4
System Users
Each CS site will require a System Administrator (SA). One of the functions of the SA will be to add users to the CS GUI, edit their privileges as necessary, and delete users from the system. Only a person with Administrator privileges is able to perform these tasks, so assigning a backup SA should be considered at each deployment site. Note: Each CS is deployed with a generic Administrator user with NO password. Upon first logon, the site SA should edit the password to make it unique. This will ensure the integrity of the CS-1000 database and its configuration.
Figure 4.4-1 - User List
Menu Choice Add Edit Delete Refresh Close
Description Allows Administrators to add new users to the CS and assign user privileges. Allows all users to change their password and Administrators to update user privileges and passwords. Allows Administrators to delete users from the CS. Allows users to refresh the User list to obtain the most current list of users. Closes the current window.
Page 26 of 87
4.4.1 User Privileges

User privileges are cumulative in the CS GUI. The most basic privilege is the Read Only privilege that allows a user to only view the data within the CS GUI. The Control privilege allows a user to read as well as control the starting and stopping of carousels. Edit allows a user to read, control and edit carousel configuration and so on. Each privilege is described in the field descriptions that follow.
Figure 4.4-2 - Add User
Privilege Read Only
Description Users assigned this privilege cannot change any data or configuration in the CS GUI, but may view all screens. Users assigned this privilege may see all screens in the CS and may control the operation of a carousel within the CS server by stopping and starting it. Users with this privilege may not edit or add any configuration settings to the CS. Users assigned this privilege have all the Read Only and Control privileges and may also edit any existing CS configuration settings. Users assigned this privilege have all the Read Only, Control, and Edit privileges and may also add Carousels, Stream Sets, Streams, Interfaces and Data Sources to the CS. Users assigned this privilege have full control of the CS configurations including the ability to delete Carousels, Stream Sets, Stream, Interfaces and Data Sources. They cannot, however, change user privileges or add or delete users. Users assigned this privilege have full rights within the CS GUI including the ability to add and delete other users in the system. Note: The default Administrator may not be deleted from the CS.
Control
Edit
Add
Delete
Administrator
Page 27 of 87
4.5
System Status and Control
The CS GUI Status and Control window allows users, with the appropriate privileges, to start and stop carousels, force poll a carousels staging area, manage and clear content present on the carousel, as well as view a carousels stream set status.
Figure 4.5-1 - Carousel Status and Control
Field Carousel Description Status Total Bit Rate Content Size
Description Name of carousel as defined on the Carousel screen. Carousel description as entered on the Carousel screen. Displays whether a carousel is running or stopped. Cumulative bit rate (bits/second) for all the streams associated with the carousel. Cumulative file size, in bytes, for all files that have been loaded on a particular carousel. This number is not the actual size of the content being carouselled since some time senstive files may not currently be active. Description Allows users to immediately start or stop any carousel in the list. Updates the carousel list with the latest data. Causes the selected carousels staging area to be polled immediately rather than waiting for the designated polling interval.
Action Start/Stop Refresh Poll Staging Area
Page 28 of 87
Action Manage Content
Description Spawns the Content Management window that allows users to view a list of the files currently loaded on the selected carousel. This window allows users to modify file attributes and expire files. Expires all files loaded on the selected carousel. You are prompted for confirmation of this action. Spawns the Stream Set Status window. Allows you to view status information for any stream sets associated with the selected carousel. Closes the Status and Control window.
Clear Content Stream Set Status Close
4.5.1 Manage Content

The Content Management window allows all users to view the file attributes of content currently loaded on the selected carousel. Those users with the Delete or Administrator privilege may also expire or update file attributes as necessary. Sort order for the file list is user definable by clicking on the header column for the data you want the list to be sorted by. The default sort order for this table is on virtual directory and then file name. Consequent clicks on a column header toggles between ascending and descending sort order. Note: All file updates and file expirations are buffered and appear in bold until the Send Metadata button is clicked, at which time a new content metadata file with the changes is created and then sent to the carousel. It is possible to back out changes to a carousels content by clicking the Refresh button before clicking the Send Metadata button. This action will clear all buffered requests and refresh the list with the most current data.
Figure 4.5-2 - CFS Carousel Management
Page 29 of 87
Field Total Files Loaded File Name Virtual Directory File Size File Date Expiration Date Time Range
Description Number of files loaded on the selected carousel. The name of a file loaded on the selected carousel. The virtual directory that the file is associated with as defined in the content metadata file. The size of the file, in bytes. The creation file date as defined in the content metadata file. The proper format for this field is yyyymmdd hh:mm:ss. The date the file will be deleted from the carousel. The format for this field is the same as the File Date format. In the case of time sensitive data, the begin and end date for when the file should be carouselled. In addition, a non-time sensitive file may be changed to time sensitive by adding a begin and end date to the file in the Edit File box. The proper format for this field is yyyymmdd hh:mm:ss- yyyymmdd hh:mm:ss. Description Allows you to expire a selected file. When pressed, the file is displayed in bold. You must then press the Send Metadata button to have a new content metadata file created and sent that will expire the data file. Processes all updates and expirations that have been buffered in the current file list (as indicated in bold). A new content metadata file is created for the selected carousel based on the changes indicated on this screen. Updates the list with the most recent data. This action will also clear the buffered update and expiration requests. Closes the Content Management window. Allows you to update the files metadata attributes. When pressed the file is displayed in bold. You must then press the Send Metadata button to have a new content metadata file sent to complete the updates.
Action Expire
Send Metadata
Refresh Close Update
Page 30 of 87
4.5.2 Stream Set Status

The Stream Set Status window allows all users to view the operations data associated with each Stream Set for the selected CFS carousel. Information is provided for the Version, Stream, Directory, and File Tables.
Figure 4.5-3 - Stream Set Status-Version Table
Figure 4.5-4 - Stream Set Status-Stream Table
Figure 4.5-5 - Stream Set Status-Directory Table
Figure 4.5-6 - Stream Set Status-File Table
Page 31 of 87
Field Version Table
Description The Version Table screen displays version information for the selected stream set. The Stream Table screen displays stream information for the selected stream set. The Directory Table screen displays a graphic of the virtual directory structure and the directory information for the selected stream set. The File Table screen displays file information for the selected stream set. Note: The file list displays only files that are currently being output based on a files time sensitive attributes. Therefore, the list of files may not include all files that are loaded on the carousel for the selected stream set.
Stream Table Directory Table File Table
Action Refresh Close
Description Allows users to refresh the display to obtain the most current operations data. Closes the Stream Set Status window.
Page 32 of 87
4.6
System Export
The CS-1000 Export window allows users to export the configuration of carousels, interfaces, data sources and CFS OOBTAB configurations to an XML file in a specified format. This utility writes a file to a location that is on the same machine as the CS GUI. Once the export button is pressed a file chooser is displayed to designate the destination path and filename. The resulting file can be saved and used for import on the same machine or another machine that requires the exported configuration.
Figure 4.6-1 - Export
Action Select All Deselect All Export Close
Description Allows users to select all items in all lists. Independent rows can be deselected by holding the CTRL key and single clicking on rows. Allows users to deselect all items in all lists. Independent rows can be selected by holding the CTRL key and single clicking on rows. Opens a file chooser window to designate the path and filename to export to. Once the file is validated the selected items are exported. Closes the Export window.
Page 33 of 87
4.7
System Import
The CS-1000 Import window allows users to chose an XML file to import from. This file must be in the exact format that is expected by the import tool. Any discrepancies will be reported and import will be aborted. An example import XML file is located with the CS GUI and on the Windows NT/2000 development installation at: <drive>:\CS\ImportExport\default_config.xml. This file contains the default configuration that a standard CS-1000 is shipped with. Note: If you encounter ANY errors while importing a configuration you will not have all of the expected objects inserted into the CS-1000. One common reason for errors during import is caused by duplicate carousel, interface, data source or CFS OOBTAB names. Be sure that no duplicates exist so that the desired configuration will be imported as expected.
Figure 4.7-1 - Import
Action Browse OK Cancel
Description Opens a standard file chooser window for browsing the local file system and selecting the file that is targeted for import. Performs import from the file designated in the text field. Cancels current action and closes import window.
Page 34 of 87
4.8
Configure - CFSOOBTAB Maintenance.
The CFS OOBTAB is a special file needed by the CFS API to locate the out-of-band mount points that are being carouselled by the CS-1000. The CFS API will attempt to locate and read the CFS OOBTAB on start-up (starting from the /etc directory) and periodically poll for any new versions of CFS OOBTAB that may have been placed into the CFS_MAIN staging area. The API validates each directory and GET request against the CFS OOBTAB to determine if the request is within one of the listed mount points. Note: CFS OOBTAB only pertains to carousels of type CFS, since PDCS carousels have no interaction with the CFS API and therefore do not require mount points. The CFS OOBTAB has no special meaning to the Carousel Server (CS-1000). From the servers perspective, it is just a file that is being carouselled like any other.
Figure 4.8-1 - Add CFS OOBTAB
Field Name CFS OOB Tab Name
Description The name entered into this field is not the file name but rather the name that will appear on the OOBTAB List screen. Maximum field length is 50 characters.
Page 35 of 87
Field Name Create CFSOOBTAB File
Description Filename must be named cfsoobtab. Creates a CFS OOBTAB file consisting of the CFS OOBTAB entries listed on this screen. The file is saved with this name in the designated directory on the CS GUI machine. The directory designated must already exist on this machine. The <drive>:\CS\cfsoobtab directory is a good location to create the file. Note: This file must be transferred to the CFS_MAIN Staging Area for carouselling to the settop population. The file you create from the GUI is a binary file. If you FTP this file to the CS-1000, ensure that the transfer mode is set to binary. In the ISV development version, the file should be copied to the CFS_MAIN Staging Area on the Windows NT/2000 machine.
4.8.1 OOBTAB Entries

The OOBTAB Entries define the contents of the CFS OOBTAB file. The CFS OOBTAB should contain all the valid mount points on the CS-1000. When a settop application makes a request it is to a mount point (User Name) contained in the CFS OOBTAB. The CFS API then uses the service name and MCA-16 address to tune to the right stream to acquire operations data needed to fulfill the request. If a new CFS OOBTAB is found during the polling process, the CFS API will re-evaluate the mount points of any pending requests against the new information.
Figure 4.8-2 - Add OOBTAB Entry
Field Name User Name
Description The name of the mount point for a particular carousel. This name indicates the name of the directory within the /usr directory in the CS1000 virtual directory structure that data will be mounted for a particular carousel. For example, if the user name is TEST, then the mount point is /usr/TEST. Third party applications will make directory and file requests within this mount point and subdirectories of this mount point (e.g., /usr/TEST/test.txt, /usr/TEST/subdir/test.txt).
Page 36 of 87
Field Name Service Name
Description The service name that the API uses when tuning or connecting to the downstream source for any requests on that mount point. This field value reflects the service name corresponding to the CFS carousel's operations data stream. The Multicast-16 Address that the API uses in conjunction with the Service Name for tuning or connecting to the downstream source for any requests on that mount point. This field value should correspond to the MCA-16 Address of the stream that is ouputting operations data for the carousel.
MCA 16
Page 37 of 87
4.9
Configure Interfaces
The Interface configuration screen allows you to add, edit and delete the output interface(s) for the CS1000. This screen may also be accessed from the CFS Stream window under the Configure Carousel menu item. When accessed from the main menu, however, multiple interfaces may be added and/or edited without being tied to a specific stream configuration.
Figure 4.9-1 - Interfaces
Field Name Interface Type
Description While both UDP/IP and TCP/IP are selectable from this field, UDP is currently the only available output interface. Future releases of the CS may allow a TCP/IP output connection.
Page 38 of 87
4.9.1 Add an IP Interface

The CS-1000 may output to multiple interfaces so that data can be sent to multiple downstream plants. Each OM is configured with the same port number. However, different IP addresses are entered for each OM-1000. Note: This menu item is available for you to add and configure all your Interfaces up front and separately from a specific Stream configuration. However, you may also add IP Interfaces from the Stream configuration window.
Figure 4.9-2 - Add IP Interface
Field Name Interface Name
Description An identifier that describes the type of equipment being output to. The interface name may be up to 50 characters and should distinguish one device from another (i.e., OM1000-1, OM1000-2, etc.) The data for this field is chosen and edited on the main IP interface MDI window. The specific IP address for the output device. The port designation for the output device as configured within that device. The default port value is 6557 (CS to OM).
Interface Type IP Address Port
Page 39 of 87
4.10 Configure Data Sources

The Data Source configuration screen allows you to add and configure the input Data Source(s) for EDSC carousels. This screen may also be accessed from the EDSC Stream window under the Configure Carousel menu item. When accessed from the main menu, multiple Data Sources may be added and/or edited without being tied to a specific stream configuration.
Figure 4.10-1 - Data Sources
Field Name Data Source Type
Description UDP/IP is currently the only available data source type.
Page 40 of 87
4.10.1 Add an IP Data Source

This menu item allows you to add and configure all your Data Sources up front and separately from a specific EDSC Stream configuration. However, you may also add IP Data Sources from the EDSC Stream configuration window. Each EDSC requires a single Data Source. Multiple Data Sources can be added from the Data Source window. For each optional Multicast Group, an IP Multicast Address and NIC IP address are specified.
Figure 4.10-2 - Edit IP Data Source
Field Name Data Source Name
Description An identifier that describes the source of the data. The Data Source name may be up to 50 characters and should distinguish one source from another. The data for this field is chosen and edited on the main Data Source interface MDI window. Optional description for the data source. The port designation for the data source.
Data Source Type Description Port
Page 41 of 87
4.10.2 Add an IP Data Source Address

Each Multicast Group requires at least one IP multicast address to specify the multicast group and a NIC IP Address to specify the network interface where the data is available. The NIC IP Address is either the network interface IP address or the network interface name corresponding to the entry in the hosts file of the CS.
Figure 4.10-3 - Add IP Data Source Address
Field Name IP Multicast Address NIC IP Address
Description A valid multicast IP address. (224.0.0.0 239.256.256.256) Either the IP address or name of the network interface. This field must correspond to an entry in the hosts file of the CS.
Page 42 of 87
4.11 Configure Carousels

The CS-1000 is designed with several types of carousels: the Carousel File System (CFS), the Private Data Carousel System (PDCS) and the External Data Source Carousel (EDSC). The CFS is the carousel used in connection with the CFS API. The PDCS is strictly a pass through stream that sends DCII Private Data across a defined PID. How that data is received and managed on the settop is strictly up to the ISV application on the settop box. The PDCS is commonly used for code downloads. The EDSC is used to multiplex data from multiple external sources. The default configuration for the CS-1000 is two CFS carousels, two PDCS carousels and one EDSC carousel. These carousels may be edited for use in your network, deleted, or added to as necessary. Note: Depending on the type of carousel you are adding or configuring, the CS GUI screens may vary in content.
Figure 4.11-1 - Carousels
Field Name Carousel Type
Description This field selects the type of Carousel to be added.
4.11.1 Add a Carousel

Once you have selected the type of carousel you want to create, the screens that are presented for further configuration of the carousel, its stream sets, and streams will vary slightly depending on whether you chose CFS, PDCS or EDSC. On the Add/Edit Carousel window, the difference in screen presentation is the addition of the CFS directory button once the new CFS carousel is saved. This button is located beside the Staging Area field and allows you to build the virtual directory structure that is used
Page 43 of 87
CS-1000 User's Guide by the ISV application to manage content data. This virtual directory structure appears under the carousel's mount point as defined in the CFS OOBTAB (e.g., /usr/TEST).
Figure 4.11-2 - Add/Edit Carousel
Field Name Carousel Name
Description An identifier that describes the carousel being configured. The carousel name may be up to 50 characters and should distinguish one carousel from another. View only field. The data for this field is chosen and edited on the main Carousel window. A 255 character field that may be used to further describe the type of data being sent on this carousel. The choices in this drop down field allow you to choose the status of the carousel at server startup. The values indicate whether the carousel will start automatically on server startup, or require a manual start using the Status and Control window. Note: Carousels configured with automatic startup will start automatically when the server is powered on. Carousels configured with either manual or disabled startup will need to be manually started using the CS GUI when the server is powered on.
Carousel Type Description Startup
Page 44 of 87
Field Name Staging Area
Description The directory where data is placed to be carouselled. Each carousel should have its own directory within the CS-1000s Staging Area directory. Note: Defining a specific staging area directory here for the CFS carousel does not create that directory on the CS-1000 server. You must still manually create this directory within the CS-1000s StagingArea directory on the server. Use the isv_user_add and isv_user_delete scripts to manage Staging Areas on a Sun Netra CS-1000.
CFS Dirs
This button is only present when creating a CFS carousel. It allows you to build the virtual directory structure that an application uses when making calls to the CFS API. (see Section 4.11.2) Note: This button only appears after a successful carousel Add.
Persistent Storage Area
DO NOT EDIT, DELETE or ACCESS ANY FILES IN THIS DIRECTORY ! This directory is where the CS-1000 database and carouselled data is stored. This directory also contains the raw data files that were loaded into the carousel from its Staging Area. These files remain in this directory until they are deleted. Additionally, operations files for the carousel are stored here. Note: All carousels can share the same Persistent Storage Area (PSA) since the CS-1000 separates persistent storage area data via well defined naming conventions. However, if separate directories are desired in the PSA, defining these directories in the GUI does not create them on the CS1000. You must still create the directories within the CS-1000s PersistentDataStore directory.
Staging Area Polling Interval
The frequency, in seconds, that the CS-1000 checks the Staging Area for new files.
Page 45 of 87
4.11.2 CFS Directory

The CFS Directory screen allows you to build a virtual directory structure for the current carousel. The virtual directory structure appears beneath the mount point for the carousel.
Figure 4.11-3 - CFS Directory
Note: Each CFS carousel has its own virtual root (/). This virtual root is mapped to a mount point (e.g., /usr/TEST) by the CFS API based on the CFS OOBTAB. Special Note: The CFS_MAIN carousel should have a single CFS Directory named /etc. This is the directory where the file named cfsoobtab should be loaded. This file defines the mount points for the CFS, or subdirectories of /usr. Application carousels should define CFS Directories as they see fit. This subdirectory structure will be present under each carousels mount point, ie: /usr/ISV_A Field Name Add Description Brings up the New Directory dialogue that allows you to add to the current directory structure. The directory is added below the item in the structure that is selected, i.e. if / is selected, the directory will be added off the root of the structure. Allows you to rename an existing directory. The directory you wish to rename must be highlighted before pressing Edit. Double clicking on an existing directory will also allow for the directory to be renamed. Allows you to delete the selected directory and subdirectories from the list. Allows you to delete the entire directory structure. You will be prompted to confirm this action before it is performed. Closes the current window and returns you to the Add Carousel screen.
Rename
Delete Clear Close
Page 46 of 87
4.11.3 Add a Stream Set

You may have one or more Stream Sets per carousel and one or more Streams defined per Stream Set. For instance, you may want to have one stream set for out-of-band data and one for inband (future capability). In the case of a CFS carousel, the stream set tracks the configuration of subordinate streams to produce operations data that enables the CFS API to locate and reassemble files.
Figure 4.11-4 - Add/Edit Stream Set
Field Name Stream Set Name Stream Set Type Refresh Interval
Description A 50 character field that identifies a particular stream set within the selected carousel. View only field. The data for this field is pre-determined based on the type of carousel that was selected. This field determines how often streams will be refreshed. Note: A Stream Set Refresh consists of updating content on time sensitive streams and rebuilding operations data if needed. If there are no streams in the stream set that carry time sensitive data it is reasonable to set the refresh interval to a very high value since stream refreshes occur automatically after content is uploaded onto a carousel.
Startup Enabled
When checked, the current Stream Set is automatically started when the carousel is started. When not checked, the stream set is not accessed by the carousel. A stream set may be disabled in order to trouble shoot a particular carousels operation, or when the selected stream set needs to be temporarily taken off line, but deleting the stream set is not desirable.
Page 47 of 87
4.11.4 Add a Stream

The Edit CFS Stream screen, illustrated in Figure 4.11-5, varies significantly depending on the type of carousel you are configuring the stream for, as well as what type of CFS configuration you are performing. The PDCS stream configuration screen is a subset of the CFS screen and contains only the Stream Name, Stream Type, Description, and Bit Rate fields. A CFS carousel stream window contains additional fields that pertain to the streams output and will vary depending on whether time sensitive data is being used and if you are sending broadcast or Multicast 16 addressed data. All field definitions for the CFS stream window are provided. PDCS fields share the same corresponding field definitions. An EDSC stream configuration, as shown later in this section at Figure 4.11-9, varies significantly from the CFS and PDCS stream configuration in that it only requires the input data source and output interface.
Figure 4.11-5 - Add/Edit Stream
Page 48 of 87
Field Name Stream Name Stream Type Description Bit Rate Service Name
Description A 50 character field that identifies a particular stream within the selected stream set. The data for this field is pre-determined based on the type of stream set that was selected. A 255 character field that may be used to further described the type of data being sent on this stream. An integer that defines the rate in bits per second that data is to be sent across the stream. The name of the service that will carry this stream, exactly as it appears in the headend controller. This is a 50 character field. Note: This Service must be manually configured into the headend controller prior to CS-1000 use. See Section 8.2 for instructions on setting up this service.
DCII Address
When configuring the stream as MCA-16, a unique multicast address must be entered. The valid range of values is 1 through 65534. When DCII Broadcast is selected as the Address type, this field defaults to 65535 and is not editable. Note: There is no automated duplicate checking on this field, so you must make certain that the DCII address entered is unique for the specified service name.
Time sensitive window size
Specifies a window size (in seconds) for which this stream should output files. The stream time window must overlap with the time sensitive attributes on a file for the file to be carouselled on the stream. Note: This field is only valid when Time Sensitive Files has been selected under Output.
Time sensitive window offset
Specifies an offset (in seconds) for the time window. Offset can be plus or minus. An offset is relative to either the current time, or to the beginning of the current day, based on the Time Sensitive Behavior for the stream. Note: This field is only valid when Time Sensitive Files has been selected under Output.
Time Sensitive Behavior
There are two valid values: Discrete sliding window and Continuous Slide window. Discrete sliding windows start at the beginning of the current day. The window always jumps 24 hours at a time. Continuous sliding windows start at the current time. Note: This field is only valid when Time Sensitive Files has been selected under Output.
Data Source Interface
A 50 character field used to descriptively name a Data Source. This field only appears in the EDSC stream. A 50 character field used to descriptively name an interface device.
Page 49 of 87
General Note: Time sensitive streams output time sensitive files that have ANY overlap with the streams time window. The streams re-evaluate their contents according at each Stream Set Refresh or content upload.
4.11.4.1 Select a Protocol

Figure 4.11-6 - Select a Protocol
Field Name MPEG Packet
Description When selected, data sent on the selected stream will be in the MPEG format. Note: Select this option when sending to a device that requires an MPEG stream (e.g., OM-1000). This option should be selected when setting up CFS streams, since the only interface currently supported is the OM-1000.
DCII Private
When selected, raw DCII private messages will be sent on the selected stream. Note: Select this option only when sending to a device that requires raw DCII messages.
4.11.4.2 Select an Address Type

Figure 4.11-7 - Select an Address Type
Field Name DCII Broadcast DCII MCA16
Description When selected, data sent on the selected stream will be broadcast addressed on the stream. When selected, multi-cast addressed messages will be sent across the selected stream.
Page 50 of 87
4.11.4.3 Output Configuration

Figure 4.11-8 - Output Configuration
Field Name Operations Data
Description When checked, indicates that the current stream will carry operations data for the carousel. Only one stream per carousel needs to send operations data. When checked, indicates that the current stream can carry non-time sensitive data. When checked, indicates that the current stream can carry time sensitive data. The Time Sensitive Window Size, Time Sensitive Window Offset and Time Sensitive Behavior fields must have values entered when this box is checked. When checked, indicates that data from all virtual directories can be sent on this stream. Opens the Output Directories window. This window displays the virtual directory structure defined on the Add Carousel screen and allows you to select specific directories to output on this stream. See the Output Directories section below for more details. Note: This button is only available after a successful stream Add.
Non-time sensitive files Time sensitive files
All Directories Output Dirs
Page 51 of 87
4.11.5 Output Directories

The Output Directories screen allows you to choose which virtual directories will be output by the associated stream. Only content loaded into the selected virtual directories will be output on the stream. Select all virtual directories and subdirectories that you wish to output data for. Selecting a parent directory will not output the data loaded in its subdirectories. This window is only available when configuring CFS Streams.
Figure 4.11-9 - Output Directories
Field Name Update Clear Close
Description Saves your selections into the database and closes the window. Allows you to clear all selections. You will be prompted to confirm this action before it is performed. Closes the current window and returns you to the Add CFS Stream screen. Any selection changes will not be saved.
Page 52 of 87
4.11.6 Edit an EDCS Stream
Figure 4.11-10 - EDCS Stream Configuration
4.11.7 Edit Stream_Interface

Note: The Edit Stream Interface screen is the same for all types of carousel streams with the same field definitions pertaining to each stream type. The Stream Interface association allows the user to specify which PID this stream should use when sending data to this interface. The Add button in the Output Interfaces section of the Stream window will bring up the list of devices you created in the Interfaces menu area, or allow you to add an interface now. In either event, when you select or create an interface to configure, you will need to have the packet ID (PID) associated with that service in the headend controller. See Section 8, CS-1000 Setup in a Local Headend for instructions on obtaining this PID.
Page 53 of 87

Figure 4.11-11 - Edit Stream Interface
Field Name Interface Name Packet ID Stream (PID)
Description A 50 character field used to descriptively name an interface device. The MPEG PID that this stream should use when sending data to this interface. Note: This PID value is not used when the stream is sending only raw DCII messages (refer to the Select a Protocol section).
4.11.8 Edit Stream_DataSource

The Stream Data Source association allows the user to specify which PID this stream should use when receiving data from this data source. The Add button in the Data Source section of the Stream window will bring up the list of data sources you created in the Data Sources menu area, or allow you to add a data source now. In either event, when you select or create adata source to configure, you will need to have the packet ID (PID) that you wish to receive data from.
Figure 4.11-12 - Edit Stream Data Source
Field Name Data Source Name Packet ID Stream (PID)
Description A 50 character field used to descriptively name an data source device. The MPEG PID that this stream should use when receiving data from this data source.
Page 54 of 87
5 CFS Content Management

This section discusses content management using a CFS carousel. A similar process for staging DCII files onto PDCS is discussed in Section 6. The CFS does not provide any authoring or content creation tools, since content is application specific. It is the ISV's responsibility to provide content to the CFS carousel for transmission. The CFS Carousel delivers application specific files verbatim. It does not require files to adhere to any particular format. Content management is performed via simple file transfers. Each CFS Carousel is given a separate staging area directory on the CS-1000, from which content is processed and uploaded into the Carousel. Application specific content should be transferred to this directory using FTP.
5.1
Managing StagingAreas and FTP User Logins
Application content is transferred to the CS-1000 staging area by way of FTP. Each ISV or user will have their own user login which will, upon successful login, put the user in their correct staging area directory. The script used to create these users also creates a corresponding directory within the /export/home/CS/StagingArea directory. Each user will be restricted to their own area and will be unable to access any other area of the system.
5.1.1 Add an ISV User

This script will create a directory for isv1 at /export/home/CS/StagingArea/isv1. Once logged in as isv1 it will appear as though you are logged in at /, this is intended. The working directory appears to be / because the isv1 user does not have the privilege to change directories outside of its own area, although it can create directories within its own area. 1. Login as root to the CS-1000 network card 0 via telnet. 2. Type isv_user_add and follow the prompts to create a user (isv1) and a corresponding StagingArea directory. 3. Logoff as root. 4. Login as the newly created user on either network card.
5.1.2 Delete an ISV User

This script will remove the ISV user login as well as the associated directory within the StagingArea and all subdirectories and files located within. 1. Login as root to the CS-1000 network card 0 via telnet. 2. Type isv_user_delete and follow the prompts to delete a user (isv1) and a corresponding StagingArea directory. 3. Logoff as root.
Page 55 of 87
5.2
Metadata File Format
In order for the content to be uploaded, an accompanying metadata file must be provided. The metadata file is a simple text file that describes the content within the staging area. Streams eventually use the metadata to select content for output. Each line of metadata contains the following pipe (|) delimited data:
Table 5.2-1 - CFS Metadata File Format
Field Staging Area Filename
Type String
Description Name of application specific file loaded into the staging area (physical file name). This filename does not have to match the CFS Filename. Fully qualified virtual directory path/file name to be used on the CFS. This can be different from the Staged Filename. The CFS Filename is the file name specified when calling CFS API functions. This path is relative to the virtual root of this particular CFS carousel. For example, if the mount point for this carousel is /usr/ISV_A, then "/test.txt" will place the file "test.txt" in /usr/ISV_A (i.e., /usr/ISV_A should not be specified). However, if a subdirectory exists under /usr/ISV_A (e.g., /usr/ISV_A/mydir), then "/mydir/test.txt" will place the file "test.txt" in /usr/ISV_A/mydir.
CFS Directory Path and Filename
String
CFS File Date
Formatted date string: yyyymmdd hh:mm:ss yyyy = 4 digit year mm = 2 digit month (1-12) dd = 2 digit day (1-31) hh = 2 digit hour (0-23) mm = 2 digit minute (0-59) ss = 2 digit second (0-59)
Date/Time the file was last updated.
CFS File Expiration Date CFS Data Date Range
See above. Formatted date range:
Date/Time that this file should be removed from the CFS. Holds the date range to which the data within the file pertains. If the data is not time related, this field should be left BLANK.
yyyymmdd hh:mm:ss-yymmdd hh:mm:ss
Page 56 of 87
CS-1000 User's Guide The figure below illustrates the format of a metadata file:
Figure 5.2-1 - CFS Metadata File Format Illustration
Staging Area File Name CFS Directory Path & File Name
CFS File Date (last updated)
CFS File Expiration Date
Time Sensitive Data Date Range
test.txt|/content.txt|20001214 00:00:00|20001231 23:59:59|20001214 00:00:00-20001231 23:59:59
5.3
Rules for using Metadata Files

The metadata fields allow for content to be added, updated, or removed based on their settings. If the file specified by a line of metadata does not exist on the applications Carousel, it will be added. If the file specified by a line of metadata already exists on the Carousel it will be updated. An existing file can be removed by (1) Leaving the Staging Area Filename blank and (2) Setting a CFS Expiration Date prior to the current date/time. Content files can also be updated and expired using the Content Management screen in the CS GUI. The CS-1000 will not process content in the staging area until there is a corresponding trigger file copied to the staging area. This ensures that content will not be processed before the copy process has completed. For example, it may take a significant amount of time to copy content and metadata files to the staging area. It is not desirable to have the CS-1000 begin processing these files while the copy is taking place. It is mandatory that the trigger file be copied to the staging area only after the content and metadata files have been copied completely. This order in which files are copied into the Staging Area is irrelevant if the carousel is stopped. The metadata file must be named CFS_METADATA_*.cmd. The associated trigger file must have the same name as its corresponding metadata file, but with a .trg extension. Example: CFS_METADATA_MYCONTENT.cmd CFS_METADATA_MYCONTENT.trg
Trigger files can be zero length. The contents of the trigger file are not relevant. Multiple metadata files can be uploaded simultaneously provided they are uniquely named. These files would then be processed in date order. Dates used in metadata must not specify a date past 20371231 23:59:59. Metadata files can have multiple entries, for example: apple.txt|/apple.txt|20000214 00:00:00|20101231 23:59:59| orange.txt|/orange.txt|20000214 00:00:00|20101231 23:59:59| grape.txt|/grape.txt|20000214 00:00:00|20101231 23:59:59| banana.txt|/banana.txt|20000214 00:00:00|20101231 23:59:59| grapefruit.txt|/sour/grapefruit.txt|20000214 00:00:00|20101231 23:59:59|20011231 00:00:00-20011231 23:59:59 cherry.txt|/cherry.txt|20000214 00:00:00|20101231 23:59:59| strawberry.txt|/strawberry.txt|20000214 00:00:00|20101231 23:59:59|
Page 57 of 87
5.4
CFS OOBTAB Metadata File
The CFS OOBTAB file must be placed in the staging area corresponding to the CFS_MAIN carousel (Service = CFS_MAIN, MCA-16 = 1). When creating the CFS OOBTAB file from the GUI, any valid file name can be used. However, the CFS file name must be cfsoobtab (all lowercase), and the file must be placed in "/etc". Since the virtual root for this file system is "/", the CFS Directory Path and Filename must specify the "/etc" directory. The complete entry is "/etc/cfsoobtab". In the example below, a CFS OOBTAB file is created from the GUI and saved as myoobtab. It must be placed in "/etc" as "cfsoobtab". myoobtab|/etc/cfsoobtab|20000726 00:00:01|20101231 23:59:59| Note: If you FTP this file to the CS-1000 (Netra), ensure that the transfer mode is set to binary. The CFS OOBTAB file you create from the GUI is a binary file.
6 PDCS Content Management

Like the CFS, content management is provided via a staging area, but the contents of the files must be in DCII format, whereas the CFS delivers any arbitrary file. The DCII private messages are delivered to DCTs verbatim. Unlike the CFS, the PDCS does not present a virtual file system to a DCT client application, and the CFS API does not apply to PDCS carousels. The following guidelines apply to PDCS content management: The PDCS polls for a trigger (".trg") file, and then uploads and carousels a similarly named ".dat " file. The ".dat" file must contain raw DCII messages. The PDCS does not require a metadata file to be placed in the staging area. PDCS can carousel any arbitrary set of DCII messages. For example, the PDCS can be used to support delivery of code download related messages (see Section 7. Code Download Generator (CDG)) Each upload replaces the prior upload. To empty out a PDCS, upload an empty ".dat" and "trg" file to the staging area. A PDCS carousels the contents of the uploaded ".dat" file over all of its configured stream sets and streams. In general, a PDCS carousel should only be configured with a single stream set and stream.
7 Code Download Generator (CDG) and DCII Message Generator (DMG)

The CDG is a tool that allows you to turn a raw code object into a DCII Code Download File as well as create DCT Download Control messages for tuning and enabling objects on the DCT 1000/1200/2000s and DCT5xxxs. The DMG tool allows you to create a series of DCII messages based on arbitrary payloads. The generated DCII messages, along with a .trg file will need to be placed in the staging area to be downloaded to DCT(s) via a PDCS carousel. Preambles and specific address types may be defined either globally or locally for each type of message contained in either the CDG or DMG file. These messages can then be sent to the DCT using a PDCS carousel in place of a DAC, DLS, or DCCG.
Page 58 of 87
CS-1000 User's Guide The following files are used with the CDG tool: cdg.bat A batch file that resides in the ..\CodeDownload directory on the Windows NT workstation. This file processes the XML file and generates a .dat file (see cdg.dat below). It also creates a corresponding trigger file. An XML file that you create/edit with the specific preambles, address types, tuning commands, download control commands and code object specifications for the object you are downloading. A file that is created based on the XML file that you create. This file is automatically created by the CDG batch file and contains either the code object or generic DCII messages to be downloaded. It must be placed in the appropriate Staging Area on the CS server for download by the PDCS carousel. A file that is automatically created by the CDG batch file. Its presence triggers the upload of the .dat file and therefore should be placed in the PDCS staging area after the .dat file is in place. The object file(s) of the code you are downloading to the DCT. This file can either be placed in the CodeDownload directory or you can path to its location in the XML file.
cdg.xml
cdg.dat
cdg.trg
code object (.obj) file(s)
The following files are used with the DMG tool: dmg.bat A batch file that resides in the ..\CodeDownload directory on the Windows NT workstation. This file processes the XML file and generates a .dat file (see dmg.dat below). It also creates a corresponding trigger file. An XML file that you create/edit with the specific preambles, address types, for the DCII messages you are generating. A file that is created based on the XML file that you create. This file is automatically created by the DMG batch file and contains the generic DCII messages containing the arbitrary data to be carouselled to the DCT. It must be placed in the appropriate Staging Area on the CS server for download by the PDCS carousel. A file that is automatically created by the DMG batch file. Its presence triggers the upload of the .dat file and therefore should be placed in the PDCS staging area after the .dat file is in place. The binary data file that is referenced in the message tag of the dmg.xml and included in the DCII message output. This file contains the payload data. A text file containing the unit addresses that you wish to have the message sent to. This file is referenced by the address location field in the dmg.xml file.
dmg.xml dmg.dat
dmg.trg
binary data files address file (.txt)
7.1
CDG XML File Format
CDG processes XML based input files to produce DCII stream files. XML files can be created using Notepad or similar Windows editor and saved using any file extension, however it is recommended you use the .xml extension in order to readily distinguish the file. CDG allows multiple code/data objects, commands, and DCII messages to be specified within a single XML file, which is then processed in the specified order into a single DCII stream file. CDG output is compatible with the CS-1000 PDCS Carousel.
Page 59 of 87
XML uses tags to denote commands. The following tags are used to create the DCII message:
<CDG> <PREAMBLE> <ADDRESS> <DCT_DOWNLOAD_CONTROL> <PREAMBLE> <ADDRESS> <ENABLE> <DISABLE> <DELETE> <PURGE> <TUNE> <DETUNE> <CONDITIONALLY_TUNE> <BOOT_CODE_CONTROL> <ASTB_TUNE> Opening tag indicating that this file is intended for CDG processing. Assigns a preamble for all following messages (optional - default is no preamble). Assigns an address/type to all following messages (optional - default is BROADCAST) Beginning tag for the DCT Download Control commands. A single message can contain several Download Control subcommands. Specifies a preamble only for this message (optional - defaults to "global" preamble) Specifies an address only for this message (optional - defaults to "global" address) Specifies an enable subcommand Specifies a disable subcommand Specifies a delete subcommand Specifies a purge subcommand Specifies a tune subcommand Specifies a detune subcommand Specifies a conditional tune subcommand for a DCT 1000/1200/2000. Note: This subcommand is not valid for DCT5xxx's. See ASTB_TUNE. DCT5xxx ONLY subcommand. Specifies a boot code control subcommand for downloading Base code. DCT5xxx ONLY subcommand. Specifies an ASTB tune subcommand. This subcommand is used in place of the conditionally_tune command used by the DCT 1000/1200/2000. Beginning tag for the DCT Download message. This message contains the object's definition (see Section 7.3.2) Specifies a preamble only for this message (optional - defaults to "global" preamble) Specifies an address only for this message (optional - defaults to "global" address) DCT5xxx ONLY message. Beginning tag for the Object Conditional Access message. This message indicates the current structure of the message. Specifies a preamble only for this message. Specifies an address only for this message.
<DCT_DOWNLOAD> <PREAMBLE> <ADDRESS> <OBJECT_CONDITIONAL_ACCESS>
<PREAMBLE> <ADDRESS>
Rules when creating the CDG XML files are as follows:

All tags must have matching end tags. For example, <tag> ... </tag>. End tags may be abbreviated when there is no expression or value that needs to be specified within its body. For example, <tag ... /> CDG is NOT case sensitive (except for code/data object names). For example, <AdDreSS TyPe='"broadCAST"/> is equivalent to <ADDRESS type="BROADCAST"/>.
Page 60 of 87

CDG accepts both decimal and hexadecimal input values. Hex values must be preceded with "0x" (e.g., 0x2BD). When using the PURGE or DELETE commands a wild card value can be used. For example, **.** can be used in place of the version number. Whitespace can be used as desired to achieve readability.
7.2
DMG XML File Format
DMG processes XML based input files to produce DCII stream files. XML files can be created using Notepad or similar Windows editor and saved using any file extension, however it is recommended you use the .xml extension in order to readily distinguish the file. DMG allows multiple DCII messages to be specified within a single XML file, which is then processed in the specified order into a single DCII stream file. DMG output is compatible with the CS-1000 PDCS Carousel. XML uses tags to denote commands. All of the rules that pertain to CDG XML files apply to DMG XML Files (see Section 7.1). In addition, the following rules apply when generating generic DCII messages using the DMG tag: A Preamble tag can be applied either globally or locally. An Address tag can be applied either globally or locally. Only one Preamble is allowed within a Message tag. If there are multiple Preambles, only the last is applied to the subsequent Message tag(s). The global Address tag will be applied to all following Message tags as long as there are no local Address tags. If a location for a file containing DCT addresses is specified inside the Address tag, any DCT address specified between <ADDRESS> and </ADDRESS> will be ignored.
7.2.1 DCII Message Generator (DMG) Tags

The DMG tag is used to define and generate a DCII message that contains arbitrary payload. The possible tags associated with DMG are:
<DMG> <PREAMBLE> <MESSAGE> <ADDRESS> Beginning tag for the definition of DCII messages for an arbitrary payload. Specifies a preamble for this message. Specifies the location and attributes of the input payload data. Specifies the unit addresses that you wish to have the message sent to.
The Address tag is optional and specifies how the generic DCII message is addressed. If no Address tag is used, the message is broadcast. The Message tag is required and specifies the payload data to be included in the generic DCII message. The intended DCII message payload must be defined in the Message tag within the DMG tag. The message description contains the following information:
Page 61 of 87
Parameter location
Description Required field that specifies where the file that contains the DCII payload is located on the local machine. Optional field that specifies, in bytes, where in the file to start processing data relative to the start of the file. The size of the DCII payload data, in bytes, that you want the message(s) created with.
Default Value None, it must be specified.
offset
size
count
The number of messages to generate. If greater than 1, each message is generated based on the size of the previous message. The DCII message type. For private data, 0xB0 has been reserved in the Motorola network for this message type.
If a location is specified, the size is optional and will default to the size of the DCII data in the file or the max payload size, whichever is smaller. When the max payload size is reached, a message is generated for the user, and excess payload will be ignored. NOTE: size is only optional if the count value is one. 1
type
0xB0 (176 decimal), private data.
When creating DCII messages, an optional Address tag can be used to define the addressing mode(s) for the message. In addition, the Address tag allows you to point to a file that contains the unit or multicast addresses that you wish the message sent to. NOTE: This address file option is only available for DMG Address tags and not CDG message Address tags. Also note that the offset, and count parameters are only meaningful when location specifies an external file. The definitions and default values for the Address tag parameters are as follows:
Parameter location
Description Optional field that specifies where the address file is located on the local machine. This can be used to hold a group of singlecast addresses. If no file is specified, it is assumed a single address is specified within the Address tag. Optional field that specifies the start line (address) in the address file. A 0 in this field will be treated as a 1. NOTE: It is assumed that the file containing the addresses has a single address per line. The number of addresses to use from the address file when generating messages. This is meaningful only when using SINGLECAST or MULTICAST16 address types. The DCII address type. The options are: BROADCAST, SINGLECAST, and MULTICAST16.
Default Value None
offset
count
type
BROADCAST
Page 62 of 87
7.2.1.1 Multiple Global and Local Address Tags

The Address and Message tags can be used both locally and globally in the XML file. If multiple global Address tags are used the last global Address tag in the markup is applied. This is true for the cases when addresses are specified explicitly and also for when addresses are specified in an external file. If multiple local Address tags are used then the message is sent to all addresses specified.
7.2.1.2 Examples of a DMG Tag for DCII Message Creation

The following is an example of a full DMG tag definition followed by a description of each line in the tag. NOTE: Line numbers are not required in the tag, they are used in this example as reference points for the explanation that follows. 1 2 3 4 5 6 7 </DMG> <DMG> <ADDRESS type=SINGLECAST>285534100</ADDRESS> <MESSAGE location = C:\temp\P-0.bin type=176 offset=0 size=44 count=1> <ADDRESS type=SINGLECAST location=c:\temp\input.txt offset=2 count=3>275882248</ADDRESS> </MESSAGE> <MESSAGE location = C:\temp\P-ALL.bin type=176 offset=0 size=44 count=2/>
The following describes each line of the example shown above. Line 1 2 3 Definition Opening DMG tag Global address that is applied to the second Message tag only (since there is no local address tag), and provides the unit address for a specific DCT. Opening tag and definition for Message 1 where: location = payloads filename and path type = private data (defined in decimal) offset = none, data will be read from the first line of the file when creating the DCII message size = 44 bytes will be read in from the payload file count = 1 DCII message will be generated Local address that is only applied to the local Message tag since it falls within the messages start and end tag. The address 275882248 will be ignored since the input file location is provided. type = SINGLECAST, MULTICAST16 or BROADCAST location = address filename and path offset = starting from line 2 in the address file count = total of 3 addresses (from line 2 to line 4) will be used in the address file when generating messages Closing tag for first Message tag. Opening tag and definition for second group of messages. This message tag generates two messages, in a single file, since the count = 2. Note: An abbreviated end tag is used and the global address is applied to these messages, as there is no local address defined. Closing DMG tag.
5 6
7.3
PDCS Streams
PDCS will carousel any message contained in a properly formatted .dat file across any stream; however, certain messages are received by the DCT only on either the EMM or NET PID (tunes, download control messages NOT associated with an object) while others are received only on an application download PID
Page 63 of 87
CS-1000 User's Guide (i.e., code objects, download control messages associated with a code object). Therefore, separate carousels should be created for each "type" of message. In addition, it may be preferable to create a separate carousel for each type of code object (firmware vs. applications) so that better control can be maintained over the sending of these objects and individual objects can be stopped once the object is received by the DCT. This will allow you to maximize your bandwidth by setting different bit rates for each type of object based on its size, as well as save bandwidth by allowing you to stop spinning objects that have already been downloaded. Special Note: In a nationally controlled headend the AC provides conditional tune messages on the EMM PID. When using the CS-1000 as a code tool, all conditional tune messages should be configured to be placed on the Network PID. The reason for this is that the OM can not multiplex messages from multiple sources on the same PID. This means that there will be a small amount of message loss due to collisions between the two sources. The Network PID is used for locally generated conditional tune messages because all of the messages on the Network PID are repeated. Therefore, if a message is lost it is not critical since the message will be repeated.
7.3.1 Control Stream Message

CDG supports DCII message creation for all types of tunes, including conditional tunes. In addition, preambles may be added to the message to further define when a DCT should tune for an object download. The following example is a tune command that will be single cast to a specific DCT 1000/1200 or 2000, based on unit address, and contains a conditional statement for tuning to channel 701 only if Platform version 6.44 is present on the box. <CDG> <ADDRESS type="SINGLECAST">0x1A9F1F3</ADDRESS> <DCT_DOWNLOAD_CONTROL> <CONDITIONALLY_TUNE virtualChannel="701" name="Platform" version="6.44"/> </DCT_DOWNLOAD_CONTROL> </CDG> SPECIAL NOTE: There are three other values that may be included as part of the conditional tune message. These are: virtual application ID the application's ID as defined in the Download Object Summary in the object's text file. segment zero timeout specifies the number of minutes that the DCT should wait for segment zero of the target object. object enable timeout specifies the number of minutes that the DCT should wait for the object enable of the target object. These fields are seldom specified in the conditional tune command and will default appropriately if not included.
7.3.2 Code Download Message

Messages containing a raw code object need a stream configured with the MPEG PID for the defined application download channel that the DCT is tuned to. In addition, the code object must be defined within the DCT_DOWNLOAD tag inside the XML file. The object's description contains the following information:
Page 64 of 87
location application ID application version object class object name object version object type storage class object's variable space size constructor offset destructor offset segment zero repeat
where the object file is located on the local machine the application's unique ID as defined in the Download Object Summary in the object's text file. the application's version number as defined in the Download Object Summary in the object's text file. the object's download classification (i.e., "platform", "application") the name of the object as defined in the Download Object Summary in the object's text file. the version of the object defined in the Download Object Summary in the object's text file. the object's type, i.e., "data" or "executable". where the object will be stored on the settop box (i.e., "volatile", "non-volatile", "flash", "any") as defined in the Download Object Summary in the object's text file or, in the case of the DCT5xxx, the PROS generated .dat file. as defined in the Download Object Summary in the object's text file or, in the case of the DCT5xxx, the PROS generated .dat file. as defined in the Download Object Summary in the object's text file or, in the case of the DCT5xxx, the PROS generated .dat file. how often the first segment of the object is to be sent during download. Regularly sending the first segment of the object can speed up the time that it takes to download the object.
Most of the DCT Download information is obtained from the Downloader Object Summary that accompanies the code object. This can be obtained from the .txt file or .dat file. Note: The .dat file is created from a given object and .txt file. The following is an example of this summary (fields in bold are ones used in the XML object description). ---- Downloader object summary ----Object name and ver: 'CFS_APIS' '03.00' Object length: with header: Variable space size: Constructor offset : Destructor offset : Application ID: Application version: Checksum: Normal segment size: Final segment size: Total segment count: Addressing mode: $0000B6C0 (46784) $0000B6EB (46827) $00005354 (21332) $00000146 (326) $00000452 (1106) $07D0 (2000) $00000001 (1) $0040B6B7 (4241079) $01F3 (499) $01A4 (420) $005E (94) B
Page 65 of 87
CS-1000 User's Guide The following example is a message that downloads and enables new platform on the settop box and deletes the older version of platform that it's replacing. Since there is no ADDRESS tag in the message, the message is sent Broadcast. <CDG> <DCT_DOWNLOAD_CONTROL> <DELETE name="CFS_APIS" version="02.00" type="executable"/> <ENABLE name="CFS_APIS" version="03.00" type="executable"/> </DCT_DOWNLOAD_CONTROL> <DCT_DOWNLOAD location="c:\CS\CodeDownload\downloadObject.obj" appID="2000" appVersion="1" objectClass="application" objectName="CFS_APIS" objectVersion="03.00" objectType="executable" storageClass="non-volatile" svarsize="21332" constructorOffset="326" destructorOffset="1106" repeatSegmentZero="5" </DCT_DOWNLOAD> </CDG>
7.4
DCT5xxx Specific Subcommands and Messages
The CDG is able to support code downloads on the DCT5xxx platform. Messages for the DCT5xxx are similar to those used on the DCT 1K-2K; however, three additional messages are specific to only the DCT5xxx and must be used when downloading objects to these settops: Boot_Code_Control, ASTB_Tune, and Object_Conditional_Access (a further description of these messages content and use follows in the proceeding sections). In addition, a system called the Permissions, Resources, Object Signatory (PROS) is used to create the necessary files for object download messages to the DCT5xxx. Figure 7.3-1 shows the input and output of the various systems used in the download process for both national and local control headends.
file.DAT file.OBJ Resource Permissions
file_AC.DAT file_AC.OBJ file_AC.OCA file_AC.ECD RCDS.OCA
CS
CDG
CDG_file.dat CDG_file.trg
PROS
cdg.xml
PDCS
UNDP or OM
Bootcode Subcommand ASTB_tune_download Subcommand OCAM Message DCT_download Message
Figure 7.3-1. File process for DCT5K downloads
Page 66 of 87
7.4.1 Boot Code Control

This subcommand is used to find a new DCT download control message within an OOB control stream. It is used when downloading Base Code to the DCT5xxx. Although not called out in the message, the storage class for the boot code is Flash. The definitions for each field of this message are as follows: Note: Unless otherwise noted, all fields are required and should be defined for proper code download to the DCT5xxx. CDG does not validate field values. While CDG may create a .dat and .trg file, this does not ensure that the object(s) described will download properly unless the message's field values are valid. Default field values are not always valid. platform ID oob download Differentiates between unique digital platform images in the field. It is set at the factory. The default value for this field is "256". Indicates whether the Base Platform image is being carried in the out-of-band or inband. Valid values for this field are "yes" or "no". The default for this field is "yes". Indicates the PID for the Base Platform Code Object. This field must be defined for successful download to the DCT5xxx. The default value is the null PID. This field is not required for CDG operation, however is necessary for successful DCT5xxx download. Specifies the center frequency where the Base Platform Code Object is carried. The default for this field is "0". Frequency values are defined in increments of 100 Hz. Not a required field. Defines the symbol rate in symbols. This field is not currently used on the DCT5xxx. Not a required field and currently not used on the DCT5xxx. Specifies the modulation scheme used on a cable delivery system. The default field value is "unknown". The valid CDG values are "unknown", "qpsk", "bpsk", "oqpsk", "vsb_8", "vsb_16", "qam_16", "qam_32", "qam_64", "qam_80", "qam_96", "qam_112", "qam_128:, "qam_160", "qam_192", "qam_224", "qam_256", "qam_320", "qam_384", "qam_448", "qam_512", "qam_640", "qam_768", "qam_896", and "qam_1024". Not a required field and currently not used on the DCT5xxx. Specifies the out FEC scheme (transmission system). The default field value is "unknown". The valid CDG values are "unknown", "ITU_T_annex_A", "ITU_T_annex_B", "ITU__R", "ANSI", "Digicipher", "ITU_T_annex_C", and "ITU_T_annex_D". Not a required field and currently not used on the DCT5xxx. Specifies the inner FEC scheme. The default field value is "none". The valid CDG values are "none", "5_11 "1_2, "val2", "3_5", "val4", "2_3", "val6", "3_4", "4_5", "5_6", "val10", "7_8", "val12", "val13", and "val14" Specifies the subscriber authorization center that "owns" the DCT OOB processor. The default field value is "0". System unique field that is assigned by the PROS. This value can be found in the .dat file created by PROS. The default field value is "0".
download PID
frequency
symbol rate modulation
fecOuter
fecInner
emm Provider ID object ID
Page 67 of 87
location
Defines the location (path) to the *.ecd on the local machine. The ECD file is a product of the PROS system (see Figure 7.3-1). There is no default for this field. This field is not required for CDG operation, however is necessary for successful DCT5xxx download.
The following example shows the syntax for a boot_code_control message: <CDG> <DCT_DOWNLOAD_CONTROL>
<BOOT_CODE_CONTROL
platformID="256" oobDownload="yes" downloadPID="1550" frequency="7525" symbolRate="0" modulation="unknown" fecOuter="unknown" fecInner="none" emmProviderID="0x123" objectID="1234" location="c:\dct5xxx\pros_files\file.ecd"/>
</DCT_DOWNLOAD_CONTROL> </CDG>
7.4.2 ASTB Tune

This subcommand is the equivalent of a Conditionally_Tune download message is the DCT1k-2k and instructs the DCT to acquire an object based on the criteria of the subcommand. The definitions for each field of this message are as follows: Note: Unless otherwise noted, all fields are required and should be defined for proper code download to the DCT5xxx. CDG does not validate field values. While CDG may create a .dat and .trg file, this does not ensure that the object(s) described will download properly unless the message's field values are valid. Default field values are not always valid. operating environment Indicates the operating environment that the message will execute in based purely on object_class. When not defined, the default is "any". Valid values are "any", "platform_object", "system_object". When enabled, directs the DCT to purge all objects in the list with an object_version that is different than the one listed in this message. When not defined, the default is "no". Valid values are "yes" or "no". When enabled, directs the DCT to automatically enable the entire list of objects in the message after successful acquisition of all objects in the message. When not defined, the default is "no". Valid values are "yes" or "no".
auto purge enable
auto list enable
Page 68 of 87
time out field enable
When enabled, indicates that the intersegment_timer and list_enable_timer field overlays are present within this message. When not defined, the default is "no". This field is only meaningful if the tune download function is set to "conditional_tune" and specification of intersegment_timer and list_enable_timer is desired. Valid values are "yes" or "no". Valid definitions for this field are "detune", "tune" and "conditional_tune"; HOWEVER, detune and tune are not used in the DCT5xxx and have merely been maintained for compatibility purposes. The default for this field is "conditional_tune". Identifies a list of objects so that operations may be performed on the list as opposed to individually on each object in the list. The default for this field is "0"; HOWEVER, this is a reserved definition that is invalid for downloads and should be changed in order for the DCT5xxx to be able to accept the download object(s). Identifies the version of the list in a message. Together the List_ID and List_Version will identify a duplicate message. The default for this field is "0"; HOWEVER, should be defined properly for successful download to occur. One of two watchdog timers that may be used with a conditional tune subcommand. Definition of this field is only meaningful if the time_out_field_enabled is "yes". The default value for this field is "0". The second watchdog timer that may be used with a conditional tune subcommand. Definition of this field is only meaningful if the time_out_field_enabled is "yes". The default value for this field is "0".
tune download function
list ID
list version
intersegment timer
list enable time
A submessage within the ASTB_Tune command is an object description. The values for this message can be obtained from the object's .dat file and produced by the PROS system. The field definitions for this message are: vct ID Specifies the virtual channel table that is applicable to the message. The default value for this field is "0", however should be defined properly for successful download to occur. Specifies the channel that the DCT should tune to acquire the download object(s). The default value for this field is "0", however should be defined properly for successful download to occur. Specifies the physical address where the code will be loaded. Only a platform_object or a system_object may have an absolute physical address. The default value for this field is "0". When not specified, the object is automatically defined as being relocatable. System unique field that is assigned by the PROS. This value can be found in the ECD file created by PROS. The default field value is "0", however should be properly defined for successful download to occur.
download channel
absolute address
object ID
Page 69 of 87
object class
Provides an enumerated definition of the type of code object. It follows the same definition as the DCT_download message. The default value for this field is "managed_object" that indicates an object other than firmware or middleware. Required field. Identifies the name of the download code object. There is no default value for this field. Required field. Identifies the version of the downloaded code object. There is no default value for this field. Specifies the required storage for the download object. Currently, all DCT5xxx downloads are targeted to flash, and all other values for this field should be ignored. The default value for this field is "flash". The valid CDG values are "flash", "volatile", "nonvolatile", and "any". Specifies the ROMMABLE size of the encapsulated code_object. Note: This object size should be taken from the PROS outputted .dat file, not the original .dat file. The default value for this field is "0", however should be properly defined for successful download to occur.
object name object version storage class
object size
table extension
Integer number used by the decoder to differentiate between different objects being sent on the same transport multiplex. Special Note: This number will correspond to the order of the objects as they appear in the DCT_DOWNLOAD_CONTROL message with the first object listed having a table extension of "1", the second "2", etc. The default value for this field is "0", however should be properly defined for successful download to occur.
Most of object description is obtained from .dat file produced by the PROS. The following is an example of this summary (fields in bold are ones used in the XML object description). Object NAME APPID APPVER TYPE VERSION IMAGE CLASS STORE SIZE SVAR CONSTRUCTOR DESTRUCTOR DESCRIPTION RELOCATABLE ABSOLUTEADDR
"TESTAPP" 2012 101 CODE 13.51 "dvt1351-AC SYSTEM_OS FLASH 8973452 0 0 0 "GI App OS System Object" NO 473956352
Page 70 of 87
OBJECT ID End
131858435
The following example shows the syntax for an ASTB_Tune message: <CDG> <DCT_DOWNLOAD_CONTROL> <ASTB_TUNE operatingEnv="any" autoPurgeEnable="no" autoListEnable="no" timeoutFieldEnable="no" tuneDownloadFunction="conditional_tune" listID="0" listVersion="0" intersegmentTimer="0" listEnableTimer="0"> <OBJECT_DESCRIPTION vctID="5" downloadChannel="702" absoluteAddress="0" objectID="126125168" objectClass="managed" objectName="CFS_APIS" objectVersion="03.10" storageClass="flash" objectSize="1328" tableExtension="1"/> <OBJECT_DESCRIPTION vctID="5" downloadChannel="702" absoluteAddress="473956352" objectID="856753985" objectClass="managed" objectName="TEST_APP" objectVersion="02.00" storageClass="flash" objectSize="1666" tableExtension="2"/> </ASTB_TUNE> </DCT_DOWNLOAD_CONTROL> </CDG>
7.4.3 Object Conditional Access

This message indicates whether or not an Object Entitlement Message is an Entitlement Control Data Structure (ECDS) or a Resource Control Data Structure (RCDS). The syntax for this message is the location of the objects OCA message, which is an output of PROS (see figure 7.3-1). <OBJECT_CONDITIONAL_ACCESS location="c:\dct5xxx\pros_output\file.OCA"/>
Page 71 of 87
7.5
Preambles
Code download messages may be addressed to specific sets of terminals through the use of an optional message preamble. The preamble contains an expression consisting of decoder conditional terms and logical operators. Rules when constructing preambles are as follows:

they may be used at any point in the message as well as at multiple points. (i.e., CDG tag level, DCT Download Control tag, and/or DCT Download tag level . a preamble may be used in conjunction with any other addressing mode (i.e., broadcast, singlecast, multicast). terms may be combined with the following operators: and, or, not. For example, <preamble> family_id(1) and model_id(1) </preamble> parentheses may be used to construct more complex expressions. For example, <preamble> (family_id(1) or family_id(2)) and not enabled_for_ippv() </preamble>
The complete list of preamble decoder conditional terms and their arguments are as follows: activation_time( activation_time ) analog() appl_version( application_id, application_version_level ) auth_state( state ) authorizable( program_epoch_number ) authorized( program_epoch_number ) bought( program_epoch_number ) can_buy( program_epoch_number ) category_sequence( sequence_number ) channel_locked_out() circle( circle ) circular_blacked_out( program_epoch_number ) connected() country_code( country_code ) credit_balance( credit_balance_threshold ) currency_region( currency_region_id ) current_channel( current_VCT_id, current_virtual_channel ) dena_version( major, minor ) enabled_for_ippv() family_id( family_id ) free_preview() full_encryption() group_inclusion( group_id ) interstitial_period( program_epoch_number ) ippv_problems( program_epoch_number ) model_id( model_id ) multicast_address( address ) on_off_test ( 0 or 1) [where 0=off; 1=on] DCT5xxx ONLY Decoder Conditional os_type( code_active or os_type ) [where code active is 0 (don't care) or 1 (yes) and os_type is a 64-bit value DCT5xxx ONLY Decoder Conditional
Page 72 of 87
package_purchase( package_provider_id, package_id ) program_purchase( service_provider_id, epoch_start_time, source_id ) rating_locked( program_epoch_number ) rating_region( rating_region_id ) region( region_ID ) regional_blacked_out( program_epoch_number ) rom_id( rom_id or platform_id ) snap_version( version_num ) subscribed( program_epoch_number ) support_mode() taping_allowed( program_epoch_number ) tier_match( category_sequence, tier ) time_zone( time_zone_id ) too_late_to_buy() tsoda_version( version_num ) tvpc_problems() tvpc_version( TvPC_version ) unreported_purchases( num_purchases ) vct_id( vctID ) DCT5xxx ONLY Decoder Conditional
7.6
Creating the DCII Download/Message File
Follow the steps below to create a DCII Private Message File. 1. Create an XML file with the appropriate messages and/or object specifications. Note: A sample file is located in the \CodeDownload directory on the CS Windows NT workstation for you to use and modify with your information. 2. Save the file as cdg.xml. Note: You may change the name of this file to something other than cdg, however you will need to edit the cdg.bat file to reflect that name. 3. Run the cdg.bat file. This file is located in the \CodeDownload directory. The batch file will create a data (.dat) file from your object and XML file, and a trigger file. Note: The DCII Download File can be created directly on the CS-1000 (Sun Netra). The code download directory is /export/home/CS/CodeDownload. Instead of a cdg.bat file, there is a script file named cdg (no extension). The script file creates a trigger file and copies the trigger file and DCII code download file (.dat) automatically to a default staging area. Modify the script file to change this behavior.
7.7
Downloading Code Objects
Follow the steps below to send a DCII message or download a code object to one or more DCTs.
1. Move the DCII Private Message(s) to the appropriate staging area. Once youve created the .dat and .trg files on the CS Windows NT workstation, you must move
Page 73 of 87
CS-1000 User's Guide them (FTP them) to the proper staging area on the CS-1000 so that they can be carouselled to the appropriate DCTs. Note: If you have not already created the Staging Area directory that you configured on the Carousel screen in the CS GUI, then you must do this prior to performing these steps. Note: If you are using a development environment, simply copy the files to the appropriate Staging Area directory on the NT platform. Caution!! Always log into the CS-1000 with the cs user name when FTPing files. Caution!! Always make certain you set the proper transfer mode in FTP before sending any files. For instance, ascii, text files should be sent in ascii mode and binary files should be sent in bin mode. The CDGs .dat and .trg files are both binary files. 2. Start the Download carousel. Click System System Status and Control, highlight the correct carousel, and click the Start button. The DCTs must receive the "tune" command before the code object will start to be downloaded.
7.8
Clearing a DCII Message from the Carousel
Data will continue to be carouselled across the PDCS carousel until you carousel a new object or download control message, or until you send an empty .dat and .trg file. The contents of a PDCS carousel can also be cleared using the CS GUI. 1. Create an empty .dat and .trg. Within the carousel's staging area, create a file called cdg.dat and another called cdg.trg. In a Windows installation you may use any windows editor available; in a Sun Netra installation you can use VI. Because these files will contain no content, they will effectively clear the stream of its existing data. 2. Poll the Staging Area. Click System System Status and Control, highlight the correct carousel, and click the Poll Staging Area button.
Page 74 of 87
8 CS-1000 Setup in a Local Headend

The following assumptions are made with regard to these procedures: The entire DCT population consists of DCT2000 settops configured as base, two-way on the DAC 6000. The DAC 6000 software is version 2.45.5-2., or higher
Note: This section contains screen captures of DAC GUI windows. For DAC versions 2.80 and greater the screens will be different. The cable system is configured with a downstream plant operating with only one OM 1000. The headend is operating properly with IRTs, C6Us, KLS, OM, and RPD configured correctly. The DCT platform code in use is version 06.44, or higher The installation and setup of the equipment is being performed by trained or experienced personnel in headend setup and operations.
Note: The following instructions are for adding a CFS_MAIN service into the DAC. These tasks must be performed for every stream that is configured with a unique service name.
8.1
Define Source
Note: The service names must match exactly in the various places they are entered throughout the setup configuration procedure. It is extremely important to enter the name fields exactly with upper and lower case matching. The service names chosen should be descriptive to allow the objects to be easily identified. 1. In the DAC 6000 Main Menu, click Manage Services.
Figure 8.1-1 - DAC - Define Source
Page 75 of 87
2. Click Define Source. 3. Click Add. 4. In the Source Name field, type CFS_MAIN as the stream name. 5. Select Application from the Source Type pull down menu. 6. Ensure the Local Definition check box is darkened. 7. Do NOT change the Source ID field, it will be filled by the DAC automatically. 8. Click Accept and Exit.
8.2
Define a Digital (Download) Service

Figure 8.2-1 - DAC - Define Digital Service
1. In the Manage Service window, click Define Digital Service.
2. Click Add. 3. Click the Source & Provider Name zoom button to bring up the Service & Provider list.
Page 76 of 87

Figure 8.2-2 - DAC - Source Name and Provider
4. Highlight CFS_MAIN from the Zoom window and click Accept. 5. Highlight Background from the Source Zoom window and click Accept. 6. Highlight CFS_MAIN from the Provider Zoom window and click Accept. 7. Select Background from the Service Type pull-down menu. 8. Select None from the Antitaping Vendor pull down menu. 9. Click the next to Locations. 10. Click Add and click the RF Device zoom button. 11. Highlight the appropriate Out-of-Band Modulator from the Zoom window and click Accept. 12. Type a unique number (MSO Service Report lists all) in the MPEG service field. 13. Select Enable Queuing from the Queuing State pull-down menu, if selectable. 14. Click the Queuing Device zoom button. 15. Highlight the appropriate Out-of-Band Modulator from the Zoom window and click Accept. 16. Click Accept. 17. Click the next to Business Systems and click Add. 18. Click the Business System Name zoom button. 19. Find and select the appropriate Business System, then click Accept. 20. Enter a unique number in the BSG Service Handle field. 21. Click Accept. 22. Click the next to Identification and click Accept.
Page 77 of 87
23. Click Exit until you return to the Main Menu.
8.3
Define Service in Channel Map (Adding Channel Map Assignments)
1. From the Main Menu, click Manage Plants. 2. Click Define Virtual Channel Map and click Select. 3. Select the VCM name to be changed and click Change to display and edit the channel map. 4. Click Define Channels under Map Operations to display the map row window. 5. Click Add to bring up the Edit Virtual Channel Map Row.
Figure 8.3-1 - DAC - Edit Virtual Channel Map Row
6. Click the Source & Provider Name zoom button. 7. Select the CFS_MAIN from the Source Name table and click Accept 8. Click the RF Device zoom button, select the appropriate device and click Accept. 9. Leave the Channel Number field blank, it will be filled automatically by the DAC. 10. Click Accept again and then click Exit until the Main Menu is displayed.
8.4
Obtain the application PID
1. In the Main Menu, click Manage Devices.

Page 78 of 87
2. Click Define OM and click Select. 3. Click the Name zoom button. 4. Find and select the appropriate Out-of-Band modulator and click Accept. 5. Click Accept again, and click Display OM Device Status under Device Operations.
Figure 8.4-1 - DAC - Display OM Device Status
6. Record the PID value for the CFS_MAIN service in the table below. Source Name PID Value
7. Click Exit until the Main Menu is displayed.
8.5
Define Multicast 16 Address Set
1. In the Main Menu, click Manage Terminals. 2. Click Define Multicast16 Address Set.
Page 79 of 87

Figure 8.5-1 - DAC - Define Multicast 16 Address Set
3. Click Add. 4. Type in CFS _MAIN in the Name field 5. Type 0.0 in the Address 1, Address 2, Address 3, and Address 4 fields. 6. Click the Service and Provider Name zoom button. 7. Find and select the CFS_MAIN as the service name and click Accept. 8. Click Accept again and click Exit until you return to the Main Menu.
8.6
Add Multicast 16 Address for CS Server
1. From the Main Menu, click Manage Plants. 2. Click Define Downstream Plant and click Select. 3. Select the appropriate downstream plant from the table and click Change. 4. Click the next to Multicast-16 Addresses.
Page 80 of 87

Figure 8.6-1 - DAC - Edit Downstream Plant
5. Click Add and click the Name zoom button. 6. Find and select CFS_MAIN from the table and then click Accept. 7. Click Accept and then click the next to Identification. 8. Click Accept and then click Exit.
8.7
Update the DAC Database for Multicast 16 Address
1. Click Manage Controller from the Main Menu. 2. Click Manage Site. 3. Click Open System Window to open an xterm-window. 4. At the % prompt, type cd data and press <Enter>. 5. Insert the floppy disk containing the mcast script file into the DAC drive. 6. At the % prompt, type dosdir a: and press <Enter> to read the contents of the floppy. 7. At the % prompt, type doscp a:mcast and press <Enter>. Note: The mcast file can be found on the CS Support/Development CD (\CS\Cfs_Components\Scripts\Dac).
Page 81 of 87
8. At the % prompt, type chmod 755 mcast and press <Enter>. 9. At the % prompt, type mcast and press <Enter>. 10. Follow the prompt as in Figure 8.7-1.
Figure 8.7-1 - DAC - Update the DAC Database for Multicast 16 Address
11. At the % prompt, type exit and press <Enter> to close the 132-window. 12. Click Exit to exit back to the Manage Controller screen.
8.8
Obtain IP Addresses of Headend Network
1. From the Manage Controller screen, click Manage Site. 2. Click Open System Window to open an xterm-window
Page 82 of 87
Figure 8.8-1 - DAC - Obtain IP Address of Headend Network
3. At the % prompt, type pg /etc/hosts and press <Enter>. 4. Record the network IP address of the OM 1000 in the table below. 5. Record an unused IP address for the CS server in the table below. Device OM 1000 CS Server IP Address
6. At the % prompt, type exit and press <Enter> to close the xterm window. 7. Click Exit until you reach the DAC 6000 Main Menu.
8.9
Define the UDP Port within the OM 1000
It is necessary to configure the headends OM with the CSs UDP port number before data transmission can occur. 1. From the OM1000s Main Menu, select Port. 2. Define a Logical port for Ethernet/Input and define the SRC-UDP> as 6557. 3. Select PIDTBL g Config and set the DST-PORT value to 01. 4. COMMIT these changes and return to the Port menu. 5. COMMIT these changes and return to the OM 1000 Main Menu. 6. Save the configuration changes and Reboot the OM 1000. Note that the OM-1000 uses a .ini file to store its configuration. The .ini file can be overwritten by the HCT (Headend Configuration Tool) or HMS (Headend Management System). Make sure that the HCT and HMS have updated .ini files that reflect the proper CS configuration for the UDP port.
Page 83 of 87
9 CS File Maintenance
This section describes the files in the CS-1000 PersistentDataStore directory, describes the characteristics of log files, provides guidelines on maintaining log file settings and directories and gives instructions for adjusting trace levels.
9.1
Persistent Data Store
The PersistentDataStore is a Directory containing the CS-1000 database and database log file. This directory or its contents must NEVER be edited or deleted. When running PDCS carousels, DCII message files are saved in raw format in this directory. When running CFS carousels, content data and operations data are stored in raw format in this directory. Raw files remain in Persistent Data Store until: The file expires, which is based on the CFS File Expiration Date in the content metadata file. The CFS data is removed from the carousel An empty metadata file and trigger are sent down a PDCS carousel, effectively clearing the carousel of its data Any carousel configured through the CS GUI can use the PersistentDataStore directory. The CS Server maintains the uniqueness of each carousel's content and metadata through file naming conventions. Although not necessary, subdirectories can be created in the PersistentDataStore directory to segregate the different carousels data.
9.2
Log Files
Log files are available for the CS Server and the CS GUI. These files contain low-level information on the operation and status of the server and GUI. They are used to debug problems that could arise during normal operation. On the CS-1000, the CS Server log files are located in /export/home/CS/LogFiles/server. If you are using the CS GUI for the Netra the log files are located in \\CS\LogFiles on the NT platform. When using the ISV Development Server Software (NT platform), the CS Server log files are located in \\CS\LogFiles\server and the CS GUI log files are located in \\CS\LogFiles\gui. Log files have the following characteristics: Trace behavior is configurable in the configuration files for the CS Server and the CS GUI. A new log file is started each time the server or GUI is started. Archived log files are saved with a file extension describing the date and time they were last written to as described in Figure 9.2-2.
9.2.1 Log File Trace Settings

The default trace settings for each of the log files (GUI and server) are set to a moderate trace (trace level 5) that primarily outputs basic operations information and all errors. In the event that you are having problems with the CS, the Motorola TRC or Acadia support center may request that you reset your trace settings on either or both systems in order for them to capture more detailed trace within each of the systems. Adjustment to log file trace settings are made through the configuration files contained in each respective systems ConfigFiles directory.
Page 84 of 87
Figure 9.2-1 - Trace Parameters
Parameter Name screen_output_enabled file_output_enabled file max_files file_period max_file_age file_rollover_size level
Default Value false for Sun server; true for GUI and NT true /export/home/CS/LogFiles/<server|gui>/ 100 for server; 30 for GUI 86400 (1 day) 2592000 (30 days) -1 (unlimited) 5
Units true / false true / false valid path and filename number time (seconds) time (seconds) size (bytes) number (higher number = more trace)
Note: Parameters that require a value, amount of time, or size all accept -1 to specify an unlimited amount. screen_output_enabled Specifies whether the trace should be output to the terminal window. (Boolean) Specifies whether the trace should be output to file. Setting this parameter to false will stop all trace saved to file. (Boolean) Specifies the path and filename to write trace to. (path and filename) Specifies the maximum number of files to be archived in the current log file directory. Once the number of files exceeds this number, the oldest files will be deleted from the directory to maintain the correct number of files. (value) Specifies the length of time a file is written to before it is archived and a new file is created. (seconds) Specifies the maximum age that an archived file is allowed to be before it is deleted from the directory. (seconds) Specifies the maximum allowable file size that the current log file is allowed to be before it is archived and a new log file created. (bytes) Specifies the relative verbosity of trace. A trace level of 0 will output only errors, more trace will be written as this value increases. (value)
file_output_enabled
file max_files
file_period
max_file_age
file_rollover_size
level
9.2.2 Log File Naming Conventions

The log file curently being written to will be named as specified by the file parameter in the configuration file. Figure 9.2-2 illustrates the CS log file naming convention for archived log files.
Page 85 of 87

Figure 9.2-2 - Archived Log File Name Syntax
GUI Log File Name
CarouselManagerGUI_trace.txt.saved_20010105_12-07-46
Generic log file name and name of current log file
Log file closing date
Log file closing time
Server Log File Name
CarouselManagerServer_trace.txt.saved_20010105_12-07-46
Generic log file name and name of current log file Log file closing date Log file closing time
Page 86 of 87
10 Acronyms
The following acronyms are used throughout the document. API ASA CDG CFS CS-1000 CS DAC DCCG DCII DLS DMG DNS EDSC FTP GUI IP MCA MDI MIB MPEG OAM&P ODBC OM OOB OOBTAB PDCS PID PMT PSA SA SDK SNMP UDP Application Program Interface Adaptive Server Anywhere Code Download Generator Carousel File System Carousel Server 1000 Carousel System Access Control Computer (DAC 6000) Digicable Control Channel Generator DigiCipher II Download Server DCII Message Generator Domain Name System External Data Source Carousel File Transfer Protocol Graphical User Interface Internet Protocol Multicast Address Multiple Document Interface Management Information Base Motion Pictures Experts Group Operations, Administration, Maintenance and Provisioning Open Database Connectivity Out-of-Band Modulator Out-of-Band Out-of-Band Table Private Data Carousel System Packet Identifier Program Map Table Persistent Storage Area System Administrator Software Development Kit Simple Network Management Protocol User Datagram Protocol
Page 87 of 87

CS-1000 User&#39;s Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CS-1000 User&#39;s Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Broadband Communications Sector

Copyright 2000 Motorola, Inc. All rights reserved.