Cs2000 Universal Translations3006a 50 SG

CS2000
Universal Translations
Student Guide
Guide release: 5.0
Guide status: Released
Date: May 2006
Copyright 2005 Nortel Networks. All rights reserved.
NORTEL NETWORKS CONFIDENTIAL: The information contained in this document is the property
of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this
document shall not copy or otherwise reproduce, or modify, in whole or in part, this document or the
information contained herein. The holder of this document shall keep the information contained
herein confidential and protect same from disclosure and dissemination to third parties and use
same solely for the training of authorized individuals.
THE INFORMATION PROVIDED HEREIN IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND. NORTEL NETWORKS DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR
IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. IN NO EVENT SHALL NORTEL NETWORKS BE LIABLE FOR ANY
DAMAGES WHATSOEVER, INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL,
LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, ARISING OUT OF YOUR USE OR
RELIANCE ON THIS MATERIAL, EVEN IF NORTEL NETWORKS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
Information subject to change without notice.

Nortel Networks, and the Nortel Networks logo are trademarks of Nortel Networks.
Publication History
July 2005 Version 1.0 Initial Issue

July 2005 Version 2.0 Updated, formatting
errors
August 2005 Version 3.0 Updated following
pilot delivery.
August 2005 Version 4.0 Additional module and
appendix added.
May 2006 Version 5.0 Update to ISN09
Contents revised.
Additional material
added.
Course introduction
Overview
Description
The purpose of this course is to familiarise the student with the datafill requirements of
CS2000 Universal Translations.
Intended audience
Personnel responsible for the initial datafill and database management of CS2000
Universal Translations.
Prerequisites
This course has the following prerequisites:
Familiarity with use of DMS / CS2000 Table Editor is recommended.
CS2000 Overview
Objectives
After completing this course, you will be able to
Explain the function of a Customer Group and datafill Customer Group Tables.
Provision Lines using OSSGate
Describe the function of Trunk tables and datafill trunk groups.
Describe the functions of the Route tables and datafill route lists using appropriate
selectors.
Describe the functions of Universal Translations
Apply Universal Translations to resolve trunk to trunk, trunk to line, line to line and
line to trunk calls.
Describe screening of CLIs in Universal Translations and the use of White v Black
lists.
Datafill Tables to screen CLIs in Universal Translations.
Datafill Tables to screen calls using Call Control and Universal Screening
Use Traver to verify correct call routing through translations.
References
The following documents provide additional information:
NTP 000-0000-000 Document title
297-9051-350 DMS-100 MMP Translations Guide
297-9051-300 DMS-100 MMP Customer Data Schema
297-1001- 824 Commands Reference Manual
NE-10004-512 OSSGate Users Guide

Contents
0. Course Introduction
1. Introduction to Tables
2. Centrex Translations Overview
3. Lines Provisioning
4. TRAVER
5. Trunk Groups
6. Route Tables
7. Universal Translations Overview
8. Universal Translations Datafill International Calls
9. Universal Translations Datafill Local Calls
10. Universal Translations Datafill National Calls
11. Time Of Day Routing
12. Universal Translations Datafill Service Calls
13. Universal Translations Indirect Access
14. Call Control and Universal Screening
15. Appendix A PRI Trunks
16. Appendix B CCS7 Tables
17. Appendix C Announcements
18. Appendix D Student Information
Introduction
nortel.com/training
V10.0 NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY
0
1
Introduction to CS2000 Universal
Translation course
Purpose
The purpose of this section is to introduce the student to;
> The Universal Translations course Table Association Chart
> Course navigation map.
> An example CS2000 network configuration
2
NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY
2
3
CS2000 Universal Translations
Course Introduction
Centrex
Customer
Group Universal
Tables Translations
Tables
Trunk
Group Routing
Tables Tables
Call Control
Tables
4
Course Introduction
For this course we will be working in several areas.
The initial aspects involve putting in place resources that will be used in later exercises.
Specifically we will be working in the following areas;

Customer Groups.
These will be required for use by Lines and Trunks.
Trunk Groups.
These simulate the linking of switches together.
Routing Table entries.
These are used to point to single or multiple Trunk Groups.
The above areas have to be completed prior to entering Universal Translations.

Once in Universal Translations, dialled digits will be analysed with calls being routed to
Lines, Trunks or treatments.
Finally, once Universal Translations have been built we will look at the Call Control
Tables, which allow us to analyse information other than dialled digits.
The above slide is a simplified depiction of the course content. The following slide
breaks this down further.
4
5
Centrex
XLANAME LINEATTR Table Association Chart
CUSTENG Universals FAHEAD

OFCHEAD
CTHEAD
CUSTHEAD PXHEAD FACODE
IBNXLA OFCCODE
NCOS CTCODE
PXCODE FARTE
OFCRTE
IBNTREAT CTRTE
PXRTE
IBNRTE
CLLI OFRT
TRKGRP OVRx
TRKSGRP Routing
LEAST
TRKMEM PATH OF
CALLCNTL COST
ENTRY
ROUTING
Trunks
TRKOPTS Call Control
UNIVERSAL
SCREENING
6
CS2000 Universal Translations Table Association Chart
The above Chart gives an indication of some of the data tables that will be used in this
course and can be used as a map to chart our progress.
At each key stage reference will be made to this chart.
Note. The above chart is only a guide to the areas this course will work within.
There are many data tables on the CS2000.
6
7
CS2000 Network Overview
Voice Core Billing Manager
Services or
CBM Multimedia Server
CS2000
CS2000 CS2000c MCS
Back Announcements
Office MS20x0 Conferencing
IEMS GWC
Element Lawful Intercept
Management CS LAN
CICM Centrex IP Phone Server
USP
SS7 Network ERS 8600
Signalling BCP NAT and NATP Translation
TDM Interface Cable Modem

IP
PSTN
MG15K Network CMTS
Video
Hosted PBX Feed
Centrex IP HFC
HFC
Derived Lines PBX

Cable
Modem
CPE
xDSL
IAD
IAD
m6350 i2004 DSLAM
Softclient Etherset
8
8
9
9
Module 1
Introduction to CS2000
Data Tables
nortel.com/training
0
1
Module 1 Introduction to CS2000
Data Tables
Purpose
> The basic skills required to enter a table, read, change and delete tuples.
The student will also be taught how to add and remove tuples and use
general table navigation commands.
After this module of instruction, you will be able to
> List the uses of tables within the CS2000.
> Define the CS2000 table structure.
> Understand the Table Editor Utility.
> Use Table Navigation Commands.
> Use CS2000 commands to add, change and delete tuples within a table
2
2
3
Introduction to Tables
Call Processing
IBN
Hardware Translations
Resources
Universal
Trunks Translations
Lines
4
The Program Stores Call Processing programs handle call processing. These programs are
dependant on customer-supplied information in Data Store. This customer-supplied
information is stored in the form of two-dimensional areas called tables (stored in Data
Store). By modifying the information in these tables, the customer can change the way the
Call Processing translate (screen and route) calls.
4
Types of Tables
> The structure of tables within the CS2000 is

standard and all commands to manage the tables are
generic. Tables are used to define various things
within the CS2000, these include:
Line information
Trunk information
Hardware configuration
Network Information
Translation, used to route a call.
Management
5
Introduction
In the CS2000, the data for a given office is located within software structures known as
tables. Since an office has requirements for many different types of data (for example,
lines, trunks, I/O devices, translations, network and management), each table within the
CS2000 will have a unique table name and contents.
However, every table is based on the same structure and uses the same Table Editing
commands. Each table will store all of the data inputs relative to that tables data type.
For example, terminal device table (Table TERMDEV) contains all of the inputs for VDUs,
printers, and modems.
This module will cover the generic Table Editing commands common to all tables.
5
Table Structure
The table structure within the CS2000 is two-dimensional. A table consists of horizontal
rows and vertical columns. A row is referred to as a tuple and the columns are called fields.
Fields
The fields in a table have the following properties:
Each field (column) has a unique identifier called a field name or a field number by
which the field may be accessed.
The field numbers begin with number one at the far left and are numbered
consecutively from left to right.
The numbers of fields vary from table to table. Some tables may have two or three fields
while others may have nine, ten or more fields.
Each field name consists of a maximum eight-character string.
The contents of a field may contain one or more elements of data.
Field data may consist of letters, numbers, or may be alphanumeric.
Tuples
The tuples in a table have the following properties:
Each tuple has a unique identifier called a key. The key field for each tuple is always
field number one. Hence, field number one is referred to as the key field name.
All of the data (fields) comprising a tuple contain information about the key.
Tuples are referenced either by their key or by the table editor (TE) cursor.
The cursor is an internal pointer to a tuple with in a table. The cursor pointer is
positioned by utilizing the TE commands. The tuple to which the cursor points to is called
the current tuple.
Tuple numbers begin with number 0 at the top and are numbered consecutively from top
to bottom.
6
Table Structure
1st Field is usually Key Field
(Must be Unique)
Field 1 Field 2 Field 3 Field 4 Field 5 Field 6

TUpLE 1
TUpLE 2
Data Entry
7
7
Table Editor Utility
The user enters a table
The table editer utility is

loaded into the Symbol
Table
The table editer help

facility provides a list of
table editing commands.
Individual commands can
be queried by using the q
<command> syntax.
8
Table Editor Functions

The table editor commands allow the user to perform the following functions:
Modify, add, delete, or change tuples or fields within a table.
List one or more tuples of a table.
Move the cursor to display any tuple within a table.
Display specified valid field values.
Search for tuples containing specified field values.
Verify table alterations before activating them.
Alter data when the journal file is not available.
Note:
A journal file which, is located on disk or magnetic tape, is used to record any alteration
to the data within a table.
8
Navigating a Table
The user obtains a list of

all tuples contained in the
table
The user is now

effectively at the start of
the last tuple in the table
The CS2000 now displays
and repositions to the
tuple five above the
previous position
The CS2000 now
repositions and lists the
tuple 2 below its current
position
Note: the field headers
are not displayed
The list command retains
the current position
within the table but adds
the fields headers
9
Navigating a Table
It is important to understand the concepts of positioning within a table before attempting to
add, change or delete a tuple
As soon a user enters a table their cursor is effectively at the start of the first tuple. Any
subsequent navigational command moves the cursor within the table but it is always at the
start of a selected tuple. Even when we position to the bottom of a table we are actually at
the start of the last tuple.
9
Table Navigation Commands
The following is a description of Table Navigation Commands, the characters in brackets
define the accepted abbreviation. Where ever <n> is mentioned this represents a user
selectable number.
count displays the number of tuples within the current table.
list (lis) Displays the currently positioned tuple.
list all (lis all) Displays all tuples within the current table.
list <n> (lis <n>) Display the defined number of tuples directly below my
current position.
top Position cursor at the first tuple in the table and display the
tuple data.
bottom (bot) Position cursor at the last tuple in the table and display the
tuple data.
first Position the cursor to the first tuple in the table.
last Position the cursor to the last tuple in the table.
next Position the cursor to the tuple following the current tuple.
prev position the cursor at the tuple previous to the current tuple.
up <n> move the cursor up the specified number of tuples, display
tuple data.
down <n> (dow <n>) move the cursor down the specified number of tuples, display
tuple data.
Position <key field> position the cursor at the specified key field. (see note)
pos <key field>
Note: When using the position command the CS2000 will search the key fields within the
table for a match with the one requested by the user. In some tables more than one tuple
will contain the same value in the first field, in these cases the key field is extended to the
second (and occasionally the third) field until the tuple can be uniquely identified.
10
Navigating a Table (contd)
The count command
obtains the number of
tuples held within the
table
The List All is used to list
all tuples within the table
The position command is

used to position on the
key field of a tuple
within the table but adds
the field headers
11
11
Obtaining Help
The user enters a table.

The range command lists
all fields within a table
and provides a brief
description of each.
The resultant list

provides a number for
each field. A range
command followed by the
field number provides the
input parameters needed.
In the example shown a
number between 0 23 is
required.
12
Obtaining Help
Once a table has been entered the help command display a list of all table editing commands
(see slide on page 7). When entering new tuples into a table it is not uncommon for the user
to need help in understanding what string of characters the CS2000 is expecting. The range
command is a useful tool in over coming this problem.
The range command is used to display the value range for the fields of the current table.
Once this information is available to the user the option to seek further information on a
given field is possible by using the range command followed by the field number.
The example opposite shows that the CS2000 requires a dumphour a range 2 command
informs the user that a entry in the range 0 to 23 is required.
12
Adding a Tuple
The add command tells
the CS2000 that a new
tuple is to be added.
The CS2000 now presents
each field in sequence for
the user to add the
required parameters.
At any stage the abort
command will stop the
process and return the
user to the table
After the input for the last

field is complete the
CS2000 presents the
complete tuple and seeks
confirmation.
The tuple is now added to
the table and a Journal
File is written
13
Adding a Tuple
To add a tuple, the add command is used. Once the add command has been entered the
CS2000 will display each field in turn starting with the key field.
The user must enter the correct string from within the range of characters expected by the
CS2000. Any unexpected characters will caused the whole entry to be rejected by the
CS2000.
Once in the add mode the CS2000 is expecting a valid string of characters for the current
field any other command (even if it is normally valid) will be matched against the expected
string and reject. The only valid command available once in the add mode is the abort
command, this aborts the add sequence and returns the user to the table.
Whilst in the add mode and if the expect string is unknown to the user, a useful tip to obtain
help without having to exit the sequence is to enter two incorrect strings of characters for
the field. The CS2000 will then present the range of characters expect, much like the range
<n> command.
After completing the last field the CS2000 will display the complete tuple to be entered and
seek confirmation.
When the tuple is subsequently added, a record of the change is written to journal file, this
file can be recalled in the event of a system problem where table data has been lost.
Note: Throughout the CS2000 there are many occasions where a tuple in one table refers
to a second tuple in a different table. There are strict rules governing table data fill
sequences.
13
Changing a Tuple
The user positions on the
tuple to be changed.
The change command
informs the DMS that the
tuple that we are
currently positioned on
needs changing.
The DMS presents each
field in turn with its
current value. If no
change is required the
return key moves onto
the next field. If a change
to a field is needed the
value followed by the
return key changes the
value of the field.
After the input for the last
field is complete the DMS
presents the amended
tuple and seeks
confirmation.
14
Changing a Tuple
To amend an existing tuple the change command is used, the abbreviated version is cha.
Prior to changing a tuple the user must correctly position at the start of the tuple to be
changed by using the navigation commands.
Once correctly positioned the change command will initiate the display of each field in turn
in a manner similar to the add command. The use of the change command displays the
current value for each field, if no change to that particular field is needed the return key
moves the user on to the next field without changing the current field value.
If a change is required the user inputs the new value. Like the add command, two incorrect
entries will force the CS2000 to display the expected range of characters for that field.
Once the last field has been amended, the whole of the amended tuple is displayed and
confirmation is sought.
The change to the table is recorded as a Journal File.
14
Deleting a Tuple
The user positions on the
tuple to be deleted.
within the table and
displays the tuple with
the field names.
The delete command
informs the CS2000 to
delete the tuple that the
user is currently
positioned on.
The CS2000 now seeks
confirmation that this
tuple is to be deleted.
Once deleted the tuple
cannot be recovered.
There is no Recycling
Bin!
15
Deleting a Tuple
To remove a tuple from a table the delete command is used (del is the abbreviated variant).
Like the change command, prior to deleting a tuple the user must correctly position at the
start of the correct tuple by using the navigation commands.
Once the delete command is entered the CS2000 will display the complete tuple that is to be
deleted and seek user confirmation.
Once the tuple is deleted Table Editing commands cannot recover it.
Again the process is recorded as a Journal File.
Note: Throughout the CS2000 there are many occasions where a tuple in one table refers
to a second tuple in a different table. There are strict rules governing table data fill
sequences, this same sequence must be reversed to delete linked tuples.
15
Summary
In this unit, you learned the following:
The uses of tables within the CS2000.

To define the CS2000 table structure.
The Table Editor Utility.
How to use Table Navigation Commands.
How to use CS2000 commands to add, change and delete tuples within a table.
16
17
Table Commands Exercise
1. Enter Table LNINV (LEN Inventory)
How many entries (TUPLEs) there? ______________________________________
What TE command did you use to answer the above?_________________________
2. Locate and view the following LEN:- CICM 07 0 01 30

What is the current state of the line? _______________________________________
What command did you use to locate the above LEN? _________________________
3. Enter Table CLLI (Common Language Location Identifier).

How many tuples currently exist in Table CLLI
4. Position on the CLLI ITALY_PVG.
What are the following values for the above CLLI?
ADNUM __________________
TRKGRPSIZ _______________
5. Enter Table Termdev (Terminal Device) and using the Device name TERM1 obtain the
following:
The CCT Number ________________
The Terminal Type _______________
The Baud Rate ___________________
The COMCLASS _________________
6. Enter Table TRKMEM (Trunk Member) and identify the GWCNO, GWCNODENO and
GWCTRMNO of the following Trunk:
GERMANYPRI Extrkrnm 2 ________________________________________
7. In Table CLLI what character range exists for field CLLI? ___________
Add a new entry with the following parameters;
CLLI Region name (EMEA, CALA, APAC, NA) + team number
ADNUM 500x (where x is your team number)
TRKGRPSIZ 100
ADMININF text stating demo datafill.
8. Change the TRKGRPSIZ to 110 for the tuple you have just entered.
9. Delete your tuple.
18
19
Module 2
Centrex Translations Overview
nortel.com/training
0
1
Module 2 Centrex Translations
Overview
Purpose
> CS2000 Digital Centrex base translations.

Name the base tables required to support basic Customer
Group Translations.
Describe the purpose of each of the tables
Describe incoming Trunk default datafill action
Datafill an example Customer Group to support Network
dialling.
2
2
3
Course Navigation Map
Centrex
Customer
Group Universal
Tables Translations
Tables
Trunk
Group Routing
Tables Tables
Call Control
Tables
4
Course Navigation
The above slide illustrates the area we are currently working in.
4
5
5
Centrex
CUSTENG Universals
CUSTHEAD
IBNXLA
NCOS
IBNTREAT
6
6
7
Centrex Introduction
CM
(cpu)
PS
DS
CM
(cpu)
Duplicated
PS
DS
Program Store (PS) Data Store (DS)
Programs software release Data tables (1100+) and other

data that contain the switchs
e.g. ISN06 or ISN07
Information
8
CS2000 Digital Centrex and CS2000 relationship

The CS2000 is a computer. Like all computers, the CS2000 has a Central Processing Unit
(CPU) located in the Central Control Complex (CCC).
The CPU combines programs from Program Store (PS) and data from Data Store (DS) to
formulate needed instructions.
Data Store contains the switch's unique information. This information is stored in software
tables. Centrex has its own special software tables which must be properly datafilled. These
tables permit the creation of a PBX environment in the CS2000.
The CS2000 can support a maximum of 4095 Centrex customer groups (discussed in detail
in this section ). All 4095 Centrex customers share the Centrex tables. In order for the
CS2000 to distinguish one Centrex customer from another, each Centrex customer is given
a unique name called a customer group name.
Introduction to Centrex Translations
The Program Stores Call Processing programs handle call processing. These programs are
dependant on customer-supplied information in Data Store. This customer-supplied
information is stored in the form of two-dimensional areas called tables (stored in Data
Store). By modifying the information in these tables, the customer can change the way the
Call Processing translate (screen and route) calls. In this module, we will begin our
discussion of translations.
8
9
Introduction to Centrex Translations
CS2k switch
GRP_A
Business
RES_GRP
Customer
A Residential
Customers
Centrex
Translations
GRP_B
Business
Table
Customer
Trunks
LINEATTR
B PSTN
Universal
Translations
Business
GRP_C
Trunks
Customer PBX
C
10
Customer Groups
The CS2000 can serve more than one customer.
This is achieved by allocating each line or trunk to a Customer Group.
A Customer Group is a collection of users with similar dial plans or requirements.
The CS2k can support lines with Private Branch Exchange (PBX) functionality and
Residential lines, all on the same switch.
A possible scenario would be multiple business customers, each with their own dialling
requirements internally (i.e, extension to extension). These business customers may only
have 2 or 3 extensions or up to several thousand.
Also, the switch can support residential customers who all need access to the Public Switch
Telephone Network (PSTN).
In the following examples, there are three different business customers and one residential
customer, all connected to the CS2000 .
We have to set up our switch so that there will be four main customers that it can classify as
Customers Groups. As we install each telephone or Trunk Group connected to the CS2000
we have to assign it to the appropriate (customer) group.
10
Customer Group Dial Plans
Dialling Instructions
Bank
Customer */# = Features
Group 5 = Extension calls
9 = Network Calls (PSTN)
0 = Attendant
Oil
0 = Attendant
Textile
0 = Attendant
11
Customer Group Dial Plans .

Lets assume that each Customer group wishes to give its employees extension dialling (ie.
the ability to dial other telephones within the same customer group).
There could be major differences however, in the dialling plan for each Customer.
The Bank is going to use a leading 5 for extension dialling, the Oil Company 4 and the
Textile Company is also going to use 3.
11
Table IBNXLA
One data table that is important to routing calls is called Table IBNXLA (i.e., IBN
"translations"). This table contains tuples with customer-defined data. These tuples are
shown below.
Customer Group Instructions in Table IBNXLA

Bank (BANK) 5 EXTN
Oil (OIL) 4 EXTN
Textile (TEXT) 3 EXTN
Separating Instructions (Tuples) Among Customers

All of the telephones served by the CS2000 will have been assigned to one of our three
customer groups. Each of the tuples in Table IBNXLA begins with a customer group name
or abbreviation that tells the switch who that tuple belongs to. The sole purpose of this
customer group name is to allow only the correct customer group to use its particular tuple.
This customer group name or abbreviation is called a customer translator (CUSTXLA). A
customer translator is made up of one-to-eight alphanumeric characters (e.g., BANKCT,
OILCT, TEXTCT etc.).
Each tuple in Table IBNXLA is guarded" by a customer translator which ensures that only
the correct customer group uses it for instructions.
Customer translators are assigned to customer groups in a table called CUSTHEAD. Below
is a simplified example of Table CUSTHEAD, showing how customer groups (field one)
are assigned to different customer translator names (field two).
Table CUSTHEAD
CUSTNAME CUSTXLA
BANK BANKCT
OIL OILCT
TEXT TEXTCT
RES RESCT
12
The instructions (tuples) in Table IBNXLA are made specific to each different customer
group. Each tuple (instruction) in Table IBNXLA begins with a customer translator that is
"owned" by a particular customer group. Therefore, to use a particular tuple in Table
IBNXLA a telephone must be assigned to the customer group that owns the tuples
customer translator name. Below are examples of how our tuples in Table IBNXLA should
be entered:
Table IBNXLA
BANKCT 5 EXTN (further data dependant on selector)
OILCT 4 EXTN
TEXTCT 3 EXTN
In summary, the switch asks the following questions before it determines which tuple a
particular line or trunk group should use:
- What customer group is the telephone assigned to?
- What customer translator does that customer group "own"?
-What leading digits were dialed by the caller?
Lets simulate the translations sequence in which one bank phone (245-6000) dials another
bank extension (56405). As shown in Figure 1 the call processing software first looks in a
table called IBNLINES. Table IBNLINES provides information about the originating
phone, including the customer group to which the telephone belongs. In Figure 1 the switch
sees that this originator has been assigned to customer group Bank. Having obtained this
information it can now go to table CUSTHEAD. In table CUSTHEAD the switch finds what
customer translator the customer group called Bank owns. The switch learns that the
customer translator for Bank is BANKCT. The switch will now proceed to table IBNXLA
to find the tuple which begins with BANKCT AND the leading digit dialled (5) that the
caller dialled. In Figure 1 the switch now finds the tuple which gives it instructions to route
this call to an extension.
Figure 1
2456000 DIALLING EXTENSION 56405
Table IBNLINES
HOST 00 0 00 29 DT STN 2456000 BANK 0 1 214 $
Table CUSTHEAD
Custname Custxla
BANK BANKCT
Table IBNXLA
BANKCT 5 EXTN . . . . . . .
13
Preliminary Translators
There are occasions when you will not want to give all the phones in a customer group the
same dialing privileges (i.e., access to the same tuples in Table IBNXLA). For example,
lets say that there are a few phones belonging to the Bank that should be restricted from
calling other extensions How do we keep these phones from using the tuple in Table
IBNXLA that permits this. The answer is two-fold; i.e., (1) through the use of Network
Classes of Service, and (2) through the use of Preliminary Translators.
Network Classes of Service (NCOS)

To keep these restricted phones from using the tuple in Table IBNXLA that permits
extension dialing, they should be grouped together into what is known as a Network Class
of Service (i.e., a number ranging from 0 to 511). A special tuple in Table IBNXLA can
then be created just for the phones assigned to this NCOS. This special tuple will instruct
the switch that when one of these restricted phones places an extension call, it should send
the call to a treatment (TRMT).
Thus, in Table IBNXLA, there will be two sets of instructions (tuples) pertaining to
extension dialing (which uses the leading digit 5) for phones in the BANK customer group,
this will create problems as the key fields are identical.
Table IBNXLA
BANKCT 5 EXTN
BANKCT 5 TRMT
14
Preliminary Translators
Just as the first tuple, in our example, is "guarded" by a customer translator BANKCT, the
second tuple must also be guarded by a special translator. This special translator is called a
preliminary translator (PRELMXLA). Similar to a customer translator, it too is nothing
more than a one-to-eight alphanumeric character (e.g., BANKPT1, OILPT1, TEXTPT1
etc.). The sole purpose of a preliminary translator is to allow only a certain NCOS to use its
tuple.
Just as customer translators are assigned to specific customer groups, preliminary translators
are assigned to specific NCOSs. In other words, a NCOS might :"own" a preliminary
translator which enables it to use certain tuples in Table IBNXLA that no one else could
use. Preliminary translators are assigned to NCOSs through a table called NCOS. Below is a
simplified example of this table, showing how NCOSs (field two) in particular customer
groups (field one) are assigned different preliminary translator names (field three).
Table NCOS
CUSTNAME NCOS No PRELMXLA
BANK 0 $ (none)
BANK 1 BANKPT1
BANK 2 BANKPT2
As you can see in the above example, the BANK phones in NCOSs 1 and 2 apparently have
some special instructions (tuples) in Table IBNXLA, since they both have been assigned
preliminary translators. (NCOS 0 has only a $ in this table, meeting that it does not have a
preliminary translator assigned and thus does not have special instructions written in Table
IBNXLA.)
Lets go back to our earlier example and restrict bank phones in NCOS 2 from using the first
tuple in Table IBNXLA (which permits extension dialing). We do this by beginning our
second tuple with its preliminary translator (BANKPT2), as shown below.
Table IBNXLA
BANKCT 5 EXTN
BANKPT1 5 TRMT
15
THE GOLDEN RULE
When a phone inputs a call and there are two sets of instructions in Table IBNXLA for it to
use (as shown above), the call processing programs (in Program Store) will always try to use
the instructions starting with the preliminary translator first. Therefore, you can say
preliminary translators always override customer translators.
In our example each tuple in Table IBNXLA begins with a customer translator (that is
owned by a particular customer group), or with a preliminary translator (that is owned by a
specific NCOS within a customer group). To use one of these tuples, a phone must be
assigned to either a listed customer group (that owns the tuples customer translator name)
or to a listed NCOS (that owns a tupless preliminary translator name). If a phone owns both
translators, the switch first will try to find a tuple in Table IBNXLA that begins with the
preliminary translator name and the digit(s) that were dialed.
In summary, the switch must ask the following questions before it can determine which of
the tuples in Table IBNXLA it should use :
What customer group is the originating phone assigned to ?

What NCOS is that phone assigned to ?
What preliminary translator does that NCOS "own" ?
What customer translator does that customer group "own" ?
What leading digit or digits were received
The Dual Function of Preliminary Translators

Thus far, we have seen that preliminary translators can be assigned to particular NCOSs to
restrict their dialing privilages (tuples) in Table IBNXLA. However, one other important
function of preliminary translators is their role in giving additional dialing privileges to
selected NCOSs. Lets, again, use the bank phones as an example. In our example, lets say
that a few of the bank phones should be allowed the special privilege of making DOD calls.
To allow these particular phones to have this privilege these phones must be grouped into
separate NCOS (e.g. NCOS 1). This NCOS can then be assigned a preliminary translator
name in Table NCOS. In our previous example, NCOS 1 was assigned the preliminary
translator name BANKPT1. Now, a special tuple in Table IBNXLA can be created for the
lines in NCOS 1. If the phones are to dial the digits 9 to access the DOD network, their
special tuple in Table IBNXLA would be as follows :
Table IBNXLA
BANKPT1 9 NET (further data dependant on selector)
This tuple, giving the switch permission to route calls out on the public (DOD) network, is
guarded by a preliminary translator (BANKPT1). Thus only lines assigned to the NCOS that
owns BANKPT1 (NCOS 1), can use this tuple and make DOD calls.
16
Connection of Trunks to the CS2000
Centrex Overview 3.00
CS2000
Trunks
Customer Group
Customer Group
Other Switches
Table
Table
Lineattr
LINEATTR
Universal
Universal
Translations
Translations
17
Incoming Trunk Access Translations

Incoming trunks are associated with a Customer Group.
Incoming calls over these trunks use a Centrex Customer Group to access Universal
Translations.
17
PRI Trunk incoming Routing options
Table TRKGRP
Table LTCALLS
Centrex Translations Table OFRT/IBNRTE Universal Translations

Customer Group and NCOS e.g. Direct to a Trunk Group via Table LINEATTR
.
Table IBNXLA etc. Table PXCode etc
18
The exception to this are PRI Trunks, which depending upon the call origination/destination
can use either Customer Groups or route directly to Universal Translations via Table
LTCALLS and LINEATTR.
Table LTCALLS will be covered in the PRI Trunks Appendix A module.
18
The role of Table XLANAME
Table XLANAME is used to define the names of translators used in the Centrex
Translations environment. Translator names must be defined before they can be referenced
in table IBNXLA or any of the other tables where translator names are required. A tuple will
comprise the following fields :-
XLANAME - A 1- 8 character translator name.
DEFAULT - Used to apply default instructions if the digits dialled cannot be found in the
given translator. The action taken here is usually one of two choices.
A $ entry in the default field indicates that the system defaults are to apply. In the case of a
Customer Translator the default action sends calls to VACT_TRMT as defined in table
Custhead. In the case of Preliminary translators the default action sends calls to the
Customer Translator.
The alternative to a $ entry is any valid selector as can be used by Table IBNXLA TRSEL
selector.
Table XLANAME Routeing i/c Trunk Calls to Universal Translations

In this event the system defaults are not appropriate. Calls can be resolved by choosing any
valid translation selector as default action, however in this scenario the use of the NET
selector as the default action is commonly used. In a typical residential Centrex customer
group this is used to send all dialled calls to Universal translations as Direct Outward
Dialled calls on the PSTN.
MAXDIG - This field defines the digit range that is valid for use with the particular
translator name. The default value is 9 indicating that digits in the range 0 - 9 may be used.
Enter C to specify a range of 0 to 9, A, B, or C.
Enter F to specify a range of 0 to 9, A, B, C, D, E, or F.
Entries other than 9, C, or F are not valid.
19
CENTREX base tables
Introduction
Calls are passed into Universal Translations from Centrex translations via table
LINEATTR. The section above has detailed the process and we must now consider the
individual tables involved. In considering the Centrex tables it must be remembered that a
Customer Group may use many tables to achieve all the possible features of CS2000 if used
for Centrex. However, this section will concentrate on the base tables required to support a
Customer Group defaulting from Table XLANAME to access Universal translations. The
recommended datafill order is:
SNPANAME
TOFCNAME
XLAPLAN
RATEAREA
XLANAME
CUSTENG
CUSTHEAD
NCOS
IBNXLA
IBNTREAT
The following pages provide information about these translations data tables and their
appropriate datafill .
20
Table SNPANAME
To enable a new range of SNPAs (Serving Number Plan Area codes) the new number must
first be entered into Table SNPANAME.
Table SNPANAME allows the operating company to define a maximum of 127 variable-
length serving numbering plan areas.
There is only 1 Field, the Key field which is the SNPA.
Sample tuple
TABLE: SNPANAME
KEY
---
162
173
161
131
141
031
1234567
Table TOFCNAME
To add an office code, Table TOFCNAME (Terminating Office Name) must be datafilled.
Software optionality control (SOC) options NPE00001 and NPE00002 implement duplicate
office code and table TOFCNAME expansion capabilities.
When NPE00001 is active, you can datafill one office code against more than one area code
in table TOFCNAME.
Up to 1024 entries can be made unless NPE00002 is active which enable up to 8151 entries.
Office parameter ACTIVE_DN_SYSTEM in table OFCENG controls the DN system in use
on the switch.
Sample tuple
TABLE: TOFCNAME
AREACODE OFCCODE OPTIONS
031 345 $
186 567 $
162 870 $
162 871 $
21
Table XLAPLAN
This table contains translations plan information previously held in Table LINEATTR.
The table has been introduced to alleviate the possibility of Table LINEATTR running out
of tuples. This table is datafilled as part of the One Night Process (ONP) during a switch
upgrade
Sample tuple
TABLE: XLAPLAN
XLAPIDX SCRNCL HSTS PRTNM ZEROMPOS RESINF OPTIONS ADMININF
------------------------------------------------------------------------------------------------------------
CS_NPRT NSCR 101 NPRT NONE N $ $
Table RATEAREA
This table contains rate area information previously held in Table LINEATTR.
The table has been introduced to alleviate the possibility of Table LINEATTR running out
of tuples. This table is datafilled as part of the One Night Process (ONP) during a switch
upgrade
Sample tuple
TABLE: RATEAREA
RTAIDX LCANAME MRSA LATANM ADMININF
-----------------------------------------------------------------------------------------------
CS_NIL NLCA NIL NILLATA $
22
Table XLANAME
The Translation Name Table (XLANAME) controls the addition and deletion of translators
to the IBN Translation Table (IBNXLA). Therefore all translators used by Centrex customer
groups must first be listed in this table before they can be used to translate access codes in
the IBNXLA Table. If we do not datafill any entries in Table IBNXLA, the default is used.
The translator is assigned a one- to eight- character name plus optional default data. If
default data is defined, it is used for that translator name whenever an access code is not
specified in Table IBNXLA.
Refer to NTP 297-9051-350 for detailed information about Table XLANAME.

Datafill for NET selector is in Table IBNXLA; NTP 297-9051- 350, not in XLANAME.
Sample tuple
XLANAME DEFAULT
MAXDIG
--------------------------------------------------------------------------------------------------------------
CXDEMO (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $
9
The following is an explanation of the above tuples fields
XLANAME DEFAULT (Note 1)

TRSEL ACR SMDR NO_ACCODE_DIGITS SECOND_DIAL_TONE
cxdemo net n n 0 n
DGCOLNM CRL INTRAGRP NET_TYPE SMDRB LINEATTR
ndgt n y dod n 1
XLAPLAN RATEAREA TOLL_RESTRICTION NETRTOPT
cs_nprt cs_nil none $
MAXDIG
9
Note 1
DEFAULT is descriptor of field, actual datafill field name is TRSEL and
subsequent data is dependant on entry made at this point.
23
Table CUSTENG
The Customer Group Engineering (CUSTENG) Table allocates certain resources to a
customer group as well as memory for other tables. This table also defines the type of
customer group assigned (public, private, or a member of a family).
Refer to NTP 297-9051-350 for detailed information about Table CUSTENG.
Sample tuple
CUSTNAME ADNUM NONCOS NOIBNTMT CONSOLES DOMAIN GROUPID

OPTIONS
---------------------------------------------------------------------------------------------------------------
-
IBNDEMO 3000 30 63 N PUBLIC 3000 $
Table CUSTHEAD
The Customer Group Head (CUSTHEAD) Table defines the group options or system
features that are available to the customer group. Once these features are assigned, they are
available to the group. The required customer group translator is assigned in this table,
however it must be built in XLANAME before you refer to them here.
Refer to NTP 297- 9051- 350 for detailed information about Table CUSTHEAD.
Sample tuple
CUSTNAME CUSTXLA DGCOLNM IDIGCOL OPTIONS

----------------------------------------------------------------------------------------------------------
IBNDEMO CXDEMO NDGT NIL (VACTRMT 0)(EXTNCOS 0) $
24
Table NCOS
The Network Class of Service (NCOS) Table can define the dialing plans or levels of
dialing restrictions available to a customer group.
The amount of usable NCOSs for your CUSTGRP was assigned in CUSTENG.
Refer to NTP 297-9051-350 for detailed information about Table NCOS.
Sample tuple
CUSTGRP NCOS NCOSNAME LSC TRAFSNO OPTIONS

- - - - - - - - - - - - - - - -- - - - -- - - - - - - - - - - - - - - - -- - - - - - -- - - - - --
IBNDEMO 0 $ 0 0 $
Table IBNXLA
The IBN Translator (IBNXLA) Table is indexed with the dialed digits and the translator
named in table NCOS or CUSTHEAD, and specifies the translations for the call. A different
translation selector is used for each type of call, and if no datafill exists in Table IBNXLA
then a default selector can be used from Table XLANAME.
Refer to NTP 297-9051-350 for detailed information about Table IBNXLA.
Table IBNTREAT
The IBN Treatment (IBNTREAT) Table lists and defines intercepts such as tones and
announcements to which calls are routed that do not have translation information assigned.
This IBNTREAT number is assigned in Table CUSTHEAD as the VACTRMT option.
Refer to NTP 297-9051-350 for detailed information about Table IBNTREAT.
Sample tuple
CUSTGRP IBNTRTMT (ITDATA) LOG RTESEL TRMTID

-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - -
IBNDEMO 0 N TRMT GNCT
Treatments can be assigned to: - Vacant codes in table IBNXLA. See option VACTRMT in
table CUSTHEAD and translation selector FLEXI in tables IBNXLA and XLANAME.
25
Summary
SNPANAME
This table allows the addition of SNPAs to the switch.
TOFCNAME
This table allows Office codes to be added and associated with SNPAs.
XLANAME
The translation name table contains the names of all the necessary CENTREX translators.
CUSTENG
The customer engineering table lists the values for the engineering parameters and options
for the CENTREX customer group.
CUSTHEAD
The customer group head table contains the values and options which apply to all lines
within the CENTREX customer group.
NCOS
The network class of service table assigns NCOS on a line basis. The main CENTREX
translators are assigned in this table.
IBNXLA
The IBN translation table stores the data for the digit translation of calls from a trunk or
station.
IBNTREAT
The IBN treatment table is used to route calls in the CENTREX customer group that do
not have a default translator.
26
27
Universal Translations Course
Exercise Naming Convention
Throughout this training course, the following regional naming

convention will be used.
This allows multi regions to utilise the switch simultaneously.
> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
28
Naming Conventions
This training event includes many exercises.
To enable the switch database to be kept tidy and assist instructors in removing datafill post-
event the above naming convention will be followed.
By using the above regional identifiers as a initial name, it will allow more than one region
to use a switch for exercises simultaneously.
Where possible, the full region name, i.e, EMEA would be used.
Example EMEA_2_CUST for a Customer Group Name.

Where EMEA is region, 2 is team/group number and CUST designates Customer Group.
However, for some names there is a restriction on available characters. In these cases, the 2
letter regional naming convention may be used.
For example the PXHEAD translator name limited to 8 alphanumeric characters
CA3PXLA where CA is CALA region, 3 is team/group number and PXLA denotes PX
Translation system.
In the event of two events running simultaneously from the same region, then additional
letters may be added to denote country.
Example - EMEA_G2_CUST where the G denotes an event being run in Germany.
EMEA_U2_CUST where the U denotes an event being run in the United
Kingdom.
28
CUSTOMER GROUP EXERCISE
Add your own IBN customer group to the switch. Your goal is to build your own new
customer group with a unique set of translations. The new customer groups will be used in
later exercises.
The office parameter tables are already set for this CS2000.
The following tables, listed in the order of datafill, should be evaluated and any appropriate
entries made:
XLANAME Assign Default as NET.......DOD

LINEATTR index 1
RATEAREA & XLAPLAN as per datafill example
CUSTENG Customer Group type is to be PUBLIC, NONCOS +

NOIBNTMT = 5, consoles are not required.
CUSTHEAD Use VACTRMT 0
NCOS Use NCOS 0, no options required.
IBNXLA No entries required
IBNTREAT Use TRMT GNCT for Vact_trmt.
Naming Convention for Exercises

Each Team will name their Customer Group using the following naming convention;
[Region abbreviation] [Team number] [Additional identifier text]
Where Region is EM = EMEA
CA = CALA
NA = North America
AP = AsiaPac
Team number is 1 to 8
Additional identifier text is Text at Instructors discretion.
Example
EM2CUSTGRP
Where EM is Region abbreviation for EMEA, Team 2 and CUSTGRP for Customer Group.
NOTE
The above naming convention will be followed for all subsequent exercises.
29
30
31
Module 3
Lines Provisioning
nortel.com/training
0
1
Module 3 Lines Provisioning
Purpose
> Provisioning Lines in a CS2000 or DMS environment
> The manipulation of Line and DN information through the use of
the OSSGate/SERVORD+ or SERVORD systems.

List the basic SERVORD and OSSGate commands
Apply the Query commands to their own lines.
Demonstrate selected basic OSSGate/SERVORD commands.
2
2
3
Table Flow Chart
IBNLINES
IBNFEAT
UPDATES
DNINV
KSETINV
These tables are automatically updated

KSETLINE
if you use SERVORD or SERVORD+ (OSSGate
(OSSGate))
KSETFEAT
SUBGRP
4
4
5
Line Provisioning Introduction
Historically, lines on a DMS100 (the CS2ks predecessor) were provisioned using Service
Order (SERVORD).
SERVORD is a command line tool on the DMS100 that downloaded user input information
into data tables.
SERVORD associated a Line Equipment Number (LEN) to a directory number, Customer
group and line features.
The user input could be entered in Prompt Mode or No-Prompt mode.
Prompt mode enabled the user to enter one piece of information at a time followed by a
carriage return. If an unacceptable piece of information was entered the switch would come
back with either the only acceptable data or the format of acceptable data.
Once all information was entered the user is given a confirmation screen showing the data to
be entered.
No-Prompt mode required the user to input all information in one line. If all values were
correct, the user is given a confirmation screen as in Prompt mode.
If any data is incorrectly entered in No-Prompt mode, SERVORD automatically reverts to
Prompt mode.
Depending whether it is within a TDM environment or IP environment lines would be

provisioned using different methods.
TDM (DMS) environment Lines provisioned in a TDM environment use the SERVORD
utility within the XACore switch using a LEN.
IP (CS2000) environment Lines are provisioned, modified and removed using the
application OSSGate which resides on the CMT server.
The OSSGate application issues SERVORD+ commands to the CS2000 and also
synchronises GWC lines datafill with the CS2000.
For this course, OSSGate will be covered as the command syntax entered is similar to the
confirmation screen seen in the TDM SERVORD prompt mode.
6
OSSGate interactions with Succession
and Maintenance components in SN07
3rdParty OSS Applications
Authentication Trunk
and OSSGate Maintenance
Authorisation Manager
Node Line Trunk Carrier ADSL

Provisioning Provisioning Provisioning Provisioning Provisioning
CS2k Core Manager Element Managers

(SDM/CBM) (GWC EM, MG9k EM,
CICM EM)
XA-Core/COMPACT Trunk Gateways Line Gateways

(PVG)
7
OSSGate Introduction
OSSGate is an application that provides a machine interface for provisioning components
within Carrier VoIP. The main functionality of OSSGate is to act as a gateway to the Node,
Carrier, Trunk, Line, ADSL Provisioning applications and the Trunk Maintenance
application. It provides the end user with an alternative to the GUI interface as a method for
provisioning Carrier VoIP components; one that allows more automation (less human
intervention) than the GUI interface.
OSSGate provides TCP/IP connectivity as an alternative to the asynchronous connections
used in the DMS100F. It implements a telnet protocol over a simple TCP/IP socket
connection to allow clients to connect to OSSGate. Although it is based on telnet it does not
implement a complete set of telnet capabilities. It implements the telnet echo option, which
is used to negotiate with telnet client to turn on or off local echo of characters, especially
during login time. It does not require the client to support all the telnet options. It does
require the client to support line mode. The client or OSS establishes a TCP/IP socket
connection to a specific port number (user configurable) on the server running the OSSGate
application.
OSSGate supports three modes - XML, CI and TL1. The XML interface is used to send
provisioning commands to the Nodes, Carrier, and Trunk applications and maintenance
commands to the TMM application. The CI interface is used to send provisioning
commands to the Lines Provisioning application. The TL1 interface supported from (I)SN08
is used to send line test commands for MG 9000 lines. OSSGate also performs basic syntax
checks on XML, TL1 input before sending it to the Nodes, Carrier, ADSL, TMM, Trunk
provisioning and LTM line test applications.
7
Using OSSGate
The OSSGate server runs as part of the CS2000 Management Tools application. The
OSSGate server continuously listens for incoming connection requests. For each connection
request, it starts a session after the username and password authentication. Such a session
can be used for sending various provisioning commands (for example, Servord+ for Line
Provisioning commands, XML for Node, Carrier, ADSL and Trunk provisioning). OSSGate
can be used by either an OSS or a standard telnet client.
Supported Provisioning Connections

Following are recommended usage limits apply when each application is being run in
isolation (for example, you can have 10 people doing Nodes provisioning as long as zero
people are doing Lines, Carriers, and LMM at the same time):
Node Provisioning (includes add/delete/query of GWs) - Maximum
simultaneous users: 10 (only 5 of which can be from the CS2K
Management tools GUI)
Line Provisioning - Maximum simultaneous users: 30
Carrier Provisioning - Maximum simultaneous users: 4
LMM - Maximum simultaneous GUI users: 10
TMM - Maximum simultaneous users: 10
Trunk Provisioning - Maximum simultaneous users: 5
The maximum number of concurrent OSSGate connections is 45. Following are maximum
recommended usage limits for concurrent operations (for example when performing Nodes
provisioning, Lines Provisioning, LMM and TMM all at the same time, these limits apply):
Nodes: 5 users
Lines: 30 users
Carriers: 4 users
LMM: 2 users (GUI)
TMM: 2 users
Trunks: 2 users
Note: System response time will increase as the number of concurrent connections increase.
8
Connecting to OSSGate via telnet
A system connects to the OSSGate server by initiating a telnet session to the correct host
name (or IP address) and port number. user must belong to primary authentication group
succcssn to login to OSSGate.
% telnet <ptm_hostname or IP address> <ossgate_primary_port>
Note: The host name or IP address is assigned by the customer network administrator. It
is assigned to the server where OSSGate is configured during installation and setup. Refer
to your local network administrator for the correct address. The default primary port is
10023 (Standard Telnet Port 23 + 10000).
Example of OSSGate login (User input is highlighted ):

$ telnet znc0s0j6 10023
Trying 42.120.94.57...
Connected to znc0s0j6.
Escape character is '^]'.
Enter username and password
> maint maint
maint logged in on 04/08/08 at 08:08:05.
*******************************************************************************
** **
** OSS Gateway **
** **
** This is a PRIVATE Database. **
** **
** All activity is subject to monitoring. **
** **
** Any UNAUTHORIZED access or use is PROHIBITED **
** and may result in PROSECUTION. **
** **
*******************************************************************************
** WARNING : Different service types require **
** different formats. Consult the OSSGate User's **
** Guide, NE1004-512, for detailed information **
** regarding command formats and usage rules. **
** Failure to do so can cause a mismatch between **
** XACore and SESM data. **
*******************************************************************************
SN07 Build: Jul 22, 2004 12:26:02 PM
*******************************************************************************
>
9
OSS/Telnet Client Requirements
Non-Secure channel between client and OSSGate
In order for a telnet connection into OSSGate to work, there are some requirements that the
telnet client must support. Listed below are the options that the telnet client should support:
Support Line Mode. For example. the telnet client should NOT send
character by character to OSSGate. Instead, it should be able to send one line
at a time.
The telnet client should be able to implicitly add a Carrier Return (CR) to
any data coming from the OSSGate server.
The telnet client should implement telnet echo option since this will be
negotiated by OSSGate to turn on/off during login.
Any client that supports these options will work.
Putty Configuration
A freeware Windows telnet client (putty.exe) which supports the above options can be
found at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
After starting up putty, remember to set the above options by checking the following in the
Terminal category:
Implicit CR in every LF
Auto wrap mode initially on
Note: In (I)SN08 OSSGate was tested using Putty Release beta 0.53b version on a Windows
2000 machine. Nortel neither recommends nor provides support for putty.
Unix telnet clients work with OSSGate without the need of any explicit options setting.
10
11
OSSGate putty.exe settings
12
OSSGate putty.exe configuration.

The above screen captures show the common settings for OSSGate use of putty.exe.
Examples settings are as follows;

Enter Host IP address e.g, 47.163.43.250
Select Protocol Telnet.
Enter Port number 10023.
Select Terminal in Category window.
Set Auto wrap mode initially on.
Set Implicit CR in every LF
Select Session in Category window
In Saved Sessions window enter name for session. i.e, MOP-OSSGate
Click on Save.
Click on Load then Open.
12
OSSGate commands
The following commands are supported by OSSGate. Note that the following commands are
accepted only in Control mode (? prompt). To change from input mode (> prompt) to
Control mode, enter (Ctrl+B) at > prompt.
login
Allows user to log in with username and password separated by a space. If a
user enters this command when already logged in, OSSGate logs out the
previous user. Note that when the user telnets into OSSGate, it automatically
prompts for login.
Screen output shown below (User input is highlighted):
> ^B
? login
admin logged out.
> maint maint
maint logged in on 04/08/08 at 08:08:05.
*******************************************************************************
** **
** OSS Gateway **
** **
** This is a PRIVATE Database. **
** **
** All activity is subject to monitoring. **
** **
** Any UNAUTHORIZED access or use is PROHIBITED **
** and may result in PROSECUTION. **
** **
*******************************************************************************
** WARNING : Different service types require **
** different formats. Consult the OSSGate User's **
** Guide, NE1004-512, for detailed information **
** regarding command formats and usage rules. **
** Failure to do so can cause a mismatch between **
** XACore and SESM data. **
*******************************************************************************
SN07 Build: Jul 22, 2004 12:26:02 PM
*******************************************************************************
>
13
If a login user id , password is invalid or the user does not belong to the primary
authentication group succssn login will fail and user will get appropriate error response
> maint maint
User Login Failed, Reason: Authentication failed. Invalid
Username / Password / Unauthorized Group.
If three consecutive attempts to login fail, the telnet session will terminate.
logout
Allows the user to log out of OSSGate.
> ^B
? logout
maint logged out.
>
The current or new user can login after a logout using the login command
> ^B
? login
>
security
Allows the user to know what security service is being used by OSSGate.
Example (User input is highlighted ):
> ^B
? security
Security service is JAAS/PAM based
clearconv
Short for clear conversation, it allows the user to end the OSSGate
session.
> ^B
? clearconv
SESSION TERMINATED.
Connection closed by foreign host.
sesm_version
this communicates and displays the version of CS2000 Management Tools
> ^B
? sesm_version
SN07 Build: Jul 22, 2004 12:26:02 PM
14
mode <OSSGate mode>
When this command is issued without the <OSSGate mode> parameter, it
will display the current mode the OSSGate session is using. The default
mode upon login is set to CI. OSSGate supports two modes, the CI mode and
the XML mode.
Examples: (User input is highlighted):
Example of querying the current mode
> ^B
? mode
Mode is XML.
Example of switching to CI mode

>^B
? mode ci
Mode is CI
Disconnecting from OSSGate

To properly disconnect from OSSGate, the user (or OSS client) should first log out from the
session and then close the session.
Example: (User input is highlighted):
> ^B
? logout
user1 logged out.
> ^B
? clearconv
SESSION TERMINATED.
Connection closed by foreign host.
Note: A user can terminate a session without explicitly logging out, since the clearconv
command automatically logs out any logged-in user. The logout command is useful, for
example, when a user has finished doing the operations and wants to let another user use the
same session, the first user can log out and let another user log in without ending the
session.
15
User Authorization
User Groups
Users of OSSGate applications must belong to the primary user group succssn and to one
or more secondary user groups listed in Table-1
Table 1: User groups
trkadm lnadm mgcadm mgadm emsadm

trkrw lnrw mgcrw mgrw emsrw
trksprov lnsprov mgcsprov mgsprov emsprov
trkmtc lnmtc mgcmtc mgmtc emsmtc
trkro lnro mgcro mgro emsro
A secondary user group consist of a user group domain which defines the range of
applications to which a user group applies. The following are valid domains for OSSGate
applications
adm groups have permissions to do everything rw, mtc, sprov and ro can do
and more.
rw groups can do everything mtc, sprov and ro can do and more, but can not
do adm specific operations.
mtc groups can do everything ro can do and more, but can not do adm, rw or
sprov specific operations.
sprov groups can do everything ro can do and more, but can not do adm, rw
or mtc specific operations.
ro groups have the least permissions. They can only do read only operations.
The CS2000 Management Tools Security and Administration Guide (NN10172611.pdf )

lists the various steps to create users, assign users to specific groups, user group domains
etc. The mapping of application specific operations to user groups is listed in the application
specific chapters discussed in this document. If the user does not have sufficient permissions
to execute the command, an error message Insufficient Security Privileges to perform this
action is returned as part of the response.
16
Line Provisioning with OSSGate
OSSGate is an application that provides a machine interface for provisioning components
within Carrier VoIP. One of these interfaces is for Line Provisioning (part of the CS 2000
Management Tools application). In order to enter Lines Provisioning commands, the
OSSGate session must be running in CI mode. CI mode is the default mode when first
connecting to OSSGate.
The SERVORD+ syntax for provisioning Carrier VoIP lines is very similar to the
SERVORD syntax used in the DMS. SERVORD commands that are executed from
OSSGate are called SERVORD+ commands. With these commands, the endpoint generally
replaces the LEN for Carrier VoIP lines.
For a complete description of the commands and their syntax, please refer to the SERVORD
Reference Manual (NTP 297-8021-808 for North American and NTP 297-9051-8081 for
international)
Some examples are given below for the types of commands that can be entered using
OSSGate.
Examples:
>QDN <DN>
>QLEN <DR_LEN_TYPE >
>QLEN <MGName> <TPname>
>NEW $ <DN> 1FR NORT1 0 0 919 NILLATA 0 <MGName> <TPname> 3WC $
>OUT $ 9917577 <MGName> <TPname> BLDN
.
Note: The media gateway name (MGname) and the termination point (TP) name have
replaced the line equipment number (LEN) wherever the LEN was used in the SERVORD
command. Please note that TP alone may not be unique in the succession call server, but the
MG and TP pair will uniquely addresses a subscriber line.
This can be seen above in the OUT command.
LEN and Gateway/termination Usage in Commands

For most Carrier VoIP lines, the gateway and termination point name replace the LEN in the
command string. However, there is one gateway type which supports either
gateway/termination names or LENs in the command.
For cable (NCS) and MGCP IAD lines this is required. For Centrex IP lines (CICM) only
LEN can be used. However, there are some gateway types which supports either
Gateway/termination names or LENs in the command.
These include MG9000, other large line GW such as Calix, Keymile and some 3rd party
GW, and SIP (Session Server-Lines).
MG 9000
LENS or gateway/termination names may be used in SERVORD+
commands with certain limitations for MG9000 lines.
CICM
LENS must be used for all (I)SN07 and later format Centrex IP lines.
17
DNH Huntgroup DEL command syntax exception
Another change is the modification in the syntax of the DEL command for DNH, DLH, and
MLH members. To delete DNH members, users must enter both DNs, MG Name and TP
names of the members. The legacy DEL command required only DNs to be entered for the
DNH members.
Examples
>DEL $ DNH <DN> <MGname> <TPname> $ bldn
>DEL $ DLH <MGname> <TPname> <key> $
>DEL $ MLH <MGname> <TPname> <key> $ y y
Line Provisioning - Special Case For Lengthy SERVORD Commands

When executing Line Provisioning commands that are greater than 75 characters long via a
telnet session to OSSGate, the commands must be entered following the convention
described in this paragraph. If a SERVORD+ command is greater than 75 characters, the
user should put up to 75 characters on one line, then enter a + symbol and a carriage return
(new line) after the 75th character. The remaining portion of the command should be
entered on the next line. Using this convention communicates to OSSGate that the
command is continued on the next line.
In the following example, the single SERVORD command is split over five lines of input.
Each of the first four lines ends with a + followed by a carriage return, and the prompt is
given back to the user after each carriage return.
Example
>EST $ DNH 9195200570 1FR LATA1 0 les24.mgcp.net aaln/16 9195200571+
>les24.mgcp.net aaln/17 9195200572 les24.mgcp.net aaln/18 9195200573+
>les24.mgcp.net aaln/23 9195200578 les24.mgcp.net aaln/24 $ $ 15
Note: The command when entered at OSSGate can be split at any position.
18
SERVORD commands supported
Appendix B lists the available commands supported for provisioning lines.
Refer to the SERVORD Reference Manual (NTP 297-8021-808 for North American and
NTP 297-9051-8081 for international) for further details and options.
MG 9000 flowthrough command support

The NEW, EST, ADD, DEL, OUT, CDN, and CHDN commands update data on the MG
9000 and MG 9000 Manager. The NEW, EST, and ADD commands add the
termination point, directory number and indicated line class code. The DEL, and OUT
commands delete the termination point. The CDN and CHDN commands change the
directory number. CLN, CKLN, and CHG commands are also supported. All flow through
to the MG 9000 Manager is blocked when the MG 9000 is in an Emergency Stand Alone
(ESA). Other conditions within the MG 9000 Manager and MG 9000 may also block the
successful process of OSSGate commands. Please refer to MG 9000 documentation for
more specific information regarding ESA and other failure modes.
CICM flowthrough command support

SERVORD+ commands are used to ensure that the necessary information is provisioned in
the CS 2000 tables and in the CICM EM for CICM lines. This ensures key labelling
consistency between the CICM client and the CS 2000 representation of the line. The
current flow through provisioning model for CICM lines does NOT flow all SERVORD
commands through to the CICM.
Note: Hunt group commands (eg. EST/ADD/DEL) do not provision CICM correctly. The
use of hunting features on CICM will require separate provisioning via the CICM Manager.
The user must manually ensure that the CICM client key labels are updated via the CICM
Manager. MADN also requires separate provisioning via CICM Manager.
Line provisioning commands sent to CICM gateway as part of flow through provisioning
include: ADO, CDN, CHF, CHL, DEO, NEW, NEWACD, OUT. CICM client specific
SERVORD+ commands (NEW, EST, OUT, etc.) may contain USERID and PASSWD
option. The USERID and PASSWD options are used to specify CICM client information in
the various SERVORD+ commands which create or modify lines.
19
Line provisioning commands sent to CICM gateway as part of flow through provisioning
include : ADO, CDN, CHF, CHL, DEO, NEW, NEWACD, OUT. CICM client specific
SERVORD+ commands (NEW, EST, OUT, etc..) may contain USERID and PASSWD
option. The USERID and PASSWD options are used to specify CICM client information
in the various SERVORD+ commands which create or modify lines. Datafill interaction
include:
Data fill interaction include:
1. Key feature addition overwrites any existing key feature on the CICM
terminal. No SERVORD equivalent data fill rules are applied to CICM data
fill. CS 2000 SERVORD checking still applies.
2. Assignment of multiple features to a single key is not allowed (e.g., 4 rag 4
3WC). Duplicate feature assignments to key 1 only is allowed (e.g., 1
USERID 1234 $ 1 RAG).
3. CICM specific key features USERID and PASSWD must be assigned to key
1. Duplicate feature assignments to key 1 only is allowed (e.g., 1 USERID
1234 $ 1 RAG).
4. The USERID feature cannot be changed using the CHF command. Use DEO
and ADO commands instead. Note that the password is also reset when the
ADO command is executed.
5. The PASSWD feature can be added, changed or deleted at anytime providing
that the USERID feature is provisioned. If the USERID feature is
provisioned, but the PASSWD feature has not been provisioned, there is no
default PASSWD.
6. USERID and PASSWD features will never be sent to the CS 2000
SERVORD interface.
7. CICM and CICM EM applications must be running, otherwise the
SERVORD+ command will fail. SERVORD+ commands are not saved or
queued when CICM communications is unavailable. They will not be
executed when connectivity to CICM is restored.
20
CICM Line provisioning examples.
1. NEW $ 8906917 M5216 CSLINES 0 0 125 1 Y CICM 142 2 00 01 3 3WC 4 ACB 1 $ $
RESULT: features 3WC, ACB, added to CICM LEN
2. NEW $ 8906917 M5216 CSLINES 0 0 125 1 Y CICM 142 2 00 01 3 3WC 4 ACB 1 $ 1

USERID 9999 PROFILE SRV $ 1 PASSWD 1234 $
RESULT: features 3WC, ACB, USERID, PASSWD added to CICM LEN
3. ADO $ CICM 142 2 00 01 1 USERID 123456 $ $
RESULT: USERID feature (no default PASSWD) created on CICM.
4. DEO $ CICM 142 2 00 01 5 3WC 6 RAG 7 ACBAMA $
RESULT: features 3WC and RAG deleted from key 5 and 6 on CICM
5. CHF $ CICM 142 2 00 01 5 3WC 6 RAG 7 ACBAMA $
RESULT: features 3WC and RAG added to keys 5 and 6.
6. OUT $ 1278701234 CICM 142 2 00 01 BLDN $
RESULT: All features and USERID and PASSWD options deleted from CICM
21
21
CICM line OSSGate example
An example of the NEW command to add a new line against a CICM is
new $ 6105000 m5316 cs2kcust 0 0 207 1 Y CICM 000 0 00 01 $
An example of out to remove an existing line is:
Out $ 6105000 CICM 000 0 00 01 BLDN
Blank
Directory
Number
new $ 6105000 m5316 cs2kcust 0 0 207 1 Y CICM 000 0 00 01 $
customer
NEW line LEN Option key
DN group
= No
NCOS
LCC Key Ringing
Issued NOW subgroup SNPA
22
Example of OSSGate new command

Fields:
DN Directory Number
LCC Line Class Code (m5316 in CentrexIP)
Group Customer Group
Subgroup Sub group
NCOS Network Class of Service
SNPA Serving Number Plan Area
Key Which key DN shall be assigned to on the phone
Ringing Will ringing be applied on this line
LEN Line Equipment Number mapped to Media Gateway and terminal
point
22
IBN line OSSGate example
An example of the NEW command to add a new line against a Lines Gateway is
new $ 6103101 ibn res_cust 0 0 207 mediatrix_1.net aaln/0012 dgt $
An example of out to remove an existing line is:
Out $ 6103101 mediatrix_1.net aaln/0012 BLDN
Blank
Directory
Number
new $ 6103101 ibn res_cust 0 0 207 mediatrix_1.net aaln/0012 dgt $
SNPA
NEW line DN customer line Option
group number
NCOS
LCC FQDN
Issued NOW subgroup
23
Example of OSSGate new command

Fields:
DN Directory Number
LCC Line Class Code
Group Customer Group
Subgroup Sub group
NCOS Network Class of Service
SNPA Serving Number Plan Area
FQDN Fully Qualified Domain Name of analogue lines gateway
AALN Analogue gateway line number.
Option DGT Digitone. Required for analogue IBN lines.
23
SERVORD+ Command Examples for SIP Lines Provisioning
SIP lines can be provisioned using the SIP endpoint or the corresponding LEN. The
examples below show a command using the endpoint and the same command using the
LEN.
New SERVORD+ Command Examples
1. NEW $ 6195209998 1FR LATA1 0 SCOT 00 0 00 00 dgt

SIP_DATASIP_PACKAGE SIP Lines SIP_URI
slynch@mordor.comSIP_CLIENT_TYPE SIP Line SIP_LOCATION
Nortel Networks.RTP.NC0SIP_PASSWD scott11 $ DPL Y 10 $
2. NEW $ 6195209998 1FR LATA1 0 vmg1 SCOT/000/0/0000 dgt

SIP_DATASIP_PACKAGE SIP Lines SIP_URI
slynch@mordor.comSIP_CLIENT_TYPE SIP Line SIP_LOCATION
Nortel Networks.RTP.NC0SIP_PASSWD scott11 $ DPL Y 10 $
CHF Command Examples
1. CHF $ SCOT 00 0 00 00 SIP_DATA SIP_PACKAGE siplines

SIP_PASSWD scott11 SIP_CLIENT_TYPE IBN SIP_LOCATION
IBM.RTP $ $
2. CHF $ vmg1 SCOT/000/0/0000 SIP_DATA SIP_PACKAGE siplines

SIP_PASSWD scott11 SIP_CLIENT_TYPE IBN SIP_LOCATION
IBM.RTP $ $
OUT Command Examples
1. OUT $ 6195209998 SCOT 00 0 00 00 BLDN
2. OUT $ 6195209998 vmg1 SCOT/000/0/0000 BLDN
24
Query Examples
1. > QLEN SCOT 00 0 00 00
LEN: SCOT 00 0 00 00
END POINT: vmg1 SCOT/000/0/0000
TYPE: SINGLE PARTY LINE
SNPA: 619
DIRECTORY NUMBER: 5209998
LINE CLASS CODE: 1FR
SIGNALLING TYPE: DIGITONE
LINE TREATMENT GROUP: 0
LINE ATTRIBUTE INDEX: 0
CARDCODE: RDTLSG GND: N PADGRP: PKNIL BNV: NL MNO: Y
PM NODE NUMBER : 87
PM TERMINAL NUMBER : 1
OPTIONS:
DGT DPL Y 10
OFFICE OPTIONS:
SRA
END POINT DATA:
SIP_CLIENT_TYPE: sip line
SIP_EP_NAME: SCOT/000/0/0000
SIP_VMG_NAME: vmg1
SIP_DN: 6195209998
SIP_LOCATION: nortel networks.rtp.nc0
SIP_PACKAGE: sip lines
SIP_URI: slynch@mordor.com
2. > QDN 5209998

DN: 5209998
SNPA: 619 SIG: DT LNATTIDX: 0
LINE EQUIPMENT NUMBER: SCOT 00 0 00 00
END POINT: vmg1 SCOT/000/0/0000
LINE CLASS CODE: 1FR
LINE TREATMENT GROUP: 0
CARDCODE: RDTLSG GND: N PADGRP: PKNIL BNV: NL MNO: Y
PM NODE NUMBER : 87
PM TERMINAL NUMBER : 1
OPTIONS:
DGT DPL Y 10
OFFICE OPTIONS:
SRA
END POINT DATA:
SIP_CLIENT_TYPE: sip line
SIP_EP_NAME: SCOT/000/0/0000
SIP_VMG_NAME: vmg1
SIP_DN: 6195209998
SIP_LOCATION: nortel networks.rtp.nc0
SIP_PACKAGE: sip lines
SIP_URI: slynch@mordor.com
25
SIP provisioning information
SIP provisioning information include:
1. SIP_PACKAGE - Up to 30 characters.
2. SIP_URI - Up to 60 characters.
3. SIP_CLIENT_TYPE - The system come with a default value of ONT.
This element can be created on the Prov client. This is used to provision
whether the user (sip line) has a static client that it will use to register or not.
4. SIP_PASSWD - The administrator defines the password rules. They include
the following types or rules:
Have a minimum password length between 4 and 10.
Have a minimum of 0 to 10 numerical characters.
Have a minimum of 0 to 10 non-numerical characters.
Be made up of ASCII characters 0x20 through 0x73 hexadecimal or 32
through 126 decimal.
5. SIP_LOCATION - The location name, a brief description of the location
being added. This field cannot be null. Maximum length = 30 characters.
6. SIP_SUBDOMAIN - Enter the name of the new local domain. The domain
name must not be more then 60 chars in length and cannot contain the
following symbols or characters:
$()|;~%[]/!^{}?@&+,#*=:<>
SIP SERVORD examples

See below for SIP SERVORD examples:
1. SERVORD NEW Example using SIP Endpoint.

new $ 6136040004 ibn ibntst 0 0 lata1 0 sprintnlclocation1 +
sip_data sip_package basic package sip_uri scott@nortelnetworks.com +
sip_client_type ont sip_location other2 sip_passwd scott11 +
sip_subdomain sm1.nortelnetworks.com $ dpl y 10 dgt cwt $
2. SERVORD NEW Example using LEN.

new $ 6136040004 ibn ibntst 0 0 lata1 0 ss 000 6 00 04 + sip_data +
sip_package basic package sip_uri scott@nortelnetworks.com +
sip_client_type ont sip_location other2 sip_passwd scott11 sip_subdomain +
sm1.nortelnetworks.com $ dpl y 10 dgt cwt $
26
Query System Commands
27
Query System Commands

The line data base query system commands are used to determine the status (working or
unassigned) of a directory number or of the line equipment, and to identify the parameters
associated with a working line. The commands can be executed at any level of the MAP
terminal or OSSGate system, and no commands are needed to enter or leave the query
mode. The user simply logs on at a MAP or OSSGate position and immediately enters a
query command.
At the CS2000 MAP terminal either a prompt or no-prompt mode of entry can be used. The
$ character is used to indicate the end of a list of options. The user can confirm, reject, or
edit the input for Query system commands.
For OSSGate the no-prompt method is used.
27
Entering Query System Commands in the Prompt Mode
To enter query system commands in the prompt mode, proceed as follows:

1. Log on at a valid input device.
2. Enter one of the query system commands and (CR).
3. The CS2000 will display the first prompt. Enter the valid parameter. If an incorrect
parameter entered, the system prompts for the correct information.
The Table inVolume 2 of the NTP 297-8041-808 provides valid input parameters for the
query system prompts.
4. On entry of a valid parameter, the CS2000 will display the next prompt. Enter a valid
parameter as described in Step 3. The CS2000 will continue to prompt until all
necessary parameters have been entered.
Example:
>QDN:
DIRECTORY NUMBER:
>3625004
Entering Query System Commands in the No-Prompt Mode

To enter query system commands in the no-prompt mode, log on, then enter one of the
query system commands along with the required valid parameters. If an error is made,
the CS2000 reverts to the prompt mode of entry and begins prompting at the prompt
where the invalid parameter was entered.
Example:
>QDN 3625004
The following pages list the most commonly used query system commands during service
order activity.
To reference other query system commands and more detail on the ones listed, see NTP
297-8041-808 Volume 2 Section 2.
28
Query Directory Number (QDN)
QDN queries information about hardware and software associated with a DN.
Example:
ENTRY:QDN
DIRECTORY NUMBER
8795530
DN: 8795530
SNPA: 162 SIG: N/A LNATTIDX: N/A
LINE EQUIPMENT NUMBER: HOST 00 0 00 30
LINE CLASS CODE: M5209
KEY: 1
CUSTGRP: IBNDEMO SUBGRP: 0 NCOS:0 RING:Y
CARDCODE: 6X21BC GND: N PADGRP: NPDGP BNV: NL MNO: Y
PM NODE NUMBER: 30
PM TERMINAL NUMBER: 1
OPTIONS: 3WC CFU CFB CFD LNRA RAG INSPECT CPU
29
Query Line Equipment Number (QLEN) from CS2000
QLEN obtains a printout of line data related to a specified LEN.
Example:
> QLEN CICM 0 0 0 30
------------------------------------------------------------------------------------------
LEN: CICM 00 0 00 30
SNPA: 162
LINE CLASS CODE: M5316 SET
CUSTGRP: IBNDEMO SUBGRP: 0 NCOS: 0 RING: Y
CARDCODE: GWLEBS GND: N PADGRP: NPDGP BNV: NL MNO: Y
PM NODE NUMBER: 30
OPTIONS:
3WC MCH RAG DCPU DCPK PRK EBO LNRA GIC SALES 07 CFK $ 1
$
CPU 0 HOST 00 1 18 09 $ SCL 0 L30 CNF C30
KEY DN
1 8795530
2 8795540
3 GIC 7 SALES
KEY FEATURE
1 CFK
1 CPU 0 HOST 00 1 18 09 $
1 SCL 0 L30
1 MCH
1 PRK
1 EBO
1 DCPK
3 RAG
4 CNF C30
5 GIAC
6 ICM HOST 00 1 19 04 7 N N
7 EMW CLASSP 1
8 3WC
30
Query Line Equipment Number (QLEN) from OSSGate
QLEN obtains a printout of line data related to a specified LEN and includes provisioning
information as well.
Example:
> QLEN CICM 0 0 0 30
--------------------------------------------------------------------------------------------------------
LEN: CICM 00 0 00 30
END POINT: CICM-000 tp/0/0030
SNPA: 162
LINE CLASS CODE: M5316 SET
CUSTGRP: IBNDEMO SUBGRP: 0 NCOS: 0 RING: Y
CARDCODE: GWLEBS GND: N PADGRP: NPDGP BNV: NL MNO: Y
PM NODE NUMBER: 30
OPTIONS:
3WC MCH RAG DCPU DCPK PRK EBO LNRA GIC SALES 07 CFK $ 1
$
CPU 0 HOST 00 1 18 09 $ SCL 0 L30 CNF C30
KEY DN
1 8795530
2 8795540
3 GIC 7 SALES
KEY FEATURE
1 CFK
1 CPU 0 HOST 00 1 18 09 $
1 SCL 0 L30
1 MCH
1 PRK
1 EBO
1 DCPK
3 RAG
4 CNF C30
5 GIAC
6 ICM HOST 00 1 19 04 7 N N
7 EMW CLASSP 1
8 3WC
31
Query Software Unassigned Directory Numbers (QDNSU) from CS2000
QDNSU obtains a detailed or summary listing of all Software Unassigned DNs.

Example:
ENTRY:
>QDNSU
DIRECTORY_NUMBER_RANGE: ALL
>R
FROM_DN:
>3625000
TO_DN:
>3625005
TREATMENT: UNDT
>(CR)
SUMMARY OR DETAIL: S
>D
SYSTEM RESPONSE:
COMMAND AS ENTERED
QDNSU R 3625000 3625005 UNDT D
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT
Y (CR)
WARNING: QUERIES OF ALL DN'S OR QUERIES OF A LARGE RANGE OF
DN'S MAY RUN FOR 30 MINUTES OR MORE BEFORE PRODUCING ANY
OUTPUT REPORT ON UNASSIGNED DN FROM 3625000 TO 3625005
3625004 BLDN
3625005 BLDN
TOTAL COUNT OF UNASSIGNED DN FROM 3625000 TO 3625005: 2
32
Query Working Assigned Directory Number (QDNWRK) from CS2000
QDNWRK obtains a detailed or summary printout of Software Assigned DNs.

Example:
ENTRY:
>QDNWRK (CR)
DIRECTORY_NUMBER_RANGE: ALL
>R
FROM_DN:
>6211200 (CR)
TO_DN:
>6211300 (CR)
LINE CLASS CODE:
>IBN (CR)
OPTION:
>DGT (CR)
SUMMARY OR DETAILS: S
>(CR)
SYSTEM RESPONSE:
COMMAND AS ENTERED
QDNWRK R 6211200 6211300 IBN DGT S
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT
>Y (CR)
WARNING: QUERIES OF ALL DN'S OR QUERIES OF A LARGE RANGE OF
DN'S MAY RUN FOR 30 MINUTES OR MORE BEFORE PRODUCING ANY
OUTPUT REPORT ON WORKING DIRECTORY NUMBERS
FROM 6211200 TO 6211300
LCC IBN OPTION DGT
TOTAL COUNT OF WORKING DN FROM 6211200 TO 6211300: 4
33
Query Group (QGRP)
QGRP obtains a printout of all the members in the following group types: Call Pickup
(CPU), Speed Call User (SCU), Query Busy Station (QBS), Multiple Appearance Directory
Number (MDN), Group Intercom (GIC), Hunt (HNT), and Key Short Hunt (KSH).
The optional feature Group Number Feature Control allows the assignment of group
numbers to CPU, SCU and HNT groups. When this feature is activated, the prompt
GRP_NUM replaces DN_or_LEN.
Query CPU Group example:

ENTRY:
>QGRP (CR)
GRP_TYPE:
>CPU (CR)
LEN: >>00 0 18 08 (CR)
SYSTEM RESPONSE:
CPU GROUP
----------
LINKLEN: HOST 00 0 18 08 3625089
HOST 00 0 18 09 3625090
HOST 00 0 18 10 3625091
HOST 00 0 18 11 3625092
HOST 00 0 18 12 3625093
HOST 00 0 18 13 3625094
The number of members in the CPU GROUP is 6.
Query Group SCU example:

ENTRY:
>QGRP (CR)
GRP_TYPE:
>SCU (CR)
LEN:
>00 0 18 08 (CR)
SYSTEM RESPONSE:
SCU GROUP
-----------
CONTROLLER: HOST 00 0 18 08
HOST 00 0 18 13
HOST 00 0 18 12
HOST 00 0 18 11
HOST 00 0 18 10
HOST 00 0 18 09
The number of members in the SCU GROUP is 6.
34
35
Student Exercise
Students are required to provision lines into the customer groups they have just created.
The following instructions may change depending on the course location and equipment
available. Your instructor will advise.
Each team will use OSSGate/Servord to create the following;
One Analogue line minimum required features only at this point.

One CICM business set comprising of 2 DNs on keys 1 & 2.
Your instructor will advise of Media Gateway names, line numbers and LENs.
Note down the information.
Analogue Line Info CICM LEN
Team 1__________________________ __________________________________
Team 2__________________________ __________________________________
Team 3__________________________ __________________________________
Team 4__________________________ __________________________________
Team 5__________________________ __________________________________
Team 6__________________________ __________________________________
Note down the DNs for all the teams.

Analogue DN CICM DNs
Team 1__________________________ __________________________________
Team 2__________________________ __________________________________
Team 3__________________________ __________________________________
Team 4__________________________ __________________________________
Team 5__________________________ __________________________________
Team 6__________________________ __________________________________
36
37
Module 4
TRAVER
nortel.com/training
0
1
Module 4
TRAVER
Purpose
The purpose of this section is to introduce you to the following
concepts;
> The Translation Verification (TRAVER) tool
> List the common commands used by TRAVER.
> Describe the purpose of TRAVER.
> Explain the results of Line and Trunk Travers.
2
2
3
TRANSLATIONS VERIFICATION.
A Translation Verification, or TRAVER, is a computer programme which aids in
determining the path which a particular call will take through translations tables.
TRAVER is used by datafill persons to "dry run" a datafill, so that the sequence of
translations can be verified. Traver may be used to test the translations for calls from
Lines, Trunks, Attendant consoles, Virtual Facility Groups and Routes.
Traver Line
To verify a specific type of Line call ( 4 - digit, in this example ), a TRAVER is entered at
the MAP terminal by typing in this command :
TRAVER L 8795301 5302 T
Where the parameters are . . . . .
L = lines ( other parameters are available too )
8795301 = dialling number i.e. the calling line
5302 = dialled number i.e. the called line
The last parameter comprises T, B, or NT where :

T= a request to trace translations tables by listing each TUPLE of each TABLE
used during the translation process.
B= a request to trace through translations tables by listing each TUPLE of each
TABLE used during the translation process, as well as displaying the actual
routes ( trunks, etc. ) selected.
NT = no trace of TUPLES is to be displayed ; only digit translation routes are to be
reported.
NOTE : You may also traver digits starting with * ( star ) or # ( hash ) by entering B for the
star and C for the hash.
Example : To traver a line dialling a feature code of *70, the called line entry would be B70.
The TRAVER displays the entries in the translations tables that were used to arrive at the
terminating point, which in this example was a directory number on the CS2000. An
example of the output for this command is given overleaf.
4
In the example on page 1, the command entered is for a station to station call where line
8795301 called 5302. An example of the result is given below.
Traver L 8795301 5302 T
TABLE IBNLINES
HOST 00 0 01 01 0 DT STN IBN 8795301 IBNDEMO 0 0 162 $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5301 5301
( PUBLIC ( ADDRESS 162 897 NNNN ) $ ) $
TABLE NCOS
IBNDEMO 0 0 0 NO_REST ( XLAS PXDEMO NXLA NDGT ) $
TABLE CUSTHEAD : custgrp, prexla, custxla, featxla, vactrmt, and digcol
IBNDEMO NXLA CXDEMO FXDEMO 1 DCDEMO
TABLE DIGCOL
DCDEMO 5 COL S 3
TABLE IBNXLA : XLANAME PXDEMO0
TUPLE NOT FOUND
Default is to go to next XLA name.
CUST PRELIM XLA name is NIL. Go to next XLA name.
TABLE IBNXLA : XLANAME CXDEMO
CXDEMO 5 EXTN N N Y 162 879 4 $
TABLE TOFCNAME
162 879
TABLE DNINV
162 879 5302 ILC HOST 00 0 01 02
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5302 5302
( PUBLIC ( ADDRESS 062 879 NNNN ) $ ) $
+++ TRAVER : SUCCESSFUL CALL TRACE +++
An explanation of the result is given opposite.
5
In this TRAVER, we see that the following occurred:
1.The TRAVER looked at table IBNLINES to determine the customer group name
(IBNDEMO) and NCOS number (0).
2.Table NCOS indicated the assignments of any translators to NCOS numbers.
3.Table CUSTHEAD indicated any translators assigned to the customer group.
4.Table DIGCOL indicated a first digit dialled of 5 should use a digit collector (DCDEMO)
to collect the next 3 digits.
5.The next two lines show that there were no preliminary translators assigned in NCOS or
CUSTHEAD.
6.Table IBNXLA positioned on the customer group translator (CXDEMO) for the digit 5
and determined that 5 is the leadingdigit of a 4 - digit extension number.
7.Table TOFCNAME indicated whether or not the thousands groupof the dialled extension
number had been opened up for assignment to LENs in table DNINV.
8.Table DNINV checked to see if the dialled number had been assigned to a line equipment
number (LEN).
The message that the TRAVER was successful means that the software trace went where
your entries in the data tables routed the call.
This message does not mean that the call reached the number called i.e. it does not prove
that the line itself is working.
6
Traver Trunk
To verify the translations for incoming trunk calls the following Traver command is used.
TRAVER TR CLLINAME DIGITS B, T, or NT.
TR = Trunk ( other parameters are available too )
CLLINAME = the Common Language Location Identity name assigned to
the trunk group.
DIGITS = dialled number i.e. the incoming digits received on the trunk
The last parameter comprises T, B, or NT which were described
earlier.
An example of a trunk traver is given on the next page.
7
>traver tr ntdemo2wnat 01628795528 b
TABLE TRKGRP
NTDEMO2WNAT IBNT2 0 NPDGP NCRT MH4BGRP 0 LIDL 0 N ANSDISC 0 Y N
NN
NNN00N
0 0 0 0 N N N N N N N N N NATL $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
AIN_OFFICE_TRIGGRP NIL
INAP Origination Attempt TDP: no subscribed trigger.
TABLE NCOS
MH4BGRP 0 0 0 NOREST $
TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,
AND DIGCOL
MH4BGRP NXLA MH4BCXLA NXLA 0 NDGT
TABLE DIGCOL
NDGT specified: digits collected individually
INAP Info Collected TDP: no subscribed trigger.
TABLE IBNXLA: XLANAME MH4BCXLA
TUPLE NOT FOUND
Default from table XLANAME:
MH4BCXLA
(NET N N 0 N NDGT N Y DOD N 4 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9
TABLE DIGCOL
TABLE LINEATTR
4 IBN NONE NT 0 0 NILSFC 0 PX MH4BXLA NIL 00 162_NPRT_4 NLCA_NILLA_1
$
LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE
TABLE XLAPLAN
162_NPRT_4 NSCR 162 NPRT NONE N $ $
TABLE RATEAREA
NLCA_NILLA_1 NLCA NIL NILLATA $
TABLE PXHEAD
MH4BXLA DFLT RTE ( MM 10 11) ( DEST 3)$ DFOP ( MM 10 11)$ NOCON 9
THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795528
TABLE PXCODE
MH4BXLA 016287955 016287955 RTE ( MM 11 11) ( DEST 79)$
TABLE: PXRTE
8
KEY: MH4BXLA 79
. T IBNRTE 79
. . TABLE IBNRTE
. . 79 DN 162 879 N 0 4
. . . TABLE TOFCNAME
. . . 162 879 $
. . . TABLE DNINV
. . . 162 879 5528 L HOST 00 0 00 28
TABLE DNFEAT
TUPLE NOT FOUND
. . . TABLE DNATTRS
. . . TUPLE NOT FOUND
. . . TABLE DNGRPS
. . . 162 879 5528 5528
. . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$
. . EXIT TABLE IBNRTE
EXIT TABLE PXRTE
INAP Info Analyzed TDP: no subscribed trigger.
+++ TRAVER: SUCCESSFUL CALL TRACE +++
DIGIT TRANSLATION ROUTES
1 LINE 1628795528 ST
TREATMENT ROUTES. TREATMENT IS: GNCT
1 GNCT
This example shows a typical Trunk Traver. The information about the Customer Group and
NCOS is contained in the Trunk Group Table information. The call passes through
Customer Group translations in a similar way to line calls and is resolved as a Network call.
The call passes through Universal translations and is terminated on a line within the switch.
Universal translations are covered in course 3006A.
9
Traver VFG (Virtual Facility Group)
To verify the translations for incoming VFG calls the following Traver command is used.
TRAVER V VFGNAME DIGITS B, T, or NT.
V= VFG ( other parameters are available too )
VFGNAME = the name assigned to the Virtual Facility Group.
DIGITS = dialled number i.e. the incomming digits received on the VFG.
The last parameter comprises T, B, or NT which were described earlier.
An example of a VFG traver is given below.
>traver v alevfg 725101 b

TABLE VIRTGRPS
ALEVFG SIZE 2 IBN N ALECGRP 0 0 4 N N N $
TABLE NCOS
ALECGRP 4 0 0 VFG ( XLAS ALECPTV NXLA NDGT)$
TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA,
VACTRMT, AND DIGCOL
ALECGRP NXLA ALECCT ALECFET 10 ALECDC
TABLE DIGCOL
TUPLE NOT FOUND
Default is RPT
TABLE IBNXLA: XLANAME ALECPTV
TUPLE NOT FOUND
ALECPTV
(NET N N 0 N NDGT N N DOD N 68 162_NPRT_4 NLCA_NILLA_1
NONE $) $ 9
TABLE DIGCOL
TABLE LINEATTR
68 IBN NONE NT 0 0 NILSFC 0 PX EMERG NIL 00 162_NPRT_4
The rest of this TRAVER continues as for any call processed by Universal Translations.
10
The traver example on page 7 shows the result of digits received on a VFG. It is also
possible to traver a Line originated call through a VFG and see the originating and
terminating translation result. The command is:-
traver l 8795528 615529 b rtevfg all
An example output for this command is shown below. The originating line is a business set.
TABLE KSETLINE
HOST 00 0 00 28 1 DN Y 8795528 IBNDEMO 0 0 162 (CWT) (3WC) (CWI) (CPU)
(CFX)
$
TABLE DNATTRS
162 879 5528
(PUBLIC ( NAME KEITH_ROBERTS) $)$ $
TABLE DNGRPS
TUPLE NOT FOUND
TABLE KSETFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
AIN Orig Attempt TDP: no subscribed trigger.
TABLE NCOS
IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT)$
AND DIGCOL
TABLE DIGCOL
DCDEMO 6 COL S 3
TABLE IBNXLA: XLANAME PXDEMO0
TUPLE NOT FOUND
TABLE IBNXLA: XLANAME CXDEMO
CXDEMO 61 ROUTE N N N 2 N 1 6 NDGT Y T IBNRTE 61 $
11
TABLE DIGCOL
AIN Info Collected TDP: no subscribed trigger.
AIN Info Analyzed TDP: no subscribed trigger.
TABLE IBNRTE
61 VFG N N N VFGDEM 0
EXIT TABLE IBNRTE
1 VFG: VFGDEM 5529 ST
1 GNCT
--->
---> Resolving VFG: VFGDEM Route with calling digits 5529
--->
TABLE VIRTGRPS
VFGDEM SIZE 2 IBN N MH4BGRP 0 0 0 Y N N $
TABLE NCOS
MH4BGRP 0 0 0 NOREST $
AND DIGCOL
MH4BGRP NXLA MH4BCXLA NXLA 0 NDGT
TABLE DIGCOL
NCOS PRELIM XLA name is NIL. Go to next XLA name.
TABLE IBNXLA: XLANAME MH4BCXLA
MH4BCXLA 5 EXTN N N Y 162 879 4 $
AIN Info Collected TDP: no subscribed trigger.
AIN Info Analyzed TDP: no subscribed trigger.
TABLE TOFCNAME
162 879
TABLE DNINV
162 879 5529 L HOST 00 0 00 29
AIN Term Attempt TDP: no subscribed trigger.
TABLE DNATTRS
12
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND

1 LINE 1628795529 ST
1 GNCT
13
The following is an extract from the DMS Quick Reference Guide NTP TAM-1001-018
TRAVER Commands
(NTP 297-1001-360, Basic Translations Tools Guide)
(NTP 297-YYYY-350, Translations Guide)
The TRAVER command simulates a call and displays the translation and routing tables the
call accesses.
Note: The following information is an overview of TRAVER and provides
only samples of the many variables that are possible using TRAVER.
Use HELP TRAVER at CI level for details. Also, see the REVXLER
command within this guide.
TRAVER L <digits> [T,NT,B] %% see Notes & Trace Option
TR <clli> [T,NT,B]
TR >clli> <digits> <RPOA/RPOAS> [T,NT,B]
C <console> [T,NT,B]
V <vfg> [T,NT,B]
R <table> [T,NT,B]
L <digits> <bc> <64kdata/56kdata> [T,NT,B]
Notes: 1. For digits'*' substitute a 'b'for a '#' substitute a 'c'.
2. For ISDN, bc = bearer capability.
3. For DMS PH, RPOA = registered private operating agencies.
3. T = [authcode] [mfst] [billno] [bill_mfst].
4. NT = (includes routing and digit information).
5. B = both T and NT options.
Trace Options
The "T" option uses parallel software to simulate a call and display the tables used to
translate and route a call along with the appropriate tuple for each table. The "NT (no
trace) option has its own setup processor which calls translation utilities to determine a
result. This option displays digit translation routes, position routes, and the circuits and/or
treatments on which the call would terminate. The "B" option invokes both the T and the
NT option and displays both the call's route & treatment.
Optional Parameters
<authcode> for tracing LATA Equal Access System (LEAS) calls, mfst, billno, and
bill_mfst parameters are needed; enter nil value (N) for authcode before
specifying other optional parameters.
<mfst> indicates the type of signalling on the trunk, the called number MF start
signal. A LEAS call cannot be properly traced without this parameter.
<billno> is the number to be billed (an information digit plus the calling digits). A
LEAS call cannot be properly traced without this parameter.
<bill_mfst> indicates the type of signalling on the calling number trunk; a call involving
LEAS cannot be properly traced without this parameter.
14
Line TRAVERs
>TRAVER L <calling_dn> <called_dn> [T,NT,B]
>TRAVER L <ISDN_dn> <bc> [T,NT,B]
>TRAVER L <calling_dn> <called ISDN _dn> <bc> <bc_name> [T,NT,B]
Trunk TRAVER
>TRAVER TR <CLLI> <digits> [T,NT,B]
Console TRAVER
>TRAVER C <console CLLI> <digits> [T,NT,B]
Virtual Facility Groups TRAVERs

>TRAVER V <vfg> <digits> [T,NT,B]
>TRAVER L <calling_dn> <called_dn> [T,NT,B] RTEVFG ALL
ISDN TRAVERs
Bearer Capability Routing example travers:
> traver l 4844015 94834035 bc 64kdata b % for BC 64kdata calls
> traver l 4844016 94834036 bc 56kdata b % for BC 56kdata calls
Some PRI routing examples: (PUBlic call type is traver default)

> traver tr PRITEST1 n cdn e164 19192384567 b % NPI:E164, NSF:nil, call type:PUBlic
> traver tr PRITEST2 n cdn e164 2831199 prvt b % NPI:E164, NSF:PRVT, call
type:PriVaTe
> traver tr PRITEST3 n cdn pvt 095 tie b % NPI:PVT, NSF:TIE, call type:PriVaTe
Note: The type of number (TON) is in the Called Party Number and Calling Party
Number information element. According to the Nortel PRI protocol specifications, when
the NPI is Private the TON is Subscriber. When the NPI is E.164, the TON is based
on the number of digits dialed as follows:
less than 10 digits: TON is Subscriber (Local)
exactly 10 digits: ` TON is National (NAtional)
more than 10 digits: TON is International (INternational)
15
Module 6 Exercise
Students are to run a Traver of their designated line dialling an extension call.
Note down the Tables that are shown.
Which Tables contain no data?

____________________________________
____________________________________
____________________________________
____________________________________
16
17
Module 5
Trunk Groups
nortel.com/training
0
1
Module 5 Trunk Groups
Purpose
The purpose of this section is to introduce the student to the
concepts of;
> Trunk Groups and their datafill.

List the tables used to establish voice calls.
Complete a trunk group datafill exercise
2
2
3
Centrex CS2000 Universal Translations
CUSTENG Universals
CUSTHEAD
IBNXLA
NCOS
IBNTREAT
CLLI
TRKGRP
TRKSGRP
TRKMEM
Trunks
4
4
5
5
Trunk Network the big picture
PBX
R.O.W B
Switch
A
Switch PBX
C A
Switch
B Switch
E
6
Trunk Groups
Trunks form the physical connection between exchanges. The exchanges may be either
Public exchanges or PBXs (Private Branch eXchanges).
Linking exchanges together form Networks over which calls may pass from one location to
another. An example of this is the PSTN or Public Switched Telephone Network. A number
of operators are licensed to run such networks. Many Private Networks exist linking
together the multi location offices of private companies.
The above diagram illustrates a simple group of switch linked together. The links between
the switches are designated as Trunk Groups.
Individual trunk circuits are grouped together to form Trunk Groups in which they share
common attributes. A number of parameters need to be established in order for trunks to
work. Among these are, quantity, signalling type, direction, hardware, name, customer
group and NCOS.
6
Services or
CS2000
CS2000 CS2000c MCS
Back Announcements
IEMS GWC
Management CS LAN
USP

IP
PSTN
MG15K Network CMTS
Video
Hosted PBX Feed
Centrex IP HFC
HFC
Derived Lines PBX

Cable
Modem
CPE
xDSL
IAD
IAD
m6350 i2004 DSLAM
Softclient Etherset
7
In a CS2000 environment, calls to the Public Switched Telephone Network

(PSTN) would ingress/egress via an MG15k ISUP/PRI Gateway.
These gateways would be hosted by the CS2000s GWCs.
Direct trunks from PBXs would also be hosted in a similar method.
7
Trunk Groups a simple view
CLLI
er
TRKGRP a rri
C
TRKSGRP
TRKMEM
er
a rri
C
CLLI
TRKGRP
TRKSGRP
TRKMEM
8
Trunk Groups
Trunks form the physical connection between exchanges. The exchanges may be either
Public or Private (PBXs). Linking exchanges together form Networks over which calls may
pass from one location to another. An example of this is the PSTN or Public Switched
Telephone Network. A number of operators are licenced to run such networks. Many
Private Networks exist linking together the multi location offices of private companies.
group and NCOS.
A number of tables are used to datafill voice trunk information although a number of other
tables, such as hardware inventory tables and CCS7 tables are required.
For CCS7 (C7UP) trunks, the following data tables will be covered;
CLLI, TRKGRP, TRKSGRP and TRKMEM.
For Primary Rate Interface (PRI) trunks, the following additional data tables are covered in
an appendix;
LTMAP, LTDEF and LTCALLS
8
Table CLLI
Table CLLI is used to define a Common Language Location Identifier, (CLLI name).
CLLI names are used to identify a variety of resources on the CS2000 amongst which are
Tones, Announcements and Trunk groups. The fields in table CLLI are the same, regardless
of the use to which the CLLI name is put. The CLLI name provides the link through all the
following trunk tables and may be pointed to from a variety of other tables in the Centrex or
Universal translations environment.
Table TRKGRP
Table TRKGRP defines each trunk group, the customer group to which it belongs with
associated attributes, direction and options.
The datafill for table TRKGRP potentially differs dependant on the direction type and the
signalling type.
Table TRKSGRP
Table TRKSGRP defines the signalling parameters used. Two subgroups may be defined for
a trunk group which means that trunks of a different signalling type may be grouped
together within a single group, however, this is not common practise.
Table TRKMEM
Table TRKMEM defines and allocates the hardware resource used by each individual trunk
within the trunk group. One physical connection may contain a number of trunks as in a
PCM 30 circuit, or only a single trunk.
9
Trunk Group Table Examples (C7UP)
The following examples illustrate some typical trunk table datafill.
Full information is contained in NTP Succession Networks Operational Configuration:
Data Schema Reference NN10324-509.01.02
10
Table CLLI Example (C7UP & PRI)
TABLE CLLI
CLLI ADNUM TRKGRSIZ ADMININF
UKPVG 155 31 PVG_TO_UK
UKPRI 743 30 TOPVG
11
Table CLLI Example

In this example, a CLLI name is created and an administration number assigned to it.
Further fields are used to size the maximum number of trunk members and provide a
description of the CLLI name use.
The fields are:-
CLLI A name of up to 16 characters. There are four types of CLLI used on the
CS2000.
They are:-
CLLI codes contained in external files that are added automatically if a
feature is present on the switch.
Fixed CLLI codes that must be added to the switch exactly as shown e.g.
EBOT for Executive Busy Override Tone.
Suggested CLLI codes that must be added to table CLLI but need not be as
suggested e.g. RING for ring back tone.
CLLI codes defined by the operating company e.g. A Trunk Group CLLI
ADNUM Administration number. A number in the range 0 - 8191. The ADNUM is
used by the DMS for down stream processor purposes e.g. to identify a CLLI
in an AMA record. The number must be unique to each CLLI and may not be
changed unless all references to the CLLI are first removed from other tables.
ADNUM 0 should never be used as some downstream processors do not
accept 0 as a legitimate value. ADNUM 1 - 50 are reserved and may not be
used for freely defined CLLIs.
11
TRKGRSIZ Trunk Group Size. A number in the range 0 - 2047. This field sizes the
maximum number of trunks expected in the trunk group. This number may
be greater than the actual number of trunks to allow for future expansion,
however, it may not be decreased to a value other than 0 and only if all
references to the CLLI have been deleted.
ADMININF Administration Information. This field is not used by the CS2000 but is there
to enable a description of the CLLI to be added for information purposes. A
description of up to 32 characters may be entered.
12
Table TRKGRP example (C7UP)
TABLE TRKGRP
GRPKEY GRPTYP TRAFSNO PADGRP NCCLS CUSTNAME SUBGRPNO
ukpvg ibnt2 0 npdgp ncrt cs2kcust 0
SELSEQ NCOS BILLDN SUPV DISCTSEL INTRAGRP DIGIT0
aseq 0 n ansdisc 0 n n
DIGIT1 DTI TES CDR SMDR TRC ALTNCOS TRKDSR LSCFN ALTLSCFN
n n n n n 0 0 N 0 0
LSCINCPT ALSCINCP IGA FDN FDV FLASH DPX PREEMPT AIOD
0 0 n n n n n n n
REORIG OFFNET COFFTYP OPTION
N n natl $
13
In this example, an IBNT2, (bothway), trunk group has been established. The trunk group
has been assigned to a customer group and assigned an ncos. Further fields assign the
supervision parameters and determine the order in which free trunks are sought. As this is a
BOTHWAY trunk group, certain fields only apply to incoming calls and some to outgoing
calls, also, many fields have no application in the U.K. and may be assigned their default
value. The datafill may be slightly different for IBNTO and IBNTI trunk groups.
The fields are:-

GRPKEY Group key. This field contains the subfield CLLI and the CLLI name of the
trunk group should be entered here. The CLLI name must have been
established in table CLLI before it can be entered here.
GRPTYP Group type. Enter the trunk group type. This may be IBNT2, IBNTO or
IBNTI. In this example, IBNT2 has been used.
TRAFSNO Traffic separation number. A number used to give separate OM counts for
traffic on this trunk group. If not required enter 0.
PADGRP Pad group. Enter the name of a Pad group assigned to the trunk group. The
pad group must first be built in table PADDATA and is used to define
transmission parameters for the trunks. Enter NPDGP (no pad group), if not
required.
NCCLS Operational measurement no circuit class. Enter the OM class to indicate
which register is to be incremented when treatment GNCT, (General no
circuit class), occurs. GNCT occurs when all the available trunks in a route
are busy and no alternative is datafilled. Enter NCRT if none apply.
13
CUSTNAME Customer group name. Enter the name of the Customer Group to which the
trunk group belongs. Trunks forming part of the PSTN network often belong
to a dummy customer group which is established specifically to route
incoming calls directly to Universal translations. Private trunks to other sites
will probably belong to the Business customer group owning them and may
use centrex translations to handle the calls.
SUBGRPNO Subgroup number. This field specifies the attendant console subgroup to
which attendant calls should route. It is important not to confuse this
subgroup reference with trunk subgroup references specified later. Enter 0 if
none apply.
SELSEQ Selection sequence. This field specifies how free trunks will be selected for
use from within the trunk group. The terminating ends of each trunk group
should be datafilled with the opposite sequence to help avoid dual seizure
attempts.
The selection sequences are:-
ASEQ - Ascending sequence. Trunks will be selected in ascending order of
trunk member number as assigned in table TRKMEM.
DSEQ - Descending sequence. Trunks will be selected in descending order of
trunk member number as assigned in table TRKMEM.
LIDL - Least idle. Trunks will be selected on the basis of the least idle trunk
will be used next.
MIDL - Most idle. Trunks will be selected on the basis of the most idle trunk
will be used next.
An existing trunk group with ASEQ can be changed to DESQ and visa -
versa, so long as the trunk group members are all in the INB state. The
selection sequence may not be changed from ASEQ/DSEQ to MIDL/LIDL.
NCOS Network Class of Service. Enter the NCOS number assigned to the trunk
group. The NCOS value is used on IBNTI and the incoming call of an IBNT2
trunk. The NCOS may be used to determine the translation path to be
followed and can control routing options using the COSMAP system and
conditional routing.
BILLDN Billing directory number. If the trunk is seize only, enter the DN to
which the call will route. If the trunk receives incoming digits and a billing
record is required for calls that tandem through the switch, enter the DN to
which calls are to be billed. Enter N if none apply.
SUPV Supervision. Enter the type of call supervision required. Generally, this will
be ANSDISC, (answer disconnect). This value allows for notification of far
end answer and disconnect conditions.
DISCTSEL Disconnect timing selector. A value in the range 0 - 3 which determines the
period of disconnection required to cause the trunk to disconnect. The value
represents increments of 200 ms. 0 = 200ms.
INTRAGRP Intragroup. Enter Y, (yes), if the call is to be checked for intragroupness
otherwise enter N, (no).
14
DIGIT0 Digit 0. It is possible to prefix a digit onto the front of the incoming digit
string using this field. A maximum of two digits may be prefixed, the second
digit is assigned in the DIGIT1 field. Digits in the range 0-9, B or C may be
assigned.
NOTE: The default for this field is B which translates to * (star).
If no prefix digits are required you must enter N in this field.
DIGIT1 Digit 1. As for Digit 0 above but for the second prefix digit.
DTI Dial tone incoming. If second dial tone is sent to the incoming caller enter Y.
Generally, this field is set to N.
TES Toll essential service. Not used, enter N
CDR Call detail recording. If incoming calls are to be recorded using the SMDR
format enter Y.Generally, this field is set to N.
SMDR Station Message Detail Recording. (call logging). If call logging records are
required enter Y, otherwise enter N.
TRC Terminating restriction code. TRC codes work with the line feature DIN,
(Deny incoming). TRC codes assigned with the feature DIN allow calls from
the trunks with matching codes to terminate on the line. Calls from trunk
groups whose codes do not match will be denied.Avalue of 0 - 7 may be
entered here. Generally, this field is set to 0.
ALTNCOS Alternate NCOS. Enter an NCOS value that will be applied if the attendant
feature Attendant Control of Trunk Group Access is activated. Generally, this
field is set to 0.
TRKDSR Trunk distinctive ringing. Generally, this field is set to N.
LSCFN Line screening code flag number. This is a code number in the range 0 - 255.
This field is used in conjunction with the NCOS field LSC, (line screening
code). The two values are mapped together in table LSCFLAGS and may be
used to control access to trunks from lines or incoming trunks. Generally, this
field is set to 0.
ALTLSCFN Used in conjunction with the above.Generally, this field is set to 0.
LSCINCPT Line screening code flexible intercept. A value in the range 0 - 63 which is
an index into table IBNTREAT. Calls failing line screening will be routed to
this treatment table.
ALSCINCP Alternate Line screening code flexible intercept. A value in the range 0 63
which is an index into table IBNTREAT. Calls failing line screening will be
routed to this treatment table if the attendant feature Attendant Control of
Trunk Group Access is activated.
IGA Generally, this field is set to N.
FDN Generally, this field is set to N.
FDV Generally, this field is set to N.
FLASH Generally, this field is set to N.
DPX Generally, this field is set to N.
PREEMPT This field must be set to N.
15
AIOD Generally, this field is set to N.
REORIG Generally, this field is set to N.
OFFNET Generally, this field is set to N.
COFFTYP Class of Office Type. Enter NATL for National.
OPTION Options. Enter any options required. One example is the option NETXLA.
This is used to indicate that customer group information is to be sent in the
NETINFO parameter of an ISUP trunk group.
16
Table TRKSGRP Example (C7UP)
TABLE TRKSGRP
SGRPKEY CARDCODE SGRPVAR DIR ESUPR SAT ECSTAT NSMATCH
ukpvg 0 ds1sig c7up 2w n n internal n
AUTOON ABCNTL PROTOCOL CONTCHK COTREQ ADJNODE ACO OVLP
n none q767 thrl 0 dmsnode n y
VARIANT VERSION OPTION TMRNAME GLARETYP
Base 100_blue $ nil cic
17
This is an example of a TRKSGRP entry for voice trunks using CCS 7 User Part signalling.
Once again, the CLLI name forms the key into the table along with the subgroup number.
If the type of pulsing is Common Channel Signaling 7 (CCS7), datafill table TRKSGRP as
described in the following datafill table. This datafill also applies to DMS-300 CCITT No. 7
ISDN user part signaling (ISUP), the United Kingdom variant of national user part (BTUP),
telephone user part (TUP), and telephone user part plus (TUPPLUS or TUP+) trunk groups.
For the C7UP example the fields are:-
SGRPKEY Subgroup key. This field comprises the subfields CLLI and SUBGRP, the
CLLI name of the trunk group and the trunk subgroup number.
CARDCODE Enter the card type used to support the trunks. This may differ dependant on
the signalling system. CCS 7 uses DS1SIG.
SGRPVAR Variable subgroup data. This field consists of subfields as described
below. Enter TUP here to indicate the U.K. CCS 7 signalling variant.
DIR Direction. Enter the trunk group direction 2W,(two way), IC (incoming), or
OG (outgoing). The direction must be the same as defined in table TRKGRP.
ESUPR Echo suppression. Enter N to indicate that no echo suppressors are
installed.
SAT Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a
satellite. If not, enter N, (no).
17
ECSTAT Echo canceler status. Enter UNEQ to indicate that Echo canceler is not
equipped on this subgroup.
NSMATCH Noise match control. Enter N to indicate that background noise is not
maintained if internal echo canceler status is actively cancelling echoes.
The default is N.
AUTOON Auto re-enable control. Enter N to indicate that the echo canceler status is
not automatically turned on after the 2100-Hz tone control is removed. This
option is similar to the END OF CALL option for tone disablers in external
echo canceler status.
The default is Y.
ABCNTL A-bit control. Enter NONE if this field is not used by call processing control
software.
PROTOCOL Signalling protocol type. Enter the required signaling protocol and datafill
any applicable subfields. Signaling protocols BTUP, Q764, Q767, and
TUPPLUS are used by switching units in the United Kingdom.
When field PROTOCOL is datafilled Q767 (ETSI ISUP), datafill subfield
VERSION with BLUE, WHITE, MTX_BLUE, MTX_WHITE, AVENTEL,
GSM_BLUE, GSM_WHITE, 100_BLUE, 100_WHITE, or 100_EIV3.
CONTCHK Continuity check. Datafill this field to specify the type of continuity test to be
performed if such a test is requested. Enter one of the following values:
LOOPAROUND
THRH - transmit high and receive high
THRL - transmit high and receive low
TLRH - transmit low and receive high
2W2W - two-wire-two-way
COTREQ Continuity test required. The continuity check indicator is determined by
datafill in table TRKSGRP. Because continuity is not supported for AISUP
trunks, a value other than 0 (zero) is not allowed if datafilling field COTREQ
for AISUP trunks.
If the trunk direction is outgoing or two-way, enter the percentage of calls on
each trunk in this subgroup that requests a continuity test be performed
during call setup. If the trunk direction is incoming, leave this field blank.
ADJNODE Adjacent Node. Enter the 1 to 12-character name, previously datafilled as the
key in table ADJNODE. Table ADJNODE also contains the adjacent node
data used for this trunk subgroup. If the reference to table ADJNODE does
not apply, enter NIL.
ACO Answer charge. This field determines if an answer charge is applied on
BTUP to ISUP calls.
OVLP Overlap signaling. Enter Y if overlap signaling is permitted. Enter N if digits
are outpulsed en bloc, that is, outpulsing does not begin until all digits have
been received from the incoming trunk. The default is N.
VARIANT Variation. This field is used if the user part of ISUP is datafilled against the
trunk subgroup to identify the variation of ISUP. The default is BASE.
VERSION Version. See the PROTOCOL parameter.
18
OPTIONS Options. Enter up to 7 options. See NTPs for details. Otherwise enter $.
TMRNAME Timer name. Enter the timer name previously datafilled in table C7UPTMR,
which is the key to the tuple where the call processing and trunk maintenance
timers for the trunk group are found.
Enter NIL if the call processing and trunk maintenance datafillable timers are
hard coded.
GLARETYP Glaretype. If the entry in field DIR is 2W, datafill this subfield.
Enter CIC (circuit identification code) if glare is resolved using CICs. For
example, given two switching units connected with two-way trunks, if glare
occurs, the switching unit with the higher originating point code is granted
control of all the trunks with even-numbered CICs. This other switching
unit, with the lower originating point code, is granted control of all the
trunks with odd-numbered CICs.
19
Table TRKMEM (C7UP)
TABLE TRKMEM
CLLI EXTRKNM SGRP MEMVAR
UKPRI 1 0 GWC 1 8 300
UKPRI 2 0 GWC 1 8 301
UKPVG 1 0 GWC 1 8 332
UKPVG 2 0 GWC 1 8 333
20
The fields are:-
CLLI Common Language Location Identifier. Enter the CLLI name of the trunk
group to which these trunks are to become members.
EXTRKNM External trunk number. A number in the range 0 to 9999. Each trunk must
have a unique number and they usually run consecutively in ascending order.
Remember, the total number of members is restricted by the TRKGRSIZ
field in table CLLI.
SGRP Subgroup number. A value of 0 or 1 which represents the subgroup number,
built in table TRKSGRP, to which these trunks are assigned. Table
TRKSGRP defines the signalling parameters for the trunks.
PMTYPE Peripheral module type. Enter the type of peripheral module to which the
trunks connect.
GWCNO Gateway Controller Number
GWCNODENO Gateway Controller Node Number
GWCTRMNO Gateway Controller Terminal Number
20
21
SUMMARY
Trunks form the virtual connection between switches and a variety of signalling methods
can be used.There are four tables used to establish voice trunks, table CLLI, table TRKGRP,
table TRKSGRP and table TRKMEM.
Table CLLI.
CLLI names are used to identify a variety of resources on the DMS amongst which are
Tones, Announcements and Trunk groups.
Table TRKGRP
There are three types of IBN trunk in use, they are
IBNTI - Incoming only,
IBNTO - Outgoing only and
IBNT2 - Bothway.
Table TRKSGRP
a trunk group.
Table TRKMEM
Table TRKMEM defines and allocates the resource used by each individual trunk within the
trunk group.
22

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
23
Naming Conventions

Translation system.
Kingdom.
23
TRUNK GROUP EXERCISE.
The purpose of this exercise is to build trunk groups and to illustrate how switches would be
linked together.
In later exercises you will use TRAVER to test calls to and from trunks.
Depending on local requirements, the students will datafill C7UP trunks, PRI trunks or a
combination. PRI Trunk datafill is included in an appendix.
Your instructor will advise.
C7UP Trunks Exercise

Datafill Two C7UP trunk groups.
Each trunk group will have one trunk member.
A suggested trunk group room plan appropriate to your class is included for reference
overleaf, however your instructor may allocate the connections differently.
Obtain the following information from your instructor:-

Destination Customer Group A name__________________________
Destination Customer Group B name__________________________
Destination A - GWCNO _____ GWCNODENO_____ GWCTRMNO____________

Destination B - GWCNO _____ GWCNODENO_____ GWCTRMNO____________
Use the example datafill shown earlier for C7UP for common values using the following
settings and naming convention;
Trunk group size = 2
Signalling system = DS1SIG
SGRPVAR = C7UP
Customer Group = Your Customer Group Name.
Direction = Twoway
Trunk Group Type = IBNT2
NCOS 0
CLLI name is to follow the following naming convention;
[Region ] [Team number] [Signalling Type] [Identifying text]
Where Region EM for EMEA, CA for CALA, NA for North America or AP for AsiaPac
Team Number 1 to 8
Signalling Type C7
Identifying text TRK for Trunk, A for 1st circuit, B for second circuit.
Examples;
EM3C7TRKA and EM3C7TRKB
Refer to the NTP and the examples on earlier pages for information on datafill.
24
25
Trunk Group Exercise Room plan
GWC No__1__ GWC No__1__

GWC Node__8__ GWC Node_8___
GWC TermNo_631__ GWC TermNo__641__
Team 3 Team 4

GWC TermNo__630__ GWC TermNo_640___

GWC TermNo_621___ GWC TermNo_651___
Team 2 Team 5
GWC No_1___ GWC No_1___

GWC Node__8__ GWC Node__8__
GWC No_1___ GWC No__1__

Team 1 Team 6

26
27
Module 6
Route Tables
nortel.com/training
0
1
Module 6 Route Tables
Purpose
concepts of;
> Route Table datafill procedures

List the Route Tables
Describe the format of a Route Table
Explain the term ARS
Define the route element selectors and their purposes
Datafill route lists
2
2
3
CUSTENG Universals
CUSTHEAD
IBNXLA
NCOS
IBNTREAT
IBNRTE
CLLI OFRT
TRKGRP OVRx
TRKSGRP Routing
TRKMEM
Trunks
4
4
5
Introduction to Routing Tables
Centrex Universal
Translations Translations
IBRTx ORTx OVRx

Tables Tables Tables
Directory Trunk
Number Treatment Group/s
6
Introduction to Routing Tables

This module describes the routing tables. The routing tables are used to determine the final
destination of a call once the digits have been analysed and translated.
Historically, the legacy DMS switch had two routing tables originally IBNRTE and
OFRT. Each comprised of 1024 tuples.
IBNRTE was primarily for destinations within the switch, OFRT for destinations off of the
switch.
Due to demand each of these was quadrupled to give a total of 8192 routing table entries on
a switch.
This has been further expanded by the additional of the OVRx tables to now allow up to
100352 Routing Table entries per switch.
Routing Tables
IBNRTx (IBN Routing Tables)
The IBNRTE, IBNRT2, IBNRT3 and IBNRT4 Route tables are designed for use in the
Centrex environment and have fields and choice of selectors that are unique to Centrex
working.
OFRx (Office Routing Tables)
The OFRT, OFR2, OFR3 and OFR4 Route tables have a more simple field choice and
cannot be used if specific Centrex features are required.
OVRx (Overseas Routing Tables)
The OVR0 to OVR89 Route Tables are similar to OFRT tables.
6
Route Lists
Each tuple in a Routeing Table is known as a ROUTE LIST. The index into a ROUTE
LIST is via the table name and a ROUTE LIST number from 0 to 1023. A ROUTE LIST
may comprise of up to 8 elements (route elements) of choice. If the first choice in a
ROUTE LIST is unavailable, the call advances to the next choice in the list. The process
of advancement is known as ARS, Automatic Route Selection. ROUTE LISTS may be
chained together such that if all the choices in one ROUTE LIST are unavailable, the
call may pass onto another ROUTE LIST.
Calls originating from LINES or INCOMING TRUNKS will usually terminate on a
ROUTE LIST. Generally, calls will either terminate to an OUTGOING TRUNK or a
DIRECTORY NUMBER on the switch. Other results may be appropriate, e.g. an
announcement or tone and these can be pointed to in a ROUTE LIST. In the Universal
Translations environment, route lists may be pointed to from the XLASYS HEAD,
CODE or RTE tables. Route lists may also be pointed to directly from the Centrex
Translations tables IBNXLA, XLANAME and IBNTREAT.
An example of a Route List is given below.
TABLE: OFRT
RTE RTELIST
60 (S D NTMDHDDLOG) (S D NTMH4B2WNAT) (S D NTMH4B2WLOC)(ST 70) $
70 (S D NTSLGHDLOG) (S D ANSILP1) (S D BUSY) $
This example shows two route list entries in table OFRT.

Route list 60 points calls to the trunk group CLLI name NTMDHDDLOG as the first
choice in this ROUTE LIST and then staying in the same Route Table, on to Route List
70 as the fourth choice.
Route List 70 points calls to a trunk group CLLI name of NTSLGHDLOG as the first
choice and to the tone BUSY as the last choice.
The Route List elements use Route Selectors to point to the trunk CLLIs, route link and
tone.
The Route selectors are discussed next.
7
Route Element Selectors
A number of Route Selectors are available within the Route tables. The selector is used to
determine the action taken by a particular Route Element within a Route List. There are
many selectors that are common across both the IBNRTE and OFRT (+OVR) tables
however there are some selectors that are only available in specific Route Tables. For
example, the VFG Selector is only available from the IBNRTE Table as it is used for a
Centrex feature.
It is also important to note that the datafill may be different depending on which of the
tables being used.
Route Element Selector Descriptions

There are many selectors available and they are all detailed in NTP Succession Networks
Operational Configuration: Data Schema Reference NN10324-509.01.02.
This module will concentrate on the selectors commonly used in the European market.
Route Selector S Points to a CLLI name. This may be the name of a trunk
group, announcement or tone. This selector is used when the
digits dialled are the digits outpulsed.
Route Selector T Points to another route list. The route list may be in the same
Route table or a list in another Route table. The T selector is
used when linking Route lists together. If you stay in the same
Route table, the list pointed to must have a higher Route list
number.
Route Selector ST Points to another index within the same route Table. The
index pointed to must be a higher number.
Route Selector DN Resolves a call to a Directory Number on the same switch.
Route Selector N Points to a CLLI name in the same way as an S selector. The
N selector additionally allows for digit modification of the
outpulsed digits. The modification occurs after translation and
does not affect the translation registers. The use of this
selector in the IBNRTE tables will point to an index into the
digit modification table DIGMAN. In the OFRT tables, digit
modification occurs within the fields of the table itself.
Route Selector CND The conditional selector, CND, is used when a call is to
proceed only if a certain condition is met. If the condition is
not met, the call is routed as specified in the next element of
the route list. The common conditions are:-
TOD, Time of Day, where routing choices can be altered
dependant upon the time, the day and special days of the year.
RND, Random, where traffic can be split across routes on a
random percentage basis.
COSMAP, where calls can route dependant on their Class of
Service.
NRR, Network blocking Re-Route, where calls can route if a
network busy condition is encountered from the next switch
onwards.
8
Route Selector VFG Points to a Virtual Facility Group from an IBNRTE table.
VFGs are (IBNRTE only) software trunks and are used to
limit access to real trunks as well as allowing the
assignment of different Customer Group attributes and billing
numbers.
Route Selector TRMT Points to a specified Office Treatment.
Route Selector INS Allows new route elements to be inserted into existing route
lists at any route element position.
Route Selector NIL This selector allows deletion of elements from the route list at
any route element position.
Route Selector MEM Allows the selection of one or a number of trunks from the
trunk group. (Not IBNRTE) E.g. for testing purposes.
Route Selector SG This selector in conjunction with Table SUPERTKG joins up
to 220 ISDN primary rate interface (PRI) trunk groups
(defined in table TRKGRP) together into super-groups.
The following examples show typical table entries for some of the route selector options
described.
The S & N selectors are shown using both IBNRTE and OFRT (+OVR) tables to give a
comparison of the differences in the fields when using these different routing tables.
9
Route Table Datafill Example
IBNRTx S selector
Table IBNRTE
RTE IBNRTSEL OHQ CBQ EXP MBG CLLI
11 s n n n n ntmdhddlog
IBNRTSEL OHQ CBQ EXP MBG CLLI
s n n n n ntslghdlog
s n n n n busy
10
This example shows a route list of 3 elements. The first 2 elements point to trunk groups
and the final element points to the tone busy. The fields are:-
RTE The Route list number in the range 0 to 1023. This field is entered for the
first instance of the route list.
IBNRTSEL The route element selector. S in this example.
OHQ Off hook queuing. Set to Y if Off hook queuing is allowed for this route
element, otherwise enter N.
CBQ Call Back Queuing. Set to Y if Call back queuing is allowed for this route
element, otherwise enter N.
EXP Expensive Route Warning Tone. Set to Y if this element is an expensive
route and warning tone is required.
MBG Multi Switch Business Group. Enter N
CLLI Common Language Location Identifier. Enter the CLLI name to which the
translation is routed.
As can be seen above, the S Selector when used in the IBNRTE Table has Centrex Feature
fields to enable Centrex features. The fields need not be used so, as in the example a datafill
of N can be used.
To illustrate the different field choices if the same S selector is used from the OFRT
Table, the datafill is shown on the next page.
10
OFRTx S selector
TABLE: OFRT
RTE RTESEL CONNTYPE CLLI
20 s d ntmdhddlog
RTESEL CONNTYPE CLLI
s d ntslghdlog
RTESEL CONNTYPE CLLI
s d busy
11
In this example, the S selector is used to point calls to a choice of two trunk group CLLIs
with a final choice of BUSY. Note that the IBNRTE features OHQ, CBQ, EXP and MBG
are not available in the OFRT table.
The fields are:-
RTESEL Route Selector. The route element selector. S in this example.
CONNTYPE Connection type. The field is not used by the software, enter D to satisfy
table editor.
RTESEL Route Selector. The route element selector. S in this example.
CONNTYPE Connection type. The field is not used by the software, enter D to satisfy
table editor.
The datafill is simplified by using the S selector in the OFRT routing table.
The following example, use of the N selector in both IBNRTE and OFRT routing tables,
shows that the selector operates in a different way with different fields.
11
IBNRTx N selector
TABLE IBNRTE
RTE IBNRTSEL OHQ CBQ EXP MBG CLLI DMI
12 n n n n n ntmdhddlog 0
IBNRTSEL
$
12
In this example, route list 12 is used to point calls to the trunk group CLLI ntmdhddlog. The
difference between using the N selector and S selector is that you may use digit
modification to modify the digits sent out on the trunk group. The DMI field is set to 0
indicating that no modification is required.
The fields are:-
RTE The Route list number in the range 0 to 1023.
IBNRTSEL The route element selector. N in this example.
OHQ Off hook queuing. As seen before for IBNRTx.
CBQ Call Back Queuing. As seen before for IBNRTx.
EXP Expensive Route Warning Tone. As seen before for IBNRTx.
MBG Multi Switch Business Group. As seen before for IBNRTx.
DMI Digit Manipulation Index. 0 means no index, any number between 1-32767
will index Table Digman.
Again the Centrex Features fields are present, however an extra field is added.
This extra field, the DMI field is an index into table DIGMAN where digit manipulation
may be performed on the dialled digits. Table DIGMAN is designed for use in Centrex
applications, so it was designd to be accessed from different tables by the use of an index
(DMI).
Compare this with the following OFRT routing table datafill
12
OFRx N selector
RTE RTESEL CONNTYPE CLLI DELDIGS PRFXDIGS CANCNORC

23 n d ntslghdlog 0 162 y
13
In this example, the N selector is used to point calls to a trunk group CLLI. The N selector
gives the additional ability to manipulate the outpulsed digits. The manipulation occurs
within the fields of the tuple as table OFRT cannot be used to index table DIGMAN. A
further field allows for the cancellation of normal call charges. A common application for
this is where termination of test calls to an announcement requires an answer condition and
billing.
The fields are:-
RTE The Route list number in the range 0 to 1023.
RTESEL Route Selector. The route element selector. N in this example.
CONNTYPE Connection type. As seen before for OFRx.
CLLI Common Language Location Identifier. As seen before for OFRx.
DELDIGS Delete Digits. Enter the number of digits to be deleted from the digit string
prior to outpulsing. A maximum of 15 digits may be deleted. Enter 0 if no
digits are to be deleted.
PRFXDIGS Prefix Digits. Enter the digits to be prefixed prior to outpulsing. A maximum
of 11 digits may be specified. The specified digits will be prefixed to the
front of the digit string once any deletion has occurred.
N.B. Enter N if no digits are to be prefixed.
CANCNORC Cancel Normal Charge. This field may be set to Y, (yes) or N, (no). Calls
may have their normal charge cancelled using this field. Calls routing to an
announcement ( these are not normally charged ) that require a charge to be
raised will have this field set to Y. In general, when this field is set to Y, a
non revenue call is assumed. If the field is set to N, a revenue call is assumed
unless non revenue is indicated elsewhere.
13
IBNRTx T selector
Table IBNRTE
RTE IBNRTSEL OHQ CBQ EXP MBG CLLI
10 s n n n n ntmdhddlog
IBNRTSEL EXTRTEID
t ovr55 11
IBNRTESEL
$
21 IBNRTSEL OHQ CBQ EXP MBG CLLI

s n n n n ntrdgdlog
IBNRTSEL RTEREF
st 22
14
In this example, route list 10 uses the T selector to point on to another route list after the
first two choices have been tried. The new route list is route 11 in table IBNRTE. The T
selector is often used as the last element in a route list. Used in this way, route lists can be
linked together to provide more choice.
The T selector may be used in other tables to point to an IBNRTE or OFRT tables.
The fields are:-
IBNRTSEL The route element selector. T in this example.
EXTRTEID External Route I.D. The Route table, e.g. OFRT, and index number to which
the call will be routed.
Note; If staying in the same table, the ST Selector is easier to use.
The ST selector is limited to pointing to a higher index in the current Routing Table.
The ST selector is available in OFRx and OVRx also.
In the example above calls routed to IBNRTE index 10 will search through CLLIs
NTMDHDDLOG then NTSLGHDLOG before going to OVR55 index 11 to continue.
IBNRTE index 21searches CLLI NTRDGDLOG then goes to IBNRTE index 22.
14
IBNRTx DN selector
TABLE: IBNRTE
RTE IBNRTSEL SNPA NXX EXP DMI STNLEN
211 dn 162 870 n 0 4
IBNRTSEL
$
15
In this example, route list 211 is used to resolve a call to a DN on the switch. Calls pointed
to this route would be either locally dialled own switch calls or incoming PSTN calls.
The call will terminate to a number in the 162 870 xxxx range. Digits can be modified in
table DIGMAN.
The fields are:-
IBNRTSEL The route element selector. DN in this example.
SNPA Serving Number Plan Area also known as the Area Code. The first three
digits of the full 10 digit number.
NXX The Office Code digits. The next three digits in the number.
EXP Expensive Route Warning Tone. Set to Y if this element is an expensive
route and warning tone is required.
DMI Digit Manipulation Index. An index into table DIGMAN where digit
manipulation may be performed on the dialled digits. Table DIGMAN uses
index numbers in the range 1 to 32767. In this example, the DMI index
number is 0 to indicate that no digit manipulation is required. In this case, the
last four digits of the dialled number are passed on transparently.
STNLEN Station length (1 to 8 digits). Used to identify the station code length of the
terminating agent.
15
IBNRTx & OFRx TRMT selector
TABLE IBNRTE or OFRT

RTE RTESEL RTETRMT
212 trmt gnct
16
In this example, route list 212 is used to point calls to a treatment. The treatment name must
be one datafilled in table TMTCNTL (Treatment Control).
The fields are:-
IBNRTSEL The route element selector. TRMT in this example.
RTETRMT Route Treatment. A treatment name from table TMTCNTL.
16
IBNRTx CND - TOD selector
TABLE IBNRTE
RTE IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUM
211 cnd tod demotod 1 sk 1
s n n n n ntmdhddlog
IBNRTSEL EXTRTEID
t ibnrte 300
17
In this example, the conditional selector TOD, (time of day), is used. If the condition is met,
calls will skip 1 route element, i.e. trunk group ntmdhddlog, and pass on to the next. If the
condition does not apply, normal ARS occurs and the conditional element is ignored. The
Time of Day parameters are set in the Time of Day system tables using Time of Day system
name DEMOTOD. The final element in this list will route calls to IBNRTE 300 if there are
no available trunks in the specified trunk groups.
Time Of Day routing tables will be covered in a later module.
17
IBNRTx CND - COSMAP selector
TABLE IBNRTE
RTE IBNRTSEL CNDSEL COSMAP RTETYPE RTEREF
212 cnd cosmap netcos st 300
s n n n n busy
18
In this example, the conditional selector COSMAP (nCOS MAPping) is used to route calls
to IBNRTE 300 if the ncos of the call passes ncos screening. The screening parameters are
established in the COSMAP table entry for COSMAP NETCOS. If the condition is not met,
i.e. the call fails ncos screening, normal ARS occurs and the conditional element is ignored.
The COSMAP tables are covered in course 5314, Centrex Translations.
18
IBNRTx CND - RND selector
TABLE IBNRTE
RTE IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEID
211 cnd rnd 50 t ibnrte 600
IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEID
cnd rnd 50 t ibnrte 601
IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEID
cnd rnd 50 t ibnrte 602
IBNRTSEL EXTRTEID
t ibnrte 604
19
In this example, the conditional selector RND (random), is used.

Of the traffic passed to IBNRTE index 211, 50% will be passed to IBNRTE 600.
Of the remaining traffic, 50% will be passed to IBNRTE 601.
Again, of the remaining traffic, 50% will be passed to IBNRTE 602.
The remaining traffic is sent to IBNRTE index 604.
The percentages are over time, therefore as an example if IBNRTE index 211 received 1000
calls over a period of time, they would be approximately distributed as follows;
IBNRTE 600 500 calls
IBNRTE 604 125 calls.
As an alternative, for all the remaining calls are to be sent to IBNRTE 604 the above T
selector could have been datafilled as follows;
IBNRTSEL CNDSEL PERCENT RTETYPE INDEX
cnd rnd always st 604
In this instance Always send 100% of the remaining traffic to IBNRTE 604.
19
INS Selector
To use this selector, pos on the route list in which you wish to insert a route element e.g.
to add a new CLLI as the second choice in the route list below;
999 (S D NTMH4B2WEMG) (S D NTMH4B2WLOC) (TRMT BUSY) $ $
Tab to where you want the new route element e.g .(S D NTMH4B2WLOC)
Type INS over the existing route selector at the point you want to add this new route
selector ;
Step through the list until you reach the end of the route list, enter $ and return, you will see
this;
999 (S D NTMH4B2WEMG) (INS) (TRMT BUSY) $ $
( dont worry, although it looks like (S D NTMH4B2WLOC) has been deleted, it will still
be there )
Upon trying to confirm to the switch it will give you the following message and show the
following Tuple;
Change INS to desired route

INCONSISTENT DATA
TUPLE TO BE CHANGED:
999 (S D NTMH4B2WEMG) (INS) (S D NTMH4B2WLOC) (TRMT BUSY) $ $
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
Enter E (edit) and step through data until the INS selector is reached,
Replace INS with your new route element data, (e.g. S D TRKTOBHMNWM)
continue through the data to the end and return to see the message below,
TUPLE TO BE CHANGED:
999 (S D NTMH4B2WEMG) (S D TRKTOBHMNWM) (S D NTMH4B2WLOC)
(TRMT BUSY) $ $
Confirm to switch and CLLI TRKTOBHMNWM will have been added.
20
21
ROUTE TABLE EXERCISE A.
The purpose of this exercise is to:-

Datafill two route lists using table OFRT. Each route is to comprise of two
route elements pointing to the trunks to your partner groups.
Datafill an IBNRTE using the DN selector to terminate own exchange calls
on to your lines.
Datafill an OFR2 for other destinations Other National calls, Operator
calls and Emergency calls.
Datafill an OVR30 to point European calls to an announcement CLLI.
Datafill a further OVR50 to point all other International calls to an
announcement CLLI.
These routes will be used for later translations exercises.
OFRT number_________Destination Group_A__________________
OFRT number_________Destination Group_B__________________
IBNRTE number ______Own exchange calls.
OFR2 number ______ Other National Calls ( CLLI DANNAT )

______ Operator calls ( CLLI DAN100 )
______ Emergency calls ( CLLI DAN999 )
OVR30 number______ European calls use CLLI DANEURO
OVR50 number______ Other International destinations use CLLI DANNONEURO
22
23
ROUTE TABLE EXERCISE B.

Add an extra route element to your existing route lists.
Use each route for a later translation exercise.
A) Add a third element to your 1st route list which will link the 1st and 2nd route lists
together in the event that all trunks in the 1st route are busy.
B) Add a third element to your 2nd route list which will send calls to the treatment BUSY in
the event all trunks are busy.
24
25
Module 7
Universal Translations Overview
nortel.com/training
0
1
Module 7 Universal Translations
Overview
Purpose
concepts of;
> Universal Translations tables and their options.
Name the Universal Translation Systems and their associated tables
Describe the purpose of the translation registers
Detail the translation selector options
Explain the function of the translation tables
Explain the function of Table Lineattr
Demonstrate the TRANSVER tool
2
2
3
Centrex
Customer
Group Universal
Tables Translations
Tables
Routing
Tables
Trunk
Group
Tables
Call Control
Tables
4
4
5
5
Centrex
CUSTENG Universals FAHEAD

OFCHEAD
CTHEAD
CUSTHEAD PXHEAD FACODE
IBNXLA OFCCODE
NCOS CTCODE
PXCODE FARTE
OFCRTE
IBNTREAT CTRTE
PXRTE
IBNRTE
CLLI OFRT
TRKGRP OVRx
TRKSGRP Routing
TRKMEM
Trunks
6
6
7
Overview BILLING
Centrex
Universal
Customer
Translations
Group NET DOD LINEATTR
To
Announcements
Other
Customer
Groups
To Trunks to
other switches
8
Universal Translation Tables Functional Overview

CS2000 uses the universal translation tables to translate the received digit string after
receiving the digits from Table LINEATTR.
The entry point into the universal translation tables where the translation of the incoming
digits is to begin is defined as XLASYS, the translation system, and XLANAME, the
translation name. When a call is originated by a line or incoming trunk, the line attribute
index applicable to the originator are used to determine the point where translation of the
received dialled digits is to begin. Table LINEATTR will point to the appropriate XLASYS
(translation system) and XLANAME (translator name). Typically this will be a PXHEAD
table entry.
The results of the digit translation in the universal translation tables are as follows:
a - Route the call to one of the following:
- Terminate on a line
- Outgoing trunk group
- Another network
- Fail to route the call and determine the applicable treatment code
which will result in the prescribed combination of announcement (s)
and/or tone (s) being returned to the originator.
- Recognise that the digits dialled are a specific function code of a
specific feature and react accordingly.
b - Modify or replace the received digital string before out pulsing and/or call
data recording.
c - Determine the parameters required for screening and charging.
8
Universal Translations Numbering
Plans
Example Dialled Digits 900441628795000
The above number can be generalised into the following

areas;
Access Code - 9
+ Prefix Code - 00
+ Country Code - 44
+ Area Code - 162
+ Office Code - 879
+ Station Number - 5000
9
Requirements for Universal Translations

The general function of translations is to route a call based on the digits dialled, and by
whom. The first task is therefore to look at what digits can be dialled.
The Access code is for access to another network, an attendant, or a feature. If a feature
access code is dialled, the digits following may not correspond to the numbering plan. The
access code of a network is usually only required when dialling into a network.
For example, the typical business user in the United Kingdom dials an access code of 9
when dialling into the PSTN network from a line, whilst business users in Europe dial an
access code of 0.
Prefix Codes give information about the type of call being dialled.
In the PSTN network, there is a prefix for STD, IDD, operator handled national calls, and
operator handled international calls.
The default is not to dial the prefix, which would indicate a local call.
Country Codes are internationally agreed upon, 2 or 3 digit numbers. Each country also has
a pseudo country code, which is used for operator handled traffic. All country codes are
carefully chosen to be completely unambiguous with each other. The country code may be
omitted when dialling a destination inside the same country (and sometimes when the
destination is an adjacent country).
9
An Area Code is assigned to an area of the country.
The areas are usually the results of a fairly arbitrary break-up of the country, done for
administration purposes, and to impose a hierarchical structure on the network.
In the North American plan, the area codes are distinguishable from the Office codes, but
this is the exception, rather than the rule. Usually if the destination is within the same area,
the area code is not dialled (if it is dialled, it may be ignored or blocked).
An Office Code is an exchange within the area.

The office code may not be dialled if the terminating station is within the same exchange, or
at the same destination.
A Station number usually identifies the particular station on which to terminate. However,
there are many exceptions such as features:
- Hunt groups
- ACD and UCD groups
- Meet me Conference
10
Universal Translation Digit Registers
Outpulse Register May change
Translation Register Will probably change
Billing Register May change - Careful !
11
Universal Translation Digit Registers.

The universal translation system uses three digit registers to store the digits dialled. The
three are known as the OUTPULSE, TRANSLATION, and BILLING registers. Initially,
dialled digits are stored in each of the registers , however, the contents of the registers may
change as the call progresses through the translation process.
Outpulse Register
The outpulse register stores the digits that will be outpulsed to a final destination , typically
a route, once the translation scheme has determined that destination. The contents may
change as the call progresses.
Translation Register
The translation register stores the digits that will be used during the translation process. The
contents of this register may change as the call progresses through the different XLASYS.
Billing Register
The billing register stores the digits that will be used for the call detail record. The contents
may change as the call progresses, however, caution must be exercised as the digits in this
register will be the digits used in the billing record.
Digit Manipulation
Digit manipulation options are discussed in a following section. It is important to
understand that the digit registers can be changed by using the digit manipulation options.
11
Universal Translation Systems &
Tables
AC PX CT FA OFC FT NSC AM
HEAD HEAD HEAD HEAD HEAD HEAD HEAD HEAD
CODE CODE CODE CODE CODE CODE CODE CODE

Am
RTE RTE bi
RTE RTE RTE RTE RTE gu
ou
Pr Co Fo Ut Nu s
e O m co
Ac
fix un re ffi ilit be de

ig ce y
ce
Co try n Co r
Co
ss
de Co Ar de Se
ea de
C
de rv
od
Co ice
e
de Co
de
12
Universal Translation Systems

Universal translations consist of a set of 8 translation systems.
Access code (XLASYS AC)
The access code is for access to another network, an attendant, or a feature. If a feature
access code is dialed, the digits following do not correspond to the numbering plan. The
access code of a network is usually required only when dialing into another network. For
example, the user must dial an access code of 9 to access the local operating telephone
company network from a private tie line network.
Prefix code (XLASYS PX)
The prefix code gives information about the local operating telephone company type of call
being dialed. For example, in North America there usually are prefix codes for domestic
direct distance dialing (DDD), international DDD, domestic operator-handled calls, and
international operator-handled calls. The default is usually not to dial the prefix code for a
local call.
Country code (XLASYS CT)
Country codes are internationally agreed upon one-, two-, or three-digit numbers, beginning
with the zone digit. Each country also has a pseudo country code, which is used for
operator- handled traffic. All country codes are uniquely defined. The country code can be
omitted if dialing a destination inside the same country (and sometimes if the destination is
in an adjacent country).
12
Foreign area code (XLASYS FA)
An area code is assigned to an area of the country. In North America, area codes are
distinguishable from office codes so that if the called number is within the same area as the
calling number, the area code is not dialed. If it is dialed, it is ignored or blocked.
Office code (XLASYS OFC)
An office code is an exchange within the area.
Utility Code (XLASYS FT)
The utility code is called from office parameters and is used to perform operations such as
validation of an announcement or a call diversion destination.
Number service code (XLASYS NSC)
A number service code is for service switching point (SSP) applications that require access
to a database.
Ambiguous code (XLASYS AM)
The ambiguous code universal translations tables are invoked when the total number of
digits received in addition to the leading digits received determine which terminating route
applies.
Universal translation of a digit segment

To translate each of the digit string segments, there are three universal translations tables
(with the exception of the AM translation system, which only has a HEAD and CODE):
(XLASYS)HEAD table
(XLASYS)CODE table
(XLASYS)RTE table
For example, the universal translations tables used to translate the prefix code digits
segment, translation system XLASYS PX, are PXHEAD, PXCODE, and PXRTE.
In the universal translation tables described in this section
each (XLASYS)HEAD table has identical syntax with other (XLASYS)HEAD tables
each (XLASYS)CODE table has identical syntax with other (XLASYS)CODE tables
each (XLASYS)RTE table has identical syntax with other (XLASYS)RTE tables
The head tables define the names, and other characteristics, of the instances of each code
table. The code tables all share a common set of data selectors and options. The HEAD and
CODE tables work together but there will only be a ROUTE table used if the translations
can point to a destination.
The reason for a set of head tables, as opposed to one very large head table, is to preserve
the semantic differences between the various digit segments. For example, the Access Code
table may well be required to handle the * and # digits, whereas none of the other code
tables would be expected to handle them. The various head tables also clarify the default
order.
13
Universal Translation Head Tables
Table xxHEAD
DFLT - Default DFOP - Default CON MAXIDX

action if digits options to apply Consume the 9 or STD
XLANAME when digits are digits used to
are not in the
Code table matched in the index the
Code table Code table
14
Universal Translation Head Tables

Head Tables and Their Options
As mentioned previously, there is a head table for each code table type (i.e.
PXHEAD,FAHEAD, OFCHEAD, etc.). These head tables define the instances of code and
route tables, and their characteristics. The translator name ( XLANAME ) is the link
between a specific HEAD table and its CODE and ROUTE table. As with the CODE tables,
all HEAD tables have identical format for the options that they contain. The tables that are
indexed with digits will contain all the options listed below.
A tuple in a head table will consist of the name of the code and route table instance i.e.
XLANAME, and some or all of the following options: The tables that are indexed with
digits will contain all the options listed below.
DFLT<a code table tuple>
DFOP<code table options>
CON
MAXIDX<hex digit>
A description of each option follows:
14
DFLT - Default
This is the result that translations will use if the dialled digits are not datafilled in the code
table associated with this head table. Any valid code table tuples can be specified with this
option.
DFOP - Default Options
In the case of the dialled digits resolving into a RTE or CONT selector, any options not
datafilled against the digits may be defaulted to the value specified here. This facility, and
the DFLT OPTION, are intended to minimise the amount of datafill required in a given
code table, especially if most of the expected codes have the same attributes. If an option is
applicable to most, but not all, tuples in the code table instance, the option may still be
datafilled in the default options.
NOTE Options datafilled in the CODE table tuples override the options in the HEAD
table, so a different value can be filled into those few code tuples to which the default
option does not apply.
CON - Consume Digits.

This option acts with the CONT selector of the CODE table. The default case is not to
consume digits (i.e. the next table is indexed using the same digits as the current table,
(ignoring prefix digits). However, under certain conditions, we wish to index the next table
starting with the digits following the digits used to index the current table (i.e. translations
should absorb or CONsume the current index digits). An example of this is when an IDD
prefix code is found in PXCODE. The CTCODE table should be indexed with the digits
following the IDD code (the country code), so the digits used to index the PXCODE table
should be consumed.
NOTE This does not mean that the digits are deleted from all the digit registers. They are
still there, and will be outpulsed unless explicitly deleted in the code or route tables.
The CON option only means that they will not be used to index the next table. The CON
option will only delete digits from the Translation register.
MAXIDX - Maximum Index.

The translation tables are indexed by dialled digits. The MAXIDX field stipulates the
allowed digit ranges in the code table. The default case is that these digits fall in the range
of 0 to 9. The MAXIDX field stipulates the allowed digit ranges in the code table. In the
U.K. dialling scheme this field is set to a value of 9 or STD ( both do the same thing ),
which means that digits in the range 0 to 9 are valid.
Other values that may be used (but they do not apply in the U.K) are;
C Digits 0-9, Hexidecimal value B (*), Hexidecimal value C (#)
F Digits 0-9, Hexidecimal value B (*), Hexidecimal value C (#),
Hexidecimal values D, E & F
15
Universal Translation Code Tables
Table xxCODE
XLANAME FROMD TOD XLADATA
Digit range to be matched Instructions to follow

if dialled digits fall
within the FROMD
and TOD range
16
The Code Tables consist of four fields, as shown above.

The XLANAME is the link to the corresponding Head Table entry, and Route Table entries.
FROMD
The digit string of the first number range being screened ( 1 to 11 digits )
TOD
The digit string of the last number in the range being screened. (1 to 11 digits )
XLADATA
This field comprises of subfields XLASEL (Translation Selector) and OSEL (Option
Selector).
For this course, only the common Translation Selectors and Option Selectors will be
covered.
For XLASEL these are; For OSEL these are;
CONT XLT
RTE DEST
TRMT MM
DMOD CLASS
FEATINFO CONSUME
CALLCTRL
AMAXLAID
16
Universal Translation Tables Routing Options
In this section we will consider the choices available to us as DFLT actions in the HEAD
table and XLADATA actions in the CODE table. You will see that they are the same !
TRANSLATION SELECTOR XLASEL

Table (XLASYS) CODE field XLADATA and table (XLASYS) HEAD field DFLT are
identical in format and are composed of a translation selector and translation selector
dependent groups of options for routing, digit manipulation, screening and charging as
described below:
TRMT - An exception of failure condition
-The treatment to be applied may be global to the whole switch (an
office treatment), or based on the originators COS (flexible
treatment).
CONT - Continue translation
-The next XLASYS and XLANAME to be traversed by the
translation.
RTE - A destination name has been found, and translation is to be
terminated.
-Further digit collection may be required, based on min. digits and
max. digits in the translation block.
DMOD - Digit modification required.
-Some or all of the dialled digits may be replaced, or digits may be
inserted.
Each selector will have an associated set of options that may be datafilled. Based on studies
conducted so far, the following options should be available:
TRMT - route to treatment
A treatment is a known exception or failure condition. The action taken is to terminate
translation, returning an indication that a treatment has been encountered and decoded into a
route.
OFC - Office treatment. These are a fixed set of pre-defined treatments that are basically
standard across the office. The set includes Partial Dial, Vacant Code, etc.
CONT - Continue translating
This selector is used when further translation is required. The next table to scan will be
given by the XLT option. An option (CON. NOCON) in the head table entry for the current
XLANAME will determine whether the digits that were used to index the current table
should be consumed (i.e. ignored by the next table). For example, in a translator, the digits
are not usually consumed, but they would be when continuing from the Prefix ( PX ) Code
table to the Country Code ( CT ) table in the case of an International call.
The XLT option allows the user to specify the next translation system to use. The PXCODE
entry for the IDD prefix would indicate that the country code translation system should be
invoked next. A further option allows the XLANAME of the next translation system to be
specified. e.g. CONT XLT CT COUNTRY
17
All of the other options available with the CONT selector are identical to those in the RTE
selector and are described under the RTE heading. This allows information to be associated
with a given digit stream, while continuing translation for other purposes (validation,
screening, metering, etc.).
RTE - a destination result has been found
A translation result has been found (maybe in a previous table), and translation is to be
terminated. A new digit collection algorithm and/or further digit collection may be required,
but no further translation is required. For overlapped out pulsing, the outgoing trunk may
not be selected, and out pulsing started.
The following options are available:
PF - Prefix Fence. This is the number of prefix digits associated with this tuple (i.e. If some
prefix digits had been identified in a previous table, then the number here will be added to
the existing value). Prefix digits are not stored in translation tables.
MM - The Minimum and Maximum total number of digits expected. These values include
the digits used to index the current tuple, but do not include the prefix digits specified in the
current tuple.
DEST - Destination Number. This number is mapped into a Route List index, or may be put
through a more complex mapping for Time of Day routing etc.
CLASS - The class of the dialled digits, in terms of emergency, national, international.
This is used to trigger AMA billing records.
AMAXLAID - Used to specify an AMA identity from table AMAXLAID. This must be
used with CLASS EMERG, ( emergency ), to trigger a billing record for emergency calls.
Entries in table AMAXLAID can be used to override any previously defined CLASS type in
the HEAD and CODE tables.
CALLCTRL - Call Control. This option is used to specify which party controls the call.
Three options are available, Called, Calling, or Both. The option is used with emergency
and service calls to assign control of the call to the operator. Once applied, the call will only
clear when the nominated controlling party clears the call.
CONSUME - The option consume is used to explicitly define the number of digits to
consume when passing through translations from one XLASYS to another. The digits
consumed are removed from the TRANSLATION register only.
FEATINFO
The FEATINFO selector is used for specific screening purposes and will be
covered in a later module.
18
DMOD - Digit Modify
This selector allows some or all of the input digit stream to be modified. The following
options are available :
PF - Removes the number of digits that are considered to be prefix digits. PF digits remain
in the Billing record (CDR only) but not the Outpulse or Translation registers.
INSRT - This causes digits to be inserted (after skipping over the digits to be untouched,
see AFTER). Further digits will be accepted from the agency and overlapped out pulsing
should not be affected. All registers are affected.
REPL - This causes the whole digit stream (after skipping digits ) to be replaced.
Overlapped out pulsing will be disabled, and all digits will be collected before continuing.
REPL and INSRT cannot be used in the same tuple. All registers are affected.
DEL - This causes digits to be deleted (after skipping over the digits to be left alone).
Further digits will be accepted from the agency, and overlapped out pulsing should not be
affected. All registers are affected.
The digits to be deleted will be processed before those to be inserted, so that individual
digits may be replaced by deletion followed by insertion.
AFTER - The default case will be to calculate the new prefix fence (cursor position), and
then replace, insert or delete digits after the fence (i.e. starting at the next digit). The
AFTER option gives an additional number of digits to skip before doing the modification.
All registers are affected.
The option AFTER refers to the option datafilled immediately before it
e.g. DMOD DEL 3 AFTER 2 INSRT 11.
This instruction skips 2 digits, deletes the next 3 and inserts 11 at the position of the cursor.
The result when applied to the digits 234567 is 23117.
Note: Also note that the above operations are done in the actual digit stream and the
changes reflected in call detail records, etc.
XLT - The next translation system and translator name to use. This option is as described
above for CONT. Note that following DMOD, RTE is not an option from the current
translation system
19
Universal Translation Route Tables
Table xxRTE
XLANAME RTEREF RTELIST
Index number Route selector,

pointed from as seen in
xxCODE table earlier Route Table
module.
20
When a Routing decision has been made in a code table, the XLASEL of RTE will point to
a Route Reference (RTEREF) in the xxRTE table.
Again the XLANAME is the link, along with the RTEREF.
The RTELIST choices are the same as covered in the earlier Routing Tables module.
20
Head and Code Table example
Table PXHEAD
DFLT - Default DFOP - Default CON MAXIDX

action if digits options to apply Consume the 9 or STD
XLANAME when digits are digits used to
are not in the
Code table matched in the index the
Code table Code table
Table PXCODE
Digit range to be matched Instructions to follow

if dialled digits fall
within the FROMD
and TOD range
21
To illustrate the workings of the HEAD and CODE tables we will look at a simple example.
We now know the information contained in a HEAD table.
As previously stated, a HEAD table will be associated with a CODE table.
The CODE tablefill contain the fields XLANAME, FROMD, TOD, and XLADATA
( translation data ).
The XLANAME is the translator name used in the HEAD table. This name forms the link
between the two tables.
The FROMD and TOD ( from digits and to digits ) field allows you to specify a range of
digits that you wish to match.
The XLADATA ( translation data ) field contains the instructions that will be actioned if the
digits dialled fall within the range specified in the FROMD and TOD fields.
The above diagram shows the relationship between the HEAD and CODE tables.
21
XLANAME DFLTSEL DFOP CON MAX
What to do if the If there is a match in CON - consume the
digits do not match in the FROMD
Centrex TOD
Overview digits 3.00
Translator name
FROMD TOD field use these options. NOCON - do not
is the index into 9 or STD
SDFLT = vactrmt NODFOP no default consume the digits
the 3 tables
DFLT = xlasel to options or DFOP e.g. from the FROMD
HEAD process the call MIN MAX TOD field
Same translation Code table instructions NOCON cannot be

Selectors as Code overrides Head table Overridden by the
Table options instructions code table
XLANAME FROMD TOD XLADATA XLASEL

If there is a match in The translation
Translator name Digit range to be the FROMD TOD selectors you can use .
is the index into matched field, instructions on e.g.
the 3 tables e.g. from 00 to 00 on how to CONT, RTE,
process the call. DMOD & TRMT
CODE
XLANAME RTEREF RTESEL TABNAME INDEX
Route selector
Translator name A reference number
T Index number into the
is the index into from the code table Routing table name
to point out to the routing table
the 3 tables into this table.
routing tables
RTE
22
This diagram shows the relationship between the three tables that make up a Translation
System.
Note all the Translation Systems have the same relationship.
22
Translations Expansion
Translations Expansion provides the following enhancements to the CS2000 Translations
capabilities:
Expands the number of universal translations CODE table tuples by adding four new
tables:
CT2CODE, FA2CODE, OFC2CODE, and PX2CODE.
The xx2CODE tables have all the features and characteristics of the corresponding
xxCODE tables.
Provides the ability to route from any HEAD or CODE table to any routing table.
(previously it was only possible to route to the RTE Table of the Translation system of that
HEAD or CODE Table; e.g. FACODE used the DEST option to route only to FARTE).
This is achieved by the use of a new option TERM
Note the following differences between the xxCODE and xx2CODE tables:
The xx2CODE tables use the equivalent xxHEAD table.
No xxHEAD tables have been added. In the same way as for the xxCODE table structure,
the XLANAME, which is used for indexing within a given table, must first be defined
within the corresponding xxHEAD table. Therefore, the new xx2CODE tables use the
existing xxHEAD tables, for example, PX2CODE uses PXHEAD.
The xx2CODE tables use the equivalent xxRTE tables for routing.
No xxRTE tables have been added. When the DEST option is used in the new xx2CODE
tables, the referenced tuple must first be created in the relevant xxRTE table.
The xx2CODE tables provide up to 30 digits for searching.

In the xx2CODE tables, fields FROMD and TOD can be 1 to 30 digits in length compared
with 1 to 11 digits in length in the xxCODE tables.
Limitations and restrictions

The limitations and restrictions are:
The xxHEAD and xxCODE tables cannot be datafilled with the TERM and DEST options
on the same tuple because TERM and DEST provide similar functionality, and would
therefore conflict.
In the xxHEAD tables, the TERM option can be datafilled under the DFLT RTE selector,
but not under the DFOP selector.
Options that provide direct access to xxRTE (where xx is AC, AM, FA, FT, NSC, PX, CT,
or OFC) tables will be prevented from datafilling the new Translations Systems (PX2, CT2,
FC2 and FA2) because corresponding xxRTE tables were not created by this activity (for
example, no PX2RTE tables exist).
23
Functional diagram for the new xx2 translations
systems
Default xxHEAD Default

Routing Routing
xx2CODE CONT xxCODE
RTE RTE
CONT CONT
xxRTE
24
New translations systems

The functional diagram for the new translations systems is shown in the above figure.
As the diagram above illustrates, the translations flow of the new xx2Code tables are exactly
the same as the xxcode tables.
To access the xx2CODE tables, four new translations systems are provided: PX2, FA2, CT2
and OFC2. The new translations systems can be accessed by using the CONT selector from
the existing translations systems.
To point the XLTNAME to XX2CODE Tables using the CONT option
Examples;
From Table PXHEAD
EMERG DFLT CONT (XLT PX2 NATIONAL) $ DFOP (MM 3 5) (CLASS NATL) $
CON 9
From PXCODE
EMERG 5555 5555 CONT (XLT PX2 EMERG) $
The above datafill is as normal in the prompt mode, however when in the xx2code
tables it is different;
24
When adding datafill to the XX2" code table e.g. PX2CODE in prompt mod, the switch
prompts for the KEY, Not the translator name, followed by FROMD TOD e.g.
TABLE: PX2CODE
>add
KEY:
>emerg 5555 5555
XLASEL:
>cont
OSEL:
>xlt
XLASYS:
>ct2
XLANAME:
>danct2la
OSEL:
>$
TUPLE TO BE ADDED:
EMERG 5555 5555 CONT (XLT CT2 DANCT2LA) $
ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.
>y
TUPLE ADDED
WRITTEN TO JOURNAL FILE AS JF NUMBER 496
RTE Selector option TERM
The new option TERM is provided under the RTE selector in the xxHEAD tables (where xx
is AC, PX, CT, FA, NSC, OFC or FT) and xxCODE tables (where xx is AC, PX, CT, FA,
NSC, OFC, FT, PX2, CT2, OFC2 or FA2). The TERM option provides similar functionality
to the T selector in the routing tables, and can be used to route to any CS2000 routing table,
that is, IBNRTx (where x is E, 2, 3 or 4), OFRx (where x is T, 2, 3, 4), OVRx (where x is 0
to 89), and xxRTE (where xx is AC, PX, CT, FA, NSC, OFC or FT).
Note: In the xxHEAD tables, the TERM option can be datafilled under the DFLT RTE
selector, but not under the DFOP selector.
ROUTING from a CODE table
The new TERM option allows the xxCODE tables to directly access the OFRx, IBNRTx
and OVRx tables.
The DEST option can still be used to access the xxRTE tables.
The TERM option uses one of the following suboptions:
- TABNAME and INDEX to access OFRx, OVRx and IBNRTx tables
- IRTE followed by a valid XLASYSTEM and XLANAMEto enable access to an xxRTE
table
The functional diagram for routing from a CODE table is shown in the following figure.
25
Functional diagram for routing from a
CODE table
xxHEAD
xxCODE
IBNRTx
Corresponding OFRx
xxRTE OVRx
xxRTE
26
26
Table Lineattr Entry point to Centrex Overview 3.00
Universals
CS2000
Lines
Customer Group
Customer Group
Trunks
Table
Table
Lineattr
LINEATTR
Universal
Other Switches
Universal
Translations
Translations
27
Table LINEATTR
Table LINEATTR, (line attribute), is used to point calls from the Centrex translations
environment into Universal translations. The NET - DOD selector is used to point to a
LINEATTR index number. An example tuple from a TRAVER is shown below.
TABLE IBNXLA: XLANAME UNICT

TUPLE NOT FOUND
UNICT (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9
Note. The Index to Table LINEATTR can also be Alpha-numeric characters.
TABLE LINEATTR
1 IBN NONE NT 0 0 NILSFC 0 PX NCCPXLA NIL 00 CS_NPRT CS_NIL_1 $
In this example, the net - dod selector points to lineattr index 1.

Table LINEATTR index 1, points calls to the PX XLASYS, translator name NCCPXLA.
Note: The datafill shows that Lineattr tables can point to any Universal translation system,
however any translation system other than PX results in data error.
27
Table LINEATTR (another) Example:
Table Lineattr
LNATTIDX LCC CHGCLSS COST LTG TRAFSNO SFC MDI
PSTNXLA ibn none nt 0 0 nilsfc 0
XLASYS XLANAME DGCLNAME FANIDIGS DFLTXLP DFLTRA OPTION
px mh3pxla nil 00 CS_NPRT CS_NIL $
In this example, line attribute index PSTNXLA is used to point calls to the PX XLASYS,
XLANAME mh3pxla. There are a number of fields that do not apply to the U.K. translation
schemes and default values may be assigned.
The fields are:-
LNATTIDX Line Attribute Index. Alphanumeric (up to 16 characters)
LCC Line Class Code. The line class code assigned to the line attribute index.
Enter IBN for IBN translations.
CHGCLSS Enter NONE.
COST Enter NT.
LTG Enter 0, (zero)
TRAFSNO Traffic Separation Number. Peg counts calls by type. Enter 0, (zero)
SFC Enter NILSFC
MDI Enter 0, (zero)
XLASYS Translation System. Enter the XLASYS in which calls will start translation.
N.B. The PX system must be used for calls from Centrex translations using
the NET - DOD selector.
XLANAME Translator name. Enter the translator name within the PX XLASYS in which
calls will start translation.
DGCLNAME Enter NIL
FANIDIGS Enter 0 0, (zero) (zero)
DFLTXLP Defaullt XLAPLAN, enter valid entries from Table XLAPLAN
DFLTRA Default RATEAREA, enter valid entries from Table RATEAREA
28
Universal Translations Verification
(TRANSVER)
CI:
>transver
Next par is: <XLA_SYSTEM> {AC,
PX,
CT,
FA,
OFC,
DN,
AM,
FT,
NSC,
CC,
CTY,
NN,
VPN,
ALL}
Enter: <XLA_SYSTEM> [<OPTION>]
29
Universal Translations Verification Tool ( TRANSVER)

The TRANSVER tool allows the checking of Universal Translation systems for errors or
redundant keys.
From the CI prompt, enter TRANSVER.
An example of the screen that appears is shown above.
As can be seen, any specific Universal Translation system may be checked or if ALL is
entered then all systems are checked.
29
TRANSVER example
>transver ofc

******************************
* UNIVERSAL TRANSLATIONS *
* VERIFICATION TOOL *
* *
* DATAFILL OF SYSTEM OFC *
* WILL BE VERIFIED *
******************************

WARNING : TUPLES ARE REDUNDANT FOR THE FOLLOWING KEYS
WARNING : OFCRTE T4OFC 999

ERROR : TUPLES ARE MISSING FOR THE FOLLOWING KEYS
ERROR : OFCRTE PARISA 3

VERIFICATION IS COMPLETE

NUMBER OF WARNINGS = 1 NUMBER OF ERRORS = 1
30
30
31
Module 8
Universal Translations Datafill
International Calls
nortel.com/training
0
1
International Calls
Purpose
concepts of;
> Universal Translations datafill procedures.

Describe the call flow process in Universal Translations
Datafill an exercise to handle International Calls, using the
translation selector CONT and RTE with applicable OSEL
options
Traver the results of your datafill
Explain the results of the Travers
2
2
3
Universal Translations Datafill International Calls
from table LINEATTR
IDD PX
PSTNPXLA
SDFLT (temporarily)
CT
PSTNCTLA
DFLT
Route for calls
To Europe
Route for calls to

rest of the world
4
Universal Translations Datafill Examples

The previous section detailed the options and selectors available in the XLASYS HEAD and
CODE tables. This section will describe the process of translating digits through different
XLASYS using the RTE, CONT and XLT options.
In this example we shall consider an International call. The call is to route dependant on the
country code. In this example, the call will be translated in the PX XLASYS and pass on to
the CT XLASYS. The requirement is that all calls to the European zone, (country code 3 &
4), will route to a specific Gateway switch and calls to the North American zone, (country
code 1), will DEFAULT route over another. The translation requirements can be
represented as a flow diagram and an example is given above.
Calls will be filtered in the PXHEAD table, PSTNPXLA. If the call has an IDD prefix, it
will proceed to the CT SYSTEM, PSTNCTLA.
The CODE table entries in table CTCODE, PSTNCTLA, will look for IDD codes with the
European country codes starting with 3 or 4. Codes not found will be non European and will
default route to the appropriate destination. Codes that are matched will route to the
European Gateway destination.
Non IDD calls will use the default from the PSTNPXLA HEAD table and will (for now),
fail to Treatment.
4
Datafill Planning
The flow diagram can be a useful tool when planning your datafill requirements. The
diagram on on the previous page shows how a particular call will progress through a
translation scheme.
It shows the point of entry and exit, i.e. a final route. The different XLASYS and
XLANAMES are shown so that it can be seen where the translation continues to and from
where it came. It is logical that you plan top down from point of entry to point of exit.
Datafill Entry
Once planned, you must enter the appropriate data into the CS2000. No matter how
complex your translation requirements, the same datafill rules apply. Clearly, you cannot
point to a XLASYS and XLANAME unless it is pre - defined. Bearing this in mind, the
rule to apply is that the order in which datafill must take place is from the bottom to the
top of the translation scheme flow plan.
Consider again the plan on the previous page. Translation begins in the PX XLASYS using
a translator name of PSTNPXLA. An international call will continue in the CT XLASYS
using the PSTNCTLA translator name. In order to complete the datafill, the first tables to be
entered must be the HEAD, CODE, and RTE tables of the CT XLASYS.
Remember! You cannot point to a XLASYS and XLANAME that does not exist.
Datafill Example
The following example is given to show the datafill requirements to provide the translation
of International calls as per the previous flow chart. The example will show the use of the
translation selectors, (XLASEL), RTE and CONT along with any appropriate options
(OSEL).
The translation selectors and their options were discussed in the Universal Translations
Overview module.
NOTE: The tables will be presented in call flow order for ease of understanding.
An example of the table structure is given in the Universal Translations Overview module.
In our example, we need to define the XLANAME and action to take if the call is not an
IDD call. This is the DEFAULT action, DFLT, and is defined in the HEAD table along with
any DEFAULT OPTIONS, DFOP, which will apply to all associated CODE table entries.
The HEAD concludes with the CON and MAXIDX fields.
If the call is an IDD call, it must CONT, (continue), in the CT XLASYS using translator
name PSTNCTXLA. This action will be defined in the associated CODE table.
For the purposes of the example we will assume the dialled digits are 00 31 23 567 5555.
5
Head Table Example
The call begins the translation process in the PX XLASYS using a translator name of
PSTNPXLA.
The associated CODE table will define the IDD prefix code, 00.
The HEAD table will look like this:-
TABLE PXHEAD
XLANAME DFLTSEL DFOPSEL CON MAXIDX
pstnpxla sflt nodfop con std
The HEAD table tuple shows the fields in bold text. It can be seen that a translator name of
PSTNPXLA has been created. The DFLT action SDFLT will send codes not matched in the
CODE table to Standard Default Treatment (Vacant Trmt).
The DFOP, (Default options), field shows that no options are to apply to codes in the CODE
table.
The CON field shows that digits are to be consumed before passing to another translation
system.
The MAXIDX field shows that any digit in the range 0 to 9 is valid in the CODE table.
Code Table Example

The HEAD and CODE tables always work together and the XLANAME forms the link
between them. (see the Universal Translations Overview module)
The CODE table must define the digits to be matched along with instructions (XLASEL),
and any options (OSEL) to follow if they are matched.
The CODE table will look like this:-
TABLE PXCODE
XLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGS
OSEL
pstnpxla 00 00 cont xlt ct pstnctla consume 2 $
The CODE table tuple shows the fields in bold text.

Field XLANAME contains the translator name used in the corresponding HEAD table and
links the two tables together.
Fields FROMD and TOD declare the range of digits to be matched.
Field XLASEL determines the action to take if the digit range is matched by the dialled
digits. The field includes options, (OSEL), that are applied to the matched digits.
6
The CODE table example shows that if an IDD call is dialled, the call will CONT
(continue), XLT (translating) in the CT XLASYS using XLANAME PSTNCTLA. A
consume option has been included to consume 2 digits before passing to the CT XLASYS.
The example shows an IDD call passing to the CT XLASYS where country codes will be
sampled.
Our example must now contiue in the CT XLASYS where we will check for European
country codes. A HEAD, CODE and RTE table is required in the CT XLASYS as we are
going to route calls to European Gateway route or a route for all other countries.
Option MM-MIN MAX

Another option will be needed here, the option MM, (MAX MIN digit check). The MM
option must be included to define the minimum and maximum digit string length expected.
The MM option is described on p.12 of the Overview module. The MM option can be
applied in the HEAD table if the digit range specified will apply to all codes defined in the
CODE table. Alternativly, the MM check can be specified for each code entry in the CODE
table. MM checks applied in the CODE table override those applied in the HEAD table.
Note If no MM option is specified, the system defaults to a value of Min 3, Max 3.
If fewer than the Minimum specified digits are received, the call will fail as PDIL, ( partial
dial), after the inter digit wait time has expired. If more than the Maximum specified digits
are received they will be ignored and a warning will be seen in the call traver .
7
CT Head and Code table
As in the PX XLASYS example, we must build a CT HEAD table to apply default action,
Default options, Consume and Maxidx values.
The CT HEAD table will look like this :-
TABLE CTHEAD
XLANAME DFLTSEL XLASEL OSEL MIN MAX OSEL DEST OSEL CLASS OSEL
pstnctla dflt rte mm 7 18 dest 3 class intl $
DFOPSEL OSEL CLASS OSEL CON MAXIDX
dfop class intl $ nocon std
The HEAD table tuple shows the fields in bold text.

The field XLANAME declares the translator name PSTNCTLA.
The field DFLTSEL defines the action to take if the dialled digits are not matched in the
associated CODE table. In this example the default action is to RTE (route) calls to a DEST
(destination) of 3 and apply a MIN and MAX digit check of 7 to 18 digits. A further option
CLASS has been applied. The CLASS type is INTL (international),which is the trigger for
an AMA billing record. The options used where described in the Overview module.
The field DFOPSEL defines default options to be applied to all entries in the CODE table.
In this instance the CLASS INTL (international) has been applied. Remember, DFOP
options applied in the HEAD table can be overriden by options applied in the CODE table.
The field CON declares that nocon, (no consume), will be applied. This value applies as we
are going to RTE calls without further translation applying.
The CODE table must now be considered. Only one code entry will be studied for ease of
understanding.
We need to sample the dialled digits and look for European codes. The digits used to index
the CODE table will begin with country codes. The IDD prefix of 00 was consumed in the
PX CODE table, NCCPXLA.
The CODE table will contain the instruction to RTE, (route), all European calls. It will be
seen that a specific MM check has been applied to the dialled digits ( This is done because
we are assuming all European destination codes are 12 digits inclusive of country codes).
An example of the CODE table is given overleaf.
8
TABLE CTCODE
XLANAME FROMD TOD XLASEL OSEL MIN MAX OSEL DEST OSEL
pstnctla 31 31 rte mm 12 12 DEST 6 $
CT RTE table
A RTE table is required to point calls to the appropriate ROUTE table. In considering the
RTE table it is assumed that appropriate OFRT or IBNRTE tables exist.
The CT RTE table will look like this:-
TABLE CTRTE
XLANAME RTEREF RTESEL TABNAME INDEX RTESEL
pstnctla 3 t ibnrte 70 $
Once again, the fields are shown in bold text.

There are two tuples, one for each route destination required. Remember, calls to Europe are
to route one way and all other country codes are to route differently.
The index into the CT RTE table is by XLANAME and the DEST index number used in the
corresponding XLASYS tables. In this example, the CT HEAD and CODE tables.
The field XLANAME defines the translator name. Once again, this is the link to the
corresponding HEAD and CODE tables in the same XLASYS. The field RTEREF is the
index number into the RTE table form the DEST field of option RTE used in the HEAD or
CODE table.
The field RTESEL defines the route selector to be used. In this instance a T which allows us
to point to a predefined OFRT or IBNRTE table entry.
The fields TABNAME and INDEX allow us to specify the OFRT or IBNRTE table entry
applicable to this RTE.
For clarification, the tables of the PX XLASYS and CT XLASYS can now be looked at
together. It will now be possible to see the whole picture in terms of datafill.
9
TABLE PXHEAD
pstnpxla sdflt nodfop con std
TABLE PXCODE
OSEL
TABLE CTHEAD
TABLE CTCODE
TABLE CTRTE
pstnctla 3 t ibnrte 70 $ Other International
pstnctla 6 t ibnrte 60 $ European
10
TABLE PXHEAD
pstnpxla sdflt nodfop con std
TABLE PXCODE
OSEL
TABLE CTHEAD
TABLE CTCODE
TABLE CTRTE
11
Call Summary
Calls are filtered in the PX XLASYS using translator PSTNPXLA. The CODE table looks
for IDD calls. IDD calls are sent to the CT XLASYS by the PX CODE table instruction.
All other calls are sent to the PX XLASYS, translator PSTNPXLA, TO THE SDFLT
instruction to fail the call to TRMT.
Calls entering the CT XLASYS do so without the IDD code 00, as this was consumed in the
PX CODE table entry.
The CT CODE table, translator name PSTNCTLA, looks for European codes starting 3 or 4.
(Remember, only one code was entered for demonstration purposes.)
The CODE table entry points European codes to a RTE DEST of 6. This is the index into
the CT RTE table.
All other codes use the DFLT instruction in the CT HEAD table and are pointed to a RTE
DEST of 3. This is also an index into the CT RTE table.
The CT RTE table, translator name PSTNCTLA, is indexed by the RTEREF numbers used
in the HEAD and CODE tables of the same XLASYS and XLANAME.
The CT RTE table points calls to the appropriate OFRT or IBNRTE tables.
Note : It has been assumed that the PSTNPXLA tables and the IBNRTE tables already exist.
12
This page is intentionally left blank
13
Traver - European Call
>TRAVER L 8795215 00331234567890 B
TABLE KSETLINE
RM05 00 0 02 15 1 DN Y 8795215 CLASSDEM 0 0 162 $ MBS
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5215 5215
(PUBLIC ( ADDRESS 0162 879 NNNN) $)$
Originator is not an EIN agent, therefore EIN info is not processed.
TABLE NCOS
CLASSDEM 0 0 0 NO_BAR $
TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL
CLASSDEM NXLA CXCLASS FXDEMO 0 CLASSDIG
TABLE DIGCOL
TUPLE NOT FOUND
Default is RPT
TABLE IBNXLA: XLANAME CXCLASS
TUPLE NOT FOUND
CXCLASS
TABLE DIGCOL
TABLE LINEATTR
1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
14
TABLE PXHEAD
DEMOXLA SDFLT DFOP $ CON STD
TABLE PXCODE
DEMOXLA 00 00 CONT ( CONSUME 2) ( XLT CT DANCTLA)$
TABLE CTHEAD
DANCTLA DFLT RTE ( MM 10 18) ( DEST 2) ( CLASS INTL)$ DFOP ( MM 12 12) ( CLASS 9
TABLE CTCODE
DANCTLA 3 3 RTE ( DEST 1)$
TABLE: CTRTE
KEY: DANCTLA 1
. T OVR30 1
. . TABLE OVR30
. . 1 S D DANEURO
. . EXIT TABLE OVR30
EXIT TABLE CTRTE

1 DANEURO
1 GNCT
15
Traver - Rest of the World
>TRAVER L 8795215 0063334745255 B
TABLE KSETLINE
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5215 5215
TABLE NCOS
TABLE DIGCOL
TUPLE NOT FOUND
Default is RPT
TUPLE NOT FOUND
CXCLASS
TABLE DIGCOL
TABLE LINEATTR
1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
16
TABLE PXHEAD
DEMOXLA SDFLT DFOP $ CON STD
TABLE PXCODE
DEMOXLA 00 00 CONT ( CONSUME 2) ( XLT CT DANCTLA)$
TABLE CTHEAD
DANCTLA DFLT RTE ( MM 10 18) ( DEST 2) ( CLASS INTL)$ DFOP ( MM 12 12) ( CLASS 9
TABLE CTCODE
TUPLE NOT FOUND
DEFAULT FROM HEAD TABLE USED
TABLE: CTRTE
KEY: DANCTLA 2
. T OVR30 2
. . TABLE OVR30
. . 2 S D DANNONEURO
. . EXIT TABLE OVR30
EXIT TABLE CTRTE

1 DANNONEURO
1 GNCT
17
18
18

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
19
Naming Conventions

Translation system.
Kingdom.
19
Universal Translations Datafill International Calls Exercise
from table LINEATTR
IDD PX
PSTNPXLA
SDFLT (temporarily)
CT
PSTNCTLA
DFLT
Route for calls
To Europe
Route for calls to

rest of the world
20
Universal Translations Exercises

The exercises are designed to allow students to build their own translations following real
world practice. Each exercise builds on the previous one until a complete translations
scheme has been built. Students are expected to plan their datafill on paper and support their
solutions with travers. The examples given in the module Datafill Examples may be used
for reference, however, the requirements of the exercises may differ. A flow diagram
depicting the exercise requirements is shown above.
20
Exercise 1
The purpose of this exercise is to :-
Practise the use of the Cont and Rte selectors, with appropriate options, to translate through
the PX and CT XLASYS.
Students are required to:-
Translate International calls.
Datafill a table LINEATTR tuple.
Use the routes previously datafilled in Route Exercise A for European and Non-European
routes.
The translation requirements are :-
European calls in the range 00 3X XXXXXXXXXX to 00 4X XXXXXXXXXX are to route
to the European route.
All other international calls are to route to the International route.
Datafill a LINEATTR tuple. Ask your Instructor for a LINEATTR index reference.
TASK A.
Plan your translations on paper and discuss the results with your instructor
TASK B.
Datafill the Universal Translation Tables.
Datafill the LINEATTR tuple.
Change your Customer Group translations to point your NET DOD selector to your new
LINEATTR index.
Traver your datafill and test by dialling (if available in this classroom).
Notes.
It is assumed that all European countries have 12 digit numbering plans, inclusive of the
country code plus the international access code (14 digits total).
Use SDFLT in your PX HEAD table for the time being. This will be changed in later
exercises.
Remember, although you may plan top down, you must datafill from the last XLASYS
first.
Also remember the required naming convention.
There is a flowchart depicting the exercise requirements on the previous page.
21
22
23
Module 9

Local Calls
nortel.com/training
0
1
Datafill Local Calls
Purpose
The purpose of this section is to introduce the student to the concepts of;
> Universal Translations datafill procedures

Datafill an exercise to handle Local Calls, using the translation selectors
DMOD, CONT and RTE with applicable OSEL options
2
2
3
Universal Translations Datafill Local Calls
from table LINEATTR
IDD PX
PSTNPXLA
Local SDFLT (temporarily)
CT OFC
PSTNCTLA 628FALA
DFLT
Route for calls SDFLT Terminate
To Europe Local calls
Route for calls to

rest of the world Treatment
4
Introduction
In this module we will be dealing with local calls.
In many countries these can be either dialled as a 6, 7 or 8 figure number or as a full
national number.
For the purposes of this course we will assume local dialling is 6 digit.
To do this, local 6 figure numbers will be screened in the PX system, modified to a full
national number, and then dealt with accordingly.
To accomplish this, we will use the DMOD selector to modify the digit string.
4
Datafill Examples using DMOD
The DMOD, digit modification, option was described in the Universal Translations
Overview module. DMOD allows modification of digits within the translation process and
two examples will be considered. In the first, digits will be added to a number before
continuing translation, in the second, digits will be deleted and new digits inserted before
translation continues. Once again, the examples are given to describe the process used. The
process will be implemented in later exercises.
Digit insertion
In the first example, a 6 digit local number in the range 79xxxx is to be modified to include
the national code 01628. The number will then continue translating in the OFC XLASYS
where own office calls are translated.
The translation requirements can be represented as a flow diagram and an example was
given on the previous page.
Datafill Example - Local Calls
The following example is given to show the datafill requirements to provide the translation
of local calls as per the flow chart on page 1. The example will show the use of the
translation selectors, (XLASEL), RTE, CONT and DMOD along with any appropriate
options (OSEL).
The translation selectors and their options were discussed in the Universal Translations
Overview module.
This example assumes that the tables for Non local calls are already in place. The tables will
be presented in call flow order for ease of understanding.
Head Table Example
The call begins the translation process in the PX XLASYS using a translator name of
PSTNPXLA.
The associated CODE table will define the range of local call numbers in both full national
and 6 digit dialling format. In this example, 79xxxx and 016287xxxxx.
The HEAD table will look like this:-
Table PXHEAD
XLANAME DFLTSEL XLASEL OSEL XLASYS XLANAME DFOPSEL OSEL CLASS
pstnpxla dflt cont xlt fa pstnfala dfop class natl
CON MAXIDX
con std
The HEAD table tuple show the fields in bold text. It can be seen that a translator name of
PSTNPXLA has been created. The DFLT action will send codes not matched in the CODE
table to the FA XLASYS using XLANAME - PSTNFALA.
The DFOP, (Default options), field shows that the option CLASS NATL is to apply to codes
in the CODE table.
The CON field shows that digits are to be consumed before passing to another translation
system.
5
Code Table Example
The HEAD and CODE tables always work together and the XLANAME forms the link
between them. (see the Universal Translations Overview module).
The CODE table must define the digits to be matched along with instructions (XLASEL),
and any options (OSEL) to follow if they are matched.
TABLE PXCODE
pstnpxla 016287 016287 cont xlt ofc 6287fla consume 4
XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAME
pstnpxla 79 79 dmod insrt 01628 xlt px pstnpxla
OSEL CONDIGS OSEL
consume 0 $
The CODE table tuple shows the fields in bold text.

Field XLANAME contains the translator name used in the corresponding HEAD table and
links the two tables together.
Fields FROMD and TOD declare the range of digits to be matched.
Field XLASEL determines the action to take if the digit range is matched by the dialled
digits. The field includes options, (OSEL), that are applied to the matched digits.
The CODE table example shows that if a local call is dialled using the full national number,
the call will CONT (continue), XLT (translating) in the OFC XLASYS using XLANAME
6287FLA. A consume option has been included to consume 4 digits before passing to the
OFC XLASYS.
If a local call is dialled using the 6 digit format, the DMOD option is used to insert 01628
and the CONT option is used to pass the translation back into the PX XLASYS,
XLANAME PSTNPXLA. The translations proceed using the 016287 tuple in the CODE
table. Local calls with the short format are dealt with in this way because billing systems
use the full national number format.
The PSTNPXLA tables will not require a PXRTE entry because all calls point to further
translation systems.
The OFC XLASYS entries are required to complete the translation.
6
OFC table example
The call continues in the OFC XLASYS, XLANAME 6287FLA. Only 7 digits will be
received from the PX CODE table PSTNPXLA because 4 digits were consumed. The OFC
HEAD table will look like this :-
TABLE OFCHEAD
XLANAME DFLTSEL DFOPSEL OSEL CLASS CON MAXIDX
6287fla sdflt dfop class natl nocon std
The HEAD table tuple show the fields in bold text. It can be seen that a translator name of
6287FLA has been created. The DFLT action will send codes not matched to System
Default.
The DFOP, (Default options), field shows that the option CLASS NATL is to apply to codes
in the CODE table.
The CON field shows that digits are not to be consumed before passing to another
translation system.
The call enters the OFCCODE table using the XLANAME 6287FLA and the 7 digits
received from PX.
The OFCCODE table will look like this:-
TABLE OFCCODE
XLANAME FROMD TOD XLASEL OSEL DEST OSEL MIN MAX OSEL
6287fla 879 879 rte dest 1 MM 7 7 $
The entry 6287FLA specifies any digits starting 879 are to RTE to DESTination index 1 in
the OFCRTE table.
The next table to consider is OFCRTE. It will look like this:-
TABLE OFCRTE
6287fla 1 t ibnrte 79
The index into the OFC RTE table is by XLANAME and the DEST index number used in
the corresponding XLASYS tables. In this example, the OFC CODE table.
The field XLANAME defines the translator name. Once again, this is the link to the
corresponding HEAD and CODE tables in the same XLASYS.
The field RTEREF is the index number into the RTE table form the DEST field of option
RTE used in the CODE table.
The field RTESEL defines the route selector to be used. In this instance a T which allows us
to point to a predefined IBNRTE table entry.
The fields TABNAME and INDEX allow us to specify the IBNRTE table entry applicable
to this RTE.
7
For clarification, the tables of the PX XLASYS and CT XLASYS can now be looked at
together. It will now be possible to see the whole picture in terms of datafill.
Table PXHEAD
XLANAME DFLTSEL XLASEL OSEL XLASYS XLANAME DFOPSEL OSEL CLASS
pstnpxla dflt cont xlt fa pstnfala dfop class natl
CON MAXIDX
con std
TABLE PXCODE
pstnpxla 016287 016287 cont xlt ofc 6287fla consume 4
XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAME
pstnpxla 79 79 dmod insrt 01628 xlt px pstnpxla
OSEL CONDIGS OSEL
consume 0 $
TABLE OFCHEAD
XLANAME DFLTSEL DFOPSEL OSEL CLASS CON MAXIDX
6287fla sdflt dfop class natl nocon std
TABLE OFCCODE
XLANAME FROMD TOD XLASEL OSEL DEST OSEL MIN MAX OSEL
6287fla 879 879 rte dest 1 MM 7 7 $
TABLE OFCRTE
6287fla 1 t ibnrte 79
Finally, two travers are shown as examples of one way to translate dialling a local number
in the short format and full national format. The travers are shown overleaf.
8
Traver - Local number full format
>TRAVER L 7895215 01628795214 B
INVALID DIRECTORY NUMBER
>TRAVER L 8795215 01628795214 B
TABLE KSETLINE
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5215 5215
TABLE NCOS
TABLE DIGCOL
TUPLE NOT FOUND
Default is RPT
TUPLE NOT FOUND
CXCLASS
TABLE DIGCOL
TABLE LINEATTR
68 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_4 NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( MM 3 18) ( CLASS NATL) $ CON 9
TABLE PXCODE
PSTNPXLA 01628 01628 CONT ( CLASS NATL) ( XLT OFC 628FLA)(CONSUME 4) $
TABLE OFCHEAD
628FLA SDFLT DFOP ( MM 7 7) ( CLASS NATL)$ NOCON 9
TABLE OFCCODE
628FLA 879 879 RTE ( DEST 1) $
Continued overleaf
9
Traver - Local number full format - continued
TABLE: OFCRTE
KEY: 628FLA 1
. T IBNRTE 79
. . TABLE IBNRTE
. . 79 DN 162 879 N 0 4
. . . 162 879 $
. . . TABLE DNINV
. . . 162 879 5214 L RM05 00 0 02 14
TABLE DNFEAT
TUPLE NOT FOUND
. . . TABLE DNATTRS
. . . TABLE DNGRPS
. . . 162 879 5214 5214
EXIT TABLE OFCRTE

1 LINE 1628795214 ST
1 GNCT
10
Traver - Local number short format
>traver l 8795215 795214 b
TABLE KSETLINE
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
162 879 5215 5215
TABLE NCOS
TABLE DIGCOL
CLASSDIG 7 COL L 5
TUPLE NOT FOUND
CXCLASS
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
PSTNPXLA DFLT CONT ( XLT PX INTERNAT) $ DFOP ( CLASS NATL) $ CON 9
TABLE PXCODE
PSTNPXLA 7 7 (DMOD INSRT 01628 XLT PX PSTNPXLA) (CONSUME 0) $
TABLE PXHEAD
PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( MM 3 18) ( CLASS NATL) $ CON 9
TABLE PXCODE
PSTNPXLA 01628 01628 CONT ( CLASS NATL) ( XLT OFC 628FLA)(CONSUME 4) $
TABLE OFCHEAD
628FLA SDFLT DFOP ( MM 7 7) ( CLASS NATL)$ NOCON 9
TABLE OFCCODE
628FLA 879 879 RTE ( DEST 1) $
Continued overleaf
11
Traver - Local number short format - continued
TABLE: OFCRTE
KEY: PSTNFALA 1
. T IBNRTE 79
. . TABLE IBNRTE
. . 79 DN 162 879 N 0 4
. . . 162 879 $
. . . TABLE DNINV
. . . 162 879 5214 L RM05 00 0 02 14
TABLE DNFEAT
TUPLE NOT FOUND
. . . TABLE DNATTRS
. . . TABLE DNGRPS
. . . 162 879 5214 5214
EXIT TABLE OFCRTE
1 LINE 1628795214 ST
1 GNCT
>
12
13

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
14
Naming Conventions

Translation system.
Kingdom.
14
15
Universal Translations Datafill Local Calls
from table LINEATTR
IDD PX
PSTNPXLA
Local DFLT (temporarily)
CT OFC
PSTNCTLA 628FALA
DFLT
Route for calls SDFLT Terminate
Route for calls to

rest of the world Treatment
16
Exercise 2
Practise the use of the Cont, Rte and Dmod selectors, with appropriate options, to translate
through the PX and OFC XLASYS.
Translate Local calls using both the full national and 6 digit number.
Use the routes previously datafilled in Route Exercise A.
Calls to your office using the full 11 digit national number are to route to the IBNRTE with
your DN selector.
Local calls within your office using the 6 digit number are to be modified to a full national
number and routed appropriately.
TASK A.
Plan your translations on paper and discuss the results with your instructor.
TASK B.
Traver your datafill and test by dialling.
16
17
Module 10

National Calls
nortel.com/training
0
1
Datafill National Calls
Purpose
The purpose of this section is to introduce the student to the concepts of;
> National call handling, including specific Office Codes and Freephone
numbers

Datafill an exerise to handle National Calls, using the translation
selectors CONT and RTE and SETCODEC with applicable OSEL options
2
2
3
Universal Translations Datafill National Calls
from table LINEATTR
IDD PX
PSTNPXLA
Local DFLT (non-IDD)
CT OFC FA
PSTNCTLA 628FALA PSTNFALA
DFLT Route to adjacent

Route for calls SDFLT Terminate DFLT
switches
Route for calls to

rest of the world Treatment Default Route for
calls to the
rest of the country
4
Introduction
In the previous modules we have dealt with International calls and Local calls. In this
module we will deal with other National calls, including specific adjacent Office codes,
Freephone numbers and other known numbers.
In an earlier module you built routes to your partner groups, in this module you will be
screening for your partner groups within your translation system and routing the calls
accordingly.
Your Universal translation system is currently dealing with International calls within the CT
System. Local calls for your office with either a 6 figure number, or full national number are
being handled within your OFC System. All other calls are at present being sent to SDFLT
in PXHEAD.
If the call is not International or Local, it can be assumed it will be a National call.
4
Universal Translations Other
National Destinations
DFLT (non-IDD) from PX
FA
PSTNFALA
Adjacent known codes - Route to Trunks
Freephone numbers - Route to higher tandem switch for

real number resolution
Mobile numbers - Route to Mobile network
5
National Calls will be sorted within the Foreign Area (FA) System. Some calls will route
over a dedicated route, others will be passed to a Tandem switch or another carrier.
For the purposes of this module, we will look at three specific call types of national call;
Adjacent known codes
Within the FA System adjacent switch codes are screened for and calls routed via dedicated
trunks.
Freephone numbers
Freephone numbers could be dealt with in one of the following 2 ways;
1 - An Intelligent Networking (IN) platform could be used to make a
database enquiry to find the real number. Once the real directory number
has been acquired from a central database the call is re-translated using the
real DN.
2 The call is passed to a tandem switch which can handle the call.
For the purposes of this module the Freephone calls will be dealt with using method 2
above.
Mobile Operator numbers
Calls to mobile operators may need additional operations performed due to fact that the call
will be subject to codec compression within the mobile network which could add additional
delay to the call and reduce quality.
5
Adjacent known codes
Known adjacent codes can be screened within the FA system using the same technique used
in previous modules.
The following datafill example only shows the key steps. See previous modules for more
information on applicable options.
TABLE FACODE
XLANAME FROMD TOD
pstnfala 01628 01628 rte dest 162 .........................
TABLE FARTE
XLANAME RTEREF RTESEL
pstnfala 162 t ofrt 162
pstnfala 175 t ofrt 175
Freephone numbers
As previously mentioned, we will be looking at the scenario of passing Freephone calls to
another switch for handling.
As above, the following datafill example only shows the key steps.
TABLE FACODE
XLANAME FROMD TOD
TABLE FARTE
XLANAME RTEREF RTESEL
pstnfala 800 s DAN800
pstnfala 500 s DAN500
6
Mobile Operator numbers
Calls to and from mobile operators may need extra attention specifically in relation to
Codecs.
Codec Selection via Translations

The codec and packetisation rate used for a call is determined by a codec negotation process
that involves the originating and terminating media gateways and their GWCs.
The aim is that the codec used should be the codec that is highest in preference order and
supported by both gateways involved in the call. The capabilities of each media gateway are
conveyed to its GWC and to the far-end gateway in the form of an SDP (Session
Description Language) session description, and an appropriate codec is selected from the
intersection of both gateways sets of capabilities.
When GWCs and media gateways are datafilled, GWC datafill specifies a preferred codec
and packetisation rate and a default codec and packetisation rate for each subtending media
gateway.
Compression codecs such as G.729 use bandwidth more efficiently than non-compressed
codecs such as G.711. It is therefore typical for the preferred codec for a media gateway to
be a compression codec.
To ensure interoperability between different types of gateway, however, it is a Nortel
requirement that all CS 2000-controlled gateways should support G.711.
There are call scenarios in which a compression codec should not be used:
- Calls for which compression has already been performed on another leg of
the end-to-end bearer path (e.g. calls originating from a mobile network).
- Calls for which the additonal latency of using a compressed codec would
add too much of a delay (e.g. international VoIP calls).
Such scenarios cannot be determined in advance and controlled statically via datafill.
Instead, they must be identified during translations or call screening so that appropriate
action can be taken. The SETCODEC option, which can be specified at various points in the
translations process to allow a codec to be selected on the basis of call-related criteria.
7
xxCODE SETCODEC selector
The following datafill example shows the SETCODEC selector.
TABLE: FACODE
--------------------------------------------------------------------------------------------
CS2KFA 07 07 CONT (CONSUME 2) (XLT CT CTDEMO)
(SETCODEC INTL) $
The SETCODEC option specifies the CALLTYPE of the current call. This CALLTYPE is
an index into table CODEC, which in turn specifies the codec to be used for the call.
CS 2000 Core communicates this alternative codec to the GWC during call setup. It takes
precedence over the codec(s) specified in GWC datafill, and is used by the GWC during
codec negotiation.
NOTE. The SETCODEC option has the following restriction in ISN09;
The only Codec that can be selected via translations is the network default (G.711a-law or
G.711 u-law, depending on network configuration).
An example of Table CODEC follows.
TABLE: CODEC
CALLTYPE CODEC OPTIONS
---------------------------------------------------
MOBILE ( PCMA) $ $
INTL ( PCMA) $ $
The fields of Table CODEC are as follows;
CALLTYPE CODEC_KEY 8 character alphanumeric value, customer

defined.
CODEC CODEC_NAMES_VECTOR One of the following codecs;
PCMU G711mLaw
PCMA G711aLaw
Other choices are not valid at
this time.
OPTIONS CODEC_OPTION_RANGE Currently no options defined
The following pages show example Travers of National Calls.
8
Traver - National call ( different office routing via another carrier )
traver l 8795301 01753456789 b
TABLE IBNLINES
HOST 00 0 01 01 0 DT STN IBN 8795301 UNIGRP 0 0 162 $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
UNIGRP NXLA UNICT NXLA 0 NDGT
TABLE DIGCOL
TUPLE NOT FOUND
UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
162_NPRT_150 NSCR 150 NPRT NONE N $
TABLE RATEAREA
TABLE PXHEAD
PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
PSTNFALA DFLT RTE ( MM 3 11)( DEST 3)(CLASS NATL) $ DFOP(CLASS NATL)$ NOCON
STD
TABLE FACODE
TUPLE NOT FOUND
Continued overleaf
9
Traver - National call ( different office routing via another carrier ) continued
TABLE: FARTE
KEY: PSTNFALA 3
. T OFRT 628
. . TABLE OFRT
. . 628 S D NTMH4B2WNAT
. . S D NTMH4B2WLOC
. . TRMT BUSY
+++ TRAVER: TREATMENT SET +++

1 NTMH4B2WNAT 01753456789 ST
2 NTMH4B2WLOC 01753456789 ST
TREATMENT ROUTES. TREATMENT IS: BUSY

1 ENGAGED
10
Traver - 0800 call
traver l 8795301 0800234567 b
TABLE IBNLINES
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
Continued overleaf
11
Traver - 0800 call - continued
TABLE FAHEAD
PSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STD
TABLE FACODE
PSTNFALA 0800 0800 RTE ( MM 10 10) ( DEST 3)$
TABLE: FARTE
KEY: PSTNFALA 3
. T OFRT 628
. . TABLE OFRT
. . 628 S D NTMH4B2WNAT
. . S D NTMH4B2WLOC
. . TRMT BUSY

1 NTMH4B2WNAT 0800234567 ST
2 NTMH4B2WLOC 0800234567 ST

1 ENGAGED
12
Traver Mobile network call
>traver l 6105600 007345678901 b
TABLE KSETLINE
CICM 07 0 00 06 1 DN Y 6105600 EMEA_G6 0 0 207 (3WC) (PRK) (CFX) $ MBS
TABLE DNATTRS
207 610 5600
(PUBLIC ( NAME TIDS_LINE) $)$ $
TABLE DNGRPS
207 610 5600 5600
TABLE NCOS
EMEA_G6 0 0 0 $ $
EMEA_G6 NXLA EMG6CT EMG6FET 0 NDGT
TABLE DIGCOL
TABLE IBNXLA: XLANAME EMG6CT
EMG6CT 0 NET N N 1 N NDGT Y N DOD N 2 CS_NPRT CS_NIL NONE $
TABLE DIGCOL
TABLE LINEATTR
2 IBN NONE NT 0 0 NILSFC 0 PX PXDEMO NIL 00 CS_NPRT CS_NIL $
TABLE XLAPLAN
TABLE RATEAREA
13
Traver Mobile network call continued
TABLE PXHEAD
PXDEMO DFLT CONT ( CLASS NATL) ( CONSUME 0) ( XLT FA FADEMO)$ NODFOP CON STD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
FADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$
NOCON 9
TABLE FACODE
FADEMO 07 07 RTE ( MM 11 11) ( DEST 700) ( CLASS NATL) ( SETCODEC MOBILE)$
TABLE: FARTE
KEY: FADEMO 700
. S UKPVG
EXIT TABLE FARTE
1 UKPVG 07745678901 ST
SETCODEC option encountered. Codec Requested: PCMA

1 UNOBT
SETCODEC option encountered. Codec Requested: PCMA
>
14

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
15
Naming Conventions

Translation system.
Kingdom.
15
16
Universal Translations Datafill National Calls
from table LINEATTR
IDD PX
PSTNPXLA
CT OFC FA
DFLT Routes to specific

To Europe Local calls destinations
Route for calls to

rest of the world Treatment Default Route for
calls to
rest of the country
17
Exercise National Calls

Practise the use of the Cont and Rte selectors, with appropriate options, to translate through
the PX and FA XLASYS.
Translate National calls.

Use the routes previously datafilled in Route Exercise A which point to your partner trunks
datafilled in the Trunk Group Exercise.

National calls to your partner groups are to route to the dedicated trunks previously
established between you.
Freephone calls 0800xxxxxx route to the CLLI DAN800
Mobile Operator calls 07xxxxxxxxx to route to the CLLI MOBILE
All other national numbers are to route to OFRT (For CLLI DANNAT)
17
TASK A.
TASK B.
Hint.
You will need to change the DFLT action in your existing PX HEAD table.
Take care with the Min Max checks.
TASK C.
Revisit the International Calls exercise and include the SETCODEC option for all calls.
A flow chart depicting the exercise requirements is included on the previous page.
18
19
Module 11
Time Of Day Routing
nortel.com/training
0
1
Module 11 Time Of Day Routing
Purpose
concepts of;
> The Time of Day Route System feature.

> Describe the purpose of the Time of Day system.
> List the tables used by Time of Day system.
> Complete an exercise using Time of Day Routing.
2
2
3
Introduction
Time of Day Routing.
The Time of Day Routing system allow the user to alter route choices based on the time of
day. The Time of Day system is accessed from the Route tables IBNRTE, OFRT or OVRx
using the conditional selector CND TOD.
Table IBNRTE, 2, 3,4. Ibn Route

Table OFRT, 2,3,4. Office Route
Table OVR0 OVR89 Overseas Routing
The Time of Day tables allows changes to routing choices during specific times of the day,
week or year.
This may be for route changes to occur at specific times to overcome congestion during
busy periods.
Once built, the changes will occur automatically unless overridden. The Time of Day
system uses five tables to establish the times when changes are to occur, they are:-
Table DAYTYPES Type of Day

Table DAYOWEEK Day of Week
Table DAYOYEAR Day of Year
Table TODHEAD Time of Day Head
Table TIMEODAY Time of Day
These tables will be discussed first.
4
Table DAYTYPES
Table DAYTYPES
DAYTYPE
---------------
HOLIDAY
WEEKEND
WEEKDAY
SPARE1
SPARE2
SPARE3
SPARE4
SPARE5
MONDAY
TUESDAY
WEDNESDAY
THURSDAY
FRIDAY
5
Table DAYTYPES
The CS2000 knows the real time and date from its internal clock. It does not know the
names of days that you wish to use in some of the Time of Day tables. The Type of Day
(DAYTYPES) table defines the names of all the days required for time of day changes.
Obvious examples of DAYTYPES include the names MONDAY, TUESDAY, WEEKDAY
etc. There may be special daytypes defined for use in a Time of Day system e.g. SPARE1,
SPARE2, HOLIDAY etc. A DAYTYPE must be entered in this table before it can be used
in any of the Time of Day tables.
N.B. You cannot Change entries in table DAYTYPES, you can only Delete and Add. Once
a DAYTYPE has been added to this table it may be used in any of the Time of Day systems.
An example is given above.
5
Table TODHEAD
Table TODHEAD
TODNAME TODTYPE TIME DAYTYPES
demotod rte 0 (holiday)(weekday)(weekend)
(spare1) (spare2) (spare3) (xmas)
6
Table TODHEAD
In table TODHEAD, the TODTYPE field is RTE (Route), and a field specifies the default
action. An example is given above.
The fields are:-

TODNAME Time of Day Name. Enter a 1 to 8 character name assigned as the time of day
system name. This name is used in the Route tables with the Conditional
selector CND TOD.
TODTYPE Time of day type. Enter RTE to indicate that this is a ROUTE time of day
system.
TIME Times. Enter the Time element alphanumeric ( 1 to 14 ) characters from
which applies if there are no instructions for the current time and daytype in
table TIMEODAY.
DAYTYPES Types of day. Enter the daytypes on which changes are to occur. Up to 32
different daytypes may be listed here. It is advised that some extra
daytypes are included in the list to allow for future growth or changes. The
daytypes SPARE1, SPARE2 etc. are often used for this purpose.
N.B. Existing DAYTYPE names can be changed, however, the CHANGE
command cannot be used to add new daytypes not previously included in
the list.
Remember! Daytypes must be defined in Table DAYTYPES first.
6
Table DAYOWEEK
Table DAYOWEEK
TODNAME WEEKDAY DAYTYPE
demotod mon weekday
demotod tue weekday
demotod wed weekday
demotod thu weekday
demotod fri weekday
demotod sat weekend
demotod sun weekend
7
Table DAYOWEEK
Table Day of Week (DAYOWEEK) is used to associate real days with the DAYTYPES
defined in table DAYTYPES. The entries in this table are specific to a Time of Day system
which means that a real Monday could be known as different DAYTYPES in different
Time of Day systems. An example is given below.
In this example, the real day, MONDAY (MON), is associated with the daytype weekday.
REAL Friday (FRI), will be known as HOLIDAY and SATURDAY (SAT) will be known
as WEEKEND, but only in the DEMOTOD time of day system. The fields are:-
TODNAME Time of day name.Enter the 1 to 8 character name assigned as the time of
day system name to which entries in this table are linked.
DAY Weekday. Enter the real name of a day of the week. Only 3 characters are
used in this field e.g. MON,TUE,WED,THU,FRI,SAT or SUN.
DAYTYPE Type of Day. Enter the 1to 8 character name assigned as a DAYTYPE which
the real day will be known as in the Time of Day system.
7
Table DAYOYEAR
Table DAYOEAR
TODNAME MONTH DAY DAYTYPE
demotod dec 25 xmas
demotod jan 01 holiday
8
Table DAYOYEAR
The Day of Year (DAYOYEAR) table defines any special days of the year on which
something happens other than what would happen on their normal DAYTYPE. For
example, in the tuples used to illustrate the Time of Day tables, Monday is known as a
Weekday and may have Time of Day instructions applying to it. However, if it was
MONDAY December the 25th, we may wish to apply a different set of instructions for that
special day e.g. XMAS. This may be achieved by using the DAYOYEAR table. Entries in
table DAYOYEAR are specific to a Time of Day system. The rule is, Table DAYOYEAR
entries override DAYOWEEK entries.
An example is given above.
In this example, December 25th is assigned the DAYTYPE xmas in the demotod Time of
day system. The fields are:-
TODNAME Time of Day name. Enter the 1 to 8 character name assigned to the Time of
Day system.
MONTH Month. Enter the month to which this entry applies. Months use 3 letters in
this field e.g. JAN,FEB,MAR,APR etc.
DAY Day. Enter the day of the month to which this entry applies. Days are referred
to by the date i.e. a number from 1 to 31.
DAYTYPE Type of Day. Enter the 1 to 8 character name assigned as a DAYTYPE
which the real day will be known as in the Time of Day system.
8
Table TIMEODAY
Table TIMEODAY
TODNAME DAYTYPE TIME DATA
demotod weekday 00 00 rte 1
9
Table TIMEODAY
The Time of Day (TIMODAY) table defines the results for a given time and day. The result
is the time element number that applies on a specific time and day.The time element is used
in the route tables with the conditional selector CND TOD. If the condition applies i.e. it is
the current time and day specified, the condition will be applied. If it is not, the condition is
ignored and normal route selection continues. A day covers a 24 hour period between 00:00
and 23:59. A maximum of 16 changes (0-9, A-F) can be specified in one 24 hour period i.e.
a day. To illustrate this, consider a customer who wants to implement some route changes
during the daytype HOLIDAY.
The Time of Day Routing System is to apply route changes between 00:00 to 08:00, 08:00
to 12:00 and 12:00 to 23:59. The changes can be represented in a chart, an example is given
below.
00:00 08:00 12:00 23:59
< Time Rte 1 >< Time Rte 2 >< Time Rte 1 >
Table TIMEODAY would be datafilled as per the above slide to match the time chart above
In this example, the DEMOTOD time of day system points to time element numbers as the
Result for a given time and daytype. The time element numbers are used in the route tables
with the conditional selector CND TOD.
The route tables must now be considered. The conditional selector was described in the
Route Tables module and an example is repeated on the following page.
9
Routing Table Conditional Selector -
TOD
TABLE IBNRTE
RTE IBNRTSEL CNDSEL TODNAME TIMES RTETYPE RTEREF
300 cnd tod demotod 2 st 301
IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUM
cnd tod demotod 1 sk 1
IBNRTSEL EXTRTEID
t ibnrte 300
10
In this example, the conditional selector TOD (time of day), is used. If the condition is met,
i.e. it is time element 2, calls will route to ibnrte 301. If the condition does not apply, normal
ARS occurs and the conditional element is ignored. The next route element is tried. If the
condition applies, calls will skip 1 route element and pass on to the next. If the condition
does not apply, normal ARS occurs and the conditional element is ignored. The next route
element is tried.
The Time of Day parameters are set in the Time of Day system tables using Time of Day
system name DEMOTOD. The final element in this list will route calls to IBNRTE 300 if
there are no available trunks in the specified trunk groups.
10
Time of Day Route Tables
Table DAYTYPES Table DAYOWEEK Table DAYOYEAR
TODNAME MONTH DAY DAYTYPE
DAYTYPES
TODNAME DAY DAYTYPE
MONDAY DEMOTOD DEC 25 XMAS
WEEKEND DEMOTOD MON WEEKDAY
WEEKDAY DEMOTOD FRI HOLIDAY
HOLIDAY DEMOTOD SAT WEEKEND
XMAS
Table TODHEAD
TODHEAD TODTYPE TIMES DAYTYPES
DEMOTOD RTE 0 (WEEKDAY) (WEEKEND)(XMAS)(HOLIDAY)(SPARE1)
Table TIMEODAY
TODNAME DAYTYPE HOUR MIN TODTYPE TIME 00:00 08:00 12:00 23:59
DEMOTOD HOLIDAY 00 00 RTE 1
DEMOTOD HOLIDAY 08 00 RTE 2 Time Rte 1 Time Rte 2 Time Rte 1
DEMOTOD HOLIDAY 12 00 RTE 1
Table IBNRTE
RTE IBNRTSEL CNDSEL TODNAME TIMES RTETYPE RTEREF
holiday
201 CND TOD DEMOTOD 2 ST 301
IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUM
CND TOD DEMOTOD 1 SK 1
IBNRTSEL EXTRTEID
t ibnrte 300
11
11
Time of Day Query System.
The Time of Day Query system allows users to query the results of the Time of Day
systems. It also allows the user to override the current result, disable and restart Time of
Day systems. The Time of Day Query system is accessed from the CI prompt by entering
the command TDQ. Help is available by entering TDQ Help. The HELP command lists the
TDQ commands and describes their purpose. An example is given below.
tdq help
TDQ: The query and override command for the Time-Of-Day and Day-Of-Week/Year
feature system.
Valid parameters: [xxx] indicates xxx is optional no parameters gives the status display
HELP: This Display.
ALL: Current results for all TODNAMES.
NAME: Current result for specified TODNAME.
LIST: List of all TIMEODAY entries (time ordered) with some extra information
displayed for each.
TRAPS: Gives the number of traps since the last non-warm or manual restart.
TEST: Gives the ALL display after making a few tests.
THRESHOLDS: Used to reset the TRAP thresholds for the SYSTEM, FEATURES,
TODNAMES. (If these thresholds are exceeded, the system commits suicide.)
DISABLE [todname]: Disable the whole TOD system, or just for the given TODNAME.
TODRESET: [todname]: Restart the whole TOD system, or just for the given TODNAME.
OVERRIDE: Override the scheduled result for a given TODNAME with a manually
specified result.
FEATURE: Turn the specified feature on, off, or off permanently (i.e. not enabled by
restarts.) (Manually Disable a feature causing problems/ traps or enable a Disabled
Feature.)
12
Datafill Order
It is very important that the correct datafill order is applied to the Time of Day tables.
The datafill order is given in the following list.
DAYTYPES
TODHEAD
DAYOWEEK
DAYOYEAR
TIMEODAY
13
14

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
15
Naming Conventions

Translation system.
Kingdom.
15
Time-Of-Day Routing
from table LINEATTR
IDD PX
PSTNPXLA
CT OFC FA

Route for calls to Time Of Day

rest of the world Treatment Default Route for Routing Tables
calls to
Route A
rest of the country
16 Route B
Time Of Day Routing Exercise

Review the Time of Day and Route tables.
Datafill a Time of Day Rte system.
Exercise requirements.
Build a new Time of Day system for use with your existing route list. At a specified time
and day, calls over your trunks to your partner groups are to use the second choice trunk
group only. At all other times, routing should be as normal i.e. all route elements can be
used.
Your Instructor will give you the specified times and day.
Start time ________________ End time _______________
Traver the results of making calls when normal routing is in place and when the Time of
Day system applies.
Use the TDQ system to check your results.
PLAN ON PAPER FIRST. IF IN DOUBT PLEASE ASK.

Do not apply your datafill until you have discussed it with your instructor.
16
17
17
Module 12
Universal Translations Service

Calls
nortel.com/training
0
1
Service Calls
Purpose
concepts of;
> Handling of Service calls, i.e. Operator and Emergency calls.

> Describe the call flow process used in Universal Translations
> Datafill an exercise to handle Service Calls, using the
translation selectors DMOD, CONT and RTE with applicable
OSEL options
> Traver the results of their datafill
> Explain the results of the travers
2
2
3
Service Calls
from table LINEATTR
IDD PX Service PX
PSTNPXLA SRVCPXLA
SDFLT
CT OFC FA
PSTNCTLA 628FALA PSTNFALA Treatment


calls to
rest of the country Route A
4 Route B
Introduction
This module will deal with Service calls, i.e. Operator, Emergency and 151 calls.
Service calls can be filtered out in the PX system and dealt at the earliest opportunity, to
reduce the risk of losing Emergency Service due to data entry errors.
Alternatively, the calls may be routed to a service bureau of another Network Service
provider.
This module will deal with the 2nd scenario, as previous exercises have covered the datafill
procedures to accomplish the 1st scenario.
Datafill example - Emergency and Operator calls
The examples given here will show the use of the DMOD option to delete and insert digits.
It is sometimes the case that 999 and 1xx calls have an exchange I.D.code inserted to enable
operators to identify the originating office. The I.D. is particularly important where these
calls terminate on an emergency or operator bureau of another licensed network provider.
Another common requirement is that 151 calls (faults), terminate on the local service
providers customer service desk. In this case, 151 is modified to give the service desk
number.
The translation requirements can be represented as a flow diagram and an example is given
above.
4
Traver examples
The tables required to achieve the call scenarios depicted by the flow chart on page 1 will
not be seperatly listed here. They are similar to previous examples and can be clearly seen
in traver examples.The 999 call traver shows the translation passing through the screening
table PSTNPXLA as before. Further screening in the PX XLASYS, translator name
SRVCPXLA, allows for digit modification prior to final translation in the FA XLASYS,
translator name PSTNFALA.
Note the following entries:-
Table PXCODE, srvcpxla 999 999, uses dmod to insert i.d number 12.
Table PXCODE, srvcpxla 100 100, uses dmod to insert i.d number 12.
Table PXCODE, srvcpxla 112 112, uses dmod to change the digits to 99912.
Table PXCODE, srvcpxla 151 151, uses dmod to change the digits into a local service desk
number.
The travers will also show that the FA XLASYS is used to translate all the remaining calls.
Remember, local and international calls have already been dealt with in the CT and OFC
XLASYS. The FACODE table is used to list codes of specific interest only.
Examples are Emergency and Operator numbers, Freephone and other 10 digit numbers
requiring separate min max checks. All non listed codes use the DFLT action in the
FAHEAD table to route calls to destinations in the FARTE table. The FARTE table will
point calls to trunks connecting to other network operators or tandem switching centres.
Note the following special entry in the FACODE table:-
Table FACODE, pstnfala 99912 99912,uses the option CALLCTRL to give control of the
call to the emergency operator.
The option AMAXLAID is used to give the trigger for billing. The entry for amaxlaid
points to a reference, 999AMA, in table AMAXLAID where the requirements are defined.
The option is required because CLASS EMERG does not have a billing trigger, however, it
is required to set a BTUP flag signifying alternate routing is allowed.
The following travers give examples of calls to 999,112, 100 and 151.
5
6
Traver - 999 call
traver l 8795301 999 b
TABLE IBNLINES
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
7
TABLE PXHEAD
TABLE PXCODE
PSTNPXLA 999 999 CONT ( XLT PX SRVCPXLA)$
TABLE PXHEAD
SRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STD
TABLE PXCODE
SRVCPXLA 999 999 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$
TABLE FAHEAD
TABLE FACODE
PSTNFALA 99912 99912 RTE ( MM 5 5) ( DEST 1) ( CLASS EMRG) (CALLCTRL CALLED)
(AMAXLAID 999AMA)$
TABLE: FARTE
KEY: PSTNFALA 1
. T OFRT 999
. . TABLE OFRT
. . 999 S D NTMH4B2WEMG
. . S D NTMH4B2WLOC
. . TRMT BUSY
1 NTMH4B2WEMG 99912 ST
1 ENGAGED
8
Traver - 112 call
traver l 8795301 112 b
TABLE IBNLINES
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
9
TABLE PXHEAD
TABLE PXCODE
PSTNPXLA 112 112 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$
TABLE PXHEAD
TABLE PXCODE
SRVCPXLA 112 112 DMOD ( DEL 3) ( INSRT 99912) ( XLT FA PSTNFALA)$
TABLE FAHEAD
TABLE FACODE
PSTNFALA 99912 99912 RTE ( MM 5 5) ( DEST 1) ( CLASS EMRG) (CALLCTRL CALLED)
(AMAXLAID 999AMA)$
TABLE: FARTE
KEY: PSTNFALA 1
. T OFRT 999
. . TABLE OFRT
. . S D NTMH4B2WLOC
. . TRMT BUSY
10
Traver - 100 call
traver l 8795301 100 b
TABLE IBNLINES
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
11
TABLE PXHEAD
TABLE PXCODE
PSTNPXLA 100 100 CONT ( XLT PX SRVCPXLA)$
TABLE PXHEAD
TABLE PXCODE
SRVCPXLA 100 100 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$
TABLE FAHEAD
TABLE FACODE
PSTNFALA 10012 10012 RTE ( MM 5 5) ( DEST 1)$
TABLE: FARTE
KEY: PSTNFALA 1
. T OFRT 999
. . TABLE OFRT
. . S D NTMH4B2WLOC
. . TRMT BUSY
12
Traver - 151 call
traver l 8795301 151 b
TABLE IBNLINES
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE IBNFEAT
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
UNIGRP 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
13
TABLE PXHEAD
TABLE PXCODE
PSTNPXLA 151 151 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$
TABLE PXHEAD
TABLE PXCODE
SRVCPXLA 151 151 DMOD ( DEL 3) ( INSRT 01628795616) ( XLT PX PSTNPXLA)$
TABLE PXHEAD
TABLE PXCODE
PSTNPXLA 0162879 0162879 CONT ( XLT OFC 6287FLA) ( CONSUME 7)$
TABLE OFCHEAD
6287FLA DFLT RTE ( MM 4 4) ( DEST 1) ( CLASS NATL)$ DFOP ( CLASS NATL)$ NOCON
STD
TABLE OFCCODE
TUPLE NOT FOUND
TABLE: OFCRTE
KEY: 6287FLA 1
. T IBNRTE 79
. . TABLE IBNRTE
. . 79 DN 162 879 N 0
EXIT TABLE OFCRTE
1 LINE 1628795616 ST
1 GNCT
14
15

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
16
Naming Conventions

Translation system.
Kingdom.
16
17
Service Calls - Exercise
Practise the use of the Cont ,Rte and Dmod selectors, with appropriate options, to translate
through the PX and FA XLASYS.
Translate Emergency and Operator assistance calls.
999 calls are to be modified to include the office I.D.code 29 and route to OFRT 999.
112 calls are to be modified into 999 calls with office I.D. code 29 and route to OFRT 999.
100 calls are to be modified to include the office I.D. code 29 and route to IBNRTE 100.
151 calls are to be modified and directed to your Business set directory number.
TASK A.
TASK B.
Note.
Point the 100 call to IBNRTE 100 and change the tuple to point to CLLI DAN100.
Point the 999 call to OFRT 999 and change the tuple to point to CLLI DAN999.
AMAXLAID 999AMA already exists.
Hint.
Do not forget to include all the appropriate options for emergency calls.
A flowchart depicting the exercise translation requirements is include over the page.
18
Service Calls
from table LINEATTR
IDD PX Service PX
PSTNPXLA SRVCPXLA
SDFLT
CT OFC FA
PSTNCTLA 628FALA PSTNFALA Treatment
DFLT Route to adjacent

To Europe Local calls switches

calls to
rest of the country Route A
19 Route B
19
20
Module 13
Universal Translations Indirect

Access
nortel.com/training
0
1
Indirect Access
Purpose
The purpose of this module is to introduce the student to the
concepts of;
> Indirect Access.
After this module of instruction, you will be able to:

> Identify the purpose of Indirect Access.
> Identify the different types of Indirect Access.
> Demonstrate datafill by completing specified exercises for
Indirect Access.
2
2
3
The Purpose of Indirect Access
Indirect access services enable alternative national operators to provide long-distance
carrier capability in competition with the PTT (or its privatised successor). Such operators
can thus compete with the PTT, by guaranteeing lower long-distance charges for both
business customers and residential subscribers, and by making value-added services
available. Indirect access is therefore extremely important in enabling alternative national
operators to establish themselves in deregulated telecommunications markets.
Indirect access is based on the principle that subscribers attached to the PTT network can
explicitly request access to the alternative operators network for the completion of their
calls. Because subscribers use existing physical connections, the alternative operator does
not have to create a complete access network.
Indirect access differs from simple network interconnect because extra call processing is
required for the following purposes:
To verify that callers attempting to access the network are authorised to do so
To ensure that the operator of the alternative network receives

appropriate revenues from calls routed through it on request.
Indirect access can also be used to enable roaming or remote users to dial in to a corporate
VPN and have free or low-cost access to its standard world-wide dial plan.
To complement trunks used to support indirect access, alternative national operators use
network interconnect trunks for calls where authorisation checks are not required, e.g. calls
originating in the alternative network and terminating in the PTT network. The following
pages describes possible call completion scenarios, and indicates whether indirect access
and/or network interconnect is used in each case.
Network interconnect trunks are also used by alternative local operators, typically cable TV
companies, who provide direct line and PBX connections for residential and business
subscribers in competition with the PTT. Such operators must support access to a national
long-distance network for their customers, and for this purpose they negotiate bilateral
network interconnect agreements with national operators. Such local operators do not
require indirect access services, and their use of interconnects is outside the scope of this
chapter.
4
Call Completion Scenarios
Network A
Default network, e.g. PTT
Call routed
to B only if Transit Terminating
requested switch switch
Call Call
origination termination
Default ingress
Requested Egress for calls
typically for calls
ingress with terminating to
terminating
authorisation network A lines
within network B
checks
Media Media
Gateway Gateway
CS2000 CS2000
Media Media
Gateway Gateway
Call Network B
Call
origination Alternative national operator termination
using IP or ATM packet backbone
5
The above figure illustrates possible call completion scenarios for an alternative national
operator using CS2000 indirect access capabilities to compete with the established PTT.
The scenario illustrated in the above figure and described overleaf assumes that the
equipment belonging to a given alternative network operator is dedicated to carrying that
operators traffic and generating revenue for that operator. In some regulatory regimes,
however, it is possible for a network operator to set up a virtual network, without
equipment, by buying capacity from other operators and reselling it. CS2000s deployed in
such a regulatory regime must be able to support carrier selection, as described later in this
module, even if they are only providing transit functionality.
Note: It is also possible to support indirect access as an IN (Intelligent Network) service. In
this case, a database of user details and authorisation information is maintained centrally by
an SCP, and CS2000 initiates an IN query to the SCP when it recognises an incoming
indirect access call.
5
Simple Scenarios: Indirect Access Involving One AO
For the simple network configuration illustrated previously, the following list describes
each call completion scenario in turn, indicating in each case whether it involves indirect
access and/or network interconnect. Beginning with the most complex and important, the
scenarios are as follows:
Call originated on default national network.
o Caller requests routing via alternative network.
o Call routed directly into alternative network on ingress interconnect, to CS2000
that checks authorisation and performs call routing.
o If call needs to leave alternative network to reach termination, it does so on
egress interconnect to PSTN switch serving terminating line.
o Alternative network performs billing and receives most call revenue.
This is the key scenario for indirect access, involving extra signalling
over the ingress interconnect trunk to allow caller authorisation to be
checked; there is no extra signalling over the egress interconnect trunk.
Call originated on default national network.
o No specific routing request, so call routed through default network.
o Call needs to enter alternative network to reach termination (e.g. PBX directly
connected to AO network media gateway), and is eventually routed into
alternative network on ingress interconnect, to CS2000 serving called party.
o Default national network performs billing and receives most call revenue.
There is no extra signalling over this type of ingress interconnect trunk.
Call originated on alternative network and routed through it.
o Call needs to leave alternative network to reach termination, and does so on
egress interconnect to PSTN switch serving terminating line.
o Alternative network performs billing and receives most call revenue.
There is no extra signalling over the egress interconnect trunk.
6
Different types of Indirect Access
Table CLI Initial Further Main

Access method 2nd
Used Checked? information information advantage
tone?
provided provided
Access code Speed/convenience

Single- No
Yes + destination N/A for voice calls;
stage DNSCRN
number support for data calls
Carrier Carrier ID Speed/convenience

selection DNSCRN Yes + destination No N/A for voice calls;
CLI_ screening number support for data calls
based
access Account Account code Account code billing
code DNSCRN Yes Access code Yes + destination for business customers
required number
MONA via Destination Confirmation of access
ambiguous DNSCRN Yes Access code Yes number [1] to alternative network
translations
Authorisation
Authcode No Access code Yes code + Support for roaming access;
AUTHCDE
access destination more powerful screening
number [2]
[1] The MONA feature can be set up to collect additional information, e.g. authorisation code and/or account code.
[2] Optional PIN and/or account code can also be collected between the authorisation code and the destination number.
7
Different Types of Indirect Access

CS2000 supports a number of different types of indirect access. These can be categorised on
the basis of the following criteria:
Whether access is authorised on the basis of the callers Calling Line Identification (CLI)
or on the basis of an explicitly dialled authorisation code (authcode).
Which items of information have to be provided by the caller.
How the caller is prompted to provide information.
A caller is prompted to provide additional information by the playing of a tone. For TDM-
side access, tones are applied in-band to the incoming TDM-side bearer channel by the
originating media gateway.
Note: In ISN09, it is not possible for indirect access services to prompt the user for
additional information by means of announcements provided by a media server.
In both cases, additional information provided by a caller when prompted is collected as in-
band DTMF digits. These are collected by the originating media gateway (or via a TDM-
side looparound), and H.248 is then used to pass the information on to the GWC.
Note: The types of screening described above can be complemented by standard COS
screening on a trunk group basis, as follows:
TRKOPTS option COS can specify a COS value (0-1023) for a trunk group.
Table COSBLK specifies combinations of orginating trunk group COS and terminating
trunk group COS for which call completion will be permitted.
7
Indirect Access Screening Options
Three types of CLI-based indirect access have been defined. One of these is a single-stage
process; the others are refinements in which further information is collected after the CLI
has been checked. They are:
Single-stage CLI-based access
Single-stage access is so called because the calling party provides the
access code and destination number by means of a single operation, and
need not provide any further information.
Note: This is the only type of indirect access that can support data calls,
because it is the only one that requires no in-band interaction with the
caller.
Account code required
With this method, the DNSCRN table entry for the callers CLI specifies
that an account code must be provided as well as the destination
number.
Meridian Off-Net Access (MONA) via ambiguous translations
With this method, the caller initially dials only the access code, which
permits the CLI to be checked. Translations then activates MONA,
which provides a second dial tone and collects destination digits.
MONA can also be set up to collect other information, e.g. an
authorisation code and/or account code.
Access is authorised on the basis of the CLI, which is automatically provided by the
originating switch, either by default or in response to a request from the ingress CS2000; no
action is required from the calling party. Calls that fail CLI screening are routed to "VPN
Service Not Allowed" treatment.
Note: CLI-based access can be supported only if the calling party address is available, i.e. if
no analogue switches have been encountered before the call reaches the ingress CS2000. If
the originating switch is unable to provide the CLI because interworking has occurred, this
will be indicated in the first call setup message, and CS2000 will route the call to treatment.
8
Indirect Access
CLI based Single stage
Table LINEATTR
PXCODE
CLI
screening
XLASYS FROMD TOD XLASEL FTR XLASYS XLANAME
check
cs2kpx 0901 0901 featinfo validate px2 cs2kpx
VALDATOP
SUBSCRN Check for CLI in DNSCRN
Pass screening
Continue
translating
9
CLI Triggers in Universal Translations

The screening function is triggered by the XLASEL selector FEATINFO in the universal
translation tables.
Enter FEATINFO and datafill its sub-option VALIDATE to trigger the screening function.
Selector FEATINFO makes use of table DNSCRN to store information against DNs, which
is used during call processing to determine how to proceed with the call.
As shown in the above example the FTR option of VALIDATE enables screening via sub-
options.
For CLI screening to occur the SUBSCRN sub-option is used.
CLI screening will be dealt with first using the FEATINFO/VALIDATE/SUBSCRN sub-
option.
There are other Sub-Options available for the VALIDATE option, which include;
BCSCRN identifies Bearer Capability.
CLDTOCLG copies digits from the calling to the called digit stream.
CLISERV The CLISERV field indicates the name of the CLI Screening Services index
in Table CLISERV.
CUSTMOD alters the NCOS and Customer Group to a new value for a given DN
based on the CUSTINFO attributes in table DNSCRN.
For this module however we will only be dealing with the two CLI related options;
FEATINFO/VALIDATE SUBSCRN
FEATINFO/VALIDATE - CLISERV.
9
FEATINFO option VALIDATE - SUBSCRN
xxCODE

cs2kpx 0901 0901 featinfo validate px2 cs2kpx
VALDATOP SUBSCTYP WHITLIST CHKUNPD CHBLKCL CHKCCR

subscrn general N N Y N
SUBSCTYP
$
VALDATOP
$
PFDIGS MINDIGS MAXDIGS Continue
0 11 11 translating
Table DNSCRN
DN ATTROPTS
01182345678 (UNPAID) (BLCKCALL) $
10
FEATINFO option VALIDATE, Sub-option SUBSCRN

SUBSCRN allows screening of 3 of the following 4 subscriber types;
GENERAL,
PAYPHONE,
PERSONAL,
MOBILE.
Within these subscriber types, the following information is datafilled;
Enter subscriber type, followed by a space, and datafill refinements
WHITLIST, CHKBLKCL, CHKUNPD, and CHKCCR.
WHITLIST Y or N Whether it is a white or Black list. Enter Y (yes) to indicate that

the subscribers directory number must be datafilled in table DNSCRN
i.e. a WHITELIST.
Otherwise, enter N (no) indicating that the screening is a BLACKLIST
and only CLIs that need screening are entered.
CHKBLKCL Y or N Check block call. Enter Y to check if the subscriber has
subscribed to all services for which this tuple is being used (BLKCALL
attribute in table DNSCRN). Otherwise, enter N.
CHKUNPD Y or N Check unpaid. Enter Y to check if the subscriber has paid his
bills. Otherwise, enter N.
10
CHKCCR Y or N Check cumulative call restriction. Enter Y to check the
subscribers cumulative charge limit. Otherwise, enter N.
PFDIGS 0 to 24 Prefix digits. Enter the number of prefix digits present at this
point in the call. Prefix digits are not used to index any further
translation tables and are not outpulsed, but they remain stored in call
detail records (CDR).
MINDIGS 0 to 30 Minimum digits. Enter the minimum number of digits expected.
This value includes the digits used to index the current tuple and must
also include the prefix digits specified in the current tuple.
MAXDIGS 0 to 30 Maximum digits. Enter the maximum number of digits expected.
This value includes the digits used to index the current tuple and and
must also include the prefix digits specified in the current tuple.
TABREF see subfields Table reference. This field consists of subfields XLASYS
and XLANAME.
White List v Black list.

A White List is a CLI screening list where the CLI MUST be entered or the call will fail i.e.
the CLI must match an entry in Table DNSCRN for the call processing to continue. With
this feature a call can subsequently be failed or other actions taken as a result of further
datafill, if required.
A Black List is a CLI screening list where a CLI that matches will cause the call processing
to stop i.e. the call will Fail. So a CLI that does NOT match will continue call processing
through translations.
11
Table DNSCRN
The fields within this table are as follows
DN ATTROPTS
Within table DNSCRN, numerous attributes can be used as a screening basis.

Some are listed below;
UNPAID Check unpaid. Enter Y to check if the subscribers bills are paid. For
other conditions, enter N.
BLCKCALL indicates that the DN cannot make or receive calls.
CLISERV allows the use of CLI service screening and CLI based routing
An example tuple is shown below.

TABLE: DNSCRN
DN ATTROPTS
----------------------------------------------------------------------------
1628795352 ( UNPAID ) ( BLCKCALL ) $
In this datafill example the specified CLI has not paid their bill and are blocked from
making or receiving calls.
Use of Multiple DNSCRN Tables

It is possible to define and use more than one DNSCRN table, as follows:
Additional tables DNSCRN2 to DNSCRN7 can be used to increase the capacity of
the screening database.
The DNSCRNx tables to use in screening a call can be selected on the basis of the
type of number to be screened, as indicated by its NOA (or equivalent).
Use of these enhancements is controlled via table DNSCRMAP, each entry in which
comprises the following:
Number type (SUB, NAT, INTL or UNKN)
Note: These are the possible values of an ISUP NOA. For other protocols, mapping is
performed to determine an appropriate NOA value.
List of tables to be used in screening numbers of this type (DNSCRN or DNSCRNx)
Index into table DIGMAN (optional), if digit manipulation is to be performed before
screening
Table DNSCRMAP is accessed via table CLISERV.
Note: Access to table DNSCRMAP is restricted to calls where the screening number has an
NPI of E164. For all other calls, only table DNSCRN will be used for screening.
12
FEATINFO option VALIDATE - CLISERV
xxCODE

cs2kfa 0901 0901 featinfo validate fa2 cs2kfa
fa scrnfail
VALDATOP SUBSCTYP WHITLIST CHKUNPD CHBLKCL CHKCCR

SUBSCRN GENERAL N N Y N
SUBSCTYP
$
VALDATOP SERVNAME
CLISERV CLIDEMO
VALDATOP
$ Continue
PFDIGS MINDIGS MAXDIGS translating
0 11 11
Fail
Table CLISERV Screening
SERVNAME SERVNUM SERVOPTS

CLIDEMO 2 ( PARTIAL ) ( FAILAMA ) ( SERVAMA ) ( FAILRTE FA SCRNFAIL ) $
13
FEATINFO option VALIDATE, Sub-option CLISERV

The FEATINFO/VALDATOP of CLISERV allows the datafill of an index into the CLI
Screening Services table CLISERV.
This table has the following fields;
SERVNAME 8 character unique name index
SERVNUM 0-32766 numeric. Service number to be used by billing as part
of the CLI Screening information.
SERVOPTS A combination of up to 5 of the following;
PARTIAL Allows the screening of partial CLIs in
DNSCRN.
FAILRTE Specifies a Universal Translations system to
handle calls which failed screening.
FAILAMA This option provides the ability to trigger an
AMA record and capture CLI Screening
information for calls that fail screening. *
Without this option, generation of an AMA
record is not guaranteed.
SERVAMA This option provides the ability to capture CLI
Screening information if an AMA record is
produced for calls that fail or pass screening.*
This option does not generate an AMA record
on its own.
* A warning is generated when datafilling these options as a reminder of the implications on
billing.
13
Table CLISERV SERVOPTS continued.
SERVSCRN This option provides the ability to fail

screening if the CLI has not subscribed to the
CLI Screening service. In order for screening
to succeed, the CLI matched in table
DNSCRN must have the CLISERV option
present indicating the CLI Screening profile,
PROFIDX, to be used. A SERVNAME listed
against the PROFIDX in table CLISRVPF
must also match the SERVNAME provided in
the CLISERV option of the FEATINFO
VALIDATE selector encountered in Universal
translations.
DNSCRMAP This option enables screening based on the
NOA parameter.
CLICNTL This option enables the use of table CLICNTL
to select the address to screen and the
address to capture in the AMA billing record.
ACCTREQ ACCTREQ is request for account code
collection and validation. This field specifies
that a CLI must collect cost center code (CCC)
digits. Enter data in subfields ACCTLEN,
ACCTTONE and ACCTVAL.
14
TRAVER to a CLI Screened number with CLI listed in DNSCRN.
>traver l 8885000 0898123456 b
TABLE KSETLINE
RM05 00 0 02 17 1 DN Y 8885000 BOB 0 0 111 (LNR) $ MBS
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE NCOS
BOB 0 0 0 CLASS $
AND DIGCOL
BOB NXLA BOBCT NXLA 0 NDGT
TABLE DIGCOL
TABLE IBNXLA: XLANAME BOBCT
TUPLE NOT FOUND
BOBCT
(NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $)
$9
TABLE DIGCOL
TABLE LINEATTR
DANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA NIL 00 162_NPRT_4
NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
BOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
BOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11)
(CLASS NATL) $ CON 9
TABLE FACODE
BOBFALA 0898 0898 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y Y N N) $)
$ 0 10 10 FA VALIDXLA
PLEASE ENTER CLI DIGITS:
>1118885000
TABLE DNSCRN
. 1118885000 $
15
TABLE FAHEAD
VALIDXLA SDFLT NODFOP NOCON 9
TABLE FACODE
VALIDXLA 1 1 RTE ( DEST 5)$
TABLE: FARTE
KEY: VALIDXLA 5
. S NTEDILONBTUP
EXIT TABLE FARTE
1 NTEDILONBTUP 0898123456 ST
1 GNCT
16
TRAVER of a call with a CLI that does not exist in Table DNSCRN
>traver l 8885555 0898123456 b
TABLE KSETLINE
RM05 00 0 02 18 1 DN Y 8885555 BOB 0 0 111 (LNR) $ MBS
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE NCOS
BOB 0 0 0 CLASS $
AND DIGCOL
TABLE DIGCOL
TUPLE NOT FOUND
BOBCT
$9
TABLE DIGCOL
TABLE LINEATTR
NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
TABLE FACODE
>1234567890
TABLE DNSCRN
. No match found
17
. Screening failed
TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLED
TREATMENT ROUTES. TREATMENT IS: CNAD
1 UKREORDER
18
TRAVER of a call from a phone number with an UNPAID bill.
>traver l 8885000 0898123456 b
TABLE KSETLINE
RM05 00 0 02 17 1 DN Y 8885000 BOB 0 0 111 (LNR) $ MBS
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE NCOS
BOB 0 0 0 CLASS $
AND DIGCOL
TABLE DIGCOL
TUPLE NOT FOUND
BOBCT
$9
TABLE DIGCOL
TABLE LINEATTR
NLCA_NILLA_1 $
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
TABLE FACODE
>1118885000
TABLE DNSCRN
. 1118885000 (UNPAID )
19
. CLI unpaid
. Screening failed
TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLED
TREATMENT ROUTES. TREATMENT IS: CNAD
1 UKREORDER
20
TRAVER of a successful call to CLI screened number using CLISERV option.
>traver tr ukpvg 01252855111 b
TABLE TRKGRP
UKPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 N 0 0 0
0 N N N N N N N N N NATL $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
AIN_OFFICE_TRIGGRP ETSIGRP
TABLE NCOS
CS2KCUST 0 0 0 NO_RST $
CS2KCUST NXLA CXDEMO NXLA 0 CSDIG
TABLE DIGCOL
CSDIG 0 RPT
TUPLE NOT FOUND
CXDEMO
(NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9
TABLE DIGCOL
TABLE LINEATTR
1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
CS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS
INTL)$ CON 9
TABLE PXCODE
TUPLE NOT FOUND
21
TABLE FAHEAD
NOCON 9
TABLE FACODE
FADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) (
CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMO
>1312345000
TABLE CLISERV
. CLIDEMO 1 ( PARTIAL ) ( FAILRTE FA SCRNFAIL) ( FAILAMA ) ( SERVAMA )$
TABLE DNSCRN
. 1312345 $
TABLE FAHEAD
NOCON 9
TABLE FA2CODE
Default from head table used
TABLE: FARTE
KEY: FADEMO 5
. S PBX_SITE_A
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL
. GENTRIG ( CDPN ETSITRIG)$ NIL
Trigger INAPV8 GENTRIG is applicable to office.
INAP Info Analyzed TDP: trigger criteria not met.
INAP Route Select Failure TDP: no subscribed trigger.
1 PBX_SITE_A 01252855111 ST

1 UNOBT
22
TRAVER of an un successful call to CLI screened number using CLISERV option.
TABLE TRKGRP
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
CS2KCUST NXLA CXDEMO NXLA 0 CSDIG
TABLE DIGCOL
CSDIG 0 RPT
TUPLE NOT FOUND
CXDEMO
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
CS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS
INTL)$ CON 9
TABLE PXCODE
TUPLE NOT FOUND
23
TABLE FAHEAD
NOCON 9
TABLE FACODE
FADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) (
CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMO
>1343214000
TABLE CLISERV
. CLIDEMO 1 ( PARTIAL ) ( FAILRTE FA SCRNFAIL) ( FAILAMA ) ( SERVAMA )$
TABLE DNSCRN
. No match found
. Screening failed
TABLE FAHEAD
SCRNFAIL DFLT RTE ( DEST 1)$ NODFOP NOCON STD
TABLE FACODE
TUPLE NOT FOUND
TABLE: FARTE
KEY: SCRNFAIL 1
. S CLI_FAIL_ANNC
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL
INAP Route Select Failure TDP: no subscribed trigger.
1 CLI_FAIL_ANNC

1 UNOBT
>
24
Indirect Access CLI Screening Exercise 1
Your task is to provide a subscription service for a third party vendor. The service needs to
be established so that customers can only access a particular premium rate number if they
pay a subscription, all other callers to the service will receive treatment.
The screening will be performed on the calling line identity (CLI) and you will need to
datafill the universal translation selector with the appropriate options to establish this
service.
The service vendor also wishes to have the option to stop a customer from using the service
if they have not paid their bill.
Student Task
Your task is to bar a designated line from dialling a specific number - 09000112233, based
on their CLI.
If the CLI passes screening you will route the call to the CLLI established in previous
exercises, for calls to national destinations. You will need to set up the screening trigger,
and datafill the CLI in reference tables.
HINT: think where these calls would go at present, where would be the easiest place to set
this up. Think about where to send the call after screening.
Use the Sub-option VALIDATE and the Subscriber type GENERAL; CHKCCR = N
Test with Traver, you should be prompted for a CLI, enter the CLI of your designated line
and observe. (10 digit CLI) Finally test with a real Call if available.
What datafill will be required if the Vendor wishes to prevent the customer from accessing
the service if that customer has not paid their bill?
25
26
Indirect Access CLI Screening Exercise 2
Your task is to screen for calls to a specific DN range which terminates to a PBX.
Only callers with a specified partial CLI are to be successful, all other callers are to be sent
to treatment.
The screening will be performed on the calling line identity (CLI) and you will need to
datafill the universal translation selector with the appropriate options to establish this
service.
Student Task
Your task is to screen calls to a specific number range 01252855xxx, based on their CLI.
Each team will screen for the specified partial CLIs below;
Team 1 1312221
Team 2 1312222
Team 3 1312223
Team 4 1312224
Team 5 1312225
Team 6 1312226
For the purposes of this exercise, successful calls will be dealt with in the FA system and
sent to the CLLI UKPRI. Therefore think where to screen for these calls.
Calls that fail screening are to be handled in a new FA system specifically built to send calls
to an announcement CLI_FAIL_ANNC.
27
Indirect Access Account Code
Required
Table DNSCRN
DN ATTROPTS
01182005000 (ACCTREQ 4 DT N ) $
Account Code Required
Account Code length

Account Code Prompt
Tone Type
Account Code validation
28
Single-stage CLI-based access - Account code required

With this method, the DNSCRN table entry for the callers CLI specifies that an account
code must be provided as well as the destination number.
Table DNSCRN
Within Table DNSCRN option ACCTREQ specifies that for this entry an Account code is
required.
Datafill the subfields ACCTLEN ( account length ) and ACCTTONE (what tone will be
played to prompt for account digits ).
28
Indirect Access Meridian Off-Net
Access (MONA) via ambiguous
translations
Universals
routing Table DNINV
decision
Table DNROUTE
Table AUTHPART
Pass Screening?
Continue translating
Table AUTHCDE
Fail Screening?
Table DIALPLAN Treatment
29
Meridian Off-Net Access (MONA).

MONA is accessed from IBN Translations or Universal Translations via Table DNINV and
Table DNROUTE to a directory number designated with the MONA feature.
The callers CLI can be checked prior to reaching this directory number.
Once reached, the caller can be prompted for an Authorisation Code, with optionally an
Account Code and/or Security Digits.
If the Authorisation Code is valid the call can progress.

If the code is invalid the call is routed to treatment.
29
Authcode Checking via Table AUTHCDE
Digit Collection
Authcode access is a two-stage process. The calling party provides the access code and
destination number in two separate operations. Providing the access code initiates an
authorisation sequence in which the ingress CS2000 opens a speech path back to the calling
party so that authorisation information and the destination number can be provided in-band.
The authorisation code service uses the access code to select the Meridian Off-Net Access
(MONA) feature via a translations table (IBNXLA or DNROUTE). This table also specifies
the name of the dial plan to be used.
Three methods of dial plan digit collection are supported:
DESTONLY
Only destination digits are collected
AUTHONLY FIRST
Authcode digits are collected first, optionally followed by an account
code and/or security digits, and finally the destination digits.
AUTHONLY LAST
Destination digits are collected first, followed by authcode digits, which
are in turn optionally followed by an account code and/or security digits.
30
Table Dial Plan
Table DIALPLAN example
DIALPLAN CUTHRUTY ORDER AUTHPRMT DESTPRMT ACCTPRMT

DEFAULT AUTHONLY FIRST CDT SDT N
OPTIONS
$
Order Authcode FIRST or LAST Type of tone prompt
31
The Screening Process
For two-stage access, the access code in the initial setup message may be followed by one
of the following:
A 5-digit NNGP (National Number Group Plus) code identifying the originating
exchange. This provides a secondary level of checking to prevent fraud. If the
AUTHCDE table entry for the authorisation code provided (see below) also specifies
an NNGP code, the call attempt will be rejected if this does not match the NNGP in
the IAM or if the IAM contains no NNGP.
A single-digit Inter-Administration Accounting Single Digit (IAASD) code
indicating the interconnect tariff band that applies to the call attempt. This is not
verified by the CS2000.
Before examining the authorisation information, CS2000 verifies that there are 5 (NNGP), 1
(IAASD) or 0 (neither NNGP nor IAASD) digits after the access code.
The authorisation code provided on a call attempt is used as a key into table AUTHCDE.
An authcode is a number of between 2 and 14 digits in length. For a given partition (or
access code), authcodes can be variable in length if the AUTHRAN option is specified in
table DIALPLAN; otherwise, they must have the same fixed length. The maximum number
of authcodes allowable per partition (access code) is 1 million.
Authorisation is successful only if there is an entry for the authorisation code provided and
only if the other items of authorisation information provided match those that are specified
as required in that AUTHCDE entry. The following types of screening are possible:
PIN verification (security digits)
The SECDIGS field can be used to specify a Personal Identification
Number (PIN) of up to 4 digits that must be provided. This must exactly
match the PIN provided by the subscriber.
Account code or Customer Cost Centre (CCC) code screening
The ACCT field specifies whether a Customer Cost Centre (CCC) code of up
to 18 digits (to be placed in the billing record) must be provided. If
provided, a CCC is checked for length, and may also be screened via
table ACCTSCRN.
Hotline number
The HOTLINE option and the HOTLN_NUM field can be used to
specify a hotline number for automatic connection.
32
Additional options that may be specified in table AUTHCDE are:
CUSTGRP / NCOS
Allows the customer group and/or NCOS associated with the caller to be
overridden
CALLBLK
Allows calls to be blocked in spite of successful screening (e.g. if the
subscribers bill has not been paid). If required, an IBN110 log can be
generated to log such a blocked call attempt.
Two other types of screening may be enforced on a call attempt, though not directly by
table AUTHCDE:
Region code screening
A customer group may be assigned (and thus restricted) to a particular
region.
Restricted usage screening
The Time Of Day (TOD) routing feature may be used to implement call
restrictions based on date, day or time of day.
33
Indirect Access MONA via
ambiguous translations example
Table DNROUTE
AREACODE OFCCODE STNCODE DNRESULT
207 620 6000 FEAT MONA DEFAULT $
Table DIALPLAN
DIALPLAN CUTHRUTY OPTIONS
DEFAULT AUTHONLY FIRST CDT SDT N $
Table AUTHPART
PARTNM INFO
CS2KAUTH IBN 4 100
Code Authorised
dial this number automatically
Table AUTHCDE
AUTHPART AUTHCODE INFO
CS2KAUTH 1234 IBN 0 N $ SW (HOTLINE 01618880000) $
34
The above example shows the table flow of a MONA call.

The following pages describe the datafill.
34
To invoke Indirect Access through MONA, the following tables require datafill;
They are listed in datafill order.
Table AUTHPART
Table AUTHCDE
Table CUSTHEAD
Table DIALPLAN
Table DNROUTE
Table AUTHPART
This table defines the Authorisation Partition name and is referenced from CUSTHEAD and
AUTHCDE.
Table AUTHCDE
This table defines the actual codes, the NCOS, whether Account Codes are used, any
Security Digits used, the type of Authorisation Code and any options.
Table CUSTHEAD
This table associates the Partition Name to a Customer Group. If the code entered is
authorised, it continues as a line in this Customer Group, at the NCOS associated with the
Authorisation Code.
Table DIALPLAN
Specifies the cut-through access type.
Table DNROUTE
This table defines software Directory Numbers, i.e, numbers that do not relate to actual
lines but to software features such as UCD, ACD etc.
35
ambiguous translations - continued
Table DNROUTE
Table DIALPLAN
Table AUTHPART
PARTNM INFO
CS2KAUTH IBN 4 100
Code Authorised
Table AUTHCDE
36
Table AUTHPART
Table AUTHPART defines a name used by the customer group as an index into the
AUTHCDE table. It also defines the format and length of the authorisation code and limits
the number of codes a customer group may use. An example tuple is given below.
TABLE AUTHPART
PARTNM FORMAT LENGTH MAXSIZE
cs2kauth ibn 4 100
In this example, the name AUTHDEM is defined along with the format of IBN, length of
code 4 and maximum number of codes 100.
36
The fields are:-
PARTNM Partition name. Enter a 1 to 16 character name to be used by the
customer Group as the index into the AUTHCDE table. This name will be
used in table CUSTHEAD to link the Customer Group to the
Authorisation Codes that it may use.
FORMAT Format. Enter the format of the Authorisation Partition. The
format may be:- CFRA, Call Forward remote Access, or IBN.
Enter IBN if the codes are to be usable.
LENGTH Length of Authorisation Code. Enter the number of digits in
the Authorisation Code. Codes may be between 2 and 10 digits in length
and the number entered here fixes the code length for the Customer
Group.
MAXSIZE Maximum Size. Enter the maximum number of codes (0-1000000) that
the Customer group may use.
The maximum number of codes that may be used also depends on the
length of the code. E.G. if the length = 3, the maximum range of codes
can only be between 000 & 999
37
Table DNROUTE
Table DIALPLAN
Table AUTHPART
PARTNM INFO
CS2KAUTH IBN 4 100
Code Authorised
Table AUTHCDE
38
Table AUTHCDE
Table Authcde defines the actual authorisation codes used by a customer group. In addition,
this table assigns an NCOS with each code, specifies any optional digits such as security
digits, allows for an account code to be included and defines the type of authorisation code.
A number of other options may be included in this table. the options are:-
Toneburst on Answer TONEBURST
Private Speed Calling PSC
Authcode Hotline HOTLINE
Customer group CUSTGRP
An example tuple is given below:-
TABLE AUTHCDE
AUTHPART AUTHCODE FORMAT NCOS ACCT SECDIGS AUTHTYPE
cs2kauth 12567 ibn 0 n $ sw
OPTION
$
38
In this example, The authorisation code 12567 has been assigned to the Authorisation
partition name cs2kauth. The format of the code is IBN and NCOS 0 has been attached to
the code. Account code and Security digits are not required. The authorisation code is an
SW type and no options apply.
The fields are:-

AUTHPART Partition name. Enter the name of the Authorisation Partition table to
which this code is linked. This name must exist in an AUTHPART table
first.
AUTHCDE Authorisation Code. Enter the actual authorisation code number. The
number of digits must be the same as defined in the field LENGTH in
the associated AUTHPART table. Up to 12 digits.
FORMAT Format. Enter the format of the code. The format may be CFRA,
EXEMPT or IBN. The fields following the format entry will differ
depending on the format chosen. Enter IBN if the code is assigned to
the Customer group and is usable. The following fields must be
datafilled if FORMAT is IBN.
NCOS Network Class of Service. Enter the NCOS assigned to the Authorisation
Code.
The NCOS value must be valid for the customer group. The line from
which the authorisation code is used will assume this NCOS value for
the duration of the call.
ACCT Account Option. Enter Y (yes), if the authorisation code is to include a
combined account code. Otherwise enter N (no). If an account is
required, the ACCT option must be assigned to the Customer group in
table CUSTHEAD.
SECDIGS Security Digits. The authorisation code can be given extra security by
the inclusion of up to four extra security digits. Enter the actual digits
required as the security digits.
Enter $ in this field if security digits are not required.
AUTHTYPE Authorisation code type. Enter one of the following types:-
SSAC Station Specific Authorisation Code Used in Centrex
Translations
SW Switch Wide Available for use for MONA.
SUPAC Super Authorisation Code Available for MONA
OPTION Options. Enter any of the options which may be applied to the
authorisation code.
39
Use of security digits and account code.
An example of an authorisation code with security digits is given below.
AUTHPART AUTHCODE FORMAT NCOS ACCT SECDIGS AUTHTYPE

cs2kauth 12469 ibn 3 y 5643 sw
OPTION
$
In this example, the authorisation code 12469 is assigned NCOS 3. The ACCT option is set
to yes, indicating that an account code is required. The security digits 5643 have been
assigned and the auth type is SW (system wide).
In order for Account Codes to be used with an Authorisation Code, an additional option
must be added to the Table CUSTHEAD entry for the Customer Group.
40
Table CUSTHEAD
Table Custhead is used to assign the Authorisation and Account Code options to a Customer
Group. Four Customer Group options can be assigned, they are AUTH, ACCT, ACR and
ACRANN. Each of the options assign particular operating parameters to the features which
are then fixed on a customer group wide basis.
Option AUTH.
The AUTH option is used to assign the AUTHPART table name to the Customer Group.
Assignment of this name links the Customer Group to the Authorisation codes assigned to
it. Other fields determine how the user indicates the end of the Authorisation code and
whether a combined account code is required. An example is given below, however, the
leading fields are not repeated.
Table CUSTHEAD
CUSTNAME - - - - - - - - - - OPTION PARTNM SECRECY COMB

cs2kcust - - - - - - - - - - - - - auth authdem y y
In this example, the option AUTH has been added to the cs2kcust customer group. The
option consists of the following fields:-
OPTION Option. Enter the name of the required option, AUTH in this example.
PARTNM Authorisation Partition Name. Enter the name of the Authpart table used by
the Customer Group.
SECRECY Security. Enter the method used to indicate the end of an authorisation
code entry.
There are two methods. Enter N(no) if the user has to dial a #
(octothorpe)
OR wait for the expiry of interdigit time-out to indicate the end of an
authorisation code entry. Otherwise enter Y(yes).
COMB Combined Authorisation and Account Code. Enter Y (yes) if the code is a
combined authorisation and account Code. Otherwise enter N (no).
N.B. if the code is a combined authorisation and account code the option
ACCT must also be defined for the customer group.
41
Option ACCT
The ACCT (account code capability) option is used to assign operating parameters to the
account code feature for the customer group. The option includes the number of digits in
account codes and how the end of an account code entry is indicated. An example is given
below, however, the leading fields are not repeated.
Table CUSTHEAD
CUSTNAME - - - - -OPTION DIGINACC NOTIMOUT STARACPT ACCTVAL
cs2kcust ------- acct 3 y y n
POTSDGT
n
In this example, the option ACCT has been assigned to the cs2kcust customer group. The
account codes are to be 3 digits long and an end of code indication has been defined. The
option consists of the following fields:-
OPTION Option. Enter the name of the required option, ACCT in this example.
DIGINACC Digits in account code. Enter the number of digits in the account code. In this
example 3, i.e.account codes must be 3 digits long. Range from 2 to 14digits.
NOTIMOUT Time Out. Enter the method used to indicate the end of an account code
entry. There are two methods. Enter N(no) if the user has to dial a #
(octothorpe) OR wait for the expiry of interdigit time-out to indicate the
end of an authorisation code entry. Otherwise enter Y(yes).
STARACPT Star accept. Enter Y (yes ) if the star * is to be a valid digit for the
account code first. Otherwise enter N (no ) if the star * is to be used for
reset dialing.
ACCTVAL Account code validation. Enter Y (yes) if the account codes are to be
validated for content. Only codes of 2 or 3 digits may be validated.
Otherwise enter N.
POTSDGT POTS Digit collection. Y or N. Only answer is N.
42
ambiguous translations continued
Table DNROUTE
Table DIALPLAN
Table AUTHPART
PARTNM INFO
CS2KAUTH IBN 4 100
Code Authorised
Table AUTHCDE
43
Table DIALPLAN
For each dial plan, table DIALPLAN specifies that cut-through access is permitted only on
authorisation, and specifies the secondary tone that should be used to prompt the user for
authorisation information as Carrier Dial Tone (CDT), Special Dial Tone (SDT) or Dial
Tone (DT).
The fields are;
DIALPLAN Dial Plan Name. 1-16 alphanumeric
CUTHRUTY Cut Through Type, the choices are;

AUTHONLY Auth Code only,
ORDER First or Last
AUTHPRMT SDT, CDT, DT or N
DESTPRMT - SDT, CDT, DT or N
ACCTPRMT - SDT, CDT, DT or N
or DESTONLY Auth Code and destination digits
INITPRMT - SDT, CDT, DT or N
ACCT Account code required Y or N
ACCTPRMT - SDT, CDT, DT or N
43
Additional options may be specified for a given dial plan. Some of them are:
AUTHRAN Allows variable-length authcodes (2-14 digits)

AUTHPART Allows the authcode partition associated with the callers
customer group to be overridden
PARTIAL Allows partial authcode screening
CONFTONE Causes a confirmation tone to be played to the caller after
successful authcode screening
CUSTGRP / NCOS Allows the csutomer group and/or NCOS associated with
the caller to be overridden
MASK Allows authcode digits that would normally appear in the
AMA record to be masked
44
Table DNROUTE
Table DIALPLAN
Table AUTHPART
PARTNM INFO
CS2KAUTH IBN 4 100
Code Authorised
Table AUTHCDE
45
Table DNROUTE
The Directory Number route (DNROUTE) table contains directory numbers not associated
with a L.E.N. (Line Equipment Number). The DNs datafilled in this table may point to a
treatment, route list or special Centrex features. The DNROUTE table uses selectors to
point the DN to the appropriate termination. The commonly used selectors are:-
D Treatment
MM Meet Me Conference (Datafilled in Table MMCONF )
T Route list in table OFRT or IBNRTE
FEAT Centrex Feature.
The special Centrex features accessed by DNs in table DNROUTE are:-
ACD Automatic Call Distribution

DISA Direct Inward System Access
MONA Meridian Offnet Access
UCD Uniform Call Distribution
45
DNROUTE FEAT Selector (MONA)
The FEAT selector is used when the DN is used to access one of the special Centrex
features.
For this course we will only be looking at the MONA feature.
TABLE DNROUTE
AREACODE OFCCODE STNCODE DN_SEL FEATURE DIALPLAN
207 620 6000 feat mona default
OPTION
$
In this example, the DN 2076206000 uses the FEAT selector of MONA.

The fields are:-
AREACODE Area Code. Enter the three digit Area Code portion of the DN. This
must be a valid Area Code (SNPA) for the switch.
OFCCODE Office Code. Enter the three digit Office Code portion of the DN.
The Office Code must be specified in table TOFCNAME first.
STNCODE Station Code. Enter the digits of the Station code.
DN_SEL Directory Number Selector. Enter the appropriate selector. The

FEAT selector is used in this example.
FEATURE Feature. Enter the required feature acronym. MONA in this example.
OPTION MONA billing options

Enter ENTRYID to generate a billing record. If ENTRYID is specified, a
module 046 record is appended to the AMA record for the leg of the
call that was made from a MONA DN. The module 046 contains the
ISUP ENTRYID, the originator's CLI, or the billing number of the trunk
used to access MONA.
The following pages have an example of a call to a MONA number.

This shows the links through these tables.
46
TABLE TRKGRP
TABLE CUSTSTN Original Customer Group and NCOS
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
CS2KCUST NXLA CXDEMO NXLA 0 NDGT ( AUTH CS2KAUTH N N)
TABLE DIGCOL
NDGT specified: digits collected individually AUTH option associated to CustGrp
CXDEMO 02 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) (
CLASS NATL)$ NOCON 9
TABLE PXCODE
CS2KPX 0207 0207 CONT ( MM 11 11) ( XLT OFC 2KLOCAL)$
TABLE OFCHEAD
2KLOCAL SDFLT DFOP ( CLASS NATL)$ NOCON 9
TABLE OFCCODE
2KLOCAL 0207 0207 RTE ( MM 11 11) ( DEST 207)$
TABLE: OFCRTE
KEY: 2KLOCAL 207
. T IBNRTE 207
. . TABLE IBNRTE
. . 207 DN 207 620 N 0 4
. . . 207 620 $
. . . TABLE DNINV
. . . 207 620 6000 FEAT MONA DEFAULT $ Entry in Table DNROUTE
TABLE DIALPLAN
DEFAULT AUTHONLY FIRST CDT SDT N $ DIALPLAN cut-thru type
TABLE AUTHPART
CS2KAUTH IBN 4 100 Link to CUSTGRP
47
ENTER AUTHCODE DIGITS
>1234
TABLE AUTHCDE
CS2KAUTH 1234 IBN 0 N $ SW (HOTLINE 01628795888) $ Auth Code check and options
TABLE NCOS
CS2KCUST 0 0 0 NO_RST $ Call continues with possible new CustGrp and NCOS
CS2KCUST NXLA CXDEMO NXLA 0 NDGT
TABLE DIGCOL
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND Call enters Universals with HOTLINE number
DEFAULT FROM HEAD TABLE USED and processed as normal
TABLE FAHEAD
01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS N
ATL)$ NOCON 9
TABLE FACODE
TUPLE NOT FOUND
48
TABLE: FARTE
KEY: 01628FA 1
. S DANNAT
EXIT TABLE FARTE
TABLE DNFEAT
TUPLE NOT FOUND
. . . TABLE DNATTRS
. . . TABLE DNGRPS
EXIT TABLE OFCRTE
TABLE TRIGGRP
ETSIGRP INFOANAL
1 FEATURE 2076206000 ST

1 UNOBT
>
49
Indirect Access Student Exercise 3 - MONA
Students are to set up the following;

Enable a MONA number within your allocated number range.
Callers are to be prompted to use a four figure AUTHCode, one of your choice.
If the AuthCode is correct, the caller is to be automatically connected to the following
number -01628797979.
Evaluate the tables required.

Plan your datafill. If in doubt, ask your instructor.
50
51
Module 14
Universal Translations Call

Control and Universal Screening
nortel.com/training
0
1
Call Control and Universal Screening
Purpose
The purpose of this module is to introduce the student to the concepts of;
> Call Control and Universal Screening.
After this module of instruction, you will be able to:

> Identify the various elements that may be screened within Universal
Screening.
> Enter datafill into the tables associated with screening these various
elements.
> Apply Universal Screening functions to real-world situations.
> Datafill Call Control tables
> Identify Path Of Entry screening tables and datafill an example
> Identify Least Cost Routing Engine tables and datafill an example
2
2
3
Universal Trunk Group Enhanced

Translations option CLI Screening
Table
CALLCNTL
Universal
Screening
4
Introduction
Universal Screening is a flexible screening and call manipulation function that enables the
network operator to manipulate call processing elements as required. The network operator
can screen both external and internal parameters, and use these screening processes to
further manipulate translations.
Call Control is activated on a per-trunk basis and can be invoked before any existing call
processing or screening.
Call Control and Universal Screening enable the network operator to control call processing
events such as invocation of screening and setting of internal translation/routing parameters.
Calls can be screened based on:
Called Party Number Digits
Called Party Number Length
Network Class of Service (NCOS)
Call Control and Universal Screening are triggered from IBN translations and are therefore
supported by all protocols that can access IBN translations. For PRI-based access, only
Private call types can access IBN translations.
Call Control and Universal Screening provide a capability that is similar to universal
translations but is based on various options, not only digit strings.
4
Universal Screening Tables
Entry to US via Entry to US on Entry to US from
Enhanced CLI screening trunk group basis translations
Tables
Table CCNTLRX
DNSCRN +
TRKOPTS Selector
CLISRVPF
Table
CCNTLGRP
Table
DTMFSCRN IBNXLA
processing
Table
Table CALLCNTL DIGMAN
ACCTSCRN manipulation
Table Table Table Table Table Table

CGPNSCRN CDPNSCRN CDPNLSCR NCOSSCRN CGRPSCRN SINTSCRN
Table Table Table Table Table

CDNNSCRN NOASCRN BCSCRN CICSSCRN RDRISCRN

CKTSCRN IPISCRN CPCNSCRN OLISCRN VARDEF
5
Call control and universal screening provide a framework for systematically enhancing the
power and flexibility of call processing and translations.
The call control table CALLCNTL supports access to up to fifteen universal screening
tables. Each of these allows calls to be screened, and allows call processing data to be
updated to influence further translation, on the basis of:
Called party number digits
Called party number length
Network Class of Service (NCOS)
Customer group
User-defined variables
Called party number NOA and NPI
Calling party number digits
Calling party number NOA
Bearer capability
Carrier Identification Code (CIC)
Redirecting information
ISDN Preference Indicator
Calling Partys Category (CPC)
FGD ISUP Originating Line Information (OLI)
FGD ISUP CKT
5
The capabilities provided by CALLCNTL and the universal screening tables are similar in
principle to those provided by universal translations, i.e. the screening process can conclude
successfully, continue or be abandoned. The difference is that CALLCNTL already supports
the screening and manipulation of a wider range of call processing data than just called
party number digits, and the framework it provides can easily be extended to include many
more types of data.
Entry into Universal Screening via table CALLCNTL can take place in three ways:
On a trunk group basis
For a given trunk group, the CCNTLIDX option in table TRKOPTS can
specify an index into table CALLCNTL. Alternatively, to simplify
service provisioning, it is possible to group up to eight call control
indexes into a profile defined in table CCNTLGRP. If this is done, the
CCNTLIDX option points to CCNTLGRP rather than directly to
CALLCNTL.
From translations
The GBL (Global) selector in xxRTE tables can be used to support
access to table CALLCNTL.
If GBL=CCNTLRX, the CCNTLIDX field of the CCNTLRX selector
provides an index into table CALLCNTL.
From enhanced CLI screening
For a call being screening on the basis of the callers CLI, the basic CLI
screening performed using table DNSCRN can be enhanced by means of
service profiles defined in table CLISRVPF which can provide an
index into table CALLCNTL.
6
entry from Trunks
Table TRKGRP
GRPKEY GRPINFO
----------------------------------------------------------------------------
HOLLANDPVG IBNT2 0 NPDGP NCRT CS2KCUST 0
DSEQ 0 N ANSDISC 0 Y N N N N N N
0 0 N 0 0 0 0 N N N N N N N N N NATL $
Table TRKOPTS
OPTKEY OPTINFO
------------------------------------------------------------------------------------
HOLLANDPVG CCNTLIDX CCNTLIDX SCRN_4_64KDATA
Table CALLCNTL
7
Table TRKOPTS
The option CCNTLIDX is used to set the index into table CALLCNTL or table
CCNTLGRP, enabling a CALLCNTL index to be associated with an incoming trunk group.
Only values that already exist in table CALLCNTL or table CCNTLGRP can be datafilled
in table TRKOPTS.
7
entry from translations
xxRTE tables
XLANAME RTEREF RTELIST
----------------------------------------------------------------------------
CS2KPX 2 ( GBL CCNTLRX SCRN_4_64KDATA Y Y N 0)$
Table CALLCNTL
8
Call Control and Universal Screening entry from translations.

The GBL (Global) selector in xxRTE tables CAN be used to support access to table
CALLCNTL, however it is meant for MMP markets, not CS2000.
If GBL=CCNTLRX, the CCNTLIDX field of the CCNTLRX selector provides an index
into table CALLCNTL.
8
entry from enhanced CLI screening
Table DNSCRN
DN ATTROPTS
----------------------------------------------------------------------------
01483891111 ( CLISERV 1) $
Table CLISRVPF
PROFIDX PROFOPTS
----------------------------------------------------------------------------
1 (TEST (CCNTLIDX SCRN_4_64KDATA) $ )$
Table CALLCNTL
9
Call Control and Universal Screening entry from enhanced CLI screening.
For a call being screening on the basis of the callers CLI, the basic CLI screening
performed using table DNSCRN can be enhanced by means of service profiles defined in
table CLISRVPF which can provide an index into table CALLCNTL.
9
Table CALLCNTL
Table CALLCNTL (Call Control) is the main table for Call Control and Universal
Screening. Table CALLCNTL provides a capability that is similar in many respects to
universal translations, but based on data items, and not only digit strings.
The fields and subfields in table CALLCNTL can be added in any order, depending upon
the service requirement. By combining these entries, the switch operator can screen and set
various internal variables to specify how the call is further translated.
Table CALLCNTL enables the call-processing data to be examined for certain information
items, then the data is changed as defined by the rules provided. These rules determine
whether call processing should stop immediately, continue with the same CALLCNTL
index, or use the new CALLCNTL index that is provided by the rules engine.
Note: The call control index SCRN_INDX is the key that is used by tables TRKOPTS and
CCNTLGRP to index into the call control tables CCNTLGRP, CALLCNTL, CDPNSCRN,
CDPNLSCR, NCOSSCRN, VARDEF, SINTSCRN, CGPNSCRN, CICSCRN,
CGRPSCRN, OLISCRN, CKTSCRN, RDRISCRN, IPISCRN, NOASCRN,
CPNNSCRN, CPCNSCRN, BCSCRN and DTMFSCRN, and is the first field in these call
control tables.
The initial call control index is used to start the process. Each option that is datafilled on the
initial tuple in table CALLCNTL is processed in turn:
1. If the SCRN option is datafilled, call processing continues to the appropriate screening
table using the same index as in table CALLCNTL.
2. If the CALLCNTL index is updated via this screening table, table CALLCNTL uses the
updated value to re-index this table when processing of the current option is complete.
3. If processing of the current option is not complete, the updated CALLCNTL index is
used to access any subsequent Universal Screening tables.
Table CCNTLGRP
Using table CCNTLGRP (Call Control Group), you can set up a grouping or profile of call
control indexes. Therefore, the operator can provision additional call control functions into
this profile without having to change the previously-defined call control function to point to
a new call control index. A maximum of eight call control indexes can be grouped into each
call control profile (tuple).
During call origination, if the CCNTLIDX option is datafilled against the originating trunk
group in table TRKOPTS, the CS2000 accesses table CCNTLGRP and retrieves the first
index within the defined profile. This index is then used to access table CALLCNTL. Each
CALLCNTL index from table CCNTLGRP is processed completely before proceeding to
the next index. The next index is taken regardless of the value of the CALLCNTL index, at
the end of the last iteration through CALLCNTL.
When all possible CCNTLGRP (if applicable) and CALLCNTL iterations have been
processed, the call continues to table NCOS using all the call processing variables (for
example, NCOS, COS, POECNAME, CLICNTL index) that might have been updated in
CALLCNTL.
10
Universal Screening
Screening is invoked via two subfields in table CALLCNTL: SCRN and GOTO.
Subfield SCRN enables a user to list the element (or elements) to be screened. The
element (or elements) is specified by the entries in subfield SCRN, which act as pointers
into tables that screen the specified elements. When the screening of an element is complete
in the corresponding screening table, the call can return to table CALLCNTL with an
updated CALLCNTL index.
Subfield GOTO provides two options:
The option to go to Universal Screening tables with a new index. Because each
Universal Screening table screens a specific element, the element to be screened is
determined by the table datafilled in the GOTO subfield, for example, GOTO CDPNSCRN
SCRN_CDPN.
The option to remain within table CALLCNTL but with a new index to access a new
tuple.
11
Universal Screening Tables
Entry to US via Entry to US on Entry to US from
Enhanced CLI screening trunk group basis translations
Tables Table CCNTLRX

DNSCRN + TRKOPTS Selector
CLISRVPF
Table
CCNTLGRP
Table
IBNXLA
DTMFSCRN
processing
Table
Table CALLCNTL DIGMAN
ACCTSCRN manipulation
Table Table Table Table Table Table

CGPNSCRN CDPNSCRN CDPNLSCR NCOSSCRN CGRPSCRN SINTSCRN

CDNNSCRN NOASCRN BCSCRN CICSSCRN RDRISCRN

CKTSCRN IPISCRN CPCNSCRN OLISCRN VARDEF
12
Universal Screening tables

There is a screening table dedicated to each element that can be screened.
Although the format of each table is slightly different, they all have the following common
characteristics: they are indexed using the 1- to 32-character string from table CALLCNTL;
and they return an updated CALLCNTL index.
Note: If a match is not found in the screening table, call processing returns to table
CALLCNTL without updating the CALLCNTL index. However, if the screening table was
invoked via the GOTO subfield, call processing continues with the call without returning to
CALLCNTL.
Each table has an options field that provides the same options as table CALLCNTL, with
the exception of the SCRN and GOTO subfields.
Therefore, various call processing variables can be set, and services can be activated or
overridden without having to return to table CALLCNTL.
The Universal Screening tables have two formats:

The tables that require storage of a large amount of data (for example, CDPNSCRN) use
the headtable and subtable format.
All others are flat tables, which are indexed using the CALLCNTL index and the screened
value.
12
Table CDPNSCRN
Table CDPNSCRN is organized using a headtable and subtable format. All called-party-
number screening tuples that are associated with a given CALLCNTL index are grouped
together. The head table contains only the CALLCNTL index (1- to 32-character string); the
subtable (CDPNDATA) contains the actual digits.
The subtable CDPNDATA contains the actual called party number digits to be screened. If
a match is found, the CALLCNTL index is updated to the new value specified by the
CDPNINDX option. The CALLCNTL options are set as datafilled, and the CDPNSCRN
subfields CONTINUE with CONSUME are performed as datafilled. The CDPNSCRN
subfields provide the flexibility to consume a specified number of digits and continue
screening in CDPNSCRN with the remaining digits without having to perform digit
manipulation on the incoming number or without returning to CALLCNTL.
Table CDPNLSCR
Table CDPNLSCR enables the operator to screen the called party number based on the
length of digits received. If the allowed length is found, the CALLCNTL index is updated
and the datafilled CALLCNTL options are performed.
Table NCOSSCRN
Table NCOSSCRN enables screening of the network class of service that is associated with
a given call.
Table VARDEF
Table VARDEF allows the additions of strings up to 8 characters in length.
These strings become variables usable by tables SINTSCRN, CALLCNTL and
OUTPULSE.
Table SINTSCRN
Table SINTSCRN is used to screen small integer user-defined variables with the screening
option of Call Control. It is organized using a head/sub-table architecture. With this
approach, all the variable values associated with a given variable name (from table
VARDEF) are grouped together. The head table contains only the Variable name. The sub-
table (SINTDATA) contains the actual values and SCRN_INDX pairs.
Table CGPNSCRN
Table CGPNSCRN is used to screen the CallinG Party Number/Calling Line Identity (CLI)
with the screening option of Call Control. It is organized using a head/sub-table
architecture. With this approach, all calling party number screening tuples associated with a
given SCRN_INDX index are grouped together. The head table contains only the
SCRN_INDX index. The sub-table (CGPNDATA) contains the actual digits.
Table CICSCRN
Table CICSCRN is used to screen Carrier Identification codes received in Transit Network
Selection (TNS), Carrier Selection Parameter (CSP) and Carrier Identification Parameter
(CIP) received in incoming ISUP IAMs. It is organized using a head/sub-table architecture.
With this approach, all the Carrier Identification Codes associated with a given
SCRN_INDX index are grouped together. The head table contains only the SCRN_INDX
and the length of CIC to be screened. The sub-table (CICDATA) contains the Carrier
Identification codes.
Table CGRPSCRN
Table CGRPSCRN enables the operator to screen calls based on the Customer Group. If a
match is found for the current customer group, the CALLCNTL index is updated and the
datafilled CALLCNTL options are performed.
13
Table OLISCRN
Table OLISCRN enables the operator to screen calls based on the Originating Line
Information parameter (OLI) received on an ISUP FGD agency. If a match is found for the
OLI, the CALLCNTL index is updated and the datafilled CALLCNTL options are
performed.
Table CKTSCRN
Table CKTSCRN allows the operator to screen the Circuit Digits (TNS_CKT) received
within the TNS parameter of an IAM on ISUP FGD trunks. If a match is found for the
circuit digits, the CALLCNTL index is updated and the datafilled CALLCNTL options are
performed.
Table RDRISCRN
Table RDRISCRN enables the operator to screen calls based on the Redirection Information
Parameter received in an incoming ISUP IAM. If a match is found for the Redirection
Information, the CALLCNTL index is updated and the datafilled CALLCNTL options are
performed.
Table IPISCRN
Table IPISCRN enables the operator to screen calls based on the ISDN Preference Indicator
received in an incoming ISUP IAM or PRI setup message. If a match is found for the ISDN
Preference Indicator, the CALLCNTL index is updated and the datafilled CALLCNTL
options are performed.
Table NOASCRN
Table NOASCRN enables the operator to screen calls based on the Calling Number Nature
of Address (NOA)/Type of Number (TON) received in an incoming ISUP IAM or PRI/BRI
setup message. If a match is found for the NOA/TON, the CALLCNTL index is updated
and the datafilled CALLCNTL options are performed.
Table CPNNSCRN
Table CPNNSCRN enables the operator to screen calls based on the CDNNAME (from
table CDNCHAR) set based on the incoming NOA(TON)/NPI received in an incoming
ISUP or PRI message. If a match is found for the CDNNAME, the CALLCNTL index is
updated and the datafilled CALLCNTL options are performed.
Table CPCNSCRN
Table CPCNSCRN enables the operator to screen calls based on the CPCNAME (from table
CCNCHAR) set based on the incoming Calling Party Category (CPC) received in an
incoming ISUP/TUP or PRI message. If a match is found for the CPCNAME, the
CALLCNTL index is updated and the datafilled CALLCNTL options are performed.
Table BCSCRN
Table BCSCRN enables the operator to screen calls based on the Bearer Capability. If a
match is found for the Bearer Capability, the CALLCNTL index is updated and the
datafilled CALLCNTL options are performed.
14
entry from Trunks example 1
Table TRKGRP
GRPKEY
GRPINFO
Incoming Trunk ----------------------------------------------------------------------------
HOLLANDPVG
IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N
0 0 N 0 0 0 0 N N N N N N N N N NATL $
Table TRKOPTS
OPTKEY OPTINFO
----------------------------------------------------------------------------
Table CALLCNTL
CALCTL_KEY CALCTL_OPTIONS
----------------------------------------------------------------------------
CHG_CUSTGRP ( CUSTGRP GRP1)$
SCRN_4_64KDATA ( SCRN ( BC ) $)$
Table BCSCRN
BCKEY NEWSCRN_KEY CCOPTION
-----------------------------------------------------------------------------------------------------------------
SCRN_4_64KDATA 64KDATA CHG_CUSTGRP $
15
The above example shows the link through the data tables for a call originating from a
trunk.
Incoming call on trunk group HOLLANDPVG.

Call arrives and picks up the Customer Group (CS2KCUST) and NCOS (0) as specified in
Table TRKGRP.
Call processing accesses Table TRKOPTS to check for an entry for HOLLANDPVG and
any options.
Option CCNTLIDX specifies the index name SCRN_4_64KDATA which is used to access
Table CALLCNTL.
In Table CALLCNTL, the index name SCRN_4_64KDATA specifies the following;

SCRN_4_64KDATA (SCRN (BC) $ ) $
The first instruction is SCRN, and the value to screen BC (Bearer Capability).
The same CALLCNTL index name is then used to access Table BCSCRN.
SCRN_4_64KDATA 64KDATA CHG_CUSTGRP $
15
The instruction here is to screen for 64KDATA calls.
If the call is 64KDATA - then the call picks up a new CALLCNTL index name of
CHG_CUSTGRP.
Table CALLCNTL is then re-indexed using the new index name CHG_CUSTGRP.
This index specifies to change the Customer Group to GRP1.
The call then continues to Centrex Translations with the Customer Group GRP1 and NCOS
0.
If the call is not 64KDATA The call returns to CALLCNTL still with the
SCRN_4_64KDATA index name and checks for the next instruction.
SCRN_4_64KDATA (SCRN (BC) $ ) $
As there are no more instructions, the call progresses to Centrex Translations with the
original Customer Group (CS2KCUST) and NCOS (0).
16
Traver of previous datafill example
>traver tr hollandpvg 01234567890 b
TABLE TRKGRP
HOLLANDPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 0
0 0 0 N N N N N N N N N NATL $
TABLE TRKOPTS
TABLE CALLCNTL
SCRN_4_64KDATA
(SCRN ( BC ) $)$
PLEASE ENTER VALUE FOR BEARER CAPABILITY:
>64kdata
. . TABLE BCSCRN
. . SCRN_4_64KDATA 64KDATA CHG_CUSTGRP $
. TABLE CALLCNTL
. CHG_CUSTGRP (CUSTGRP GRP1) $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
GRP1 0 0 0 $ $
GRP1 NXLA GRP1CT NXLA 0 NDGT
TABLE DIGCOL
TABLE IBNXLA: XLANAME GRP1CT
TUPLE NOT FOUND
GRP1CT
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
17
TABLE PXHEAD
CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14)
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS
ATL)$ NOCON 9
TABLE FACODE
TUPLE NOT FOUND
TABLE: FARTE
KEY: 01628FA 1
. S DANNAT
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL

>64kdata
1 DANNAT 01234567890 ST

1 UNOBT
>
18
entry from Trunks example 2
Table TRKGRP
GRPKEY
GRPINFO
Incoming Trunk ----------------------------------------------------------------------------
FRANCEPVG
IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N
0 0 N 0 0 0 0 N N N N N N N N N NATL $
Table TRKOPTS
OPTKEY OPTINFO
----------------------------------------------------------------------------
FRANCEPVG CCNTLIDX CCNTLIDX SCRN_4_GOLD_CUSTOMER
Table CALLCNTL
CALCTL_KEY CALCTL_OPTIONS
----------------------------------------------------------------------------
CHG_CUSTGRP ( CUSTGRP GRP1)$
SCRN_4_GOLD_CUSTOMER ( SCRN ( CGPN ) $) (GOTO CALLCNTL CHG_CUSTGRP) $
CHG_CUSTGRP_CUST_A (CUSTGRP GRP4) $
CHG_CUSTGRP_CUST_B (CUSTGRP GRP5) $
Table CGPNSCRN TABLE: CGPNSCRN SCRN_4_GOLD_CUSTOMER: CGPNDATA

CGPNSCRN_KEY CGPNDATA FROMDIGS TODIGS CGPNINDX CCOPTION CGPNOPT
----------------------------------------- ----------------------------------------------------------------------------
SCRN_4_GOLD_CUSTOMER ( 1) 1483890000 1483890000 CHG_CUSTGRP_CUST_B $ $
1628792000 1628792000 CHG_CUSTGRP_CUST_A $ $
19
The 2nd above example shows the link through the data tables for a call originating from a
trunk, this time screening for CLIs.
Incoming call on trunk group FRANCEPVG.

Table TRKGRP.
Call processing accesses Table TRKOPTS to check for an entry for FRANCEPVG and any
options.
Option CCNTLIDX specifies the index name SCRN_4_GOLD_CUSTOMER which is used
to access Table CALLCNTL.
In Table CALLCNTL, the index name SCRN_4_GOLD_CUSTOMER specifies the

following;
SCRN_4_GOLD_CUSTOMER (SCRN (CGPN) $ ) (GOTO CALLCNTL
CHG_CUSTGRP) $
The first instruction is SCRN, and the value to screen CGPN (Calling Party Number).
The same CALLCNTL index name is then used to access Table CPGNSCRN.
SCRN_4_GOLD_CUSTOMER ( 1 )
This tuple shows there are Sub Table entries.
Enter SUB to go to the SubTable.
19
The instruction here is to screen for Callers CLIs.
The fields consist of a FROMDIGS and TODIGS, where the CLIs will be listed.
A CGPNINDX and CCOPTION.
In this example;
Any callers with a CLI of 1483890000 to 1483890000 will return to CALLCNTL using
the index name CHG_CUSTGRP_CUST_B.
This instruction says to change the CUSTGRP to GRP4.
The call then progresses to Centrex Translations as GRP4 instead of CS2KCUST.
Any callers with a CLI of 1628792000 to 1628792000 will return to CALLCNTL using
the index name CHG_CUSTGRP_CUST_A.
This instruction says to change the CUSTGRP to GRP5.
The call then progresses to Centrex Translations as GRP5 instead of CS2KCUST.
Any other callers not matching either of the above would return to CALLCNTL with the
original index name of SCRN_4_GOLD_CUSTOMER and check the next option;
SCRN_4_GOLD_CUSTOMER (SCRN ( CGPN ) $ ) (GOTO CALLCNTL
CHG_CUSTGRP ) $
This specifies to GOTO Table CALLCNTL and use index name CHG_CUSTGRP.
This instruction specifies to change the customer Group to GRP1, and continue to Centrex
Translations.
20
The following TRAVER is an example of the previous scenario, from a known CLI.
>traver tr francepvg 01234567890 b
TABLE TRKGRP
FRANCEPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 0 0
TABLE TRKOPTS
TABLE CALLCNTL
SCRN_4_GOLD_CUSTOMER
(SCRN ( CGPN ) $) (GOTO CALLCNTL CHG_CUSTGRP ) $
>1628792000
. . TABLE CGPNSCRN
. . SCRN_4_GOLD_CUSTOMER (1)
. . SUBTABLE CGPNDATA
. . 1628792000 1628792000 CHG_CUSTGRP_CUST_A $ $
. TABLE CALLCNTL
. CHG_CUSTGRP_CUST_A (CUSTGRP GRP4) $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
GRP4 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
GRP4CT
TABLE DIGCOL
TABLE LINEATTR
21
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLAS
ATL)$ NOCON 9
TABLE FACODE
TUPLE NOT FOUND
TABLE: FARTE
KEY: 01628FA 1
. S DANNAT
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL
1 DANNAT 01234567890 ST

1 UNOBT
22
The following TRAVER is an example of the previous scenario, from an unknown
CLI.
>traver tr francepvg 01234567890 b
TABLE TRKGRP
FRANCEPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0
TABLE TRKOPTS
TABLE CALLCNTL
SCRN_4_GOLD_CUSTOMER
(SCRN ( CGPN ) $) (GOTO CALLCNTL CHG_CUSTGRP ) $
>1753876543
. . TABLE CGPNSCRN
. . SCRN_4_GOLD_CUSTOMER (1)
. . SUBTABLE CGPNDATA
. . KEY NOT FOUND
. TABLE CALLCNTL
. CHG_CUSTGRP (CUSTGRP GRP1) $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
GRP1 0 0 0 $ $
TABLE DIGCOL
TUPLE NOT FOUND
GRP1CT
TABLE DIGCOL
TABLE LINEATTR
23
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLAS
ATL)$ NOCON 9
TABLE FACODE
TUPLE NOT FOUND
TABLE: FARTE
KEY: 01628FA 1
. S DANNAT
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL
1 DANNAT 01234567890 ST

1 UNOBT
24

> EMEA..... or EM......
> CALA..... or CA......
> APAC.... or AP.....
> NA........
25
Naming Conventions
To enable the switch database to be kept tidy and assist instructors in removing datafill
post-event the above naming convention will be followed.

Translation system.
Kingdom.
25
Call Control and Universal Screening Exercise 1
The purpose of this exercise is to practice the datafill associated with Call Control and
Universal Screening.
Your task is enter datafill such as to fulfill the following requirements;

Part 1 BC Screening
Screen calls from your 1st partner trunks for the following;
SPEECH calls are to be sent to Centrex Translations with an NCOS of 1.
Part 2 CLI Screening
Calls from your 2nd partner trunks are to be screened for the following CLIs;
2083005000. These calls are to enter Centrex Translations with the Customer Group name
of DEFAULT, all other CLIs are to enter Centrex Translations with their original Customer
Group name.
Evaluate the tables required.

Plan your datafill on paper first.
If in doubt, ask your instructor.
HINT.
In Table CALLCNTL, use a logical naming convention as Table TRKOPTS can only have
one entry per Trunk Group and datafill from this exercise will be used for subsequent
exercises.
Suggested naming convention: [Region]xSCREEN
Where [Region] is region name as per required naming convention and x is your team/group
number.
Enter your Translations into the switch and test with TRAVER.
26
27
Path of Entry Screening
CS2000 Carrier X
Carrier Y
a ll Carrier Z
i ceC
Vo
Incoming Trunk PSTN
Da
ta
Ca Carrier Y
ll
Carrier Z
28
Introduction
When translating or routing calls through a network, multiple variables, such as calls
origination, destination, class of origination, and language need to be considered. Switch
operators may require the flexibility to selectively restrict or reroute calls based upon both
the call origination information and destination determination. For instance, a service
provider is using Least Cost Routing, which allows them to cost effectively route all calls to
a particular destination.
For data calls routing to the United Kingdom using a particular carrier, the service provider
has been experiencing loss of data due to data compression performed by the particular
carrier. A service provider does not want to reroute all of their traffic to another carrier that
could turn out to be a costly option just to prevent one call type. Instead, they want to
isolate special routing requirements on a case-by-case basis and only reroute the data traffic
through another route/carrier to the UK. This can be accomplished by using Path of Entry
Screening (POE) and Destination Control.
This scenario is described graphically above.
28
Path of Entry Screening
Path of Entry Screening includes the screening of information to determine the variables
that are used to make the routing decisions. The types of information to be screened can be
categorized as follows:
Origination Information (origin, CPC, and DISD, for example)
Destination information (digit analysis)
Origination Information
The screening of the origination information is currently provided on the CS2000 through
Call Control and Universal Screening. Path of Entry Screening requires the ability not only
to screen this information but also retain the information to determine call routing during
later translations. This capability is implemented using an option in table CALLCNTL
called Path of Entry Characteristic Name, POECNAME.
Destination Information
Destination information consists of data (Country, Area, City, etc.) which identifies the
destination of a call. This information is determined by digit analysis through the Universal
Translations xxCODE and xx2CODE tables.
To successfully provide Destination Control, the origination screening information needs to
be retained but also the destination determined from digit translation needs to be
maintained.
Destination Control
In the above sections, the types of information (origination and destination) essential to
make routing decisions have been discussed. This section discusses the routing
determination from the information provided. Based on the Path of Entry Screening,
Destination Control requires the ability to alter the intended route, which is provided by the
Universal Translations xxCODE tables and xx2CODE tables, before reaching the Universal
Route (xxRTE) tables.
The switch invokes this functionality by accessing table POECRTE (Path of Entry
Characteristics Route) before the xxRTE tables. Table POECRTE uses the data from call
origination screening and the destination from digit analysis to determine if a call is to be
rerouted to a different route list or if a call is to be blocked through treatment. Additionally,
table POECRTE allows the flexibility to continue a call with a previous route list.
29
Path Of Entry (POE) screening/routing
Table Trkgrp
Table Trkopts
Callcntl/bcscrn tables
Centrex Translations
POE tables
Xxcode table (Dest) (Destname)
Route(s) 1 Route(s) 2
30
Translations for Path of Entry Screening

The example described in the introduction section of this lesson requires the use of Path of
Entry Screening and Destination Control to redirect the data traffic. The logic performed to
accomplish this is as follows:
1. Access Call Control with the CALLCNTL index from table TRKOPTS for the
originating trunk. The Call Control tuple indicates to screen the Bearer Capability, which
obtains a POECNAME for a 64k data call.
2. Continue to Universal Translations CODE tables to determine the destination using digit
analysis. The analysis yields a DESTNAME associated with the call.
3. Before continuing to the Universal Translations Route tables, access table POECRTE
with the POECNAME and DESTNAME obtained in steps 1 and 2. The tuple indexed
indicates a new route table with the "T" option.
For this example, shows the associated TRAVER. Assume the following variables:
Dialed address: 01234567890
Received Bearer Capability indicates "Data Call"
30
Path Of Entry Screening example
Table TRKGRP
GRPKEY
Incoming Trunk GRPINFO
----------------------------------------------------------------------------
ITALYPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N
0 0 N 0 0 0 0 N N N N N N N N N NATL $
Table TRKOPTS Table BCSCRN

OPTKEY OPTINFO BC_KEY NEWSCRN_KEY CCOPTION
----------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN
INITIAL_SCREEN SPEECH SET_VOICE_CUSTGRP $
INITIAL_SCREEN 64KDATA SET_DATA_POE $
Table CALLCNTL Table POECNM

CALCTL_KEY CALCTL_OPTIONS VALUE SYMBOL
---------------------------------------------------------------------------- ---------------------------------------------
INITIAL_SCREEN (SCRN (BC) $ ) $ 3 POE_DATA
SET_VOICE_CUSTGRP (CUSTGRP DEFAULT) $
SET_DATA_POE (POECNAME (POECGRP POE_DATA) (POECIDX 5) $ ) $
TABLE xxCODE Table DESTNAME

XLANAME FROMD TOD XLASEL VALUE SYMBOL
---------------------------------------------------------------------------- ---------------------------------------------
xxxXLA 012345 012345 RTE (DEST 1) (DESTNAME DATA_POECRTE) $ 3 DATA_POECRTE
TABLE xxRTE Table POECRTE

XLANAME RTEREF POECGRP POECIDX DESTNAME NEWROUTE
---------------------------------------------------------------------------- --------------------------------------------------------------------------------
xxxXLA 1 S ROUTE1 POE_DATA 5 DATA_POECRTE T OVR1 1
31
The above example shows the link through the data tables for a call originating from a
trunk, this time screening for SPEECH or 64KDATA.
Incoming call on trunk group ITALYPVG.

Table TRKGRP.
Call processing accesses Table TRKOPTS to check for an entry for ITALYPVG and any
options.
Option CCNTLIDX specifies the index name INITIAL_SCREEN which is used to access
Table CALLCNTL.
In Table CALLCNTL, the index name INITIAL_SCREEN specifies the following;
INITIAL_SCREEN (SCRN (BC) $ ) $
The first instruction is SCRN, and the value to screen BC (Bearer Capability).
The same CALLCNTL index name is then used to access Table BCSCRN.
The index used is INITIAL_SCREEN with either SPEECH or 64KDATA
If the call is SPEECH, the call returns to CALLCNTL with the index name
SET_VOICE_CUSTGRP where the instruction is to change the Customer Group to
DEFAULT and continue to Centrex Translations.
31
If the call is 64KDATA, the call returns to CALLCNTL with the index name of
SET_DATA_POE.
This specifies the option of POECNAME.
The 2 options set are;
POECGRP POE_DATA with the POECGRP previously specified in Table POECNM.
POECIDX 5 This index number will be the link to Table POECRTE later.
The above options are stored in memory ready for use later on if required.
The call continues to Centrex Translations with the original Customer Group (CS2KCUST)
and NCOS (0).
On reaching a routing decision in a xxCODE Table, the tuple specifies that the call will
RTE to DEST 1, however the extra option of DESTNAME is the trigger to recall any POE
information stored in memory.
The DESTNAME of DATA_POECRTE, combined with the POECGRP and POECIDX

from Table CALLCNTL is then used to access Table POECRTE.
The key of POE_DATA 5 DATA_POECRTE specifies the NEWRTE of Table OVR1,
index 1.
Therefore the original routing from the xxCODE table is overridden with the Table
POECRTE data.
32
33
Information about the POE tables are as follows;
Table POECNM
This table specifies valid POE names to be used within the POE system.
The fields are VALUE numeric, 0-32767
SYMBOL 1-32 alphanumeric characters
Table DESTNAME
This table specifies valid names for use in Tables xxCODE and POECRTE
The fields are VALUE numeric, 0-32767
SYMBOL 1-32 alphanumeric characters
Table POECRTE
This table combines the valid POE name from POECNM with the POECIDX and
DESTNAME.
Fields are:
POECKEY, consisting of;
POECGRP from Table POECNM
POECIDX from Table CALLCNTL option POECNAME, POECIDX
DESTNAME from table DESTNAME
NEWROUTE Values are T Routing Table name and index
D - Treatment to be set for the call
P Continue the call with the previous route choice
The following pages show example TRAVERS of a SPEECH call and 64KDATA call.
34
TRAVER of SPEECH call using POE Screening/Routing
>traver tr italypvg 01234567890 b
TABLE TRKGRP
ITALYPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 N 0
TABLE TRKOPTS
TABLE CALLCNTL
INITIAL_SCREEN
(SCRN ( BC ) $)$
>speech
. . TABLE BCSCRN
. . INITIAL_SCREEN SPEECH SET_VOICE_CUSTGRP $
. TABLE CALLCNTL
. SET_VOICE_CUSTGRP (CUSTGRP DEFAULT) $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
DEFAULT 0 0 0 DFLT $
DEFAULT NXLA DFLTXLA NXLA 0 NDGT
TABLE DIGCOL
TABLE IBNXLA: XLANAME DFLTXLA
TUPLE NOT FOUND
DFLTXLA
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
35
TRAVER of SPEECH call using POE Screening/Routing - continued
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE FAHEAD
ATL)$ NOCON 9
TABLE FACODE
01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE)$
TABLE: FARTE
KEY: 01628FA 1
. S DANNAT
EXIT TABLE FARTE
TABLE TRIGGRP
ETSIGRP INFOANAL

>speech
1 DANNAT 01234567890 ST

1 UNOBT
>
36
TRAVER of 64KDATA call using POE Screening/Routing
>traver tr italypvg 01234567890 b
TABLE TRKGRP
ITALYPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0
TABLE TRKOPTS
TABLE CALLCNTL
INITIAL_SCREEN
(SCRN ( BC ) $)$
>64kdata
. . TABLE BCSCRN
. . INITIAL_SCREEN 64KDATA SET_DATA_POE $
. TABLE CALLCNTL
. SET_DATA_POE (POECNAME (POECGRP POE_DATA) (POECIDX 5) $)$
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
TABLE DIGCOL
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
37
TRAVER of 64KDATA call using POE Screening/Routing - continued
TABLE PXHEAD
CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 1
TABLE PXCODE
TUPLE NOT FOUND
TABLE POECRTE
TUPLE NOT FOUND
TABLE FAHEAD
01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CL
ATL)$ NOCON 9
TABLE FACODE
01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE)$
TABLE POECRTE
POE_DATA 5 DATA_POECRTE T OVR1 1
TABLE OVR1
1 S D SPAINPVG
EXIT TABLE OVR1
TABLE TRIGGRP
ETSIGRP INFOANAL

>64kdata
1 SPAINPVG 01234567890 ST

1 UNOBT
>
38
39
Call Control and Universal Screening Exercise 2 - Path Of Entry
Set up a Path of Entry Screening service so that calls arriving from your first partner trunk
group terminating to an area code of 01306, have the following destinations based on bearer
capability:
Speech calls should terminate to DANNAT, as before.
64kdata calls should terminate to UKPVG, with the prefix digits 22.
Set up path of entry screening in Table CALLCNTL.

Use additional CALLCNTL index of [Region]_POECNMx to set the POE parameters.
Use a POECGRP of [Region]xPOECGRP and a POECIDX of 1x .
Use a destination name of [Region]xDEST.
Use any available indexes in the following Routing Tables as required;
OVR1x.
(Where x is your group number)
NOTE
This exercise builds on the previous Call Control and Universal Screening exercise.
Your Table TRKOPTS entry should NOT be changed.
You should be able to build on the existing naming convention: [Region]xSCREEN
Test your datafill using TRAVER.
40
41
Least Cost Routing Engine
Switch A

Incoming ?
CS2000 ?
calls
Switch B
?

Switch C
42
Introduction
The CS2000 currently has a very flexible translation system which can support almost any
dialing plan in any network. The routing of a call is controlled from many different sources
such as trunk group, CLI, authorization code, access code, calling party category, etc.
Least Cost Routing (LCR) means routing calls to a route which represents the best value
based on cost, quality, availability of carriers. The operator must consider these criteria and
provision CS2000 with all possible combinations of carriers for each destination in existing
CS2000 translations.
The factors that affect LCR can change frequently. For example, a carrier may change its
pricing which may no longer make that carrier the best value. So the operator must monitor
these factors and update translations frequently. This process can be slow and inefficient
using the existing translations and routing tables on the CS2000 , which creates a need for a
simple, flexible interface for creating and manipulating routing plans based upon origination
and destination. This interface is the Least Cost Routing (LCR) Engine.
The LCR engine is a generic translations and routing function that incorporates the
flexibility of existing CS2000 translations with the requirements of an efficient, low-
maintenance LCR database.
42
The LCR engine includes the following:
quick and efficient updates to routing data
single point of interface for changing routing
ability to change multiple routes in few steps
automatic updates of routing using off-board equipment
implementation of all routing changes simultaneously
group common dialling plans (limit duplication of data)
The LCR engine uses two key components of CS2000 translations to determine the calls
origin and destination:
CS2000 screening functions
Path of Entry (POE) Screening and Destination Control functions on the CS2000 allow
screening of origination and destination information to determine the variables which are
used to make the routing decisions. The screening of origination information is provided
through table TRKOPTS and Call Control and Universal Screening. Destination
information is determined by digit analysis through the Universal Translations xxCODE
tables.
43
LCR Engine Components
CS2000
CS2000 LCR Engine
Origination Destination
Mapping Mapping
Mapping
Standby Function
Standby Route List 1
Output:
List of Route List 2
Route
Active Active Lists
Route List 3
SWACTing SWACTing
Function Function
Input 1: Input 2:
Incoming Path Of Entry Destination
Call Universal Translations
Existing CS2000
Screening Functions (Digit Analysis)
44
The LCR engine includes two databases:

Origination Mapping
Destination Mapping
The origination mapping maps the POE for each carrier to one or more route plans.
The destination mapping map these route plans to a list of route lists based on destination
information. The route lists are a set of destinations that a call can route to based on route
plans for a particular carrier. Currently routing tables must be provisioned with all possible
combinations of carriers for each destination, which could exhaust the capacity of routing
tables. The destination mapping will create route lists in a single database which will
alleviate exhaustion of routing tables.
Each database will have a standby and an active version. Data manipulation is allowed
only on the inactive (standby) version, where as call processing can only access the
active version.
The active and standby databases can be:

swapped (SWACT)
synchronised.
44
Origination Mapping Database
The origination mapping database consists of 2 tables:
the active table LCRORIG
the inactive table LCRORIG2
The purpose of this database is to map the POE information to a Route Plan Index.
The fields for LCRORIG/LCRORIG2 are as follows;
LCROKEY comprising of POECGRP and POECIDX, as previously seen.
RTEPLIDX Numerical index to Table LCRDEST (0-65000)
The following is an example of Table LCRORIG/LCRORIG2.
Table LCRORIG
LCROKEY RTEPLIDX
----------------------- -----------------------------
POE_BC 2 1000
The POE information (POECNAME) has two parts: POECGRP and POECIDX. POECGRP
has a string value which is defined in table POECNM, and POECIDX is an integer between
0 and 255.
The output of this table is a route plan index RTEPLIDX, which is used as one of two inputs
to the destination mapping database.
45
Destination Mapping Database
The destination mapping database consists of 2 tables:
the active table LCRDEST
the inactive table LCRDEST2
The purpose of this database is to map the originating and terminating information to a set
of route lists.
The fields for LCRDEST/LCRDEST2 are as follows;
TLCRKEY comprising RTEPLIDX, (0-65000) and DESTNAME (32 alpha-numeric
character)
LCR_ROUTE_LIST Vector of up to 16 multiples of OVRx, OFRx.
The following is an example of Table LCRDEST/LCRDEST2.
Table LCRDEST
LCRKEY LCR_ROUTE_LIST
----------------------------------------------------------------------------
100 NATL_CALL ( OVR1 4) ( OVR1 5) ( OVR1 6)$
RTEPLIDX is the value obtained from table LCRORIG which represents the originating
information. DESTNAME has a string value defined in table DESTNAME, the value of
which obtained from xxCODE and xx2CODE tables.
If more than one DESTNAME are datafilled in the xx/xx2CODE tuple, the most recent
DESTNAME will be used in LCR processing. The output of this table is a route list
consisting of the name of the routing table and its reference index. Multiple routes can be
datafilled to the route list.
Note that the reference index must first exist in the routing table before it can be datafilled
into the destination mapping tables.
46
Establishing an LCR Call
The following information is required for a call accessing the LCR database:
POECNAME - Includes POECGRP and POECIDX, obtained from table
CALLCNTL
DESTNAME - Obtained from tables XXCODE/xx2CODE tables.
The LCR engine is activated in table xxCODE/xx2CODE. The existence of an LCR option
will activate the least cost routing functionality.
If the LCR option is datafilled, call processing will ignore the XLA selector and route the
call based on the information in the LCR engine. However, if the LCR datafill is
incomplete, then the call will resume the use of the XLA selector.
All option selectors datafilled after the LCR option will first be executed prior to entering
the LCR engine.
If the DESTNAME is datafilled in RTE selector in table xxCODE, but the LCR option
is not, the call is treated as a POE screening call, and will access table POECRTE.
If the index used to access into LCRORIG or LCRDEST is not datafilled in those
tables, or the DESTNAME is not selected in table xxCODE, or the LCR option is not
present, the call will resume routing with its original course.
LCRORIG and LCRDEST tables will not be restored after ONP. Instead, the ONP
process will copy the content of the inactive tables (LCRORIG2 and LCRDEST2) to
the active tables.
47
LCR Call Flow
Table xxCODE
Table TRKGRP
DESTNAME N
option exists?
Table TRKOPTS
Y
LCR N
option exists?
Table CALLCNTL Y
POECNAME
index? exists? Y
N Table LCRORIG Continue
Y
Update as regular
POECNAME call
Centrex
Translations LCRORIG N
index exists?
Y
Universal Table LCRDEST

Translations
LCRDEST N
index exists?
Route call
Y using
RTELIST
48
The above slide illustrates the callflow for LCR.
The following TRAVERS give examples of LCR and POE.
Note. TRAVER can be used to test the inactive/standby datafill of LCRORIG2 and
LCRDEST2.
This enables operators to datafill and test without affecting real calls.
The first TRAVER illustrates the use of the LCRORIG2/LCRDEST2 tables by using the
following TRAVER command;
>traver tr italypvg 01234567890 lcr stdby b
The second TRAVER illustrates the use of the LCRORIG/LCRDEST tables by using the
following TRAVER command;
>traver tr italypvg 01234567890 lcr active b
48
TRAVER of an LCR Data call Standby tables
>traver tr italypvg 01234567890 lcr stdby b
TABLE TRKGRP
ITALYPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 N 0 0
0 0 N N N N N N N N N NATL $
TABLE TRKOPTS
TABLE CALLCNTL
INITIAL_SCREEN
(SCRN ( BC ) $)$
>64kdata
. . TABLE BCSCRN
. TABLE CALLCNTL
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
TABLE DIGCOL
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE POECRTE
TUPLE NOT FOUND
49
TRAVER of an LCR Data call Standby tables continued
TABLE FAHEAD
ATL)$ NOCON 9
TABLE FACODE
01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE) ( LCR )$
TABLE LCRORIG2
POE_DATA 5 200
TABLE LCRDEST2
200 DATA_POECRTE (OFR2 1) (OFR2 2) (OFR2 3) $
TABLE OFR2
1 S D GERMANYPRI
S D FRANCEPRI
EXIT TABLE OFR2
TABLE OFR2
2 S D FRANCEPRI
S D HOLLANDPRI
EXIT TABLE OFR2
TABLE OFR2
3 S D HOLLANDPRI
S D ITALYPRI
EXIT TABLE OFR2
TABLE TRIGGRP
ETSIGRP INFOANAL

>64kdata
1 GERMANYPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH
2 FRANCEPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH
3 HOLLANDPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH
4 ITALYPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH

1 UNOBT
50
TRAVER of an LCR Data call Active tables
>traver tr italypvg 01234567890 lcr active b
TABLE TRKGRP
ITALYPVG IBNT2 0 NPDGP NCRT CS2KCUST 0 DSEQ 0 N ANSDISC 0 Y N N N N N N 0 0 N 0 0
0 0 N N N N N N N N N NATL $
TABLE TRKOPTS
TABLE CALLCNTL
INITIAL_SCREEN
(SCRN ( BC ) $)$
>64kdata
. . TABLE BCSCRN
. TABLE CALLCNTL
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
TABLE DIGCOL
TABLE DIGCOL
TABLE LINEATTR
TABLE XLAPLAN
TABLE RATEAREA
TABLE PXHEAD
TABLE PXCODE
TUPLE NOT FOUND
TABLE POECRTE
TUPLE NOT FOUND
51
TRAVER of an LCR Data call Active tables continued
TABLE FAHEAD
ATL)$ NOCON 9
TABLE FACODE
01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE) ( LCR )$
TABLE LCRORIG
NO MAPPING ENTRY
TABLE POECRTE
POE_DATA 5 DATA_POECRTE T OVR1 1
TABLE OVR1
1 S D SPAINPVG
EXIT TABLE OVR1
TABLE TRIGGRP
ETSIGRP INFOANAL

>64kdata
1 SPAINPVG 01234567890 ST

1 UNOBT
52
Database Update and Manipulation
The LCR engine includes functions designed for quick and efficient manipulation of all
routing data. These functions include:
switch active and standby databases
query / select data based on: Path of Entry, Route Plan, Destination or Individual
route
add / remove Path of Entry, Route Plans, or Destinations
add / remove routes at any position in the list of route lists
replace / remove full route lists
copy entire route plans to new route plans
database synchronization (copy the active database to standby)
LCRSWACT Command
A LCRSWACT (Switch Active LCR) CI command is used to swap the standby and active
databases. This allows the information datafilled in the inactive version to be moved to the
active database, so that it can be used during call processing. Similarly, the information
previously present in the active database is moved to the inactive, allowing the user to make
changes to it.Calls immediately following the LCRSWACT will use the new database.
> LCRSWACT <ORIG/TERM/BOTH>
When LCRSWACT ORIG is employed. only the origination database is swapped.

When LCRSWACT TERM is employed, only the termination (destination) database is
swapped.
When LCRSWACT BOTH is employed, swapping of both origination and destination
databases will take place simultaneously.
53
LCRTM Tool User enters CI command
CI:
> LCRTM
User prompted for table selection
LCRORIG2
LCRORIG2 LCRDEST2 LCRDEST2
INSERT INSERT
SELECT SELECT
Insert LCRSYNC LCRSYNC Synchronise
Synchronise Insert
Select Select
INSERT LCRSYNC
LCRSYNC INSERT
SELECT
SELECT
UPDATE
UPDATE User can update or delete values DELETE
DELETE in a selected field ADDRTE
CHGRTE
DELRTE
Rudimentary Hierarchy for Table Management

54
LCRTM Tool
The LCR engine can be manipulated simply by editing the tables LCRORIG2 and
LCRDEST2 then using the command LCRSWACT to update the active database.
However, the LCRTM (LCR Table Management) tool allows quick and efficient
manipulation of all routing data using a list of available commands:
INSERT
SELECT
UPDATE
DELETE
ADDRTE (LCRDEST2 table only)
CHGRTE (LCRDEST2 table only)
DELRTE (LCRDEST2 table only)
LCRSYNC
54
Table Selection
Before any CI commands can be issued to manipulate the database in the LCRTM tool, the
user must first choose from the list of tables that support these CI commands. The choices
that exist are LCRORIG2 or LCRDEST2.
The figure below shows what is displayed when the LCRTM tool is entered.
CI:
> LCRTM
Next par is: <Table name> {LCRORIG2, LCRDEST2}
Enter: <Table name>
> LCRORIG2
LCRORIG2:
>
Or if table LCRDEST2 is chosen:
Next par is: <Table name> {LCRORIG2, LCRDEST2}

Enter: <Table name>
> LCRDEST2
LCRDEST2:
>
55
Subcommand Definition
INSERT Command
The INSERT command allows a user to add a new tuple to the selected table (similar to
the ADD command in Table Editor). The required INSERT command parameters are
listed as follows:
LCRORIG2:
> INSERT <POECGRP> <POECIDX> <RTEPLIDX>
LCRDEST2:
>INSERT <RTEPLIDX> <DESTNAME> <TABLE1> <INDEX1> [<TABLE2>
<INDEX2> <TABLE3> <INDEX3>. . .<TABLE16> <INDEX16>]
The parameters entered in this command must be valid entries for the particular field
values of table LCRORIG2/LCRDEST2.
Note: The INSERT command can potentially overwrite an existing tuple in the
LCRORIG2 or LCRDEST2 table.
The figure below shows some examples of the use of the INSERT command
LCRORIG2:
> INSERT POEGRP5 11 22
LCRORIG2:
LCRDEST2:
> INSERT 22 LONDON OFRT 1 OFRT 3 OFRT 5
LCRDEST2:
56
SELECT Command
The SELECT command allows the user to examine data from fields within the selected
table. The required SELECT command parameters are listed as follows:
> SELECT <Field> <Operator1> <Value> [<Operator2> <Field> <Operator1>

<Value>]
Field: This parameter refers to a particular field in either table LCRORIG2 or

LCRDEST2.
Value: This parameter refers to the value of the fields (search data).
Operator1: This parameter refers to EQ (equal) or NE (not equal) as the relationship
between field and value.
Operator2: This parameter enables a combination of values can be searched on using
AND/OR. There is also a NODISP option that can be placed at the end of the SELECT
command to select information but not display that information.
Note: Fields enclosed in [] are considered optional, however, if operator2 is utilized then
<field>, <operator>, and <value> are mandatory unless operator2 = NODISP.
The SELECT command must be entered before using the UPDATE, DELETE, ADDRTE,
CHGRTE or DELRTE commands
The following figures show some examples of the SELECT command.
LCRORIG2:
> SELECT RTEPLIDX EQ 100
Tuples Successfully Selected = 3
**** WARNING * WARNING * WARNING * WARNING ****

This operation could potentially overwrite
existing tuples in LCRORIG2.
POECGRP POECIDX RTEPLIDX

------------------------
POEGRP1 12 100
POEGRP1 15 100
POEGRP5 9 100
LCRORIG2:
SELECT:
>
57
LCRDEST2:
> SELECT RTELISTS EQ OFRT 1

existing tuples in LCRDEST2.
RTEPLIDX DESTNAME RTELISTS

--------------------------
15 FRANCE (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1)
21 UK (OFRT 1)
38 US (OVR2 8)(OFRT 5)(OVR3 3)(OFRT 1)
77 BRAZIL (OFR5 1)(OFRT 3)(OFRT 1)
120 CANADA (OVR8 5)(OFRT 1)
LCRDEST2:
SELECT:
>
LCRORIG2:
> SELECT POECGRP NE POEGRP1 NODISP

LCRORIG2:
SELECT:
>
58
UPDATE Command
Once a field has been selected, the UPDATE command allows users to make changes to
values. The required UPDATE command parameters are listed as follows:
UPDATE <Update Field> EQ <New Value> [<Update Options>]
Update Field: This parameter represents the section of data the user wants to modify.
New Value: This parameter denotes what the user wants to change the existing value to.
Update Options: This is an optional field in which the user can update additional field(s)
within the tuple and/or choose to not display the tuple once updated. The options include
the fields contained in Update field with the addition of NODISP.
Note: Upon updating a tuple, the following actions will take place:
Any data that was saved off from the SELECT command will be removed.
The user will be taken out of the SELECT level and put in the appropriate
LCRORIG2 or LCRDEST2 level.
Update can potentially overwrite an existing tuple in the LCRORIG2 or LCRDEST2
tables. For example, if a tuple is selected and the update is such that it creates a tuple that
already exists (base on its key) in the table, the existing tuple will be overwritten by the
selected tuple. If an update causes a tuple or tuples to be deleted, a warning message will
appear indicating how many selected tuples were deleted.
The following figures show some examples of the UPDATE command.
59
LCRDEST2:
> SELECT RTPLIDX EQ 120 AND DESTNAME EQ UK


--------------------------
120 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1)
LCRDEST2:
SELECT:
> UPDATE RTELISTS EQ OFRT 12
Tuples Successfully Updated = 1

--------------------------
120 UK (OFRT 12)
LCRDEST2:>
LCRDEST2:
> SELECT DESTNAME EQ UK


--------------------------
LCRDEST2:
SELECT:
> UPDATE RTEPLIDX EQ 150

--------------------------

Selected tuples deleted due to update ========> 1
LCRDEST2:
>
60
DELETE Command
The DELETE command allows the user to remove a tuple/tuples once a field has been
selected. There are no required parameters in the DELETE statement.
Note: Upon completion of the delete command, the user will automatically be taken out of
the SELECT level and placed into the appropriate LCRORIG2/LCRDEST2 level.
The following figure shows an example of the DELETE command.
LCRORIG2:
> SELECT RTEPLIDX EQ 100

POECGRP POECIDX RTEPLIDX

--------------------------
POEGRP1 12 100
POEGRP1 15 100
POEGRP5 9 100
SELECT:
> DELETE
Tuples Successfully Deleted = 3
LCRORIG2:
>
61
ADDRTE Command
The ADDRTE command adds routes to a specific position in an existing route list for the
LCRDEST2 table. This position will be based on the parameter passed into ADDRTE.
The required ADDRTE command parameters are listed as follows:
>ADDRTE <Table Name> <Index Value> <Position> [<Operator>]
Table Name: This parameter specifies the name of the routing table.
Index Value: This parameter specifies the index into the above-mentioned table.
Position: This parameter specifies at which position the new route should be added to
within the existing route list. The user can enter 1 - 16 and the items on the existing route
list after the specified value will be moved down by one. If there are less than 16 items on
the list, selecting 16 will automatically place the route at the end of the route list.
Operator: The only option for tis is NODISP which prevents the modified tuples from
being displayed.
Note: Upon completion of the ADDRTE command, the user will automatically be taken
out of the SELECT level and placed into the LCRDEST2 level.
The following figure shows some examples of the ADDRTE command.
LCRDEST2:
> SELECT (RTEPLIDX EQ 120) AND (DESTNAME EQ UK)


------------------------------------------------
120 UK (OFRT 1)(OFRT 10)
SELECT:
> ADDRTE OVR8 3 1

--------------------------
120 UK (OVR8 3)(OFRT 1)(OFRT 10)
LCRDEST2:
>
62
CHGRTE Command
The CHGRTE command allows the user to change an existing entry in a route list to a
new value. The required CHGRTE command parameters are listed as follows:
> CHGRTE <Old Table Name> <Old Table Index> <New Table Name> <New Table
Index> [<Operator>]
Old Table Name: This parameter combined with the Old Table Index represents the route
that will be changed.
Old Table Index: This parameter combined with the Old Table Name represents the
route that will be changed.
New Table Name: This parameter combined with the New Table Index represents the
route which will replace the existing route.
New Table Index: This parameter combined with the New Table Name represents the
route which will replace the existing route.
Operator: The only option for this is NODISP which prevents the modified tuples from
being displayed.
Note: Upon completion of the CHGRTE command, the user will automatically be taken
out of the SELECT level and placed into the LCRDEST2 level.
The following figure shows some examples of the CHGRTE command.
LCRDEST2:


------------------------------------------------
120 UK (OFRT 1)(OFRT 10)
LCRDEST2:
> CHGRTE OFRT 10 OVR3 3

--------------------------
120 UK (OFRT 1)(OVR3 3)
LCRDEST2:
>
63
DELRTE Command
The DELRTE command allows the user to delete an existing entry from the route list. The
required DELRTE command parameters are listed as follows:
> DELRTE <Table Name> <Index Value> [<Operator>]
Table Name: This parameter combined with the Index Value represents the route to be
deleted.
Index Value: This parameter combined with the table name represents the route to be
deleted.
Operator: The only option for this is NODISP which prevents the modified tuples from
being displayed.
Note: Upon completion of the delrte command, the user will automatically be taken out of
the SELECT level and placed into the appropriate LCRORIG2/LCRDEST2 level. If the
DELRTE operation can potentially result in 0 routes for an LCRDEST2 tuple, the
DELRTE command will be rejected and the user will be prompted to either perform a
CHGRTE, UPDATE or DELETE within LCRTM:LCRDEST2.
The following figure shows some examples of the DELRTE command.
LCRDEST2:


-----------------------------------------------
120 UK (OVR8 3)(OFRT 1)(OFR2 2)(OFRT 10)(OFR4 1)
SELECT:
> DELRTE OFRT 1

-----------------------------------------------
120 UK (OVR8 3)(OFR2 2)(OFRT 10)(OFR4 1)
LCRDEST2:
>
64
LCRSYNC Command
The LCRSYNC command synchronizes data between the active and standby databases,
i.e. copying the database from the active to the standby. The usual occasion when
LCRSYNC is used is after LCRSWACT occurs. Once the active table becomes the same
as the inactive table, the changes made in the updated table can be copied back to the
inactive table.
There is no parameter associated with LCRSYNC.
Note: If a user tries to issue LCRSYNC when the active table is empty, an additional
warning followed by a yes/no prompt is issued:
The following figure shows some examples of the LCRSYNC command.
LCRORIG2:
> LCRSYNC
*** WARNING: Data in the LCRORIG2 table will be changed
Please confirm (YES, Y, NO, N)
>Y
*** WARNING: Data synchronization in progress.

*** WARNING: Please DO NOT perform any table control
*** WARNING: operations until LCRSYNC is complete.
SYNC: 25% completed
50% completed
75% completed
LCRORIG database is synchronized.
>
LCRORIG2:
>
LCRDEST2:
> LCRSYNC
***WARNING: Active table is empty. LCRSYNC will erase
***WARNING: all existing datafill in the inactive table
Please confirm (YES, Y, NO, N)
>N
LCR database is not changed
LCRORIG2:
>
65
Summary
The LCR engine is a generic translations and routing function that
incorporates the flexibility of existing CS2000 translations with the
requirements of an efficient, low-maintenance LCR database
The LCR engine includes two databases: origination mapping and
destination mapping. The origination mapping maps the POE for each
carrier to one or more route plans. The destination mapping map these
route plans to a list of route lists based on destination information.
Each database consists of two tables: LCRORIG/LCRORIG2 for the
origination database and LCRDEST/LCRDEST2 for the destination
database.
The following information is required for a call accessing the LCR
database:
POECNAME - Includes POECGRP and POECIDX, obtained from
table CALLCNTL
DESTNAME - Obtained from tables XXCODE/xx2CODE tables.
The TRAVER command includes an LCR option for verifying calls that
use the LCR engine.
The LCR databases can be updated using table editor on tables
LCRORIG2 and LCRDEST2, or by using the LCRTM tool.
66
67
Call Control and Universal Screening Exercise 3 - Least Cost Routing
Least Cost Routing Exercise 1
Building on previous exercises, Students are to setup LCR.
Your task is as follows;

Build new OVR1x Route table index thus;
OVR1x 1 S D ITALYPVG
S D SPAINPVG $ $
2 S D FRANCEPVG
S D HOLLANDPVG $ $
Your task is then to route 64KDATA calls via the above routes using LCR instead of the
UKPVG route specified previously in Call Control Exercise 1.
Evaluate the tables required and plan your datafill.

Once satisfied, datafill the switch and test with TRAVER.
Least Cost Routing Exercise 2 (Optional)
Using the LCRTM CHGRTE utility, modify your LCRDEST route lists to the following;
From OVR1x, index 1 to OFRT index 1 .
NOTE There are restrictions on the number of simultaneous uses of LCRTM.

Please check with your instructor when you are ready to enter the second exercise.
68
69
Appendix A
PRI Trunk Groups
nortel.com/training
0
1
Appendix A PRI Trunk Groups
Purpose
concepts of;
> PRI Trunk Groups and their datafill.

List the tables used to establish PRI voice calls.
Optional PRI trunk group datafill exercise
2
2
3
CUSTENG Universals
CUSTHEAD
IBNXLA
NCOS
IBNTREAT
CLLI
TRKGRP LTCALLS
TRKSGRP LTMAP
TRKMEM LTDEF
Trunks
4
4
5
5
Trunk Network the big picture
PBX
R.O.W B
Switch
A
Switch PBX
C A
Switch
B Switch
E
6
PRI Trunk Groups

PRI (or ISDN) Trunks form the physical connection between exchanges. The exchanges
may be either Public exchanges or PBXs (Private Branch eXchanges).
The above diagram illustrates a simple group of switch linked together. The links between
the switches are designated as Trunk Groups.
group and NCOS.
6
Services or
CS2000
CS2000 CS2000c MCS
Back Announcements
IEMS GWC
Management CS LAN
USP

IP
PSTN
MG15K Network CMTS
Video
Hosted PBX Feed
Centrex IP HFC
HFC
Derived Lines PBX

Cable
Modem
CPE
xDSL
IAD
IAD
m6350 i2004 DSLAM
Softclient Etherset
7
In a CS2000 environment, calls to the Public Switched Telephone Network

(PSTN) would ingress/egress via an MG15k ISUP/PRI Gateway.
These gateways would be hosted by the CS2000s GWCs.
Direct trunks from PBXs would also be hosted in a similar method.
7
Outgoing PRI Translations
Line Centrex PRI

Originated Translations Outgoing
Call Trunk CLLI
Routing Tables Private
(IBNRTE & OFRT) Call
Public
Call
Universal Routing Tables

Translations (IBNRTE & OFRT)
8
Outgoing PRI Translations
A line has a Customer Group and NCOS which links the line into Centrex translations for
the purpose of analysing the dialled digits and translating them into an outgoing routing
conclusion. From here there is one of three things that can take place based on the digits
dialled and the way in which translations have been set up:-
1. The call routes direct from Centrex translations to the outgoing PRI trunk
CLLI. In this case the called number (CDN) that may be sent over the
outgoing PRI trunk will be of the type PVT.
2. The call routes from Centrex translations to routing tables (IBNRTE or

OFRT) and then to the outgoing PRI trunk CLLI. In this case the called
number (CDN) that may be sent over the outgoing PRI trunk will be of the
type PVT.
3. The call routes from Centrex translations, through Universal translations &
routing tables (IBNRTE or OFRT), and then to the outgoing PRI trunk CLLI.
In this case the called number (CDN) that may be sent over the outgoing PRI
trunk will be of the type PUBLIC (E.164).
8
TRAVER of Outgoing Private call
>TRAVER L 8795507 66015028 B
TABLE IBNLINES
HOST 00 0 00 07 0 DT STN IBN 8795507 IBNDEMO 0 0 162 (COTAMA) $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE NCOS
TABLE DIGCOL
DCDEMO 6 COL S 3
TUPLE NOT FOUND
CXDEMO 6601 ROUTE N N N 4 N 8 8 NDGT Y S PRITG1 $
TABLE DIGCOL
1 PRITG1 N CDN PVT L 5028 NIL_NSF BC SPEECH

1 GNCT

>
9
TRAVER of Outgoing Public Call
>TRAVER L 8795507 66025028 B
TABLE IBNLINES
HOST 00 0 00 07 0 DT STN IBN 8795507 IBNDEMO 0 0 162 (COTAMA) $
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
TABLE NCOS
TABLE DIGCOL
DCDEMO 6 COL S 3
TUPLE NOT FOUND
CXDEMO 6602 NET N N N 0 N NDGT N Y DOD N 602 NONE $
TABLE DIGCOL
TABLE LINEATTR
602 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRINET NIL $
TABLE PXHEAD
PRINET SDFLT NODFOP CON STD
TABLE PXCODE
PRINET 6602 6602 RTE ( MM 8 8) ( DEST 602)$
TABLE: PXRTE
KEY: PRINET 602
. T OFRT 602
. . TABLE OFRT
. . 602 S D PRITG1
. . EXIT TABLE OFRT
EXIT TABLE PXRTE

1 PRITG1 N CDN E164 L 66025028 NIL_NSF BC SPEECH

1 GNCT
10
Incoming PRI Translations
PRIVATE PUBLIC
CALL CALL
Table TRKGRP
Table LTCALLS
CENTREX TRANSLATIONS Table OFRT/IBNRTE UNIVERSAL TRANSLATIONS

(Table IBNXLA etc) (Table PXCODE etc)
11
Incoming Translations
This section describes the datafill required for the PRI call routing capability. PRI call
routing establishes the routing of calls over the PRI interface. A PRI call comes into the
DMS-100 switch over a PRI trunk and is switched to a line or trunk. The following call
types are supported.
The call type is conveyed between switches by the Q.931 SETUP message. The call type
determines the translations that will be used to route an incoming call. The call type is
significant only to the local PRI. Once inside the exchange, it is discarded. Subsequent
legs of the same call can have different call types.
The SETUP message contains information about a call. The Numbering Plan Indicator
(NPI) is contained in the Called Party Number (CDN) IE in the Q.931 SETUP message.
The NPI indicates whether the numbering plan used for the called number is public or
private.
In order to implement PRI call routing, Table LTCALLS must first be datafilled:
Note: Public translations can use any of the selectors in Table LTCALLS whereas Private
translations can only use XLAIBN and RTEREF.
11
Private Incoming Calls
> SETUP message contains CDN
PRIVATE info element which indicates that
the type of number being dialled
CALL is a Private call.
> TABLE LTCALLS:-
Table TRKGRP I/C PRIVATE CALLS:-
XLAIBN :- Customer
group & NCOS link PVT
calls into Centrex
translations.
RTEREF :- Links PVT
Table LTCALLS calls direct to Table
OFRT or IBNRTE
XLAIBN RTEREF
Table OFRT/IBNRTE
CENTREX TRANSLATIONS
(Table
12 IBNXLA etc) NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY
Table LTCALLS
Table LTCALLS provides initial translations for the calls incoming from the trunk group.
The table is datafilled with the trunk groups LTID (the LTID is defined in Table
LTDEF), the call type (i.e. PUB or PVT) and the initial translations route for the call.
Table LTCALLS used for Private Translations
>TABLE LTCALLS
LTID XLARTSEL OPTIONS

-------------------------------------------------------------------------------------------------
QNSX 230 PVT XLAIBN 204 QUEENSX00MEL 0 10 $
>
Note you cannot use the XLALEC selector with Private calls.
12
TRAVER of Incoming Private (PVT) call
>TRAVER TR PRITG2 N CDN PVT 5505 B
TABLE TRKGRP
PRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $
TABLE LTCALLS
MMPRI 2 PVT XLAIBN 682 IBNDEMO 0 0 $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT) ( DFT )$
TABLE DIGCOL
DCDEMO 5 COL S 3
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE TOFCNAME
162 879
TABLE DNINV
162 879 5505 L HOST 00 0 00 05
TABLE DNATTRS
TUPLE NOT FOUND
TABLE DNGRPS
TUPLE NOT FOUND
1 LINE 1628795505 ST

1 GNCT
13
Public Incoming Calls
PUBLIC SETUP message contains CDN
CALL
info element & indicates that the
type of number being dialled is a
Public (E.164) call.
Table TRKGRP
TABLE LTCALLS:-
I/C PUBLIC CALLS:-
XLAIBN :- LINEATTR
links E.164 calls into
Table LTCALLS Universal translations.
NCOS may also be used
for COSMAPPING (See
XLAIBN RTEREF XLALEC Later)
RTEREF :- Links E.164
calls direct to Table OFRT
or IBNRTE
XLALEC:-LINEATTR links
Table OFRT/IBNRTE E.164 calls into Universal
translations. No NCOS for
COSMAPPING (See later)
Universal Translations Universal Translations
14
XLALEC allows a LINEATTR to be specified linking public calls into Universal

Translations.
XLAIBN allows a LINEATTR to be specified linking public calls into Universal

Translations.
Note 1:- with XLAIBN the NCOS value datafilled in LTCALLS can be used for
COSMAPPING later.
Note 2:- The customer group specified in LTCALLS against a public tuple cannot be
used to link public calls into Centrex translations; it only works with Private
calls.
RTEREF allows a Table Name & Index to be specified linking the calls direct to Table
OFRT or Table IBNRTE without routing through Centrex or Universal
Translations.
>TABLE LTCALLS

--------------------------------------------------------------------
QNSX 230 PUB XLALEC 204 $
>
14
TRAVER for Incoming Public (E164) call
>TRAVER TR PRITG2 N CDN PUB 66025505 B
TABLE TRKGRP
TABLE LTCALLS
MMPRI 2 PUB XLALEC 782 $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE LINEATTR
782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$
TABLE PXHEAD
PRIUSER SDFLT NODFOP CON STD
TABLE PXCODE
PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 678) ( CLASS NATL)$
TABLE: PXRTE
KEY: PRIUSER 678
. T IBNRTE 678
. . TABLE IBNRTE
. . 678 DN 162 879 N 0
EXIT TABLE PXRTE
1 LINE 1628795505 ST

1 GNCT

>
15
Linking Public Calls Into Centrex
Translations.
>TABLE LTCALLS

------------------------------------------------------------------------------
MMPRI 1 PUB RTEREF IBNRTE 66 $
>TABLE IBNRTE
RTE RTELIST
--------------------------------------
66 (RX IBNDEMO 0 30 25 $) $
>TABLE DIGMAN
DMIKEY DMIDATA
----------------------------------------------------------------------------
25 ( REM 4)$
16
It may be required to translate incoming PRI public calls using Centrex translations. In this
case the RTEREF selector should be used in Table LTCALLS which links the incoming
public calls to Table IBNRTE.
In Table IBNRTE using the RX selector you are able to re-translate the dialled digits
using a specified Customer Group & NCOS. This will link the call back into Centrex
translations. Note digit manipulation is also possible since the IBNRTE tuple has the
possibility of specifying an index into Table DIGMAN.
Note: Table DIGMAN is used to remove the leading 4 digits in this example.
16
TRAVER for Public (E164) call
>TRAVER TR PRITG1 N CDN PUB 67825028 B
TABLE TRKGRP
TABLE LTCALLS
MMPRI 1 PUB RTEREF IBNRTE 692 $
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE IBNRTE
692 RX IBNDEMO 0 0 25 $
. TABLE DIGMAN
. 25 (REM 4)
. EXIT TABLE DIGMAN
EXIT TABLE IBNRTE
1 LINE 1628795028 ST

1 ENGAGED
>
Note: Traver does not show the retranslation, but the result is correct.
17
Table LTCALLS summary
PVT PUB
XLAIBN RTEREF XLAIBN XLALEC RTEREF
LINEATTR OFRT/IBNRTE LINEATTR LINEATTR OFRT/IBNRTE
CUST GRP INDEX CUST GRP INDEX
RX
Cust Grp
NCOS NCOS +
NCOS
Centrex Bypass Centrex Universal Universal XLA Bypass Centrex

XLA XLA XLA (No COSMAPPING) Universal XLA XLA
18
18
Table CLLI
CLLI names are used to identify a variety of resources on the CS2000 amongst which are
Tones, Announcements and Trunk groups. The fields in table CLLI are the same, regardless
of the use to which the CLLI name is put. The CLLI name provides the link through all the
following trunk tables and may be pointed to from a variety of other tables in the Centrex or
Universal translations environment.
Table TRKGRP
The datafill for table TRKGRP potentially differs dependant on the direction type and the
signalling type.
Table TRKSGRP
a trunk group which means that trunks of a different signalling type may be grouped
together within a single group, however, this is not common practise.
Table TRKMEM
Table TRKMEM defines and allocates the hardware resource used by each individual trunk
within the trunk group. One physical connection may contain a number of trunks as in a
PCM 30 circuit, or only a single trunk.
Table LTMAP
Table LTMAP maps logical terminals to trunk span DS-0 location and the terminal
equipment interface.
Table LTCALLS
Table LTCALLS stores service-related data, such as translations, that the CS2000 switch
associates with the call type.
19
As previously mentioned PRI trunks can route to Universal Translations via different tables.
Table CLLI is datafilled as previously shown.
Table TRKGRP is datafilled with the GRPTYP of PRA (Primary Rate Access).
The primary rate access (PRA) trunk group type is used when a minimum of service and
translation related data, such as billing and trunk selection information, is required.
Table LTDEF defines the service profile of an ISDN logical terminal identifier (LTID).
Table LTCALLS allows;

Access to Centrex Translations using the XLARTE of XLAIBN.
Access to routing tables using the XLARTE of RTEREF.
Access to Universal Translations via Table LINEATTR using the XLARTE of
XLALEC.
For this example the last choice - XLALEC, will covered.
Table LTMAP maps logical terminals to trunk span DS-0 location and the terminal
equipment interface.
Examples of these tables datafill follows.
20
Table TRKGRP Example (PRI)
TABLE TRKGRP
GRPKEY GRPTYP TRAFSNO PADGRP NCCLS SELSEQ BILLDN
ukpri pra 0 npdgp ncrt aseq n
LTID OPTION
$ $
21
The fields are:-

GRPKEY Group key. This field contains the subfield CLLI and the CLLI name of the
trunk group should be entered here. The CLLI name must have been
established in table CLLI before it can be entered here.
GRPTYP Group type. Enter the trunk group type. For PRI trunks this is PRA.
TRAFSNO As per C7UP TRKGRP example
PADGRP As per C7UP TRKGRP example
NCCLS As per C7UP TRKGRP example
SELSEQ As per C7UP TRKGRP example
BILLDN As per C7UP TRKGRP example
LTID Logical terminal identifier This subfield consists of subfields LTGRP and
LTNUM. These read-only subfields display the LTID that has been mapped
to the trunk group by table LTMAP. Subfield LTID cannot be datafilled by
operating company personnel. Enter $.
OPTION Options. Enter any options required.
21
Table TRKSGRP Example (PRI)
TABLE TRKSGRP
SGRPKEY CARDCODE SGRPVAR PSPDSEIZ PARTDIAL VERSION
ukpri 0 ds1sig isdn 4 4 87q931
CRLENGTH BCHNEG BCHGLARE IFCLASS CONFIG LOCATION SAT
2 n stand network pt_pt user n
ECSTAT NSMATCH AUTOON TRKGRDTIM L1FLAGS PARMNAME PMTYPE
Internal n n 70 n default gwc
GWCNO GWCNODENO GWCTRMNO DCHRATE HDLCTYPE PMTYPE
1 8 315 64k hdlc $
OPTION
$
22
The above is an example of PRI or Integrated Services Digital Network (ISDN).
For the above example the fields are:-
SGRPKEY Subgroup key. This field comprises the subfields CLLI and SUBGRP, the
CLLI name of the trunk group and the trunk subgroup number.
CARDCODE Enter the card type used to support the trunks. This may differ dependant on
the signalling system. ISDN uses DS1SIG.
SGRPVAR Enter ISDN for ISDN type trunks.
PSPDSEIZ Permanent signal or partial dial on seizure timing. Enter the time, in seconds,
that the trunk waits for reception of the first digit.
PARTDIAL Partial dial timing. Enter the time, in seconds, that the trunk has to wait for
reception of each digit, excluding the first digit.
VERSION Protocol version. Enter the version of the protocol. Value for all PRI variants.
Value for all QSIG variants.
CRLENGTH Call reference length. Enter the number of octets in the call reference.
BCHNEG B-channel negotiation. Enter Y (yes) if B-channel negotiation is allowed.
Otherwise, enter N (no).
BCHGLARE B-channel glare. Enter YIELD if the B-channel is used in set-up messages,
simultaneously in both directions, or if the call must be taken down by this
switch. Enter STAND if the switch must wait for the other switch to yield.
IFCLASS Interface class. Enter NETWORK if it is the network end.
Enter USER if the PRA link is considered the user end of the protocol.
22
CONFIG Configuration. If broadcast procedures are to be used on this interface, enter
PT_MLT_PT (point-to-multipoint). Otherwise, enter PT_PT (point-to-point).
LOCATION Location. Enter the location to be used if creating CAUSE information
elements. The following CAUSE information elements are contained in
release messages that map to a specific treatment:
LOCALEO - local end office (public network) location
PVTNET private network location
USER - user location
LOC_MAP location map
SAT Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a
satellite. If not, enter N, (no).
ECSTAT Echo canceler status. Enter UNEQ to indicate that Echo canceler is not
equipped on this subgroup.
NSMATCH Noise match control. Enter N to indicate that background noise is not
maintained if internal echo canceler status is actively cancelling echoes.
The default is N.
AUTOON Auto re-enable control. Enter N to indicate that the echo canceler status is
not automatically turned on after the 2100-Hz tone control is removed. This
option is similar to the END OF CALL option for tone disablers in external
echo canceler status.
The default is Y.
TRKGRDTIM Trunk lock-out timeout. If the entry in field DIR is OG, enter the time, in 10-
ms intervals, that the trunk waits to receive on-hook from the far-end before
reporting lock-out on the trunk. The timer begins on sending an on-hook
signal to the far-end.
L1FLAGS Layer 1 flags. This field is used by ISDN primary rate access (PRA) trunks to
indicate whether or not the ISDN DTC (DTCI) sends layer 1 flags if the D-
channel is in flagfill mode. Enter Y if the connection is between CS2000 and
a different vendor. Enter N for CS2000-to-CS2000 PRA connections.
PARMNAME ISDNPARM name Enter a name in table ISDNPARM.
This field associates the information found in table ISDNPARM with the
primary rate interface defined by the table TRKSGRP tuple. The default is
DEFAULT.
PMTYPE Peripheral module type.
GWCNO Gateway Controller Number
GWCNODENO Gateway Controller Node Number.
GWCTRMNO Gateway Controller Terminal Number
DCHRATE D-channel data rate. Enter the data rate of the D-channel, 56K or 64K. The
data transmission rate of the carrier (DS-1) and of the D-channel on it must
be compatible. If the carrier is datafilled to transmit at 56K, then the entry in
field DCHRATE must also be 56K.
HDLCTYPE High level data link type. Enter HDLC or INVHDLC.
HDLC for high level data link or INVHDLC for inverted high level data link.
23
Table LTDEF Example
TABLE: LTDEF
LTKEY LTAP CLASSREF
PRI 1 B PRA 30 ETSIPRI 1990 NIL (NOPMD ) $
24
For the above example the fields are;
LTKEY Logical terminal key. This field consists of subfields;

LTGRP - alphanumeric (up to 8 characters) Logical
terminal group.
LTNUM - 1 to 1022 Logical terminal number.
LTAP B For circuit switching or for ISDN MFT terminals, enter B.
CLASSREF Class reference field consists of; LTCLASS
PRA For primary rate access, enter PRA.
. NUMBCHNL 1 to 479
VARISSUE see subfields This field consists of subfields
VARIANT and ISSUE.
ETSIPRI - ETSI PRI (Europe)
1990
PROFNAME (alphanumeric to 8 characters)
OPTION Up 4 Options may be added. See NTP for details.
24
Table LTCALLS Example
TABLE LTCALLS
LTID XLARTE LINEATTR XLAPLAN RATEAREA LTCOPT
pri 7 pub xlalec 1 cs_nprt cs_nil $
25
LTID Logical terminal identifier. This field consists of subfields;

LTGRP - alphanumeric (up to 8 characters) Logical
terminal group.
LTNUM - 1 to 1022 Logical terminal number.
CALLTYPE - PUB (Public).
Note other Calltypes are available, see NTP for details.
XLARTE XLALEC Enter XLALEC for local exchange carrier translations.
Note other XLARTEs are available, see NTP for details.
LINEATTR - alphanumeric (1 to 16 characters) Line
attributes index.
XLAPLAN - valid entry from Table XLAPLAN
RATEAREA - valid entry from Table RATEAREA
LTCOPT Logical terminal option. See NTP for details.
25
Table LTMAP Example
TABLE: LTMAP
LTKEY MAPPING OPTION
PRI 1 CLLI FRANCEPRI ( TEI 0) $
PRI 2 CLLI GERMANYPRI ( TEI 0) $
PRI 3 CLLI HOLLANDPRI ( TEI 0) $
PRI 4 CLLI ITALYPRI ( TEI 0) $
PRI 5 CLLI SPAINPRI ( TEI 0) $
PRI 6 CLLI UKPRI ( TEI 0) $
26

LTKEY This field consists of subfields LTGRP and LTNUM.
LTGRP Logical terminal group datafilled in table LTGRP.
LTNUM Logical terminal number (1 to 1022 )
MAPPING This field consists of subfield MAPTYPE.
MAPTYPE CLLI, LEN or XSG
Logical terminal mapping type Enter the type of mapping
being used.
Enter CLLI and datafill refinement CLLI.
Enter LEN and datafill refinement LEN.
Enter XSG and datafill refinement XSG.
For primary rate access (PRA), the logical terminal
identifier must be mapped to a CLLI.
CLLI Common language location identifier
Enter the CLLI of the PRA trunk to which the logical
terminal is assigned.
OPTION TEI 0 to 63 Terminal endpoint identifier
Enter the terminal endpoint identifier that is specified for
static TEI terminals.
Other options are available, see NTPs for details.
26
27
PRI Bearer Capability Routing
PVG
CS2000 Gateway
PVG
PRI 64k Data
Gateway
Incoming
PSTN
PRI Call CS LAN
Voice
PVG
Gateway
28
Bearer Capabilty Routing
ETSI PRI supports bearer capability routing. This is the ability to route calls incoming from
a PRI trunk based on the associated bearer capability. For example, this could be used to;
separate data traffic (64K clear) onto high quality routes
separate 3.1KHz traffic from speech, avoiding echo cancellers
Bearer Capability (BC) routing is the capability which enables the routing of ISDN calls
based on routing characteristics. The routing characteristics that are considered are found in
the Called Party Number IE and the Bearer Capability IE. The fields relating to these
routing characteristics are:
BC - Bearer Capability (Speech, unrestricted digital etc.)
CDN - Called Party Number (PVT or PUB)
For incoming PRI calls to the DMS-100, routing characteristics are defined in the inbound
SETUP message. For outgoing PRI calls, the DMS creates a SETUP message that specifies
the routing characteristics of the call.
The following tables need datafilling in the order listed to perform BC routing:-
Table BCDEF
Table RCNAME
Table RTECHAR
28
Table BCDEF
Table BCDEF contains all the valid bearer capability names. Each tuple in the table lists
a BCNAME and its associated transmission characteristics, which include the trunks
transfer capability, transfer mode, and coding standard. The BCNAME is used in table
RTECHAR to represent its associated transmission characteristics.
>TABLE BCDEF
KEY BCDATA
-----------------------------------------------------------------------------------------------------
SPEECH SPEECH CIRCUIT CCITT
64KDATA UNRESDIG CIRCUIT CCITT
64KX25 RESDIG CIRCUIT NETWORK DTU X25 Y AUTO
56KDATA UNRESDIG CIRCUIT NETWORK DTU NONE Y 56KBS
DATAUNIT UNRESDIG CIRCUIT NETWORK DTU TLINK Y 56KBS
64KRES RESDIG CIRCUIT CCITT
3_1KHZ AU3_1KHZ CIRCUIT CCITT
7_KHZ AU7KHZ CIRCUIT CCITT
VOICE_DATA AU3_1KHZ CIRCUIT CCITT
64K_RATE_AD_DATA UNRESDIG CIRCUIT CCITT
>
Table RCNAME
Table RCNAME contains all the valid routing characteristic names. Each tuple in the
table lists an RCNAME which is associated with a group of routing characteristics in table
RTECHAR. The RCNAME is used in tables throughout the translation and routing
process to represent its associated routing characteristics.
>TABLE RCNAME
NAMEKEY
---------------------
64K
31K
Table RTECHAR
Table RTECHAR defines an RCNAME by assigning it a set of routing characteristics. For
each RCNAME, up to seven sets of routing characteristics can be listed. the table allows
call routing based on the services identified by the BCNAMEs.
>TABLE RTECHAR
RCKEY GROUPRC
----------------------------------------------------------------------------
64K (BC 64KDATA $) $
31K (BC 3_1KHZ $) $
The way that subsequent translations are datafilled for BC routing differ from Private and
Public calls and will be discussed separately next.
29
Private Call (Centrex Translations)
CUSTGRP + NCOS RCNAME eg 64k from
Table RTECHAR
NCOS or XLTR Name

CUSTHEAD XLAMAP
XLTR Name New XLTR Name
IBNXLA IBNXLA
Speech Call Data Call

To LINEATTR
FOR PUBLIC
CALLs
OFRT /IBNRTE OFRTMAP /IBNMAP OFRT /IBNRTE
Nil Entry
ROUTE A ROUTE B
30
Private Call (Centrex Translations)

The diagram above illustrates the principle of BC routing in Centrex translations.
Notice that a private 64k data call picks up a new translator in Table XLAMAP to analyse
the incoming digit stream. This will only occur when a match is found in table XLAMAP.
The key to Table XLAMAP is a Translator Name + RCNAME.
Because there is no match in Table XLAMAP for SPEECH calls they continue to use the
existing translator to analyse the incoming digit stream.
>TABLE XLAMAP
XLAKEY DATA
---------------------------------------------------------------------------------
64K CXDEMO ( XLA CXDEMO1)$
64K PXDEMO1 ( XLA CXDEMO)$
64K PXDEMO2 ( XLA DATA)$
30
Private BC Speech Call Traver
>TRAVER TR PRITG2 N CDN PVT 5028 BC SPEECH B
Warning: Routing characteristics are present.
Originator must be able to send in
characteristics specified.
TABLE TRKGRP
TABLE LTCALLS
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
TABLE DIGCOL
DCDEMO 5 COL S 3
TUPLE NOT FOUND
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE TOFCNAME
162 879
TABLE DNINV
162 879 5028 L STUDENT 28
TABLE DNATTRS
162 879 5028 $
(CT (VBINFO (PROVCGS ) (PROVCDS ) (PROVLLC ) (PROVHLC )
(ISDNAMA RECORDALL) $)
(CMDATA (PROVCGS ) (PROVCDS ) (PROVLLC ) (PROVHLC ) (ISDNAMA RECORDALL)
$)$)$
TABLE DNGRPS
TUPLE NOT FOUND
1 LINE 1628795028 ST

1 GNCT
31
Private BC 64KDATA Call Traver
>TRAVER TR PRITG2 N CDN PVT 5028 BC 64KDATA B
TABLE RTECHAR
. 64K ( BC 64KDATA $)$
TABLE TRKGRP
TABLE LTCALLS
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE NCOS
TABLE DIGCOL
DCDEMO 5 COL S 3
TABLE XLAMAP
. 64K PXDEMO0 ( XLA PXDEMO1)$
PXDEMO1 5 ROUTE N N N 0 N 4 4 NDGT N S NTDEMO2WNAT $
TABLE DIGCOL
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
1 NTDEMO2WNAT 5028 ST

1 GNCT
32
Public Call (Centrex Translations)
FROM CENTREX XLAS or Table LTCALLS
LINEATTR
PXHEAD
RCNAME eg 64k from
Table RTECHAR
PXCODE
Route Index
PXRTE OFRTMAP /IBNMAP
Route Index New Route Index
OFRT /IBNRTE
OFRT /IBNRTE
Speech Call Data Call
ROUTE A ROUTE B
33
Public Call (Universal translations)

The diagram below shows Table LINEATTR being accessed which is the link into
Universal translations for a public (E.164) call.
We get to Table LINEATTR from Table LTCALLS in the case of a public SETUP
message received on a PRI trunk, or from CENTREX translations in the case of a
received Private call jumping over into Universal translations.
In Universal Translations, Table OFRTMAP or Table IBNMAP will be searched to see if
there is a match with the BC received. If a match is found then a new Index is generated.
The key to Table OFRTMAP or Table IBNMAP is an existing Route Index+ RCNAME.
Note the following tables also have mapping tables as listed:-
Routing Table Mapping Table
OFR2 OFRTMA2
OFR3 OFRTMA3
OFR4 OFRTMA4
IBNRT2 IBNMAP2
IBNRT3 IBNMAP3
IBNRT4 IBNMAP4
>TABLE OFRTMAP
KEY NEWINDEX
------------------------------------
64K 20 21
64K 602 612
33
Public BC Speech Call Traver
>TRAVER TR PRITG2 N CDN PUB 66025014 BC SPEECH B
TABLE TRKGRP
TABLE LTCALLS
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE LINEATTR
TABLE PXHEAD
TABLE PXCODE
PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) ( CONSUME 4)$
TABLE: PXRTE
KEY: PRIUSER 682
. T IBNRTE 682
. . TABLE IBNRTE
. . 682 DN 162 879 N 0
EXIT TABLE PXRTE
1 LINE 1628795014 ST

1 GNCT
34
Public BC 64KDATA Call Traver
>TRAVER TR PRITG2 N CDN PUB 66025014 BC 64KDATA B
TABLE RTECHAR
. 64K ( BC 64KDATA $)$
TABLE TRKGRP
TABLE LTCALLS
TABLE CUSTSTN
TUPLE NOT FOUND
TABLE OFCVAR
TABLE LINEATTR
TABLE PXHEAD
TABLE PXCODE
PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) $
TABLE: PXRTE
KEY: PRIUSER 682
. T IBNRTE 682
. . TABLE IBNMAP
. . . 64K 682 502
. . TABLE IBNRTE
. . 502 S N N N N NTDEMO2WNAT
. . TABLE IBNMAP
. . . Tuple not found. Default to old index.
EXIT TABLE PXRTE
1 NTDEMO2WNAT 66025014 ST

1 GNCT

>
35
36
PRI Trunks Exercise
Datafill Two PRI trunk groups.

Each trunk group will have one trunk member.
A suggested trunk group room plan appropriate to your class is included for reference
overleaf, however your instructor may allocate the connections differently.

Destination Customer Group A name__________________________
Destination Customer Group B name__________________________
TRKSGRP circuit info

TRKMEM info
Use the example datafill shown earlier for PRI for common values.
For Table LTCALLS, use the following information;

LTGRP = PRI
LTNUM = 10x (where x is your team number)
XLARTE = XLALEC
LINEATTR Index = as built in Centrex Translations module.
RATEAREA and XLAPLAN = as used in Centrex Translations module.
For Table LTMAP, add entries to map your LTGRP and LTNUM to your Trunk CLLIs
CLLI name is to follow the following naming convention;

[Region ] [Team number] [Signalling Type] [Identifying text]
Where Region EM for EMEA, CA for CALA, NA for North America or AP for AsiaPac
Team Number 1 to 8
Signalling Type PRI
Identifying text TRK for Trunk, A for 1st circuit, B for second.
Examples;
EM3PRITRKA and EM3PRITRKB
Refer to the NTP and the examples on earlier pages for information on datafill.
37
Trunk Group Exercise Room plan

GWC TermNo_631__ GWC TermNo__641__
Team 3 Team 4

GWC TermNo__630__ GWC TermNo_640___

Team 2 Team 5
GWC No_1___ GWC No_1___

GWC Node__8__ GWC Node__8__
GWC No_1___ GWC No__1__

Team 1 Team 6

38
39
Appendix B
CCS7 Information
nortel.com/training
0
1
Appendix B
Purpose
This section contains information in relation to CCS7 Signalling
and is for information only.
2
2
3
CCS7 Tables
C7 Tables
C7NETWRK C7TIMER
User Part Tables
C7RTESET C7LKSET C7LINK CLLI
TRKGRP
C7NETSSN
TRKSGRP
C7LOCSSN
TRKMEM
ISUPDEST C7TRKMEM
4
Signalling Link Provisioning

This section lists and briefly describes the CS 2000 Core data schema tables used to
provision signalling links, which convey the messages used by the Core to translate and
determine the destination of a call so that an appropriate trunk can be selected.
Specifying the signalling capability required for each trunk group/member is essential to
ensure that the signalling channels entering the CS 2000 are routed to appropriate signalling
terminations.
4
CCS7 Signalling Links
The way in which CCS7 signalling links are datafilled depends partly on whether CCS7
functionality is provided by the USP or the FLPP, which is indicated by office parameter
USP_ACTIVE_IN_NETWORK. Most signalling link datafill is the same in both cases, but
physical link terminations are defined differently.
Table C7NETWRK lists the CCS7 point code domains supported and indicates the
network type of each (ANSI or ITU-T/ETSI). It also specifies the point code(s) used to
identify each CS 2000 network appearance to other nodes or network appearances within
a CCS7 given point code domain. A CS 2000 can be assigned up to four point codes in a
given domain and up to 31 point codes in total.
Table C7RTESET defines routesets, where a routeset comprises all the possible routes
(up to a maximum of eight, listed in order of preference) from a CS 2000 to another to
other target node or network appearance within a CCS7 given point code domain. Each
element in a routelist is a linkset, where a signalling linkset is a group of one or more
signalling links that provides a route to an adjacent CCS7 node. For a direct route to the
target node, the linkset provides a direct connection. For an indirect route to the target
node via one or more other nodes, the linkset provides a connection to the first node on the
route.
Note: If CCS7 functionality is provided by the USP, table C7RTESET is
automatically populated with data downloaded to the CS 2000 Core from the
USP.
The way in which linksets are defined depends on whether CCS7 functionality is
provided by the USP or the FLPP, as follows:
o USP rather than the Core. The USP sends the Core the routeset information it needs to
populate table C7RTESET, and also keeps the Core informed about routeset
availability.
Note: From the perspective of Core call processing, it makes no difference
whether CCS7 signalling terminates at the USP on dedicated TDM-side
signalling link terminations or is backhauled over the backbone packet
network from a trunk gateway.
o If CCS7 functionality is provided by the FLPP, signalling linksets are defined in table
C7LKSET. The individual links belonging to a linkset are defined in table C7LINK,
which in turn refers to the datafilled list of available link terminations in table
LIUINV). Each linkset is associated with a particular CCS7 network appearance
defined in table C7NETWRK (network type, point code domain, point code).
ISUP and TUP signalling links are provisioned using tables ISUPDEST (which maps
trunk groups to the signalling routesets and associated network appearances defined in
table C7RTESET) and C7TRKMEM (which assigns CICs).
5
Trunk Provisioning Flowcharts (TDM-Side)
6
ISDN Signalling Links
Signalling links for ISDN PRI are provisioned using table TRKSGRP, as used to define the
signalling characteristics of a given trunk group. QSIG signalling links are datafilled in the
same way. A PRI trunk group has no subgroups as such, but table TRKSGRP defines the
signalling characteristics of the D-channel that conveys the ISDN signalling for the B-
channels in the group:
Signalling type ISDN
Protocol version 87Q931
Configuration PT_PT
In conceptual terms, there is a logical terminal (LT) at either end of an ISDN PRI trunk
interface. Each logical terminal has an identifier and belongs to a logical terminal group. On
CS 2000, logical terminal attributes are datafilled in tables LTGRP, PRIPROF, LTDEF and
LTMAP, as follows:
Table LTGRP is used to define group numbers to be assigned to ISDN logical terminals.
Only one option is available per group, this being SAPI16. SAPI16 is the Service Access
Point Identifier used for communication between Layers 2 and 3.
Table PRIPROF is used to create profiles that can be used by ISDN logical terminal
groups. The key field is PROFNAME, which is referenced in table LTDEF. Profiles are
used when interworking with a PBX that uses an implementation of ETSI PRI that differs
from the CS 2000 implementation. This table provides additional control of PRI variants on
each interface to ensure compatibility.
Table LTDEF identifies logical terminals and defines their access privileges. Since each
PRI trunk group is considered as the equivalent of a logical terminal, it must be assigned a
logical terminal identifier (LTID) and access privileges in table LTDEF. The protocol
variant information is extracted from table PRIPROF.
o LTAP field is B for the logical terminal access privilege.
o LTCLASS field is PRA for the logical terminal class.
o NUMBCHNL field defines the number of B-channels associated with this logical
terminal.
o The version of PRI to be used, which is identified by means of a unique Protocol
Version Control (PVC) value generated from the values of the VARIANT and ISSUE
fields in the table LTDEF entry. Base/generic ETSI PRI trunks, for example, have ETSI
PRI in the VARIANT field and 1990 in the ISSUE field; other values in the ISSUE field
are used to identify different national variants, e.g. SPAIN1 for Spanish PRI.
Note: QSIG trunks, for which Layer 3 signalling is very similar to PRI, are
datafilled with the value QSIGPRI in the VARIANT field.
Table LTMAP associates the LTID assigned to the trunk group in table LTDEF with the
trunk group CLLI.
o MAPTYPE field specifies the CLLI for mapping purposes.
o OPTION field specifies 0 as the TEI (Terminal Endpoint Identifier)
7
8
The following is an example of CCS7 datafill.
TABLE: C7NETWRK
NETNAME NODETYPE PTCODE NI SLSROT TFR MCS CLUSTERS
RCTEST MTPRES CNGCONT SLSENH
---------------------------------------------------------------------------------------------------------
C7NETWRK1 SSP CCITT7 BASIC 6969 NATL N N
1 N N Y N N
CS2KNAT SSP CCITT7 BASIC 789 NATLSPARE N N
1 N N Y N Y
TABLE: C7RTESET
ROUTESET NETNAME TFPBCAST DPC
ROUTES
----------------------------------------------------------------------------
SNODE_RS CS2KNAT N CCITT7 BASIC 123
(SNODE_LS 0)$
SNSEB_RS CS2KNAT N CCITT7 BASIC 345
(SNSEB_LS 0)$
SPC_RS C7NETWRK1 N CCITT7 BASIC 1212
( SPC_LS 0)$
TABLE: C7LKSET
LINKSET LSTYPE NETNAME FEPC
FECLLI SIGLKTST RSTEST INHTEST
Q704 CNGSTN NUMFLAGS MTPRES CHNGSLS SCCPONLY NIRPLMT
AUTOINH CONGENH
----------------------------------------------------------------------------
SNODE_LS FLINK CS2KNAT CCITT7 BASIC 123
SNODE N N N
0 1 1 N N N NIL
Y N
SNSEB_LS FLINK CS2KNAT CCITT7 BASIC 345
SNSEB N N N
0 1 1 Y N N NATL
Y N
SPC_LS FLINK C7NETWRK1 CCITT7 BASIC 1212
LINK_TO_SPC N N N
0 1 1 N N N NIL
Y N
9
TABLE: C7LINK
LINKNAME LINKDATA CLASDATA Q707 LINKOPT
-----------------------------------------------------------------------------------------
SNODE_LS 0 LIUBASIC LIU7 13 MTP2 0 0 $
SNODE_LS 1 LIUBASIC LIU7 23 MTP2 0 0 $
SNSEB_LS 0 LIUBASIC LIU7 25 MTP2 0 0 $
SNSEB_LS 1 LIUBASIC LIU7 36 MTP2 0 0 $
SPC_LS 0 LIUBASIC LIU7 1 MTP2 0 0 $
TABLE: ISUPDEST
DESTKEY ISUPROUT
-----------------------------------------------------
GERMANYPVG 0 SNSEB_RS
FRANCEPVG 0 SNSEB_RS
SPAINPVG 0 SNSEB_RS
HOLLANDPVG 0 SNSEB_RS
ITALYPVG 0 SNSEB_RS
UKPVG 0 SNSEB_RS
TABLE: C7NETSSN
PCNAME XUDTIND CGT1 CGT2 SSNAMES
----------------------------------------------------------------------------
SPC_RS Y 0 0 ( ETSIIN 106)$
10
11
11
Appendix C
Announcements
nortel.com/training
0
1
Appendix C
Purpose
This section contains example datafill on Announcements in a
CS2k environment and is for information only.
2
2
3
Announcement Datafill
The media server and its controlling audio GWC are datafilled using the following tables:
The SERVRINV Server Inventory table defines the GWCs supported.
The SERVSINV Server Subtending Node Inventory table, which lists logical nodes that
subtend GWC peripherals. The media server is defined as a node of type AUD.
Announcements are identified by a CLLI and an announcement number. The tables used to
define them are:
Table CLLI
Defines a logical Common Lanaguage Location Identifier (CLLI) for each
announcement on which a call can terminate. It also specifies the trunk group
size (number of members) for each announcement CLLI.
Table ANNS
For each announcement, table ANNS defines the CLLI used in routing calls
to that announcement (e.g. ATTBUSY or MUSIC). It also specifies the cycle
time of the announcement.
Table ANNMEMS
An announcement CLLI is a logical destination. As with a trunk group CLLI,
it is necessary to provide physical paths to that destination. For
announcements provided by the media server, the MEMINFO field in table
ANNMEMS provides two items of information:
A numeric phrase list index into table ANNPHLST for
locating the phrase(s) that comprise the announcement.
The identifier of the media server where the announcement
resides, as defined in SERVSINV, e.g. AUD 0
Table ANNPHLST
This is the mechanism used to assemble complete announcements from
separate phrases and variables. An announcement may consist of up to 16
phrases, which are listed in order in table ANNPHLST using the names
assigned to them when recorded. The CLLI of an announcement and the
ANNMEMS phrase list index are used to retrieve the names of its consituent
phrases from table ANNPHLST.
Table ANNAUDID
Because the media server does not recognise the CS 2000 names for
announcement phrases, table ANNAUDID maps the phrase identifiers
datafilled on CS 2000 to the audio segment identifiers that have been
separately provisioned on the media server. This enables the media server to
retrieve, assemble and play the correct announcement in response to a
CS2000 request.
4
5
CS2k Announcements example datafill
Table CLLI Table SERVRINV

CLLI ADNUM TRKGRSIZ ADMININF SRVRNAME SRVRADDR SRVREXEC SRVRTONE BEARNETS SRVROPTS
----------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------
WRONG_NUM 1000 10 WRONG_NUM_ANNC GWC 3 IP 47 163 43 40 (ABTRK GWCEX) $ UK100 (NET_IP Y) $ $
Table ANNAUDID Table SERVSINV

PHRASEKY AUDID Segment ID SRVSNAME SRVRNAME NUMTERMS OPTIONS
---------------------------- on MS2010 --------------------------------------------------------------------------------------------------------
WRONG_NUM 3000 AUD 1 GWC 2 2048 ( ANNC 300)$
AUD 2 GWC 3 4095 (3PORT 30) (6PORT 60) (ANNC 90) $
Table ANNS
CLLI ANNARCH TRAFSNO CYTIME MAXCYC DATA
-------------------------------------------------------------------------------------------
WRONG_NUM NETWK 0 10 1 STND N 10
Table ANNMEMS
ANNMEM HDWTYPE CARD MEMINFO
------------------------------------------------------------------------
WRONG_NUM 0 UAS AUD 2 AUD 2
Table ANNPHLST
ANNPHKEY PHSLIST
-------------------------------------------------------------------
WRONG_NUM 2 ( BLACK ) $
6
The above datafill is an example.
The actual announcement would have to be recorded and uploaded to the MS2010 Audio
Server.
See course 2788.
6
7
Appendix D
Student Information
nortel.com/training
0
1
Appendix D
Purpose
This section contains additional information which the student
may find useful.
2
2
3
Datafill Order
XLANAME
CUSTENG
AUTHPART
AUTHCDE
CUSTHEAD
NCOS
DIALPLAN
DNROUTE
IBNXLA
IBNTREAT
CLLI
TRKGRP
TRKSGRP
TRKMEM
DPNSSLK
DAYTYPES
TODHEAD
DAYOWEEK
DAYOYEAR
TIMEODAY
CODEC
OFRT/IBNRTE/OFRx
FAHEAD/CODE/RTE
OFCHEAD/CODE/RTE
CTHEAD/CODE/RTE
PXHEAD/CODE/RTE
LINEATTR
POECNM
CALLCNTL
Universal Screening Tables i.e; CGPNSCRN, BCSCRN, NCOSSCRN etc
TRKOPTS
DESTNAME
POECRTE
LCRORIG/LCRORIG2
LCRDEST/LCRDEST2
4
5
6
7
8
9
10
11
12
12

Cs2000 Universal Translations3006a 50 SG

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cs2000 Universal Translations3006a 50 SG

Încărcat de

Drepturi de autor:

Formate disponibile

CS2000

Information subject to change without notice.

July 2005 Version 1.0 Initial Issue

NTP 000-0000-000 Document title

297-9051-350 DMS-100 MMP Translations Guide

297-9051-300 DMS-100 MMP Customer Data Schema

297-1001- 824 Commands Reference Manual

NE-10004-512 OSSGate Users Guide

V10.0 NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Specifically we will be working in the following areas;

The above areas have to be completed prior to entering Universal Translations.

CUSTENG Universals FAHEAD

CS2000 Universal Translations Table Association Chart

TDM Interface Cable Modem

Derived Lines PBX

V10.0 NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

> The structure of tables within the CS2000 is

Field 1 Field 2 Field 3 Field 4 Field 5 Field 6

The user enters a table

The table editer utility is

The table editer help

Table Editor Functions

The user enters a table

The user obtains a list of

The user is now

The position command is

The user enters a table.

The resultant list

After the input for the last

In this unit, you learned the following:

The uses of tables within the CS2000.

2. Locate and view the following LEN:- CICM 07 0 01 30

3. Enter Table CLLI (Common Language Location Identifier).

Centrex Translations Overview

V10.0 NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

After this module of instruction, you will be able to

Program Store (PS) Data Store (DS)

Programs software release Data tables (1100+) and other

CS2000 Digital Centrex and CS2000 relationship

Customer Group Dial Plans .

Customer Group Instructions in Table IBNXLA

Separating Instructions (Tuples) Among Customers

Network Classes of Service (NCOS)

What customer group is the originating phone assigned to ?

The Dual Function of Preliminary Translators

Incoming Trunk Access Translations

Centrex Translations Table OFRT/IBNRTE Universal Translations

Table LTCALLS will be covered in the PRI Trunks Appendix A module.

XLANAME - A 1- 8 character translator name.

Table XLANAME Routeing i/c Trunk Calls to Universal Translations

Refer to NTP 297-9051-350 for detailed information about Table XLANAME.

The following is an explanation of the above tuples fields

XLANAME DEFAULT (Note 1)

CUSTNAME ADNUM NONCOS NOIBNTMT CONSOLES DOMAIN GROUPID

CUSTNAME CUSTXLA DGCOLNM IDIGCOL OPTIONS

CUSTGRP NCOS NCOSNAME LSC TRAFSNO OPTIONS

CUSTGRP IBNTRTMT (ITDATA) LOG RTESEL TRMTID

Throughout this training course, the following regional naming

Example EMEA_2_CUST for a Customer Group Name.

XLANAME Assign Default as NET.......DOD

CUSTENG Customer Group type is to be PUBLIC, NONCOS +

CUSTHEAD Use VACTRMT 0

NCOS Use NCOS 0, no options required.

Team 1 ________

Team 2 ________

Team 3 ________