Académique Documents
Professionnel Documents
Culture Documents
Security Level 1
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
X.5
365-095-1578
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
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:
Page 2 of 87
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
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
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
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
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
Document Number: 365-095-1578 Rev: X.11
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
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
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
nt nte Co
li De
r ve
Carousel Server
OOB Data Delivery
DAC6000
NC1500
OAM&P Network
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.
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
Page 10 of 87
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)
Carousels 2 thru N
Carousel 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.
/ (contains /etc/cfsoobtab)
/usr/ISV_A
/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
User
/usr/ISV_A
/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.
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
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
Page 14 of 87
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)
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.
Page 16 of 87
Code Object
XML File
CDG
/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.
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
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
About
User Add/Edit
Carousel Add/Edit Stream Set Add/Edit Stream Add/Edit Stream Interface EDSC Stream Data Source
Interfaces Add/Edit
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
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.
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
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
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
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.
Page 23 of 87
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.
Page 24 of 87
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
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
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
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
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.
Page 28 of 87
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.
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
Page 30 of 87
Page 31 of 87
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.
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
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
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
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
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
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.
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
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
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
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).
Page 39 of 87
Page 40 of 87
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.
Page 41 of 87
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
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
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.
Page 44 of 87
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.
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.
The frequency, in seconds, that the CS-1000 checks the Staging Area for new files.
Page 45 of 87
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
Page 46 of 87
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
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.
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.
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.
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.
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.
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.
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
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.
Page 51 of 87
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
Page 53 of 87
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).
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.1
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.
Page 55 of 87
5.2
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
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.
String
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 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.
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
5.3
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
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.
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
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
7.1
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.
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
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.
<PREAMBLE> <ADDRESS>
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 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.
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.
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
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.
offset
count
type
BROADCAST
Page 62 of 87
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
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
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.
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
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.
CS
CDG
CDG_file.dat CDG_file.trg
PROS
cdg.xml
PDCS
UNDP or OM
Page 66 of 87
download PID
frequency
fecOuter
fecInner
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>
Page 68 of 87
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".
list ID
list version
intersegment timer
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 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
Motorola Security Level 1
"TESTAPP" 2012 101 CODE 13.51 "dvt1351-AC SYSTEM_OS FLASH 8973452 0 0 0 "GI App OS System Object" NO 473956352
Document Number: 365-095-1578 Rev: X.11
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>
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
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
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
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
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
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
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
2. Click Add. 3. Click the Source & Provider Name zoom button to bring up the Service & Provider list.
Page 76 of 87
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.
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
Page 77 of 87
8.3
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.
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
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
8.5
1. In the Main Menu, click Manage Terminals. 2. Click Define Multicast16 Address Set.
Page 79 of 87
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
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
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
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).
Motorola Security Level 1 Document Number: 365-095-1578 Rev: X.11
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
1. From the Manage Controller screen, click Manage Site. 2. Click Open System Window to open an xterm-window
Page 82 of 87
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
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
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.
Page 84 of 87
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
Page 85 of 87
CarouselManagerGUI_trace.txt.saved_20010105_12-07-46
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