software guide version 4.9

V25, V50PLUS, V150 AND V200

Software Guide

Version 4.9

www.vocality.com

BEFORE INSTALLING THE UNIT

PLEASE REFER TO THE SAFETY INSTRUCTIONS IN APPENDIX A

Contacts For further information, contact:

Vocality International Ltd

Lydling Barn

Lydling Farm

Puttenham Lane

Shackleford

Surrey GU8 6AP

United Kingdom

Tel +44 (0) 1483 813 120

Fax +44 (0) 1483 813 121

For technical support, email [email protected]

For sales information, email [email protected]

For online support, registered users should visit www.vocality.com and select the ‘support’ section.

Table of Contents

1 ABOUT THIS MANUAL.................................................................................... 8

1.1 Conventions..............................................................................................................8

1.2 Structure ..................................................................................................................8

2 CONFIGURING THE UNIT............................................................................... 9

2.1 Standard Configuration or Push-Config?...................................................................9

2.2 The Port Addressing Scheme ....................................................................................9 2.2.1 The Node ID....................................................................................................... 10 2.2.2 The Slot and Channel Numbers ............................................................................. 10

2.2.2.1 V200 and V150 ................................................................................................ 10 2.2.2.2 V50plus, V25 ................................................................................................... 12

2.3 Using the Supervisor or Management and Configuration (M&C) Port......................13 2.3.1 User Interface .................................................................................................... 13 2.3.2 Cursor Movement................................................................................................ 15 2.3.3 Parameter Selection ............................................................................................ 15 2.3.4 Updating the Configuration................................................................................... 15 2.3.5 Password Protection ............................................................................................ 17

2.4 Menu Structure.......................................................................................................19 2.4.1 The MAIN menu.................................................................................................. 20 2.4.2 The SYSTEM menu .............................................................................................. 22 2.4.3 The CONFIGURATIONS menu................................................................................ 28 2.4.4 The CLOCKING menu .......................................................................................... 32

2.4.4.1 Clocking and Push Config................................................................................... 34 2.4.5 The ROUTING menu ............................................................................................ 35

2.4.5.1.1 Overview .................................................................................................. 39 2.4.5.2 Secondary Routing ........................................................................................... 39

2.4.5.2.1 Configuration ............................................................................................ 39 2.4.5.2.2 Failure & Recovery ..................................................................................... 40

2.4.5.2.2.1 Data Aggregates................................................................................... 40 2.4.5.2.2.2 IP Aggregates ...................................................................................... 40

2.4.5.2.3 Status, Logs & Alarms ................................................................................ 40 2.4.5.3 Push Config ..................................................................................................... 40

2.4.6 The SIP GATEWAY menu...................................................................................... 41 2.4.6.1 The SYSTEM menu............................................................................................ 42 2.4.6.2 The CHANNEL SUMMARY menu........................................................................... 43 2.4.6.3 The CHANNEL DETAILS menu............................................................................. 44

2.4.6.4 The SIP DIRECTORY menu................................................................................. 47 2.4.7 The FEATURE KEYS menu..................................................................................... 48 2.4.8 The CALL ROUTING menu .................................................................................... 49

2.4.8.1 The HUNT GROUPS menu .................................................................................. 50 2.4.8.2 The AUTO MAPPING menu ................................................................................. 52 2.4.8.3 The DIRECTORY menu....................................................................................... 55 2.4.8.4 The MLPP menu................................................................................................ 57

2.4.8.4.1 The MLPP ENTRIES menu ............................................................................ 59 2.4.9 The SLOTS menu ................................................................................................ 61

2.4.9.1 The DATA menu ............................................................................................... 63 2.4.9.2 The ANALOGUE VOICE menu.............................................................................. 69

2.4.9.2.1 The ANALOGUE PORTS menu....................................................................... 70 2.4.9.2.2 The SIGNALS & TONES menu ...................................................................... 73 2.4.9.2.3 The VOICE ACTIVATION menu ..................................................................... 75

2.4.9.3 The IP menu.................................................................................................... 76 2.4.9.3.1 The GENERAL menu ................................................................................... 77 2.4.9.3.2 The NETWORKS menu ................................................................................ 79

2.4.9.3.2.1 Loopback interfaces .............................................................................. 81 2.4.9.3.3 The ROUTE MANAGEMENT menu .................................................................. 81

2.4.9.3.3.1 The RIPv2 menu................................................................................... 82 2.4.9.3.3.2 The OSPF menu.................................................................................... 84

2.4.9.3.3.2.1 The SYSTEM menu......................................................................... 85 2.4.9.3.3.2.2 The AREA menu ............................................................................ 87 2.4.9.3.3.2.3 The INTERFACE menu .................................................................... 89 2.4.9.3.3.2.4 The VIRTUAL LINK menu ................................................................ 91

2.4.9.3.4 The IP STATIC ROUTE TABLE menu .............................................................. 93 2.4.9.3.5 The POLICY menu ...................................................................................... 95

2.4.9.3.5.1 The ADDRESS LISTS menu .................................................................... 96 2.4.9.3.5.2 The ROUTE MAPS menu......................................................................... 99 2.4.9.3.5.3 The RIP EXPORT FILTERS menu............................................................ 103 2.4.9.3.5.4 The AGGREGATION menu .................................................................... 104

2.4.9.3.6 The ACCESS TABLE menu ......................................................................... 106 2.4.9.3.7 The UDP RELAY TABLE menu ..................................................................... 107 2.4.9.3.8 The DBA POOLS menu .............................................................................. 108 2.4.9.3.9 The MAC SOURCE FILTER TABLE menu ....................................................... 112 2.4.9.3.10 The SERVICE MANAGEMENT menu............................................................ 113

2.4.9.3.10.1 The ADDRESS DEFINITIONS menu........................................................ 114 2.4.9.3.10.2 The PROTOCOL DEFINITIONS menu ...................................................... 115 2.4.9.3.10.3 The FILTER TABLE menu...................................................................... 116 2.4.9.3.10.4 The TCPGw FILTER TABLE menu ........................................................... 118

2.4.9.3.11 IP AGGREGATES menu............................................................................ 118 2.4.9.4 The SYSLOG menu ......................................................................................... 122 2.4.9.5 The ISDN menu.............................................................................................. 124

2.4.9.5.1 Terminal Adaptor(TA) Mode....................................................................... 125 2.4.9.5.1.1 US NI-1, Manual SPID Entry................................................................. 128 2.4.9.5.1.2 US NI-1, Automatic SPID Entry............................................................. 129 2.4.9.5.1.3 US NI-1, Auto SPID Entry with SPID Guessing ........................................ 130

2.4.9.5.2 Network Function Semi(NFS) Mode............................................................. 132 2.4.9.6 The DIGITAL VOICE menu ............................................................................... 135

2.4.9.6.1 The DIAL PARAMETERS menu .................................................................... 141 2.4.9.7 The TDM menu............................................................................................... 143

2.4.9.7.1 The TDM Timeslots menu .......................................................................... 144 2.4.9.7.1.1 Destination Specifics ........................................................................... 146

2.4.9.7.2 Timeslot Types ........................................................................................ 147 2.4.9.7.2.1 Selecting The Best Packet Type ............................................................ 151

2.4.9.7.3 The TDM Advanced Config menu ................................................................ 152 2.4.9.7.3.1 Radio Silence mode............................................................................. 153

2.4.9.8 The DIAGNOSTICS menu................................................................................. 154 2.4.9.9 The SNMP menu............................................................................................. 155

2.4.9.9.1 The SNMP GENERAL menu ........................................................................ 156 2.4.9.9.2 The SNMP KEYS menu .............................................................................. 157 2.4.9.9.3 The SNMP TARGET TABLE menu................................................................. 158 2.4.9.9.4 The SNMP TRAP CONFIGURATIONS menu.................................................... 159

2.4.10 The SOFTWARE MANAGEMENT menu ................................................................... 160 2.4.11 The SLOT MANAGEMENT menu ........................................................................... 162 2.4.12 The BACKUP SYNCHRONIZATION menu ............................................................... 165 2.4.13 The ALARM MANAGEMENT menu ......................................................................... 166

2.4.13.1 The CURRENT ALARMS menu ........................................................................... 167 2.4.13.2 The ALARM SIGNALS menu.............................................................................. 169 2.4.13.3 The SYSTEM EVENTS menu.............................................................................. 170 2.4.13.4 The SERIAL DATA EVENTS menu ...................................................................... 172 2.4.13.5 The IP EVENTS menu ...................................................................................... 173 2.4.13.6 The E1/T1/J1 EVENTS menu ............................................................................ 175 2.4.13.7 The ALARM LOG menu .................................................................................... 176

2.4.14 The PUSH CONFIG CLIENTS menu....................................................................... 177 2.4.15 The REMOTE menu............................................................................................ 179

3 DIAGNOSTICS ........................................................................................... 181

3.1 The DIAGNOSTICS menu .................................................................................181 3.1.1 The CLOCK STATUS menu.................................................................................. 182 3.1.2 The AGG SUMMARY menu .................................................................................. 183 3.1.3 The TEST PORTS menu ...................................................................................... 184 3.1.4 The SLOTS menu .............................................................................................. 186

3.2 The SLOT N / DIAGNOSTICS menu ...................................................................186 3.2.1 The IP menu .................................................................................................... 187

3.2.1.1 The PING menu.............................................................................................. 187 3.2.1.2 The IP ROUTE TABLE menu.............................................................................. 191 3.2.1.3 The IP STATISTICS menu ................................................................................ 192 3.2.1.4 The ETHERNET menu ...................................................................................... 195 3.2.1.5 The POWER OVER ETHERNET menu .................................................................. 196

3.2.1.5.1 The SLOT x menu .................................................................................... 197 3.2.1.6 The ARP TABLE menu...................................................................................... 199 3.2.1.7 The BRIDGE FDB menu ................................................................................... 200 3.2.1.8 The BRIDGE PORTS menu................................................................................ 201

3.2.2 The DATA PORT STATS menu ............................................................................. 202 3.2.3 The AGG CALL STATS menu ............................................................................... 206 3.2.4 The TRIB CALL SUMMARY menu.......................................................................... 207 3.2.5 The TRIB CALL STATS menu............................................................................... 208 3.2.6 The AGG STATUS menu ..................................................................................... 209 3.2.7 The SYSTEM INFO menu .................................................................................... 210 3.2.8 The TDM Status menu ....................................................................................... 211 3.2.9 The TDM STATISTICS menu ............................................................................... 213 3.2.10 The LOGS menu ............................................................................................... 217

3.2.10.1 The CONNECTION LOG menu ........................................................................... 218 3.2.10.2 The CONFIGURATION LOG menu ...................................................................... 219 3.2.10.3 The ALARM LOG menu .................................................................................... 220 3.2.10.4 The CALL RECORD LOG menu .......................................................................... 221 3.2.10.5 The IP LOG menu ........................................................................................... 222 3.2.10.6 The SIP GATEWAY LOGS menu......................................................................... 223 3.2.10.7 The SVR DEBUG LOG menu.............................................................................. 224 3.2.10.8 The ALL LOGS menu ....................................................................................... 225 3.2.10.9 The LOG HELP menu ....................................................................................... 226

3.2.11 The SNMP STATS menu ..................................................................................... 227

4 FEATURES.................................................................................................. 228

4.1 Data Capabilities...................................................................................................228

4.2 Voice Capabilities .................................................................................................228

4.3 Multi-level Precedence and Pre-emption (MLPP) ..................................................229 4.3.1 MLPP Service Invocation .................................................................................... 230

4.3.1.1 Primary rate interface ..................................................................................... 230 4.3.1.2 Invoking an outgoing precedence call ................................................................ 230 4.3.1.3 Provisioning access codes ................................................................................ 231

4.3.2 Pre-emption Rules............................................................................................. 232 4.3.2.1 Precedence call with no pre-emption ................................................................. 232 4.3.2.2 Precedence Call Pre-empted............................................................................. 233 4.3.2.3 Precedence Ringback and Cadence.................................................................... 233

4.3.3 Interaction with other features............................................................................ 233

4.4 Push-Config ..........................................................................................................234 4.4.1 Push-Config Features......................................................................................... 235

4.4.1.1 Multi-unit configuration at hub site for remotes................................................... 235 4.4.1.2 Remote Unit Identification ............................................................................... 235 4.4.1.3 Pushing the Config.......................................................................................... 235 4.4.1.4 Automatic Routing .......................................................................................... 236 4.4.1.5 Start-up Configs for Remote Units..................................................................... 236 4.4.1.6 Reconfiguration Control ................................................................................... 238

4.5 Call Progress Tones ..............................................................................................238

4.6 Dynamic Bandwidth Allocation .............................................................................239

4.7 Asymmetric Bandwidth.........................................................................................240

4.8 Clocks ...................................................................................................................240 4.8.1 Direction Conventions........................................................................................ 240 4.8.2 Global Clocks ................................................................................................... 242 4.8.3 Receive Clocks ................................................................................................. 243 4.8.4 Transmit Clocks ................................................................................................ 244 4.8.5 Phase-Locked Loops .......................................................................................... 245

4.9 Broadcast Mode ....................................................................................................245

4.10 Async Error-correction and Compression..............................................................245 4.10.1 Error-correction ................................................................................................ 246 4.10.2 Compression .................................................................................................... 247 4.10.3 General Characteristics ...................................................................................... 247

4.11 Switched Carrier Operation...................................................................................247 4.11.1 SWITCHED Mode .............................................................................................. 247 4.11.2 SCADA Mode .................................................................................................... 249

4.12 The Integrated IP Router......................................................................................251 4.12.1 Overview ......................................................................................................... 251 4.12.2 Basic IPV4 Routing............................................................................................ 251 4.12.3 Network Configuration ....................................................................................... 251 4.12.4 Virtual Ports ..................................................................................................... 252 4.12.5 Unnumbered IP ................................................................................................ 254 4.12.6 MTUs .............................................................................................................. 255 4.12.7 RIPv2 and OSPF................................................................................................ 258

4.12.7.1 Compatibility ................................................................................................. 259 4.12.8 Static Routes.................................................................................................... 260 4.12.9 Loopback Interfaces .......................................................................................... 260 4.12.10 Example Configuration....................................................................................... 261 4.12.11 UDP Relay........................................................................................................ 265 4.12.12 TCP Gateway –(TCP PEP) ................................................................................... 266 4.12.13 DHCP Client/Server/Relay .................................................................................. 266 4.12.14 Telnet Access ................................................................................................... 270 4.12.15 Spanning Tree Protocol ...................................................................................... 271

4.13 IP Aggregates.......................................................................................................271

4.14 TDM Aggregates ...................................................................................................272 4.14.1 TDM Aggregate Specification .............................................................................. 273 4.14.2 Targets Supported ............................................................................................ 273 4.14.3 Interworking .................................................................................................... 273 4.14.4 TDM Tunnelling................................................................................................. 274 4.14.5 Configuration Summary ..................................................................................... 274

4.15 SIPGw...................................................................................................................275

4.16 SNMP ....................................................................................................................275

5 APPLICATIONS EXAMPLES ........................................................................ 276

5.1 Back-to-back Testing ............................................................................................276

5.2 Use with Satellite Modems....................................................................................280

5.3 Use with IP Aggregates ........................................................................................285

5.4 Broadcast Voice and Data .....................................................................................292

APPENDIX A: ABBREVIATIONS...................................................................... 295

APPENDIX B: INDEX ...................................................................................... 297

C H A P T E R 1 A B O U T T H I S M A N U A L

Multiplexer Software Guide Version 4.9 of 297

1 About This Manual The portfolio of Vocality International multiplexer/router products contains a wide range of units from the

compact hand-portable V25 to the expandable, rackmount V200. Even so, the whole range is based on a

common core of software functionality and the various members differ only in their physical architecture,

number of ports and flexibility. This manual describes the generic software facilities for all products, with

specific exceptions noted either in the text itself or through the use of icons as described below.

Details of the hardware for each unit are provided in an individual Hardware Guide which should be read

in conjunction with this manual. The Hardware Guide contains important safety information and

Declarations of Conformity and must be read before installing the product.

1.1 Conventions

Throughout the text, each section heading is accompanied by a set of four icons bearing the legends

“V25”, “V50+”, “V150” and “V200”:

Some icons may be absent, indicating the section is not relevant to a particular product. It may be the

case that most of a section is relevant but specific details are different; where this is the case the icon is

present but exceptions are noted in the text with an asterisk “*”. For example, the valid range for some

configurable objects is different on the high-speed CPU on the V200 and V150 systems only.

1.2 Structure

This manual contains a section on Configuration, which consists of detailed examples of all of the menu

pages together with explanations of all of the features and lists of all of the selection options. For a

summary of the unique features and benefits the Vocality products offer, read the section entitled

“Features”. For practical discussions on how the software should be configured to suit specific applications,

there is a section entitled “Applications Examples”.

Chapter

1 Chapter

1

C H A P T E R 2 C O N F I G U R I N G T H E M U L T I P L E X E R


2 Configuring the Unit 2.1 Standard Configuration or Push-Config?

All of the units may be configured manually using a menu system which is accessed using a PC or laptop.

The computer can gain access to the menus either serially using the Monitor and Control port or via the

Ethernet port using a Telnet session. These techniques may be used to set up both the locally connected

unit and also any remote unit that is connected in the network and it relies on complete knowledge of how

all of the relevant parameters must be set, against a background of default initial values which help to get

the unit working with the minimum number of changes.

As an alternative to the manual approach, V25, V50plus and V150 units may receive their configuration

settings automatically from a hub unit using a mode known as “Push-Config”. In this case, the hub unit,

which may be either a V200 or a V150, contains all of the configurations for the clients in the network and

pushes them out using a proprietary protocol at start of day. These configurations are entered at the hub

on a dedicated menu screen. By default, V25 and V50plus units start up in Push-Config mode and must

be configured into Standard Configuration mode in order to be set up manually. Refer to section 4.4

“Push-Config” for details. The primary aim of Push-Config is to remove the need for multiplexer

management skills from personnel in the field, whilst retaining the ability to dynamically change network

operation. The ultimate aim is for a factory-defaulted multiplexer to be installed at a remote site, and

automatically obtain its multiplexer settings when it is connected to the Vocality network. When in Push-

Config mode, a remote unit obtains its configuration when it initially connects to a hub multiplexer –

therefore only basic serial aggregate connectivity to the hub unit is required in the remote unit

configuration.

Note that this feature is an optional enhancement to the existing management scheme. It is intended for

remote sites in a hub-spoke type network (i.e. not mesh) where there is a single aggregate link in use at

the remote site. A customer may continue with the manual configuration mode (where the remote

multiplexer carries its own complete configuration) if the restrictions imposed by Push-Config operation

are too inflexible.

2.2 The Port Addressing Scheme

Throughout the configuration of the Vocality multiplexer/router products, references are made to nodes,

bays, slots and port numbers in the network. By convention, the addressing syntax used is

“NODE:SLOT:CHANNEL”, where NODE is the Node ID, SLOT refers to a logical grouping of ports, often on

the chassis or a particular card and CHANNEL refers to a specific port within a slot. This scheme is

Chapter

2



interpreted according to the physical arrangement of each unit. The details specific to each product are

given below.

2.2.1 The Node ID

The most important item in the multiplexer’s configuration is the Node ID. This is a unique number

between 0 and 999 (however, 240-255 are reserved) which specifies each chassis in the network and it

must be programmed into the unit before anything else. This is done on the SYSTEM menu – see Section

2.4.2 for details.

Once the Node ID has been programmed, the unit should be restarted since this allows it to clear all

previous routing information and assume the new identity without confusion. NOTE: When a remote unit

is configured for Push-Config (the factory default operation for all multiplexers except the V200 and

V150), the Node ID is set via the Push Config Client menu screen. See section 2.4.14, “The PUSH CONFIG

CLIENTS menu”.

2.2.2 The Slot and Channel Numbers

2.2.2.1 V200 and V150

From the rear, the V200 is laid out as follows:

ETHERNET 2STATUS

CPU

ALERT

ALARMS

12PORT 1

M&C

ETHERNET 1

ETHERNET 2STATUS

CPU

ALERT

ALARMS

12PORT 1

M&C

ETHERNET 1

ALERTPORTS 1 TO 4

EXPANSION

STATUS

DATA

ALERTPORTS 1 TO 4

EXPANSION

STATUS

DATA

TX

E1/T1

RX

ALERT

UTPSTATUS

TX

E1/T1

RX

ALERT

UTPSTATUS

STATUS

A.C.PSU

100-240AC 47-63Hz

STATUS

A.C.PSU

100-240AC 47-63Hz

ALERT1 STATUS 2

ENETDATA

CHANNELS 1-8

12

34

56

78

ALERT1 STATUS 2

ENETDATA

CHANNELS 1-8

12

34

56

78

The V150 is laid out as follows:

A SLOT is a number which maps a card in a physical bay to a logical slot via the Slot Management menu

and CHANNEL is a number which indicates the particular channel number within that logical slot. By

default Bay A is mapped to Slot 0, Bay B is mapped to Slot 1 and so on. See the table below:

A B C

A B C

A B C D E F G H I J

M&C PORT

BACKUP PSU

MAIN PSU



Bay Default Slot mapping V150 V200 A 0 0 B 1 1 C 2 2 D - 3 E - 4 F - 5 G - 6 H - 7 I - 8/PSU2 J - PSU1

The configuration pages list local channels only, so they begin with a simplified version just using the slot

and channel numbers, such as “0:1” and “0:2”.

So why use bays as well as slots? Bays are used as a means of identifying the physical position of a card

within the chassis, whereas the slot number is purely a logical identity used to define a card’s place in the

addressing system. This allows a CPU card in Bay A to be defined as Slot 0, with its backup CPU card in

Bay B, which is defined as the “Slot 0 Backup Card” and which is configured identically to the primary

card. In this example Bay C could then house Slot 1 and so on. In fact, the only rule is that Bay A must

house the Slot 0 primary card – all other logical slots may be located in any other physical Bay, in any

order.

CHANNEL is a number which means the particular channel number within a slot. So, for example, the

DB15HD connector labelled “DATA” on the Standard CPU card in Bay A(Slot 0) Node3, which happens to

be the V150 above, would be indicated as “3:0:0”, or voice channel 4 on same card would be called

“3:0:4”.

The routing of voice channels is often done dynamically by decoding the DTMF dialling digits. In this case,

the destination field is simply set to “AUTO” and the route is either directly decoded from the dialled digits

or looked up in the internal directory. So, for example, if the directory number for “23:1:7” is “820”, then

when the number “820” is dialled from anywhere in the network, the telephone on channel 7 of the card

in Option Card 1 in node 23 will ring. NOTE: This assumes the directory entry is configured on all

multiplexers in the network.



The ports of the V50plus are grouped as follows:

The ports of the V25 are grouped as follows:

For V25 and V50plus systems the integrated router is on slot 0 and channels 0:10 through 0:31 are used

to represent IP tributaries. The configuration pages list local channels only, so they begin with a simplified

version just using the slot and channel numbers, such as “0:10” and “0:11”. Voice channels in the V25

are assigned to logical slot 1 and all other ports are assigned to slot 0. The assignment is similar in the

V50plus, although the option slot numbers more naturally represent the physical module that may be

fitted at either end.

For V150 and V200 systems on the High-Speed CPU cards, channels x:10 through x:99 are used to

represent IP tributaries. On standard CPU cards, channels x:10 through x:31 are used to represent IP

tributaries. Again for V150 and V200 systems, the integrated router may be in the system multiple times

— one for each CPU card (standard or high speed) installed. If IP is configured on a high speed CPU card

in slot 3, the tributaries available are 3:10-3:99. If IP is configured on a standard CPU card in slot 0, the

tributaries are 0:10-0:31.

2.2.2.2 V50plus, V25

Slot 0 – The Chassis Slot 1 – the Voice ports

Option Slot 1 Option Slot 2

Slot 0 – the chassis



2.3 Using the Supervisor or Management and Configuration (M&C) Port

2.3.1 User Interface

Vocality multiplexer/routers provide either a formatted menu control structure for interactive user control,

or a simple Teletype mode for interface to a network management system. The use of the formatted M&C

(supervisor) is described here; the Teletype mode is described in a separate manual supplement.

In formatted mode, the unit is configured by moving around the menus using the cursor keys and

selecting from a choice of available options for each parameter. The current cursor position is highlighted

in most terminal emulations. There are also a number of keys, which may be used as a shortcut or to

access additional features. The keys are summarised below, with key names represented between

chevrons, e.g. <SPACE> for the spacebar, <CR> for Carriage Return or Enter.

The unit is configured using an asynchronous terminal or PC running Windows™ 95/98/2000/XP/Vista

HyperTerminal, connected to the dedicated port on the back panel marked "M & C". On the “Connect To”

tab, HyperTerminal should be configured to use the COM port on the PC used to connect to the

multiplexer and on the “Settings” tab, the Function, arrow and ctrl keys should be set to act as terminal

keys:



Click on the “Configure” button to set HyperTerminal to operate at 9600bps, 8 data bits, no parity, one

stop bit with no flow control:

The unit supports most common terminal emulations, such as VT100, VT52, TVI925 and will automatically

detect the emulation in use. When the multiplexer is powered up with no passwords entered, it displays

the initial banner shown below.

(This menu may be returned to at any time by entering <CTRL>&<E>). Teletype mode may be entered

at this time by typing <CTRL>&<T> twice (the commands and responses used in teletype mode are

detailed in a separate manual). Once in Teletype mode, the above menu may again be returned to by

entering <CTRL>&<E>. To use the full-screen formatted configuration display, proceed as described

below.

Once the unit has been configured for use in an IP network, the management menus may also be

accessed via telnet.



2.3.2 Cursor Movement

<Up Arrow> Move to parameter above the current cursor position.

<Down Arrow> Move to parameter below the current cursor position.

<Right Arrow> Move to parameter to the right of the current cursor position.

<Left Arrow> Move to parameter to the left of the current cursor position.

<CR> Select a menu

<ESC> Return to the previous screen

2.3.3 Parameter Selection

Some parameters are selected by toggling around a sequence of choices, some are entered as

alphanumeric characters. Context-sensitive instructions are given at the bottom of the screen.

<+> or <Spacebar> Select next item in list

<-> Select previous item in list

<Spacebar> at alphanumeric field Clear field

<Characters> Enter literal data

2.3.4 Updating the Configuration

When a menu has been edited, the changes are stored in non-volatile system memory by entering

<ESC>, which prompts the user with this message:

“Save Changes (y/n)?”



Responding with a <Y> will update the non-volatile memory. The changes may be abandoned by entering

<N> instead.

If at any time the user wishes to clear all configuration settings and start again from factory defaults,

return to the terminal selection screen (Section 2.3.1) by entering <CTRL>&<E>, then enter

<CTRL>&<R> three times, to which the unit will prompt:

“Set Factory Defaults and Reboot?”

To proceed, enter “y”. Any other key will abort.

NOTE: This clears all the information stored in the numbered configuration stores and in the

system configuration.



2.3.5 Password Protection

To prevent unauthorised access to the menus, the unit has three levels of password protection; Read-

only, Read/Write and Superuser.

The serial number is used in the password mechanism. By default, the units have no passwords

configured, and there is no password required to access the supervisor port. The user can configure two

levels of password through the SYSTEM menu. The first is for read-only (RO) access - the second is for

read-write (RW) access. Once a RW password has been configured then any future access to the

supervisor port (either local or remote) will encounter a request for a password before allowing access. If

the RW password is entered, then the supervisor port works as before with full management functionality.

If the RO password is entered, then the menu system is presented, but any changes made to the

configuration will not be saved - also access to the debug menus and debug mode (and other shortcuts)

are prevented. The RO password is only effective once the RW password is configured.

Password entry is in a conventional format, with the entry being asterisked out and password setting

requiring re-entry for confirmation. The password is case-sensitive. If the user forgets their configured

password there is a backdoor mechanism to get them back into their units. This backdoor is the

"superuser" password - it is unique for each multiplexer, and consists of an encrypted key based on the

serial number. Once entered, the user is given normal read-write privileges to allow him/her to set the RW

password to something that they can remember! A superuser password can only be supplied by Vocality

International on the following telephone number:

+44 1483 813120

Please be prepared to supply your name, company name and the serial number of the unit.

Status Unit

Response Access rights

No password or default None Full access to menus, terminal and debug mode

RO password entered

Prompt for password

Full access to menus but no configs can be changed – no access to terminal and debug modes.

RW or superuser password entered

Prompt for password Full access to menus, terminal and debug mode

Users are encouraged to configure the ACCESS TIMEOUT on the SYSTEM screen to activate auto-logout.

NOTE: Users are advised not to configure the ACCESS TIMEOUT to less than 10 seconds.

Once a password has been entered it is effective until that session is completed with a CTRL-E command

or the session is inactive for the configured access timeout. - i.e. a CTRL-E to escape to the top-level

menu will require the user to re-enter the password (if configured) to continue.



In read-only access mode, the lines which divide the menu screens are composed of the tilde “~”

character. (In default or read-write mode they use the hyphen “-“).



2.4 Menu Structure

Once the user has entered an UP ARROW cursor key on the terminal selection screen - and if the unit is

not configured as a Push-Config client - the following page appears:

This is the Main Menu page. From here all of the submenu pages may be accessed by moving the

highlighted cursor up or down and pressing <ENTER>. To return up the menu tree, press <ESC> at any

time. The screen shown above is an example; the menu for each option card will only be shown if the card

is fitted.

All of the menu pages display the status lines at the top of the screen for information. At top left, the Node

Name of the currently logged unit appears. Below the “Vxxx Multiplexer Supervisor” banner, the

connection status of the aggregate links is displayed. For V200 and V150 systems, only the status of

aggregate ports on slot 0 is shown. The status of aggregate ports on other slots can be seen by accessing

the menus for those slots. In the example above, chassis data port 0:1 is configured as an aggregate and

has lost connection with a remote unit. Below this, the third line confirms the current menu page. The

right-hand corner of the top line is also used for important status messages. For example, the V200 and

V150 CPU card redundancy scheme will indicate when backup synchronization is required (BACKUP SYNC

REQUIRED). See the section “The BACKUP SYNCHRONIZATION menu” for more information.

At the bottom of the screen, the active configuration store (one of seven) is shown and on the final line, a

context-sensitive help line guides the user as to what may be entered in the current field.



The default MAIN menu for the V25, V50plus and V150 systems is shown below:

If this remote system is connected to a Vocality multiplexer network and if the hub system has been

configured to include this Push-Config client, the appropriate configuration is pushed to this remote

client enabling this system to connect to other multiplexers on the network. See section 2.1, “Standard

Configuration or Push-Config?” and section 4.4, “Push-Config” for more information.

If you wish to configure the multiplexer locally and do not wish to use the Push-Config feature, select

START-UP CONFIGURATION. The following screen is displayed:

2.4.1 The MAIN menu



Change the Mode from “Push Config” to “Normal”. Press <ESC>, then “y” to save the changes. The full

menu system is then displayed:



REAL TIME CLOCK

NOTE: V200 and V150 only

Sets the time and date of the real time clock. Once the time and date have been set, this is used by the

real time clock to ensure the multiplexer always shows the correct time and date. This information is not

lost during a reset or a default configuration.

NODE NAME

The SYSTEM SETTINGS menu allows the user to define a name for the chassis, which appears at the top

left-hand corner of the screen and is used to address the unit in Teletype mode. This may be

alphanumeric but must start with a letter.

NODE ID

The I.D. number specifies the chassis and must be unique within the network; the multiplexer uses it to

route packets to the correct destination. This number must be entered explicitly into each unit before the

network is configured and cannot be entered remotely. All other fields (except the “Configuration By

Remote” field – see below) may be edited locally or remotely.

2.4.2 The SYSTEM menu



CONFIGURATION BY REMOTE

Allows or prevents other users on the network from configuring this multiplexer via remote configuration.

The “Configuration By Remote” field may only be set locally since this prevents remote tampering.

MLPP COMPATIBILITY

In order to implement the MLPP functionality it has been necessary to add extra parameters to various call

control messages. This means that an MLPP enabled system is not compatible with pre-4.8.X versions of

software. In order to retain compatibility with these systems an additional item “MLPP COMPATIBILITY”

has been added to the system screen, the default for this option is OFF.

If the Compatibility option is set to OFF, the software will still be able to communicate with older software

variants however the MLPP functionality will be disabled and access to the MLPP configuration screens will

be blocked.

If the option is turned ON, the MLPP functionality will be available however the unit will no longer

communicate with any connected units running older software. In order for the MLPP functionality to

work, all participating units must have this option switched ON.

COUNTRY

Five country selections are available to allow the user to tailor the ring cadence and comfort tones of the

voice channels to suit national standards.

PROGRESS TONES

Call progress tones are generated by the multiplexer for voice calls connected through the system. These

indicate when a call is ringing, connecting and busy. Previously, the tones generated by the Vocality

multiplexer have been a proprietary set of frequencies and cadences – these are known as VOCALITY

progress tones. The tone can now also be set to COUNTRY – these are the standard set of frequencies and

cadences for the COUNTRY parameter that is also configured on this page.

CONNECTION TIMEOUT

Data paths in a multiplexer network are managed in terms of connections. When a telephone is lifted and

a destination channel number dialled, a connection request is processed by the routing software and

either accepted or rejected according to the existing link traffic. The CONNECTION TIMEOUT parameter

allows the network manager to optimise the timeout before the multiplexer rejects the request. This can

be adjusted to allow slow-response networks (e.g. DAMA) time to connect.

RECEIVE READY FILTER

In satellite systems there is often a “Carrier Detect” or “Receiver Ready” signal returned by the network

when the connection is made. In SWITCHED carrier modes (see Data Configuration), this is used by the



multiplexer as an indication to proceed. The signal produced by satellite modems can be unstable during

the initial stages of carrier acquisition and so a programmable filter is provided to guarantee the “Receiver

Ready” signal is steady before the multiplexer sends connection messages across the link.

DATA CHANNEL ACTIVATION

Connections for data channels in the multiplexer network are always point-to-point. In other words,

however complex the route taken from say, terminal to computer, a permanent connection is still set up

between the two devices. Here, the “DATA CHANNEL ACTIVATION” option is left in its default state of

“Auto”. In some cases, it may be desirable for the connected terminal equipment to switch the bandwidth

on only when required; in this case the “DATA CHANNEL ACTIVATION” option may be set to “Flag”, such

that the connection is set up when the terminal affirms the RTS signal (or equivalent in V.11, RS449 or

V.35 modes) into the port. This allows more flexible interworking with voice and DBA data channels.

DATA CHANNEL FLAG

In a similar way, the “DATA CHANNEL FLAG” setting allows the user to select how the “CTS” (or

equivalent) signal from the multiplexer reacts. It may be set permanently on, to activate only when the

connection is made or to reflect the state of the “RTS” signal at the remote port.

TIE-LINE ACTIVATION

This item only appears when voice channels are fitted. For voice channels, the “TIE_LINE ACTIVATION”

field specifies how Tie-line bandwidth is requested. In “Auto” mode, a permanent connection is made

which takes bandwidth all the time. When set to “M-lead”, connections are made only when the M-lead is

seized, thereby yielding bandwidth when not required.

“M-lead & Back Busy” was developed to overcome a failing in system topologies which are indirectly

connected to a remote analogue PABX. Such systems in the multiplexer network could take the form of a

unit connected via an intermediate node, where the carrier status of the overall link is unknown. In such a

case the call is placed by the local PBX, which sees the local port is free and raises the M-lead. The local

unit tries to connect to the remote port but the connection fails because a link along the way is down. To

the calling PBX, the call status is unknown because there is no feedback and the user hears nothing.

To avoid this frustrating phenomenon, the “M-lead & Back Busy” selection was designed. Here, the local

port issues pings every 30 seconds from mapped Tie-Line ports (provided the system Tie-Line Activation

mode is set to "M-Lead & Back Busy" and the Tie-Line port has an algorithm selected). The remote port

responds to this ping if it is free. The local port checks for Ping Response timeouts (45 seconds) and

asserts a Back Busy request. If the port is in the idle state the Back Busy state is immediately translated

into the E-Lead signal. So, the state of Back Busy is translated to the E-Lead signal, unless the port is

turned off in which case the E-Lead signal is affirmed (busy).

This provides the following features on mapped Tie-Line Voice channels:-

• Back Busy will be asserted between 15 and 45 seconds after loss of communication



• Back Busy will be disaffirmed between 0 and 30 seconds after communication is restored.

• A manual Back Busy facility is activated by turning the coder algorithm off.

ASYNC BUFFER SIZE

The “ASYNC BUFFER SIZE” field allows the user to optimise the number of 100mS input buffers used by

asynchronous channels. This can be useful when channels are used for remote internet access which is

made at a negotiated rate and cannot be controlled.

JITTER TOLERANCE

The size of jitter buffers used for voice channels and constant bit-rate (CBR) data tributaries can be

independently configured via TTY commands (contact your Vocality support representative for details). It

is also possible to increase the size of all jitter buffers in the system via this parameter in the SYSTEM

menu. If all tributaries are using aggregate links with a significant jitter (> 10ms), the JITTER

TOLERANCE parameter should be set to represent the network jitter. This will automatically increase the

jitter buffer size implemented for all voice and CBR data tributaries, at the expense of throughput delay.

PASSWORDS

The RW and RO passwords allow the user to enter personal codes to restrict supervisor access to Read-

Write or Read-Only. In both cases, the code must be followed by a carriage return and then entered a

second time for confirmation. The new password is saved when the screen is exited in the normal way.

Once a password is entered, the user is prompted to enter it when first logging on to the system before

any access is granted to the menus. Refer to Section 2.3.5 for details.

ACCESS TIMEOUT

As an additional security feature, if either an RW or an RO password has been set, the “ACCESS

TIMEOUT” parameter allows the user to specify a period of keyboard inactivity after which menu access is

denied. When this happens, the user is logged off and the following message is displayed:

“Password Access Expired....”

“Re-Enter Password for Node0:”

This feature can be turned off by entering a value of zero seconds.

ACTVITY TIMEOUT

The “ACTIVITY TIMEOUT” is relevant to dial-up links only. When configured, it sets the aggregate dial-up

link’s activity timeout period. After the specified period of inactivity the dial-up link is dropped.

This feature can be turned off by entering a value of PERMANENT.



BACKUP TIMER

This timer allows the user to control how long it takes following the detection of an aggregate failure for

the route to use the backup path. This timer defaults to 40 seconds.

FALLBACK TIMER

This timer allows the user to control how long it takes following the detection of an aggregate recovery for

the route to use the fall back to the original path. This timer defaults to 40 seconds.

POE PSU RATING

NOTE: Power over Ethernet is not supported by the V25

This field allows the user to configure the rating of the external power supply used with the VI68054/PoE

Power over Ethernet (PoE) option module, when fitted. Power supplies differ in rating so please refer to

the specification of the power supply you are using to determine the value you should enter here. This

value is used by the POWER OVER ETHERNET menu in the DIAGNOSTICS menu to calculate how much

power is available for additional devices.

The parameters and options available on the SYSTEM menu are shown in the following table:

Field Options Description V200 and V150 only REAL TIME CLOCK

hh:mm:ss dd/mm/yyyy or hh:mm:ss mm/dd/yyyy when in US mode

Displays the current time and date for the multiplexer, and allows a new time and date to be entered

NODE NAME Any Alphanumeric string up to 8 characters

Allows the user to enter a convenient network name for the chassis. Also used as identifier in Teletype Mode

NODE ID 0-999 numeric 240-255 excluded

Network I.D. for this chassis. MUST be unique

Enabled, Configuration settings may be changed by another unit in the network

CONFIGURATION BY REMOTE

Inhibited Configuration settings may only be changed at the local unit

On, Unit will operate the MLPP protocol but not communicate with older software versions

MLPP COMPATIBILITY

Off Unit will not operate the MLPP protocol but will be able to communicate with older versions

UK, BT standard ringing cadence US, AT&T standard ringing cadence France, France Telecom standard ringing

cadence

COUNTRY

Germany Deutsche Telecom ringing cadence



Field Options Description Australia Telstra ringing cadence

Vocality Use the Vocality proprietary tones PROGRESS TONES

COUNTRY Use the standard tones for the configured COUNTRY (above)

CONNECTION TIMEOUT 10-255 numeric entry Number of seconds after which a connection request is rejected

RECEIVE READY FILTER 0-255 numeric entry Number of seconds from assertion of RR after which signal is accepted

Auto, Connection is made when one end is mapped

DATA CHANNEL ACTIVATION

Flag Connection only is made when one end is mapped AND ‘C’ lead affirmed at both ends

Always On, Channel output signal always asserted

Follows Connect, Channel output signal asserted when connection is established

Follows Remote, Channel output signal follows remote input signal transparently

DATA CHANNEL FLAG

Follows Alarms Channel output signal disaffirmed during alarm conditions

M-Lead Connections are only made when the M-Lead is seized

M-Lead & Back-Busy Same as above but pings are used to check the link status. See the section TIE LINE ACTIVATION above for details

TIE LINE ACTIVATION

Auto Permanent connection is made which takes bandwidth all the time.

ASYNC BUFFER SIZE 8-256 numeric entry Number of 1K buffers used by data channels in async mode

JITTER TOLERANCE 0-1000ms Global addition to size of tributary jitter buffers

RW PASSWORD Alphanumeric entry Read-Write access password

RO PASSWORD Alphanumeric entry Read-Only access password

ACCESS TIMEOUT 0-86400 numeric Supervisor keyboard timeout period. if either an RW or an RO password has been set, 0 = Permanent access (default) 1-86400 = Seconds as entered

PERMANENT PERMANENT = Permanent supervisor access

ACTIVITY TIMEOUT

0-86400 numeric This sets the aggregate dial-up link’s activity timeout period. 0= immediate timeout 1-86400 = Seconds as entered

BACKUP TIMER 0-600 seconds Delay before switching to backup aggregate path

FALLBACK TIMER 0-300 seconds, NEVER, RESET

Delay before falling back to original aggregate path Do not fall back Restart the fallback timer

V150 and V50plus with PoE option only PoE PSU RATING

0-250 watts This sets the rating for the power supply used with the PoE option



The unit supports multiple configuration stores which allow up to seven different configurations to be

stored on the multiplexer. The selection of which configuration is being edited or used at any time is made

in the CONFIGURATIONS menu. There are also options for copying and deleting configurations.

The screen for the V200 is shown below:

The screen for the V150, V50plus and V25 multiplexers is shown below:

2.4.3 The CONFIGURATIONS menu



CONFIGURATION MODE

CONFIGURATION MODE determines whether the remote multiplexer uses the Push-Config functionality

to enable the unit to be remotely configured or whether the configuration mode is set to Normal to allow

the unit to be configured locally.

ACTIVE CONFIGURATION#

The ACTIVE configuration is the one currently being used by the multiplexer. The “CONFIGURATION#”

identifies the configuration number. Seven configurations may be stored (1-7).

NOTE The ACTIVE configuration and the EDIT configuration can be the same. When this

happens, all configuration changes take effect immediately the <ESC>, <y> key sequence is

used to save the configuration.

EDIT CONFIGURATION#

The EDIT configuration is the one that will change as a result of any parameter changes on the menus.

For example, if parameters on the Clocking Menu are changed, those changes are saved in the

configuration identified here. The “CONFIGURATION#” identifies the configuration number. Seven

configurations may be stored (1-7).

NOTE The ACTIVE configuration and the EDIT configuration can be the same. When this

happens, all configuration changes take effect immediately the ESC key is used to save the



configuration. When the ACTIVE configuration and the EDIT configuration are different,

changes made to parameters are stored in the specified configuration number but the effects

of those changes are not seen until the edited configuration is made the ACTIVE configuration.

COPY CONFIGURATION#

A configuration can be copied to another configuration. This is useful when you want to make some

network configurations but want to have the option of reloading a known ‘good’ configuration should the

changes prove unsuccessful. The COPY configuration specifies the number of the configuration you want

to make a copy of. The “CONFIGURATION#” identifies the configuration number. Seven configurations

may be stored (1-7).

TO CONFIGURATION#

The TO configuration specifies the configuration that is overwritten with the COPY configuration (see

above). The “CONFIGURATION#” identifies the configuration number. Seven configurations may be stored

(1-7).

FACTORY DEFAULT CONFIG#

The FACTORY DEFAULT configuration specifies the configuration to be overwritten with the factory default

settings. The “CONFIGURATION#” identifies the configuration number. Seven configurations may be

stored (1-7).

NOTE: If the ACTIVE configuration and the FACTORY DEFAULT configuration are the same,

network connectivity may be lost until a valid configuration is entered.

CONFIGURATION#

The “CONFIGURATION#” identifies the configuration number. Seven configurations may be stored (1-7).

SIZE

The configuration size is shown in bytes.

DESCRIPTION

A description may be given to a configuration number to help identify it.



Field Options Description Push Config On connection with the network, the multiplexer is given

a configuration by the hub unit. CONFIGURATION MODE

Normal The multiplexer may be configured locally using the menus described in this manual.

ACTIVE CONFIGURATION#

1-7 The number of the Configuration currently being used.

EDIT CONFIGURATION#

1-7 The number under which to save the Configuration currently being edited.

Note: if the ACTIVE CONFIGURATION# is different from the

EDIT CONFIGURATION#, the changes being made to the

configuration will have no effect until the ACTIVE

CONFIGURATION# is set to the EDIT CONFIGURATION#

1-7 The number of the Configuration currently being copied. COPY CONFIGURATION# None No Configuration is currently being copied.

1-7 The number the Copied Configuration will be saved under.

TO CONFIGURATION#

None No copy will take place.

1-7 Set the Configuration specified back to the factory default settings.

DEFAULT CONFIGURATION#

None No Configuration is currently being set to the factory default settings.

CONFIGURATION# Information only The configuration (1-7).

SIZE Information only The size in bytes of the configuration file.

DESCRIPTION Alphanumeric text

Up to 55 characters used to identify the configuration.



The clocking menu specifies how the GRX and GTX clocks in the Multiplexers are driven. These are

reference clocks that allow data and voice ports in different multiplexers to be driven from a common

clock to prevent clock slip problems. Two configurations are given; the Primary for the preferred clock

configuration to be used and the Backup for the clock configuration to be used in the event of primary

clock failure. If no backup is specified, the primary clock configurations are used at all times.

SOURCE TYPE

Configures the source for driving the GRX and GTX system clocks.

NOTE: V25 does not support GTX.

NOTE: When a digital voice card is present, this can also be set to “E1/T1/J1”.

SOURCE CLOCK

When the SOURCE TYPE is configured to DATA, SOURCE CLOCK specifies which data interface clock is

driving GRX or GTX. When SOURCE TYPE is configured to IP AGG, SOURCE CLOCK specifies the name of

IP Aggregate driving GRX or GTX. The names of the IP aggregates configured in the IP AGGREGATES

menu are given in list format and are selected using the SPACE bar or the + and – keys. For all other

values of SOURCE TYPE, the SOURCE CLOCK field is not used.

2.4.4 The CLOCKING menu



NOTE: When a digital voice card is present and SOURCE TYPE is set to “E1/T1/J1”, SOURCE

CLOCK is set to “slot:x”

The parameters and options are shown in the following table:

Field Options Description

Internal GRX system clock is driven from a clock within the system.

Data GRX is driven from a clock on a serial data port. When this is selected, the SOURCE CLOCK is selected from a list of installed data ports.

IP AGG

GRX is driven from a clock reference received on an IP aggregate. When this is selected, the SOURCE CLOCK is selected from a list of configured IP Aggregates.

GRX SOURCE TYPE

E1/T1/J1 GRX is driven from the digital voice card.

None

Slot:Channel When Source is set to Data, the data slot: channel must be selected from a list of valid data ports.

Text When Source set to IP AGG, select the name from the list of configured IP Aggregates.

SOURCE CLOCK

Slot:x When GRX Source Type is set to E1/T1/J1, the SOURCE CLOCK is selected from a list of installed digital voice cards.

Internal GTX system clock is driven from a clock within the system.

Data GTX is driven from a clock on a serial data port. When this is selected, the SOURCE CLOCK is selected from a list of installed data ports.

IP AGG GTX is driven from a clock reference received on an IP aggregate. When this is selected, the SOURCE CLOCK is selected from a list of configured IP Aggregates.

GTX SOURCE TYPE

E1/T1/J1 GTX is driven from the digital voice card.

None

Slot:Channel When Source is set to Data, the data slot: channel must be selected from a list of valid data ports.

Text When Source set to IP AGG, select the name from the list of configured IP Aggregates.

SOURCE CLOCK

Slot:x When GTX Source Type is set to E1/T1/J1, the SOURCE CLOCK is selected from a list of installed digital voice cards.

The clock source failure and recovery conditions are summarized below:

Type Failure Recovery Data Calibration reports a missing clock Calibration reports a non-zero clock

rate IP No clock sync packets received

from far end Clock sync packet received from far end

E1/T1/J1 Framer reports “Loss of line interface transmit clock”

Framer clears previous “Loss of line interface transmit clock”

Internal None N/A



An additional failure and recovery mechanism is available for data and IP aggregate ports. This additional

mechanism provides an interaction between route backup and clock synchronization. A switch to the

secondary clock source will occur if all the following conditions are true:

• A secondary route is configured (see Route Back-up section for more details) • The primary reference clock source is the serial data port or IP aggregate used in the primary

route • The primary route is considered to have “failed” and the router switches to using the secondary

route.

In this case the secondary clock reference source will continue to be used until the router switches back to

using the primary route. The conditions under which this happens are described later (in the route back-

up section).

Note that there is no requirement for the backup clock source to be related to the backup route

aggregate.

2.4.4.1 Clocking and Push Config

A secondary reference clock source configuration is included in the client configuration as part of the push-

config scheme. The push-config client controls the selection of the secondary clock under the normal

failure and recovery rules.



The routing menu describes the mechanisms the multiplexer uses to direct traffic across a network. The

principle of the routing table is to configure which aggregate is used to reach a particular destination. The

destination is typically a target node number, but can also be a target slot or channel number if traffic to

different channels within slot, or slots within a node are to traverse the Vocality network along different

paths.

The following example shows a V200 routing setup with a leased satellite service, IP aggregate

interconnecting three V200 units. The units are labelled Node1, Node2 and Node3. A leased satellite

service connects Node1 (port 0:1) to Node2 (port 0:1). An IP aggregate connects Node2 to Node3. On

Node2 this IP aggregate is configured with the name “Node3”. On Node3 this IP aggregate is configured

with the name “Node2”. For full connectivity between all V200s in the network, each node must contain a

route to each other node in the network.

Node1 routes all traffic via the leased satellite service on port 0:1.

2.4.5 The ROUTING menu



Node2 uses the IP aggregate to Node3 to communicate with Node3. Traffic to Node1 is routed via port

0:1:



Node3 uses the IP aggregate to Node2 to reach Node1 and Node2:

It is necessary to enter the routes to all nodes since any chassis only has knowledge of its immediate

neighbours; the address in the data packets contains the full destination port address so by consulting the

routing table, every node can determine the next route to the destination even if it is to an intermediate

node, no matter how many nodes there are in the network.

The Vocality architecture allows a maximum of 999 chassis to be interconnected in a single network and

individual routing information must be entered into each chassis when the network is commissioned. Once

all the data has been entered, the entire network may be managed from any node – the remote

supervisor function depends on the routing tables as well!

Three options are presented on the ROUTING page, each of which may be accessed using the

conventional cursor keys and selected using the <space> bar. The typical entry sequence is as follows:

STEP 1 Select <DELETE ALL ROUTES> to clear all entries and start afresh.

STEP 2 Select <NEW ROUTE> to create a new entry line in the table. This may

then be accessed using the cursor keys to enter data. Repeat this step until all routes has been entered.

STEP 3 Select <TIDY LIST> to regroup the entries in a logical order. All routes

from each node are arranged in ascending order, with any specific channel routes from each node at the

end of each group.



NOTE: It is not necessary to use the ROUTING menu for simple point-to-point networks. The

complex example above requires the user to specify particular routes other than those that the

multiplexer will automatically work out. The multiplexer uses a technique called implicit routing to

automatically establish the most direct aggregate route to adjacent nodes. Any configured routes are

overlaid on top of the implicit routes; any duplicate implicit routes are replaced. In this way, by starting

with implicit routes, the entries required to set up even a complex network are minimised and the routing

tables are kept as simple as possible. Implicit routing is not available over IP aggregates or switched

aggregate links.

The parameters and options for the ROUTING menu are shown in the following table:

Field Options Description NAME Text Field Provides an identifying name for the route

0-999 numeric Identity of node to which traffic will be routed (240-255 reserved)

ANY Any of the available nodes.

NODE

BRD Traffic to be broadcast to many remotes is routed to the port specified by the AGG field (see below). This is used for the broadcast voice feature. The broadcast traffic may be routed to any number of aggregate ports this way.

0-99 Identifies the slot within the specified node which traffic will be routed to.

SLT

ANY Any of the available slots on the target NODE.

0-999 Identifies the channel within the specified SLOT on the specified NODE which traffic will be routed to. If specified then the SLOT must contain a specific slot number.

CHAN

ANY Any of the available channels on the target SLOT on the target NODE.

Dev: Chan Identify the aggregate to use to route traffic to the target NODE:SLOT:CHAN

- No aggregate configured

IP Route using an IP aggregate. The CONNECT USING field specifies the name of the IP aggregate to use.

AGG

Dev: ST(1-4) Identify ISDN BRI S/T interface to use to route traffic to the target NODE:SLOT:CHAN

CONNECT USING Text Only used for routes using IP aggregates. For an IP aggregate route this is the name of the IP aggregate to use – this must match the name of a configured IP aggregate.

ALTERNATE Text For future use. SEC Text For future use.

Note that more specific routes (i.e. those with specific channel and slot targets) always take precedence

over least specific routes.



2.4.5.2 Secondary Routing

The route backup feature allows the multiplexer router to route traffic down an alternate aggregate if the

path that is normally used “fails”. Once the original path “recovers”, traffic is routed back along the

primary path. The following rules apply to this route back-up feature:

- Primary aggregate is non-switched point to point data aggregate or IP aggregate

- Secondary aggregate may be any aggregate type (including switched data & IP)

- An aggregate used as a secondary route may be the primary or secondary path for other routes

Providing route back-up for shared outbound links is another possible future enhancement. The problem

here is again down to detecting when the outbound path has failed.

The “failures” that cause the back-up to the secondary route and the “recoveries” that initiate the fallback

to the primary route depend on the type of aggregates used. They are detailed in the Failure & Recovery

sub-section below.

Tributaries that are established via a route when a back-up or fallback switch occurs for that route are

automatically disconnected. These tributaries will re-connect if the connection attempt is retried once the

route switch has occurred. Tributaries that are already established on an aggregate (via a route) remain

connected when another route switches to use that aggregate. Note that in this case, the additional

bandwidth load of the tributaries that have been switched may alter the performance of the already

established connections.

Once a secondary route is in use, the fallback to the primary path will only occur if the primary path

recovers. If the secondary path fails the route remains via the secondary path.

The second row in each route table entry is used to allow the user to specify the aggregate to use for the

backup link. A SEC mode of BACKUP is the normal mode used. BoD is to be used when an ISDN data

aggregate is used for the backup facility.

The SYSTEM menu includes the BACKUP and FALLBACK TIMERS which allow the user to control how long

it takes following the detection of an aggregate failure or recovery for the route to use the backup path or

fallback to the primary path. These timers both default to 40 seconds.

Primary and backup aggregates may be used on different slots. Note however that the primary and

secondary aggregates must be on the same node.

2.4.5.1.1 Overview

2.4.5.2.1 Configuration



Failure and recovery conditions on the primary link control how and when the secondary route is used.

The failure and recovery conditions used depend on the primary aggregate in use. Routes are removed

and re-installed with the appropriate aggregate connection and backup and fallback occur.

The mechanism to detect link failure on the data aggregate must be able to identify a half-duplex failure.

The existing frame sync protocol determines when an inbound link has failed. The secondary routing v1

operation halts the outbound frame sync protocol when the inbound mechanism fails – however this

requires frequent fallback attempts in order to allow the primary to recover – this can lead to the

aggregate “bouncing” when the path fails in one direction.

To overcome this, the frame sync protocol conveys the health of the return links on point-to-point serial

aggregates. For this to work successfully, units at both ends of a link must be running the same software

for the link failure detection to work. However, the aggregate link itself will work between a unit running

the enhanced frame sync protocol and one running the older version.

The backup is initiated if either the inbound or outbound path is determined to have failed. Inbound

failure detection is based on not receiving Frame Sync protocol packets for the AGGTO (configurable via

TTY mode) period. Outbound failure detection based on the peer not receiving Frame Sync protocol

packets for its AGGTO period. The frame sync protocol continues to run on the failed link to allow the

recovery to be detected.

The link recovery is simply the successful reception of the frame sync protocol that indicates a good bi-

directional data path.

IP aggregate failure is identified when the clock management protocol fails between IP aggregate peers.

A recovery condition is considered to be when we start to receive these clock management protocol

packets again. Note that there is no half-duplex detection available here.

An entry in the configuration trace log is generated for each switchover or fallback. An alarm is already

generated on aggregate failure.

2.4.5.3 Push Config

Secondary routing is not available in a push config scheme. The routing table is not directly distributed to

the push-config client. “Normal” configuration mode must be selected on the remote nodes, and

secondary routes installed through the router menu.

2.4.5.2.2 Failure & Recovery

2.4.5.2.2.1 Data Aggregates

2.4.5.2.2.2 IP Aggregates

2.4.5.2.3 Status, Logs & Alarms



SIP gateway is enabled via a feature key. Feature keys may be purchased for various numbers of SIP

User Agents (UAs). If there are no SIP UAs on this product (i.e. no SIP UA feature key has been entered),

this menu is empty.

2.4.6 The SIP GATEWAY menu



The System sub-menu provides control of parameters that apply to the entire SIP gateway (i.e. they are

not UA-specific):

MODE

Specifies whether the gateway is enabled or not. It takes the values Gateway or Disabled

FULLY QUALIFIED DOMAIN NAME

Allows the user to specify a name the SIP gateway uses for identifying its UAs. If not specified, the

gateway uses the IP address configured on the first Ethernet port.

SIP TRANSPORT

A read-only field that indicates SIP is run over UDP.

THE RE-REGISTRATION INTERVAL

Specifies the frequency at which a UA will re-register with its configured registration proxy. Note that the

actual period used may be over-ridden by the SIP registration proxy itself.

2.4.6.1 The SYSTEM menu



PROTOCOL LOGGING

Protocol logging is provided to enable the generation of verbose trace logs to help debug call set up

issues. Each SIP packet received or transmitted is collected in the SIP trace log when this is enabled. It is

intended that this only be enabled by field engineers when debugging problems, as there is considerable

processing overhead to leaving it permanently enabled.

The UA configuration is accessed via two separate menu screens. The channel summary screen shows a

line for each UA present. It shows the user-id (Name), and configured destination for each channel

present.

Select the <VIEW> button of the appropriate entry to see the Channel Details.

A description of the fields used here can be found in the Channel Details menu description.

2.4.6.2 The CHANNEL SUMMARY menu



The channel details menu screen contains a page for each SIP UA channel present.

The example screen below shows the Channel To Edit is set to “COMMON”. This setting allows common

values to be configured for all UAs in the SIP gateway. It is used to set the IP TOS, Outbound Proxy,

Registration Proxy, Auth Login ID, Alt Auth ID, Auth Password and Algorithm. If one of these values is

changed for an individual channel then that channel will no longer pick up a change to the common value.

An individual channel can revert to the common channel settings by pressing Ctrl-D when editing that

channel in the details page.

When the Channel To Edit is set to a specific channel, all items on the screen may be set.

CHANNEL TO EDIT

Shows which channel we are currently displaying/editing. Changing this selection automatically changes

the page display to the selected UA.

USER-ID (AOR)

Allows the configuration of the user ID to use for setting the AOR (Address Of Record)) for this UA.

2.4.6.3 The CHANNEL DETAILS menu



DESTINATION

Specifies the peer location in the Vocality network to map calls received on this UA to. The default setting

is AUTO, which indicates that received calls are to be processed through the directory table and auto-

mapping procedure.

SIP PEER URI

Allows the user to configure a fixed entity in the SIP network to forward all outgoing call on this SIP UA to.

It effectively provides a long-line extension feature into the SIP network.

IP TOS

Specifies the IP TOS field (in hex) to use for voice packets generated into the SIP network from this UA.

OUTBOUND PROXY

The location (DNS name) or address of the SIP proxy server all calls made out of the SIP UA are

forwarded through if the SIP PEER DEST or SIP DIRECTORY TABLE is not used.

REGISTRATION PROXY

The location (DNS name) or address of the SIP registration server this UA should attempt to register with.

If left blank no registration occurs.

AUTH LOGIN ID

Takes the values UserID or AltAuthID. It specifies whether the UA should use the configured UserID or

separate Alt Auth ID when attempting to authenticate this UA.

ALT AUTH ID

The alternative authentication ID to use when the Auth Login ID is set to AltAuthID.

AUTH PASSWORD

Password used during authentication of this SIP UA. This should be left blank if no authentication is

required.

ALGORITHM

Specifies the voice coder type to use for calls through this SIP UA. Supported values are G.729A 8K,

G.711A 64K and G.711u 64K.



In addition, a page is shown for the common channel configuration.



The SIP directory is used to map SIP destination addresses into the Vocality network numbering scheme.

It is typically used for simple SIP outbound call routing when no outbound proxy is available:

Each line in the table represents a single SIP destination. The destination field is the complete URI for

routing the call to. The Directory Number specifies the called number that must match to route the call to

this SIP destination.

2.4.6.4 The SIP DIRECTORY menu



The feature keys menu allows the entry of encrypted keys which enable enhanced features in the

multiplexer. Two types of keys are supported – permanent keys are purchased to permanently enable the

features. Temporary keys are available to trial test a feature. They are active for up to 24 hours or until

the multiplexer is restarted. Please contact Vocality International to obtain the appropriate keys for your

units.

Select the feature you want to enable and then enter the key provided by Vocality in the appropriate field.

Press <Enter> to accept the key.

The permanent keys are based on the serial number on the backplane of the multiplexer. Therefore the

keys remain valid even when cards are swapped out or system control changes from the active to backup

card.

NOTE: The TCP Gateway (PEP) feature key and the SIMPLE NETWORK MANAGEMENT

PROTOCOL (SNMP) feature key are built-in (automatically supported) on the V200 only. For all

other products, these features keys must be purchased.

Once a feature key has been purchased and correctly entered, the State changes from LOCKED to

UNLOCKED.

NOTE: For the SIP Gateway UA Count feature, both the correct UA Count and the corresponding

Key must be entered before the feature is UNLOCKED (useable).

2.4.7 The FEATURE KEYS menu



The call routing menu provides access to sub-menus that provide configuration for the call routing

services in the multiplexer.

2.4.8 The CALL ROUTING menu



Hunt groups allow voice calls to be routed to an available port within a configured group of ports. The hunt

group feature makes it possible to route a call to an available port within a hunt group and allow the

generation of an outgoing DTMF digit stream on the available port if required. This provides for hot-line

extension into a PBX or PSTN.

A hunt group can be configured to ring the first available phone (FirstAvailable), or all available phones

(RingAll), or it can be configured to call the first available phone but if all phones are busy, a call back will

be made to the caller as soon as a phone is available (RingBack).

Once a hunt group is defined, it can be used as a destination for a voice call - either through directory

routing, AUTO DTMF routing, or hot-line configuration. The address of a hunt group is node:HG:[1-n]. See

the appropriate menu in this chapter for more information.

HG TO EDIT/VIEW

This is the primary selection field which allows any of the currently configured Hunt Groups to be

displayed. The format for Hunt Group names is “HG:1”, “HG:2”, …and so on.

2.4.8.1 The HUNT GROUPS menu



OUT DIAL STRING

This is blank by default and can be configured with up to 25 digits. Supported digits are ‘0 1 2 3 4 5 6 7 8

9 # $ ,’. The string is dialled on FXO or digital voice hunt group members when attempting to connect

through the hunt group. A comma adds a 1 second delay in the dial string. For example, the dial string ‘9,

1234’ dials the digit 9, pauses for 1 second, then dials 1234.

OPERATION MODE

There are three operating modes: first available, ring all, and ring back. First available is the default and in

this mode, the call is connected to the first detected available port.

Ring all mode is used with FXS ports only. In this mode phones connected to all the FXS ports that are

members of the hunt group are rung together. When a phone is picked up, the call is connected and all

the other phones stop ringing.

The ring back mode can only be used with originating ports configured as FXS although the hunt group

member ports may be either FXS or FXO. In this mode, if the call cannot be completed because all ports

are busy, as soon as a port is available, a callback is made to the originating port causing it to ring and a

connection is made upon answer.

MEMBER LIST

A hunt group can have voice port members from the multiplexer the hunt group is configured on, or from

other systems in the network. These members may be FXS ports, FXO ports, or digital voice channels.

Typically, however, they will be located in the local chassis. The location of each member port of a hunt

group is configured in the member list in the form node:port:channel.

SOFT KEYS

Four soft keys manage the addition or deletion of members within a Hunt Group and the addition or

deletion of Hunt Groups completely. <ADD MEMBER> is used to include a new element within the

currently selected Hunt Group; <DELETE MEMBERS> empties a Hunt Group of all its members; <ADD

NEW GROUP> appends the next sequential Hunt Group number to the end of the list; <DELETE GROUP>

removes the currently selected Hunt Group from the list. These keys are activated by positioning the

cursor and typing the space bar.

Field Options Description HG TO EDIT/VIEW HG:1, HG:2…HG:n Selects a configured Hunt Group

OUT DIAL STRING Up to 25 digits: 0 1 2 3 4 5 6 7 8 9 # $ ,

DTMF digit string dialled on FXO hunt group members when attempting connection through a hunt group. 0 1 2 3 4 5 6 7 8 9 # $ are valid DTMF digits. A comma adds a 1 second delay in the dial string.



FirstAvailable Default. In this mode, the call is connected to the first detected available port.

RingAll Used with FXS ports only. In this mode available (non-busy) phones connected to all the FXS ports members of the hunt group are rung together. When a phone is picked up, all the other phones stop ringing.

OPERATION MODE

RingBack Used only with originating ports configured as FXS although the hunt group member ports may be either FXS or FXO. In this mode, if the call cannot be completed because all ports are busy, as soon as a port is available, a callback is made to the originating port causing it to ring and a connection is made upon answer.

node:port:channel Identifies the full port number of the ports belonging to the shown hunt group. Up to 32 entries can be added to each hunt group.

MEMBER LIST

node:port:1st channel - last channel

Identifies a range of ports belonging to the shown hunt group. For example, 1:1:1-4 defines the range of ports 1:1:1, 1:1:2, 1:1:3 and 1:1:4 and is a way of using a single entry to add multiple port members to the shown hunt group. Up to 32 entries can be added to each hunt group.

Calls received on digital voice channels, FXS ports or FXO ports configured with an AUTO destination or

SIP UAs configured with an AUTO destination use automapping and/or the directory table to route the call

across the Vocality network.

2.4.8.2 The AUTO MAPPING menu



Automapping is used to specify the number of digits used to represent nodes, slots and channels in the

auto DTMF mapping scheme. These all default to one digit (one digit for node, one digit for slot, one digit

for channel) to provide backward compatibility with the pre-3.0 release scheme. This menu also allows

you to configure a slot number to represent hunt groups and the SIP gateway in the automapping scheme

(see Section 2.4.8.1 for more information on hunt groups).

AUTOMAP MODE

This is used to enable and disable the automapping feature.

DIGIT COUNTS

These counts allow the user to define how dialled digits are mapped to the node, slot and channel

components of destinations in the multiplexer network.

SLOT # FOR HUNT GROUPS

If the automapping feature is required to route calls to hunt groups, a number must be used to represent

a hunt group (as the usual designator, HG, cannot be dialled on a phone).This is done by configuring a

slot number to be used to represent a hunt group. The slot number for hunt groups defaults to an

unconfigured value (indicated by -). If the dialled slot number is configured to any other value (valid

range 0-999) then the hunt group mapping will be the standard slot mapping. For example, if the digit

count for the node is set to 1, the digit count for the slot is set to 1, and the digit count for the channel is



set to 1, and the hunt group slot number is configured as 1, then a call to 511 will be routed to hunt group

1 on node 5, and not voice channel 1 on slot 1 on node 5.

NOTE: It is advisable to use an unused slot for the slot number for hunt groups so that calls are

not mistakenly routed to a hunt group instead of a voice port.

SLOT # FOR SIP GATEWAYS

If the automapping feature is required to route calls to SIP gateways, a number must be used to

represent a SIP gateway (as the usual designator, SG, cannot be dialled on a phone).This is done by

configuring a slot number to be used to represent a SIP gateway. The slot number for SIP gateways

defaults to an unconfigured value (indicated by -). If the dialled slot number is configured to any other

value (valid range 0-999) then the SIP gateway mapping will be the standard slot mapping. For example,

if the digit count for the node is set to 1, the digit count for the slot is set to 1, and the digit count for the

channel is set to 1, and the SIP gateway slot number is configured as 1, then a call to 611 will be routed

to SIP gateway 1 on node 6, and not voice channel 1 on slot 1 on node 6.

NOTE: It is advisable to use an unused slot for the slot number for SIP gateways so that calls

are not mistakenly routed to a SIP gateway instead of a voice port.


Field Options Description



Enabled Enables the automapping mode. AUTOMAP MODE

Disabled Disables the automapping mode. Calls are routed via the directory menu only.

DIGIT COUNT FOR NODE

1-3 Determines the number of digits assumed to be the node number. For example if the number 98765 is called, and the digit count for node is 1, then ‘9’ is assumed to be the Node number. If the count is set to 2 then ‘98’ is assumed to be the node number. If set to 3 then ‘987’ is assumed to be the node number.

DIGIT COUNT FOR SLOT

1,2 Determines the number of digits assumed to be the slot number.

DIGIT COUNT FOR CHANNEL

1-4 Determines the number of digits assumed to be the channel number.

1-999 The slot number used to represent a hunt group. SLOT # FOR HUNT GROUPS - Unconfigured. Calls are not automatically mapped

to a hunt group unless the dialled slot is set to 253 – see the section SLOT # FOR HUNT GROUPS above for more information.

1-999 The slot number used to represent a SIP gateway. SLOT # FOR SIP GATEWAYS - Unconfigured. Calls are not automatically mapped

to a SIP gateway unless the dialled slot is set to 253 – see the section SLOT # FOR SIP GATEWAYS above for more information.

Any of the voice channels in the network may be assigned a dialling code such that

dialling digit sequences map on to physical destination ports. This page lists all ports

in the network and allows the user to enter DTMF destination numbers that the

network will use to set up calls, without having to use the multiplexer hardware port

numbering scheme. The DIRECTORY page for voice ports in a network could look like

this:

2.4.8.3 The DIRECTORY menu



This facility may be used to integrate ports connected over a multiplexer network into an existing dialling

plan or corporate extension list. The direct hardware numbering scheme may still be used at the same

time i.e. in the example above both “114” and “823” would dial port 1:1:4 as long as the number 114 has

not also been used as a directory code. See section 2.4.8.2, “The AUTO MAPPING menu” for more

information on automapping. However this consumes the dialed digits and only additional digits are

passed onto the destination. e.g If as above a directory entry for a primary rate card existed:

0:1:X 123

And a call were made with the Called Party Number (CPN) of 123456, the digits 123 would be consumed

by the node and only the digits 456 would be passed onto the destination in the outgoing SETUP

message. In many applications, the Vocality products are used to transparently extend the primary rate

link between two PBXs and therefore calls need to be routed without consuming routing digits.

Additionally there is a requirement to be able to substitute routing digits with a different digit string. To

satisfy both of these requirements an additional “Prefix” field is available in the directory entries. This

entry, if present, will insert the given digits at the start of the remaining digit stream before forwarding

the call onto the destination. This can be used either to re-insert consumed routing digits or to substitute

consumed routing digits with a different digit string.

In the example above, an incoming call with the CPN 123456 will cause the consumed routing digits 123

to be re-inserted and the SETUP message sent to the destination 0:1:X will contain the CPN 123456.



An incoming call with a CPN 124456 will cause the routing digits 124 will be consumed and the prefix

string 789 will be inserted so the outgoing SETUP message sent on to the destination, 0:2:X, will contain

the CPN 789456.

The existing functionality, where the digits are consumed, can be achieved by the fourth entry. A CPN of

125456 would consume 125 and insert no replacement digits and so the destination 1:1:X would send a

SETUP with a CPN of 456.

In addition an “ANY” directory number is now supported. A directory number of “ANY” will cause any CPN

which doesn’t match a specific entry to be routed over the “default” route, additional digits can be inserted

into the outgoing CPN. In the example above a CPN of 321 will route to destination 1:2:X and send a CPN

of 555321 in the outgoing setup menu. If the directory contains more than one “ANY” entry, the first one

encountered will be used and subsequent entries will be ignored.

The enhancements are also available for hunt groups and although the requirement in mainly for primary

rate circuits, the feature is also available to other supported destinations.

The Directory menu is a multi-page menu with buttons provided for moving between pages (if enough

entries are present for multiple pages). The parameters and options are shown in the following table:

Field Options Description Node:Slot:Channel Specifies the channel the call is mapped to.

Node:HG:Channel Specifies the Hunt Group the call is mapped to.

Node:SG:Channel Specifies the SIP UA the call is mapped to.

X Can be used to identify any channel on a digital voice card, or any channel on a SIP gateway.

CHANNEL

# Digit used with Hunt Groups to signify the HG should wait to collect further digits before sending out the dial string. The wait timeout is 4 seconds but can be expedited by actually entering a’#’ at the end of the digit string.

AGG No Aggregates are not supported in this release. For future use.

DIRECTORY NUMBER

1-25 digits, *, ANY

When the directory number is dialled, the call is mapped to the specified channel. The ‘*’ digit is supported Any CPN without a direct match in the Directory gets routed to the specified channel.

PREFIX 1-25 digits When the directory number is dialed the prefix is sent out by the Hunt Group

If the MLPP Compatibility option on the System menu is turned ON, the MLPP submenu is provided under

the “Call Routing” menu. Choosing this option causes the following new submenu to be displayed:

2.4.8.4 The MLPP menu



This menu has two entries:

MLPP ENTRIES – Choosing this causes the new MLPP Entries submenu to be launched. The MLPP

functionality for individual ports is provisioned in this menu.

Network Identity – Is a value sent in the ISDN signalling when an MLPP call attempt is made. It is

essentially the international dialing code for the network. The default value for this field is 001, the

international dialing code for the USA.



The MLPP functionality is provisioned on a per port basis. The functionality is provisioned via the MLPP

Entries submenu shown below. Only ports provisioned in this menu will participate in the MLPP

functionality. Only MLPP ports in the same domain will be considered for pre-emption in the case of

congestion.

The screen has the following softkeys defined: Add Entry, Delete All Entries, Next (not always present)

“Add Entry” creates a new entry in the table.

“Delete All Entries” Deletes all the entries in the table.

“Next” only appears if there are more MLPP entries than will fit on one page, it scrolls onto the next page

of entries.

CHANNEL

The CHANNEL field indicates the port to which the MLPP entry pertains, this field is in the format

<node>:<slot>:<channel>. The first two entries shown in the example are single analogue voice ports.

The third entry describes a primary rate interface, a primary rate interface is described by an entry in the

format <node>:<slot>:X , this is consistent with the dial plan notation used in the directory. Hunt group

2.4.8.4.1 The MLPP ENTRIES menu



entries such as 1:HG:2 are not valid in this screen, please see section on feature interaction for more

details.

PRECEDENCE

PRECEDENCE is the maximum priority this port may request, this is a numerical field in the range 0

(highest) to 4 (lowest). This menu only describes the maximum precedence level a call can request, in the

case of a PRI this is forced to 0 as the assumption is made that the connected equipment will verify

subscriber precedence. Making a precedence call request is done on a per call basis and is determined by

the digits dialled.

ACCESS

ACCESS determines whether the user access (the terminating equipment) can be pre-empted. If this is

set to “NO”, a call to this subscriber cannot be pre-empted because the users access is busy. The call still

may be pre-empted if congestion is encountered in the network. The default for this field is “YES”.

DOMAIN

DOMAIN is a six digit hexadecimal number identifying the MLPP domain. Only calls in the same MLPP

domain may pre-empt one another.

OPERATION

OPERATION defines the action the port should take when receiving an incoming precedence call while

connected to a pre-emptable call. The two options are “FRIENDLY” and “RUTHLESS”.

In Friendly mode, when the call is pre-empted, the called user hears the pre-emption tone through the

handset which persists until the handset is hung-up. The phone will then ring with the precedence

cadence and when the pre-empted user picks up, the pre-empting caller is connected.

In Ruthless mode, when a call is pre-empted, the called user hears a brief pre-emption tone through the

handset and will then be immediately connected to the pre-empting caller.



The Slots menu allows you to configure the voice, data, and IP features on slots associated with the

physical bays in the V200 and V150 multiplexers. This menu also provides access to the diagnostic tools

for each of the slots.

A menu item is presented for all slots present in the system and any slots that have been pre-provisioned

in the SLOT MANAGEMENT menu. In the example above, the V200 has two CPU cards installed and slot 5

has been pre-provisioned for a serial data card in the SLOT MANAGEMENT menu. Slot 5 can now be

configured as though it had a serial data card installed.

Select the slot you wish to configure:

2.4.9 The SLOTS menu



A menu for the selected slot is then shown. Above, the Slot 0 CPU card has been selected.



CHANNEL

The data channels resident on this slot are presented on this menu page. The slot number and channel

number distinguish the position of the channel within the chassis.

IFACE

The electrical interface standard used by each port must be selected according to the equipment to be

connected.

MODE

Data channels may operate in one of two basic modes, either as an aggregate port or as a tributary

channel. An aggregate port performs the function of multiplexing a number of tributary connections over a

carrier service to a remote unit. The multiplexer is capable of operating multiple aggregate ports.

Point-to-multi-point (PMP) aggregates are used to multiplex over shared outbound links. See Section 4.9

Multi-point to multi-point (MPMP) aggregates are used to multiplex over full mesh broadcast networks.

Mesh is used when it is known that all data received on an aggregate has already been received by all

other units in the network.

2.4.9.1 The DATA menu



TYPE

The port type field allows the user to select the correct circuit presentation for the data port. When DTE

type is selected, the port is configured as Data Terminating Equipment and may be logically connected

using a straight cable to modems, for example (which are normally DCE). In other words, the TXD signal

is an output from the multiplexer and should be connected to the TXD pin on the modem, which is an

input.

When DCE is selected, all of the signals reverse direction and the port is configured as Data Circuit

terminating Equipment and may be logically connected using a straight cable to terminals, for example.

The TXD signal is now an input to the multiplexer and should be connected to the TXD pin on the PC,

which is an output. The changeover is performed under software control and no jumper links need to be

changed internally.

NOTE: On the V25, 0:1 is DTE only while 0:2 is DCE only.

FORMAT

The format field is used to specify the kind of data to be transferred by the port. If synchronous, then

transparent (SYNC) or NRZ framed data may be selected, or if async then the specific word structure is

selected. The format must be the same at both ends of the multiplexer link.

In async modes an additional parameter is accessible immediately to the right of the main format entry

which consists of a single character. This allows the user to select from Raw, Error-corrected or

Compressed operation (Raw is selected by default). See Section 4.10 “Async Error-correction and

Compression” for details.

The format field is also used to select TDM operation on a per-port basis in conjunction with the Mode

being set to Agg. Refer to Section 4.14 “TDM Aggregates” for details.

CLOCK SETTINGS

The multiplexer offers independent RX and TX clocks on every port and each one has three settings

controlling rate, source and reference. The convention used is that the RX clock is associated with the

direction of data from the aggregate to the tributary, whereas the TX clock is associated with the flow of

data from the tributary to the aggregate. The clock source defines where the clock physically comes from.

The reference field defines if the unit generates the clock using one of the two internal busses as a

reference. When the clock is generated by the unit, the rate field must be specified. For external (“EXT”)

or looped clocks, it may be left blank.

Every data port can have two independent Phase-Locked Loops (PLLs) associated with it; one for the

receive clock and the other for the transmit. In combination with the two internal clock busses this allows

channels to be set up for asymmetric bit rates, or to onward link or phase lock to any Clock source in the

network. By default, standard clock speeds are available at predefined granularities (see the Specification



in the relevant Hardware Guide) but other non-standard rates are achievable by using special commands;

refer to Vocality for details.

Clock switching selections are available according to the following table:

RXC TXC 89 T (Input, from pin)

EXT (Input, from pin)

TXC (Output, looped from TXC) RXC (Output, looped from RXC)

DBA (Variable output, from PLL) DBA (Variable output, from PLL)

PLL (Output, locked to clock bus) PLL (Output, locked to clock bus)

TTP (TT input, ST output from PLL)

TTD (AS TTP but variable ST output)

In PLL, TTP, TTD, and DBA modes, where an output clock is being derived from a Phase-Locked Loop, the

PLL reference source must be selected from either the Global Receive Clock (GRX) bus or the Global

Transmit Clock (GTX) bus. The reference clock bus must first be attached to a source by configuring the

”Clocking” menu. The RX PLL reference for the tributary channel may then be derived from the GRX bus

by selecting “<GRX” (FROM GRX) on the Data Channels menu.

In DBA modes, the “Rate” entered is the maximum rate at which the channel will run, when there is no

demand for bandwidth from higher priority sources such as voice channels.

Refer to Section 4.8, for more details.

DESTINATION

Destinations are needed by tributary channels to specify to which port the data should be sent and the

format follows the rules “NODE:SLOT:CHANNEL”. The destination must be a channel of the same type,

i.e. a data channel destination must always be another data channel, but it can be anywhere in the

network, even for example, on the same card. This can be a useful aid in diagnostics.

Another useful technique is to specify a loopback in the destination field. By entering the word “LOOP” as

the destination, data to be sent out of a port is looped back internally to the receiver. By entering the

word “ECHO” as the destination, data coming into a port is internally looped to the transmitter. This is

applicable to aggregate ports and tributaries, but care should be exercised when using aggregate

loopbacks! DO NOT USE AGGREGATE LOOPBACKS UNLESS LOCAL M&C ACCESS IS AVAILABLE.



The multiplexer operates by sending packets from tributaries to their corresponding port using a route,

which is looked up based on the destination in the packet header. This is usually via a serial aggregate

port but could be via an IP aggregate. In any case, the route a packet takes out of the multiplexer may be

indirect, going via another unit to reach the final destination. Aggregate ports therefore use routing

information only and do not need a destination to be specified in the menu; the destination field

should be left blank. The only exceptions to this are SWITCHED or SCADA modes, which are specified

by entering the keyword in the destination field (see Section 4.11 for more information on Switched mode

and SCADA mode).

Tributary ports however are the end points of all connections and so, the port address of the final

destination must be specified by all tributaries. This is true of both point-to-point connections and

shared outbound connections, which are discussed more fully in the context of the voice menus in section

4.9.

The parameters and options for the DATA menu are shown in the following table:

Tributary in ECHO: Data transmitted back out of the port

Tributary in LOOP: Data transmitted back over the aggregate

Aggregate in LOOP: Data transmitted back out of all tributaries

Aggregate in ECHO: All data transmitted back over the aggregate



Field Options Description CHANNEL Information only Displays the numbers of all data channels

installed in the slot on a separate line.

INTERFACE RS449, V.11, RS232, V.35, RS422, V.36

Electrical interface standard used on the port.

Agg, Channel is used as a point to point aggregate

Trib, Channel is a tributary

PMP Channel is used as a point to multi-point aggregate

MPMP Channel is used as a multi-point to multi-point aggregate

MODE

Mesh Channel is connected to a meshed network.

DTE, Port is configured as Data Terminating Equipment (TX is an output)

TYPE

DCE Port is configured as Data Communications Equipment (TX is input)

Sync, Data is transparent synchronous

NRZ, Data is synchronous, HDLC Non-Return to Zero format

NRZI, Data is synchronous, HDLC Non-Return to Zero Inverted format

TDM, “Agg” mode must be selected; port will operate as a TDM aggregate

8N1, Data is async, 8bits, no parity, one stop

8N2, Data is async, 8bits, no parity, two stop

7E1, Data is async, 7bits, even parity, one stop

7E2, Data is async, 7bits, even parity, two stop

7O1, Data is async, 7bits, odd parity, one stop

7O2, Data is async, 7bits, odd parity, two stop


7N1.5, Data is async, 7bits, no parity, 1.5 stop Not on V200


FORMAT

5N1.5 Data is async, 5bits, no parity, 1.5 stop Not on V200

R, Raw data passed transparently

E, Error-correction active

FORMAT (ASYNC)

C Compression active (error-correction is automatic) Receive clock bit rate. This may be set at any rate from: (*see *PLL rates) 50 to 10240000bps (synchronous) High-speed CPU card only 50 to 5120000bps (synchronous) All systems except high-speed CPU card

RX CLOCK RATE 50-10240000bps

50 to 115200bps (asynchronous)

RX CLOCK SRC Ext, RX clock input from the interface



Field Options Description Txc, RX clock output, looped from TX

PLL, RX clock output, derived from PLL

Dba Dynamic Bandwidth Allocation (output)

- None

<GTX, The reference for the TX PLL is taken from the Global RX Clock bus

RX CLOCK REFERENCE

<GRX The reference for the RX PLL is taken from the Global RX Clock bus Transmit clock bit rate. This may be set at any rate from:(see *PLL rates) 50 to 10240000bps (synchronous) High-speed CPU card only 50 to 5120000bps (synchronous) All systems except high-speed CPU card

TX CLOCK RATE 50-10240000bps

50 to 115200bps (asynchronous)

Ext, TX clock input from the interface

Rxc, TX clock output, looped from RX

PLL, TX clock output, derived from PLL

Dba, Dynamic Bandwidth Allocation (output)

TTP, Terminal Timing with ST supplied to DTE

TX CLOCK SRC

TTD As TTP, with DBA facility on ST supplied to DTE

“NODE:SLOT:CHANNEL", Data will only be transmitted to the designated port

LOOP, Port TX data is internally looped to RX

ECHO, Port RX data is internally looped to TX

SWITCHED, Aggregate link requested by RTS flag

SCADA Aggregate link uses SCADA protocol BTXnnn, Broadcast TX channel number

BRXnnn, Broadcast RX channel number

DESTINATION

BTRttt,rrr" Broadcast TX and RX channel numbers

When the RX CLOCK SRC or TX CLOCK SRC is set to PLL, DBA, TTP or TTD the actual rate used is limited

to certain intervals. The intervals vary according to the frequency range the configured rate is in. When

configured to rates that do not match these intervals, the multiplexer uses the nearest rate available.

Min Max Interval 25Hz 9600Hz 25Hz 110 110 - 10400 51200 800Hz 520000 5120000 8000Hz 5128000 10240000 8000Hz High-speed CPU card

lTable 1 *PLL rates



This menu is displayed when an Analogue Voice Card is installed.The VOICE menu allows you to select

from a choice of items in a sub-menu.

2.4.9.2 The ANALOGUE VOICE menu



CHANNEL

All voice channels detected on power-up are presented on the same menu page. The slot number and

channel number distinguish the position of the channel within the chassis.

CLOCK REFERENCE

All voice ports may be configured completely independently of each other. The only restriction is that the

reference clock source is common to all the channels in an option slot, since the voice motherboard

(VI68701) contains one PLL. As with all other cards, the PCM sample clock generated on the voice card

must be phase-locked to either the GRX or the GTX clock busses.

SIGTYPE

Voice channel connections are made by dialling the remote destination. This may be done using tone-

based signalling, loop dialling or E&M pulses according to the application. The choice of signalling type

allows the user to specify how the channel is operated and also which of the modem or fax relays may be

used. “DTMF” signalling type decodes the tone pair digits and passes them to the remote end. “E&M”

passes all tones but decodes pulse dialling digits if present. The remaining options pass all tones but allow

the user to select which modem/fax relay function will operate. “TRANS” signalling passes all tones and

2.4.9.2.1 The ANALOGUE PORTS menu



loop pulses transparently and turns off all of the modem/fax relay functions. “V.22” permits only the V.22

modem relay to operate, and “STU” permits only the STU-IIB/STU-III relay to operate (if the card is

fitted).

INTERFACE

When the interface type is set to “FXS”, the port provides DC loop current or ring voltage for driving a

telephone or a trunk port on a PABX, while “FXO” configures the port to accept DC current or ring voltage;

both types are 2-wire interfaces. When set to “TIE-LINE”, the port is configured as a 4-wire E&M port and

should not be connected to network voltages.

ALGORITHM

The wide range of voice algorithms (codecs) allows a trade-off between voice quality, delay and

bandwidth.

Codec/Algorithm negotiation: it is possible to select a different codec in each direction, with the sending

codec forcing the choice of receiving codec; this allows different bandwidth to be used according to which

end makes the call. Note that, if using a TDM Aggregate, and a TDM timeslot is carrying the call, then

codec negotiation should not be used (since the TDM timeslot is configured with a fixed bandwidth size).

GAIN

Analogue voice applications often require adjustment to optimise the speech quality. This can be caused

by poor line impedance matching, signal loss and echo across the telephone network. A combination of

input and output gain adjustment over a wide range allows the user to achieve the clearest line,

consistent with echo cancellation. At the far end, input gain should be adjusted down to the lowest level

which cancels any echo, then the near end output gain adjusted to compensate for the overall signal level.

DESTINATION

When a voice channel destination is specified as “AUTO”, calls made on this channel will be automatically

routed to the dialled destination port according to the DTMF or E&M signalling received. It is also possible

to set up fixed destinations, as in the example above, by entering the specific address of the destination

port. This feature is useful when configuring Tie-lines between PABXs, or “hotlines” between telephones

and avoids the need for the user to enter any dialling digits just to route through the Vocality network.

Using the Directory menu it is possible to specify personalised numbers instead of Vocality-style port

numbers. This allows an existing network numbering scheme to be used with the multiplexer, as well as

permitting the use of node numbers greater than 9.


Field Options Description CHANNEL Information only Displays the numbers of all data channels installed.



Field Options Description CLKREF GRXCLK,

GTXCLK Clock reference bus used by the voice card PLL

DTMF, DTMF signalling passed. All relays enabled

E&M, E&M signalling passed. All relays enabled

TRANS, All signalling passed in-band. All relays disabled

V.22, As DTMF, but only V.22 data modem relay enabled

STU, As DTMF, but only STU-IIB/STU-III relays enabled

SIGTYPE

NOSTU As DTMF, but all relays except STU-IIB/STU-III enabled

FXS, 2-wire port configured to drive a telephone or Trunk Line input

FXO, 2-wire port configured to connect to an extension port

INTERFACE

Tie-line 4-wire E&M port. No telephone voltages allowed

Off, Channel not used

G.711-A 64K, PCM coded voice

G.711-u 64K, PCM coded voice

G.726 16K, ADPCM coded voice




G.727 16K, E-ADPCM coded voice

G.727 24/16K, E-ADPCM coded voice with asymmetric bit rate TX/RX








G.723.1 5.3K, ML-PLQ compressed voice

G.723.1 6.3K, ML-PLQ compressed voice

G.729A 8K, CELP compressed voice

Transp. 64K, Raw PCM sampled voice

Netcode 6.4K, Proprietary CELP compressed voice


Netcode 8K, Proprietary CELP compressed voice


ALGORITHM

Netcode 9.6K Proprietary CELP compressed voice

I-GAIN-O -31dB to +31dB Input and Output gains

"NODE:SLOT:CHANNEL", Voice channel has fixed destination

AUTO Call routed by dialled digits

NODE:HG:NUMBER Hunt group identified by the node number, ‘HG’, and the hunt group number

DESTINATION

NODE:SG:NUMBER SIP Gateway identified by the node number, ‘SG’ and the SIP Gateway number



Field Options Description BTXnnn, Broadcast TX channel number

BRXnnn, Broadcast RX channel number

BTRttt,rrr" Broadcast TX and RX channel numbers

DTMF RELAY

DTMF Relay mode is enabled or disabled on all ports. When DTMF Relay mode is disabled, the multiplexer

operates as it did prior to release 2.1.22 - the DTMF tones are carried through the compressed voice path.

When DTMF Relay is enabled, the DTMF digits are regenerated in the decoder and thus are not subject to

the loss effects through the standard encoder/decoder path. If DTMF is disabled and DTMF applications do

not seem to be working, the user may enable DTMF and tune the signal levels as necessary until the

application detectors work correctly.

NOTE: DTMF Relay must be enabled on at least the encoding side for the relay to work -even if

DTMF Relay is disabled on the decoder, the DTMF digit is regenerated correctly.

2.4.9.2.2 The SIGNALS & TONES menu



DTMF OUTPUT LEVEL

By using the DTMF Output Level setting, it is possible to adjust the volume of DTMF tone pairs relative to

all other (comfort) tones. The relative output level of the low frequency tone for DTMF digits (relative to

the high frequency output level) can be tuned.

DTMF TWIST

The twist allows you to set the relative levels of each member of the tone pair if necessary although by

using the defaults this is rarely necessary.

SIGNAL OUTPUT GAIN

The Signal Output Gain setting adjusts the output volume of both DTMF tones and call progress tones -

i.e. the volume of generated DTMF tones is controlled via a combination of the DTMF output level and

Signal output gain.


Field Options Description Disabled Default DTMF RELAY

Enabled Enables DTMF Relay. Mute Mutes the output. DTMF OUTPUT LEVEL

-31dBm - +3dBm

Sets the output level..

DTMF TWIST -4dB-0dB Sets the DTMF Twist.

DTMF TWIST -4dB-0dB Sets the DTMF Output Gain.

DTMF TONE PERIOD(ms) 50 to 1000ms Sets the DTMF tone-on period.

DTMF INTER-TONE GAP(ms) 20 to 500ms Sets the DTMF tone-off period.

ALT FXO RING DETECT Disabled, Default ring detection thresholds. Should be used in most cases.

Enabled An alternative ring detection thresholds are invoked, recommended for certain PBXs e.g. Alcatel



The VOICE ACTIVATION menu should be used only when it is necessary to guarantee that no data, IP or

Voice traffic is sent over a link. For example, when using Inmarsat-based apps where the link is a dial-up

commodity (which is expensive), it is important only to bring up the link when it is needed for genuine

traffic and not for the purposes of "background IP chatter". This is achieved by locking the activation in to

voice channels. When the first voice call is made, the link comes up and can then be used by any other

channel that can benefit from it, including other voice calls, IP traffic and so on. The link is then dropped

when all voice calls have finished, even if there is traffic on other ports.

In all other configuration locations no destination mappings should be configured – that is, they should be

left blank.

The activation script is run when the first voice call goes off-hook. A single TTY command (please refer to

the TTY Manual for more information) is entered on each line which assigns a destination to the voice,

data or IP channel.

The deactivation script is run when the last voice call goes on-hook. A single TTY command is entered on

each line which removes the destinations added in the activation script. Both the activation script and the

deactivation script are limited to eight TTY commands.

2.4.9.2.3 The VOICE ACTIVATION menu



2.4.9.3 The IP menu




Field Options Description AUTONEGOTIATE, Local connection mode

1000Mbps/FULL DUPLEX V200 only

100Mbps/FULL DUPLEX,

100Mbps/HALF DUPLEX,

10Mbps/FULL DUPLEX,

ETHERNET MODE

10Mbps/HALF DUPLEX

DNS SERVER Numeric IP address entry as: nnn.nnn.nnn.nnn

IP address of the DNS Server in the host network

OFF, The Integrated IP Router acts as a DHCP client

SERVER*, The Integrated IP Router acts as a DHCP server

DHCP SERVER MODE – applies to ENET1 only

RELAY** The Integrated IP Router relays DHCP address negotiations transparently between the client and the host server

*SERVER MODE = "SERVER" – only operates on ENET1

LEASE* Numeric entry 0-99999 secs

Duration of the DHCP IP address lease. (0=permanent)

2.4.9.3.1 The GENERAL menu



Field Options Description ADDRESS RANGE….TO*

Numeric IP address entry as: nnn.nnn.nnn.nnn

Inclusive range of grantable IP addresses

WINS SERVER* Numeric IP address entry as: nnn.nnn.nnn.nnn

IP address of the WINS Server in the host network

DOMAIN NAME* Alphanumeric entry Domain name of local network

**SERVER MODE = "RELAY”

PRIMARY ADDRESS** Numeric IP address entry as: nnn.nnn.nnn.nnn

Primary IP address of the DNS Server in the host network

SECONDARY ADDRESS**


Secondary IP address of the DNS Server in the host network (optional)

BRIDGE PRIORITY and HELLO TIME are always present

BRIDGE PRIORITY 0-65535 Sets the Spanning Tree bridge priority. See Section 4.12.15 for more information on the Spanning Tree protocol.

HELLO TIME(secs) 1-10 Sets the Spanning Tree hello time. See Section 4.12.15 for more information on the Spanning Tree protocol.

60-86400 seconds Sets the amount of time an idle TCP connection will remain connected when TCP PEP feature is used.

IDLE TIME

PERMANENT Idle TCP connections are left connected until the TCP peer disconnects the session.



When Ethernet ports are available they are represented in the user interface with the port name “ENET1”

and “ENET2”. When only a single Ethernet port is available it is represented in the user interface as ENET.

The Ethernet must be configured with the IP address of the Ethernet port on the local network, and the

mask of the local subnet. Any host stations (PCs), or routers on this local network, must be configured to

use the IP address of the multiplexer’s Ethernet as the next-hop gateway for all IP networks that the

multiplexer is providing interconnect services for. Alternatively, RIP may be used to do this automatically.

In the example below, the Ethernet port ENET1 has been configured with the address 192.168.0.135, and

the mask 255.255.255.0 – this mask allows the configuration of 253 other IP stations on the local network

(two addresses are also reserved for broadcast use). The Maximum Transmission Unit (MTU) in bytes is

typically left at the default value of 1514 for the Ethernet port. The UDP Gateway (UDPGw) option is

discussed later in the UDP relay section.

The Bridge field allows bridging or bridging and Spanning Tree Protocol to be enabled on a per-port basis.

If the IP field is configured as OFF and bridging is ON or STP then all traffic is bridged across the

multiplexer network. If the IP field is NUM (for ENETx port) or UNN (for tributary channels) and bridging is

ON or STP, then IP traffic is routed across the multiplexer network and all other traffic is bridged. (See

Section 4.12.15 for more information on Spanning Tree Protocol.)

The DBA and Destination fields are not used for the Ethernet port.

2.4.9.3.2 The NETWORKS menu



The TCP Gateway (TCPGw) option enables the use of the Performance Enhancement Protocol (PEP) and is

either blank (because a Feature Key has not been programmed) or can be set to On or OFF, on both

ENETx and the logical channels. See Section 4.12.12 for more information on PEP.

The IP field is fixed at NUM for standard numbered packet support for the Ethernet ports.

If an entry is provided for both ENET1 and ENET2 the multiplexer will bridge or route traffic locally

between these two ports.

A set of channel numbers (10-99) has been reserved within the multiplexer port numbering scheme for

use as virtual IP ports. These are assigned to the slot that is being configured. In this example, Slot 0 is

being configured and so the first virtual port, 0:10, is configured as a 512000bps DBA pipe connecting to

the corresponding virtual port in the remote multiplexer. All virtual ports may use the same IP address

allocation as the Ethernet port itself. It is possible to configure up to 90 such ports so as to link together

the integrated routers of up to 90 remote systems through the integrated router on this slot. Refer to

section 4.12.4 for details.


Field Options Description CHAN ENET1, ENET2,

x:10 - x:99, LOOP

Port or Virtual Port number on slot x Create a Loopback interface (See section 2.4.9.3.2.1)

DBA 0-10240000 Maximum DBA rate allocation between multiplexer units

IP UNN, NUM or OFF IP routing mode. Unnumbered for tributary interfaces, numbered for the Ethernet interface or Off.

ADDRESS Numeric IP address entry as: nnn.nnn.nnn.nnn

IP port address

MASK Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount

IP address mask. May be entered e.g. as "/24"

MTU Numeric 128 to 1516 Maximum Transmission Unit. Set to give max 20mS packets

OFF, User Datagram packet support UDPGw

ON

TCPGw ON OFF

Enable/disable the TCP PEP optimisation feature. This is only configurable if the TCPPEP feature has been purchased and the appropriate key has been entered in the feature key menu

ON Bridging is enabled on the specified port

STP Bridging and Spanning Tree Protocol is enabled on the specified port

Bridge

OFF Bridging is disabled on the specified port

DEST NODE:SLOT:CHANNEL Data will be forwarded to this virtual port address



A separate loopback interface may be configured for each Ethernet port that the embedded router

supports. If there is just a single Ethernet interface present, then the loopback interface is represented

with the port name “LOOP”. If there are two Ethernet interfaces present, then the loopback interfaces are

represented with the port names “LOOP1” and “LOOP2”.

To create a loopback interface, add a subnet to the IP NETWORKs menu for the LOOP interface. The

address used on the loopback interface can be a sub-component of one of the other numbered interfaces.

The loopback address can be used for ping or telnet access regardless of the state of the Ethernet

interfaces. It may also be used as the unnumbered source address for IP tributaries. This should be done

to avoid routing problems over the IP tributaries if the Ethernet ports fail.

When OSPF is run, and the loopback interface address is used as the unnumbered source address for IP

tributaries, then the loopback interface must be configured with a mask that is less than 31 bits.

The route management menu provides access to the RIPv2 and IP static route table menus, as well as

providing access to an OSPF sub-menu and a route policy control sub-menu:

2.4.9.3.2.1 Loopback interfaces

2.4.9.3.3 The ROUTE MANAGEMENT menu



Field Options Description CHAN ENET1,ENET2 x:10 -

x:99 Port or Virtual Port number

RIPv2 ENABLED, DISABLED Turns RIPv2 on or off on the specified channel.

IMPORT ENABLED, All received updates are processed.

ACCESS, Only updates received from IP addresses configured for RIP access in the access table are processed.

DISABLED All received updates are discarded.

COST 0-15 Sets the metric or cost value used in the RIP protocol for this embedded router port.

YES, Routes for local interface routes that have been configured on this IP router are included in RIP route advertisements sent on this port.

NO, Routes for local interface routes that have been configured on this IP router are not included in RIP route advertisements sent on this port.

IF

FILT The RIP export table configuration (under the policy sub-menu) controls which interface routes are advertised via RIP on this port.

2.4.9.3.3.1 The RIPv2 menu



YES, Routes for static routes that have been configured on this IP router are included in RIP route advertisements sent on this port.

NO, Routes for static routes that have been configured on this IP router are not included in RIP route advertisements sent on this port.

STAT

FILT The RIP export table configuration (under the policy sub-menu) controls which static routes are advertised via RIP on this port.

YES, RIP routes that have been learnt on this IP router are included in RIP route advertisements sent on this port.

NO, RIP routes that have been learnt on this IP router are not included in RIP route advertisements sent on this port.

RIP

FILT The RIP export table configuration (under the policy sub-menu) controls which RIP routes are advertised via RIP on this port

YES, OSPF routes that have been learnt on this IP router are included in RIP route advertisements sent on this port.

NO, OSPF routes that have been learnt on this IP router are not included in RIP route advertisements sent on this port.

OSPF

FILT The RIP export table configuration (under the policy sub-menu) controls which OSPF routes are advertised via RIP on this port

NONE, No authentication is required on RIP protocol packets sent and received on this port.

OPEN, Clear text authentication is attempted on RIP protocol packets sent and received on this port.

AUTH MODE

MD5 Encrypted authentication is attempted on RIP protocol packets sent and received on this port. The KeyID used for MD5 Authentication is fixed to the value 1.

AUTH KEY Alphanumeric entry The authentication information (password) to use when using simple MD5 authentication on this port – up to 16 characters.

ENABLED, The poison reverse mechanism of the RIP protocol is used. This setting must be the same for all RIP enabled ports.

POISON REVERSE*

DISABLED The poison reverse mechanism of the RIP protocol is not used. This setting must be the same for all RIP enabled ports.

* The POISON REVERSE feature can be set to ENABLED (default) or DISABLED for each IP subnet. When it is

enabled we will advertise routes learnt on an interface back out of that interface with an infinite metric. When

it is disabled we will not advertise routes learnt on a interface back out of that same interface.



Four sub-menus are provided for controlling OSPF configuration. An OSPF system menu provides control

over slot-wide system OSPF parameters. An Area sub-menu allows the user to configure which OSPF

areas the router will operate in. An Interface sub-menu allows the user to configure how OSPF will

operate on each router interface. The Virtual Link sub-menu allows the user to configure OSPF virtual

links.

The menu is presented as follows:

2.4.9.3.3.2 The OSPF menu



The OSPF system menu controls the parameters that affect OSPF protocol operation across the entire

embedded IP router (i.e. on the slot being configured). The menu is presented as follows:

Field Options Description PROTOCOL SUPPORT ENABLED, DISABLED Controls whether the OSPF protocol is run

on this embedded router. Note that the protocol must be enabled here and on each interface that it is required on to operate successfully.

AUTOMATIC, The highest IP address configured on the router’s loopback ports is used as the OSPF protocol 32-bit router ID. If no loopback ports are present then the highest address on the Ethernet ports is used.

ROUTER ID


Uses a specific address

ENABLED, Enable RFC 1583 compatibility mode for the SPF calculation.

RFC1583 COMPATIBILITY *

DISABLED Default state.

ASE ROUTE PREFERENCE

Integer range 1-255 Specifies how active routes that are learned from the OSPF ASE (Autonomous System External) (compared to other protocols) will be selected. When a route has been learned from more than one protocol, the active route will be selected from the protocol with

2.4.9.3.3.2.1 The SYSTEM menu



the lowest preference. Each protocol has a default preference in this selection.

NSSA ROUTE PREFERENCE

Integer range 1-255 Specifies how active routes that are learned from the OSPF NSSA (Not So Stubby Area) (compared to other protocols) will be selected. When a route has been learned from more than one protocol, the active route will be selected from the protocol with the lowest preference. Each protocol has a default preference in this selection.

ALL, This node causes Interface routes to be considered for redistribution into OSPF-ASE when set to All.

NONE, Interface routes will not be considered for redistribution.

ASE EXPORT IFACE ROUTES

CONFIGURED ** Interface routes that match the named route map will be considered for redistribution into OSPF-ASE.

ALL, This node causes Static routes to be considered for redistribution into OSPF-ASE when set to All.

NONE, Static routes will not be considered for redistribution.

ASE EXPORT STATIC ROUTES

CONFIGURED ** Static routes that match the named route map will be considered for redistribution into OSPF-ASE.

ALL, This node causes RIP routes to be considered for redistribution into OSPF-ASE when set to All.

NONE, RIP routes will not be considered for redistribution.

ASE EXPORT RIP ROUTES

CONFIGURED ** RIP routes that match the named route map will be considered for redistribution into OSPF-ASE.

ALL, This node causes ASE routes to be considered for redistribution into OSPF-ASE when set to All.

NONE, ASE routes will not be considered for redistribution.

ASE EXPORT ASE ROUTES

CONFIGURED ** ASE routes that match the named route map will be considered for redistribution into OSPF-ASE.

ALL, This node causes NSSA routes to be considered for redistribution into OSPF-ASE when set to All.

NONE, NSSA routes will not be considered for redistribution.

ASE EXPORT NSSA ROUTES

CONFIGURED ** NSSA routes that match the named route map will be considered for redistribution into OSPF-ASE.

ALL, This node causes Interface routes to be considered for redistribution into OSPF-NSSA when set to All.

NONE, Interface routes will not be considered for redistribution.

NSSA EXPORT IFACE ROUTES

CONFIGURED ** Interface routes that match the named route map will be considered for redistribution into OSPF-NSSA.



ALL, This node causes Static routes to be considered for redistribution into OSPF-NSSA when set to All.

NONE, Static routes will not be considered for redistribution.

NSSA EXPORT STATIC ROUTES

CONFIGURED ** Static routes that match the named route map will be considered for redistribution into OSPF-NSSA.

ALL, This node causes RIP routes to be considered for redistribution into OSPF-NSSA when set to All.

NONE, RIP routes will not be considered for redistribution.

NSSA EXPORT RIP ROUTES

CONFIGURED ** RIP routes that match the named route map will be considered for redistribution into OSPF-NSSA.

ALL, This node causes ASE routes to be considered for redistribution into OSPF-NSSA when set to All.

NONE, ASE routes will not be considered for redistribution.

NSSA EXPORT ASE ROUTES

CONFIGURED ** ASE routes that match the named route map will be considered for redistribution into OSPF-NSSA.

ALL, This node causes NSSA routes to be considered for redistribution into OSPF-NSSA when set to All.

NONE, NSSA routes will not be considered for redistribution.

NSSA EXPORT NSSA ROUTES

CONFIGURED ** NSSA routes that match the named route map will be considered for redistribution into OSPF-NSSA.

* NB RFC1583 COMPATIBILITY: Do not configure this parameter "ENABLED" if all the routers using an OSPF implementation in your domain are based on RFC 2328 or later. This parameter should be specified the same way on all routers in the domain. If any of the routers do not have this option, you should always enable this. When disabled, the preference rules for best route election are changed to eliminate certain kinds of possible routing loops. ** NB Route maps need to be configured first before this option is available in the menu.

The OSPF Area sub-menu allows to specification of which areas the OSPF protocol should operate in. An

area must be added via this menu for OSPF to operate successfully. Interfaces are configured to operate

in areas created via this menu. By default there are no areas created, and the menu is presented as

follows:

2.4.9.3.3.2.2 The AREA menu



Use the ADD AREA button to create a new area. Once areas have been added, the menu is presented as:



Field Options Description AREA TO EDIT/VIEW Select from list Select which area you are currently

configuring parameters for. If only a single area has been created then this has no affect.

AREA ID Numeric IP address entry as: nnn.nnn.nnn.nnn

IP address – Each OSPF router must be configured into at least one OSPF area. Each OSPF area must have a unique ID. An area ID of 0.0.0.0 signifies that the area is a backbone.

NORMAL, Generic Area

STUB, A "stub" area is one in which there are no ASE or NSSA routes. Each router in the area must specify that the area is a stub, or adjacencies will not form.

TYPE

NSSA A Not-So-Stubby-Area (NSSA) is configured according to draft-ietf-ospf-nssa-update-11.

The OSPF Interface menu allows the user to configure how the OPSF protocol will operate on each

interface on the embedded router. A separate page is presented for each interface that has been

configured (via the Networks menu) on the router:

2.4.9.3.3.2.3 The INTERFACE menu



Field Options Description ENTRY TO EDIT/VIEW Select from list Select which interface you are currently

configuring parameters for. INTERFACE Read only The interface name of the interface currently

being configured. ENABLED, OSPF routing protocol is run on this interface.

DISABLED, OSPF routing protocol is not run on this interface.

PROTOCOL

PASSIVE The port does not receive or transmit any protocol packets onto the interface, but the attached network is treated as part of the routing domain.

ENABLED, The router only accepts OSPF protocol packets from units with IP addresses that are configured in the access table.

ACCESS CHECK

DISABLED No Access security checks are made


Selects which of the areas configured via the area menu this interfaces is operating within.

OUTPUT COST Integer between 1 and 65535 – defaults to 10.

The metric for this interface.

RETRANSMIT INTERVAL

Integer between 1 and 65535 – defaults to 5.

The default for the number of seconds between link state advertisement retransmissions for adjacencies. If a Link State Protocol is not acknowledged within the amount of time specified here, it is re-sent.

TRANSMIT DELAY Integer between 1 and 65535 – defaults to 1.

This parameter sets the estimated number of seconds required to transmit a link state update. This parameter takes into account transmission and propagation delays and must be greater than 0.

ROUTER PRIORITY Integer between 0 and 255 – defaults to 1.

The priority for becoming the DR (Designated Router). *

HELLO INTERVAL Value in seconds between 1 and 65535

Defaults to 10 seconds. This parameter specifies the length of time, in seconds, between hello packets that the router sends on the interface.

DEAD INTERVAL Value in seconds between 1 and 65535

Defaults to 40 seconds. This parameter specifies the number of seconds that may elapse without receiving a router's hello packets before the router's neighbours will declare it down. A general rule is to be at least three times the HELLO interval. Do not set this value to be less than the HELLO interval, or convergence will not occur.

POLL INTERVAL Value in seconds between 1 and 65535

Defaults to 120 seconds. This parameter sets the length of time in seconds between OSPF packets that the router sends before adjacency is established with a neighbour. The poll interval can be used to reduce network overhead in cases where a router may or may not have a neighbour on a given interface at the expense of initial convergence time.

AUTHENTICATION SIMPLE, MD5

The authentication protocol to run on this interface.

MD5 KEY ID 0-255 The KeyID to use when using MD5 authentication. Not used when the Authentication parameter is set to Simple.



KEY Alphanumeric, 16 characters maximum

The key or password used for OSPF authentication on this interface. The entry is hidden from the user and must be re-entered to verify.

* NB When more than one router attached to a network attempts to become the DR, the one with the highest priority wins. If the competing routers have the same priority, the one with the highest router ID becomes the DR. The router coming in second in the election becomes the backup DR. A router with a router priority set to 0 is ineligible to become the DR.

This menu allows the OSPF implementation to operate over virtual links. Virtual links are used to

establish or increase connectivity of the backbone area. By default there are no virtual links configured

and the following menu is presented:

The ADD LINK button allows the user to add a new virtual link. Once at least one virtual link has been

added, the following menu page is presented to control the parameters of each of the virtual links. Note

that the backbone area (0.0.0.0) must be present in the router’s configuration for virtual links to work

correctly:

2.4.9.3.3.2.4 The VIRTUAL LINK menu



Field Options Description LINK TO EDIT/VIEW Select from list Select which link you are currently configuring

parameters for. NEIGHBOUR ID Numeric IP address

entry as: nnn.nnn.nnn.nnn

IP Address. The router ID of the remote end of the virtual link.


Selects the transit area through which this virtual link should exist. This should be one of the areas that is configured on the unit, but cannot be the backbone area (0.0.0.0).

RETRANSMIT INTERVAL

Value in seconds between 1 and 65535

Defaults to 5 seconds. This parameter sets the default for the number of seconds between link state advertisement retransmissions for adjacencies. If a Link State Protocol is not acknowledged within the amount of time specified here, it is re-sent.

TRANSMIT DELAY Value in seconds between 1 and 65535

Defaults to 1 second. This parameter sets the estimated number of seconds required to transmit a link state update. This parameter takes into account transmission and propagation delays and must be greater than 0.

ROUTER PRIORITY Integer between 0 and 255

Defaults to 1. This parameter specifies the priority for becoming the DR (Designated Router).*

HELLO INTERVAL Value in seconds between 1 and 65535

Defaults to 10 seconds. This parameter specifies the length of time, in seconds, between hello packets that the router sends on the virtual link.

DEAD INTERVAL Value in seconds between 1 and 65535

Defaults to 40 seconds. This parameter specifies the number of seconds that may elapse without



receiving a router's hello packets before the router's neighbours will declare it down. A general rule is for this value to equal atleast three times the HELLO interval. Do not set this value to be less than the HELLO interval, or convergence will not occur.

POLL INTERVAL Value in seconds between 1 and 65535

Defaults to 120 seconds. This parameter sets the length of time in seconds between OSPF packets that the router sends before adjacency is established with a neighbour. The poll interval can be used to reduce network overhead in cases where a router may or may not have a neighbour on a given virtual link at the expense of initial convergence time.

AUTHENTICATION SIMPLE, MD5

The authentication protocol to run on this interface.

MD5 KEY ID 0-255 The KeyID to use when using MD5 authentication. Not used when the Authentication parameter is set to Simple.

KEY Alphanumeric, 16 characters maximum

The key or password used for OSPF authentication on this interface. The entry is hidden from the user and must be re-entered to verify.

* NB When more than one router attached to a network attempts to become the DR, the one with the highest priority wins. If the competing routers have the same priority, the one with the highest router ID becomes the DR. The router coming in second in the election becomes the backup DR. A router with a router priority set to 0 is ineligible to become the DR.

If RIP is not used, each multiplexer IP router must be configured with static routes to tell it how to reach

IP networks other than the one that it is locally attached to. An IP STATIC ROUTE TABLE menu screen is

provided under the IP sub-menu to do this. Each configured route consists of a description, a destination

address, a mask for the destination address and a next-hop.

The IP static route table includes a route preference parameter with each route configured. Route

preferences provide a selection mechanism when the same route (address/mask match) is learnt from

multiple sources (static routes, RIP and OSPF). The route with the lowest preference is selected. Note

that both address and mask must match for the preference to be considered. A route with a more specific

mask will always take preference over one with a more generic mask regardless of the configured

preferences. RIP routes are always installed with a preference value of 100. The preference for OSPF

routes is taken from the OSPF system configuration menu. The preference used for static routes is taken

from the parameter configured in the static route table:

2.4.9.3.4 The IP STATIC ROUTE TABLE menu




Field Options Description DESCRIPTION Alphanumeric For user entry

DESTINATION Numeric IP address entry as: nnn.nnn.nnn.nnn

IP port address

MASK Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount

IP address mask. May be entered e.g. as "/24"

NEXT HOP Numeric IP address entry as: nnn.nnn.nnn.nnn or /bitcount or Virtual port I.D. x:[10-99] NODE:SLOT:CHANNEL

Address of forwarding node or port

PREFERENCE 1 to 255 Route preference rating (lowest preferred)



By default, when a routing protocol is enabled it will advertise all routes in the embedded protocol’s

routing table. The routing policy menu allows control over whether another protocol’s routes are

advertised – it is also possible to be more selective about which routes are advertised.

The route policy allows single aggregate routes to be advertised in place of member routes that make up

that aggregate (in order to reduce the complexity/size of the routing updates through the network), and

for more complex selection on what routes are exported via the routing protocols.

The policy control is done via address lists, route maps, RIP export filters and route aggregation.

Address lists just define ranges of IP addresses with inclusion and exclusion rules. These address lists are

referenced from route maps definitions and RIP export filters. Route maps identify sets of routes. They

are referenced from RIP export filters, OSPF export rules and route aggregation definitions. RIP export

filters define which routes are included in RIP updates when the RIP export control is set to filter for a

particular protocol. Route aggregation rules specify which aggregate routes to advertise when member

routes are present.

The policy sub-menu provides access to the configuration pages for the policy control:

2.4.9.3.5 The POLICY menu



Address lists define ranges of IP addresses with inclusion and exclusion rules. Each address list should be

configured with a unique name. These named address lists are referenced from route maps definitions

and RIP export filters. By default there are no address list names present and the Address List menu is

presented as:

A new list button is presented to allow the user to add the first named address list. When this is selected,

an empty address list with the name AL00 is created and the following menu is presented:

2.4.9.3.5.1 The ADDRESS LISTS menu



Each line in the presented table represents a named address list. The name of the address list may be

altered at this time. Note that address lists are referenced by name, so if you change the name of an

address list that is already referenced from a route map or RIP export filter, then those entities will not get

configured correctly when the configuration is saved and applied to the running router.

Each named address list is made up of a number of entries (rules) which specify which addresses are

included in the list. The number of rules in each address list is shown in the EntryCount column (read-

only). To configure or view the address matching rules the <CONFIGURE> button should be selected.

When there are no address rule entries in an address list, the following menu is presented:



The NEW ENTRY button can be used to add entries to the named address list. When it is selected, the

next entry in the sequence of address list rules (0 if there are no entries currently in the list) is created.

Each line in the menu is a new sequenced entry in the address list rules. Each entry allows the user to

specify an IP address and IP mask, and whether the checked address should match (MATCH) or not

match (IGNORE) this information to be considered as part of this address list.

When an address is checked against an address list, it is checked against each entry in the sequence

order specified. If the address matches any of the entries then it is considered a member of the address

list.

The following example shows an address list (named AL00) that has been configured to check for any

addresses on the 192.168.1.0/24 or 192.168.2.0/24 subnets:



Route maps identify sets of routes. Each route map should be configured with a unique name. These

named route maps are referenced from RIP export filters, OSPF export rules and route aggregation

definitions. A route map is made up of a sequence of rules that are used to match route destination

addresses and other route characteristics. Route maps also allow the user to change some metric

characteristics of the route that matches the identification rules.

The top-level route map menu page shows a row for each route map that has been configured on the

unit. When there are no route maps present, the following menu is presented:

2.4.9.3.5.2 The ROUTE MAPS menu



To create the first route map, select the NEW ROUTE MAP button. This creates a new route map with a

default name of RM00. The name can be changed and the menu for creating rules for this route map can

be accessed via the menu screen:



The CONFIGURE button provides access to the configuration of the rules entries. By default a new route

map has no rule entries associated with it. The following menu is presented:

Use the ADD ENTRY button to create the next rule. A menu page is provided for each rule in each map:



NEXT ENTRY and PREV ENTRY buttons are available for scrolling between them. The DELETE ENTRY

button will delete the rule entry, but leave the route map in place. The parameters for each route map

rule entry are as follows:

Field Options Description MAP NAME Alphanumeric Read-only identification of the route map name that

this rule belongs to. SEQUENCE NUMBER

Numeric 0-99 The relative order in which this rule is checked compared to other rules in the same route map. If this is set to the same value as another rule in the same route map, then the other rule will be removed.

ALLOW/DENY ALLOW, DENY

Selects whether routes that match the route identification rules are either included (ALLOW) or excluded (DENY) in the route map.

ROUTE IDENTIFICATION

MATCH PROTOCOL NO, YES

Selects whether the route must match the PROTOCOL specified to be considered to follow the rule specified.

PROTOCOL STATIC, RIP, OSPF, OSPFASE, OSPFNSSA, IF

Selects the protocol that a route must be learned from if the MATCH PROTOCOL parameter is set to YES. OSPF indicates OSPF AS-internal routes. OSPFASE indicates OSPF AS-external routes. OSPFNSSA indicates OSPF type-7 LSA routes. IF indicates local interface routes.

MATCH ADDRESS NO, YES

Selects whether the route must match the address list specified via ADDR LIST NAME to be considered to follow the rule specified.

ADDR LIST NAME List of configured address names

The address list name that the route destination is checked against if the MATCH ADDRESS parameter is set to YES. Only address list names that are currently configured on the unit are selectable – create the address list name first if this is being used. If a route map references a route map that is then deleted, then the route map check will no longer operate correctly.

MATCH INTERFACE NO, YES

Selects whether the outbound interface for a route must match the INTERFACE specified to be considered to follow the rule specified.

INTERFACE List of configured interface names

The interface name to be used if the MATCH INTERFACE parameter is set to YES.

REDISTRIBUTE OPTIONS

REAPPLY METRIC NO, YES

When set the YES then the route metric for routes that match the identification rules is updated with the specified METRIC value. When set to NO the metric is unaltered except for standard protocol rules.

METRIC Value between 1 and 65535

Route cost. Only values between 0 and 15 are valid when using RIP however.

OSPF METRIC TYPE 1 or 2 The OSPF metric type that is used when advertising routes that match this route map rule via the OSPF protocol.

OSPF TYPE 5 PROPAGATION

NO, YES

This parameter controls whether Area Border Routers on an NSSA area propagate the route into type-5 reachability.



Note that the parameters that are used to create route map rules are generic for all route types. Some

parameters may not be required when using route maps for certain mechanisms. For example, when

using route maps to filter which static routes are advertised via RIP, it is not necessary to indicate that we

should match static routes within the route map rule entry, as this has already been constrained by

checks at a different level.

When the RIP export policy for an interface running the RIP protocol is set to FILT, the RIP export filters

are checked to find routes to include in RIP updates on that interface. These are configured via the RIP

Export Filters menu. By default there are no RIP export filters present (and therefore no routes will match

the filters and be included in filtered updates). The menu is presented as follows:

The NEW EXPORT FILTER button creates a new filter to check. Each filter is made up of the interface that

the filter applies to, a reference to an address list to check the route destination address against, a

protocol to specify where the route was learned from, and an optional route map that can further restrict

the route selection (based on outbound interface) and/or update the metric to use in the RIP update.

A single row is used for each filter in the RIP export filter database:

2.4.9.3.5.3 The RIP EXPORT FILTERS menu



The address list is a named address list that must have been previously configured on the unit. The route

map is a named route map that must have been previously configured on the unit, or the name

“(Unconfigured)” if the route map is not required for the filtering.

The route aggregation menu allows the user to configure the IP router to aggregate routes that it is

advertising. Aggregation involves advertising a summary route in place of several less significant

contributing routes. Configuration of a route aggregate involves specifying the aggregate route

(address/mask combination) and then specifying which contributing routes may make up this aggregate.

If any of the contributing routes is present then the aggregate route is used instead of the contributing

route. The route aggregation feature can also be used to filter out which routes are advertised – you can

select to block the advertisement of the aggregate route. By default there are no route aggregates

configured and the route aggregation menu is presented as:

2.4.9.3.5.4 The AGGREGATION menu



The NEW ROUTE AGG button is used to create a new aggregate route. When the route is created, it is

presented on a single row in the menu as follows:



The destination and mask specifies the aggregate route to advertise. The contributing route map is a

route map name for the aggregate’s contributing routes. The route map must be already configured on

the unit. The Block parameter allows the user to either BLOCK or ALLOW the advertisement of the

aggregate route when the contributing routes are present.

The supervisor configuration screens can now be accessed via the telnet protocol. To provide additional

security to ensure that telnet access is only granted to the appropriate parties, an access table has been

provided. The access table must be configured to specify which station or group of stations are allowed

access to IP host facilities on the multiplexer. Each access table entry comprises a description an IP

address, an IP mask, and a service definition. When an attempt is made to access the host service (e.g. a

telnet connection is requested), the access table is checked to ensure that an entry matches the

requesting host. An IP address/mask pair of 0.0.0.0/0.0.0.0 will allow access from any station to the

configured service. The services that are controlled through this access are currently (i) the embedded

telnet server, and (ii) “Chargen” (character generator) TCP server.

This table is empty by default. An entry must be added to allow telnet access.

2.4.9.3.6 The ACCESS TABLE menu



Standard IPV4 router operation does not allow for the forwarding of subnet broadcasts. However certain

network applications rely on the relay of UDP packets sent to the subnet broadcast address. For example

Windows browsing service relies on Netbios datagram service packets (addressed to UDP port 138 and

the IP subnet broadcast address) reaching all stations within the browsing domain. The UDPGw

configuration must be turned to “On” for each port that we wish the relay operation to work on and an

entry in the UDP relay table must be added for each service that must be relayed. Some well-known

service types are pre-configured for addition to this table – other services require the appropriate UDP

port number to be configured. The example below shows the configuration required to get legacy

Windows networking working smoothly:


Service Port Number Domain Name 53

NetBIOS Name 137

NetBIOS Datagram 138

Time 37

Other For user entry

2.4.9.3.7 The UDP RELAY TABLE menu



DBA pools are used to pool available DBA-assigned bandwidth between IP tributaries that share a

common aggregate path. The pooling allows unused bandwidth from one tributary in a pool to be

assigned to other tributaries that currently have excess data routed through them. It is intended for use in

networks where IP tributaries are routed across a common broadcast aggregate, or where several IP

tributaries have been configured between two multiplexers and are used separately for service

management. An unlimited number of DBA pools may be defined in the system.

By default, no tributaries are assigned to the pools. To use the DBA pooling, the IP tributaries must be

assigned to DBA pools. The DBA pools menu provides the mechanism for assigning the tributaries to

pools. Members may be added to a pool from a selection list of all available IP tributaries, as configured

on the Networks menu. A tributary is assigned to a pool by giving it a priority

(highest/high/medium/low/lowest) within the pool. A pool must have at least two tributaries assigned to it

for the pooling to operate. To remove a tributary from a pool, the priority value should be toggled to

“EXCLUDE” and the member is deleted when the page is updated.

The priority scheme defines how bandwidth is shared between tributaries. Each tributary always has

access to the bandwidth assigned from the original DBA calculation. However, any bandwidth not used is

then shared according to the following scheme:

- Highest priority tributaries share the spare bandwidth between them using as much as is needed.

- If any spare bandwidth is available after this then the remainder is shared with a weighting between

high, medium and low priority tributaries.

- Any spare bandwidth after this is assigned to lowest priority tributaries.

Tributaries must only be configured in the same pool if they share a common aggregate path - otherwise

bandwidth management will be compromised.

An example:

0:10 is an IP tributary between node 0 and node 1.

0:11 is an IP tributary between node 0 and node 2.

2.4.9.3.8 The DBA POOLS menu



0:10 & 0:11 are routed across a shared outbound aggregate.

On Node0 you can configure 0:10 and 0:11 in the same DBA pool.



If 0:10 and 0:11 are both assigned 64kbps of bandwidth, then when 0:10 is not using its share, 0:11 has

access to 128k of the broadcast aggregate. If 0:10 is only using 32kbps at any instant, then 0:11 is given

access to 96kbps at the same instant.

Another example:

0:10, 0:11 & 0:12 are three IP tributaries between node 0 and node 1. 0:10 has been set up to provide

bandwidth for TCP application X. 0:11 has been setup to provide bandwidth for TCP application Y. 0:12

has been setup to provide bandwidth for TCP application Z. Application X is considered much more

important than application Y, and Y is more important than Z.

DBA has assigned 64kbps to 0:10, 4kbps to 0:11 and 4kbps to 0:12.

By pooling 0:10, 0:11 and 0:12 together with 0:10 assigned at highest priority, 0:11 assigned at medium

and 0:12 assigned at lowest priority, applications Y & Z can access the additional 64kbps bandwidth

assigned to application X when it is not in use. Application Y gets access to the bandwidth before

application Z.



This table adds a security feature to the multiplexer enabling the administrator to limit IP and bridge

access to a defined set of end stations. By default the table is empty and no MAC source filtering occurs –

all traffic is successfully received. As soon as a single entry is added to the table and the configuration

changes are saved, MAC source filtering is enabled. Only stations whose MAC address appears in the MAC

source filter table may access the IP and bridge services.

New entries are given a description which is used to identify the device specified by the MAC address in

the table. The Address is the device’s MAC address. In the example above, only the two devices with the

MAC addresses 08:00:31:02:22:ad and 08:ab:11:00:a2:f4 will be able to receive traffic (however,

unauthorised units will still be able to receive traffic broadcast by the multiplexer). Also, although

unauthorised units will be able to access other machines on the remote network, the embedded DHCP

server will not assign them addresses because it will not receive the DHCP request.

MAC source filter table entries affect all received Ethernet traffic including bridged, IP routed, PEP, and

telnet traffic for the local supervisor.

NOTE: When two Ethernet ports are present, the entries in this table apply to both ENET1 and

ENET2.

2.4.9.3.9 The MAC SOURCE FILTER TABLE menu



The service management facility allows the multiplexer administrator to perform IP filtering and

forwarding decisions based on fields within the protocol header in addition to the standard destination

address. This allows bandwidth management per protocol, set of end stations (source and/or destination),

and/or IP ToS field. Configuring the service management is a 3-stage process:

1. Defining sets of address ranges in the address definitions menu

2. Defining IP/UDP/TCP/ICMP protocol definitions in the protocol definitions menu

3. Applying address range matches against source and/or destination addresses in combination with

matching IP TOS fields and protocol definitions to determine a filter disposition. This disposition is

to either forward a packet down a specific tributary or discard the packet.

If no match is found in the configured filter table for a packet, then standard destination address IP

routing is performed.

The Service Management feature allows the multiplexer administrator to perform IP filtering and

forwarding decisions based on fields within the protocol header. This allows bandwidth management per

protocol, set of end stations (source and/or destination) and/or IP Type of Service (ToS) field.

2.4.9.3.10 The SERVICE MANAGEMENT menu



NOTE: Service Management applies only to IP routed traffic. It does not apply to bridged

traffic. Traffic forwarded by the PEP feature is also subject to Service Management.

NOTE: This table does not define a filter, it only defines address ranges. Filters are created

when address ranges are combined with protocols (see Section 2.4.9.3.10.2) in the FILTER

TABLE menu (see Section 2.4.9.3.10.3).

This menu allows the user to define the range of addresses to be used in the filtering definitions. Each

range is given a name to identify it, an address range (ADDRESS and MASK), and an operator (either

MATCH or NOT MATCH). The name is used in the Service Management Filter Table.

In the example above, the address 192.168.0.1 falls within the range defined by the entry INTERNET.

However, since the operator is NOT MATCH, the entry only filters those addresses that do not fall within

the address range specified. Since the address 192.168.0.1 does not fall within the range defined by the

entry LOCATION1 either, Service Management filters are not applied to it.

However, the address 192.168.1.1 falls within the address range specified by the LOCATION1 entry. Since

the operator is MATCH, this address is filtered using the rules defined in the SERVICE MANAGEMENT

FILTER TABLE.

2.4.9.3.10.1 The ADDRESS DEFINITIONS menu



NOTE: If an address definition that is in use in the SERVICE MANAGEMENT FILTER TABLE is

deleted then any entries in the SERVICE MANAGEMENT FILTER TABLE that reference the

deleted address entry are also deleted.

This page is used to define the protocols and ports used in the Service Management filters. Each entry is

given a name which is used in the SERVICE MANAGEMENT FILTER TABLE.

The definition can either be a range of UDP ports for UDP IP packets, a range of TCP ports for TCP IP

packets, or any other IP protocol. The IP PROTO field defines which IP protocol the packet is for. This is a

decimal value for the IP protocol field in the received packet. Three special values of TCP, UDP, and ICMP

are available for common protocols. If a value other than TCP or UDP is entered, nothing else needs to be

configured for the entry. If TCP or UDP (or the corresponding IP protocol number) is entered, a range of

source and destination ports must be specified for the protocol definition. The range consists of a

minimum and maximum (inclusive) decimal port number. The value ANY may be used to indicate the

range does not matter for a particular entry. A single page of up to 14 protocol definitions is allowed.

NOTE: If a protocol definition that is in use in the SERVICE MANAGEMENT FILTER TABLE is

deleted then any entries in the SERVICE MANGEMENT FILTER TABLE that reference the deleted

protocol entry are also deleted.

2.4.9.3.10.2 The PROTOCOL DEFINITIONS menu



The FILTER TABLE combines address ranges and protocols defined in the other two Service Management

menus and applies them to packets received on the Ethernet ports.

PRIO

Each set of rules has a priority which defines the order the rules are applied - 01 is the highest priority. To

change the priority of an entry, edit the PRIO field with a new number. All the entries are re-numbered to

reflect changes to the priorities.

Filters are applied in the order of priority in the table. Once a filter is matched no other filters in the table

are attempted. The SERVICE MANAGEMENT FILTER TABLE provides a single page of up to 15 entries.

RXNET

RxNet is used to identify the Ethernet interface of IP tributary that a packet was received on. Valid entries

are ENET (for single port products), ENET1, ENET2 (for dual port products), virtual channel (slot:channel)

or ANY.

2.4.9.3.10.3 The FILTER TABLE menu



TARGET

Target is used to identify the Ethernet interface of IP tributary that the packet would normally get routed

to (based on an IP route table lookup). Valid entries are ENET (for single port products), ENET1, ENET2

(for dual port products), virtual channel (slot:channel) or ANY.

ADDRESSES

The SOURCEADDR and DESTADDR fields can be configured with the value ANY or a name from the

SERVICE MANAGEMENT ADDRESS DEFINITIONS menu. The value ANY indicates any source or destination

address.

TOS

The Type of Service (TOS) field may be any 8-bit hex value or the word ANY. This defines what the TOS

field in the IP header should be to match the rule.

PROTOCOL

The PROTOCOL field can be configured with the value ANY or a name from the SERVICE MANAGEMENT

PROTOCOLS DEFINITIONS menu. The value ANY indicates any IP, UDP or TCP protocol/port combination.

RESULT

The RESULT field is used to define the operation should all the other elements of the filter match. The

entry may forward the traffic to an IP tributary (slot:port) or it may DISCARD the traffic or it may ALLOW

matching entries to be passed on to the destination.

NOTE: If an address or protocol definition that is in use in the SERVICE MANAGEMENT FILTER

TABLE is deleted then any entries that reference the deleted entry are also deleted.



The TCPGw filter table allows a simple and efficient scheme for selecting which TCP traffic is subject to the

Proxy Enhancement Protocol (PEP) optimization. This TCPGw Filter table is laid out in an identical fashion

to the standard Filter Table above. The filter can use any combination of the received interface (RxNet),

the target interface (Target), the source address, the destination address, the ToS and the TCP protocol to

decide whether the packet is subjected to the optimization (Result = PEP) or whether the optimization is

bypassed (Result = BYPASS). If no match is found in the TCPGw table then the default result is to

optimize (PEP) the traffic – this default behavior can be changed by added a default entry (all the

parameters set to ANY) with a result of BYPASS as the last entry in the table. The TCPGw Filter table is

presented as:

The multiplexer supports multiplexing over IP networks. This is achieved through the configuration of

point-to-point connections between pairs of multiplexers over an IP network. These connections are

known as IP aggregates. NOTE: IP Aggregates can only be configured on Slot 0.

2.4.9.3.10.4 The TCPGw FILTER TABLE menu

2.4.9.3.11 IP AGGREGATES menu



Each page in this menu represents a separate IP aggregate. Up to 31 IP aggregates may be specified.

Additional pages are presented with menu buttons to move between pages. The aggregate to edit or view

can be selected via the “Next Channel” and “Prev Channel” buttons or via the “Agg to Edit/View” field.

The IP aggregates operate over the UDP transport protocol. The quality of tributary connections across the

IP aggregate depends on the quality of service provided by the IP network. For optimum performance the

IP network should provide a guaranteed level of service - where a fixed bandwidth is always available

between the IP aggregate peers with minimum variation in latency. When an IP quality of service scheme

is in place in the IP network, the IP QoS edge router can identify the multiplexer IP aggregate frames

either by address/port recognition, or by configuring the IP aggregate to generate packets with a certain

TOS (type of service) setting. The IP aggregate multiplexing protocol includes a facility for re-ordering

multiplexed packets that were mis-ordered within the IP network (typically due to split-path routing with

latency variation on the split paths). The IP aggregate can also be tuned to trade-off multiplexing

overhead versus latency. A multiplexing period specifies the frequency at which tributary packets are

multiplexed into IP packets over the IP network. A small multiplexing period will create a larger number of

smaller IP aggregate packets. A large multiplexing period will create a smaller number of larger IP

aggregate packets, thus reducing the IP header overhead at the expense of a greater multiplexing

latency.

The configuration of a DNS name instead of an IP address is made in the Peer Address field – just enter a

name instead of an IP address. The term ANY can also be used in this field if the address of the IP

aggregate peer is unknown or variable (and no dynamic DNS name is available). If the term ANY is used

then the authentication field must be used to configure a password that is the same at both ends of the IP



aggregate. The authentication field is a case-sensitive alphanumeric field that is hidden by asterisk

characters when displayed – it must be entered twice when configured. The menu also has fields for

Control TOS, Setup Delay and Setup Idle Time. The Control ToS allows the user to specify the IP ToS field

used for packets in the IP aggregate control protocol – this protocol permanently runs in the background

even if there is no traffic to multiplex. By default the same value as the standard TOS is used. The Setup

Delay and Setup Idle time are designed for use in networks where the ToS in multiplexed traffic is used to

setup bandwidth across a packet switched network. If this bandwidth reservation is not instantaneous

and the network equipment does not buffer outstanding traffic when establishing the circuit, the IP

aggregate can be configured to buffer this traffic for the Setup Delay period. During this period, ICMP

packets with the IP Aggregate TOS are sent to the peer. If no traffic is multiplexed over the aggregate for

the setup idle time, the next traffic to be multiplexed will be subjected to the setup delay time.

The Data Duplication field is a field that is used to configure the simple forward error correction scheme

available for IP aggregates. N.B. when enabled, the bandwidth used by the IP aggregate is increased.

The IP aggregate protocol allows for the synchronization of multiplexer system clocks over the IP

aggregate. An IP aggregate peer can be configured to transfer clock synchronization data (derived from

the local GRX or GTX clock) to its peer. The peer can use this clock synchronization protocol to drive GRX

and/or GTX.

NOTE Implicit routing is not supported across IP aggregates. Multiplexer routes across the IP

aggregate must be configured in the routing table.


Field Options Description Agg to Edit/View Information only Select the IP Aggregate to Edit or View. Description Alphanumeric text Up to 11 characters used to identify the

configuration. This is used in the Connect Using field in the route table to match routes to IP aggregates.

Peer IP Address* Numeric IP address entry as: nnn.nnn.nnn.nnn or text for DNS name

IP address of the IP Aggregate Peer. This may be also be configured via the Domain field. If the IP address of the IP aggregate peer is not known its URL may be configured here instead.

UDP Port 0-65535 The UDP Port number of the IP Aggregate Peer. This must be configured to the same value at each end of the IP aggregate.

Rate 0-10240000 or automatically generated based on the IP CIR

The effective bandwidth of the IP aggregate that is available for multiplexing. This does not include the overhead of IP headers. When configured this Rate also determines the value set for the IP CIR. If a value is entered for Rate and then the user enters a value for IP CIR (discarding the automatically generated value) the Rate will be re-calculated based on the IP CIR.

Permanent, Normal operation Mode Switched Activated only when there is traffic to send.



Field Options Description Agg to Edit/View Information only Select the IP Aggregate to Edit or View. IP CIR Automatically configured

based on the Rate or 0-10240000 0-5121000

The committed information rate required from the IP network to support this IP aggregate. This does include the overhead of IP headers, but can only be used when there is a non-zero multiplexing overhead configured. The IP CIR is automatically calculated based on the value entered for Rate. If a specific IP CIR is entered (discarding the automatically generated value), the Rate will be re-calculated based on the IP CIR. 0 -10240000 – range for high-speed CPU cards 0-5121000 – range for other systems.

TOS 0-FF hex value Hex value relating to network provider's TOS/DSCP scheme. The IP TOS value is used in packets sent on each aggregate allows the IP aggregate network edge nodes to make bandwidth management service decisions based on IP address, UDP port numbers and/or IP TOS value.

Control TOS 0-FF hex value ToS field used for packets in the Vocality IP aggregate control protocol.

Mux Delay 0-1000 milliseconds The packetisation period for multiplexed packets to be sent over the IP aggregate. The larger this value, the more efficient the multiplexing over the IP aggregate is. The smaller the value, the less jitter is introduced over the IP aggregate

Reseq Delay 0-1000 milliseconds The maximum time to wait for out-of-sequence packets. This should be set to the largest expected variation in latency between different paths between the IP aggregate peers across an IP network with multiple paths. Setting this value too high creates unwanted jitter that may affect voice and data quality in networks where IP aggregate packets are lost.

- No clocking calibration information is sent to the peer.

<GRX Clocking calibration information is sent to the peer based on the GRX clock.

Tx Clock

<GTX Clocking calibration information is sent to the peer based on the GTX clock

Setup Delay 0-60000 milliseconds Initial traffic buffering delay to be used over switched aggregates.

Setup Idle Time 0-86400 secs Traffic idle timer after which the next traffic is again subject to the Setup Delay

Data Duplication OFF, ON Control for the simple FEC

Authentication Alphanumeric text Up to 16-character password which must match that of the peer if the “Peer IP Address” field is set to ANY.

*The term ANY can also be used in this field if the address of the IP aggregate peer is unknown or

variable (and no dynamic DNS name is available.



The SYSLOG feature allows the multiplexer to send log messages generated on this slot to an external

server known as a Syslog Daemon. The protocol for sending these messages is described in RFC 3164.

The protocol is run over UDP port 514.

The customer defines the IP address of the Syslog Daemon. If no IP address is specified then no log

messages are sent to the Syslog Daemon. The messages that are sent can also be seen in the diagnostic

log pages. They include a timestamp from the multiplexer indicating when the message was generated

and two sequence numbers. Each trace type (CONNECTION, CONFIGURATION, IP, etc) has its own

sequence range – this is the first sequence number generated. The second is a sequence number for all

messages sent to the Syslog Daemon. These sequence numbers provide the user with an indication as to

whether a log message has been missed. The message format is:

Nodename: Timestamp : (Specific Seq No : Overall Seq No) log message

The Slot number is also put in here.

The Syslog protocol provides a mechanism for each message to be sent with a category and a priority, to

allow facilities such as filtering on the Syslog Daemon. The multiplexer sends all of its messages with a

priority of 6 (Informational). Configuration options are provided to enable categories to be used for each

2.4.9.4 The SYSLOG menu



type of log message. Each log message type can be configured to generate Syslog messages at categories

Local0 through Local7, or not at all (Disabled). For example if a user wants to use the Syslog facility to

monitor only voice port call records, then configure the Call Records category for Local0 and disable the

category for all other traces.

Parameters and options for the SYSLOG menu are shown in the following table.

Field Options Description Daemon Address Numeric IP address

entry as: nnn.nnn.nnn.nnn

IP address of the Syslog daemon

Trace Type Information only Identifies the type of log message.

Local0-Local 7 The category sent for the log type Category

Disabled Log messages are disabled for this trace message type



The ISDN Basic Rate Interface (BRI) Module (68057) presents a single ‘S’-bus interface, or when

supplemented by the 68059 ISDN expansion card, up to four ISDN ‘S’-bus interfaces via the standard 8-

port 8-way RJ45 connector. Ports are wired in parallel in vertical pairs, so ports 1 and 5 represent the

same ‘S’-bus, then 2 and 6, 3 and 7, 4 and 8. This allows single-bearer devices to be connected together

on the same ‘S’-bus. Ports may be used in Terminal Adaptor (TA) mode, when they give the host

unit the ability to dial up a 64K bearer for communication with a peer unit, as the sole aggregate, a

supplementary aggregate or as a backup service for another aggregate port. They may also be used to

present an ISDN network in Network Function Semi (NFS) mode, also in conjunction with a peer

module or a digital voice card in another unit. It is possible to program any combination of TA and NFS on

all 4 ports. The module is compatible with any Euro-ISDN (NET3) or US National ISDN network as

standard. The following menu is only available when an ISDN Module is installed:

PORT

Up to four ISDN BRI ports are available when the 68059 ISDN Expansion Card is fitted to the Module and

more than one module may be fitted in a system at the same time. This field specifies the particular slot

and port to be configured. “ISDN_2ST1” refers to BRI #1 of the module in slot 2.

2.4.9.5 The ISDN menu



MODE

Ports may be operated in either Terminal Adaptor (TA) mode or Network Function Semi (NFS) mode. In

TA mode they present a TE interface and can be used to dial up a switched aggregate connection to

another unit. In NFS mode, ports present an ISDN network with an NT interface and may be used to link

together ISDN terminals over the Vocality network.

The card provides the host with a dual 64K bearer interface and either bearer may be used as a

permanent connection or dialled up in response to bandwidth requests from any tributaries that are

routed over it.

To use the ISDN interface as a 64K backup service to another aggregate, it should be specified as a

secondary route to a normally available primary aggregate (the corresponding unit must, of course, also

have an ISDN Link Interface fitted). If the primary route fails, all connections are then re-routed via the

ISDN interface, which will automatically dial the stored destination number.

This principle may be extended to provide top-up bandwidth on a temporary basis, simply by overbooking

bandwidth on the primary route with the ISDN interface specified as the secondary route. Then, when a

connection cannot be made over the primary route through congestion, the ISDN interface will

automatically be used. The ISDN call will be maintained until all re-routed connections are closed, even if

the primary route becomes free. Next time, the primary route will be used as normal.

LINK MODE

In normal operation the card is configured to Dial On Demand, in which case the ISDN link will be dialled

when the first request for a connection is made, for example by a voice channel or data port which is

routed over the ISDN link (See ROUTING). The ISDN connection will remain up until the last channel

clears its bandwidth request or there is no traffic activity for the configured activity timeout (SYSTEM

menu). It is also possible to specify which end makes the call by setting the other end into Answer mode

(This can be useful for billing purposes).

CALL TIMER

The ISDN service carries a tariff based on call duration. It is therefore advantageous to be able to limit the

maximum duration to prevent excessive call charges. The Call Timer offers the ability to select a

maximum call time after which any ongoing ISDN call is dropped. It may also be set to “Permanent”,

which ensures that the timer never expires and calls stay up permanently.

LINE TYPE AND TEIS

The user must configure the ISDN Link Interface to operate according to the correct service type. “Point to

Point(PP)” mode requires fixed (known) Terminal Endpoint Identifiers (TEIs) to be set for Layer 2 of the

protocol to establish a connection. The number is usually 0 but may be set in the range 0-63. Layer 1 is

2.4.9.5.1 Terminal Adaptor(TA) Mode



activated immediately with or without a call and Layer 2 comes up and stays up. This is useful for fixed

links which use the ISDN network for connectivity.

“Point to Multi Point(PMP)” mode, TEIs are negotiated automatically with the network via a broadcast

channel 127 and assigned a number in the range 64-126. Layer 2 of the protocol is activated by an

exchange of SABME UA (Unnumbered Acknowledge) messages and thereafter by sequentially numbered

messages. This is stimulated by placing a call, which brings up first layer 1 and can take a few seconds to

activate. Once activated, Layers 1 and 2 will stay active until physically disconnected. It is possible

therefore that the first call may fail following line connection, but calls will always succeed thereafter.

ISDN PROTOCOL

The ISDN protocols are programmed into the ISDN Link Interface Card in the factory. See below for the

range of protocols supported.

SPIDS AND LDNS

These are only applicable to ISDN connections in the USA and only therefore appear if the ISDN Link

Interface is fitted with an American software stack. The Service Profile IDentifier (SPID) is a number

assigned by the Local Exchange Carrier (LEC) or ISDN provider when the customer requests an ISDN line.

It allows the network to associate the correct level of functionality with the terminal and also to identify a

unique terminal on a BRI circuit (to which up to 8 may be connected) with the same directory number.

The generic SPID format is comprised of 14 digits which can be divided into the following three

components: a 10 digit telephone number, a 2 digit Sharing Terminal Identifier and a 2 digit Terminal

Identifier (TID). The 10 digit number is the main directory number associated with the terminal and

includes the 3 digit area code. The 2 digit TID differentiates terminals that have the same main number

and the same Sharing Terminal ID. These terminals have the same service profile, which means they

have access to the same services and translations in the ISDN network switch. TID values range from

“01” to “08”, with values assigned in sequential order beginning with “01”. Terminals not sharing the

same main number always use the value “01” by default.

Although the generic SPID format allows for many different combinations of Sharing TID and TID,

configurations that use values other than “0101” may not be available from all ISDN service providers.

Local Directory Number (LDN): Used for call routing, the LDN is associated with a SPID and therefore

with North American BRI interfaces. It is necessary for receiving incoming calls on the second B-channel.

SPID ALLOCATION

SPID Allocation may be performed manually by the user, who simply appends the relevant codes (if

known) to the 10 digit local telephone number. Alternatively, if his ISDN service supports it, the unit offers

an Automatic SPID mode in which only one SPID is supported. The SPID 1 and LDN 1 fields cannot be

entered and if a SPID response is received from the network in response to the first call, the fields are

automatically updated on the menu. A third option – “Auto + SPID guessing” requires the user to enter



the LDN field only. This enables the switch to guess against a likely or similar SPID to reduce the response

time. This mode is recommended.

ANSWER DELAY

The Answer Delay is the delay in milliseconds between the host being presented with an ISDN call, and it

indicating to the network that it can answer that call. It may be required when the host ISDN port is

attached to equipment that is sensitive to the immediate answering of presented calls.

RETRY STRATEGY

The Retry Strategy defines the behaviour in the event of the ISDN call failing.

CLOCK REF

The Clock Ref field allows the user to select either GRX or GTX as the clock reference source for the

module when in network (NFS) mode.

BOD

The BoD settings control the ISDN call management strategy when the secondary routing mode is set to

BoD. The Bandwidth on Demand (BoD) feature continually monitors the level of traffic that is routed

through the ISDN interface, and raises and clears the second bearer as required and configured. The

traffic levels are calculated with a damping factor to avoid unnecessary dial and clear events in bursty

traffic situations. The lower the damping factor the faster the host is to react to changes in traffic patterns

(at the cost of potentially unexpected dial/clear events in bursty networks). When the dampened traffic

level exceeds the dial threshold the second bearer is dialled. Once established, traffic is split between the

two bearers. When both bearers are established and the dampened traffic level drops below the

configured clear threshold, all traffic is routed over the first bearer channel. The second bearer is dropped

if the dampened traffic level remains below the dial threshold for the secondary activity timer.



Some examples of the used of the SPIDs, LDNs and Allocation are given below:

The above mode is used if the SPIDs and LDN values are known. The second fields may be left blank

when only the first SPID entry is required. The SPID format is different for both the Switch Types and the

Local Telecom Provider used, and knowledge of this is required before entry. A SPID code is asserted

around the LDN with examples shown above.

All North American SPID codes tend to use this but the SPID entry requires local knowledge of the

network type as well as the switch, ie two different networks using AT&T switches will have different SPID

codes. Example entries might be as follows: NI <nnnxxxxxxx0101> where nnn = 3 digit area code.

xxxxxxx = 7 digit number.

AT&T <01xxxxxxx0>.

2.4.9.5.1.1 US NI-1, Manual SPID Entry



Only one SPID is supported. The SPID and LDN fields are deleted.

The ISDN Terminal Adaptor is programmed with blank SPID and LDN fields. The SPID/LDN values are not

saved in the configuration.

2.4.9.5.1.2 US NI-1, Automatic SPID Entry



Only one SPID is supported. In this case, SPID guessing requires the user to enter the LDN field only. This

enables the switch to guess against a likely or similar SPID to reduce the response time. This mode is

recommended. The SPID 1 field is set to SPID guessing format with the code above. The ISDN Terminal

Adaptor is programmed as above. The SPID/LDN values are not saved in the Configuration.


Field Options Description PORT ISDN_0ST1… ISDN_XSTY where X = slot number, Y = port

number

TA, Terminal Adaptor mode. The module presents TE interface(s)

MODE

NFS Network Function Semi mode. The module presents NT interface(s)

Dial On Demand, ISDN number dialled on first bandwidth request. Incoming calls also answered.

LINK MODE

Answer Incoming calls answered only.

CALL TIMER 5min, 10mins, 20mins, 1 hour, 2 hours, 5 hours, 10 hours, 24 hours, Permanent

Maximum single call duration. The ISDN call will be terminated when this duration is exceeded.

LINE TYPE PMP, Point-to-multipoint. This is the default for Euro ISDN.

2.4.9.5.1.3 US NI-1, Auto SPID Entry with SPID Guessing



PP Point-to-point. A TEI must be entered in the range 0-63.

TEI AUTO Terminal Endpoint Identifier for information only

ISDN PROTOCOL EURO ISDN, France VN6, NI (National ISDN), ATT 5ESS (Custom), Nortel DMS-100

Country-specific protocols

CLI1, CLI2 Text Entry Text appears as Calling Line Identifier

EN-BLOC, All digits output in dial message DIAL TYPE

EN-BLOC/OVERLAP Digits forwarded when entered by user

Manual, SPID and LDN must be entered by the user.

Automatic, SPID1, LDN1 are displayed automatically when allocated by the network

SPID ALLOCATION

Auto + SPID Guessing

SPID1 Special field Manual : Numeric Entry Automatic: Information only Auto+Guessing: Enter 01010101010101

LDN1 Special field Manual : Numeric Entry Automatic: Information only Auto+Guessing: Numeric Entry

SPID2 Special field Numeric Entry, visible in Manual SPID allocation

LDN2 Special field Numeric Entry, visible in Manual SPID allocation

ANSWER DELAY (ms) 0-5000 Programmable delay from receiving call to answering it.

NORMAL, Minimum 2secs between calls and no more than 10 calls per 30-minute period to the same number

INMARSAT, Only retries after 62 seconds

RETRY STRATEGY

AGGRESSIVE Continual redialing without delay

-, Do not use (or need) a clock reference

<GRX, Clock reference from GRX

CLOCK REF

<GTX Clock reference from GTX

BoD DIAL THRESH (bps)

0-64000 Sets the Bandwidth on Demand dial threshold which determines when the second bearer channel is dialled.

BoD CLEAR THRESH (bps)

0-64000 Sets the Bandwidth on Demand clear threshold which determines when the second bearer channel is dropped.

BoD DAMPING FACTOR (%)

0-99 Sets the Bandwidth on Demand damping factor which is used to calculate traffic levels and hence whether to dial up or drop the second bearer channel.

0-86400 Sets the Bandwidth on Demand activity timer which determines after what time the second bearer is dropped if the dampened traffic level remains below the dial threshold

BoD ACTIVITY TIMER

PERMANENT The second bearer channel is never dropped



In Network Function Semi mode, the D-channel is terminated on the BRI extender card. Connections are

signalled across the Vocality network using the standard Vocality connection signalling protocol. 64kpbs

connections are opened for the B-channel traffic when required. Calls made from devices connected to

the BRI extender card are forwarded across the Vocality network to either another BRI card running in

Network Function Semi mode, or to a PRI interface. Calls made from devices connected to a PRI card can

be forwarded across the Vocality network to a BRI module in Network Function Semi mode. This provides

new network architecture possibilities for ISDN services across Vocality equipment. Note that only basic

call establishment services are provided, and any enhanced services that are typically available on PTT

ISDN networks are not available.

Call routing from the BRI module in Network Function Semi mode will be handled in a similar fashion to

the Vocality voice ports. The CALL ROUTING\DIRECTORY menu is used to set up either a destination BRI

module or a hunt group (n:s:x) for routing the call to its destination card in the Vocality network. Since

the first available bearer is used, the port number is superfluous and should be left as a ‘X’. So, in the

example below when a dial digit ‘9’ is received, the call is automatically routed to the ISDN BRI module in

chassis ‘0’, slot ‘2’:

2.4.9.5.2 Network Function Semi(NFS) Mode



If the call signalling succeeds, then data is carried between the B-channels across the Vocality

network as a 64kbps synchronous data stream. The following parameters are configurable for each

BRI extender card running in network function semi mode:

OPERATING MODE

In NFS operation the card can only be operated in NT mode; its function is to look like an ISDN network.

PROTOCOL

The ISDN protocols are programmed into the ISDN Link Interface Card in the factory. See above for the

range of protocols supported.

SPIDS AND LDNS

Refer to the preceding section on TA operation.

CLIS

The user may enter the text to be used as the Calling Line Identification.



DIAL TYPE

The module generates dialing either EN-BLOC (all digits together in the called number) or OVERLAP, when

digits are still collected until a terminating ‘#’ is entered or the digit collection timeout expires (4 seconds).

The card will accept either form of dialing.



This menu is only available when a Digital Voice card is installed.

NOTE: When an option value is changed, the Digital Voice card is reconfigured causing it to be

unavailable for 10 seconds.

PORT

Within the user interface the channel identifiers X & Y are used to represent the two interfaces (also

marked X & Y on the metalwork) on the 48/60-channel dual digital voice card. On a 24/30-channel card,

this parameter does not appear.

OPERATING MODE

Only Switched mode is supported in this release.

INTERFACE

E1 and T1 are supported in this release.

2.4.9.6 The DIGITAL VOICE menu



PRESENTATION

This controls the presentation of the 4 wire physical interface. When TE is selected the primary rate ISDN

signal is received on pins 1 & 2 and transmitted on pins 4 & 5. When NT is selected the signal is

transmitted on pins 1 & 2 and received on pins 4 & 5.

TX CLK SRC

This parameter selects the source for the Transmit Clock on the Digital Voice card.

PLL REF

This parameter selects the reference for the clocks on the Digital Voice card.

IDLE CODE

This allows the binary pattern for the idle code to be defined. The idle code is transmitted down bearer

timeslots when no call is present.

CRC4

Enables and disables the Cyclic Redundancy Check procedures on the Digital Voice card.

INT TERM

Sets the internal line termination resistance on the Digital Voice card.

SIGNALLING MODE

Sets the signalling mode on the Digital Voice card. Only Common Channel Signalling (CCS) is supported in

this release.

LAYER 2

Allows the unit to be configured as either Master or Slave at layer 2.

TEI

Sets the Terminal Endpoint Identifier.

PROTOCOL

The layer 3 protocol to be implemented.



COMPRESSION

The compression algorithm to be used on calls. Note that this field applies to all voice calls handled on the

interface. A transparent 64kbps codec is used for all data calls.

CPN ROUTING

Calls from an ISDN network that are presented to the digital voice card require a scheme for routing these

calls into the multiplexer network. Since there is no control over which digital voice channel any call is

presented on, there is no concept of fixed mappings for hot-line extension of digital voice channels. All

calls must be auto-map routed or directory routed. The number that is used to do this routing is the

Called Party Number (CPN) that is presented by the ISDN network. CPN ROUTING is permanently enabled

(ON) such that the call routing is done with the CPN value presented by the ISDN network. This

parameter is therefore for information only. Refer to section 2.4.8.3 “Directory” for details.

CLI

CLI presentation allows calls originated from the multiplexer on the digital voice card to present a calling

line identifier value. When the feature is set to AUTOMAP, the CLI presented is made up of the

node/slot/channel of the multiplexer port that originated the voice call in the multiplexer network. The

number is formatted according to the digit counts that are configured in the AUTO MAPPING menu. For

example, if the auto mapping settings have a single digit defined for node, slot and channel, and a call is

made from 1:2:3, the CLI presented in the outgoing digital voice call is “123”. If the auto mapping

settings have a single digit allocated for node and slot, but two digits allocated for the channel, then the

same call will generate a CLI of “1203”. If the configured digit counts are not big enough for the originated

port identifier, then no CLI is presented in the outgoing call. When the CLI feature is configured to OFF, no

CLI is presented on calls to the ISDN network.

DIAL PARAMETERS

This allows access to the “Dial Parameters” Menu. See section 2.4.9.6.1, “The DIAL PARAMETERS menu”.



The menu above is only available when a Digital Voice card is installed in T1 mode. The variances from E1

mode are described below:

FRAMING

Selects the superframe mode on the Digital Voice card.

LINE BUILD OUT

Defines the gain setting for the transmit pulse shape according to the application.

The overall parameters and options are shown in the following table:

Field Options Description PORT sX, sY Interface identifier, where s=slot number. Not

displayed on single-span digital voice cards. OPERATING MODE

Switching Only Switching mode is supported in this release.

INTERFACE E1, T1 Identifies the type of interface installed.

TE The UTP port is configured as a TE PRESENTATION

NT The UTP port is configured as an NT

Rxc The Transmit Clock reference can be set to the received clock.

TX CLK REF

Int The Transmit Clock reference can be set to the internal clock generated from a PLL.

PLL REF NONE There is no reference clock for the PLL.



Field Options Description GRXCLK The GRX clock is the reference for the PLL

GTXCLK The GTX clock is the reference for the PLL

IDLE CODE 00000000 to 11111111

Binary coded field, MSB first

CRC4 Enable, Disable Enables and disables the Cyclic Redundancy Check procedures on the Digital Voice card - E1 only

INT TERM 75 Ohm, 100 Ohm, 120 Ohm

Sets the internal line termination resistance on the Digital Voice card

D4 Superframe (12 frames/multiframe) structure FRAMING (T1 ONLY) ESF Extended Superframe (24 frames/multiframe)

SIGNALLING MODE

CCS Sets the signally mode on the Digital Voice card. Only CCS is supported in this release - E1 only

LINE BUILD OUT (T1 ONLY)

DSX-1 0 to 133Ft, DSX-1 133 to 266Ft, DSX-1 266 to 399Ft, DSX-1 399 to 533Ft, DSX-1 533 to 655Ft, CSU 7.5 dB, CSU 15 dB, CSU 22.5 dB

Short haul TX gain settings Long-haul TX gain settings

SIGNALLING MODE

CCS Common Channel Signalling available only

LAYER 2 Master, Slave Allows the unit to be configured as either Master or Slave at layer 2

TEI 0 - 63 Sets the Terminal Endpoint Identifier

ETSI(DSS1) The layer 3 protocol to be emulated on the digital voice card

QSIG ETSI The layer 3 protocol to be emulated on the digital voice card

QSIG ISO/ECMA The layer 3 protocol to be emulated on the digital voice card

Cornet-N The layer 3 protocol to be emulated on the digital voice card

National ISDN The layer 3 protocol to be emulated in T1 mode

Lucent 4ESS The layer 3 protocol to be emulated in T1 mode

Lucent 5ESS The layer 3 protocol to be emulated in T1 mode

PROTOCOL

Nortel DMA-100 The layer 3 protocol to be emulated in T1 mode

Off Channel not used

G.711-A 64K PCM coded voice

G.711-u 64K PCM coded voice

G.726 16K ADPCM coded voice




G.727 16K E-ADPCM coded voice

G.727 24/16K E-ADPCM coded voice with asymmetric bit rate TX/RX







COMPRESSION




Field Options Description G.723.1 5.3K ML-PLQ compressed voice

G.723.1 6.3K ML-PLQ compressed voice

G.729A 8K CELP compressed voice

Transp. 64K Raw PCM sampled voice

NetCode 6.4K Proprietary CELP compressed voice


NetCode 8K Proprietary CELP compressed voice NetCode 8.8K, Proprietary CELP compressed voice


CPN ROUTING On The call routing is done with the CPN value presented from the ISDN network. See the section CPN ROUTING above for more information

AUTOMAP Calling line Id is enabled and automapped according to the digit counts configured in the AUTO Mapping menu. See the section CLI above for more information

CLI

Off Calling line Id is disabled

DIAL PARAMETERS

Select the DIAL PARAMETERS menu. See Section 2.4.9.6.1

Within the user interface, the channel identifiers X & Y are used to represent the two interfaces (also

marked X & Y on the metalwork) on a dual digital voice card.

n:s:X is interface X on slot s in node n. n:s:Y is interface Y on slot s in node n.

These interface identifiers can be used to route calls directly (i.e. not via a configured hunt group) to an

interface on the dual digital voice card.

Note that the internal channel definition for channel X has had to be changed for dual digital voice

operation. Channel X is now designated as channel number 979 – it was previously 0 – this channel

number has changed for older single digital voice cards as well. Other units that need to route calls

directly to n:s:X on a dual digital voice card will need to be running a software version greater than or

equal to the version that first includes dual digital voice functionality. Similarly newer versions that route

calls directly to old single digital voice interfaces will need to ensure that the system with the old digital

voice interface is running a software with this channel number change. Note that if calls are routed via

configured hunt groups instead of via the automatic hunt groups X & Y then there is no backward

compatibility issue here. Channel Y is now designated as channel number 978.

Note also that there is no shortcut to allow auto-mapping to work directly to the digital voice interfaces

(you could previously use channel 0 to do this). The only way for auto-mapping to work directly to the

interface is to assign a 3 digit channel mapping and use the numbers 978 & 979 to route the calls.

Alternatively use configured hunt groups.

The single interface digital voice card uses channels 1-30 to represent the voice & data call endpoints on

the digital voice interface. The dual digital voice interface operates on the standard CPU card, and these

channel numbers are already assigned for other uses. The following channels are therefore assigned to

represent the voice & data call endpoints:



Interface X: Channels 101-130 Interface Y: Channels 201-230

These channel numbers are required for configured hunt group operation and appear in the connection

trace logs.

There is no automatic configuration to allow a call to be routed to either interface X or interface Y. To

allow this, a hunt group entry must be configured. The hunt group should contain the members n:s:101-

130 and n:s:201-230.

There is a limitation on the hardware architecture of the dual digital voice card that means that the two

interfaces must share a common clock configuration. Therefore the TX CLK SOURCE and PLL REF

parameters are common between the two interfaces on the same card. When one of these parameters is

changed for interface X, the parameter is automatically changed for interface Y. Similarly, when one of

these parameters is changed for interface Y, the parameter is automatically changed for interface X.

Either interface X or interface Y may be configured as the source for either of the system reference clocks.

If the SOURCE TYPE is set to E1/T1/J1, both interfaces appear in the configuration list for the SOURCE

CLOCK.

2.4.9.6.1 The DIAL PARAMETERS menu




Field Options Description PORT 1, 2 Digital Voice span identifier. Fixed at 1 on a single-

span card, selectable on a Dual-span card DTMF DTMF signalling passed. All relays enabled

V.22 As DTMF, but only V.22 data modem relay enabled

RELAY TYPE

Trans All signalling passed in-band. All relays disabled

TONE LEVEL -31 to +3dBm Sets the level (or loudness) of the generated tone

TONE TWIST -4 to 0dBM Sets the twist (the difference in amplitude between the two tones) of the generated dual tone

TONE PERIOD 50 to 1000 ms Sets the period in milliseconds for which a tone is applied

SILENCE PERIOD 20 to 500 ms Sets the length of the silent period in milliseconds between tone pairs

TONES OFF The digital voice interface does not generate call progress tones on calls presented on the interface - in this case it is expected that the ISDN network equipment generates any tones back to the caller

PROGRESS TONES

TONES ON To be used when the ISDN network equipment does not support progress tone generation itself. The digital voice interface generates call progress tones on calls presented on the interface

INPUT GAIN -31dB to +31dB, MUTE

Gain applied to calls in the input direction

OUTPUT GAIN -31dB to +31dB, MUTE

Gain applied to calls in the output direction

Enabled DTMF tones are sent across the network in the signalling path and regenerated at the target voice port

DTMF RELAY

Disabled Tones are sent across the network in the compressed voice path

SENDING COMPLETE*

SEND, DON’T SEND The “SENDING COMPLETE” information element will be sent/not sent in outgoing SETUP messages

* The Sending Complete information element is an optional information element which, if sent in an

outgoing SETUP message, indicates to the remote receiving device that the call routing information

(dialled digits) is complete and no further information will be sent.

The Sending complete information element is supported in all the European protocols the Vocality

multiplexers support (ETSI DSS1, QSIG ETSI, QSIG ISO/ECMA and CORNET-N).



The TDM menu provides access to two further sub-menus for the detailed configuration of timeslots on

each one of the ports available on this slot. TDM functionality is available on any data port in the system,

subject to the restrictions noted in Section 4.14.2. TDM configuration is always available for all ports on

which TDM is supported, regardless of whether TDM Format has been selected in the DATA menu.

2.4.9.7 The TDM menu



This menu configures the Timeslots on each Port.


Field Options Description CHANNEL Node:Slot The Channel/Port being configured

TIMESLOTS Information only The Maximum Number of Timeslots supported. Set to 16 if using TDM on this port, 0 otherwise

<NEXT TDM> Space bar only Select using the space-bar to move on to the next TDM port

TRANSMIT TIMESLOTS*

TOTAL The total Transmit or Receive bandwidth configured. It is the total of each timeslot’s Actual Bandwidth in bits/sec. Under some situations it is valid for this to exceed the TDM port’s line-speed: for example, if DBA is being used; or if multiple Voice channels are present, not all of which may be used at the same time. Note that DBA-Ctrl timeslots are not included in this total since the bandwidth they use is stolen.

TS 0 to 15 The ID of the Timeslot

CBR, Constant Bit-Rate traffic

CBR-DBA, CBR with Dynamic Bandwidth Allocation

Voice, Use for voice-only traffic (no relays) ModemFax, Use for voice traffic with Modem/Fax relay support

2.4.9.7.1 The TDM Timeslots menu



SVR, Use for voice traffic with Modem/Fax/SVR relay support

Packet, Use for packetized traffic: Aysnc, Serial-NRZ/NRZI, Test Ports

Pack-DBA, Use for packetized traffic where DBA is in use IP-DBA, This uses the same techniques as Pack-DBA but

has more (configurable) local buffering to handle the bursty nature of Internet traffic

DBA-Ctrl Dedicated Bandwidth control timeslot

PCBR This is the underlying mode which is used in Voice mode.

PCBR-CRC This is the same as PCBR except a two-byte CRC is added to each frame. Thus, corrupted data will be discarded.

Relay This is the underlying mode which is used in ModemFax and SVR modes. It may be selected explicitly. If selected explicitly, then the user should specify the data rate to INCLUDE any overhead.

Underlying Types

Pack-IP This is the underlying mode which is used in IP-DBA mode.

DESTINATION n:s:c, Standard Node:Slot:Channel address

P:s:c Peer node:Slot:Channel

L:s:c Local node:Slot:Channel

n:TP:c, Specify a Test Port (normally Packet type)

n:SG:c, n:SG:X

Specify a particular SIP Gateway, Specify any SIP Gateway

n:CG:c Specify a CallGen port

BRDn For example BRD2- if the Timeslot is to carry traffic from Broadcast multiplex 2

PATTERN The timeslot will carry a simple incrementing pattern

REMOTE The timeslot will be used to carry Remote Management traffic

=, +, blank Special editing keys, see notes below

PAYLOAD** Numeric, 0, 400-2046400 (modulo 400)

The amount of Payload which this timeslot will carry, excluding overhead in Bits per second

ACTUAL*** Information only The actual amount of bandwidth used by this Timeslot, including the timeslot’s overhead

RECEIVE TIMESLOTS as TRANSMIT TIMESLOTS

*There is no explicit correlation between Transmit and Receive Timeslots. However in the interests of

simplicity, most users will use the same timeslot for traffic to/from the same destination.

**PAYLOAD: This is normally set to the corresponding Trib’s normal data size. For example, if using a 64K

G711 codec, then set this field to 64000; or if using a 128000 Sync Trib, then set it to 128000. If this field

is set to 0, then the Timeslot is not used.

***ACTUAL: The actual amount of bandwidth used by this Timeslot, including the timeslot’s overhead,

measured in bits/sec.. The amount of overhead required varies depending upon the type of traffic being

carried.



Note that a particular BRDn circuit will normally only ever be specified in the transmit or receive direction

– never both-ways.

Note that hunt groups will never be specified here – the interpretation of Hunt-group to a destination

N:S:C is performed at a higher level than the TDM. The TDM deals with actual addresses.

PATTERN: An incrementing pattern is generated which will be validated at the Peer – the results of this

can be displayed using TDM RXSLOT Diagnostic Command. This provides a simple BERT-type test which

can be used to check the integrity of a connection. PATTERN traffic should normally use the CBR timeslot

type.

REMOTE: The timeslot will be used to carry Remote Management traffic (for access to the menus on a

remote unit). REMOTE should normally use the Packet-DBA timeslot type. If no REMOTE timeslot is

specified, Remote Management traffic will use the “Dynamic” area of the frame.

P : Rather than specify a particular node number, it is possible to use the P (Peer) option to specify a

generic peer node number, to whose specified slot and channel the timeslot payload will be directed.

Thus, if a number of identically configured remotes exist, which are redeployed from time to time to

reappear on a different TDM port, no further configuration changes are needed. The actual node number

used will be learned by the implicit routing function when the TDM aggregate comes up.

L : In a similar way the Local node ID may be specified when defining received timeslots, such that data

from a particular timeslot is always received on the local port corresponding to the specified channel,

irrespective of which node it may be coming from.

= : Instructs the menu to duplicate this timeslot’s configuration from the other direction. This may be

entered for transmit or receive timeslots. If the TX Destination includes a Node (Chassis) Id, then it is

overwritten with “P” for the Peer Chassis number; If the RX Destination includes a Node (Chassis) Id, then

it is overwritten with “L” for the Local Chassis number. For example, say receive timeslot 5 is mapped to

6:7:8; if “=” is entered for transmit timeslot 5, then transmit timeslot 5 will be set to “P:7:8”. Note that

BRDn values are not duplicated. Note: this option is provided as a short-cut to make creation of configs

easier. Often the equipment at each end of the link will be symmetrical in which case the values

automatically entered will be usable; alternatively the Destination field may need to be edited.

+ : Incrementing copy: copies the configuration of the previous row (transmit or receive), incrementing

the value of the Port by 1. + is not supported on the first row.

(Blank): Data will never be sent on a timeslot if it’s Destination field is blank, except for the special case

of DBA-Ctrl timeslots, which implicitly carry traffic between each end of the TDM and do not need a

destination to be specified.

2.4.9.7.1.1 Destination Specifics



2.4.9.7.2 Timeslot Types

CBR-DBA (Constant Bit-Rate with Dynamic Bandwidth Allocation)

Timeslot Overhead: zero CRC: none Error Extension: none Notes: This is used to carry CBR-type serial port traffic with automatic negotiation of the Timeslot size when DBA-negotiation occurs. The Payload in this case is the maximum which the TDM will assign to this timeslot. The Trib must also be configured with a maximum bandwidth, as for conventional aggregates. The Timeslot Payload should normally be configured to the same as configured against the Trib. (Note also that trib-to-trib bandwidth negotiation does not intelligently use the value configured here: if the trib-to-trib negotiates a higher value than that configured against the timeslot then data will be lost). Note that data will be lost whenever a rate-change occurs. DBA Trib channel speeds must be symmetric (i.e. the same in both directions). A DBA-Ctrl channel must be configured in each direction for CBR-DBA to function correctly. Unused bandwidth is recycled in the Dynamic Area (used by Type “Packet”).

Voice

Timeslot Overhead: zero CRC: none Error Extension: none Notes: Carries Voice Traffic in a highly efficient manner. This is NOT suitable for Fax/Modem/SVR calls. (Uses the underlying PCBR type)



ModemFax

Timeslot Overhead: 2400 bits/sec more than payload CRC: yes Error Extension: may occur Notes: Carries Voice, Modem, and Fax traffic (Uses the underlying “Relay” type). Note that when Modem and Fax calls are made, additional overhead is required.

SVR (Secure Voice Relay)

Timeslot Overhead: 3600 bits/sec more than payload CRC: yes Error Extension: may occur Notes: Carries Voice, Modem, Fax, and SVR traffic. Similar to ModemFax, but SVR requires more overhead. (Uses the underlying “Relay” type with additional overhead)

Packet

Timeslot Overhead: Variable depending on nature of traffic. If single packet being carried, then 2800 bits/sec more than payload. The overhead budgeted is configurable in the TDM Advanced Config.

CRC: yes Error Extension: may occur since the data is protected by a CRC. Notes: Carries packet-oriented data. Use for: Aysnc, Serial-NRZ/NRZI. Supports fragmentation: one buffer may be split over multiple frames; one frame may carry multiple messages (or message fragments). Data is protected by a CRC. The “Packet” type can be used for IP but for IP the timeslot type would normally be IP-DBA.



DBA-Ctrl (Dynamic Bandwidth Allocation control channel).

Control channel for CBR-DBA channels. This is used to negotiate changes in bandwidth assigned to CBR-DBA and Packet-DBA channels. When a DBA speed-change occurs, this channel “steals” bandwidth from the circuit which is being negotiated. It is necessary to specify a timeslot size here so that both ends agree. No destination need be configured. If used, this should normally be one of the first timeslots (to ensure that it has priority of transmission). A bandwidth of at least 4800 is recommended. Note that bandwidth allocated to DBA-Ctrl timeslots are not included in bandwidth total since the bandwidth they use is “stolen”.

IP-DBA (Packet with Dynamic Bandwidth Allocation, tuned for IP traffic)


CRC: yes Error Extension: may occur since the data is protected by a CRC. Notes: As for Pack-DBA but this is tuned to handle the bursty nature of IP traffic. It has a larger transmit queue size, which is configurable in the Advanced Config menu.

Pack-DBA (Packet with Dynamic Bandwidth Allocation).


CRC: yes Error Extension: may occur since the data is protected by a CRC. Notes: As for Packet, but with automatic DBA negotiation of the bandwidth to be used. The Payload in this case is the maximum which the TDM will assign to this timeslot. Note that the Trib must also be configured with a maximum bandwidth, as for conventional aggregates. The Timeslot Payload should normally be configured to the same as configured against the Trib. (Note also that trib-to-trib bandwidth negotiation does not intelligently use the value configured here. If the trib-to-trib negotiates a higher value than that configured against the timeslot then data will be lost). The “Packet-DBA” type is suitable for NRZ-Tribs with DBA, or Test Ports. It may be used for IP traffic, but IP would normally use IP-DBA. Data is protected by a CRC. A DBA-Ctrl channel must be configured in each direction for CBR-DBA to function.



The following (shown greyed out) are the fundamental underlying packet types, which should

only be used with knowledge of the format of the expected traffic:

PCBR-CRC

Timeslot Overhead: 800 bits/sec. CRC: yes Error Extension: may occur Notes: This is the same as PCBR except a two-byte CRC is added to each frame. Thus, corrupted data will be discarded.

Relay

Timeslot Overhead: none included – but the user should make allowance. CRC: yes Error Extension: may occur Notes: This is the underlying mode which is used in ModemFax and SVR modes. It may be selected explicitly. If selected explicitly, then the user should specify the data rate to INCLUDE any overhead.

Pack-IP (Packet with queue size tuned for IP traffic)


CRC: yes Error Extension: may occur since the data is protected by a CRC. Notes: As for Packet but this is tuned to handle the bursty nature of IP traffic. It has a larger transmit queue size, which is configurable in the Advanced Config. (This option would not normally be used: IP traffic should normally use IP-DBA since IP-Trib connections are implicitly DBA)

PCBR

Timeslot Overhead: zero. CRC: none Error Extension: none Notes: This is the underlying mode which is used in Voice mode. It may be selected explicitly.



This section lists the various types of call within the Vocality product range and indicates the type of

timeslot to use. (Note that all types may also be routed via the dynamic area – if a timeslot is not

explicitly set-up).

Serial Data: - Format Sync: CBR or CBR-DBA (the data consists of a continuous stream of data) - Format NRZ or NRZI: Packet or Pack-DBA. (the data is packet-oriented and must be CRC-

Protected) - Format Async: Packet or Pack-DBA

IP: - Usually IP-DBA.

Analogue Voice call types (from FXO, FXS):

- Use Voice, ModemFax or SVR depending on type of voice calls being carried. Note that TDM Timeslots do not support Codec-Negotiation: the timeslot size configured must match the configured codec. If codec-negotiation is happening, then do not assign a timeslot (instead, let the calls use the dynamic area). G723 5.3k and G723 6.3k codecs are not supported: TDM timeslots require data-rates of precise multiples of 400 bits/sec.

ISDN-PRI:

- PRI does have access to codecs . For voice calls, the codec to be used is configured in the COMPRESSION option in the DIGITAL VOICE menu. The TDM timeslot should be set to be compatible with this in a similar fashion to Analogue Voice. If ISDN DATA calls are being used, then use CBR/64000. If it is not possible to predict the type of traffic (i.e. there is a mixture of Data and Voice calls) then it is not suitable for TDM timeslots (instead, let the calls use the dynamic area)

ISDN-BRI:

- Always use CBR at 64000 (for both Speech/3k1 audio and Data traffic). Note that there are no codecs available for BRI calls.

REMOTE management:

- Normally should be Packet-DBA. Set speed to 9600. Packet may be used if do not wish to configure a DBA-Ctrl timeslot. If other DBA connections are in use on the TDM, recommend that don’t assign a timeslot (so that Remote connections use the dynamic area). This is because it is not as bandwidth efficient.

Test Ports:

- Pack-DBA should be used since these are inherently “DBA” – the bandwidth allocated to them will vary. (“Packet” type will often be OK. However on a fully-booked connection the bandwidth allocated to Test Ports will vary).

2.4.9.7.2.1 Selecting The Best Packet Type



This menu allows the configuration of certain advanced TDM parameters. Each parameter applies only to

the port in question. The default settings should normally be used.


Field Options Description CHANNEL Node:Slot The Channel/Port being configured.

<NEXT TDM> Space bar only Select using the space-bar to move on to the next TDM port.

DUPLEX, DUPLEX should normally be used. This makes use of two-way negotiation to establish the connection

TDM MODE

SIMPLEX Use if Radio-silence is required. Both ends of the link must be set the same.

OFF, Normal setting. DATA STREAM INVERSION

INVERTED Used when running a TDM aggregate as a Tributary over another TDM. One of the TDMs should be configured as OFF, the other as INVERTED.

CONFIGURED OVERHEAD (TX), CONFIGURED OVERHEAD (RX)

0-2048000bps Reserves additional overhead in the transmit or receive direction respectively. This “additional overhead” reserves space in the Dynamic area of the TDM frame.

PACKET TIMESLOT OVERHEAD*

0-2048000bps The overhead to calculate for Packet (and Pack-DBA) timeslots.

2.4.9.7.3 The TDM Advanced Config menu



SEND,

All Broadcast data will be sent over the TDM’s dynamic area if no transmit timeslot is explicitly assigned to it.

SEND BROADCAST MESSAGES VIA DYNAMIC

DISCARD Broadcast data will only be sent over the TDM if a timeslot is explicitly allocated.

MAX TX FRAMES IN TRANSIT

Numeric This determines the size of the transmit Jitter buffer on the TDM port. Set to the number of frames in transmit. The default value of 2 should normally be suitable. This value may need to be increased under certain loading conditions.

IP-DBA/Pack-IP queue limit (frames)

2 - 1000 This determines the amount of transmit data which may be buffered for IP-DBA and Pack-IP timeslots on this port. It is measured in frames (50 frames are sent per second). Thus, a value of 100 will permit a maximum of 2 seconds of data to be buffered.

*Packet Timeslot Overhead: The default value of 2800 will normally be fine. However, if the traffic

includes a large number of small packets then more overhead may need to be budgeted. Note that this

parameter only affects Packet/Pack-DBA/IP-DBA/Pack-IP traffic when routed via Timeslots, not via the

Dynamic area.

Under certain operational conditions it may be desirable to operate a TDM aggregate stream in one

direction only. This requires the transmitting end to override the normal bidirectional synchronization

handshakes and to start transmission irrespective of a return channel. Any receiving stations are able to

acquire and synchronise to the bitstream at any time. The synchronization pattern is cyclically repeated to

allow this to happen.

To implement Radio Silence Mode, configure the TDM at all stations to run in SIMPLEX Mode as above.

Any tributary circuits which are required to operate in Radio Silence Mode should be configured as

Broadcast (BRD) Channels.

Radio Silence Mode cannot be used over conventional aggregates since they require bi-directional comms.

2.4.9.7.3.1 Radio Silence mode



See Section 3.2 for information on the Diagnostics menus.

2.4.9.8 The DIAGNOSTICS menu



The SNMP menus define the configuration of the embedded SNMP agent in the unit. This allows

monitoring of the system operation via the SNMP V2/V3 protocols as defined in RFC 1442.

NOTE: SNMP Requires a Feature Key on all products except the V200.

2.4.9.9 The SNMP menu




These configuration parameters control which versions of SNMP are to be used and the security settings

that apply.

Field Options Description Yes SNMPv3 messages are to be handled SNMPV3

ENABLED No All SNMPv3 transactions will fail - they will be silently ignored

Yes SNMPv1 and SNMPv2c messages are to be handled SNMPV1V2C ENABLED No All SNMPv1 and SNMPv2c transactions will fail -

they will be silently ignored Received SNMPv3 messages must match this

security level precisely. This field also determines the security level used for all Trap messages transmitted

NoAuthNoPriv The security level to use for all SNMPv3 messages -no authentication and no privacy

AuthNoPriv The security level to use for all SNMPv3 messages -authentication but no privacy

V3 SEC LEVEL

AuthPriv The security level to use for all SNMPv3 messages - authentication and privacy

V3 AUTH PROTOCOL

MD5, SHA1 Select the Authentication Protocol to be used for all SNMPv3 messages This field is only used if V3 SEC LEVEL is AuthNoPriv or AuthPriv

2.4.9.9.1 The SNMP GENERAL menu



Field Options Description V3 PRIVACY PROTOCOL

DES The privacy protocol to be used if V3 SEC LEVEL is AuthPriv

V1/V2C COMMUNITY NAME

Public Alphanumeric string

The Community Name for SNMPv1/v2c Alphanumeric with upper and lower case letters

NOTE: Changes to these fields require the unit to be rebooted in order for them to be applied. A message

is displayed when this is necessary.


If SNMPV3 is configured and authentication and/or privacy is enabled, then the multiplexer must be

configured with the correct keys. The keys should match the settings on the SNMP server.

Field Options Description V3 AUTH PASSWORD

8-30 characters Sets the local authentication password.

V3 PRIVACY PASSWORD

8-30 characters Sets the local privacy password

No keys generated Keys have not been generated and saved.

Keys invalid - Engine-ID mismatch

the Engine-ID used to generate the keys is different to that of the unit

PROGRESS

Compatible keys exist Keys exist which were generated using this unit’s Engine-ID

2.4.9.9.2 The SNMP KEYS menu




The SNMP Target Table specifies the destinations for traps, along with the format in which they are to be

sent. SNMPv1 and v2c messages will only be accepted if their source address is in this table.

The number of entries in this table is limited to six. This allows support for four different Trap Destinations

and also allows room for multiple IP address masks to restrict SNMPV2c access.

Field Options Description Description 16 alphanumeric

characters Description of the entry.

IP ADDRESS Numeric IP address entry as: nnn.nnn.nnn.nnn

IP address of the destination of the traps. Also used in conjunction with the Mask to specify the valid sources of SNMPv2c (and SNMPv1) messages which the Vocality unit will accept. Note that no such restriction is placed upon the source of SNMPv3 messages – this is in conformance with the SNMPv3 recommendations

MASK Numeric IP mask entry as: nnn:nnn:nnn:nnn

Mask used in conjunction with the IP address field to specify the valid sources of SNMPv2c and SNMPv1 messages.

SRC Yes, No If set to Yes SNMPv2c (and SNMPv1) messages from the IP Address/Mask combination will be handled

TRAP Yes, No Enables or disables this IP address as a destination for SNMP traps

2.4.9.9.3 The SNMP TARGET TABLE menu



Field Options Description TRAPVER V2C, V3 The version of SNMP to use to send Traps to this

destination – SNMPV2c or SNMPV3.


This menu provides the option of individually enabling/disabling the generation of each type of trap.

NOTE: On the V200 and V150, CPU Cards operating as SLOT-0 display all possible traps – both

Vocality and MIB-2/SNMP Standard Traps. However, for SNMP agent CPU Cards functioning as

line-cards, only the COLDSTART trap is displayed. All other traps are generated through the

SNMP client on slot 0.

Note SNMP Standard Authentication Failure traps are never generated.

Trap statistics are displayed on the SNMP STATS menu screen in the DIAGNOSTICS menu. The actual

traps that can be generated on a unit depend on the hardware and the configuration of the unit. The

complete list of all possible traps is provided in section 3.2.10, “The LOGS menu” and sub-sections.

2.4.9.9.4 The SNMP TRAP CONFIGURATIONS menu



This menu is used to display and manage the application software which is present on the Compact Flash

on the Slot 0 CPU card and distributed to the rest of the cards in the chassis. The card can store a large

number of files which allows the user freedom to load the one most appropriate to his particular

application and to keep previous versions for reference/backup. It also provides a fail-safe method for

upgrading the unit as the previous version is retained and can be restored in the event of a problem. The

version name uniquely identifies each application version as it was distributed by Vocality International Ltd

and each version is given an Attribute which is used to specify how it is used. For each version present,

one may be identified as primary, one as secondary and one as upgrade. The primary and secondary files

must be different. The upgrade file may also be primary or secondary. For details of the upgrade process

refer to the appropriate Hardware Guide.

When a unit is booted, it first tries to find an UPGRADE file. If one is found, the UPGRADE attribute is

removed and the file is loaded. Note that if the loading fails, then the subsequent load should find another

file. If no UPGRADE file is found, a PRIMARY file is loaded. If no PRIMARY file is found, a SECONDARY file

is loaded. If no SECONDARY file is found, the most current file is loaded. If no application can be found,

then a command line kernel is entered – disaster recovery operations can be controlled via this command

line kernel. Contact Vocality International in this event.

VERSION

Shows the software version of the files stored.

2.4.10 The SOFTWARE MANAGEMENT menu



ATTRIBUTES

Sets the software application file’s attribute. This may be Primary, Secondary, or blank.When a new

version is downloaded to the unit it is displayed with the Upgrade attribute.

CREATED

Shows the date and time when the software application was created by Vocality International Ltd.

LOADED

Shows when the software application was loaded on to the multiplexer.

TFTP SERVER

The IP address of the TFTP Server used to upgrade the software application. See the appropriate

Hardware Guide for information on upgrading the application software.

UPGRADE VERSION

Shows the software version of the application being loaded on to the multiplexer. This must be the prefix

of the file being upgraded. For example, if the file on the TFTP Server is named V04_01_01.APL, the

Upgrade Version field must be V04_01_01.

OPERATION

Starts the upgrade of the software application specified in ‘Upgrade Version’ on the TFTP Server specified

in ‘TFTP SERVER’ to the multiplexer.

STATUS

Shows the status of the software application upgrade.



This screen provides information about the cards installed in each of the ten slots and the serial number

and hardware revision of the backplane (BP).

BAY

Shows the bays A-J and the backplane (BP).

2.4.11 The SLOT MANAGEMENT menu

A B C D E F G H I J



SLOT

By default, bay A is mapped to slot 0, bay B to slot 1, and so on. However, the mapping between a bay

and a slot may be changed. This is usually done to configure a redundant (backup) card. See the example

below.

FUNCTION

A card is normally set as Primary. However, redundancy can be configured: If there is an identical card

installed in the V200/V150 and both cards have been configured to use the same slot, one card must be

configured as Secondary. NOTE: Secondary should not be configured except when redundancy is

configured.

STATE

The State shows whether the bay is empty, or, if a card is installed, whether it is ACTIVE or OFF.

CARD TYPE

This shows the type of card installed in the bay, or ‘empty’ if no card is installed. If a bay is empty it is

possible to preselect from a range of options using the space bar to select. The selected card appears in

parentheses and may be stored using the normal procedure. From this point onwards the phantom card

appears in menus as if it were present and allows the user to preconfigure its functionality, ready for when

the real card is plugged in.

REV

The hardware revision of the card or backplane.

SER NUM

The serial number of the card or backplane.

OPERATION

The default operation is NONE. However, if a card is in state OFF, the operation can be set to RESTART.

The V200/V150 then attempts to make the card ACTIVE. If a card is ACTIVE, the operation can be set to

SHUTDOWN. This causes the multiplexer to turn off the specified card. NOTE: An attempt to

SHUTDOWN an ACTIVE CPU card which does not have a Secondary CPU card configured on the

same slot number will fail. In the example, there are similar cards in bay A and bay D. Both cards have

been configured to use Slot 0, with the CPU card in bay A set as the Primary card for that slot, and the

CPU card in bay D set as the Secondary card for that slot. The multiplexer now has a redundant CPU card

and should the Primary CPU card fail or be shutdown, the Secondary CPU card will become ACTIVE.



NOTE: When two identical cards are configured to use the same slot, one of the cards must be

configured as Primary the other as Secondary. If this is not done, one of the cards will be

turned OFF (see STATE above).



When two CPU cards have been configured for redundancy (see the example in Section 2.4.11), the

Backup Synchronization Menu can be used to ensure both CPU cards are running the same application

software and to ensure all the configuration information is backed up on to the Secondary CPU card.

The Software Status shows that an update is required if the Primary and Secondary CPU cards are

running different versions of software. When the cards are synchronised by selecting ‘Update Now’ the

application software from the Primary CPU card is copied to the Secondary CPU card. This ensures that

should the Primary CPU card fail, the Secondary CPU card will take over and will be running the same

software as the Primary CPU card. By selecting ‘Update Later’ no action is taken at this time.

In a similar way, the Configuration Status shows that an update is required if the Primary and Secondary

CPU cards have different configuration data. This data can also be synchronised, causing the configuration

information to be copied from the Primary CPU card to the Secondary CPU card, thus ensuring the

configuration information is not lost if the Primary CPU card fails.

2.4.12 The BACKUP SYNCHRONIZATION menu



The Alarm Management menus enable the user to control how the multiplexer signals, collects and

manages alarms.

The conditions that can cause alarms and the way alarms can be signalled differ between the products in

the Vocality multiplexer range. The menus presented and the layout of the parameters is customised for

the features available on each product and may therefore not match what is documented here. The

conditions that can cause alarms are split into the following categories: SYSTEM, SERIAL, DATA, IP,

E1/T1/J1.

Two categories of alarms are supported: Major and Minor. The alarm management configuration allows

the user to select which events cause which alarms to be raised, and how those alarms are signalled.

2.4.13 The ALARM MANAGEMENT menu



This menu shows the current alarm events and enables the user to ‘ignore’ or ‘unignore’ current alarms.

In this example, there is currently one major alarm condition present. The IGNORE button allows the user

to ignore the alarm condition. An ignored alarm condition will not generate an alarm signal.

Field Options Description Minor Indicates a current minor alarm.

Major Indicates a current major alarm.

ALARM

When an alarm’s OPERATION is set to ‘IGNORE’, the ALARM field is blank.

SYS A system alarm has occurred.

DATA An alarm has occurred on a serial data port.

IP An alarm has occurred on an IP port.

TYPE

E1/T1/J1 An alarm has occurred on an E1, T1 or J1 port.

SYSTEM START/RESTART

Alarm indicating the multiplexer has been powered up or power-cycled.

REFERENCE CLOCK LOST

Alarm indicating the system reference clock has been lost.

SUPERVISOR SECURITY FAILURE

Alarm indicating a password failure for the menu system.

CARRIER LOSS Alarm indicating the aggregate is lost.

SWITCHED AGG UNEXPECTED DISC

Alarm indicating an unexpected disconnection on a switched aggregate link.

CONDITION

SWITCHED AGG CONNECTION FAIL

Alarm indicating a connection failure on a switched aggregate link.

2.4.13.1 The CURRENT ALARMS menu



Field Options Description ACCESS TABLE VIOLATION

Alarm indicating the password failed during an attempt to log in to the Access Table.

ETHERNET DISCONNECTED

Alarm indicating the Ethernet link was disconnected.

IP AGGREGATE FAILURE

Alarm indicating an IP aggregate failure.

E1/T1/J1 NOS/LOS/RED

Alarm indicating no signal/loss of signal/T1 red alarm.

E1/T1/J1 RAI/AIS/YELLOW/BLUE

Alarm indicating remote alarm indication/alarm indication signal/T1 yellow or blue alarm.

slot:channel Serial data port alarm conditions are reported with the slot:channel that the alarm condition occurred on.

IP aggregate name IP aggregate alarm conditions are reported with the name of the IP aggregate.

IP address IP access violation events are reported with the IP address of the station attempting the bad access.

ENET1 or ENET2 Ethernet failure events are reported with the name of the Ethernet port.

GRX or GTC System reference clock failures are reported with the name of the clock that has failed.

INSTANCE

All other alarm events are reported without a value in the INSTANCE field.

SET The current alarm condition is set

IGNORED The current alarm condition is ignored (see OPERATIONS below)

STATE

LATCHED The current alarm condition has triggered and is configured as a manually cleared alarm.

IGNORE IGNORE an event in the SET or LATCHED state. An ignored alarm will not cause an alarm signal to be generated. The event will remain in the ignored state until the system is restarted or the event is UNIGNORED.

UNIGNORE UNIGNORE an event in the IGNORED state.

OPERATIONS

CLEAR Clear a latched alarm The event is removed from the current list when the event is cleared.



The Alarm Signals menu allows the user to control how Major and Minor alarms are signalled on the unit.

The V200 has separate major and minor alarm relays. The major alarm relay may be configured to signal

major alarms. The minor alarm relay may be configured to signal minor alarms.

The V150 has a single alarm relay. Major and minor alarms can be separately configured to trigger the

relay.

Field Options Description SIGNAL DELAY 0-600 seconds Sets the amounts of time to wait from the first alarm

event to generating the signal. A value of 0 indicates the alarm signal will be generated as soon as the alarm event occurs.

V200 and V150 only

Enabled The alarm relay is turned on when an alarm is signalled and off when an alarm is cleared.

Disabled The relay is not used as part of the alarm signal.

SIGNAL RELAY

Toggle 0-600 seconds

When Toggle is selected, the user can configure a period at which to toggle the alarm relay between on and off states whilst the alarm is signalled. The period may be set between 0 and 600 seconds. When configured to 0 seconds, the relay toggles at the highest rate supported by the system.

2.4.13.2 The ALARM SIGNALS menu



Field Options Description RING 0-60 seconds The alarm causes a bell signal to be sent to the

supervisor port. When RING is configured, the user can configure how often a signal is sent. When 0 seconds is configured, the bell signal is sent almost constantly.

SUPERVISOR BELL

DISABLED No supervisor bell signal is generated when an alarm is generated.

Enabled The front panel alarm LED is used to show an alarm. FRONT PANEL LED Disabled The front panel alarm LED is NOT used to show an

alarm. V200 and V150 only

Disabled The Backup Failover option is disabled.

BACKUP FAILOVER

Failover 0-600 seconds

If a major alarm condition arises, a switchover is forced from the slot reporting the alarm to a backup bay. The switchover only occurs if a backup card is both configured and installed for the reporting slot. The failover is supported on all slots including slot0. The failover delay is independent from the major signal delay. The failover delay is set between 0 and 600 seconds. NOTE If BACKUP FAILOVER is configured on a V200 which generates Major alarms constantly, the V200 may continually switch from one bay to the backup and then back again.

The events menus specify which multiplexer events cause an alarm condition to be raised. When the

Alarm is set to “Off” the condition is ignored and no alarms are generated for that condition. When the

Alarm is set to “Major”, a major alarm event is generated when the condition occurs. When the Alarm is

set to “Minor”, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm

condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition

for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions

that support auto-clearing, the user can configure whether they want the alarm condition to be auto-

cleared. If an event is set to “Manual” clearing, an alarm condition is latched when it occurs, and must be

manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only

have a Clear setting of “Manual”. The Log setting indicates whether changes to the alarm condition are

included in the ALARM LOG. Events may be logged in the alarm log, even if they are not configured to

generate an alarm.

NOTE Each of the events pages show different subsets of conditions which control the alarms.

Although the conditions displayed on each events page are different, the settable options are

the same. The conditions have been put on to different menus to make it easier to find and

configure the various conditions.

2.4.13.3 The SYSTEM EVENTS menu



Field Options Description SYSTEM START/RESTART

Alarm indicating the multiplexer has been powered up or power-cycled

REFERENCE CLOCK LOST

Alarm indicating the system reference clock has been lost

SLOT FAILURE Alarm indicating a slot with a card installed has failed. V200 and V150 only

BACKUP SYNC REQUIRED

Alarm indicating a Backup synchronization is required. See Section 2.4.12 for more information. V200 and V150 only

Condition

SUPERVISOR SECURITY FAILURE

Alarm indicating a password failure for the menu system

Major The alarm has been defined as a Major event

Minor The alarm has been defined as a Minor event

Alarm

Off The event does not cause an alarm

Manual The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically

Clear

Automatic The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically

Enabled The alarm event is written to the Alarm Log Log

Disabled The alarm event is not written to the Alarm Log




Alarm is set to Off the condition is ignored and no alarms are generated for that condition. When the

Alarm is set to Major, a major alarm event is generated when the condition occurs. When the Alarm is set

to Minor, a minor alarm event is generated when the condition occurs. Clear specifies how an alarm

condition is cleared. Some conditions have an automatic clearing event. For example, an alarm condition

for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For conditions

that support auto-clearing, the user can configure whether they want the alarm condition to be auto-

cleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must be

manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may only

have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are


generate an alarm.





2.4.13.4 The SERIAL DATA EVENTS menu



Field Options Description CARRIER LOSS Alarm indicating the aggregate is lost.

SWITCHED AGG UNEXPECTED DISC

Alarm indicating an unexpected disconnection on a switched aggregate link.

Condition

SWITCHED AGG CONNECTION FAIL

Alarm indicating a connection failure on a switched aggregate link.

Major The alarm has been defined as a Major event.

Minor The alarm has been defined as a Minor event.

Alarm

Off The event does not cause an alarm.

Manual The alarm is cleared manually by the user. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically.

Clear

Automatic The alarm is cleared automatically by the system. For example, a carrier loss alarm may be raised and then cleared automatically once the connection has been re-established. Some events may only be cleared manually. other alarms may be configured to be cleared either manually or automatically.

Enabled The alarm event is written to the Alarm Log. Log

Disabled The alarm event is not written to the Alarm Log.




set to “Minor”, a minor alarm event is generated when the condition occurs. “Clear” specifies how an

alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm

condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For

conditions that support auto-clearing, the user can configure whether they want the alarm condition to be

auto-cleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must

be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may

only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are


generate an alarm.





2.4.13.5 The IP EVENTS menu



Field Options Description ACCESS TABLE VIOLATION

Alarm indicating the password failed during an attempt to log in to the Access Table.

ETHERNET DISCONNECTED

Alarm indicating the Ethernet link was disconnected.

Condition

IP AGGREGATE FAILURE

Alarm indicating an IP aggregate failure.



Alarm



Clear









set to “Minor”, a minor alarm event is generated when the condition occurs. “Clear” specifies how an

alarm condition is cleared. Some conditions have an automatic clearing event. For example, an alarm

condition for an Ethernet port disconnecting can be automatically cleared by the port reconnecting. For

conditions that support auto-clearing, the user can configure whether they want the alarm condition to be

auto-cleared. If an event is set to Manual clearing, an alarm condition is latched when it occurs, and must

be manually cleared via the CURRENT ALARMS menu. Conditions that do not support auto-clearing may

only have a Clear setting of Manual. The Log setting indicates whether changes to the alarm condition are


generate an alarm.





2.4.13.6 The E1/T1/J1 EVENTS menu



Field Options Description E1/T1/J1 NOS/LOS/RED

Alarm indicating no signal/loss of signal/T1 red alarm.

Condition

E1/T1/J1 RAI/AIS/YELLOW/BLUE

Alarm indicating remote alarm indication/alarm indication signal/T1 yellow or blue alarm.



Alarm



Clear




This log shows messages relating to events which have occurred and which may be configured to raise

alarm conditions.

2.4.13.7 The ALARM LOG menu



This menu page only exists on Push-Config hosts and allows the user to specify which remote units

(serial number and type) are configured via the Push-Config scheme. It also provides a mechanism for

the user to specify which hardware options are present on the remote unit. A single line on the menu

page is used for each remote unit. The user must specify the node number and node name to use for the

remote unit. The menu page provides a button for accessing the configuration pages for this remote unit.

NOTE: If the hardware options are changed following initial configuration, then the

configuration specific to any hardware options may be lost. A button to add a new remote unit is

provided. There is also an option to remove all remote configurations. A single remote unit may be

removed by typing <Ctrl-D> when the cursor is on the line representing that unit. If more remote units

are added than can be displayed on a single page, then <NEXT PAGE> & <PREV PAGE> buttons are

provided. There is no limit placed on the number of supported remote units.

The configuration is stored on the hub unit and is pushed out to the remote unit when the remote unit

connects to the hub. This connection does not need to be present when the <CONFIGURE> button is

pressed.

Once the hardware information has been entered for a node, use the <CONFIGURE> button to configure

parameters for that remote unit. The example below shows the remote node ‘boston’ being configured via

the <CONFIGURE> button.

2.4.14 The PUSH CONFIG CLIENTS menu



The banner near the top of the screen shows Push-Config is being used to configure the remote node

‘boston’. To complete the configuration of ‘boston’ use the menus provided. Use the appropriate sections

of this manual for more information on the menu option.

See section 4.4, “Push-Config” for more information on this feature.



This Main Menu screen allows the user to log on to any unit in the network, by selecting the “REMOTE”

option. The user is then prompted for the node I.D. number of the unit to be selected, as shown below:

The required node number is then entered, followed by <CR> and the following message then appears:

“Connecting to node N. Please wait…”

If the connection is successful, the menu selection page of the chosen unit is then presented, as if logged

on locally. All menus appear as normal and any data edited and accepted will be stored in the logged

chassis. To return to the local unit, enter <CTRL>&<E> at any time. To configure or monitor a different

unit, return to the local unit (the only location at which the “REMOTE” menu option is provided) and enter

a different node I.D.

If the chosen unit cannot be reached due to, perhaps, a faulty or unconfigured aggregate route, the

following message is displayed:

“Failed to connect to node N. Press any key…”

After pressing a key, the main menu selection page is again displayed. The user can then inspect the local

menus to discover why the chosen remote could not be reached.

2.4.15 The REMOTE menu



WARNING:

During the remote configuration process, it is of course possible to change settings which could result in

loss of carrier to that remote unit. Under these circumstances, unpredictable results may occur. Be

cautious when changing the configuration settings of any remote aggregate ports!

NOTE:

When a remote node is accessed, the connection to the chosen unit requires at least 2400bps of

bandwidth, which must be available throughout the route to that node. If the route already supports a

DBA (Dynamic Bandwidth Allocation) connection, the DBA rate will drop by 2400bps. If not, the

connection to the remote supervisor will itself act as a DBA connection and use as much spare bandwidth

as is available. This process is automatic and ensures that the responses of the remote unit are as rapid

as possible.

C H A P T E R 3 D I A G N O S T I C S


3 Diagnostics Extensive diagnostics facilities are available in all products. They are divided into two categories, Slot-

specific diagnostics and generic diagnostics which are relevant to the whole unit.

3.1 The DIAGNOSTICS menu

The generic Diagnostics menu appears on the MAIN MENU.

Chapter

3



The CLOCK STATUS menu shows several key statistics relating to the two internal clock reference busses,

GRX and GTX (the V25 only has GRX). This page is for information only and has no editable fields. The

statistics shown automatically uodate every 30 seconds but may be updated manually by pressing the

REFRESH STATS softkey. The statistics may be reset using the RESET STATS softkey. For details on

clocking strategies, refer to section Error! Reference source not found..

An entry in the configuration log is made whenever a switch is made between the Primary and Backup

clock sources. On a V150/V200 system this log is generated on both the slot that the clock reference is

on as well as slot0. The following logs are generated when the primary clock source fails for GRX:

000d:00h:05m:59s:17 GRX source rate change to 0

000d:00h:05m:59s:17 GRX switch to backup source

The clock management scheme generates an alarm when the GRX/GTX control logic reports a problem

locking the reference clock to the configured source. This alarm is cleared when lock is achieved. This

same alarm generation scheme remains in place for the reference clock source back-up scheme. When a

primary clock fails it is likely that the clock failure alarm condition is temporarily raised whilst the

secondary is being switched in. Once the control logic has locked on the secondary source the alarm

condition will be locked. The alarm control mechanism (signal delay) can ensure that this temporary

alarm condition does not result in an alarm being signalled.

3.1.1 The CLOCK STATUS menu



The AGG SUMMARY shows some simple statistics relating to aggregate status. It is for information only.

The menu presents all currently configured aggregates, showing their current state, number of failures

and time since the last failure and recovery. The statistics shown automatically uodate every 30 seconds

but may be updated manually by pressing the REFRESH STATS softkey. The statistics may be reset using

the RESET STATS softkey.

The aggregate name is the serial data port name for the aggregate or the IP aggregate name appended

to the term “IP”. The state column reports whether we consider each aggregate to be either UP or

DOWN.

If the system contains more aggregate ports than can be shown on a single page then <NEXT PAGE> and

<PREV PAGE> buttons are provided to access this info for all ports.

3.1.2 The AGG SUMMARY menu



The Test Ports menu provides the ability to test the packet connectivity between two tributaries in a

multiplexer network. Slot 253 is reserved as the test port – known as TP. The channels in this slot are

peered with each other to provide mappings across the multiplexer network over which test packets can

be sent.

To configure a connection between two Test Ports, one test port is configured to Type TxRx and the other

end is configured to Type echo. In this example, node 1 is configured to TxRx (see screen above). Node 0

is configured for echo (see screen below).

3.1.3 The TEST PORTS menu



The screen shows the channels – up to 16 can be configured. The Type is configured as either Off, Echo,

or TxRx. Off stops the test. The Rate is configured on the TxRx side. A rate between 0 and 2048000 bps

can be entered. The Dest is entered as node:TP:channel, where TP indicates a test port. State shows

either the receive rate (Rx@rate), the transmit rate (Tx@rate) or Idle (the test port is Off). Packets shows

the number of packets received. Lost shows the total number of packets lost. % shows the percentage of

packets lost. RTT Min shows the minimum round trip time in milliseconds, Avg shows the average round

trip time in milliseconds and Max shows the maximum round trip time in milliseconds.

Statistics are updated every 30 seconds once the test is started.

Since these tests use up bandwidth, it is advisable to stop the test by setting the Type to “Off”, once the

connection has been successfully established.



The SLOTS menu gives an alternative route to the same diagnostics menus as are available under the

individual SLOTS configuration menus. Refer to section 3.2 below for details.

3.2 The SLOT N / DIAGNOSTICS menu

A number of tools, statistics and messages are available under the diagnostics menu. The V200 and V150

systems provide separate access to these tools for each slot on the unit. The diagnostics tools on these

platforms apply just to the ports and IP router on the slot being diagnosed.

3.1.4 The SLOTS menu



There are a number of troubleshooting tools in an IP sub-menu beneath the DIAGNOSTICS menu. These

tools allow the user to run the ping protocol (ICMP echo) from the multiplexer, view the current internal IP

route table, view the statistics from the IP router, view the statistics from the Ethernet device, and view

the Address Resolution Protocol (ARP) table. When the network is not performing as expected, these tools

can be used to troubleshoot behaviour.

The Diagnostics, IP sub-menu is shown below:

This menu provides the user with a series of screens, which can be used for running Ping tests and

analysing the results. Refer to the following example configuration for IP routing across a pair of

multiplexers:

3.2.1 The IP menu

3.2.1.1 The PING menu



Troubleshooting - example network

If Station A is not successfully communicating with Station B, the following steps should be taken to

troubleshoot the network configuration:

Local Ping Tests

Ping Station A from Node 1

Ping Station B from Node 2

Inter-multiplexer Ping Test

Ping Node 2 from Node 1 (or vice-versa)

Remote Ping Tests

Ping Node 2 from Station A

Ping Node 1 from Station B

Full Ping Tests

Ping Station A from Station B (or vice versa)

Selecting the PING test from the menu displays the following screen:



The table below shows the configurable parameters and the ranges that may be set:

NOTE: Once a ping test has been started, it is possible to leave the test running while you view

other screens. The test is stopped by clicking the <STOP> button.

NOTE: The parameters on this page are not stored and will be lost over a system reset.

Parameter Range of Values Target IP address nnn.nnn.nnn.nnn.

Count 0-9999 pings

Size 0-1472 bytes

Response Timeout(mS) 10-30000

Delay(mS) 0-60000 mS between pings

A simple guide to PING diagnostics is given below:



Problem What to check Solution Local Ping test fails IP network configuration on multiplexer

& Station: Are the multiplexer ENET port and the station configured on the same IP subnet?

Correct the configuration

multiplexer connectivity: Are other services operating between the multiplexers?

Standard multiplexer connection troubleshooting

IP Subnet config on multiplexer: Does Node1 have a subnet configured to Node 2 with a peer matching Node 2’s channel ID? Does Node 2 have a subnet configured to Node 1 with a peer matching Node 1’s channel ID? Are the DBAs configured at something other than 0? Are the IP addresses for the unnumbered links set the same for the local ENET port?

Correct configuration

Inter-multiplexer Ping test Fails

IP Route Configuration on multiplexer: Is the NoRoutes count in the IP STATISTICS page incrementing? Is there an IP Route to get to Node 2 on Node 1? Is there an IP Route to get to Node 1 on Node 2?

Add routes or enable RIP

Remote Ping Test fails IP Route Configuration on Station: Does the station have a route configured that will ensure the ping request to the remote multiplexer node goes through the local multiplexer node?

Add correct route to Station or enable RIP

Full Ping test fails IP Route Configuration on Stations: Does Station A have an IP route configured that will ensure that packets for Station B are routed through Node 1? Does Station B have an IP route configured that will ensure that packets for Station A are routed through Node 2?

Add correct route to Station or enable RIP



The IP ROUTE TABLE, IP STATISTICS, ETHERNET and ARP TABLE screens are for information only. The

two tables record the IP routes in use while the IP STATISTICS and ETHERNET pages give detailed packet

statistics and Address Routing Protocol conversions and are updated every ten seconds. These may be

used to help track down any routing, congestion or filtering problems but require specialist knowledge –

contact Vocality for details.

3.2.1.2 The IP ROUTE TABLE menu






used to help track down any routing, congestion or filtering problems but may require specialist

knowledge – contact Vocality for details. A brief explanation of each is given below:

ipForwarding

“The indication of whether this entity is acting as an IP router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP routers forward datagrams. IP hosts do not (except those source-routed via the host).”

ipDefaultTTL

“The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.”

ipInReceives

“The total number of input datagrams received from interfaces, including those received in error.”

ipInHdrErrors

“The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.”

3.2.1.3 The IP STATISTICS menu



ipInAddrErrors

“The number of input datagrams discarded because the IP address in their IP header’s destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.”

ipForwDatagrams

“The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route option processing was successful.”

ipInUnknownProtos

“The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.”

ipInDiscards

“The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.”

ipInDelivers

“The total number of input datagrams successfully delivered to IP user-protocols (including ICMP).”

ipOutRequests

“The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams.”

ipOutDiscards

“The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion.”

ipOutNoRoutes

“The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this ‘no-route’ criterion. Note that this includes any datagrams which a host cannot route because all of its default routers are down.”

ipReasmTimeout

“The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.”

ipReasmReqds

“The number of IP fragments received which needed to be reassembled at this entity.”



ipReasmOKs

“The number of IP datagrams successfully re-assembled.”

ipReasmFails

“The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.”

ipFragOKs

“The number of IP datagrams that have been successfully fragmented at this entity.”

ipFragFails

“The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don’t Fragment flag was set.”

ipFragCreates

“The number of IP datagram fragments that have been generated as a result of fragmentation at this entity.”

ipRoutingDiscards

“The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries.”






used to help track down any routing, congestion or filtering problems but require specialist knowledge –

contact Vocality for details.

3.2.1.4 The ETHERNET menu



This menu is present when the V150 or V50plus has the power over Ethernet option installed. This menu

allows you to view the power used on an option slot.

NOTE: This menu is displayed only when multiple option cards are present. If a single option

card is present, the following screen is shown instead.

3.2.1.5 The POWER OVER ETHERNET menu



This menu shows the power used by devices connected to the option slot selected (in this case, slot 2). In

the example above, a device is connected to port 5 that is using 16 Watts of power. The status line below

the table shows the maximum power available (as configured on the SYSTEM page) and the remaining

free power.

PORT

Identifies the port on the chosen slot.

STATUS

The status can be ‘Empty’, indicating no devices are connected to the port, ‘Non PoE Device’ indicating a

device is connected but it is not a PoE device, and ‘PoE Device’ indicating a PoE device is connected to the

port.

3.2.1.5.1 The SLOT x menu



DEVICE

‘-‘ is displayed when the STATUS is Empty or a non PoE device is attached – otherwise the class of the

attached PoE device is shown. The classes are shown in the table below:

Class Minimum Power Levels Output at the PSE (Watts)

Maximum Power Levels at the Powered Device (Watts)

0 15.4 0.44 – 12.95

1 4.0 0.44 – 3.84

2 7.0 3.84 – 6.49

3 15.4 6.49 – 12.95

4 Reserved for future use. Reserved for future use.

POWERED

‘Yes’ indicates the device is currently powered by the power over Ethernet option. ‘No’ indicates that this is

not currently powered by the power over Ethernet option.

WATTS

Shows the power used by the device shown.



This menu provides details of the current internal state of the IP address resolution protocol table of the

embedded IP router. You may be asked to provide details of the contents of this table during

troubleshooting sessions with qualified multiplexer service personnel.

3.2.1.6 The ARP TABLE menu



This menu provides details of the current internal state of the bridge forwarding database in the

embedded transparent bridge. It indicates which MAC stations have been learned on which bridge ports.

You may be asked to provide details of the contents of this table during troubleshooting sessions with

qualified multiplexer service personnel.

3.2.1.7 The BRIDGE FDB menu



This menu provides details of the current internal state of the embedded transparent bridging ports. It

includes details of the number of packets that have been forwarded (to a learnt destination), filtered (the

destination is local) and flooded (multicast packet or unknown destination) through the configured bridge

ports. It also provides details of the current spanning tree protocol state of each port if the spanning tree

protocol is configured. You may be asked to provide details of the contents of this table during

troubleshooting sessions with qualified multiplexer service personnel.

This page automatically refreshes periodically if no keys are hit.

3.2.1.8 The BRIDGE PORTS menu



This menu displays data about the data ports in use in the V25 or V50plus multiplexer or on the specified

V200 or V150 slot. These data ports include serial data ports, IP ports and internal ports used to connect

across the system backplane in V200 and V150 systems. A separate page is shown for each port

supported. The user may use the <NEXT PORT> and <PREVIOUS PORT> buttons to move through the

pages, or may select the port page via the Port field.

SYSTEM UPTIME

Shows the time the multiplexer has been up and running since the last power-cycle.

PORT

Identifies the port in the form slot:channel. Both physical and virtual ports (such as virtual ports used by

Aggregates) can be displayed. Statistics for a different port on the slot can be viewed by selecting the

<NEXT PORT> button at the top of the screen.

TYPE

Shows the type of ports – for example, Serial Data or IP.

3.2.2 The DATA PORT STATS menu



MODE

Shows whether the port is configured as a Tributary or Aggregate port.

NAME

The name of the IP aggregate or the route name used to create a switched aggregate.

STATE

Shows the current state of the port – for example, ‘disconnected’.

SINCE LAST CHANGE

Shows the time that has elapsed since the last state change.

CONNECTIONS

Shows the number of times this port has successfully connected.

CURRENT RX CLOCK

Shows the rate the receive clock is currently running at.

CURRENT TX CLOCK

Shows the rate the transmit clock is currently running at.

MINIMUM RX CLOCK

For tributaries only, shows the minimum rate of the receive clock on this port.

MINIMUM TX CLOCK

For tributaries only, shows the minimum rate of the transmit clock on this port.

MAXIMUM RX CLOCK

For tributaries only, shows the maximum rate of the receive clock on this port.

MAXIMUM TX CLOCK

For tributaries only, shows the maximum rate of the transmit clock on this port.

RX PACKETS

Shows the number of packets received on this port.



TX PACKETS

Shows the number of packets transmitted on this port.

RX BYTES

Shows the number of bytes received on this port.

TX BYTES

Shows the number of bytes transmitted on this port.

RX ERRORS

Shows the count of receive errors detected on this port.

TX ERRORS

Shows the count of transmit errors detected on this port.

SINCE LAST RX ERRORS

Shows the time since the last receive error was detected on this port – if any.

SINCE LAST TX ERRORS

Shows the time since the last transmit error was detected on this port – if any.

CURRENT RX RATE

Shows the current receive rate in bits per second.

MAXIMUM RX RATE

Shows the maximum receive rate in bits per second.

SHORTAVG RX RATE

Shows the short term receive rate average in bits per second. This represents the average receive rate

over the last 30 seconds (approximately).

LONGAVG RX RATE

Shows the long term receive rate average in bits per second. This represents the average receive rate

over the last 30 minutes (approximately).



The statistics for this port only can be reset to zero by selecting the <RESET PORT STATS> button at the

bottom of the screen.

The statistics for all the ports can be reset to zero by selecting the <RESET ALL STATS> button at the

bottom of the screen. On the V200 and V150 systems, this button resets all the statistics on the unit.



N.B This menu is only displayed if SWITCHED aggregates are configured in the system.

On the V200 and V150 systems, this menu provides call statistics for switched aggregate ports on this

slot. On the V25 and V50plus systems, this menu provides call statistics for switched aggregate ports on

this unit.

Step through the port statistics pages by using the <NEXT PORT> and <PREVIOUS PORT> buttons at the

top of the page - if these buttons are not present there is just a single port to report statistics for.

Each page is split into three sections. The top sections report the call statistics for that port since the

multiplexer last restarted, and the current state of the port. The middle section reports the call statistics

for the last 24 hour period, split into 3 hour segments. The bottom section reports the call statistics for the

last 7 days split into 24 hour periods.

NOTE: Call statistics are not maintained through a restart of the multiplexer.


3.2.3 The AGG CALL STATS menu



This menu identifies all of the voice channels fitted in the current slot and displays their statistics:

• IN/OUT/IDLE for handling incoming call/handling outgoing call/no call present

• The time in minutes that the channel has been in that state

• The Peer: n:s:c of the port that this call is connected to

• How many calls have been made through this device since restart.

Also at the top of the menu is a summary of the total number of outbound calls made and the number

currently active; also the total number of inbound calls received and the number currently active.

3.2.4 The TRIB CALL SUMMARY menu



The Trib Call Stats menu is available only when a Digital Voice card is installed.

This menu provides call statistics for voice ports.

The call statistics provided are the same for voice ports and switched aggregates.

Step through the port statistics pages by using the <NEXT PORT> and <PREVIOUS PORT> buttons at the

top of the page - if these buttons are not present there is just a single port to report statistics for.

Each page is split into three sections. The top sections report the call statistics for that port since the

multiplexer last restarted, and the current state of the port. The middle section reports the call statistics

for the last 24 hour period, split into 3 hour segments. The bottom section reports the call statistics for the

last 7 days split into 24 hour periods.

NOTE: Call statistics are not maintained through a restart of the multiplexer.

A "CallIn" represents an external device taking the port "off-hook". A "CallOut" represent the multiplexer

taking the device "off-hook". This page automatically refreshes periodically if no keys are hit.

3.2.5 The TRIB CALL STATS menu



This menu provides a summary of the multiplexing currently occurring over each aggregate in the

multiplexer. The status is provided for each aggregate port in the system - each port's status is on a

separate page. Use the <UP> and <DOWN> buttons to cycle through each port.

Each line in the status reports the current state of a tributary connection that is multiplexed over the

aggregate.


3.2.6 The AGG STATUS menu



The data presented on this menu is for information only. It shows details of the hardware and software

revisions currently installed in this slot.

3.2.7 The SYSTEM INFO menu



This menu provides detailed status information about the TDM connection.

CHANNEL

The Channel/Port being displayed.

<NEXT TDM>

Select using the space-bar to move on to the next TDM port. (In chassis systems such as V150 or V200,

this will select between TDM ports on the current card).

OVERALL STATUS

The overall status of the TDM Aggregate:

UP : Both Transmit and Receive directions are active and calls can be made. UP-LOOPED: Established and Loop detected (either a loopback connection is in place or

the peer is configured with the same Node-Id). DOWN: TDM is not established in both directions.

3.2.8 The TDM Status menu



PEER

The Id of the peer – automatically detected by the TDM protocol. This is displayed in brackets if the

Overall Status is not Up (or Up-looped), to indicate the ID of what was last connected to this port. Note

that this information could be out-of-date if displayed in brackets.

TDM MODE

SIMPLEX or DUPLEX, as configured on the TDM ADVANCED CONFIG menu.

TIMESLOTS

The number of Timeslots, as configured on the TDM TIMESLOTS menu.

TRANSMIT STATUS

The status of the TDM in the transmit direction (i.e. of data leaving the local unit).

NO_CLOCK: No clock detected in the transmit direction. SYNCING-SIMPLEX: The TDM is in the process of initialising and is configured to SIMPLEX

mode. In Simplex mode, the Transmit direction will automatically go active without requiring signalling from the peer.

START_SENT_1: The first phase of TDM protocol initialisation when in DUPLEX mode. START_SENT_2: The second phase of TDM protocol initialisation when in DUPLEX mode. ACTIVE: The transmit direction is fully active.

RECEIVE STATUS

The status of the TDM in the receive direction (i.e. of data incoming to this unit from the TDM aggregate).

SYNC_WAIT: The receiver is waiting for the peer to start communicating. ACTIVE: The receive direction is fully active

TRANSMIT SPEED

The speed of the transmit direction in bits/sec. *TOO HIGH* is displayed if the speed is higher than that

specified for TDM. *NOT 1600 MULT* is displayed if the speed is not a multiple of 1600 bits/sec.

RECEIVE SPEED

The speed of the receive direction in bits/sec. *TOO HIGH* is displayed if the speed is higher than that

specified for TDM. *NOT 1600 MULT* is displayed if the speed is not a multiple of 1600 bits/sec.

LOCAL TDM VERS

The version of TDM protocol running on this unit.



PEER TDM VERS

The version of TDM protocol running on the peer.

3.2.9 The TDM STATISTICS menu

This menu provides detailed status information about the TDM connection.

CHANNEL

The Channel/Port being displayed.

TIMESLOTS

The number of Timeslots, as configured on the TDM TIMESLOTS menu.

<RESET STATS>

Resets statistics for all TDM ports on this card



<NEXT TDM>

Select using the space-bar to move on to the next TDM port. (In chassis systems such as V150 or V200,

this will select between TDM ports on the current card).

“TRANSMIT” AND “RECEIVE” STATISTICS

CURRENT LINE SPEED

The speed of the transmit/receive direction in bits/sec.

TOTAL TIMESLOT B/W (BITS)

The total bandwidth assigned to all configured timeslots (including the timeslots’ overhead).

Calculated on the basis of all timeslots active simultaneously and (in the case of DBA timeslots) running at

the maximum rate. Under some situations it is valid for this to exceed the TDM port’s line-speed: for

example, if DBA is being used; or if multiple Voice channels are present, not all of which may be used at

the same time.

FRAMING OVERHEAD

The framing overhead used by the TDM protocol, before considering the timeslots.

This comprises the standard signalling overhead (when 16 timeslots are configured, this is 1600 bits/sec)

plus any Configured Overhead from the TDM ADVANCED CONFIG menu.

RESERVED TIMESLOT B/W

The total amount of bandwidth "reserved" for Timeslots on this line. This is for the special cases of

PATTERN mode and BRD Broadcast voice timeslots: there is no call-control set-up for either of these types

of timeslot. The bandwidth is permanently reserved for both of these types.

If the total Reserved Timeslot B/W plus Framing Overhead exceeds the current line speed, then the

warning *HIGH* will be displayed here – since there is no bandwidth available for traffic.

DYNAMIC B/W AVAILABLE

The total amount of bandwidth available in the Dynamic area of the frame. This area is the lowest priority

after all other timeslot types and accepts any bandwidth from temporarily unused timeslots.

“LAST SECOND” STATISTICS

These statistics show traffic levels for the last complete second for TX and RX directions as follows:



TIMESLOTS USED

Count of the number of different timeslots used in the last second.

TIMESLOT USAGE (BITS SENT)

The amount of bandwidth consumed by Timeslots in the last second (including Timeslot Overhead)

DYNAMIC PACKETS SENT

The number of packets sent/received through the Dynamic Area in the last second.

“LAST TRANSMITTED/RECEIVED FRAME” STATISTICS

These statistics show the usage of the last Frame transmitted or received. (The TDM protocol sends 50

frames/second – each frame corresponds to 20 ms. The Frame size in bits is the line-speed in bits/second

divided by 50).

TIMESLOTS IN USE

The number of timeslots carrying payload.

TIMESLOT AREA (BITS)

The amount of data (including timeslot overhead) used by Timeslots in the frame.

DYNAMIC AREA (BITS)

The size in bits of the Dynamic Area of the frame.

DYNAMIC AREA USED

The amount of data (including overhead) used within Dynamic Area of the frame.

DYNAMIC AREA SPARE

The amount of spare space in the Dynamic Area of the frame.

LONG TERM STATISTICS

These are two statistics which relate to the long-term operation of the TDM link, (Note that both of these

relate to the transmit direction).



DISCARD TIMESLOT TX PACKETS

The number of packets associated with Transmit Timeslots which have been discarded.

Packets may be discarded when DBA changes occur, or on TDM Aggregate failure. Alternatively, this may

be an indication that a timeslot has been misconfigured (e.g. a Trib is running at a faster rate than the

aggregate).

DISCARD DYNAMIC TX PACKETS

The number of packets which were routed to the Dynamic area which have been discarded.



The LOGS menu presents a range of more detailed historical information on specific types of event. There

is also an overall log which combines them all so as to display everything sequentially, with time stamps.

Examples of the individual selections follow.

3.2.10 The LOGS menu



This log shows messages relating to the management of tributary connections. These messages refer to

internal multiplexer state machines and protocols and are not intended for customer interpretation.

Commands to pause the log storage, resume the log storage, move through the log buffer, and list the

entire contents of a log buffer are documented in the LOG HELP page.

You may be asked to provide details of the contents of these pages during troubleshooting sessions with


These pages update as new log messages are generated.

3.2.10.1 The CONNECTION LOG menu



This log shows messages relating to the storage, retrieval and implementation of configurations. These

messages refer to internal multiplexer state machines and protocols and are not intended for customer

interpretation.






3.2.10.2 The CONFIGURATION LOG menu



This log shows messages relating to the major and minor alarms generated on the multiplexer.






3.2.10.3 The ALARM LOG menu



This log shows messages relating to voice and switched aggregate ports going on- and off-hook.






3.2.10.4 The CALL RECORD LOG menu



This log shows messages relating to the operation of the internal embedded IP router. These messages

refer to internal multiplexer state machines and protocols and are not intended for customer

interpretation.






3.2.10.5 The IP LOG menu



This log shows messages relating to the operation of the SIP gateway. These messages refer to internal

multiplexer state machines and protocols and are not intended for customer interpretation.






3.2.10.6 The SIP GATEWAY LOGS menu



This log shows messages relating to the operation of the Secure Voice Relay module, if fitted to a voice

card in this slot. These messages refer to internal multiplexer state machines and protocols and are not

intended for customer interpretation.






3.2.10.7 The SVR DEBUG LOG menu



This log shows all the log events regardless of their category. These messages refer to internal multiplexer

state machines and protocols and are not intended for customer interpretation.






3.2.10.8 The ALL LOGS menu



In most cases, the commands are self-explanatory with [S]tart, [E]nd, [U]p, [D]own moving the viewing

window to the relevant point in the trace buffer. [L]ist outputs the contents of the whole trace buffer,

which may be useful when capturing the trace to a file and [C]lear empties the buffer. The [P]ause

command freezes the trace buffer and stops recording status messages. When the[R]esume command is

entered, the last page in the buffer is repeated together with the next five messages from live output. The

display then continues in real-time.

3.2.10.9 The LOG HELP menu



This log shows messages relating to the operation of the SNMP. Counts are shown for the different SNMP

message types.





3.2.11 The SNMP STATS menu

C H A P T E R 4 F E A T U R E S


4 Features 4.1 Data Capabilities

Serial data channels are presented with common functionality right across the range of Vocality products,

with only a few minor variations. Except where specifically noted in the relevant Hardware Guides, the

user can expect to be able to freely configure the Electrical Interface type, Aggregate/Tributary mode,

DCE/DTE presentation, Sync/Async protocol, clock rate/sources and peer destination.

Synchronous modes give the user the ability to specify clock sources with great flexibility and provide for

speeds up to 5.12Mbps on all products, with the High-speed CPU and Data cards extending this to

10.24Mbps. Also provided are the ability to clock high-speed data sources using source-synchronous

clocking in the TTP and TTD modes and the ability to smoothly vary the clock rate by Dynamic Bandwidth

Allocation (DBA), thereby making the most of available bandwidth at all times under varying traffic

conditions.

Access to the DATA menu is direct from the SYSTEM menu for the simpler V25 and V50plus products,

while the slot-based V150 and V200 have an intermediate menu level for SLOTS. This allows for an

architecture where data ports are present on a wide range of cards which can be fitted in almost any Bay.

The DATA menu is then accessed in the same way on a per-slot basis.

Modem Control signals for all data ports are conditioned the same way, on the SYSTEM menu. Here the

user may define the behaviour of the output signals and also how the input signals bring data connections

up.

4.2 Voice Capabilities

The Vocality range of multiplexers provides a powerful solution for carrying voice calls in a high-quality,

bandwidth-efficient manner. The smaller V25 and V50plus products provide 2-wire analogue telephony

and 4-wire monitoring circuits only, which are configured via the VOICE menu. On the V150 and V200

products, both analogue voice and primary rate digital voice interfaces are available, accessed first via the

SLOTS menu then by selection of the relevant interface type.

In all cases, voice channels may be configured to use one of a wide range of compression algorithms

according to the quality and bandwidth profile required. Voice channels are given dedicated bandwidth for

the duration of the call and can interact dynamically with data and IP services for optimum bandwidth

usage. Voice quality may be optimised using adjustable gain parameters.

Chapter

4



For efficient Fax, Data Modem or Secure Telephone Unit (STU) calls the voice channels can operate in

relay modes, where data may be transferred directly at speeds up to the compression algorithm rate.

Here, the DSP in the multiplexer trains locally with the originating device and demodulates the connection

back into data, which is passed to the remote channel using the bandwidth-efficient Vocality proprietary

protocol, where it is re-modulated before passing out to the terminating device.

Analogue ports support Pulse-dialling and DTMF relay, while the digital ports support E1 ETSI Q.931

(DSS1) primary rate ISDN signalling or T1 National ISDN2 (NI2), AT&T 5ESS and Nortel DMS-100 CCS

protocols.

The products provide considerable flexibility of call routing either through the use of an internal auto-

mapping facility which uses the NODE-SLOT-CHANNEL numbering scheme to identify destinations or a

Directory menu that allows voice ports on the Vocality network to be mapped to match the numbering

scheme being used by the customer’s installation. Hunt groups allow voice calls to be routed to any

available port within a configured group of ports. The hunt group feature makes it possible to route a call

to an available port within a hunt group and allow the generation of an outgoing DTMF digit stream on the

available port if required. This provides for hot-line extension into a PBX or PSTN.

4.3 Multi-level Precedence and Pre-emption (MLPP)

This feature is provided as a Supplementary Service on the primary rate ISDN interfaces available in

Vocality equipment, whereby voice calls may be assigned precedence on a per call basis ranging from the

lowest precedence, 4 (Routine) to highest precedence 0 (Flash Override). In the case of congestion, either

at the terminating user end or within shared network resources, this precedence level may be used to

pre-empt (terminate) existing low precedence calls to allow a high precedence call to complete. Pre-

emption can only occur on calls where the parties are assigned to participate in the MLPP feature.

This feature provides:

References:

[1] ITU Q955 (03/93) Stage 3 - Clause 3 – Multi-Level Precedence and Pre-Emption.

[2] ITU Q85 Stage 2 – Section 3 – Multi-Level Precedence and Pre-emption.

[3] Department of Defence Voice Networks. Generic Switching Centre Requirement (GSCR) 8 Sept 2003 – Errata change 2 14 Dec 2006.

[4] ANSI T1.619 -1992 Integrated Services Digital Network (ISDN) Multi-Layer Precedence and Preemption (MLPP) Service Capability.

[5] ANSI T1.619a -1994 (R2007) Integrated Services Digital Network (ISDN) Multi-Layer

Precedence and Preemption (MLPP) Service Capability (MLPP Service Domain and Cause Value

Changes)



- ISDN signaling on the primary rate interface to allow MLPP requests incoming to the Vocality network to be processed.

- ISDN signaling to allow outgoing MLPP requests to be forwarded from the Vocality network across the primary rate interface

- Transport of MLPP functionality across the proprietary portions of the Vocality network.

- Pre-emption based on call precedence at each point within the Vocality network where congestion may occur.

- Participation in MLPP functionality by analogue voice extensions within the Vocality network.

Restrictions and limitations:

- The optional Look Forward Busy (LFB) functionality detailed in (Ref. [1], Ref. [2]) is not supported.

- The optional Alternate Party functionality detailed in (Ref. [1], Ref[2]) is not supported.

- Only voice calls participate in MLPP functionality.

- In Band recorded announcements detailed in Ref.[3] are not implemented.

- For incoming MLPP requests received on the PRI, it is assumed that subscriber precedence validation has taken place at the connected equipment and the precedence level being requested is allowed for the originating subscriber.

- Only one precedence level per PRI span will be allowed, essentially to turn feature on/off, it is assumed connected equipment carries out subscriber precedence checking.

- Only calls involving parties provisioned to participate in MLPP may be pre-empted.

- Within the Vocality network only E1/T1 digital voice cards and analogue voice ports currently support MLPP. Other voice ports such as SIP, ISDN BRI etc. do not currently support MLPP.

4.3.1 MLPP Service Invocation

4.3.1.1 Primary rate interface

If the PRI is not provisioned for MLPP the call will be treated as a routine call. If no precedence invocation

is received in the call SETUP but the destination has MLPP provisioned, the call will be treated as a

precedence 4 (Routine) call. If a call SETUP is received invoking a precedence call with a Data bearer

capability, the call will be rejected with cause 88 – “incompatible destination”. If a PRI is provisioned for

MLPP and a SETUP is received with a data bearer capability and no precedence invocation it will be treated

as a routine call.

4.3.1.2 Invoking an outgoing precedence call

In order to invoke a precedence call from an analogue port which has been provisioned for MLPP, the

originating user must dial an access code prior to dialing the routing digits. If no access code is recognised

as being dialed by an MLPP subscriber, the call will be treated as an MLPP call with precedence 4 (routine).

When a valid precedence access code is recognised, the associated precedence level is validated against

the maximum precedence level provisioned for that user. If the invoked precedence level exceeds the

provisioned maximum, the call will fail.



4.3.1.3 Provisioning access codes

The access codes used to invoke a precedence call from an analogue port can be provisioned under the

existing directory menu. An access code takes a channel entry in the format <chassis>:P:<precedence>,

where precedence is a value from 0 to 4 and denotes the call precedence value associated with this access

code.

The above screen is for a hypothetical unit, “Node 0” which is connected via an aggregate to Node 1 and

also connected to Node 1 via a digital voice card in slot 1.

Entry Line1: The precedence level associated with the digit “3” is defined

Entry Line 2: If a subscriber wishes to make a routine call to port 1:0:2 via the aggregate, the subscriber

would dial the digits 102. If the subscriber wishes to make a precedence 3 (priority) call to port 1:0:2 via

the aggregate, the subscriber would dial the digits 3102. In order to successfully invoke MLPP on the call

the following would also need to be true:

(1) Both subscribers are provisioned MLPP users in the same domain.

(2) The calling user is provisioned to a maximum precedence level of at least 3.

Entry Line 3: If the subscriber wishes to make a precedence 3 (priority) call over the PRI link to port

1:0:2 the subscriber would dial 3555, this would route to the PRI line and add the dialed digits 102 to the

outgoing setup message.



Entry Line 4: If the subscriber wishes to make a precedence 3 (priority) call to huntgroup 1 the

subscriber would dial 3123. The huntgroup inherits the MLPP settings of its members as described later.

4.3.2 Pre-emption Rules

If a precedence call attempt is made from one MLPP subscriber to another in the same domain and the

call cannot complete due to congestion, pre-emption may occur if calls using the congested resource are:

- MLPP calls

- in the same MLPP domain

- potentially overriding calls of lower precedence which will allow the call attempt to succeed

Congestion may take two forms:

- Access congestion, where the terminating subscriber is busy. Pre-emption in this case is only possible if “Access” is set to “YES”.

- Network congestion. Where elements transporting the call are congested, a user may have a call pre-empted in this case even if “Access” is set to “NO”. The diagram below shows possible congestion points when making a call attempt from analogue subscriber B to analogue subscriber A across the Vocality network:

4.3.2.1 Precedence call with no pre-emption

If a precedence call attempt is made it may fail to complete if congestion is encountered at any point and

any of the following are true at that point:

- Congestion is at the terminating user and that users provision is set to “Access” = “NO”

- Insufficient MLPP calls of a lower precedence in the same MLPP domain exist

The call will be treated as a busy call.



4.3.2.2 Precedence Call Pre-empted

If a precedence call attempt encounters congestion at any point and the following are true at the

congestion point:

- MLPP calls from the same domain are present

- MLPP calls of lower precedence are present

- Clearing lower precedence calls will allow precedence call to complete

One or more of the lower precedence calls may be terminated to allow the higher precedence call to

complete.

If the congestion is at the terminating user an indication will be given to the terminating user that the

existing call has been preempted. If the terminating subscriber is on the PRI this will take the form of a

DISCONNECT message with cause 8 “pre-emption” and Return Error component “failureCaseB”. If the

terminating user is an analogue subscriber a distinctive audio tone will be presented and on the called

subscriber hanging up, the precedence call will complete.

When a precedence MLLP call with a precedence other than 4 (routine) is delivered to an analogue voice

port within the Vocality network the ringing cadence of the phone will be changed from the standard ring

cadence selected by the country code to a precedence ring cadence as defined in Ref[3].

When a precedence call attempt from a Vocality voice port is successfully delivered to the destination as a

precedence call the ringback tone heard in the earpiece will be changed from the standard ringback tone

associated with the country code setting to a special ringback tone as described in Ref[3].

When a precedence call attempt is made into a Vocality Digital card and gets successfully delivered as a

precedence call a special precedence ringback tone, as described in Ref.[3] gets applied to the bearer

channel in place of the standard ringback tone associated with the country code. Note: A ringback tone

will only be applied to the bearer channel when the “Progress Tone” option on the Digital card menu is set

to “ON”.

4.3.3 Interaction with other features

The MLPP functionality interacts with the following V100 features:

Hunt Groups

The Hunt group itself cannot be provisioned to the MLPP service. The hunt group will “inherit” the MLPP

status of its constituent members. Also with hunt groups the calling party does not actually originate the

call, rather it sends a request to the hunt group which interrogates each of its members in turn looking for

an available member. It is then the hunt group member that originates the call. The hunt group request

will have to communicate MLPP parameters from the originating subscriber to the hunt group which will

then interrogate its constituent members as follows:

4.3.2.3 Precedence Ringback and Cadence



Scan all members for MLPP subscribers of same domain and if available, establish an MLPP call. If not,

scan non-MLPP domain members for availability and if found, establish a non-MLPP call. If no members

are available at all, scan MLPP domain members for pre-emptable members and if there are any, pre-

empt the call but if not, scan non-MLPP domain members for availability and establish a non-MLPP call if

possible. In the event that no available member can be found, the call is not placed.

Secondary Routing

Should secondary routing be active and the primary aggregate route fails, all calls regardless of

precedence will be cleared. Once the secondary route is established normal precedence and pre-emption

rules will be applied to any calls re-established.

4.4 Push-Config

Push-Config is a proprietary mechanism for configuring remote multiplexers from a central V200 or

V150 hub. The primary aim of Push-Config is to remove the need for multiplexer management skills

from personnel in the field, whilst retaining the ability to dynamically change network operation. The

ultimate aim is for a factory-defaulted multiplexer to be installed at a remote site, and automatically

obtain its multiplexer settings when it is connected to the Vocality network. When in Push-Config mode,

a remote unit obtains its configuration when it initially connects to a hub multiplexer – therefore only basic

serial aggregate connectivity to the hub unit is required in the remote unit configuration.

Note that this feature is an optional enhancement to the existing management scheme. It is intended for

remote sites in a hub-spoke type network (i.e. not mesh) where there is a single aggregate link in use at

the remote site. Note also that TDM aggregates fall outside the scope of Push-Config mode and only

standard aggregate types may be configured when using it. A customer may continue with the standard

operation mode (where the remote multiplexer carries its own complete configuration) if the restrictions

on the push config operation are too inflexible.

The implementation of these features is split between the hub and remote sites. The hub site functionality

is intended for the V200 and V150 platforms (it relies on the V200 file system to operate). The remote site

functionality is provided for V150, V50plus and V25 and platforms. NOTES: (i) The Standard CPU card

supports Push-Config client only - i.e. no Push-Config hub site operation (ii) The High-speed CPU card

supports Push-Config server only - i.e. no Push-Config remote site operation. A V150 at a remote site

cannot have a high-speed CPU in any slots if it is to support Push-Config. (iii) A server pushes a client

type of V150 and therefore assumes a standard CPU card at the remote site (iv) Push-Config for voice,

data, digital voice cards, SIP and a single IP router (in slot0) only. There is currently no support for

pushing a config to an IP router in slots 1 or 2 of the V150. (v) There is no slot management config via

Push-Config - i.e. you cannot have slot redundancy at the remote V150 with Push-Config operation.



4.4.1 Push-Config Features

The menu system for configuring the remote multiplexers is provided in the management menus on the

hub (V150 or V200) multiplexer. The user can select which remote units require a configuration on a hub

unit, and then configure that remote unit at the hub site using the standard Vocality menu system. There

is no need for the remote unit to be connected during this configuration. The configuration is stored in the

file system on the hub site, and can be altered at any time. If alterations are made whilst the remote unit

is connected, then the changes will be immediately applied to the remote unit. If the remote unit is not

connected, any changes will be applied when it is next connected.

To provide the correct menus, the hub site must be told what the installed hardware options on the

remote units are. This allows it to provide the correct menu schemes for the remote site.

Each remote site configuration contains the parameters that would normally be stored in the numbered

edit configuration set. System configuration parameters are not configurable for each remote site – they

are taken from the hub site’s system configuration. Therefore all the system page parameters (except the

node number which is configured on the PUSH CONFIG CLIENTS menu), directory page parameters, auto-

mapping parameters and alarm management parameters are common between the hub unit and any

remote units connecting via this Push-Config scheme. In addition, there is no routing page provided for

each remote unit. Push-Config is only intended for remote units with a single aggregate link. Therefore

only a default (all nodes) route is required at the remote site – this can be automatically installed during

the Push-Config operation.

The serial number and platform type of a remote unit are used to uniquely identify it. This allows for

Push-Config operation without entering usernames and passwords at the remote sites. The multi-unit

configuration at the hub site is keyed from the serial number and platform type. The hub site

administrator must configure the hub site with the serial number and platform type of each remote unit

that it is hosting the Push-Config feature for. Each remote site must be assigned a node number. This is

the node number that is assigned to the remote site whenever it connects to this hub unit. It stays the

same regardless of the aggregate that is used to connect to the hub site – this allows for static mappings

on hub-site tributaries and directory tables used to connect to the remote site tributaries.

Once the hub-site has authenticated the remote site that is attempting to connect, the hub-site pushes

the configuration across the aggregate. The configuration that is pushed comprises the system

configuration from the hub unit and the stored configuration for the remote unit that is connecting. The

system configuration from the hub site is filtered to ensure that the correct node number and node name

is sent to the remote site, and also to ensure that we do not send the hub site’s access passwords across

the link. Note that the link used to push the configuration may be a shared outbound aggregate, and only

the remote unit that requested the configuration should install it. The pushed operation contains

4.4.1.1 Multi-unit configuration at hub site for remotes

4.4.1.2 Remote Unit Identification

4.4.1.3 Pushing the Config



checksumming and retry mechanisms to ensure that the whole configuration is transferred successfully

even on low quality aggregate links.

This configuration is applied to the remote unit (as the active configuration). However the configuration is

not stored in the remote unit. When the configuration is applied on top of a remote startup config (see

later section), the startup configuration is reapplied to ensure that the aggregate mechanism for accessing

the hub site remains in place.

When a remote unit receives a pushed configuration it installs a default (all nodes) route in its route table

via the aggregate link used to connect to the hub. At the hub site, inferred routing is used to install a

route to the remote site.

The default configuration for a remote unit sets a serial data port in aggregate mode for a RS449 interface

with external clocking. If this is good enough to establish a link to the hub unit then no configuration is

required on the remote unit. However, if a different serial data port configuration is required for the

aggregate link or an IP aggregate is to be used, then a basic configuration containing enough details to

access the hub unit is required. This portion of the configuration is maintained following reception of the

pushed configuration from the hub site. In other words, if the pushed configuration attempts to

reconfigure the aggregate link setup in the start-up configuration, the reconfiguration will not work. The

default client Push-Config screen is shown below:

4.4.1.4 Automatic Routing

4.4.1.5 Start-up Configs for Remote Units



A DTE presentation is assumed for the Push-Config aggregate port. The Electrical Interface, RXC Source

and TXC Source fields may be programmed as follows:

INTERFACE RS449, V.11, RS232, V.35, RS422, V.36

Electrical interface standard used on the port.

Ext, RX clock input from the interface RX CLOCK SRC

Txc, RX clock output, looped from TX

Ext, TX clock input from the interface

Rxc, TX clock output, looped from RX

TX CLOCK SRC

PLL, TX clock output, derived from PLL

The Push-config technique may also be used successfully over IP aggregates by toggling the “Aggregate

Type” field to “IP”. This allows access to enter the basic parameters as follows:

Here, the client remote must be programmed with the minimum basic IP parameters of Address, Mask

and Nexthop Gateway in order to connect to the host. The “DEF GW OVERRIDE” field permits or denies

configs pushed out from the host to override the default values stored in this menu. The “AGG ADVANCED

PARAMS” selection displays the following screen:



Here is it possible to configure some advanced options such as the TOS value, Mux or Resequence delays

and other parameters for use on the Push-Config IP Aggregate if desired. Refer to the IP Aggregates

section 2.4.9.3.11 for details.

The factory default configuration mode for V25, V50plus and V150 will be for Push-Config operation. If

locally set and stored configurations are required, then this mode should be disabled (see section 2.4.1 for

more information).

Once a remote unit has its pushed configuration it will operate as normal. However if the aggregate is lost

for more than the connection timeout, the pushed configuration is removed and the remote unit attempts

to retrieve a new configuration from the hub unit. This means that if a remote unit is connecting to a

different hub the Push-Config only works correctly if the aggregate is down for at least the connection

timeout between disconnecting it from one hub and reconnecting it to the new one.

4.5 Call Progress Tones

With the ability to dynamically route telephone calls through the network, the multiplexer can act as a

small PABX. It is therefore the case that in order to provide the subscriber with meaningful information

while a call is connected, the multiplexer must provide audible call progress tones. Many applications for

the multiplexer involve a satellite delay between subscribers and so no tones are generated for 600mS

after a call sequence is commenced, to avoid confusion during the latency.

4.4.1.6 Reconfiguration Control



In the simplest scenario, the telephone is lifted and if bandwidth is available via the prescribed route and

the destination party is not busy, the call is connected and the caller hears a ringing cadence, according to

the country code selected, until the call is answered.

If the call is connected but the destination party is busy, the caller hears an “unavailable” tone pattern

(long beeps, slow repeat).

If after the initial 600mS, the call setup has not completed (this can be the case with DAMA networks) but

the call timeout has not been reached, the caller will hear a “call pending” tone pattern (fast beeps, fast

repeat). This will give way either to the ringing tone pattern, if successful or to the “unavailable” tone

pattern if the call fails or times out.

4.6 Dynamic Bandwidth Allocation

The versatility of the multiplexer is a direct result of its packetised data transport architecture. Voice/FAX,

IP, bridged, synchronous and asynchronous data are processed in a prioritised manner which reflects their

individual demands for bandwidth.

The primary contention for bandwidth comes from Voice/FAX channels, which demand bandwidth when a

call is active and from synchronous data channels, which either demand permanent bandwidth as in the

case of a transparent channel, or which may demand bandwidth on a sporadic basis according to the

traffic they carry. Dynamic Bandwidth Allocation (DBA) on the multiplexer data ports uses a sophisticated

internal rate-change protocol to resolve the problem, which allows bandwidth to vary dynamically (on DBA

ports) in both transmit and receive directions independently.

Data channels may be set to operate at any speed up to 10.24Mbps. In DBA mode, the maximum clock

frequency of a synchronous tributary channel is configured by the user and the multiplexer then varies the

actual clock rate applied to the channel according to traffic demand. DBA mode uses the channel’s RXC

and TXC phase-locked loops to generate an internal clock which is output to the connected device.

Following any successful new connection, which is routed through the same aggregate as the DBA sync

channel, the multiplexer calculates the highest permissible clock rate that is consistent with a total

capacity of 87.5% on the chosen route and smoothly varies the output clock to the connected device. This

allows a LAN Router with a relatively low loading factor to operate without penalty while the multiplexer

simultaneously supports a voice/FAX call. As the voice traffic increases, the multiplexer is able to

successively reduce the clock speed to the Router so as to permit high-priority calls to be made at the cost

of minor and temporary reduction in Router throughput, which will probably go unnoticed by the LAN

users. The clock rate is successively restored as soon as competing connections are closed again.

By convention, the TX clock at the local end sets the originating DBA maximum rate and the RX clock at

the far end sets the terminating DBA maximum rate. They should be set equal and must both be set. The

multiplexer also supports asymmetrical Dynamic Bandwidth Allocation to cater for those cases where

network topology produces different bandwidth demands in each direction on an aggregate. In this case,

the above rules are still obeyed, but the local TX/remote RX rate and the local RX/remote TX rate are set

to different maximum values. In most cases, DBA will be used to drive bandwidth-agile devices such as



routers and therefore will be used in V.11 single-clock mode. Here the DBA RX and TX rates are set the

same throughout the connection, with the RX clock sources set to TXC. As with all other cases where the

phase-locked loops are used, the clock reference(s) must be sourced from the correct internal global clock

bus (GRX or GTX).

All data channels configured with “DBA” clock source are assigned a pool of dynamic bandwidth, which is

distributed between them in proportion to their configured bit rate. The multiplexer smoothly adjusts

the clock speeds on all DBA ports whenever a change occurs in the DBA pool. The rate-change

calculations are performed at both ends of the connection, with the overall size of the dynamic bandwidth

pool limited by the lowest link bit rate across the network.

Asynchronous channels are treated in a similar way, where the configured channel bit rate again defines

the proportion of the DBA pool allocated, but this time to the internal connection between the two ends,

since the local connection speed out of the port must be set as configured. One extra feature takes

advantage of the bursty nature of async data: when data stops, the internal connection speed drops to a

nominal 2400bps (or the port speed, whichever is the lower) to maintain the connection ready for use

while returning most of the bandwidth to the DBA pool. When the next data character is received by the

port, the internal connection rate resumes its normal DBA level. In this way the multiplexer maximises

bandwidth use automatically, without the user having to intervene or precalculate any bit rates.

IP and bridge tributaries also participate in the DBA scheme. The DBA rate configured for an IP/bridge

tributary is the originating DBA maximum rate.

At all times the multiplexer optimises buffering and delay so as to maintain voice quality and efficient data

transfer. Packet lengths are constantly adapted to match the varying traffic demands of all channel types.

4.7 Asymmetric Bandwidth

The multiplexer is capable of considerable flexibility in clocking schemes and may operate RX and TX clock

independently and at different rates.

Each direction can use a Phase-Locked Loop (PLL) to generate a clock, which may use either Global clock

(GRX or GTX) as its reference. Each PLL is capable of generating an output clock at any rate from 800bps

up to 512Kbps in steps of 800bps and from 512Kbps to 10.24Mbps in steps of 8Kbps. Below 800bps, any

multiple of 25bps from 50bps upwards may be generated.

4.8 Clocks

4.8.1 Direction Conventions

Every data port supports the same functionality whether it is used as a tributary (DCE) or an aggregate

(DTE), the choice being defined by software. By convention, the Receive Clock “RXC” is defined as “the

clock associated with the direction of data flow from aggregate to tributary” and the Transmit Clock “TXC”

as “the clock associated with the direction of data flow from tributary to aggregate”. This assumes that



aggregate ports are normally DTE presentation and tributaries are normally DCE, so for an aggregate, RX

data is input and TX data is output whereas for a tributary, RX data is output and TX data is input.



4.8.2 Global Clocks

There are two Global Clock busses internal to the V200 chassis, the purpose of which is to make a

common, stable clock signal available to all resources in the system. These are referred to as the “GRX”

and “GTX” clock busses. GRX and GTX may be referenced to the RX or TX clock from any port and are

used as the stable reference source for all of the PLLs on any card in the system. Generally, one of them is

associated with the input data clock of the aggregate nominated as the master clock source. This one is

then used as the reference source for all tributary ports. GRX and GTX are entirely equivalent and

interchangeable. For the purposes of the following discussion, GRX is used throughout. NOTE:

V25 supports only a single reference clock – GRX.

The GRX clock bus is driven by the output of a VCXO which produces a stable frequency of 6.144MHz.

Phase-locked loops on the line cards use this as their reference frequency to produce any clocks required

by the card. A Gate Array provides the ability to select the clocks (a) used on the interface and (b) routed

to the backplane. It also provides the ability to select clocks for DTE mode or DCE mode on the interface.

In the example below, part of a serial card is shown in DTE mode with a PLL output routed to the TT pin

on the serial port under the control of the Gate Array (red). At the same time the RT signal from the port

is routed to the backplane Gate Array, which contains logic to lock the VCXO to it (blue).

Using this technique, it is possible to onward-link a clock without degradation from any port to any other

in a V200 network, even if it is located in another chassis or even in a remote location via a satellite link.

Any number of PLLs may use the GRX or GTX busses as their reference (<GRX or <GTX on the menus).

VCXO 6.144MHz

Serial Port

Gate Array

V200 Backplane

GRX Bus

Line Card

DTE PHY

DCE PHY

RT ST TT

other line cards…

Gate ArrayPLL Pool



4.8.3 Receive Clocks

The RXC signal is selected from four possible modes:

(i) “EXT”: The external interface

(ii) “TXC”: The channel TX clock

(iii) “PLL”: Derived from a Phase-locked Loop

(iv) “DBA”: PLL derived as (iii), but the rate can be dynamically varied

A block diagram of the clock logic is shown below, simplified to show only the GRX clock bus and the

selection of RXC clock sources in DTE mode:

Gate Array

VCXO 6.144MHz

Serial Port

Gate Array

V200 Backplane

PLL Pool

GRX Bus

Line Card

DTE PHY

DCE PHY

RXC TXC TT

other line cards…

CPU“TXC”

“PLL” “DBA”

“EXT”



4.8.4 Transmit Clocks

The TXC signal is also selected from four possible modes…

(i) “EXT”: The external interface

(ii) “RXC”: The channel TX clock

(iii) “PLL”: Derived from a Phase-locked Loop

(iv) “DBA”: PLL derived as (iii), but the rate can be dynamically varied

…with the addition of two further modes in DCE mode on a tributary port only:

(v) “TTP”: Terminal Timing from external device with ST generated by PLL

(vi) “TTD”: As (v), but the ST rate can be dynamically varied by the V200

These modes are provided to allow a tributary port to supply a phase-locked ST clock to the DTE whilst at

the same time allowing TX data to be clocked into the V200 using the TT clock. This is necessary when the

TT clock is derived by the DTE from the ST clock and used to actually clock the data back to the V200. For

simplicity, the RX clock is shown with “PLL” selected and the interface is in DCE mode:

VCXO 6.144MHz

Serial Port

Gate Array

V200 Backplane

TX PLL

GRX Bus

Line Card

DTE PHY

DCE PHY

RT ST TT

other line cards…

CPU“RXC”

“PLL”, “DBA”

“EXT”, “TTP”, “TTD”

RX PLL

Gate Array



4.8.5 Phase-Locked Loops

All data ports have access to a pool of Phase-Locked Loops (PLLs) for the independent derivation of RXC

or TXC. The reference clock for the PLLs is derived from either the GRX or the GTX global clock busses as

selected on the configuration menu. The PLLs allow data ports bit rates to be derived in steps of 800Hz up

to 512Kbps and in steps of 8Kbps up to 10.24Mbps. See Table 1*PLL rates for details.

During DBA rate changes (see Section 4.6) a Glitchless Transition Machine ensures that clocks change

rate smoothly without truncation, thereby avoiding data discrepancies between the V200 and the

connected device.

4.9 Broadcast Mode

The path from a hub unit to a number of remotes is a Broadcast Mode link (shared outbound aggregate).

To use Broadcast Mode, the data port on the hub multiplexer must be configured as PMP mode via the

DATA menu (see Section 2.4.9.1).

When configuring a shared outbound link, the port at the hub site that is the source of the shared

outbound must be configured as point-to-multipoint (PMP) in the DATA menu if (and only if) the return

path from one of the remote sites comes back via the same shared outbound port. The ports on the

remote sites that receive the shared outbound traffic should be configured as Aggregate (Agg) ports.

The remote multiplexers on the shared outbound must be configured with routes to handle all destinations

that use the same shared outbound - this is necessary even if the remote sites do not need to

communicate with each other. The correct configuration should be that routes to all nodes that are

configured at the hub site to use the shared outbound should also be configured to use the returning

outbound port at the remote site (except the remote site route itself). Therefore if the default route (ANY

node) uses the shared outbound at the hub site, a default route (whose aggregate is the received shared

outbound connection) must be configured at each of the remote sites as well.

4.10 Async Error-correction and Compression

This feature allows individual async channels to operate error-free over a satellite link. It does not affect or

relate in any way to bulk error-correction that may be taking place within the satellite modem or

aggregate link.

Asynchronous channels have a single-character field displayed to the right of the “FORMAT” field when the

channel is configured into an async mode.

The field allows three selections as follows:

“R” – Raw Data is passed without error-correction or compression.

“E” – Error-correction only Data is error-corrected.

“C” – Compression Data is error-corrected AND compressed.



In Raw mode, async data is transferred transparently. The compression mode intrinsically uses error-

correction, since the compression tables cannot work reliably otherwise.

4.10.1 Error-correction

The error-correction function is based on 100mS time periods. Data received by the tributary port is

buffered into a 100mS superframe irrespective of channel rate, which is then split into a number of

smaller sub-packets according to Dynamic Bandwidth Allocation (DBA) requirements. For example, if the

channel is configured with a baud rate of 115,200bps then there will be approximately 800 characters per

superframe buffer, which is then sent as a number of small HDLC frames depending on the internal DBA

rate, or the size of the logical connection on the aggregate which is allocated to the channel. The

underlying rule here is that no subframe or packet on the aggregate should occupy more than 20mS on

the aggregate.

The error-correction has a window size of 128, so it can correct up to 128 100mS buffers of continuous

data, representing roughly 128Kbytes of data at 115,200bps. For surfing/browsing this would improve,

since the data is much more sporadic.

In practice, only 75% of this buffer is used for safety reasons, before flow control is asserted at the port.

This means that at worst case, the error-correction can survive up to 9 seconds without receiving a good

frame.

The principle used for error-correction uses a NACK-only protocol. This means that a negative

acknowledgement packet is sent back whenever a good frame is received out of sequence, since at least

one frame in the middle must be missing. This NACK asks for the retransmission of frames starting with

the first missing one.

Errors experienced on the link affect the whole 100mS superframe, which has to be retransmitted. When

the error rate approaches 1 in 10e4 to 1 in 10e5, the error-correction will start to fail since every

superframe will be received in error. The technique therefore starts to reach a useful limit at error rates of

around 1 in 10e5.

When the channel input buffer reaches 75%, as caused by a poor link, insufficient bandwidth or loss of

carrier, the CTS signal on the port is dropped by the multiplexer. This signal must be connected to the

DTE for the error-correction to work. Loss of carrier is then handled by asserting flow control to stop

the input data. Realistically, this means that a channel should continue without data loss through carrier

losses of up to at least 5 seconds PROVIDED it is configured so that it does not lose any data. NOTE:

“The Data Channel Flag” parameter on the SYSTEM menu must be set to “Follows Alarms” for

the error-correction to work properly. If the connection is lost for more than 30 seconds then the

channel dumps all data, deletes the compression and restarts.



4.10.2 Compression

The data compression feature uses a derivative of the Lempel-Ziv algorithm with a code size of 12 bits.

The algorithm runs above the error-correction layer, which is always enabled when data compression is

selected.

The 100mS data buffers are compressed and fed into the error-corrector, which builds up a table of 12-bit

codes according to the data coming in. If the code table ever fills up completely (i.e. all 212 Code entries

are used) then the table is reset and begins to accumulate all over again. Similarly, the compression is

turned off whenever the throughput reaches 100%, in which case there is no gain achievable and the data

is passed transparently.

The compressor also stops operating when the channel goes idle for more than 0.5 seconds and drops

into transparent mode. This is to optimise the transfer of single characters or sequences of data less than

four characters – the compression will only start again when a block of at least four characters are present

in a buffer. If for any reason, the compressor turns off, perhaps during a sequence of incompressible data,

then it will retry after 5 seconds. This allows it to pick up again to optimise transmission automatically.

4.10.3 General Characteristics

Error-correction or compression on channels below 4800bps may start to impose excessive delays. The

usefulness of this feature should be carefully assessed before configuration.

The operation of the error-correction facility imposes a processing burden upon the host. Testing has

indicated that a safe performance limit of up to four channels per chassis running at 57600bps should be

observed to prevent any adverse effects on the normal functioning of the unit. Performance degradation

may be indicated by a slowing of the supervisor update speed.

4.11 Switched Carrier Operation

Aggregate ports are usually connected via a fixed carrier network, for example a VSAT link. However, the

multiplexer also permits operation over switched carrier links where the circuit is available on a temporary

basis such as DAMA or SCADA networks.

4.11.1 SWITCHED Mode

In this mode the multiplexer Aggregate port is connected to a switched service such as an Inmarsat-B

terminal, where the link is inactive and the multiplexer has no carrier with the remote unit until the ISDN

link is established. The modem needs to be told when to establish carrier by the mux and this will happen

when stimulated by a tributary port being activated. For example, when a telephone call is made from a

channel on the mobile unit, link bandwidth is required. This causes the aggregate port to raise the “C” or

“RTS” signal, which causes the Inmarsat terminal to request service. When the ISDN link is established,

the Receiver Ready (RR) signal from the terminal indicates that the connection may proceed, the

multiplexers establish carrier, a call setup packet is sent to the hub unit and the user hears dialtone from

the PABX. The call proceeds in the normal way until cleared, either by the mobile multiplexer, which drops

the “RTS” signal to the terminal when the handset is replaced or by the hub multiplexer which clears the



ISDN call when the line is dropped by the PABX. In both cases the “RR” signal is dropped by the terminal

and carrier is lost.

To configure the multiplexer to operate in this way, the aggregate port connected to the Inmarsat

terminal must be configured with the word “SWITCHED” entered in the destination field. In addition, the

“Connection Timeout” and “Receive Ready Filter” fields on the SYSTEM SETTINGS page become relevant.

When an Inmarsat terminal establishes carrier, the RR signal can be unstable until the link is securely

established. The Receive Ready Filter ensures that the multiplexer waits for the signal to stabilise before

sending its first packet. The ISDN system connection time can be quite long (up to 30 seconds is quite

common on Inmarsat networks) and so the Connection Timeout may be adjusted to ensure the

multiplexer does not give up too soon.

One final point to note is the clocking regime used with the switched system. Inmarsat terminals

commonly maintain a 64Kbps clock at all times irrespective of the connection state; in this case the

conventional scheme is used where the RX Clock is driven on to the GRX bus. With DAMA modems, since

the carrier is not permanently present, the mux must provide a TX clock to the modem at the intended

rate. This must also be used as the reference for the voice card, which generates call progress tones

during the connection sequence. A standard configuration is shown below:



4.11.2 SCADA Mode

The aggregate port should be configured with the word “SCADA” entered in the destination field. This

causes the port to adopt the SCADA packetised frame structure which supports the connection protocol of

the RF terminal to which it is connected:

The terminals are referred to as “RT” (or Remote Terminal) units. It is essential that on the ROUTING

page, a route to each potential destination RT is entered explicitly, so that the unit knows which address

to transmit when establishing a call. This is done in the “Connect Using…” field on the ROUTING page and

must be of the format “RTnnn” where nnn is a numeric field. It may contain up to 14 digits and will be

transmitted to the local RT when the call is established:



Notice that all RTs are accessed over the primary route 0:1. This is because in our example, Port 1 of the

chassis is used as the aggregate port in SCADA mode and is connected to the local RT unit. All other units

must be programmed in a similar way (they will of course contain a route to Node 0, our local node) and

then voice calls may be made between any stations.

As with the standard fixed-link mode of operation, destination channels for voice calls may be either

entered as specific channel numbers for hotline operation or left in “AUTO” mode, when the multiplexer

destination channel number is dialled on the telephone. Thus, to place a telephone call to voice channel 3

in Option Card 1 of Node 2 from anywhere in the network, pick up the receiver and dial “213”. The routing

menu tells the unit how to reach Node 2 and which destination RT number to transmit to the local RT to

establish the link. Once the link is established, the rest of the dialled number tells the receiving unit which

channel to route the call to.

During placement of the call it is normal to hear a succession of rapid beeps denoting establishment of the

link. This will then be followed by a ringing tone when the connection is made. If the link cannot be

established due to network congestion, the user will hear the normal “busy” tone in the handset.

All of the normal multiplexer voice channel facilities are still available in SCADA mode and so for example

may be used to connect to PABX extension ports in FXO mode or between PABXs over the 4-wire Tie-line

interface. Group III FAX machines or modems may also be used.

To prevent any unintended call or bandwidth charges, Voice Activation may be utilised.



4.12 The Integrated IP Router

4.12.1 Overview

This section describes the basic concepts behind the integrated IPV4 router available on each CPU card. It

is assumed that the reader has a basic understanding on the operation of an IP router and the operation

of other services in the multiplexer. The section includes configuration examples for typical installations

and troubleshooting tips – however, it is not intended to fully describe the user interface – please refer to

the MENUs section for these details.

4.12.2 Basic IPV4 Routing

The multiplexer integrated IP router forwards data from one LAN to another across a multiplexer WAN

link. This is achieved by establishing a connection from one node to another and assigning it a maximum

bandwidth over the aggregate in a similar way to a DBA data channel. Once this is established, the IP

router at each end performs the filtering or forwarding of all traffic relevant to the remote network

according to a manually entered static route table. The router may act as a local DHCP server and

supports UDP broadcasts to support WindowsTM applications.

4.12.3 Network Configuration

The multiplexer includes routing software for forwarding IP data between the 10/100/1000base-T

Ethernet ports and aggregate ports. To utilize this facility, the multiplexer must be configured with

information about the IP sub-networks that the multiplexer network is interconnecting. All configurations

must include at least:

IP address and subnet mask for the Ethernet port(s)

Configuration of how the IP router connects to the multiplexer network

Configuration of static IP routes

Configuration of the first two components is done through the NETWORKS screen of the IP sub-menu. The

NETWORKS screen describes how the IP router connects to both the local LAN (or LANs) and the

multiplexer WAN network.

The Ethernets are represented in the user interface with the port names “ENET1” and “ENET2”. The

Ethernet must be configured with the IP address of the Ethernet port on the local network, and the mask

of the local subnet. Any host stations (PCs), or routers on this local network, must be configured to use

the IP address of the multiplexer Ethernet as the next-hop gateway for all IP networks that the

multiplexer is providing interconnect services for. In the example below, the Ethernet port has been

configured with the address 192.168.1.1, and the mask 255.255.255.0 – this mask will allow the

configuration of 253 other IP stations on the local network (two addresses are also reserved for broadcast

use). The Maximum Transmission Unit (MTU) in bytes is typically left at the default value of 1514 for the

Ethernet port. The UDP Gateway (UDPGw) option is discussed later in the UDP relay section. The DBA and



Destination fields are not used for the Ethernet port. The IP field is be fixed at NUM (for standard

numbered packet support) for the Ethernet port.

Example of IP Subnet configuration for Ethernet

With just a single IP network entity configured on the Ethernet port, the multiplexer can communicate

with IP stations on the locally connected network, but will not yet route IP traffic over the multiplexer

network. Further network entries must be configured for this – however, unlike traditional wide-area

network routers, IP networks are not configured directly for the aggregate ports to the multiplexer

network as this would by-pass the multiplexer bandwidth management facilities provided by the

multiplexer data router. Instead, the concept of virtual ports (see below) is used to represent the wide

area networks of the IP router.

4.12.4 Virtual Ports

IP connectivity is provided across the multiplexer network as a set of point-to-point connections between

multiplexers with integrated IP capability. The IP router forwards traffic between the Ethernet ports of

pairs of multiplexers via the multiplexer network. A point-to-point connection between the IP router on a

multiplexer and the corresponding IP router on a peer multiplexer is represented by a virtual port, which

works in the same way as any other multiplexer channel but does not have a physical connector.

The IP router is fully integrated with the other multiplexer services. It interfaces to the multiplexer Data

Router for interconnectivity across the multiplexer network. The multiplexer Data Router is built on the

concept of connecting peer logical ports across the multiplexer network via aggregate links. Each tributary



has a port number that is unique within the multiplexer network. The diagram below shows how the

integrated IP router interfaces with the multiplexer Data Router via these tributary ports, and includes a

voice card for comparison.

Data Router

Aggregate Ports

Tributaries

VoiceCard (e.g.)

Voice Channels

IP Router

IP Subnets for WAN

IP Subnet for Ethernet

The Interaction of the IP Router with Data Router

Tributary ports are represented by a port number. These typically provide information about the location

of the tributary port – the 4 voice ports on a voice card are represented as n:s:c, where n is the node

number, s is the slot number that the voice card is inserted in, and c is the channel number within the

voice card. A set of special virtual ports has been reserved to represent the IP router WAN ports. These

follow the standard multiplexer port terminology of n:s:c. The slot component of the channel identifier is

the slot number of the CPU card that the integrated IP router and 10/100/1000BT Ethernet ports are on.

Channels 10 to 99 have been allocated for IP router operation. A separate channel is required for each

integrated IP multiplexer router that this unit peers with. The network configuration requires that the peer

channel is configured for each channel configured on the local router. In the example below, Node1 is

connected to both Nodes 2 and 3. The integrated router on all three nodes is in slot 0. Channel 0:10 on

Node 1 is peered with channel 0:10 on Node2. Channel 0:11 on Node1 is peered with Channel 0:10 on

Node 3.



Example of virtual port use

4.12.5 Unnumbered IP

The integrated IP router acts as a half-router – a pair of IP routers connected via the multiplexer network

provide the full router operation. To preserve IP addresses, the point-to-point link between the

multiplexers does not require an IP subnet configuration. When IP traffic is routed over the point-to-point

connection, it can only be received by the peer unit, and therefore IP addressing is not necessary. If host

IP services are run from the multiplexer across the multiplexer network, then the IP address on one of the

Ethernet ports can be used as the source address for host communications. The sample IP NETWORKS

menu page below shows the configuration of the IP virtual ports for Node1 from the earlier example.



Example configuration of IP virtual ports

Each virtual port requires a DBA (Dynamic Bandwidth Allocation) and Destination configured. The DBA is

the maximum bandwidth (in bits per second) of IP traffic that can be sent to the peer multiplexer – the

actual amount is determined by the data routers in the multiplexer network according to other offered

loads). The destination is the virtual port identifier on the remote device that we are peering with.

The IP field indicates that we are running unnumbered IP across this link – the IP address and mask

should match the ENET address and mask to allow for host operations from this virtual port. The MTU

(maximum transmission unit) is discussed below.

One quirk of IP unnumbered operation is that IP routes that are configured for IP networks across the

multiplexer network must be configured with a next-hop that identifies the unnumbered link to transfer

that data across, instead of an IP address of the next-hop gateway. This is discussed further in the section

on Static Routes.

4.12.6 MTUs

The Maximum Transmission Unit or MTU for an IP network specifies the largest datagram that may be

transmitted on to that network. Routed packets that exceed the MTU for the onward network are

fragmented before transmission over the multiplexer network and are reassembled by the peer

multiplexer unit. The default MTU for the Ethernet is 1514 – this allows transmission of the maximum

sized Ethernet frame (the 4-byte CRC is not included in the MTU).



Most servers are on segments with large MTUs, but it is increasingly common for internet users to be

connected via links with reduced MTUs, so it is becoming common for some packets to be too big. How

the problem of oversize packets has been handled has evolved considerably over time. The original

approach was to send only small packets corresponding to the TCP/IP default MTU (576 bytes). (To this

day, a sending system needs permission from the receiving system to send larger packets, but that

permission is given as a matter of routine.) For some packets, especially those sent by older equipment,

an oversize packet can be sent by breaking it into fragments and sending the fragments as smaller

packets. The fragments can be reassembled downstream to reconstruct the original large packet, but this

packet fragmentation has several problems involving both efficiency and security.

Newer servers try to optimise their transmissions by discovering the path MTU and sending packets of the

maximum size when there's enough data to fill them. The procedure for doing this was standardised and

published as in RFC 1191 1990, but it did not become widely deployed until years later. By mid 2002,

80% to 90% of computers on the internet used Path MTU Discovery.

The basic procedure is simple - send the largest packet you can, and if it won't fit through some link get

back a notification saying what size will fit. The notifications arrive as ICMP (Internet Control Message

Protocol) packets known as "fragmentation needed" ICMPs (ICMP type 3, subtype 4). The notifications are

requested by setting the "do not fragment" (DF) bit in packets that are sent out.

Some network and system administrators view all ICMPs as risky and block them all, disabling path MTU

discovery, usually without even realizing it. Of the several dozen ICMP types and subtypes, some do pose

some risk, but the risk is mostly mild and is of the "denial of service" nature. That is, an attacker can use

them to interfere with service on and from the network.

By blocking all ICMPs the administrator himself interferes with service on and from his own network.

Unless he also turns off path MTU discovery on his network's servers, he makes his servers unusable by

users with reduced-MTU links in their paths. Because service is affected only in relatively unusual cases, it

can be difficult to convince the administrator that a problem exists. The prevalence of such "unusual"

cases is growing rapidly though. Administrators who want to block all ICMPs should disable path MTU

discovery on their computers, especially on their servers. It makes no sense to ask for ICMP notifications

and then refuse to accept them. In addition, doing so opens the server to a special type of distributed

denial of service attack based on resource exhaustion from a large number of fully-open connections.

Clearly all of the above requires careful setup by the network administrator but it can still lead to basic

incompatibility when trying to access certain internet servers. The other disadvantage is that even if

reduced MTUs are allowed, the fragmentation potentially resulting from it causes a significant additional

overhead due to the increased number of packet headers (each typically containing 20 bytes in an IP

packet) and ultimately reduced throughput due to the burden of additional packet processing. The IP

Router avoids this by providing its own proprietary fragmentation over the multiplexer WAN network,

which uses only a 4-byte header to optimise throughput, while appearing to pass the original packets sent

by the network transparently. Setting the multiplexer MTU requires some care in configuration to avoid

degradation of the quality of voice channels (or other services) that are multiplexed across the same

aggregates as the IP traffic. It is recommended that a value for the multiplexer MTU is calculated which



avoids the creation of any packets that will take longer than 20ms on the slowest aggregate between the

local multiplexer and its peer. The MTU should be set according to:

MTU = LS/400

where LS is the slowest link speed (in bits per second) on the aggregate link to the peer. If the calculated

MTU exceeds the MTU for the Ethernet, then the MTU for the multiplexer channel should also be set to

1514. In the case of a link running at 64Kbps, the MTU should therefore be set to (64000/400) = 160.

Note that fragmentation has an overhead in both the computation required on the multiplexer, and the

bandwidth required to send data (each fragment carries an IP header), and you should avoid setting the

MTU below the recommended value unnecessarily.



The implementation of Routing Information Protocol version 2 (RIPv2) is described in IETF RFC

2453/STD56 and is provided as an extension to the existing embedded IP router functions within the

Vocality multiplexer family. This functionality simplifies the integration of Vocality multiplexers within

customer’s IP networks as it removes the need to configure static routes on both the mutliplexers and IP

gateways. It also allows for dynamic re-routing of IP traffic when network components fail. RIP may be

used on both the LAN interfaces and the IP tributaries across the Vocality network. When used across the

IP tributaries, any bandwidth required for protocol datagrams is shared with other IP routed packets taken

from the dynamic bandwidth allocated for that tributary.

Each device must be configured for RIPv2 operation or with static routes to tell it how to reach IP

networks other than the one that it is locally attached to. A RIPv2 menu screen is provided under the IP

sub-menu to configure RIPv2 operation.

RIPv2 should not be used on the IP Tributaries in situations where the tributary operates across a

switched aggregate since the RIP updates will keep the aggregate permanently established. The following

features are supported:

• Import Control

Enabled/Access/Disable

• Metrics

• Export Controls:

Enable/Disable/Filter Static/RIP routes

Enable/Disable/Filter OSPF routes

Enable/Disable/Filter local interface routes

• MD5 authentication

• System wide poison reverse control

Support for the Open Shortest Path First (OSPF) protocol (as defined in RFC 2328) is also included. OSPF

is a router protocol used within larger autonomous system networks in preference to RIP, an older routing

protocol that is installed in many of today's corporate networks. Like RIP, OSPF is designated by the

Internet Engineering Task Force (IETF) as one of several Interior Gateway Protocols (IGPs).

Using OSPF, a host that obtains a change to a routing table or detects a change in the network

immediately multicasts the information to all other hosts in the network so that all will have the same

routing table information. Unlike the RIP in which the entire routing table is sent, the host using OSPF

sends only the part that has changed. With RIP, the routing table is sent to a neighbor host every 30

seconds. OSPF multicasts the updated information only when a change has taken place, making its use of

bandwidth resources considerably more efficient.

Rather than simply counting the number of hops, OSPF bases its path descriptions on "link states" that

take into account additional network information. OSPF also lets the user assign cost metrics to a given

host router so that some paths are given preference. OSPF supports a variable network subnet mask so

4.12.7 RIPv2 and OSPF



that a network can be subdivided. RIP is supported alongside OSPF for router-to-end station

communication. Since many networks using RIP are already in use, router manufacturers tend to include

RIP support within a router designed primarily for OSPF.

The following features of the OSPF protocol are supported:

• Control per router interface

• RFC1583 backward compatibility mode

• Access control

• Normal, Stub & NSSA Areas

• Simple & MD5 authentication

• Virtual Links

In the Vocality implementation, policies for controlling which routes are used and how they are used may

be configured on the unit. This provides some control over:

RIP export policies

OSPF export policies

Route aggregation

Route preference between different route sources

The implementation of RIPv2 is compatible with RFC2453/STD56. The implementation includes split

horizon with poisoned reverse to avoid routing loops. Triggered updates are also sent to speed up network

convergence. Updates are triggered when routes change and/or interfaces (Ethernets or IP tributaries) go

up or down. Route summarization is not supported. All timers used in the RIP process use the values

specified in the RFC:

• Unsolicited response every 30 seconds

• Route timeout after 180 seconds

• Route garbage collection after a further 120 seconds

• Route updates received on a LAN interface will be verified to ensure that the router that sourced the update is recognised as being on the same subnet that is configured for that interface.

Note that there is no support for RFC2082 – RIP-II MD5 authentication.

Each IP network interface configured on the multiplexer may have RIPv2 support either enabled or

disabled. When enabled the multiplexer generates and processes RIP messages on UDP port 520. When

disabled, the multiplexer does not open access to this port.

The default value for RIPv2 support is DISABLED. If RIPv2 is enabled on an IP tributary interface, it is

expected that the RIPv2 feature is also enabled on the peer IP tributary across the Vocality network.

4.12.7.1 Compatibility



4.12.8 Static Routes

If the RIPv2 and/or OSPF protocols are disabled, each multiplexer IP router must be configured with static

routes to tell it how to reach IP networks other than the one that it is locally attached to. An IP STATIC

ROUTE TABLE menu screen is provided under the IP sub-menu to do this. Each configured route consists

of a description, a destination address, a mask for the destination address and a next-hop. The

“Description” is a text field used to identify a route in the configuration. The “Next-hop” is either the IP

address of the next-hop gateway on the local Ethernet network, or the channel number for a unnumbered

link to a peer multiplexer across the IP network. When a route lookup matches more than one configured

route, the one with the longest mask (i.e. the most specific) is used to route the packet. A default route

(one to use if all other route lookups fail) can be configured by using a destination and mask value of

0.0.0.0. The following example shows a route table that will send all traffic to network

192.168.0.1/255.255.255.0 via the unnumbered link 0:10, and all other traffic to the next-hop gateway

192.168.3.100:

Example of IP Static Route Configuration

4.12.9 Loopback Interfaces

Loopback interfaces may be configured in the IP networks menus. These allow for a host (i.e. non-router)

address to be assigned to each of the Ethernet interfaces on the embedded router. These interfaces

remain up even when the associated Ethernet interface goes down. The addresses used on these

loopback interfaces can be used as the unnumbered source addresses for the IP tributary ports. These

addresses are typically an unused address on the Ethernet subnet.



4.12.10 Example Configuration

Portions of example configurations have been given in the above sections. This section gives a complete

example IP configuration for a simple 3-node network. Three remote networks are interconnected with

multiplexers. Node 1 is connected to the 1.1.1.0/255.255.255.0 network. Node 2 is connected to the

1.1.2.0/255.255.255.0 network. Node 3 is connected to the 1.1.3.0/255.255.255.0 network. The

multiplexer network provides connections between Node1 and Node2, and Node1 and Node 3. Virtual

ports 0:10 and 0:11 on Node 1 have been configured to communicate with Nodes 2 & 3 respectively. A

default network is not defined at Node1, so traffic from Node 2 and Node 3 networks will only

communicate with stations on the 1.1.1.0, 1.1.2.0 and 1.1.3.0 networks, and nothing beyond. The

dynamic bandwidth allocation and MTU for all multiplexer channels is set at 256000. A network diagram of

this example configuration network is given below:

Example configuration network diagram

The following six screen samples show the IP network and static route configuration for all three nodes to

achieve this topology:



Screen #1: IP Network Configuration for Node 1

Screen #2: IP Route Configuration for Node 1



4.12.11 UDP Relay

Standard IPV4 router operation does not allow for the forwarding of subnet broadcasts. However certain

network applications rely on the relay of UDP packets sent to the subnet broadcast address. For example

WindowsTM browsing service relies on Netbios datagram service packets (addressed to UDP port 138 and

the IP subnet broadcast address) reaching all stations within the browsing domain. To allow seamless

operation of such applications across the IP ports of a multiplexer network, the ability to relay UDP subnet

broadcasts has been provided. To enable such operation the UDPGw configuration must be turned to “On”

for each port that we wish the relay operation to work on. Additionally, an entry in the UDP relay table

must be added for each service that must be relayed. Some well-known service types are pre-configured

for addition to this table – other services require the appropriate UDP port number to be configured. The

example configurations shown in below show the configuration required to relay NetBIOS datagrams (UDP

port 138) and subnet broadcasts to UDP port 200 between the Ethernet and multiplexer channel 0:11

(but not to 0:10). Note the “NetBIOS Name” and “Domain Name” ports have also been included since

they will be required to get legacy WindowsTM networking working smoothly:

Example IP Network configuration for UDP relay

When using UDP relay care must be taken to ensure that broadcast loops are not introduced into the

network. The multiplexer will ensure that the affects of such loops are minimised through TTL reduction,

but network operation will still be adversely affected.



Example UDP Relay Table configuration

4.12.12 TCP Gateway –(TCP PEP)

The TCP gateway provides a TCP performance enhancing proxy (PEP) providing optimisation of TCP traffic

carried over high latency aggregates. To enable the optimisation the TCP gateway function must be

enabled on the IP network entries that the traffic is routed through. Up to 32 (255 on high-speed CPU

cards) simultaneous TCP connections may be optimised at any one time.

Note that the optimisation feature only applies to TCP traffic that is routed through the multiplexer, If the

TCP traffic is bridged, or the TCP traffic is encrypted within an IPSec tunnel then the optimisation is not

performed.

4.12.13 DHCP Client/Server/Relay

The multiplexer has three modes of operation for DHCP (Dynamic Host Configuration Protocol). The mode

and other DHCP parameters are configurable on the GENERAL page from the IP sub-menu.

The default mode is OFF – in this mode the multiplexer does not take part in DHCP operation – it is

assumed that all stations on the local network have a static IP configuration, or that a separate DHCP

server is available on the local network, or an externally routed network. When the product is not

configured for IP router operation, an external DHCP server can be used to assign an IP address to an

Ethernet interface. To achieve this, the Address and Mask fields in the IP NETWORKS menu should be

configured as 0.0.0.0. When the DHCP server assigns an address, a default route to the default router

assigned by the DHCP server is automatically installed in the IP route table.



Above: Network configuration when DHCP server mode is OFF

In SERVER mode, the multiplexer has an embedded DHCP server that will respond to received requests

from clients:

Above: Example network configuration for DHCP SERVER mode

The embedded DHCP server can provide the following host configuration parameters in response to

received DHCP requests:

IP Address, Lease Time, WINS Server, Domain, DNS Server Address

The DHCP server only operates on ENET1.



The IP address is assigned from the (inclusive) range configured in the GENERAL parameters – the

address range should be from the range of addresses on the subnet configured on the ENET port of the

multiplexer. This range should not contain the address configured for the ENET port itself however. The

DNS Server address sent to the DHCP client (the other side of the multiplexer network) must be entered

into the “DNS SERVER” address configured on the GENERAL page of the IP configuration. A secondary

server address can also be entered. Finally, the IP address of the WINS server and its domain name

should be entered. Note that these fields are used by the multiplexer in its name lookup for ping requests.

An example of the GENERAL page configured for DHCP server operation is shown below:

Example GENERAL page for DHCP mode

In RELAY mode, DHCP requests are relayed to a remote DHCP server through the multiplexer – requests

are relayed to the addresses configured in the primary and secondary server addresses in the DHCP

server configuration:



Example network configuration for DHCP Relay mode

For this example network, the DHCP relay parameters would be set as follows:

Example configuration of DHCP Relay parameters

Note that this configuration is required on both Node 1 and Node 2.

The DHCP relay operation only works on ENET1.



4.12.14 Telnet Access

The integration of an IP stack into the multiplexer allows the supervisor configuration screens to be

accessed through the Ethernet port using the telnet protocol. Telnet access is possible once IP has been

configured. To provide additional security to ensure that telnet access is only granted to the appropriate

parties, an Access Table has been provided. The Access Table must be configured to specify which station

or group of stations are allowed access to IP host facilities on the multiplexer. Each access table entry

comprises a description (simple text – not used in the access decision), an IP address, an IP mask, and a

service definition. When an attempt is made to access the host service (e.g. a telnet connection is

requested), the access table is checked to ensure that an entry matches the requesting host. An IP

address/mask pair of 0.0.0.0/0.0.0.0 will allow access from any station to the configured service. The

services that are controlled through this access are currently (i) the embedded telnet server, and (ii)

“Chargen” (character generator) TCP server.

The following example configuration shows two entries – one is allowing telnet access from any station –

the second is allowing Chargen access only from station 1.1.1.6:

Example configuration of the Access Table



4.12.15 Spanning Tree Protocol

The spanning tree protocol is an implementation of IEEE802.1d. The protocol may be enabled on

individual bridge ports by changing the Bridge mode in the Networks Menu (see Section 2.4.9.3.2). The

spanning tree protocol is used to detect and prevent loops in bridged networks. If the multiplexer is

bridging in a network topology that contains loops then the Bridge mode should be set to STP on each

port that makes up part of the looped network - the port takes part in the spanning tree protocol and

forwards bridged traffic when the spanning tree protocol determines the port is in a forwarding state. If

the multiplexer is bridging in a network topology that does not contain loops then the Bridge mode should

be set to On – the port does not take part in the spanning tree protocol and forwards bridged packets.

The spanning tree protocol operates between the bridges in a looped network, and produces a tree

structure of bridge ports. Ports that would complete network loops are put in a blocking mode and do not

actively forward bridged packets. The tree topology is determined by the relative priority of each bridge in

the network and the relative path cost assigned to bridge hops. The multiplexer bridge priority can be

configured here in the GENERAL menu. The port priority is set to a default of 128 and cannot be altered.

The relative path cost assigned to each bridge port is calculated as 19 for the Ethernet port and

(1000000000/assigned DBA rate) for multiplexer tributary ports. Note that the Spanning Tree Protocol

relies on the periodic sending of "hello" bridge protocol data packets. When the multiplexer is determined

to be the root bridge in the spanning tree network, the period of sending these "hello" packets is set to

the HELLO TIME configured in the general menu. This periodic sending of spanning tree protocol packets

makes the use of STP undesirable is dial-up networks.

4.13 IP Aggregates

The IP aggregate feature allows tributary services such as voice, data and IP to be transported across an

IP network between Vocality systems. All tributary services that are available across data aggregate links

are also available across an IP aggregate link - this means that Vocality's dynamic bandwidth allocation

scheme allows for bandwidth management of voice and data services across the IP network. A proprietary

protocol running over UDP provides an efficient mechanism for carrying data and voice or for tunneling IP

across any IP network. The protocol also allows for a reference clock to locked between the Vocality units

at either end of an IP aggregate.

Configuration parameters are provided to allow the user to optimize bandwidth usage, at the expense of

delay and jitter.

For optimum results, the intermediate IP network should be able to provide a guaranteed quality of

service (QoS). The IP aggregate can be configured to generate packets with a specific ToS marked to

allow the network to route the traffic with the correct QoS.

The Push Config startup menu can access the IP Agg configuration menu so that all aggregate fields can

be configured. The IP Push Config also allows for the DNS server to be configured so that the IP Agg can

be configured via DNS name. Also the Push Config server at the hub site has an option to allow the Push

Config client clocking to be configured to the IP Agg since the IP Agg itself does not appear in the client

configuration.



An authentication field is provided for IP aggregate configuration. This is used to identify "connection"

attempts from unknown peers who have come through NAT gateways. The authentication info must

match on both ends of the IP Agg for the aggregate to be valid. The authentication scheme itself is based

on a random challenge scheme to avoid replay attacks. The authentication will be used only when

configured - if it is not configured for an IP Agg then the aggregate will work anyway - if the peer is

unknown we will accept a "connection" from any unit.

4.14 TDM Aggregates

For many applications, the standard packetized Vocality networking protocol is a flexible and versatile

transmission standard well-suited to dynamic applications with varying bandwidth demands and proven in

many complex mesh topologies. However, for some point-to-point applications where bandwidth is critical

and link conditions are challenging, Time-Division Multiplexing (TDM) is an alternative Aggregate protocol

which confers the following benefits:

- Greater bandwidth efficiency

- Radio Silence mode option

- Limited/zero Error Extension depending upon call-type

The potential drawbacks of TDM mode are:

- Longer latency

- More complex to configure

- Higher processing burden

The fundamental characteristic of a TDM protocol is a fixed, repeating frame structure, which is split into a

number of timeslots. The bandwidth requirements of each tributary channel are met by assigning a

number of timeslots for each one according to its needs. The predictable nature of the frame structure

requires less bandwidth to be used on overheads such as the lengths, flags or checksums which are used

by packetized protocols. Historically the rigid nature of the frame means that, to take maximum

advantage of the bandwidth, the timeslots must be permanently used and cannot adapt to dynamic traffic

patterns, which ironically leads to inefficiency. The Vocality implementation overcomes this by using a

small, error-corrected header section which dynamically defines the makeup of each frame as it is

transmitted.

Overall efficiency gains are made in many ways: Some types of traffic are Constant Bit Rate (CBR) and

therefore need no length byte in the timeslot at all since the quantity of data never varies; the aggregate

data format is purely transparent synchronous without the HDLC zero-bit insertion of packetized formats;

bandwidth is recycled dynamically when there is no data for a particular timeslot. This latter technique

requires the existence of a Dynamic area in the frame which can grow and shrink; it is an ideal “bucket”

for IP traffic, making the most use of available bandwidth at all times.



4.14.1 TDM Aggregate Specification

- Line Speed: 9600 – 2048000 bits/sec. Line speed must be a multiple of 1600 bits/sec. Requires stable line speed.

- Asymmetric line-speeds are supported.

- Minimum overhead : 1600 bits/sec

- Timeslots: Multiples of 400 bits/sec

- Timeslot range supported : 400 – 2046400 (i.e. 2048000 minus the minimum overhead of 1600 bits/sec) For user convenience when using DBA, the menus permit 2048000 to be specified. Some types of timeslot require minimum timeslot size of 2400 bits/sec.

- Asymmetric tributary rates are supported (except when using DBA)

- Latency: In order to operate without error, TDM will potentially have a higher latency than conventional NRZ Aggregates.

- Efficiency: Up to 99.92% dependent upon frame structure.

- Simplex and Duplex operation.

- TDM3 Tunnelling (i.e. TDM3-over-TDM3 operation) is supported, with limitations.

- Physical interface: Same range of physical interfaces as conventional Aggregates (RS-449 etc).

- Error Extension: TDM connections can run without Error Extensions – for certain types of timeslot.

- Push Config: TDM is not supported by Push Config.

4.14.2 Targets Supported

TDM Aggregates are supported on the following systems/cards:

- V25

- V50+

- Standard CPU Card 68151 (V150/V200)

- High Speed CPU Card 68201 (V150/V200)

- Quad Serial Card 68204 (V150/V200) – on first 4 ports only

It is not supported on the following:

- V50

- V100

- V150/V200 Serial Expansion Card 68205 – on ports 5-12

4.14.3 Interworking

TDM3 is a new feature introduced in version 4.9.1. It is not present on earlier versions. For full

compatibility, peer units must be running version 4.9.1 or later, even if TDM aggregates are not used.

This is because the convention used for rounding serial port line speeds has been changed. The range and



granularity of speeds supported on serial ports is finite: we can only generate specific multiples. Up to

version 4.8.1, if a non-multiple speed was set, we rounded UP – the extra overhead would be absorbed

within the conventional aggregate’s overhead flexibility. From version 4.9.1 we have to round DOWN – so

that the data can be guaranteed to fit in the assigned TDM3 timeslot (otherwise there will be data loss).

NOTE THAT THIS AFFECTS ALL CASES WHEN BANDWIDTH ROUNDING IS DONE – even if the call is not

routed via a TDM aggregate.

In configurations where this rounding factor does not come into play (e.g. fixed line speeds of the

supported granularity, which use the correct multiples with no DBA) – then interworking with pre-4.9.1

software is supported.

4.14.4 TDM Tunnelling

A TDM may be “tunnelled” as a synchronous Tributary over another TDM Aggregate.

This is subject to the following restrictions:

The tunnel must run at a constant speed. i.e. the sync trib must be a fixed speed, and cannot be DBA.

One TDM Aggregate should be configured with the “Data Stream Inversion” option set to OFF for both

ends, the other with the “Data Stream Inversion” option set to INVERTED for both ends.

There is a limit of one level of tunnelling.

TDM3 may be tunnelled over previous Vocality TDM offerings, provided again that a constant speed is

used for the tributary tunnel.

4.14.5 Configuration Summary

In order to configure a TDM aggregate follow these steps:

Enter the DATA menu:

- Set Mode to “Agg” and Format to “TDM”.

- Configure Clocks and Interface type in the same manner as for a conventional aggregate.

- The Destination field should be left blank.

- If externally clocked, there is no need to specify the Rate (it should be set to 0).

Enter the TDM TIMESLOTS menu:

- Navigate to the Channel (port) on which you wish to run TDM using the <NEXT TDM> button.

- Set the number of Timeslots to a suitable value. (In version 4.9.1, there is a limit of 16 timeslots)

- Configure the transmit and receive timeslots which you wish to use.

- If any of the timeslots are CBR-DBA or Pack-DBA, ensure that a DBA-Ctrl timeslot is also configured

Enter the TDM ADVANCED CONFIG menu:

- configure any special settings which you require (the default will normally be suitable).



Then repeat at the peer node. Transmit timeslot configuration should be compatible with the Receive

configuration at the peer and vice-versa.

Note that should you want to, you can always reconfigure a TDM Aggregate back to conventional mode

(NRZ or NRZI). The settings in the TDM TIMESLOTS menu will not be used, but will be preserved.

4.15 SIPGw

The SIP gateway feature allows VoIP devices in a SIP network to communicate across a Vocality network.

Calls may be routed from SIP devices to analogue voice ports, digital voice ports, or indeed other SIP

devices. The voice traffic is carried across the Vocality network in a payload that provides greater

bandwidth efficiency then VoIP. Calls that are handled via the SIPGw take part in the Vocality Dynamic

Bandwidth Allocation scheme (DBA) where bandwidth from other multiplexed services (if available) is

reduced to provide the bandwidth required for the voice call. The SIP gateway may be configured to

operate either with or without a SIP registration proxy or outbound proxy. When no SIP registration or

outbound proxy is available, the Vocality SIPGw feature provides simple call routing features to allow calls

across the Vocality network to be routed to the correct SIP device. The SIPGw allows calls originated from

the SIP network to be routed directly to other voice ports across the Vocality network - it may also be

configured to provide a secondary dial-phase, where subsequent dialled digits are used to route the call.

4.16 SNMP

The SNMP feature provides an SNMP agent to the Vocality multiplexer/router. This provides management

services via the

SNMPv1/2c/3 protocol set to an SNMP client that allow the client to monitor the status of the Vocality unit.

System and network conditions that can be configured to raise system alarms can also be configured to

trigger the generation of SNMP trap messages to SNMP clients.

C H A P T E R 5 A P P L I C A T I O N E X A M P L E S


5 Applications Examples Four common applications are given here: Back-to-back testing, use with a satellite modem, use with an

Inmarsat M4 terminal, and use with an IP aggregate. A full set of Application Notes are available on the

Vocality International support website www.vocality.com/support.

5.1 Back-to-back Testing

Before commissioning the multiplexer, it can be very useful to configure a pair of multiplexers in a back-

to-back configuration to gain familiarity with their setup and operation. In the example below, two units

are connected via Port 1 of a Serial Card in Slot 5 using cable VI68726A. System settings for the units are

as follows:

..and for the other unit:

Chapter

5



The settings for Node I.D. are critical – they must be set to different values for the units to communicate

correctly. The Clocking Configuration settings for the units are as follows:



The Data Configuration settings for the units are as follows:



Note that Unit 0 is configured to generate a transmit link clock of 128Kbps (“Int”), which is used internally

as the GRX reference (CLOCKING menu GRX source) and also received by Unit 1 and used as the GRX

reference (CLOCKING menu GRX source). Unit 1 then turns the clock around (TX clock set to “RXC”) and

it is received back at Unit 0, which uses it as the RX clock source.

The programming of the clock references is essential to all tributary channels, since they must use a clock

reference to generate all local bit rates. In this example, the Global Receive clock bus (“GRX”) takes the

Port 1 Aggregate RX clock and Port 2, which will be used to connect a router, uses the GRX as its

reference for generating the RX router clock. To go one stage further and operate Port 2 dynamically, the

RX clock source is set to “DBA”. This allows the multiplexer to smoothly vary the RX clock on Port 2

according to traffic demand. Finally, a destination address must be entered for Port 2.



5.2 Use with Satellite Modems

The multiplexer is often used in combination with satellite modems to provide telecommunications links

between remote sites. This example describes the use of the V200 with a Paradise Datacom P300 modem

that is fitted with the standard P1440 interface in RS422 mode, thereby allowing the use of the standard

RS422/RS449 cable (part number VI68723A,see the appropriate Hardware Guide for part numbers for

your multiplexer) at both ends of the link. (When using the serial data card, the four-way serial data cable

- part number VI68231A - is also required.) It is also applicable to the P400 modem when fitted with the

P1448 interface, but in this case the cable number VI68723B/P1448 should be used, to operate the

interface in “Direct” mode. The standard cable should be used with all other modems.

The configuration concept is to use one unique clock in the system as generated by Modem0 (connected

to the V200 with Node I.D. “0”), with all other clocks derived from this:

In this example, port 1 on slot 5 is used on both units.

The System settings for the units are as follows:

Disclaimer:

This example uses settings for the modems that have been tested and proven to work. There are alternative settings, which may be used according to the application. The validity of this example cannot be guaranteed with other manufacturers’ equipment or when using other settings.



The settings for Node I.D. are critical – they must be set to different values for the units to communicate

correctly.



The Clocking Configuration settings for the units are as follows:



The Data Configuration settings for the units are as follows:



Unit 0 is configured to accept the stable receive link clock of 128Kbps (“Ext”) from Modem0, which is used

to clock data out of the Doppler buffer. This is turned around as the transmit clock (“RXC”) and given back

to modem as Terminal Timing, it is then sent over the satellite link to Modem1, which recovers the receive

clock and outputs it to V200 Unit1. Unit1 is configured to accept this receive clock (“Ext”), to use it as the

GRX reference (GRX source in CLOCKING menu) and then turn it around (TX clock set to “RXC”) and

output it back to Modem1 as Terminal Timing (“TT”). Modem1 sends this back via the satellite to Modem0

which recovers the receive clock and uses it to clock the Doppler buffer.

Once again, the programming of the clock references is essential to all tributary channels, since they must

use a clock reference to generate all local bit rates. In this example, the Global Receive clock bus (“GRX”)

takes the Port 1 Aggregate RX clock and Port 2 (also in slot 5), which will be used to connect a router,

uses the GRX as its reference for generating the RX router clock. To go one stage further and operate Port

2 dynamically, the RX clock source is set to “DBA”. This allows the V200 to smoothly vary the RX clock on

Port 2 according to traffic demand.

Modem Settings:

In the example above, two Paradise Datacom P300 modems may be used. Modem0 is used to generate

the network clock, since it has a stable +/- 1ppm reference. On the “Change, Tx, Baseband” menu, select

“Continuous Data” then enter the baseband data rate, in this case “128000”. On the “Change, Tx,

Clocking” menu, the TX clock should be set to “TX CLOCK IN” which expects the transmit clock on the TT

clock pair. On the “Change, Rx, Buffer/Clocking” menu, the RX clock should be set to “INTERNAL”. This

will enable the “Change, Rx, Buffer/Clocking,Buffer Size” menu, which allows the user to select a buffer to

accommodate the incoming Doppler shift. Normally, 4mS per satellite transition is sufficient, i.e. a total of

8mS.

Modem1 recovers the clock from the satellite. On the “Change, Rx, Buffer/Clocking” menu, the RX clock

should be set to “SATELLITE” which will disable the Doppler buffer and output the RX clock on the “RT”

clock pair. On the “Change, Tx, Clocking” menu, the TX clock should be set to “TX CLOCK IN” so as to

accept the TT clock back in from the V200.



5.3 Use with IP Aggregates

The following example shows a unit with node number 0 connected to a unit with node number 1 over an

IP aggregate. Unit0 is configured with an IP address of 1.1.1.2/24. It is configured on an IP network with

a default gateway of 1.1.1.1. Unit1 is configured with an IP address of 2.2.2.2/24. It is configured on an

IP network with a default gateway of 2.2.2.1.

IP

10/100/1000BT ETHERNET V

200

V20

0

V20

0V

200

10/100/1000BT ETHERNET

Before the IP aggregate itself is configured the system node numbers and base IP configuration should be

completed.

The System settings for the units are as follows:



The IP Networks menus for the units are as follows:



The IP static route table settings for the units are as follows:



The IP aggregate is configured to provide a 64000bps aggregate to multiplex over. Clock synchronization

is required between the two units. Unit0 is configured to provide its internal clock source as a reference

for Unit1. The IP Aggregate settings specify the characteristics of the IP aggregate as follows:



A V200 routing table entry is required on both units to activate the IP aggregate. Note that the name used

in the route configuration must match the name assigned in the IP aggregate configuration:



To complete this IP aggregate configuration the clocking configuration on both units should be updated to

drive GRX from the IP aggregate:



Normal IP Tributary traffic can be routed across the IP aggregate in the normal way and is the preferred

configuration where no QoS is available.



5.4 Broadcast Voice and Data

We offer a broadcast facility, which allows Voice or Serial Data traffic to be routed to multiple destinations.

(It does not apply to IP traffic).

This facility is available within unit and across conventional and TDM aggregates. TDM Aggregates make

use of Broadcast Voice/Data in order to deliver voice/data in Radio Silence mode.

We define the concept of a “Broadcast Pathway”: this is a logical path-way within a unit which carries data

from one source to one or more destinations. A Broadcast Pathway may be directed to other units by

directing it to an Aggregate.

In order to configure a Broadcast Voice or Data connection:

1. Configure the source and destinations of the broadcast data

2. Define entries in the ROUTING menu to direct the Broadcast Pathway to other nodes

3. If in a Chassis-based system (e.g. V150 or V200), define additional entries in the ROUTING menu

to create the Broadcast Pathway within the unit.

4. If using TDM, define BRDn timeslots on the TDM TIMESLOTS menu

In more detail, these steps are as follows:

Configure the source and destinations of the broadcast data

Serial Data and Voice ports may be configured as the source and/or destination of the broadcast data.

This is done by entering BTXnn/BRXnn/BTRmm,nn in the DESTINATION field for the appropriate port, as

follows. Note that the directions in BTX/BRX are relative to the BROADCAST PATHWAY, not to the physical

interface.

• Use BTXnnn if the port is to originate broadcast voice or data. For example, if “BTX1” is specified

on an analogue voice port, received audio will supply the Broadcast Pathway 1. No audio will be

transmitted to the telephone line.

• Use BRXnnn if the port is to transmit broadcast voice or data. For example, if “BRX1” is specified

on an analogue voice port, it will transmit audio from broadcast Pathway 1. No audio will be

received from the telephone line.

• Use BTRmmm,nnn if the port is to both transmit and receive Broadcast data/voice. i.e. originate

broadcast voice/data onto one Broadcast Pathway, and transmit broadcast voice/data from

another Broadcast Pathway. For example, if BTR1,2 is specified on an analogue voice port, then

received audio will supply Broadcast Pathway 1, and transmitted audio will come from Broadcast

Pathway 2.



Note that any one Broadcast Pathway should only be supplied from one port.

Define entries in the ROUTING menu to direct the Broadcast Pathway to other nodes

For each Aggregate to which the Broadcast data is to be sent, add an entry to the ROUTING menu, as

follows. This example will cause all Broadcast traffic to be routed to the Aggregate 0:1.

Add additional entries in the ROUTING menu to create the Broadcast Pathway within the unit.

If in a chassis-based system (e.g. V200 or V150), then it may be necessary to add additional entries to

the ROUTING menu, in order to create Broadcast Pathways within the unit. This will only be necessary if

the source and destinations (whether tributary port or aggregate) of the broadcast data are on different

cards. The following example would handle the case of a Voice Card in slot 3 generating or receiving

Broadcast data (note that there does not actually need to be an Aggregate in the specified position).



If using TDM, define BRDn timeslots on the TDM TIMESLOTS menu

This step is only needed if routing broadcast data across a TDM Aggregate.

A Broadcast Pathway should normally be routed over TDM Aggregates using a dedicated timeslot, rather

than using the dynamic area. BRD timeslots should be of the type appropriate for the port being used –

typically this will be Voice, ModemFax or SVR if Analogue voice traffic is being carried, or CBR or Packet if

Serial Data is being carried (see the TDM section for more details).

There is no Call-Control Signalling when a Broadcast path is established over TDM – these means that

they can be used in TDM Radio Silence Mode.

A P P E N D I X A : A B B R E V I A T I O N S


Appendix A: Abbreviations ACK Acknowledgement Agg Aggregate Port AIS Alarm Indication Signal AOR Address Of Record ARP Address Resolution Protocol Bps(Kbps) Bits per Second (Kilobits per second) CBR Constant Bit Rate CIR Committed Information Rate CLI Calling Line Identification CPN Called Party Number DBA Dynamic Bandwidth Allocation DES Data Encryption Service DHCP Dynamic Host Configuration Protocol DNS Domain Name Service FQDN Fully Qualified Domain Name GRX Global Receive Clock GTX Global Transmit Clock ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IGP Interior Gateway Protocol IP Internet Protocol LAN Local Area Network LDN Local Directory Number LOS Loss Of Signal MAC Media Access Control MD5 message digest 5 MTU Maximum Transmission Unit (bytes) MUX Multiplexer NACK Negative Acknowledgement NFS Network Function Semi(ISDN) NSSA Not So Stubby Area OSFP Open Shortest Path First PEP Performance Enhancing Proxy PLL Phase-Locked Loop PoE Power over Ethernet QoS Quality of Service RAI Remote Alarm Indication RFC Request For Comments RIPv2 Routing Information Protocol version 2 RXC Receive Clock RXD Receive Data SHA1 Secure Hash Algorithm 1 SIP Session Initiation Protocol SIPGw SIP Gateway

Appendix

A



SNMP Simple Network Management protocol STP Spanning Tree Protocol TA Terminal Adaptor (ISDN) TCP Transmission Control Protocol TCPGw TCP Gateway TDM Time-Division Multiplexer TFTP Tiny File Transfer Protocol ToS Type of Service Trib Tributary port TXC Transmit Clock TXD Transmit Data UA User Agent UDP User Datagram Protocol UDPGw UDP Gateway URI Universal Resource Identifies UTP Unshielded Twisted Pair WAN Wide Area Network



Appendix B: Index

Back Busy, 24 Back-to-back testing, 281 Bandwidth on Demand (BoD), 132, 136 Broadcast mode, 250 Clocking, 66, 233, 245, 253, 284, 289

menu, 33 Over IP Aggregates, 124

CONFIGURATION Mode, 30 Stores, 31

CONFIGURATIONS menu, 29

DBA, 244 Pools, 112 remote configuration, 185

Diagnostics, 191 Alarms, 225 Call log, 226 Configurations, 224 Connections, 223 IP PoE power, 201 IP Route Table, 196 Ping, 193 Test Ports, 189

Feature Keys, 49, 51 FXO, 53, 54, 73, 74, 255 FXS, 53, 54, 73, 74 GRX, 144 GTX, 144 High-speed CPU, 8 Hunt Groups, 53, 57, 59 IP Aggregates, 33, 36, 37, 39, 122, 124,

125, 281, 290, 293, 295, 296, 297 IP Router, 258 MTU, 81

Discussion, 260 Node ID, 10, 22 Passwords, 14, 17, 25, 27 PEP, 82, 271

Port Numbers, 9, 57, 73, 82, 85, 111, 119, 124, 258, 270

Ports Data, 19, 66, 244, 245 M&C, 13 Supervisor, 17 Virtual, 82, 83, 85, 97, 257, 259, 260, 266

Power over Ethernet (PoE), 26 Relay

Fax, 72 Modem, 72 STU, 73 UDP, 111 V.22, 72

Routing, 36 Implicit, 39 Precedence, 39 RIPv2, 85 Static, 96 Table entry, 38

Service Management, 112, 117, 118, 119, 121, 133, 134

Shared outbound links, 65 SIP, 42

Address Of Record, 45 Destination, 48 Gateways, 56 UA Channels, 45 User Agents, 42

Spanning Tree Protocol, 81, 276 Supervisor, 27, 38, 110, 116, 185, 252,

275 Telnet, 110, 116, 275 Tie-Line, 24, 27 Tones, 243 Voice

Analogue, 71 Digital, 129, 140

Appendix

B

software guide version 4.9

Documents