Version

Chapter 3 7

Configuring the Board

3.1 Introduction

3.2 Adding CG Configurations to the OAM Database

3.3 Configuring and Starting the System with oamsys

: 3.3.1 Creating a System Configuration File for oamsys
: 3.3.2 Running oamsys

3.4 Changing Configuration Parameter Settings

: 3.4.1 Board Keyword Files
: 3.4.2 Specifying Configuration File Locations

3.5 Configuring Board Clocking

: 3.5.1 Clocking References
: 3.5.2 Fallback Clocking
: 3.5.3 Configuring CT Bus Clocks with CG Keywords
: 3.5.4 Example: Multiple Board System
: 3.5.5 CG 6000C Clocking Rules and Restrictions

3.6 Configuring Ethernet Connections

: 3.6.1 Setting up the Ethernet Connections
: 3.6.2 Ethernet Redundancy Mode
: 3.6.3 Multiple Subnet Mode

3.7 Sample Board Keyword Files

3.8 Using DSP Resource Management Keywords

: 3.8.1 Resource Management Keywords
: 3.8.2 Resource Definition String Syntax
: 3.8.3 DSP Files
: 3.8.4 Resource Definitions
: 3.8.5 Specifying Conditional Relationships Between DSP Functions
: 3.8.6 Echo Cancellation Restrictions

3.1 Introduction

This chapter: Lists and describes the sample board keyword files installed with the CG 6000C board Describes the CG 6000C system configuration file Describes how to run oamsys to start all boards Explains how to configure the Ethernet interface Provides a summary of the CG 6000C keywords

3.2 Adding CG Configurations to the OAM Database

For the OAM service to be able to configure and start your boards, each board must have a separate set of configuration parameters and values in the OAM database. This set of information is provided through a board keyword file. In a board keyword files, each parameter and value is expressed as a keyword name/value pair (for example, Country = USA).
The easiest way to update the OAM database with board keyword file information is to use the oamsys utility supplied with the OAM service software. oamsys performs system-wide configuration and startup of boards. It configures the OAM database based on system configuration files you supply, and starts all boards listed in the OAM database. Note: An application can control the OAM service programmatically, through the OAM service API. For more information, refer to your OAM Service Developer's Reference Manual.
For general documentation of OAM service utilities, refer to your OAM System User's Manual.

3.3 Configuring and Starting the System with oamsys

To configure a system using the oamsys utility: Install the boards and software, as described in Chapter 2. Create a CG 6000C board keyword file (or edit one of the sample CG 6000C board keyword files) so that it specifies appropriate configuration information for your board. Determine the CPCI bus and slot locations of the boards, using the pciscan utility. Create a system configuration file (or edit the sample CG 6000C system configuration files) that points to all the board keyword files for your system. In this file, give each board a unique name and board number. Use oamsys to set up managed objects in the OAM database based on the system configuration file, and to start all installed boards (ctdaemon must be running when you use oamsys).
You can use the pciscan utility to identify any NMS PCI boards installed in the system, and return each board's bus, slot, interrupt, and board type. For more information about pciscan, refer to the OAM System User's Manual.

3.3.1 Creating a System Configuration File for oamsys

The OAM system configuration file provides a reference to all of the boards in your system. oamsys creates records in the OAM database for your boards based on this file.
The system configuration file is typically named oamsys.cfg and located in the nms\oam\cfg directory (opt/nms/oam/cfg for Unix). By default, oamsys looks for a file with this name when it starts up.
Refer to your OAM System User's Manual for specific information on the syntax and structure of this file. The following chart describes the CG board-specific settings to include in the file for each CG board:

Keyword

Description

[name]

The name of the board, to be used to refer to the board in software. The board name must be unique.

Product

The name of the board product (for CG 6000C boards, this is CG_6000C_QUAD).

Number

The board number you will use in your CT Access application to refer to the board.

Bus

The PCI bus number. The bus:slot location for each board must be unique.
Obtain with pciscan.

Slot

The PCI slot number. The bus:slot location for each board must be unique.
Obtain with pciscan.

File

The name of the board keyword file containing settings for the board.
Several board keyword files are installed with the CG software, one for each country or region.

Keyword	Description
[*name*]	The name of the board, to be used to refer to the board in software. The board name must be unique.
`Product`	The name of the board product (for CG 6000C boards, this is `CG_6000C_QUAD`).
`Number`	The board number you will use in your CT Access application to refer to the board.
`Bus`	The PCI bus number. The bus:slot location for each board must be unique. Obtain with `pciscan`.
`Slot`	The PCI slot number. The bus:slot location for each board must be unique. Obtain with `pciscan`.
`File`	The name of the board keyword file containing settings for the board. Several board keyword files are installed with the CG software, one for each country or region.

Sample System Configuration File

The following system configuration file provides configuration information for all the CG 6000C boards on a particular chassis. Each board has its own section in this file. Each is delimited by a user-defined board name in square brackets. All board names and numbers must be unique.
You will need to modify the bus and slot numbers for each board to match your chassis configuration and you may also need to add more board sections.
[Board_VT_C5420_0] Product = CG_6000C_QUAD Number = 0 Bus = 1 Slot = 7 #------------------------------------------------------------- # Detailed board settings are in the following board keyword files. # Uncomment one of the following board keyword files, # or add a new one. You may need to modify the board keyword file # for your particular application. #------------------------------------------------------------ File = c6nocc.cfg # T1, no call control # File = c6wnk.cfg # File = c6fgd.cfg # File = c6gds.cfg # File = c6ops.cfg # File = c6ss5.cfg # File = cgi6t1.cfg # File = cgi6e1.cfg #------------------------------------------------------ # Uncomment the following section to boot another board #------------------------------------------------------- #[BoardName1] # Product = CG_6000C_QUAD # Number = 1 # Bus = 2 # Slot = 14 # File = c6nocc.cfg

3.3.2 Running oamsys

To run oamsys, enter oamsys from the command line.
If you invoke oamsys without command line options, it searches for a file named oamsys.cfg in the paths specified in the AGLOAD environment variable.
When invoked with a valid filename, oamsys does the following: Checks the syntax of your system configuration file, and that all required keywords are present. Unrecognized keywords are discarded. Note: oamsys checks syntax only on your system configuration file, and not on any board keyword files referenced in the file. oamsys reports all syntax errors it finds. Checks for uniqueness of board name, number and bus/slot. Shuts down all boards referenced in the OAM database (if any). Deletes all board configuration information currently stored in the OAM database (if there is any). Sets up the OAM database, and creates all managed objects as described in the system configuration file. Attempts to start all boards, as described in the database.
ctdaemon must be running for oamsys to operate. For more information about the CT Access Server (ctdaemon), refer to the CT Access Developer's Reference Manual.

3.4 Changing Configuration Parameter Settings

When you run oamsys, the parameter settings specified in the board keyword files are stored in the OAM database. All boards are then started in their specified configurations.
Parameters are communicated as keyword name/value pairs, such as: Clocking.HBus.ClockMode
To change board keyword parameter settings, you can: Duplicate the board sample keyword file appropriate for your country and board type, modify the new file, specify the name of this new file in the File statement of the oamsys.cfg file, and run oamsys again. (See the OAM System User's Manual for information about keyword file syntax.) Create a new board keyword file, either with additional keywords, or keywords whose values override earlier settings. Specify parameter settings directly using the oamcfg utility. For more information about this utility, refer to the OAM System User's Manual. Specify the settings programmatically, with the OAM service API. (See the OAM Service Developer's Reference Manual for more information.)
You may wish to make some changes to: Software module files downloaded to the board at startup (Section 3.4.2). Board switching (Chapter 5). CT bus clocking (Section 3.5).

3.4.1 Board Keyword Files

A sample set of board keyword files are installed by the CG 6000C installation. These board keyword files are for the digital protocols: File Description c6fgs.cfg 120 ports of IVR with Feature Group D protocol c6gds.cfg 120 ports of IVR with Ground Start protocol c6nocc.cfg 120 ports of IVR with No Call Control c6ops.cfg 120 ports of IVR with Off Station Premises protocol c6ss5.cfg 120 ports of IVR with Signaling System 5 protocol c6wnk.cfg 120 ports of IVR with Wink Start protocol ci6t1.cfg 120 ports of IVR using an ISDN variant and a T1 interface ci6e1.cfg 120 ports of IVR using an ISDN variant and an E1 interface cinfas.cfg 120 ports of IVR using an ISDN variant to run NFAS (T1 only)
A sample board keyword file is shown in Section 3.7. These board keyword files have many keywords in common. For example, there are default keywords specified for one set of Resource keywords. This set is specified for 120 ports of IVR.
For more information about board keyword files, refer to the OAM System User's Manual.

File	Description
`c6fgs.cfg`	120 ports of IVR with Feature Group D protocol
`c6gds.cfg`	120 ports of IVR with Ground Start protocol
`c6nocc.cfg`	120 ports of IVR with No Call Control
`c6ops.cfg`	120 ports of IVR with Off Station Premises protocol
`c6ss5.cfg`	120 ports of IVR with Signaling System 5 protocol
`c6wnk.cfg`	120 ports of IVR with Wink Start protocol
`ci6t1.cfg`	120 ports of IVR using an ISDN variant and a T1 interface
`ci6e1.cfg`	120 ports of IVR using an ISDN variant and an E1 interface
`cinfas.cfg`	120 ports of IVR using an ISDN variant to run NFAS (T1 only)

3.4.2 Specifying Configuration File Locations

Files to be downloaded on CG boards are specified with keywords in the CG board's keyword file. For example:
DLMFiles[ 1] = cg6kfusion
If filename contains a path specification, the OAM will searched for the file in the specified directory. If the file does not exist in this current working directory, it will be searched in the load_directory defined by the AGLOAD environment variable.

3.5 Configuring Board Clocking


*Caution:*	NMS strongly recommends that you do not mix H.100/H.110 systems with MVIP systems when doing clock fallback.

When multiple boards are connected to the CT bus, you can set up a bus clock to synchronize timing between them. In addition you can configure alternative (or fallback) clock sources to provide the clock signal if the primary source fails.
Boards in a CT bus system can be configured in one of the following modes: Board Mode Description Primary clock master Drives the primary timing reference for boards connected to the CT bus. It can switch between its two specified timing sources in order to maintain the primary timing reference. However, if both of its timing references fail, the primary clock master stops providing a timing source (and the secondary master then provides bus synchronization). Secondary clock master Drives the secondary timing reference. When the primary clock fails, the secondary master continues to drive the secondary clocks using a network timing source as its timing reference. Clock slave References its timing from the primary clock master, and uses the secondary clock master as a fallback source of clock timing. Standalone Does not reference the primary or secondary master, and consequently may not make switch connections to the CT bus.
For information about the rules and restrictions that apply to configuring CT bus clocking with CG 6000C boards, refer to Section 3.5.5. Note: CT bus clock fallback establishes a redundant system of timing references for the CT bus. It does not create an autonomous clock timing environment. When clock fallback occurs, you must intervene to reset system clocking before the all of the specified fallback timing references are exhausted. If all of the timing references specified for the primary and secondary clock masters fail (and no intervention takes place), boards on the system default to standalone mode.

Board Mode	Description
Primary clock master	Drives the primary timing reference for boards connected to the CT bus. It can switch between its two specified timing sources in order to maintain the primary timing reference. However, if both of its timing references fail, the primary clock master stops providing a timing source (and the secondary master then provides bus synchronization).
Secondary clock master	Drives the secondary timing reference. When the primary clock fails, the secondary master continues to drive the secondary clocks using a network timing source as its timing reference.
Clock slave	References its timing from the primary clock master, and uses the secondary clock master as a fallback source of clock timing.
Standalone	Does not reference the primary or secondary master, and consequently may not make switch connections to the CT bus.

3.5.1 Clocking References

Primary clock masters can synchronize their own timing signals from the following sources: NETWORK NETREF NETREF2 OSC
Secondary clock masters are hybrid systems. Their primary timing source must be A_CLOCK or B_CLOCK. Their fallback timing source must be: NETWORK NETREF NETREF2 OSC
For further information about configuring clocks on the H.110 bus, refer to the OAM System User's Manual or the ECTF H.110 Hardware Compatibility Specification: CT Bus R1.0.
Clock slaves must use A_CLOCK or B_CLOCK as their primary timing source.

3.5.2 Fallback Clocking

The CT bus supports a system of fallback clocking that allows the system to use alternate timing references when one or more sources fail.
To implement fallback clocking: Configure a primary clock master to drive the CT bus clock (A clocks or B clocks) based on a network timing reference. All slave boards will synchronize their timing through this clock. Configure a secondary clock master to use the signal from the primary clock to drive the alternate CT bus clock (in other words, if the primary master drives the A clock, the secondary master should drive the B clock based on the A clock, or vice versa). Specify a fallback network timing reference for the secondary clock master to use in the event the primary clock master fails. Configure all slave boards to specify the secondary clock master as their fallback clock source.
When the boards are configured in this way, the secondary clock master continues to drive the secondary clock (based on its own network timing reference) if the primary clock master fails. Slave boards within the system fall back to synchronize their timing from the secondary clock master.
For more information about the specific rules and restrictions that apply to setting up clocking on CG 6000C boards, refer to Section 3.5.5.

3.5.3 Configuring CT Bus Clocks with CG Keywords

CG 6000C board configuration keywords allow you to configure: The board as the system's primary clock master The board as the system's secondary clock master The board as a slave to the system's primary clock master Standalone boards that may be physically attached but not connected to the CT bus, but not allowed to perform CT bus switching Fallback sources for all the modes above
The following sections describe how to use board configuration keywords to specify clocking configurations on multiple-board or multiple-chassis systems.

Configuring the Primary Clock Master

Use the following keywords to configure the primary clock master: Keyword Description Clocking.HBus.ClockSource Specifies the source from which this board derives its timing. This should be a network source (NETREF, NETREF2, or NETWORK). Clocking.HBus.ClockSourceNetwork (optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock (trunk numbering is 1-based). Clocking.HBus.ClockMode Specifies the CT bus clock that the board drives. This must reference either the A clock (MASTER_A) or the B clock (MASTER_B). Clocking.HBus.AutoFallBack Enables or disables clock auto-fallback on the board. Clocking.HBus.FallBackClockSource Specifies an alternate timing reference to use when the master clock source fails. This should be a network timing source (NETREF, NETREF2, or NETWORK). Clocking.HBus.FallBackNetwork (optional) Specifies the trunk from which a fallback network timing source (for the fallback clock reference) can be derived When Clocking.HBus.FallBackClockSource= NETWORK. Note: Trunk numbering in this case is 1-based. Note: If the primary master's first source fails and then returns, the board's timing reference (and consequently, the reference for any slaves) switches back to the first timing source (this is not true for the secondary timing master).

Keyword	Description
Clocking.HBus.ClockSource	Specifies the source from which this board derives its timing. This should be a network source (`NETREF`, `NETREF2`, or `NETWORK`).
Clocking.HBus.ClockSourceNetwork	(optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock (trunk numbering is 1-based).
Clocking.HBus.ClockMode	Specifies the CT bus clock that the board drives. This must reference either the A clock (`MASTER_A)` or the B clock (`MASTER_B)`.
Clocking.HBus.AutoFallBack	Enables or disables clock auto-fallback on the board.
Clocking.HBus.FallBackClockSource	Specifies an alternate timing reference to use when the master clock source fails. This should be a network timing source (`NETREF`, `NETREF2`, or `NETWORK`).
Clocking.HBus.FallBackNetwork	(optional) Specifies the trunk from which a fallback network timing source (for the fallback clock reference) can be derived When Clocking.HBus.FallBackClockSource`= NETWORK`. Note: Trunk numbering in this case is 1-based.

Configuring the Secondary Clock Master

Use the following keywords to configure the secondary clock master: Keyword Description Clocking.HBus.ClockSource The source from which this board derives its timing. This must be set to the clock driven by the primary clock master. For example, if the primary master drives the A clock, this should be set to A_CLOCK. Clocking.HBus.ClockSourceNetwork (optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock. Clocking.HBus.ClockMode Specifies the CT bus clock that the secondary master drives. This must reference the clock (MASTER_A or MASTER_B) not driven by the primary clock master. Clocking.HBus.AutoFallBack Enables or disables clocking auto-fallback on the board. This should be set to YES. Clocking.HBus.FallBackClockSource Specifies an alternate timing reference to use when the master clock does not function properly. This should reference a network source (NETREF, NETREF2, or NETWORK). Clocking.HBus.FallBackNetwork (optional) The trunk from which a fallback network timing source (for the fallback clock reference) can be derived. Note: Trunk numbering in this case is 1-based. Note: If the primary master's timing reference returns, the secondary master still continues to drive the clocks referenced by all clock slaves.

Keyword	Description
Clocking.HBus.ClockSource	The source from which this board derives its timing. This must be set to the clock driven by the primary clock master. For example, if the primary master drives the A clock, this should be set to `A_CLOCK`.
Clocking.HBus.ClockSourceNetwork	(optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock.
Clocking.HBus.ClockMode	Specifies the CT bus clock that the secondary master drives. This must reference the clock (`MASTER_A` or `MASTER_B)` not driven by the primary clock master.
Clocking.HBus.AutoFallBack	Enables or disables clocking auto-fallback on the board. This should be set to `YES.`
Clocking.HBus.FallBackClockSource	Specifies an alternate timing reference to use when the master clock does not function properly. This should reference a network source (`NETREF`, `NETREF2`, or `NETWORK`).
Clocking.HBus.FallBackNetwork	(optional) The trunk from which a fallback network timing source (for the fallback clock reference) can be derived. Note: Trunk numbering in this case is 1-based.

Configuring Clock Slaves

Use the following keywords to configure the clock slaves: Keyword Description Clocking.HBus.ClockMode The CT bus clock from which the board derives its timing.This should be set to SLAVE to indicate that the board does not drive any CT bus clock (although the board may still drive NETREF or NETREF2). Clocking.HBus.ClockSource Specifies the source from which this clock derives its timing. This must reference the clock driven by the primary clock master. Clocking.HBus.AutoFallBack Enables or disables clocking auto-fallback on the board. Clocking.HBus.FallBackClockSource Specifies the alternate clock reference to use when the master clock does not function properly. For clock slaves, this should point to the clocks (A or B) driven by the secondary clock master.

Keyword	Description
Clocking.HBus.ClockMode	The CT bus clock from which the board derives its timing.This should be set to `SLAVE` to indicate that the board does not drive any CT bus clock (although the board may still drive `NETREF` or `NETREF2`).
Clocking.HBus.ClockSource	Specifies the source from which this clock derives its timing. This must reference the clock driven by the primary clock master.
Clocking.HBus.AutoFallBack	Enables or disables clocking auto-fallback on the board.
Clocking.HBus.FallBackClockSource	Specifies the alternate clock reference to use when the master clock does not function properly. For clock slaves, this should point to the clocks (A or B) driven by the secondary clock master.

Configuring Standalone Boards

To configure a board in standalone mode so the board references its own clocking information, set Clocking.HBus.ClockMode to STANDALONE. The board can use either its own oscillator or a signal received from a digital trunk as a timing signal reference. However, the board will not be able to make switch connections to the CT bus.
For more information about the rules and restrictions that apply to setting up clocking on CG 6000C boards, refer to Appendix A.

3.5.4 Example: Multiple Board System

The following example assumes a system configuration where four CG 6000C boards reside on a single chassis. The boards are configured in the following way: Board Configuration Board 0 System primary bus master (driving the A clocks) Board 1 System secondary bus master (driving the B clocks) Board 2 Clock slave (auto fallback enabled) Board 3 Clock slave (auto fallback enabled - drives the NETREF clock)
This configuration assigns the following clocking priorities: Timing Reference Timing reference First Board 0, digital trunk 1. A network signal from a digital trunk provides the primary master clock source. Second Board 3, digital trunk 3. The NETREF signal driven by a digital trunk (on Board 3) acts as the primary master fallback clock source. Third Board 1, digital trunk 2. A network signal from a digital trunk provides the secondary master fallback clock source.
Figure 21 shows an example of a multi-board system with a primary and secondary clock master: Figure 21. Sample Board Clocking Configuration
The following table shows keywords used to configure the boards according to the configuration shown in Figure 21. Board Role Clocking Keyword Settings 0 Primary clock master Clocking.HBus.ClockMode = MASTER_A Clocking.HBus.ClockSource = NETWORK Clocking.HBus.ClockSourceNetwork = 1 Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = NETREF Clocking.HBus.NetRefSpeed = 8K 1 Secondary clock master Clocking.HBus.ClockMode = MASTER_B Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = NETWORK Clocking.HBus.FallBackNetwork = 2 2 Clock slave Clocking.HBus.ClockMode = SLAVE Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = B_CLOCK 3 Slave driving NETREF Clocking.HBus.ClockMode = SLAVE Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = B_CLOCK Clocking.HBus.NetRefSource = NETWORK Clocking.HBus.NetRefSourceNetwork = 3 Clocking.HBus.NetRefSpeed = 8K
In this configuration, Board 0 is the primary clock master and drives the A clock. All slave boards on the system use the A clock as their first timing reference. Board 0 references its timing from a network timing signal received on its own trunk 1. Board 0 also uses the NETREF signal (driven based on digital signal received on trunk 3 of Board 3) as its fallback clock source. This means that if the network timing signal derived from its own digital trunks fails, Board 0 will continue to drive the A clocks based on NETREF timing reference.
If, however, both of the clocking signals used by Board 0 (the network timing signal and the NETREF signal) fail, then Board 0 stops driving the A clock. The secondary clock master (Board 1) then falls back to a timing reference received on its own trunk 3, and uses this signal to drive the B clock. The B clock then becomes the timing source for all boards that use the B clock as their backup timing reference. Note: For this to take effect, all the clock slaves must specify the A clocks as their clock source, and the B clocks as their fallback clock source.

Board	Configuration
Board 0	System primary bus master (driving the A clocks)
Board 1	System secondary bus master (driving the B clocks)
Board 2	Clock slave (auto fallback enabled)
Board 3	Clock slave (auto fallback enabled - drives the NETREF clock)

Timing Reference	Timing reference
First	Board 0, digital trunk 1. A network signal from a digital trunk provides the primary master clock source.
Second	Board 3, digital trunk 3. The NETREF signal driven by a digital trunk (on Board 3) acts as the primary master fallback clock source.
Third	Board 1, digital trunk 2. A network signal from a digital trunk provides the secondary master fallback clock source.

Board	Role	Clocking Keyword Settings
0	Primary clock master	`Clocking.HBus.ClockMode = MASTER_A` `Clocking.HBus.ClockSource = NETWORK` `Clocking.HBus.ClockSourceNetwork = 1` `Clocking.HBus.AutoFallBack = YES` `Clocking.HBus.FallBackClockSource = NETREF` `Clocking.HBus.NetRefSpeed = 8K`
1	Secondary clock master	`Clocking.HBus.ClockMode = MASTER_B` `Clocking.HBus.ClockSource = A_CLOCK` `Clocking.HBus.AutoFallBack = YES` `Clocking.HBus.FallBackClockSource = NETWORK` `Clocking.HBus.FallBackNetwork = 2`
2	Clock slave	`Clocking.HBus.ClockMode = SLAVE` `Clocking.HBus.ClockSource = A_CLOCK` `Clocking.HBus.AutoFallBack = YES` `Clocking.HBus.FallBackClockSource = B_CLOCK`
3	Slave driving NETREF	`Clocking.HBus.ClockMode = SLAVE` `Clocking.HBus.ClockSource = A_CLOCK` `Clocking.HBus.AutoFallBack = YES` `Clocking.HBus.FallBackClockSource = B_CLOCK` `Clocking.HBus.NetRefSource = NETWORK` `Clocking.HBus.NetRefSourceNetwork = 3` `Clocking.HBus.NetRefSpeed = 8K`

3.5.5 CG 6000C Clocking Rules and Restrictions

This section describes the rules and limitations that apply to setting up CT bus clocking on CG 6000C boards.
When an CG 6000C board is configured as the system primary clock master: The board's first timing reference must be set to a network trunk, a Netref clock, or OSC. The board's fallback timing reference must be set to a network trunk or a Netref reference.
When an CG 6000C board is configured as the system secondary clock master: The board's first timing reference must be the system's primary clock master. The board's fallback timing reference must be set to one of the network trunks, a Netref source, or OSC.
When an CG 6000C board is configured as a clock slave: The board's first timing reference must be the system's primary clock. The board's fallback timing reference must be the system's secondary clock. If there is no secondary clock for the system, the board's fallback timing reference must be set to OSC. In this case, if clock fallback occurs, the board will be out of sync with the system until you reconfigure the board's clocking.

Clocking Priority in Mixed Board Systems

When choosing which boards that will act as primary and secondary clock masters in a mixed-board system, use the following priority system: CG 6000C AG 4000C CompactPCI AG Quad
For example, if a system includes two CG 6000C boards and several other NMS boards, the CG 6000C boards should be configured as the system's primary and secondary clock masters. If the system includes one CG 6000C board, one AG 4000C board, and several other boards, the CG 6000C board should be configured as the system primary clock master and the AG 4000C as the system secondary clock master.
Following this priority system ensures the most reliable performance when CT bus clock fallback occurs.

3.6 Configuring Ethernet Connections

The CG 6000C board has two 10/100Base-T Ethernet connections. The CG 6000C Ethernet interfaces can be configured in several ways. This section describes the following: Generic Ethernet connections Configuring the interface in Ethernet redundancy mode Configuring the interface multiple subnet mode
Use the following board keywords to configure the CG 6000C Ethernet interface: Keyword Description IPC.AddRoute[x].DestinationAddress Specifies the IP address of a CG 6000C board Ethernet interface. You may specify up to 32 destination addresses. IPC.AddRoute[x].GatewayAddress Specifies the IP address of the network router. IPC.AddRoute[x].Interface Specifies the number (1 or 2) of the Ethernet interface you are configuring. IPC.AddRoute[x].Mask Specifies the subnet mask for the IP address specified in IPC.AddRoute[x].DestinationAddress. Note: For these keywords, x represents an entry in the routing table.
CG 6000C Ethernet interfaces must be configured for Fusion systems. For more information about Fusion software, configurations, and programming models, refer to the Fusion Developer's Manual.

Keyword	Description
IPC.AddRoute[x].DestinationAddress	Specifies the IP address of a CG 6000C board Ethernet interface. You may specify up to 32 destination addresses.
IPC.AddRoute[x].GatewayAddress	Specifies the IP address of the network router.
IPC.AddRoute[x].Interface	Specifies the number (1 or 2) of the Ethernet interface you are configuring.
IPC.AddRoute[x].Mask	Specifies the subnet mask for the IP address specified in IPC.AddRoute[x].DestinationAddress.

3.6.1 Setting up the Ethernet Connections

The IPC.AddRoute keywords are used to set the IP addressing and static IP routing table information for the CG 6000C board. You can configure up to 32 separate routing table entries for the CG 6000C board.
Depending upon the desired mode of operation, you can configure each Ethernet on the CG 6000C board with its own IP addressing information. To do this, specify the IP address, the IP subnet mask, and the particular Ethernet interface.

IP Addresses

To specify the IP address of an Ethernet interface on the CG 6000C, define the following keywords: IPC.AddRoute[x].DestinationAddress = [IP Address of Ethernet interface] IPC.AddRoute[x].Mask = [Subnet Mask for above IP Address] IPC.AddRoute[x].Interface = [Ethernet Interface # (1 or 2)]

Static IP Routes

In addition, the CG 6000C board allows you to configure multiple static IP routes. Typically, this is done to specify the address of a router(s) on the IP subnet that manages the IP routing that is between the subnet the CG 6000C board is on and the remainder of the IP network. The IP stack on the CG 6000C board uses the standard IP routing algorithms to determine how to route outbound packets.
To specify a static IP route to be used by the IP stack on the CG 6000C board, define the following keywords: IPC.AddRoute[x].DestinationAddress = [IP Address] IPC.AddRoute[x].Mask = [Subnet Mask for above IP Address] IPC.AddRoute[x].GatewayAddress = [IP Address of router]

Example

Normally you configure the CG 6000C board by using a board keyword file and an OAM utility (such as oamsys). The IPC.AddRoute statements in the CG 6000C board keyword file determine the IP addressing and Gateway information for the CG 6000C board.
The following example shows how to use IPC.Addroute statements in the CG 6000C board keyword file to specify the board's IP address, subnet mask, and gateway IP address: #CG 6000C Board IP Address, subnet mask, and gateway IP address. IPC.AddRoute[0].DestinationAddress = 10.102.64.151 IPC.AddRoute[0].Mask = 255.255.255.0 IPC.AddRoute[0].Interface = 1 #Gateway IP Address, subnet mask, and gateway IP address. IPC.AddRoute[1].DestinationAddress = 0.0.0.0 IPC.AddRoute[1].Mask = 0.0.0.0 IPC.AddRoute[1].GatewayAddress = 10.102.64.1 Note: In this example, the first three IPC entries specify the IP address and mask of the CG 6000C board. The second three entries configure the address of the gateway.
When configured in this manner, the IP addressing and gateway configuration information for each CG 6000C board resides in the board keyword file. Each time the CG 6000C board is rebooted with oamsys, the IP Addressing information is re-configured for the CG 6000C board.
The cgroute utility (included with Fusion software) provides an alternative way to configure specific IP addressing information without editing the CG 6000C board keyword file. cgroute is similar to the standard route utility found on most systems with IP processing capabilities, allowing you to add, delete, and display routing information from the CG 6000C board. For more information about cgroute, refer to the Fusion Developer's Manual.

3.6.2 Ethernet Redundancy Mode

By default, the Ethernet subsystem on the CG 6000C board initializes in redundancy mode. In this mode of operation, Ethernet 1 is the primary Ethernet connection and Ethernet 2 is in a standby mode. Refer to the Ethernet Redundancy Mode example in Section 3.6.1, Setting up the Ethernet Connections.
All IP configuration and routing information applies to both the primary and backup Ethernet connection. If the primary Ethernet losses link integrity, the backup Ethernet connection takes over for the primary Ethernet. Once link integrity has been returned to the primary Ethernet connection, all Ethernet traffic switches back to the primary Ethernet.
While in standby mode, the second Ethernet establishes link integrity, but remains passive, neither transmitting nor receiving packets to/from the Ethernet. When link integrity is lost on the primary Ethernet, the second Ethernet enables its transmitter and receiver and takes-over for the primary Ethernet. This take-over is automatic, occurs in less than 1 ms., and is transparent to both the network and the application.
Ethernet redundancy mode is disabled when the second Ethernet connection is explicitly configured with any IP addressing information by the user.

Example

The following example configures a CG 6000C board for Ethernet redundancy. This example shows a CG 6000C board on a Class C subnet (198.62.139.x), with a single router providing access to the external IP network.
The use of 0.0.0.0 as the Destination address and Subnet mask for the router configuration specifies that all IP addresses not on the local subnet (198.62.139.x) are forwarded to the router (198.62.139.1); this is typically known as the default route. IPC.AddRoute[0].DestinationAddress = 198.62.139.32 IPC.AddRoute[0].Mask = 255.255.255.0 IPC.AddRoute[0].Interface = 1 IPC.AddRoute[1].DestinationAddress = 0.0.0.0 IPC.AddRoute[1].Mask = 0.0.0.0 IPC.AddRoute[1].GatewayAddress = 198.62.139.1

3.6.3 Multiple Subnet Mode

You can configure each Ethernet on the CG 6000C board into a different IP Subnet. This might be done to split different types or classes of IP traffic onto two different IP/Ethernet networks. Refer to the Multiple Subnet Mode example in Section 3.6.1, Setting up the Ethernet Connections. Note: It is possible to configure both Ethernets into the same IP Subnet, but this is not recommended. When configured in this manner, the CG 6000C board will multi-home on each IP address, receiving packets for both addresses. However, based on standard IP routing principals, outbound packets will take the first route found that matches. Therefore, all outbound packets will be sent out the Ethernet associated with the first IP address found in the routing table.
When you configure the second Ethernet with an IP address, Ethernet redundancy mode is disabled and Multiple Subnet mode is enabled.

Example

This example configures a CG 6000C board in Multiple Subnet mode. Each Ethernet interface is configured on a separate Class C subnet, and each specifies a separate router. However, the second router is configured such that only IP addresses in the Class A subnet of 10.x.y.z are forwarded to the second router. All other external IP addresses are forwarded to the first router. # Specify IP address IPC.AddRoute[0].DestinationAddress = 198.62.139.32 IPC.AddRoute[0].Mask = 255.255.255.0 IPC.AddRoute[0].Interface = 1 # Specify route IPC.AddRoute[1].DestinationAddress = 0.0.0.0 IPC.AddRoute[1].Mask = 0.0.0.0 IPC.AddRoute[1].GatewayAddress = 198.62.139.1 # Specify IP address IPC.AddRoute[2].DestinationAddress = 198.62.140.75 IPC.AddRoute[2].Mask = 255.255.255.0 IPC.AddRoute[2].Interface = 2 # Specify route IPC.AddRoute[3].DestinationAddress = 10.0.0.0 IPC.AddRoute[3].Mask = 255.0.0.0 IPC.AddRoute[3].GatewayAddress = 198.62.140.1

3.7 Sample Board Keyword Files

The following sample configuration files are provided with Natural Access software.

E1 Configuration with ISDN

The ci6e1.cfg file shown below is a sample board keyword file provided with Natural Access software. It is located in the nms\cg\cfg (or opt/nms/cg/cfg for Unix) subdirectory under the Natural Access installation directory. This file shows a typical set of board keywords necessary to configure and start a CG 6000C board using ISDN and E1 line interfaces. # ci6e1.cfg # CG 6000 configuration file # # This file configures the board to run NMSVoice with NOCC. # # Clocking.HBus.ClockMode = STANDALONE Clocking.HBus.ClockSource = OSC Clocking.HBus.ClockSourceNetwork = 1 TCPFiles = nocc isd0 DSPStream.VoiceIdleCode[0..3] = 0xD5 DSPStream.SignalIdleCode[0..3] = 0x0D Hdlc[0,3,6,9].Boot = YES Hdlc[0,3,6,9].Comet.TxTimeSlot = 16 Hdlc[0,3,6,9].Comet.RxTimeSlot = 16 NetworkInterface.T1E1[0..3].Type = E1 NetworkInterface.T1E1[0..3].Impedance = G703_120_OHM NetworkInterface.T1E1[0..3].LineCode = HDB3 NetworkInterface.T1E1[0..3].FrameType = CEPT NetworkInterface.T1E1[0..3].SignalingType = PRI NetworkInterface.T1E1[0..3].D_Channel = ISDN DSP.C5x[0..31].Libs[0] = cg6kliba DSP.C5x[0..31].XLaw = A_LAW DSP.C5x[1..31].Files = voice tone dtmf echo callp ptf #DSP.C5x[1..31].Files = voice tone dtmf echo rvoice \ callp ptf wave DSP.C5x[0].Files = qtsignal tone dtmf echo NULL NULL NULL Resource[0].Name = RSC1 Resource[0].Size = 120 Resource[0].TCPs = nocc isd0 Resource[0].Definitions = ( dtmf.det_all & echo.ln20_apt25 \ & ptf.det_2f & ( (voice.rec_24 & \ (voice.play_24_100 | \ voice.play_24_150 | \ voice.play_24_200)) | tone.gen )) # The commented Resource Definition contains all IVR functions except OKI # To use the commented out resource definition, uncomment all of the lines # up to the DLMFiles and comment out the shorter resource definition. # Do the same with the DSP.C5x[].Files keyword. # Wave and rvoice must be loaded to the board for this resource definition. #Resource[0].Definitions =( dtmf.det_all & echo.ln20_apt25 & ptf.det_2f & \ #( ( (rvoice.rec_mulaw | rvoice.rec_alaw | rvoice.rec_lin | \ #voice.rec_16 | voice.rec_24 | voice.rec_32 | voice.rec_64 | \ #wave.rec_11_16b | wave.rec_11_8b) & \ #(rvoice.play_mulaw | rvoice.play_alaw | rvoice.play_lin | \ #voice.play_24_100 | voice.play_24_150 | voice.play_24_200 | \ #voice.play_64_100 | voice.play_64_150 | voice.play_64_200 | \ #voice.play_32_100 | voice.play_32_150 | voice.play_32_200 | \ #voice.play_16_100 | voice.play_16_150 | voice.play_16_200 | \ #wave.play_11_16b | wave.play_11_8b)) | \ #tone.gen | callp.gnc | ptf.det_4f)) DLMFiles[0] = cg6krun DLMFiles[1] = isdnetsi # For USA ISDN configurations uncomment one of the DMSFile[1] keywords #DLMFiles[1] = isdnvn6 #DLMFiles[1] = isdnqsig #DLMFiles[1] = isdnaus1 #DLMFiles[1] = isdnkor DebugMask = 0x0

No Call Control Configuration

The c6nocc.cfg file shown below is a sample board keyword file provided with Natural Access software. It is located in the nms\cg\cfg (or opt/nms/cg/cfg for Unix) subdirectory under the Natural Access installation directory. It shows the set of board keywords necessary to configure and start a CG 6000C board. # c6nocc.cfg # CG 6000 configuration file # # This file configures the board to run Voice with NOCC. # Clocking.HBus.ClockMode = STANDALONE Clocking.HBus.ClockSource = OSC Clocking.HBus.ClockSourceNetwork = 1 TCPFiles = nocc DSPStream.VoiceIdleCode[0..3] = 0x7F DSPStream.SignalIdleCode[0..3] = 0x00 NetworkInterface.T1E1[0..3].Type = T1 NetworkInterface.T1E1[0..3].Impedance = DSX1 NetworkInterface.T1E1[0..3].LineCode = B8ZS NetworkInterface.T1E1[0..3].FrameType = ESF NetworkInterface.T1E1[0..3].SignalingType = CAS DSP.C5x[0..31].Libs[0] = cg6klibu DSP.C5x[0..31].XLaw = MU_LAW DSP.C5x[1..31].Files = voice tone dtmf echo callp \ ptf NULL DSP.C5x[0].Files = qtsignal tone dtmf echo callp NULL NULL Resource[0].Name = RSC1 Resource[0].Size = 120 Resource[0].TCPs = nocc Resource[0].Definitions = ( dtmf.det_all & \ echo.ln20_apt25 & ptf.det_2f & ( (voice.rec_24 & (voice.play_24_100 | voice.play_24_150 | voice.play_24_200)) | tone.gen )) DLMFiles[0] = cg6krun DebugMask = 0x0

3.8 Using DSP Resource Management Keywords

CG 6000C DSP resource management is configured to operate on a per-port basis. A port is associated with a circuit-switched call (for PSTN-based applications) or another type of media stream. DSP resource management determines the DSPs on which particular DSP functions run, and can ensure that the DSP resources required to support a call are available when needed.
CG 6000C DSP programs are distributed in files known as Data Processing Modules (DPMs). These files use the extension .f54, and contain executable code for a family of algorithms. Each algorithm in that family is known as a Data Processing function (DPF), and can be referenced by a unique string generated by combining the DPM ID with a function ID string.
This section describes the keywords used to control DSP resource management on CG 6000C boards.

Caution:

The standard set of board keyword files provided with CG 6000C software (and Fusion software) contains DSP resource management settings suitable for most applications. Therefore, in most cases you do not need to modify these resource definitions and can skip this section.

However, if your application requires resources not specified in the sample board keyword files, you may need to customize the CG 6000C DSP resource management settings. You should understand how the CG 6000C DSP resource manager allocates resources before modifying the standard DSP resource definitions. For more information about how CG 6000C resources are calculated and how to set up CG 6000C DSP resource management, refer to Appendix B.

*Caution:*	The standard set of board keyword files provided with CG 6000C software (and Fusion software) contains DSP resource management settings suitable for most applications. Therefore, in most cases you do not need to modify these resource definitions and can skip this section. However, if your application requires resources not specified in the sample board keyword files, you may need to customize the CG 6000C DSP resource management settings. You should understand how the CG 6000C DSP resource manager allocates resources before modifying the standard DSP resource definitions. For more information about how CG 6000C resources are calculated and how to set up CG 6000C DSP resource management, refer to Appendix B.

3.8.1 Resource Management Keywords

The following keywords are used to configure CG 6000C board DSP resource management: Keyword Description DSP.C5x[x].files Specifies the data processing function modules (DPMs) to load to a specified CG 6000C board DSP. TCPFiles[x] Specifies the trunk control programs (TCP) loaded to the board. Resource[x].TCPs Specifies the TCPs the resource manager uses with the resource definition. Resource[x].Name Associates a name (character string) with a particular resource definition. Resource[x].Definitions Specifies a relational string of Data Processing Functions (DPFs), describes the functionality that can occur on a single port, and describes how and when functions execute in relation to each other. Resource[x].Size Specifies the number of channels or ports managed by the on-board resource manager.
The following sections describe in detail how to use the DSP.C5x[x].Files and Resource[x].Definitions keywords. For more information about these and other CG 6000C DSP resource management keywords, refer to Chapter 6.

Keyword	Description
DSP.C5x[x].files	Specifies the data processing function modules (DPMs) to load to a specified CG 6000C board DSP.
TCPFiles[x]	Specifies the trunk control programs (TCP) loaded to the board.
Resource[x].TCPs	Specifies the TCPs the resource manager uses with the resource definition.
Resource[x].Name	Associates a name (character string) with a particular resource definition.
Resource[x].Definitions	Specifies a relational string of Data Processing Functions (DPFs), describes the functionality that can occur on a single port, and describes how and when functions execute in relation to each other.
Resource[x].Size	Specifies the number of channels or ports managed by the on-board resource manager.

3.8.2 Resource Definition String Syntax

When specifying resource definitions, you can use a set of logical operators in board keyword files to combine DPFs and define the relationships between them.
The following operators are supported in board keyword files: Operator Description & And | Exclusive Or () Inclusion and the beginning and end of the resource string. \ Line break. Note: Resource[x].Definitions strings always start with an open-parenthesis, and end with a close-parenthesis.

Operator	Description
`&`	And
`\|`	Exclusive Or
`()`	Inclusion and the beginning and end of the resource string.
`\`	Line break.

3.8.3 DSP Files

The DSP.C5x[x].Files keyword specifies the DPMs that are loaded to particular DSPs. Note: In general, most configuration files load DSPs 1-31 with the same DSP files.
The CG 6000C DSP resource manager recognizes and manages only DPFs that are specified with the Resource[x].Definitions keyword. The DSP resource manager only recognizes DPFs if the DPMs in which they reside have been loaded to board DSPs. Load DPMs to the CG 6000C board by specifying the DPM name in a DSP.C5x[x].Files keyword string, where x represents a DSP or range of DSPs.
If the DSP resource manager is allocating resources, but finds that a DPF is not loaded to any DSP, it returns the error:
Board Error 0xa0e: Function 0xXXXXXXXX not found on any engine.
Where XXXXXXXX is the value of the DFF not found.

Example: Configuring Available DSP Resources

Use the DSP.C5x[x].Files keyword to load a particular DPMs functionality to specific DSPs on the CG 6000C board. Specify DPM files to load by using the following format:
DSP.C5x[x].Files = dpmfilename dpmfilename dpmfilename...
Where x refers to the DSP core, or a range of DSP cores, to load (there are 32 DSP cores on the CG 6000C board, so the value of x ranges from 0 to 31), and dpmfilename refers to a DPM to load to the corresponding DSP cores.
For example, the string:
DSP.C5x[1,5,11].Files = echo dtmf
indicates to load cores DSP[1], DSP[5], and DSP[11] with the DPMs echo and dtmf.

You can also specify to load the DPM files to a range of DSPs, as in the following:
DSP.C5x[1..31].Files = echo dtmf ptf
In this case, the string indicates to load cores DSP[1] through DSP[31] with the DPMs echo, dtmf, and ptf.

3.8.4 Resource Definitions

The following sections provide several examples of Resource[x].Definitions strings that use the DPFs echo.ln20_apt100, dtmf.det_all, ptf.det_2f, and voice.rec_32. These examples specify which DPFs run on a specific DSP as well as the relationship between these DPFs (that is, which DPFs can run simultaneously and which can not).

Example: All DPFs Running Exclusively

In the following example all the DPFs specified in the resource definition string run exclusively (in other words, only one DPF can run at a time). In this case, you would set the Resource[x].Definitions keyword string to:
Resource[1].Definitions = ( dtmf.det_all | ptf.det_2f | voice.rec_32)

Example: All DPFs Execute Simultaneously

In the following example all of the DPFs specified in the resource definition string can run at the same time. In this case, you would set the Resource[x].Definitions keyword string to:
Resource[1].Definitions = ( echo.ln20_apt100 & dtmf.det_all & \
ptf.det_2f & voice.rec_32 )

3.8.5 Specifying Conditional Relationships Between DSP Functions

The following examples definitions that specify conditional relationships between DPFs using the AND, OR operators and parenthesis to combine DPF string IDs. In these examples some DPFs or groups of DPFs run simultaneously while others run exclusively.

Example 1

In the following example, any one OKI play DPF runs simultaneously with: OKI record DTMF detection Echo cancellation Precise tone detection with two single frequencies
You can run simultaneous 24 kbps OKI ADPCM play and record functions by specifying the following Resource[x].Definitions string: Resource[1].Definitions = ( dtmf.det_all & echo.ln20_apt25 & \ ptf.det_2f & (( oki.rec_24 & (oki.play_24_100 | oki.play_24_150 | \ oki.play_24_200 ) ) )
This resource definition string reserves DSP resources so that one of the OKI play function (oki.play_24_100, oki.play_24_150, or oki.play_24_200) is able to run simultaneously with the OKI record function (oki.rec_24).

Example 2

In this example, OKI play, OKI record, or tone functions run in the connected state, but not at the same time. Functions that execute simultaneously with OKI play, OKI record, or tone functions include: DTMF detection Echo cancellation Precise tone detection with two single frequencies Note: In this example, the tone generator will not run if the OKI ADPCM play or record functions are running.
You can run a 24 kbps ADPCM OKI play function or a 24 kbps ADPCM OKI record function (a 24 kbps ADPCM OKI play function never runs at the same time as 24 kbps ADPCM OKI record function) by specifying the following Resource[x].Definitions string:
Resource[1].Definitions = ( dtmf.det_all & echo.ln20_apt25 & \ ptf.det_2f & ( oki.rec_24 | oki.play_24_100 | oki.play_24_150 \ |oki.play_24_200 | tone.gen ))
This resource definition string allows either the record functions, one of the play functions, or the tone generator to run at the same time as the DTMF detection, echo cancellation, and precise tone detection functions.

3.8.6 Echo Cancellation Restrictions

Only one echo canceller runs per call. Therefore, there should be only one occurrence of echo cancellation in the Resource[x].Definitions string.

Version

Want to send us feedback on our documentation? Email: Tech_Pubs@nmss.com