CS2000 Universal Translations.3006A 5.0 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 July 2005 August 2005 August 2005 May 2006 Version 1.0 Version 2.0 Version 3.0 Version 4.0 Version 5.0 Initial Issue Updated, formatting errors Updated following pilot delivery. Additional module and appendix added. 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 297-9051-300 297-1001- 824 NE-10004-512
DMS-100 MMP Translations Guide DMS-100 MMP Customer Data Schema Commands Reference Manual 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 Announcements 17. Appendix C
18. Appendix D Student Information
Introduction
nortel.com/training
V10.0
NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY
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
CS2000 Universal Translations Course Introduction
Centrex Customer Group Tables
Universal Translations Tables
Trunk Group Tables
Routing Tables
Call Control Tables
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.
XLANAME CUSTENG CUSTHEAD
Centrex
LINEATTR
CS2000 Universal Translations Table Association Chart

Universals
PXHEAD CTHEAD OFCHEAD FACODE CTCODE OFCCODE FARTE CTRTE OFCRTE IBNRTE FAHEAD
IBNXLA NCOS IBNTREAT PXCODE
PXRTE
CLLI TRKGRP TRKSGRP TRKMEM PATH OF ENTRY LEAST COST ROUTING
OFRT
OVRx
Routing
CALLCNTL
Trunks
TRKOPTS UNIVERSAL SCREENING
Call Control
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.
CS2000 Network Overview

Voice Services
CS2000
or
Core Billing Manager
CS2000
Back Office IEMS Element Management USP Network Signalling TDM Interface MG15K
CS2000c
GWC CS LAN
CBM MCS
Multimedia Server Announcements

MS20x0 Conferencing
Lawful Intercept CICM Centrex IP Phone Server
SS7
ERS 8600
BCP IP Network
NAT and NATP Translation Cable Modem

CMTS
PSTN
Hosted PBX Centrex IP Derived Lines

xDSL IAD CPE IAD DSLAM
Video Feed
HFC HFC PBX Cable Modem
m6350 Softclient
8
i2004 Etherset
Module 1
Introduction to CS2000 Data Tables
nortel.com/training
V10.0
Module 1 Introduction to CS2000 Data Tables

Purpose The purpose of this section is to introduce the student to; > 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
Introduction to Tables
Call Processing Hardware Resources Trunks Lines IBN Translations Universal 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.
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
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.
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.
Table Structure
1st Field is usually Key Field (Must be Unique) Field 1 Field 2 TUpLE 1 TUpLE 2 Field 3 Field 4 Field 5 Field 6
Data Entry
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.
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.
Navigating a Table
The user enters 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
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.
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 list (lis) list all (lis all) list <n> (lis <n>) top bottom (bot) first last next prev up <n> down <n> (dow <n>) Position <key field> 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. displays the number of tuples within the current table. Displays the currently positioned tuple. Displays all tuples within the current table. Display the defined number of tuples directly below my current position. Position cursor at the first tuple in the table and display the tuple data. Position cursor at the last tuple in the table and display the tuple data. Position the cursor to the first tuple in the table. Position the cursor to the last tuple in the table. Position the cursor to the tuple following the current tuple. position the cursor at the tuple previous to the current tuple. move the cursor up the specified number of tuples, display tuple data. move the cursor down the specified number of tuples, display tuple data. position the cursor at the specified key field. (see note)
10
Navigating a Table (contd)

The user enters a table 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 The list command retains the current position 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 user enters a table. 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 enters a table. 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 enters a table. The user positions on the tuple to be deleted. The list command retains the current position 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
V10.0
Module 2 Centrex Translations Overview

Purpose The purpose of this section is to introduce the student to; > CS2000 Digital Centrex base translations. After this module of instruction, you will be able to 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 NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY
CS2000 Universal Translations Course Navigation Map
Centrex Customer Group Tables
Universal Translations Tables
Trunk Group Tables
Routing Tables
Call Control Tables
Course Navigation The above slide illustrates the area we are currently working in.
Centrex
LINEATTR

Universals
IBNXLA NCOS IBNTREAT
Centrex Introduction
PS PS
CM (cpu)
CM (cpu)
DS
Duplicated
DS
Program Store (PS) Programs software release e.g. ISN06 or ISN07

8
Data Store (DS) Data tables (1100+) and other data that contain the switchs Information
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.
Introduction to Centrex Translations

RES_GRP Business Customer A
CS2k switch
Residential Customers
GRP_A GRP_B
Centrex Translations Business Customer B

Table LINEATTR
Trunks
PSTN
Universal Translations Business Customer C GRP_C Trunks PBX
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 Group */# 5 9 0 = = = = Features Extension calls Network Calls (PSTN) Attendant
Oil Customer Group
*/# 4 9 0
= = = =
Features Extension calls Network Calls (PSTN) Attendant
Textile Customer Group
*/# 3 9 0
= = = =
Features Extension calls Network Calls (PSTN) 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) Oil (OIL) Textile (TEXT) 5 EXTN 4 EXTN 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 BANK OIL TEXT RES CUSTXLA BANKCT OILCT TEXTCT 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 OILCT TEXTCT 5 EXTN (further data dependant on selector) 4 EXTN 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 Table CUSTHEAD Custname BANK BANKCT Custxla BANKCT 5 EXTN . . . . . . . STN 2456000 BANK 0 1 214 $
Table IBNXLA
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 BANKCT 5 EXTN 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 BANK BANK BANK 0 1 2 PRELMXLA $ (none) BANKPT1 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 BANKPT1 5 EXTN 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
Other Switches
Customer
Group
Table Lineattr LINEATTR
Table
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 Customer Group and NCOS Table IBNXLA etc.
Table OFRT/IBNRTE e.g. Direct to a Trunk Group
Universal Translations via Table LINEATTR

.
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 variablelength 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 031 186 162 162 OFCCODE OPTIONS 345 567 870 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 CS_NPRT SCRNCL HSTS PRTNM ZEROMPOS RESINF OPTIONS ADMININF 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 CS_NIL LCANAME MRSA LATANM ADMININF 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 MAXDIG CXDEMO 9 DEFAULT
-------------------------------------------------------------------------------------------------------------(NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $
The following is an explanation of the above tuples fields XLANAME cxdemo ndgt XLAPLAN cs_nprt 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. n cs_nil DEFAULT (Note 1) TRSEL ACR SMDR NO_ACCODE_DIGITS SECOND_DIAL_TONE net n y n dod none n 0 1 $ n DGCOLNM CRL INTRAGRP NET_TYPE SMDRB LINEATTR RATEAREA TOLL_RESTRICTION NETRTOPT
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 IBNDEMO CUSTXLA DGCOLNM IDIGCOL OPTIONS 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 IBNDEMO 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 IBNDEMO IBNTRTMT 0 (ITDATA) LOG N RTESEL TRMT TRMTID GNCT NCOS NCOSNAME LSC 0 $ 0 TRAFSNO 0 OPTIONS $
- - - - - - - - - - - - - - - -- - - - -- - - - - - - - - - - - - - - - -- - - - - - -- - - - - --
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - -
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..... > APAC.... > NA........ or CA...... or AP.....
28
Naming Conventions This training event includes many exercises. To enable the switch database to be kept tidy and assist instructors in removing datafill postevent 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. Use VACTRMT 0 Use NCOS 0, no options required. No entries required Use TRMT GNCT for Vact_trmt.
CUSTHEAD NCOS IBNXLA IBNTREAT
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 Additional identifier text is Example EM2CUSTGRP Where EM is Region abbreviation for EMEA, Team 2 and CUSTGRP for Customer Group. 1 to 8 Text at Instructors discretion.
NOTE The above naming convention will be followed for all subsequent exercises.
29
30
31
Module 3
Lines Provisioning
nortel.com/training
V10.0
Module 3 Lines Provisioning

Purpose The purpose of this section is to introduce the student to; > 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. After this module of instruction, you will be able to List the basic SERVORD and OSSGate commands Apply the Query commands to their own lines. Demonstrate selected basic OSSGate/SERVORD commands.
Table Flow Chart
IBNLINES IBNFEAT UPDATES

DNINV
KSETINV KSETLINE KSETFEAT
These tables are automatically updated if you use SERVORD or SERVORD+ (OSSGate ) (OSSGate)
SUBGRP
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.
OSSGate interactions with Succession and Maintenance components in SN07

3rdParty OSS Applications
Authentication and Authorisation
OSSGate
Trunk Maintenance Manager
Node Provisioning
Line Provisioning
Trunk Provisioning
Carrier Provisioning
ADSL Provisioning
CS2k Core Manager (SDM/CBM)
Element Managers (GWC EM, MG9k EM, CICM EM)
XA-Core/COMPACT
7
Trunk Gateways (PVG)
Line Gateways
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.
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.
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 ******************************************************************************* >
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. Enter username and password > maint maint maint logged in on 04/08/08 at 08:08:05. ******************************************************************************* ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** 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 ******************************************************************************* > Any UNAUTHORIZED access or use is PROHIBITED and may result in PROSECUTION. All activity is subject to monitoring. This is a PRIVATE Database. OSS Gateway ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
*******************************************************************************
*******************************************************************************
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 Enter username and password > 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 Enter username and password > 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 trkrw trksprov trkmtc trkro lnadm lnrw lnsprov lnmtc lnro mgcadm mgcrw mgcsprov mgcmtc mgcro mgadm mgrw mgsprov mgmtc mgro emsadm emsrw emsprov emsmtc 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/19 9195200574 les24.mgcp.net aaln/20 9195200575+ >les24.mgcp.net aaln/21 9195200576 les24.mgcp.net aaln/22 9195200577+ >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. 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). 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). 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. 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. USERID and PASSWD features will never be sent to the CS 2000 SERVORD interface. 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.
2.
3.
4.
5.
6. 7.
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 $
NEW line
DN LCC
customer group NCOS subgroup SNPA Key Ringing
LEN
Option key = No
Issued NOW
22
Example of OSSGate new command

Fields: DN LCC Group Subgroup NCOS SNPA Key Ringing LEN Directory Number Line Class Code (m5316 in CentrexIP) Customer Group Sub group Network Class of Service Serving Number Plan Area Which key DN shall be assigned to on the phone Will ringing be applied on this line 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 $
NEW line
DN LCC
customer group
SNPA NCOS line number FQDN
Option
Issued NOW
23
subgroup
Example of OSSGate new command

Fields: DN LCC Group Subgroup NCOS SNPA FQDN AALN Option Directory Number Line Class Code Customer Group Sub group Network Class of Service Serving Number Plan Area Fully Qualified Domain Name of analogue lines gateway Analogue gateway line number. 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 $ 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 $
2.
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 $ $ CHF $ vmg1 SCOT/000/0/0000 SIP_DATA SIP_PACKAGE siplines SIP_PASSWD scott11 SIP_CLIENT_TYPE IBN SIP_LOCATION IBM.RTP $ $
2.
OUT Command Examples 1. 2. OUT $ 6195209998 SCOT 00 0 00 00 BLDN 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 TYPE: SINGLE PARTY LINE 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. 2. 3. SIP_PACKAGE - Up to 30 characters. SIP_URI - Up to 60 characters. 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. 6. SIP_LOCATION - The location name, a brief description of the location being added. This field cannot be null. Maximum length = 30 characters. 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 TYPE: SINGLE PARTY LINE SNPA: 162 SIG: N/A LNATTIDX: N/A HOST 00 0 00 30 LINE EQUIPMENT NUMBER: LINE CLASS CODE: M5209 KEY: 1 CUSTGRP: IBNDEMO SUBGRP: 0 PM NODE NUMBER: 30 PM TERMINAL NUMBER: 1 OPTIONS: 3WC CFU CFB CFD LNRA RAG INSPECT CPU NCOS:0 RING:Y BNV: NL MNO: Y CARDCODE: 6X21BC GND: N PADGRP: NPDGP
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 TYPE: SINGLE PARTY LINE SNPA: 162 DIRECTORY NUMBER: 8795530 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 PM TERMINAL NUMBER: 1 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 1 2 3 KEY 1 1 1 1 1 1 1 3 4 5 6 7 8 DN 8795530 8795540 GIC FEATURE CFK CPU SCL MCH PRK EBO DCPK RAG CNF C30 GIAC ICM 3WC HOST 00 1 19 04 7 N N EMW CLASSP 1 0 0 HOST 00 1 18 09 $ L30 7 SALES
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 TYPE: SINGLE PARTY LINE SNPA: 162 DIRECTORY NUMBER: 8795530 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 PM TERMINAL NUMBER: 1 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 1 2 3 KEY 1 1 1 1 1 1 1 3 4 5 6 7 8 DN 8795530 8795540 GIC 7
SALES
FEATURE CFK CPU 0 HOST 00 1 18 09 $ SCL 0 L30 MCH PRK EBO DCPK RAG CNF C30 GIAC ICM HOST 00 1 19 04 7 N N EMW CLASSP 1 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 HOST 00 0 18 09 HOST 00 0 18 10 HOST 00 0 18 11 HOST 00 0 18 12 HOST 00 0 18 13 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.
3625089 3625090 3625091 3625092 3625093 3625094
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 Team 1__________________________ Team 2__________________________ Team 3__________________________ Team 4__________________________ Team 5__________________________ Team 6__________________________
CICM DNs __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________
36
37
Module 4
TRAVER
nortel.com/training
V10.0
Module 4 TRAVER
Purpose The purpose of this section is to introduce you to the following concepts; > The Translation Verification (TRAVER) tool After this module of instruction, you will be able to > List the common commands used by TRAVER. > Describe the purpose of TRAVER. > Explain the results of Line and Trunk Travers.
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 8795301 5302 = lines ( other parameters are available too ) = dialling number i.e. the calling line = dialled number i.e. the called line
The last parameter comprises T, B, or NT where : T= B= a request to trace translations tables by listing each TUPLE of each TABLE used during the translation process. 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. no trace of TUPLES is to be displayed ; only digit translation routes are to be reported.
NT =
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.
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.
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.
Traver Trunk To verify the translations for incoming trunk calls the following Traver command is used. TRAVER TR CLLINAME DIGITS B, T, or NT. Where the parameters are . . . . . TR = CLLINAME = the DIGITS = The Trunk ( other parameters are available too ) the Common Language Location Identity name assigned to trunk group. dialled number i.e. the incoming digits received on the trunk last parameter comprises T, B, or NT which were described earlier.
An example of a trunk traver is given on the next page.
>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 NDGT specified: digits collected individually 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
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 +++ TRAVER: SUCCESSFUL CALL TRACE +++ 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.
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. Where the parameters are . . . . . V= VFGNAME = DIGITS = VFG ( other parameters are available too ) the name assigned to the Virtual Facility Group. 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 Default from table XLANAME: ALECPTV (NET N N 0 N NDGT N N DOD N 68 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually 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_OFFICE_TRIGGRP NIL AIN Orig Attempt TDP: no subscribed trigger. TABLE NCOS IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT)$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 DCDEMO TABLE DIGCOL DCDEMO 6 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 61 ROUTE N N N 2 N 1 6 NDGT Y T IBNRTE 61 $
11
TABLE DIGCOL NDGT specified: digits collected individually 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 +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 VFG: VFGDEM 5529 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++ ---> ---> 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 $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL MH4BGRP NXLA MH4BCXLA NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually NCOS PRELIM XLA name is NIL. Go to next XLA name. CUST 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 +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 LINE 1628795529 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++
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. indicates the type of signalling on the trunk, the called number MF start A LEAS call cannot be properly traced without this parameter. is the number to be billed (an information digit plus the calling digits). A LEAS call cannot be properly traced without this parameter. indicates the type of signalling on the calling number trunk; a call involving LEAS cannot be properly traced without this parameter.
<mfst> signal. <billno> <bill_mfst>
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: exactly 10 digits: ` more than 10 digits: TON is Subscriber TON is National TON is International (Local) (NAtional) (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
V10.0
Module 5 Trunk Groups

Purpose The purpose of this section is to introduce the student to the concepts of; > Trunk Groups and their datafill. After this module of instruction, you will be able to List the tables used to establish voice calls. Describe the purpose of each of the tables Complete a trunk group datafill exercise
Centrex
LINEATTR
CS2000 Universal Translations Table Association Chart Universals
CLLI TRKGRP TRKSGRP TRKMEM
Trunks
Trunk Network the big picture

R.O.W Switch A Switch C PBX B
PBX A
Switch B
Switch E
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.

Voice Services
CS2000
or
CS2000
CS2000c
GWC CS LAN
CBM MCS

MS20x0 Conferencing
SS7
ERS 8600
BCP IP Network

CMTS
PSTN

Video Feed
m6350 Softclient
7
i2004 Etherset
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.
Trunk Groups a simple view
CLLI
TRKGRP TRKSGRP TRKMEM
er rri a C
er rri a C

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. 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. 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
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.
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 UKPVG UKPRI ADNUM 155 743 TRKGRSIZ 31 30 ADMININF PVG_TO_UK 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. 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.
ADMININF
12
Table TRKGRP example (C7UP)

TABLE TRKGRP GRPKEY ukpvg aseq n 0 N n n 0 n 0 GRPTYP TRAFSNO PADGRP NCCLS CUSTNAME SUBGRPNO ibnt2 n n 0 ansdisc n n natl n 0 n $ npdgp 0 0 n ncrt n N n n cs2kcust n 0 n 0 0
SELSEQ NCOS BILLDN SUPV DISCTSEL INTRAGRP DIGIT0 DIGIT1 DTI TES CDR SMDR TRC ALTNCOS TRKDSR LSCFN ALTLSCFN LSCINCPT ALSCINCP IGA FDN FDV FLASH DPX PREEMPT AIOD REORIG OFFNET COFFTYP OPTION
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. Group type. Enter the trunk group type. This may be IBNT2, IBNTO or IBNTI. In this example, IBNT2 has been used. Traffic separation number. A number used to give separate OM counts for traffic on this trunk group. If not required enter 0. 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. 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.
GRPTYP TRAFSNO PADGRP
NCCLS
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. 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. 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. 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. Intragroup. Enter Y, (yes), if the call is to be checked for intragroupness otherwise enter N, (no).
BILLDN
SUPV
DISCTSEL
INTRAGRP
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 DTI TES CDR SMDR TRC
Digit 1. As for Digit 0 above but for the second prefix digit. Dial tone incoming. If second dial tone is sent to the incoming caller enter Y. Generally, this field is set to N. Toll essential service. Not used, enter N Call detail recording. If incoming calls are to be recorded using the SMDR format enter Y.Generally, this field is set to N. Station Message Detail Recording. (call logging). If call logging records are required enter Y, otherwise enter N. 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. 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. Trunk distinctive ringing. Generally, this field is set to N. 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. 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. 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. Generally, this field is set to N. Generally, this field is set to N. Generally, this field is set to N. Generally, this field is set to N. Generally, this field is set to N. This field must be set to N.
ALTNCOS
TRKDSR LSCFN
ALTLSCFN Used in conjunction with the above.Generally, this field is set to 0. LSCINCPT
ALSCINCP
IGA FDN FDV FLASH DPX PREEMPT
15
AIOD REORIG OFFNET COFFTYP OPTION
Generally, this field is set to N. Generally, this field is set to N. Generally, this field is set to N. Class of Office Type. Enter NATL for National. 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 n Base ds1sig none 100_blue c7up q767 $ 2w thrl nil n 0 cic n internal dmsnode n n y AUTOON ABCNTL PROTOCOL CONTCHK COTREQ ADJNODE ACO OVLP VARIANT VERSION OPTION TMRNAME GLARETYP
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 DIR ESUPR SAT Variable subgroup data. This field consists of subfields as described below. Enter TUP here to indicate the U.K. CCS 7 signalling variant. 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. Echo suppression. Enter N to indicate that no echo suppressors are installed. Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a satellite. If not, enter N, (no).
17
ECSTAT NSMATCH
Echo canceler status. Enter UNEQ to indicate that Echo canceler is not equipped on this subgroup. 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. 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. A-bit control. Enter NONE if this field is not used by call processing control software.
AUTOON
ABCNTL
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 OVLP Answer charge. This field determines if an answer charge is applied on BTUP to ISUP calls. 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. 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. See the PROTOCOL parameter.
VARIANT VERSION
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 UKPRI UKPRI UKPVG UKPVG EXTRKNM 1 2 1 2 0 0 0 0 SGRP GWC 1 GWC 1 GWC 1 GWC 1 MEMVAR 8 300 8 301 8 332 8 333
20
The fields are:CLLI EXTRKNM Common Language Location Identifier. Enter the CLLI name of the trunk group to which these trunks are to become members. 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. Subgroup number. A value of 0 or 1 which represents the subgroup number, built in table TRKSGRP, to which these trunks are assigned. Table defines the signalling parameters for the trunks. Peripheral module type. Enter the type of peripheral module to which the trunks connect. Gateway Controller Number Gateway Controller Terminal Number
SGRP TRKSGRP PMTYPE GWCNO GWCTRMNO
GWCNODENO Gateway Controller Node 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. 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 DMS amongst which are Tones, Announcements and Trunk groups. Table TRKGRP Table TRKGRP defines each trunk group, the customer group to which it belongs with associated attributes, direction and options. There are three types of IBN trunk in use, they are IBNTI - Incoming only, IBNTO - Outgoing only and IBNT2 - Bothway. Table TRKSGRP Table TRKSGRP defines the signalling parameters used. Two subgroups may be defined for a trunk group. Table TRKMEM Table TRKMEM defines and allocates the resource used by each individual trunk within the trunk group.
22

23
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 Node__8__ GWC TermNo_631__
GWC No__1__ GWC Node_8___ GWC TermNo__641__
Team 3
GWC No__1__ GWC Node__8__ GWC TermNo__630__
Team 4
GWC No__1__ GWC Node_8___ GWC TermNo_640___
GWC No__1__ GWC Node__8__ GWC TermNo_621___
Team 2
GWC No_1___ GWC Node__8__ GWC TermNo_620___
Team 5
Team 1
Team 6
26
27
Module 6
Route Tables
nortel.com/training
V10.0
Module 6 Route Tables

Purpose The purpose of this section is to introduce the student to the concepts of; > Route Table datafill procedures After this module of instruction, you will be able to 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
Centrex
LINEATTR
IBNXLA NCOS IBNTREAT IBNRTE
OFRT
OVRx
Routing
Trunks
Introduction to Routing Tables

Centrex Translations Universal Translations
IBRTx Tables
ORTx Tables
OVRx Tables
Directory Number
6
Treatment
Trunk Group/s
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.
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.
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. 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. Points to another index within the same route Table. The index pointed to must be a higher number. Resolves a call to a Directory Number on the same switch. 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. 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.
Route Selector T
Route Selector ST Route Selector DN Route Selector N
Route Selector CND
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. Points to a specified Office Treatment. Allows new route elements to be inserted into existing route lists at any route element position. This selector allows deletion of elements from the route list at any route element position. Allows the selection of one or a number of trunks from the trunk group. (Not IBNRTE) E.g. for testing purposes. 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.
Route Selector TRMT Route Selector INS Route Selector NIL Route Selector MEM Route Selector SG
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.
Route Table Datafill Example IBNRTx S selector

Table IBNRTE RTE IBNRTSEL OHQ CBQ EXP 11 s n n n IBNRTSEL OHQ CBQ EXP s n n n IBNRTSEL OHQ CBQ EXP s n n n
MBG n MBG n MBG n
CLLI ntmdhddlog CLLI ntslghdlog CLLI 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 IBNRTSEL OHQ CBQ EXP MBG CLLI The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. The route element selector. S in this example. Off hook queuing. Set to Y if Off hook queuing is allowed for this route element, otherwise enter N. Call Back Queuing. Set to Y if Call back queuing is allowed for this route element, otherwise enter N. Expensive Route Warning Tone. Set to Y if this element is an expensive route and warning tone is required. Multi Switch Business Group. Enter N 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
Route Table Datafill Example 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:RTE RTESEL The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. 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. RTE RTESEL The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. 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. CLLI Common Language Location Identifier. Enter the CLLI name to which the translation is routed.
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
Route Table Datafill Example 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 IBNRTSEL OHQ CBQ EXP MBG CLLI DMI The Route list number in the range 0 to 1023. The route element selector. N in this example. Off hook queuing. As seen before for IBNRTx. Call Back Queuing. As seen before for IBNRTx. Expensive Route Warning Tone. As seen before for IBNRTx. Multi Switch Business Group. As seen before for IBNRTx. Common Language Location Identifier. Enter the CLLI name to which the translation is routed. 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
Route Table Datafill Example 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 RTESEL CLLI DELDIGS The Route list number in the range 0 to 1023. Route Selector. The route element selector. N in this example. Common Language Location Identifier. As seen before for OFRx. 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. 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.
CONNTYPE Connection type. As seen before for OFRx.
PRFXDIGS
13
Route Table Datafill Example IBNRTx T selector

Table IBNRTE RTE IBNRTSEL OHQ CBQ 10 s n n IBNRTSEL OHQ CBQ s n n IBNRTSEL EXTRTEID t ovr55 11 IBNRTESEL $ 21 EXP MBG CLLI n n ntmdhddlog EXP MBG CLLI n n ntslghdlog
IBNRTSEL OHQ CBQ EXP MBG CLLI s IBNRTSEL st n 22

ntrdgdlog
RTEREF
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:RTE IBNRTSEL EXTRTEID The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. The route element selector. T in this example. 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
Route Table Datafill Example 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:RTE IBNRTSEL SNPA NXX EXP DMI The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. The route element selector. DN in this example. Serving Number Plan Area also known as the Area Code. The first three digits of the full 10 digit number. The Office Code digits. The next three digits in the number. Expensive Route Warning Tone. Set to Y if this element is an expensive route and warning tone is required. 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. Station length (1 to 8 digits). Used to identify the station code length of the terminating agent.
STNLEN
15
Route Table Datafill Example 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:RTE IBNRTSEL RTETRMT The Route list number in the range 0 to 1023. This field is entered for the first instance of the route list. The route element selector. TRMT in this example. Route Treatment. A treatment name from table TMTCNTL.
16
Route Table Datafill Example IBNRTx CND - TOD selector
TABLE IBNRTE RTE IBNRTSEL 211 cnd IBNRTSEL s IBNRTSEL s IBNRTSEL t
CNDSEL TODNAME TIMES RTETYPE SKIPNUM tod demotod 1 sk 1 OHQ CBQ EXP MBG CLLI n n n n ntmdhddlog OHQ CBQ EXP MBG CLLI n n n n ntslghdlog EXTRTEID 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
Route Table Datafill Example IBNRTx CND - COSMAP selector
TABLE IBNRTE RTE IBNRTSEL 212 cnd IBNRTSEL s IBNRTSEL s
CNDSEL COSMAP RTETYPE RTEREF cosmap netcos st 300 OHQ CBQ EXP MBG CLLI n n n n ntslghdlog OHQ CBQ EXP MBG CLLI 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
Route Table Datafill Example 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 601 250 calls IBNRTE 602 125 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 cnd CNDSEL PERCENT RTETYPE INDEX 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.
Obtain the following information from your instructor: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.

The purpose of this exercise is to: 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
V10.0
Module 7 Universal Translations Overview

Purpose The purpose of this section is to introduce the student to the concepts of;
> Universal Translations tables and their options.
After this module of instruction, you will be able to

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
CS2000 Universal Translations

Centrex Customer Group Tables Universal Translations Tables Routing Tables
Trunk Group Tables
Call Control Tables
Centrex
LINEATTR

Universals
PXHEAD CTHEAD OFCHEAD FACODE CTCODE OFCCODE FARTE CTRTE OFCRTE IBNRTE FAHEAD
IBNXLA NCOS IBNTREAT PXCODE
PXRTE
OFRT
OVRx
Routing
Trunks
Universal Translations Overview

Centrex Customer Group
BILLING
NET DOD
LINEATTR
Universal Translations
To Announcements
Other Customer Groups

To Trunks to other switches
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.
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
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).
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
HEAD CODE RTE
ss ce Ac e od C
12
PX
HEAD CODE RTE
Pr e fix Co
CT
HEAD CODE RTE
Co un try
FA
HEAD CODE RTE
Fo re ig n
OFC
HEAD CODE RTE
O Ar ea ffi ce
FT
HEAD CODE RTE
Ut ilit y
NSC
HEAD CODE RTE
Nu m be r
AM
HEAD CODE Am bi gu ou s
Se rv ice
co
de
Co de
Co de
Co de
Co de
de
Co de
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 DFOP - Default options to apply when digits are matched in the Code table
XLANAME
DFLT - Default action if digits are not in the Code table
CON Consume the digits used to index the Code table
MAXIDX 9 or STD
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 Instructions to follow if dialled digits fall within the FROMD and TOD range
Digit range to be matched
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 Index number pointed from xxCODE table
RTELIST Route selector, as seen in 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 DFOP - Default options to apply when digits are matched in the Code table
XLANAME
DFLT - Default action if digits are not in the Code table
CON Consume the digits used to index the Code table
MAXIDX 9 or STD
Table PXCODE
XLANAME
FROMD
TOD
XLADATA Instructions to follow if dialled digits fall within the FROMD and TOD range
Digit range to be matched
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
Translator name is the index into the 3 tables
DFLTSEL
DFOP
CON
MAX
3.00
HEAD
What to do if the If there is a match in CON - consume the Centrex Overview digits do not match in the FROMD TOD digits FROMD TOD field use these options. NOCON - do not SDFLT = vactrmt NODFOP no default consume the digits DFLT = xlasel to options or DFOP e.g. from the FROMD process the call MIN MAX TOD field Same translation Selectors as Code Table options Code table instructions overrides Head table instructions
9 or STD
NOCON cannot be Overridden by the code table
XLANAME
FROMD TOD
Digit range to be matched e.g. from 00 to 00
XLADATA
XLASEL
CODE
XLANAME
If there is a match in The translation the FROMD TOD selectors you can use . field, instructions on e.g. on how to CONT, RTE, process the call. DMOD & TRMT
RTEREF
A reference number from the code table into this table.
RTESEL
Route selector T to point out to the routing tables
TABNAME
INDEX
Routing table name
Index number into the routing table
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 Routing
xxHEAD
Default Routing
xx2CODE
RTE CONT
CONT
xxCODE
RTE 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
Corresponding
xxRTE
26
IBNRTx OFRx OVRx xxRTE
26
Table Lineattr Entry point to Universals

Centrex Overview
3.00
CS2000
Lines
Customer Group
Customer
Group
Trunks
Table Lineattr LINEATTR
Table
Other Switches
Universal 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 Default from table XLANAME: 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 px ibn mh3pxla none nil nt 00 0 0 CS_NPRT nilsfc 0 $ XLASYS XLANAME DGCLNAME FANIDIGS DFLTXLP DFLTRA OPTION 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 CHGCLSS COST LTG TRAFSNO SFC MDI XLASYS Line Class Code. The line class code assigned to the line attribute index. Enter IBN for IBN translations. Enter NONE. Enter NT. Enter 0, (zero) Traffic Separation Number. Peg counts calls by type. Enter 0, (zero) Enter NILSFC Enter 0, (zero) 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. Enter 0 0, (zero) (zero) Defaullt XLAPLAN, enter valid entries from Table XLAPLAN Default RATEAREA, enter valid entries from Table RATEAREA
DGCLNAME Enter NIL FANIDIGS DFLTXLP DFLTRA
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>]
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
31
Module 8
Universal Translations Datafill International Calls
nortel.com/training
V10.0
Module 8 Universal Translations International Calls

Purpose The purpose of this section is to introduce the student to the concepts of; > Universal Translations datafill procedures. After this module of instruction, you will be able to 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
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
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.
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.
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.
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 .
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 dfop class dflt intl rte $ mm nocon 7 std 18 dest 3 class intl $ DFOPSEL OSEL CLASS OSEL CON MAXIDX
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 MAXIDX field shows that any digit in the range 0 to 9 is valid in the CODE table. 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.
The CODE table will look like this: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 pstnctla 3 6 t t ibnrte ibnrte 70 60 $ $ XLANAME RTEREF RTESEL TABNAME INDEX RTESEL
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.
TABLE PXHEAD XLANAME DFLTSEL DFOPSEL CON MAXIDX pstnpxla sdflt nodfop con std
TABLE PXCODE XLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGS OSEL pstnpxla 00 00 cont xlt ct pstnctla consume 2 $
TABLE CTHEAD XLANAME DFLTSEL XLASEL OSEL MIN MAX OSEL DEST OSEL CLASS OSEL pstnctla dfop class dflt intl rte $ mm nocon 7 std 18 dest 3 class intl $ DFOPSEL OSEL CLASS OSEL CON MAXIDX
TABLE CTCODE XLANAME FROMD TOD XLASEL OSEL MIN MAX OSEL DEST OSEL pstnctla 31 31 rte mm 11 11 DEST 6 $
TABLE CTRTE XLANAME RTEREF RTESEL TABNAME INDEX RTESEL pstnctla pstnctla 3 6 t t ibnrte ibnrte 70 60 $ $ Other International European XLANAME RTEREF RTESEL TABNAME INDEX RTESEL
10
TABLE PXHEAD XLANAME DFLTSEL DFOPSEL CON MAXIDX pstnpxla sdflt nodfop con std
TABLE PXCODE XLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGS OSEL pstnpxla 00 00 cont xlt ct pstnctla consume 2 $
TABLE CTHEAD XLANAME DFLTSEL XLASEL OSEL MIN MAX OSEL DEST OSEL CLASS OSEL pstnctla dfop class dflt intl rte $ mm nocon 7 std 18 dest 3 class intl $ DFOPSEL OSEL CLASS OSEL CON MAXIDX
TABLE CTCODE XLANAME FROMD TOD XLASEL OSEL MIN MAX OSEL DEST OSEL pstnctla 31 31 rte mm 11 11 DEST 6 $
TABLE CTRTE XLANAME RTEREF RTESEL TABNAME INDEX RTESEL pstnctla pstnctla 3 6 t t ibnrte ibnrte 70 60 $ $ XLANAME RTEREF RTESEL TABNAME INDEX RTESEL
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. 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 Default from table XLANAME: CXCLASS (NET N N 0 N NDGT N Y DOD N 1 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 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 $
14
TABLE PXHEAD DEMOXLA SDFLT DFOP $ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 00331234567890 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 331234567890 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 Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 DANEURO TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT
15
Traver - Rest of the World

>TRAVER L 8795215 0063334745255 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. 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 Default from table XLANAME: CXCLASS (NET N N 0 N NDGT N Y DOD N 1 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 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 $
16
TABLE PXHEAD DEMOXLA SDFLT DFOP $ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0063334745255 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 63334745255 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 Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 DANNONEURO TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT
17
18
18

19
19
Universal Translations Datafill International Calls Exercise
from table LINEATTR

IDD
PX PSTNPXLA
SDFLT (temporarily)
CT PSTNCTLA
DFLT
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
Universal Translations Datafill Local Calls
nortel.com/training
V10.0
Module 9 Universal Translations Datafill Local Calls

Purpose The purpose of this section is to introduce the student to the concepts of; > Universal Translations datafill procedures After this module of instruction, you will be able to Describe the call flow process in Universal Translations Datafill an exercise to handle Local Calls, using the translation selectors DMOD, CONT and RTE with applicable OSEL options Traver the results of your datafill Explain the results of the Travers
from table LINEATTR

IDD
PX PSTNPXLA
Local SDFLT (temporarily)
CT PSTNCTLA
OFC 628FALA
DFLT
SDFLT
Terminate Local calls
Treatment
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.
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 CON MAXIDX con std dflt cont xlt fa pstnfala dfop class natl
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. 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 pstnpxla pstnpxla 016287 79 OSEL consume XLASEL OSEL XLASYS XLANAME OSEL cont xlt insrt 01628 $ ofc xlt CONDIGS 4 016287 79 0 6287fla consume px pstnpxla
XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAME dmod CONDIGS OSEL
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.
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 MAXIDX field shows that any digit in the range 0 to 9 is valid in the CODE table. 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 6287fla 879 879
XLASEL OSEL DEST OSEL MIN MAX OSEL 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 XLANAME RTEREF RTESEL TABNAME INDEX 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.
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 CON MAXIDX con std dflt cont xlt fa pstnfala dfop class natl
TABLE PXCODE XLANAME FROMD TOD pstnpxla pstnpxla 016287 79 OSEL consume TABLE OFCHEAD XLANAME DFLTSEL DFOPSEL OSEL CLASS CON MAXIDX 6287fla sdflt dfop class natl nocon std XLASEL OSEL XLASYS XLANAME OSEL cont xlt insrt 01628 $ ofc xlt CONDIGS 4 016287 79 0 6287fla consume px pstnpxla
XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAME dmod CONDIGS OSEL
TABLE OFCCODE XLANAME FROMD TOD 6287fla 879 879 XLASEL OSEL DEST OSEL MIN MAX OSEL rte dest 1 MM 7 7 $
TABLE OFCRTE XLANAME RTEREF RTESEL TABNAME INDEX 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.
Traver - Local number full format

>TRAVER L 7895215 01628795214 B INVALID DIRECTORY NUMBER >TRAVER L 8795215 01628795214 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. 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 Default from table XLANAME: CXCLASS (NET N N 0 N NDGT N Y DOD N 68 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 68 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA 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 PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( MM 3 18) ( CLASS NATL) $ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795214 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 8795214 TABLE OFCCODE 628FLA 879 879 RTE ( DEST 1) $
Continued overleaf
Traver - Local number full format - continued

TABLE: OFCRTE KEY: 628FLA 1 . T IBNRTE 79 . . TABLE IBNRTE . . 79 DN 162 879 N 0 4 . . . TABLE TOFCNAME . . . 162 879 $ . . . TABLE DNINV . . . 162 879 5214 L RM05 00 0 02 14 TABLE DNFEAT TUPLE NOT FOUND . . . TABLE DNATTRS . . . TUPLE NOT FOUND . . . TABLE DNGRPS . . . 162 879 5214 5214 . . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$ . . EXIT TABLE IBNRTE EXIT TABLE OFCRTE Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 LINE 1628795214 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++
10
Traver - Local number short format

>traver l 8795215 795214 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. 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 CLASSDIG 7 COL L 5 TABLE IBNXLA: XLANAME CXCLASS TUPLE NOT FOUND Default from table XLANAME: CXCLASS (NET N N 0 N NDGT N Y DOD N 68 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 68 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA 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 PSTNPXLA DFLT CONT ( XLT PX INTERNAT) $ DFOP ( CLASS NATL) $ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 795214 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795214 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 8795214 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 . . . TABLE TOFCNAME . . . 162 879 $ . . . TABLE DNINV . . . 162 879 5214 L RM05 00 0 02 14 TABLE DNFEAT TUPLE NOT FOUND . . . TABLE DNATTRS . . . TUPLE NOT FOUND . . . TABLE DNGRPS . . . 162 879 5214 5214 . . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$ . . EXIT TABLE IBNRTE EXIT TABLE OFCRTE Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 LINE 1628795214 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
12
13

14
14
15
from table LINEATTR

IDD
PX PSTNPXLA
Local DFLT (temporarily)
CT PSTNCTLA
OFC 628FALA
DFLT
SDFLT
Treatment
16
Exercise 2 The purpose of this exercise is to :Practise the use of the Cont, Rte and Dmod selectors, with appropriate options, to translate through the PX and OFC XLASYS. Students are required to:Translate Local calls using both the full national and 6 digit number. Use the routes previously datafilled in Route Exercise A. The translation requirements are :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. Datafill the Universal Translation Tables. Traver your datafill and test by dialling.
16
17
Module 10
Universal Translations Datafill National Calls
nortel.com/training
V10.0
Module 10 Universal Translations 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 After this module of instruction, you will be able to Describe the call flow process in Universal Translations Datafill an exerise to handle National Calls, using the translation selectors CONT and RTE and SETCODEC with applicable OSEL options Traver the results of your datafill Explain the results of the Travers
from table LINEATTR

IDD
PX PSTNPXLA
Local DFLT (non-IDD)
CT PSTNCTLA
OFC 628FALA
FA PSTNFALA
DFLT
SDFLT
DFLT
Route to adjacent switches
Treatment
Default Route for calls to the rest of the country
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.
Universal Translations Other National Destinations

DFLT (non-IDD) from PX
FA PSTNFALA
Adjacent known codes - Route to Trunks Freephone numbers Mobile numbers - Route to higher tandem switch for real number resolution - Route to Mobile network
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.
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 pstnfala 01628 01753 01628 01753 rte dest 162 ......................... rte dest 175 .........................
TABLE FARTE XLANAME RTEREF RTESEL pstnfala pstnfala 162 175 t t ofrt 162 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 pstnfala pstnfala 0800 0500 0800 0500 rte dest 800 ......................... rte dest 500 .........................
TABLE FARTE XLANAME RTEREF RTESEL pstnfala pstnfala 800 500 s s DAN800 DAN500
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.
xxCODE SETCODEC selector The following datafill example shows the SETCODEC selector. TABLE: FACODE XLANAME FROMD TOD XLADATA -------------------------------------------------------------------------------------------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 MOBILE INTL CODEC ( PCMA) $ ( PCMA) $ OPTIONS $ $ ---------------------------------------------------
The fields of Table CODEC are as follows; CALLTYPE CODEC CODEC_KEY 8 character alphanumeric value, customer defined. 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.
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 AIN_OFFICE_TRIGGRP NIL AIN Orig Attempt TDP: no subscribed trigger. TABLE NCOS UNIGRP 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL UNIGRP NXLA UNICT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually NCOS PRELIM XLA name is NIL. Go to next XLA name. CUST PRELIM XLA name is NIL. Go to next XLA name. TABLE IBNXLA: XLANAME UNICT TUPLE NOT FOUND Default from table XLANAME: UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN 162_NPRT_150 NSCR 150 NPRT NONE N $ TABLE RATEAREA NLCA_NILLA_1 NLCA NIL NILLATA $ TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01753456789 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD PSTNFALA DFLT RTE ( MM 3 11)( DEST 3)(CLASS NATL) $ DFOP(CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01753456789 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED
Continued overleaf
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 +++ DIGIT TRANSLATION ROUTES 1 NTMH4B2WNAT 01753456789 ST 2 NTMH4B2WLOC 01753456789 ST TREATMENT ROUTES. TREATMENT IS: BUSY 1 ENGAGED +++ TRAVER: SUCCESSFUL CALL TRACE +++
10
Traver - 0800 call

traver l 8795301 0800234567 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 AIN_OFFICE_TRIGGRP NIL AIN Orig Attempt TDP: no subscribed trigger. TABLE NCOS UNIGRP 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL UNIGRP NXLA UNICT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually NCOS PRELIM XLA name is NIL. Go to next XLA name. CUST PRELIM XLA name is NIL. Go to next XLA name. TABLE IBNXLA: XLANAME UNICT TUPLE NOT FOUND Default from table XLANAME: UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN 162_NPRT_150 NSCR 150 NPRT NONE N $ TABLE RATEAREA NLCA_NILLA_1 NLCA NIL NILLATA $ TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0800234567 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED
Continued overleaf
11
Traver - 0800 call - continued

TABLE FAHEAD PSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0800234567 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 +++ TRAVER: TREATMENT SET +++ DIGIT TRANSLATION ROUTES 1 NTMH4B2WNAT 0800234567 ST 2 NTMH4B2WLOC 0800234567 ST TREATMENT ROUTES. TREATMENT IS: BUSY 1 ENGAGED +++ TRAVER: SUCCESSFUL CALL TRACE +++
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 (PUBLIC ( ADDRESS 207 610 NNNN) $)$ Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. TABLE NCOS EMEA_G6 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL EMEA_G6 NXLA EMG6CT EMG6FET 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually TABLE IBNXLA: XLANAME EMG6CT EMG6CT 0 NET N N 1 N NDGT Y N DOD N 2 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 2 IBN NONE NT 0 0 NILSFC 0 PX PXDEMO NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $
13
Traver Mobile network call continued

TABLE PXHEAD PXDEMO DFLT CONT ( CLASS NATL) ( CONSUME 0) ( XLT FA FADEMO)$ NODFOP CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD FADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 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 Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ 07745678901 07745678901
DIGIT TRANSLATION ROUTES 1 UKPVG 07745678901 ST
SETCODEC option encountered. Codec Requested: PCMA TREATMENT ROUTES. TREATMENT IS: GNCT 1 UNOBT SETCODEC option encountered. Codec Requested: PCMA +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
14

15
15
16
from table LINEATTR

IDD
PX PSTNPXLA
CT PSTNCTLA
OFC 628FALA
FA PSTNFALA
DFLT
SDFLT
DFLT
Routes to specific destinations
Treatment
Default Route for calls to rest of the country
17
Exercise National Calls

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 FA XLASYS. Students are required to:Translate National calls. Use the routes previously datafilled in Route Exercise A which point to your partner trunks datafilled in the Trunk Group Exercise. The translation requirements are :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. Plan your translations on paper and discuss the results with your instructor. TASK B. Datafill the Universal Translation Tables. Traver your datafill and test by dialling. 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
V10.0
Module 11 Time Of Day Routing

Purpose The purpose of this section is to introduce the student to the concepts of; > The Time of Day Route System feature. After this module of instruction, you will be able to > 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.
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. Table OFRT, 2,3,4. Table OVR0 OVR89 Ibn Route Office Route 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 Table DAYOWEEK Table DAYOYEAR Table TODHEAD Table TIMEODAY Type of Day Day of Week Day of Year Time of Day Head Time of Day
These tables will be discussed first.
Table DAYTYPES
Table DAYTYPES DAYTYPE --------------HOLIDAY WEEKEND WEEKDAY SPARE1 SPARE2 SPARE3 SPARE4 SPARE5 MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY
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.
Table TODHEAD
Table TODHEAD TODNAME TODTYPE TIME demotod rte 0
DAYTYPES (holiday)(weekday)(weekend) (spare1) (spare2) (spare3) (xmas)
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 Time of day type. Enter RTE to indicate that this is a ROUTE time of day system. 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.
Table DAYOWEEK
Table DAYOWEEK TODNAME WEEKDAY demotod mon demotod tue demotod wed demotod thu demotod fri demotod sat demotod sun
DAYTYPE weekday weekday weekday weekday weekday weekend weekend
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 DAYTYPE 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. 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.
Table DAYOYEAR
Table DAYOEAR TODNAME MONTH DAY demotod dec 25 demotod jan 01
DAYTYPE xmas holiday
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.
Table TIMEODAY
Table TIMEODAY TODNAME DAYTYPE demotod weekday demotod weekday demotod weekday
TIME 00 00 08 00 12 00
DATA rte 1 rte 2 rte 1
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 < Time Rte 1 08:00 >< Time Rte 2 12:00 >< Time Rte 1 23:59 >
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.
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 OHQ CBQ EXP MBG CLLI s n n n n ntmdhddlog IBNRTSEL OHQ CBQ EXP MBG CLLI s n n n n ntslghdlog 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 DAYTYPES MONDAY WEEKEND WEEKDAY HOLIDAY XMAS Table DAYOWEEK TODNAME DEMOTOD DEMOTOD DEMOTOD DAY DAYTYPE MON WEEKDAY FRI HOLIDAY SAT WEEKEND
Table DAYOYEAR TODNAME MONTH DAY DAYTYPE DEMOTOD DEC 25 XMAS
Table TODHEAD TODHEAD TODTYPE TIMES DEMOTOD RTE 0
DAYTYPES (WEEKDAY) (WEEKEND)(XMAS)(HOLIDAY)(SPARE1)
Table TIMEODAY TODNAME DAYTYPE HOUR MIN TODTYPE TIME DEMOTOD HOLIDAY 00 00 RTE 1 DEMOTOD HOLIDAY 08 00 RTE 2 DEMOTOD HOLIDAY 12 00 RTE 1 Table IBNRTE RTE IBNRTSEL CNDSEL TODNAME TIMES RTETYPE RTEREF 201 CND TOD DEMOTOD 2 ST 301 IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUM CND TOD DEMOTOD 1 SK 1 IBNRTSEL OHQ CBQ EXP MBG CLLI s n n n n ntmdhddlog IBNRTSEL OHQ CBQ EXP MBG CLLI s n n n n ntslghdlog IBNRTSEL EXTRTEID t ibnrte 300
11
00:00
08:00
12:00
23:59 Time Rte 1
Time Rte 1
Time Rte 2
holiday
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: ALL: NAME: This Display. Current results for all TODNAMES. 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

15
15
Universal Translations Datafill Time-Of-Day Routing
from table LINEATTR

IDD
PX PSTNPXLA
CT PSTNCTLA
OFC 628FALA
FA PSTNFALA
DFLT
SDFLT
DFLT
Routes to specific destinations Time Of Day Routing Tables Route A Route B
Treatment
16
Time Of Day Routing Exercise The purpose of this exercise is to: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
V10.0
Module 12 Universal Translations Service Calls

Purpose The purpose of this section is to introduce the student to the concepts of; > Handling of Service calls, i.e. Operator and Emergency calls. After this module of instruction, you will be able to > 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
Universal Translations Datafill Service Calls
from table LINEATTR

IDD
PX PSTNPXLA
Local
Service
PX SRVCPXLA
DFLT (non-IDD) SDFLT
CT PSTNCTLA
OFC 628FALA
FA PSTNFALA
Treatment
DFLT
SDFLT
DFLT
Routes to specific destinations Time Of Day Routing Tables Route A Route B
Treatment
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.
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.
Traver - 999 call

traver l 8795301 999 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 AIN_OFFICE_TRIGGRP NIL AIN Orig Attempt TDP: no subscribed trigger. TABLE NCOS UNIGRP 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL UNIGRP NXLA UNICT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually NCOS PRELIM XLA name is NIL. Go to next XLA name. CUST PRELIM XLA name is NIL. Go to next XLA name. TABLE IBNXLA: XLANAME UNICT TUPLE NOT FOUND Default from table XLANAME: UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN 162_NPRT_150 NSCR 150 NPRT NONE N $ TABLE RATEAREA NLCA_NILLA_1 NLCA NIL NILLATA $
TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 999 TABLE PXCODE PSTNPXLA 999 999 CONT ( XLT PX SRVCPXLA)$ TABLE PXHEAD SRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 999 TABLE PXCODE SRVCPXLA 999 999 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$ TABLE FAHEAD PSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 99912 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 +++ TRAVER: TREATMENT SET +++ DIGIT TRANSLATION ROUTES 1 NTMH4B2WEMG 99912 ST 2 NTMH4B2WLOC 99912 ST TREATMENT ROUTES. TREATMENT IS: BUSY 1 ENGAGED +++ TRAVER: SUCCESSFUL CALL TRACE +++
Traver - 112 call

TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 112 TABLE PXCODE PSTNPXLA 112 112 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$ TABLE PXHEAD SRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 112 TABLE PXCODE SRVCPXLA 112 112 DMOD ( DEL 3) ( INSRT 99912) ( XLT FA PSTNFALA)$ TABLE FAHEAD PSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 99912 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 DIGIT TRANSLATION ROUTES 1 NTMH4B2WEMG 99912 ST 2 NTMH4B2WLOC 99912 ST
10
Traver - 100 call

11
TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 100 TABLE PXCODE PSTNPXLA 100 100 CONT ( XLT PX SRVCPXLA)$ TABLE PXHEAD SRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 100 TABLE PXCODE SRVCPXLA 100 100 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$ TABLE FAHEAD PSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 10012 TABLE FACODE PSTNFALA 10012 10012 RTE ( MM 5 5) ( DEST 1)$ TABLE: FARTE KEY: PSTNFALA 1 . T OFRT 999 . . TABLE OFRT . . 999 S D NTMH4B2WEMG . . S D NTMH4B2WLOC . . TRMT BUSY DIGIT TRANSLATION ROUTES 1 NTMH4B2WEMG 10012 ST 2 NTMH4B2WLOC 10012 ST
12
Traver - 151 call

13
TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 151 TABLE PXCODE PSTNPXLA 151 151 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$ TABLE PXHEAD SRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 151 TABLE PXCODE SRVCPXLA 151 151 DMOD ( DEL 3) ( INSRT 01628795616) ( XLT PX PSTNPXLA)$ TABLE PXHEAD PSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795616 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 5616 TABLE OFCCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE: OFCRTE KEY: 6287FLA 1 . T IBNRTE 79 . . TABLE IBNRTE . . 79 DN 162 879 N 0 . . EXIT TABLE IBNRTE EXIT TABLE OFCRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 LINE 1628795616 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++
14
15

16
16
17
Service Calls - Exercise The purpose of this exercise is to :Practise the use of the Cont ,Rte and Dmod selectors, with appropriate options, to translate through the PX and FA XLASYS. Students are required to:Translate Emergency and Operator assistance calls. The translation requirements are :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. Plan your translations on paper and discuss the results with your instructor. TASK B. Datafill the Universal Translation Tables. Traver your datafill and test by dialling. 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
Universal Translations Datafill Service Calls
from table LINEATTR

IDD
PX PSTNPXLA
Local
Service
PX SRVCPXLA
DFLT (non-IDD) SDFLT
CT PSTNCTLA
OFC 628FALA
FA PSTNFALA
Treatment
DFLT
SDFLT
DFLT
Route to adjacent switches Time Of Day Routing Tables Route A Route B
Treatment
19
19
20
Module 13
Universal Translations Indirect Access
nortel.com/training
V10.0
Module 13 Universal Translations 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.
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.
Call Completion Scenarios

Call routed to B only if requested
Network A Default network, e.g. PTT

Transit switch Terminating switch Call termination Default ingress typically for calls terminating within network B
Call origination
Requested ingress with authorisation checks
Egress for calls terminating to network A lines
Media Gateway
Media Gateway
CS2000
Media Gateway Call origination 5
CS2000
Media Gateway Call termination
Network B Alternative national operator using IP or ATM packet backbone
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.
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.
Different types of Indirect Access

Access method Table Used CLI Checked? Initial information provided Access code + destination number Carrier ID + destination number Access code 2nd tone? Further information provided N/A Main advantage Speed/convenience for voice calls; support for data calls Speed/convenience for voice calls; support for data calls Account code billing for business customers Confirmation of access to alternative network
Singlestage
DNSCRN
Yes
No
CLI_ based access
Carrier selection DNSCRN screening Account code required DNSCRN
Yes
No
N/A Account code + destination number Destination number [1] Authorisation code + destination number [2]
Yes
Yes
MONA via ambiguous DNSCRN translations Authcode access AUTHCDE
Yes
Access code
Yes
No
Access code
Yes
Support for roaming access; more powerful screening
[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.
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 TDMside 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 inband DTMF digits. These are collected by the originating media gateway (or via a TDMside 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.
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.
Indirect Access CLI based Single stage

Table LINEATTR
PXCODE
XLASYS cs2kpx FROMD 0901 TOD 0901 XLASEL featinfo FTR validate CLI screening check XLASYS px2 XLANAME cs2kpx
VALDATOP SUBSCRN Check for CLI in DNSCRN Pass screening Continue translating
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 suboptions. For CLI screening to occur the SUBSCRN sub-option is used. CLI screening will be dealt with first using the FEATINFO/VALIDATE/SUBSCRN suboption. There are other Sub-Options available for the VALIDATE option, which include; BCSCRN CLISERV CUSTMOD identifies Bearer Capability. The CLISERV field indicates the name of the CLI Screening Services index in Table CLISERV. alters the NCOS and Customer Group to a new value for a given DN based on the CUSTINFO attributes in table DNSCRN. CLDTOCLG copies digits from the calling to the called digit stream.
For this module however we will only be dealing with the two CLI related options; FEATINFO/VALIDATE SUBSCRN FEATINFO/VALIDATE - CLISERV.
FEATINFO option VALIDATE - SUBSCRN

xxCODE
XLASYS cs2kpx FROMD 0901 TOD 0901 XLASEL featinfo FTR validate XLASYS px2 XLANAME cs2kpx
VALDATOP SUBSCTYP WHITLIST CHKUNPD CHBLKCL CHKCCR subscrn general N N Y N SUBSCTYP $ VALDATOP $ PFDIGS MINDIGS MAXDIGS 0 11 11 Table DNSCRN DN 01182345678 ATTROPTS (UNPAID) (BLCKCALL) $
Continue translating
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 PFDIGS
Y or N Check cumulative call restriction. Enter Y to check the subscribers cumulative charge limit. Otherwise, enter N. 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). 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. 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. see subfields Table reference. This field consists of subfields XLASYS and XLANAME.
MINDIGS
MAXDIGS
TABREF
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. allows the use of CLI service screening and CLI based routing
BLCKCALL indicates that the DN cannot make or receive calls. CLISERV
An example tuple is shown below. TABLE: DNSCRN DN 1628795352 ATTROPTS ( 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
XLASYS cs2kfa FROMD 0901 TOD 0901 XLASEL featinfo FTR validate XLASYS fa2 fa XLANAME cs2kfa 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 Table CLISERV SERVNAME CLIDEMO
13
Fail Screening
SERVNUM SERVOPTS 2 ( PARTIAL ) ( FAILAMA ) ( SERVAMA ) ( FAILRTE FA SCRNFAIL ) $

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 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.
ACCTREQ
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 Originator is not an EIN agent, therefore EIN info is not processed. TABLE NCOS BOB 0 0 0 CLASS $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL BOB NXLA BOBCT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually TABLE IBNXLA: XLANAME BOBCT TUPLE NOT FOUND Default from table XLANAME: BOBCT (NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $) $9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR DANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA 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 BOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD BOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11) (CLASS NATL) $ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 123456 TABLE FACODE VALIDXLA 1 1 RTE ( DEST 5)$ TABLE: FARTE KEY: VALIDXLA 5 . S NTEDILONBTUP EXIT TABLE FARTE Originator is not an EIN agent, therefore EIN info is not processed. Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 NTEDILONBTUP 0898123456 ST TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++
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 Originator is not an EIN agent, therefore EIN info is not processed. TABLE NCOS BOB 0 0 0 CLASS $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL BOB NXLA BOBCT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually TABLE IBNXLA: XLANAME BOBCT TUPLE NOT FOUND Default from table XLANAME: BOBCT (NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $) $9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR DANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA 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 BOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD BOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11) (CLASS NATL) $ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 TABLE FACODE BOBFALA 0898 0898 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y Y N N) $) $ 0 10 10 FA VALIDXLA PLEASE ENTER CLI DIGITS: >1234567890 TABLE DNSCRN . No match found
17
. Screening failed +++ TRAVER: TREATMENT SET +++ TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLED TREATMENT ROUTES. TREATMENT IS: CNAD 1 UKREORDER +++ TRAVER: SUCCESSFUL CALL TRACE +++
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 Originator is not an EIN agent, therefore EIN info is not processed. TABLE NCOS BOB 0 0 0 CLASS $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL BOB NXLA BOBCT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually TABLE IBNXLA: XLANAME BOBCT TUPLE NOT FOUND Default from table XLANAME: BOBCT (NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $) $9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR DANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA 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 BOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD BOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11) (CLASS NATL) $ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456 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 (UNPAID )
19
. CLI unpaid . Screening failed +++ TRAVER: TREATMENT SET +++ TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLED TREATMENT ROUTES. TREATMENT IS: CNAD 1 UKREORDER +++ TRAVER: SUCCESSFUL CALL TRACE +++
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 INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 CSDIG TABLE DIGCOL CSDIG 0 RPT INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO TUPLE NOT FOUND Default from table XLANAME: CXDEMO (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS INTL)$ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED 01252855111
21
TABLE FAHEAD FADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE FACODE FADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) ( CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMO PLEASE ENTER CLI DIGITS: >1312345000 TABLE CLISERV . CLIDEMO 1 ( PARTIAL ) ( FAILRTE FA SCRNFAIL) ( FAILAMA ) ( SERVAMA )$ TABLE DNSCRN . 1312345 $ TABLE FAHEAD FADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE FA2CODE Default from head table used TABLE: FARTE KEY: FADEMO . 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++ 5 01252855111 01252855111
DIGIT TRANSLATION ROUTES 1 PBX_SITE_A 01252855111 ST
TREATMENT ROUTES. TREATMENT IS: GNCT 1 UNOBT +++ TRAVER: SUCCESSFUL CALL TRACE +++
22
TRAVER of an un 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 INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 CSDIG TABLE DIGCOL CSDIG 0 RPT INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO TUPLE NOT FOUND Default from table XLANAME: CXDEMO (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS INTL)$ CON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED 01252855111
23
TABLE FAHEAD FADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111 TABLE FACODE FADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) ( CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMO PLEASE ENTER CLI DIGITS: >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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE: FARTE KEY: SCRNFAIL 1 . S CLI_FAIL_ANNC 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++
DIGIT TRANSLATION ROUTES 1 CLI_FAIL_ANNC TREATMENT ROUTES. TREATMENT IS: GNCT 1 UNOBT +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
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 01182005000 ATTROPTS (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 decision Table DNINV Table DNROUTE Table AUTHPART Table AUTHCDE Table DIALPLAN
29
Pass Screening? Continue translating Fail Screening? Treatment
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 OPTIONS $ AUTHONLY FIRST CDT SDT N
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 207 620 6000 DNRESULT 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) $
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
Indirect Access MONA via ambiguous translations - continued


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 cs2kauth ibn
LENGTH 4
MAXSIZE 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. 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 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. 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
FORMAT
LENGTH
MAXSIZE
37


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 Private Speed Calling Authcode Hotline Customer group TONEBURST PSC HOTLINE CUSTGRP
An example tuple is given below:TABLE AUTHCDE AUTHPART AUTHCODE FORMAT NCOS ACCT SECDIGS AUTHTYPE cs2kauth OPTION $ 12567 ibn 0 n $ sw
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. 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. 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. 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.
FORMAT
NCOS
SECDIGS
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 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. 12469 ibn 3 y 5643 sw
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 cs2kcust - - - - - - - - - - - - - auth PARTNM authdem SECRECY COMB y y
In this example, the option AUTH has been added to the cs2kcust customer group. The option consists of the following fields:OPTION PARTNM SECRECY Option. Enter the name of the required option, AUTH in this example. Authorisation Partition Name. Enter the name of the Authpart table used by the Customer Group. 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 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. a
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 cs2kcust 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 DIGINACC Option. Enter the name of the required option, ACCT in this example. 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. 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. POTS Digit collection. Y or N. Only answer is N. ------acct 3 y y POTSDGT ACCTVAL n
NOTIMOUT Time Out. Enter the method used to indicate the end of an account code
POTSDGT
42
Indirect Access MONA via ambiguous translations continued


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 CUTHRUTY Dial Plan Name. 1-16 alphanumeric 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 AUTHPART PARTIAL CONFTONE CUSTGRP / NCOS MASK Allows variable-length authcodes (2-14 digits) Allows the authcode partition associated with the callers customer group to be overridden Allows partial authcode screening Causes a confirmation tone to be played to the caller after successful authcode screening Allows the csutomer group and/or NCOS associated with the caller to be overridden Allows authcode digits that would normally appear in the AMA record to be masked
44


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 MM T FEAT Treatment Meet Me Conference (Datafilled in Table MMCONF ) Route list in table OFRT or IBNRTE Centrex Feature.
The special Centrex features accessed by DNs in table DNROUTE are:ACD DISA MONA UCD Automatic Call Distribution Direct Inward System Access Meridian Offnet Access 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 207 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 DN_SEL Station Code. Enter the digits of the Station code. Directory Number Selector. Enter the appropriate selector. The FEAT selector is used in this example. FEATURE OPTION Feature. Enter the required feature acronym. MONA in this example. 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. 620 6000 DN_SEL FEATURE DIALPLAN feat mona default
The following pages have an example of a call to a MONA number. This shows the links through these tables.
46
>traver tr ukpvg 02076206000 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 Original Customer Group and NCOS TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 NDGT ( AUTH CS2KAUTH N N) TABLE DIGCOL NDGT specified: digits collected individually AUTH option associated to CustGrp INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO CXDEMO 02 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 02076206000 TABLE PXCODE CS2KPX 0207 0207 CONT ( MM 11 11) ( XLT OFC 2KLOCAL)$ TABLE OFCHEAD 2KLOCAL SDFLT DFOP ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 02076206000 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 . . . TABLE TOFCNAME . . . 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) $ TABLE NCOS CS2KCUST 0 0 0 NO_RST $ Call continues with possible new CustGrp and NCOS TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually TABLE IBNXLA: XLANAME CXDEMO CXDEMO 01 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS N ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED 01628795888 Call enters Universals with HOTLINE number and processed as normal 01628795888 Auth Code check and options
48
TABLE: FARTE KEY: 01628FA . S DANNAT EXIT TABLE FARTE TABLE DNFEAT TUPLE NOT FOUND . . . TABLE DNATTRS . . . TUPLE NOT FOUND . . . TABLE DNGRPS . . . TUPLE NOT FOUND . . EXIT TABLE IBNRTE EXIT TABLE OFCRTE TABLE TRIGGRP ETSIGRP INFOANAL . GENTRIG ( CDPN ETSITRIG)$ NIL Trigger INAPV8 GENTRIG is applicable to office. INAP Info Analyzed TDP: trigger criteria not met. +++ TRAVER: SUCCESSFUL CALL TRACE +++ 1
DIGIT TRANSLATION ROUTES 1 FEATURE 2076206000 ST
TREATMENT ROUTES. TREATMENT IS: GNCT 1 UNOBT +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
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
V10.0
Module 14 Universal Translations 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
Call Control and Universal Screening
Trunk Group option Table CALLCNTL
Enhanced CLI Screening
Universal Screening
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.
Universal Screening Tables

Entry to US via Enhanced CLI screening Tables DNSCRN + CLISRVPF Entry to US on trunk group basis Table TRKOPTS Table CCNTLGRP Table DTMFSCRN IBNXLA processing DIGMAN manipulation Entry to US from translations CCNTLRX Selector
Table ACCTSCRN
Table CALLCNTL
Table CGPNSCRN
Table CDPNSCRN
Table CDPNLSCR
Table NCOSSCRN
Table CGRPSCRN
Table SINTSCRN
Table CDNNSCRN
Table NOASCRN
Table BCSCRN
Table CICSSCRN
Table RDRISCRN
Table CKTSCRN
Table IPISCRN
Table CPCNSCRN
Table OLISCRN
Table VARDEF
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
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.
Call Control and Universal Screening 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
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.
Call Control and Universal Screening entry from translations

Universal Translations xxRTE tables
XLANAME RTEREF RTELIST ---------------------------------------------------------------------------CS2KPX 2 ( GBL CCNTLRX SCRN_4_64KDATA Y Y N
0)$
Table CALLCNTL
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.
Call Control and Universal Screening entry from enhanced CLI screening
Table DNSCRN
DN ATTROPTS ---------------------------------------------------------------------------01483891111 ( CLISERV 1) $
Table CLISRVPF
PROFIDX PROFOPTS ---------------------------------------------------------------------------1 (TEST (CCNTLIDX SCRN_4_64KDATA) $ )$
Table CALLCNTL
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.
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 Enhanced CLI screening Tables DNSCRN + CLISRVPF Entry to US on trunk group basis Table TRKOPTS Table CCNTLGRP Table DTMFSCRN IBNXLA processing DIGMAN manipulation Entry to US from translations CCNTLRX Selector
Table ACCTSCRN
Table CALLCNTL
Table CGPNSCRN
Table CDPNSCRN
Table CDPNLSCR
Table NCOSSCRN
Table CGRPSCRN
Table SINTSCRN
Table CDNNSCRN
Table NOASCRN
Table BCSCRN
Table CICSSCRN
Table RDRISCRN
Table CKTSCRN
Table IPISCRN
Table CPCNSCRN
Table OLISCRN
Table 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-partynumber 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 subtable (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
Call Control and Universal Screening entry from Trunks example 1

Table TRKGRP GRPKEY
Incoming Trunk
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 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 HOLLANDPVG CCNTLIDX CCNTLIDX SCRN_4_64KDATA 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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS GRP1 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL GRP1 NXLA GRP1CT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME GRP1CT TUPLE NOT FOUND Default from table XLANAME: GRP1CT (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $
17
TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE: FARTE KEY: 01628FA 1 . S DANNAT 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >64kdata DIGIT TRANSLATION ROUTES 1 DANNAT 01234567890 ST
18
Call Control and Universal Screening entry from Trunks example 2

Table TRKGRP GRPKEY
Incoming Trunk
GRPINFO ---------------------------------------------------------------------------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 CGPNSCRN_KEY CGPNDATA ----------------------------------------SCRN_4_GOLD_CUSTOMER (
1)
TABLE: CGPNSCRN SCRN_4_GOLD_CUSTOMER: CGPNDATA FROMDIGS TODIGS CGPNINDX CCOPTION CGPNOPT ---------------------------------------------------------------------------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. 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 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 0 N N N N N N N N N NATL $ TABLE TRKOPTS FRANCEPVG CCNTLIDX CCNTLIDX SCRN_4_GOLD_CUSTOMER TABLE CALLCNTL SCRN_4_GOLD_CUSTOMER (SCRN ( CGPN ) $) (GOTO CALLCNTL CHG_CUSTGRP ) $ PLEASE ENTER CLI DIGITS: >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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS GRP4 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL GRP4 NXLA GRP4CT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME GRP4CT TUPLE NOT FOUND Default from table XLANAME: GRP4CT (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE
21
TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLAS ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE: FARTE KEY: 01628FA 1 . S DANNAT 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 DANNAT 01234567890 ST
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 0 0 0 N N N N N N N N N NATL $ TABLE TRKOPTS FRANCEPVG CCNTLIDX CCNTLIDX SCRN_4_GOLD_CUSTOMER TABLE CALLCNTL SCRN_4_GOLD_CUSTOMER (SCRN ( CGPN ) $) (GOTO CALLCNTL CHG_CUSTGRP ) $ PLEASE ENTER CLI DIGITS: >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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS GRP1 0 0 0 $ $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL GRP1 NXLA GRP1CT NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME GRP1CT TUPLE NOT FOUND Default from table XLANAME: GRP1CT (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE
23
TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLAS ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE: FARTE KEY: 01628FA 1 . S DANNAT 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 DANNAT 01234567890 ST
24

25
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.
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
Call Control and Universal Screening Path of Entry Screening

CS2000
a ll eC c i Vo
Carrier X Carrier Y Carrier Z
Incoming Trunk
Da ta
PSTN
Ca ll
Carrier Y 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 Universal Translations 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

Incoming Trunk
Table TRKGRP GRPKEY 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 OPTKEY OPTINFO ---------------------------------------------------------------------------ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN
Table BCSCRN BC_KEY NEWSCRN_KEY CCOPTION ------------------------------------------------------------------------------------------INITIAL_SCREEN SPEECH SET_VOICE_CUSTGRP $ INITIAL_SCREEN 64KDATA SET_DATA_POE $
Table CALLCNTL CALCTL_KEY CALCTL_OPTIONS ---------------------------------------------------------------------------INITIAL_SCREEN (SCRN (BC) $ ) $ SET_VOICE_CUSTGRP (CUSTGRP DEFAULT) $ SET_DATA_POE (POECNAME (POECGRP POE_DATA) (POECIDX 5) $ ) $ TABLE xxCODE XLANAME FROMD TOD XLASEL ---------------------------------------------------------------------------xxxXLA 012345 012345 RTE (DEST 1) (DESTNAME DATA_POECRTE) $ TABLE xxRTE XLANAME RTEREF ---------------------------------------------------------------------------xxxXLA 1 S ROUTE1
Table POECNM VALUE SYMBOL --------------------------------------------3 POE_DATA
Table DESTNAME VALUE SYMBOL --------------------------------------------3 DATA_POECRTE
Table POECRTE POECGRP POECIDX DESTNAME NEWROUTE -------------------------------------------------------------------------------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. 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 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 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. POECNM.
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 0 0 0 N N N N N N N N N NATL $ TABLE TRKOPTS ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN TABLE CALLCNTL INITIAL_SCREEN (SCRN ( BC ) $)$ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >speech . . TABLE BCSCRN . . INITIAL_SCREEN SPEECH SET_VOICE_CUSTGRP $ . TABLE CALLCNTL . SET_VOICE_CUSTGRP (CUSTGRP DEFAULT) $ TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS DEFAULT 0 0 0 DFLT $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL DEFAULT NXLA DFLTXLA NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME DFLTXLA TUPLE NOT FOUND Default from table XLANAME: DFLTXLA (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9 TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $
35
TRAVER of SPEECH call using POE Screening/Routing - continued

TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS N ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE FACODE 01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE)$ TABLE: FARTE KEY: 01628FA . S DANNAT 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. +++ TRAVER: SUCCESSFUL CALL TRACE +++ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >speech DIGIT TRANSLATION ROUTES 1 DANNAT 01234567890 ST 1 01234567890 01234567890
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 0 0 0 N N N N N N N N N NATL $ TABLE TRKOPTS ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN TABLE CALLCNTL INITIAL_SCREEN (SCRN ( BC ) $)$ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO CXDEMO 01 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $
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 CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED 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 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 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 . GENTRIG ( CDPN ETSITRIG)$ NIL Trigger INAPV8 GENTRIG is applicable to office. INAP Info Analyzed TDP: trigger criteria not met. +++ TRAVER: SUCCESSFUL CALL TRACE +++ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >64kdata DIGIT TRANSLATION ROUTES 1 SPAINPVG 01234567890 ST 01234567890 01234567890
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 calls
? CS2000 ? ?

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, lowmaintenance 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 Universal Translations 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 Mapping Mapping Function Destination Mapping
Standby
Standby
Output: List of Route Lists
Route List 1 Route List 2 Route List 3
Active
SWACTing Function Input 1: Path Of Entry Existing CS2000 Screening Functions
Active
SWACTing Function Input 2: Destination Universal Translations (Digit Analysis)
Incoming Call
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 POE_BC 2 RTEPLIDX 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 100 NATL_CALL LCR_ROUTE_LIST ( 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 option exists? Table TRKOPTS Y LCR option exists? POECNAME exists? Update POECNAME Y Y Table LCRORIG Continue as regular call N N N
Table CALLCNTL index? N Centrex Translations
LCRORIG index exists? Y
Table LCRDEST
LCRDEST index exists? Y

48
N Route call using RTELIST
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 ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN TABLE CALLCNTL INITIAL_SCREEN (SCRN ( BC ) $)$ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO CXDEMO 01 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE POECRTE TUPLE NOT FOUND
49
TRAVER of an LCR Data call Standby tables continued

TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS N ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 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 . GENTRIG ( CDPN ETSITRIG)$ NIL Trigger INAPV8 GENTRIG is applicable to office. INAP Info Analyzed TDP: trigger criteria not met. +++ TRAVER: SUCCESSFUL CALL TRACE +++ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >64kdata DIGIT TRANSLATION ROUTES 1 GERMANYPRI 2 FRANCEPRI 3 HOLLANDPRI 4 ITALYPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH N CDN E164 NA 01234567890 NIL_NSF BC SPEECH N CDN E164 NA 01234567890 NIL_NSF BC SPEECH N CDN E164 NA 01234567890 NIL_NSF BC SPEECH
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 ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN TABLE CALLCNTL INITIAL_SCREEN (SCRN ( BC ) $)$ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >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 AIN_OFFICE_TRIGGRP ETSIGRP INAP Origination Attempt TDP: no subscribed trigger. TABLE NCOS CS2KCUST 0 0 0 NO_RST $ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL CS2KCUST NXLA CXDEMO NXLA 0 NDGT TABLE DIGCOL NDGT specified: digits collected individually INAP Info Collected TDP: no subscribed trigger. TABLE IBNXLA: XLANAME CXDEMO CXDEMO 01 NET N N 0 N NDGT N N DOD N 1 CS_NPRT CS_NIL NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE XLAPLAN CS_NPRT NSCR 101 NPRT NONE N $ $ TABLE RATEAREA CS_NIL NLCA NIL NILLATA $ TABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 14) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE PXCODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED TABLE POECRTE TUPLE NOT FOUND
51
TRAVER of an LCR Data call Active tables continued

TABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS N ATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 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 . GENTRIG ( CDPN ETSITRIG)$ NIL Trigger INAPV8 GENTRIG is applicable to office. INAP Info Analyzed TDP: trigger criteria not met. +++ TRAVER: SUCCESSFUL CALL TRACE +++ PLEASE ENTER VALUE FOR BEARER CAPABILITY: >64kdata DIGIT TRANSLATION ROUTES 1 SPAINPVG 01234567890 ST 01234567890
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 SELECT LCRSYNC Select
Insert INSERT
INSERT SELECT LCRSYNC Select
Synchronise LCRSYNC
Insert INSERT
Synchronise LCRSYNC
SELECT
SELECT UPDATE DELETE ADDRTE CHGRTE DELRTE
UPDATE DELETE
User can update or delete values in a selected field
Rudimentary Hierarchy for Table Management

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 LCRSYNC UPDATE DELETE ADDRTE (LCRDEST2 table only) CHGRTE (LCRDEST2 table only) DELRTE (LCRDEST2 table only)
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. **** WARNING * WARNING * WARNING * WARNING **** POECGRP POECIDX RTEPLIDX -----------------------POEGRP1 12 100 POEGRP1 15 100 POEGRP5 9 100 LCRORIG2: SELECT: >
57
LCRDEST2: > SELECT RTELISTS EQ OFRT 1 Tuples Successfully Selected = 5 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** 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 Tuples Successfully Selected = 4 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRORIG2. **** WARNING * WARNING * WARNING * WARNING **** 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 Tuples Successfully Selected = 1 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** RTEPLIDX DESTNAME RTELISTS -------------------------120 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1) LCRDEST2: SELECT: > UPDATE RTELISTS EQ OFRT 12 Tuples Successfully Updated = 1 RTEPLIDX DESTNAME RTELISTS -------------------------120 UK (OFRT 12) LCRDEST2:>
LCRDEST2: > SELECT DESTNAME EQ UK Tuples Successfully Selected = 2 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** RTEPLIDX DESTNAME RTELISTS -------------------------120 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1) 130 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1) LCRDEST2: SELECT: > UPDATE RTEPLIDX EQ 150 RTEPLIDX DESTNAME RTELISTS -------------------------150 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1) **** WARNING * WARNING * WARNING * WARNING **** Selected tuples deleted due to update ========> 1 **** WARNING * WARNING * WARNING * WARNING **** Tuples Successfully Updated = 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 Tuples Successfully Selected = 3 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRORIG2. **** WARNING * WARNING * WARNING * WARNING **** 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) Tuples Successfully Selected = 1 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** RTEPLIDX DESTNAME RTELISTS -----------------------------------------------120 UK (OFRT 1)(OFRT 10) SELECT: > ADDRTE OVR8 3 1 Tuples Successfully Updated = 1 RTEPLIDX DESTNAME RTELISTS -------------------------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: > SELECT (RTEPLIDX EQ 120) AND (DESTNAME EQ UK) Tuples Successfully Selected = 1 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** RTEPLIDX DESTNAME RTELISTS -----------------------------------------------120 UK (OFRT 1)(OFRT 10) LCRDEST2: > CHGRTE OFRT 10 OVR3 3 Tuples Successfully Updated = 1 RTEPLIDX DESTNAME RTELISTS -------------------------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: > SELECT (RTEPLIDX EQ 120) AND (DESTNAME EQ UK) Tuples Successfully Selected = 1 **** WARNING * WARNING * WARNING * WARNING **** This operation could potentially overwrite existing tuples in LCRDEST2. **** WARNING * WARNING * WARNING * WARNING **** RTEPLIDX DESTNAME RTELISTS ----------------------------------------------120 UK (OVR8 3)(OFRT 1)(OFR2 2)(OFRT 10)(OFR4 1) SELECT: > DELRTE OFRT 1 Tuples Successfully Updated = 1 RTEPLIDX DESTNAME RTELISTS ----------------------------------------------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
V10.0
Appendix A PRI Trunk Groups

Purpose The purpose of this section is to introduce the student to the concepts of; > PRI Trunk Groups and their datafill. After this module of instruction, you will be able to List the tables used to establish PRI voice calls. Describe the purpose of each of the tables Optional PRI trunk group datafill exercise
Centrex
LINEATTR
CLLI TRKGRP TRKSGRP TRKMEM LTCALLS LTMAP LTDEF
Trunks
Trunk Network the big picture

R.O.W Switch A Switch C PBX B
PBX A
Switch B
Switch E
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. 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.

Voice Services
CS2000
or
CS2000
CS2000c
GWC CS LAN
CBM MCS

MS20x0 Conferencing
SS7
ERS 8600
BCP IP Network

CMTS
PSTN

Video Feed
m6350 Softclient
7
i2004 Etherset
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.
Outgoing PRI Translations
Line Originated Call
Centrex Translations Routing Tables (IBNRTE & OFRT)
PRI Outgoing Trunk CLLI Private Call
Public Call
Routing Tables (IBNRTE & OFRT)
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. 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. 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).
2.
3.
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 IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT)$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 DCDEMO TABLE DIGCOL DCDEMO 6 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 6601 ROUTE N N N 4 N 8 8 NDGT Y S PRITG1 $ TABLE DIGCOL NDGT specified: digits collected individually Originator is not an EIN agent, therefore EIN info is not processed. +++ TRAVER: SUCCESSFUL CALL TRACE +++
DIGIT TRANSLATION ROUTES 1 PRITG1 N CDN PVT L 5028 NIL_NSF BC SPEECH
TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
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 IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT)$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 DCDEMO TABLE DIGCOL DCDEMO 6 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 6602 NET N N N 0 N NDGT N Y DOD N 602 NONE $ TABLE DIGCOL NDGT specified: digits collected individually TABLE LINEATTR 602 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRINET NIL $ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE PXHEAD PRINET SDFLT NODFOP CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE PRINET 6602 6602 RTE ( MM 8 8) ( DEST 602)$ Originator is not an EIN agent, therefore EIN info is not processed. TABLE: PXRTE KEY: PRINET 602 . T OFRT 602 . . TABLE OFRT . . 602 S D PRITG1 . . EXIT TABLE OFRT EXIT TABLE PXRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 PRITG1 N CDN E164 L 66025028 NIL_NSF BC SPEECH 66025028
TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++
10
Incoming PRI Translations

PRIVATE CALL PUBLIC CALL
Table TRKGRP
Table LTCALLS
CENTREX TRANSLATIONS (Table IBNXLA etc)
Table OFRT/IBNRTE
UNIVERSAL TRANSLATIONS (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

>
PRIVATE CALL
>
SETUP message contains CDN info element which indicates that the type of number being dialled is a Private call. TABLE LTCALLS: I/C PRIVATE CALLS: XLAIBN :- Customer group & NCOS link PVT calls into Centrex translations. RTEREF :- Links PVT calls direct to Table OFRT or IBNRTE
Table TRKGRP
Table LTCALLS
XLAIBN
RTEREF
Table OFRT/IBNRTE CENTREX TRANSLATIONS (Table IBNXLA etc) 12 NORTEL CONFIDENTIAL

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 QNSX 230 > PVT XLARTSEL XLAIBN 204 QUEENSX00MEL 0 10 OPTIONS $
FOR TRAINING PURPOSES ONLY
-------------------------------------------------------------------------------------------------
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 AIN_OFFICE_TRIGGRP NIL TABLE NCOS IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT) ( DFT )$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 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 CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL INAP Info Analyzed TDP: no subscribed trigger. 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 +++ TRAVER: SUCCESSFUL CALL TRACE +++ DIGIT TRANSLATION ROUTES 1 LINE 1628795505 ST
13
Public Incoming Calls

PUBLIC CALL SETUP message contains CDN info element & indicates that the type of number being dialled is a Public (E.164) call.
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 Later) XLAIBN RTEREF XLALEC RTEREF :- Links E.164 calls direct to Table OFRT or IBNRTE XLALEC:-LINEATTR links E.164 calls into Universal Table OFRT/IBNRTE translations. No NCOS for COSMAPPING (See later) Universal Translations Universal Translations
Table TRKGRP
XLALEC
allows a LINEATTR to be specified linking public calls into Universal Translations. allows a LINEATTR to be specified linking public calls into Universal Translations. with XLAIBN the NCOS value datafilled in LTCALLS can be used for COSMAPPING later. 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. 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.
XLAIBN
Note 1:-
Note 2:-
RTEREF
>TABLE LTCALLS LTID XLARTSEL OPTIONS -------------------------------------------------------------------QNSX 230 PUB XLALEC 204 $ >
14
TRAVER for Incoming Public (E164) call

>TRAVER TR PRITG2 N CDN PUB 66025505 B TABLE TRKGRP PRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $ TABLE LTCALLS MMPRI 2 PUB XLALEC 782 $ TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL TABLE LINEATTR 782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE PXHEAD PRIUSER SDFLT NODFOP CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 678) ( CLASS NATL)$ INAP Info Analyzed TDP: no subscribed trigger. TABLE: PXRTE KEY: PRIUSER 678 . T IBNRTE 678 . . TABLE IBNRTE . . 678 DN 162 879 N 0 . . EXIT TABLE IBNRTE EXIT TABLE PXRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++ 66025505
DIGIT TRANSLATION ROUTES 1 LINE 1628795505 ST
15
Linking Public Calls Into Centrex Translations.

>TABLE LTCALLS LTID XLARTSEL OPTIONS -----------------------------------------------------------------------------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 PRITG1 PRA 0 PRAC NCRT MIDL N (MMPRI 1) $ $ TABLE LTCALLS MMPRI 1 PUB RTEREF IBNRTE 692 $ TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL INAP Info Analyzed TDP: no subscribed trigger. TABLE IBNRTE 692 RX IBNDEMO 0 0 25 $ . TABLE DIGMAN . 25 (REM 4) . EXIT TABLE DIGMAN EXIT TABLE IBNRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++
TREATMENT ROUTES. TREATMENT IS: GNCT 1 ENGAGED +++ TRAVER: SUCCESSFUL CALL TRACE +++ >
Note: Traver does not show the retranslation, but the result is correct.
17
Table LTCALLS summary

PVT PUB
XLAIBN
RTEREF
XLAIBN
XLALEC
RTEREF
OFRT/IBNRTE
LINEATTR
OFRT/IBNRTE
LINEATTR
LINEATTR
CUST GRP
INDEX
CUST GRP
INDEX RX
Cust Grp + NCOS
NCOS Centrex XLA

18
NCOS Bypass Centrex Universal XLA XLA Universal XLA
(No COSMAPPING)
Bypass Centrex Universal XLA XLA
18
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. 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 ukpri $ $ GRPTYP TRAFSNO PADGRP NCCLS pra 0 npdgp ncrt SELSEQ BILLDN n aseq
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. Group type. Enter the trunk group type. For PRI trunks this is PRA. As per C7UP TRKGRP example As per C7UP TRKGRP example As per C7UP TRKGRP example As per C7UP TRKGRP example As per C7UP TRKGRP example 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 $. Options. Enter any options required.
GRPTYP TRAFSNO PADGRP NCCLS SELSEQ BILLDN LTID
OPTION
21
Table TRKSGRP Example (PRI)

TABLE TRKSGRP SGRPKEY CARDCODE SGRPVAR PSPDSEIZ PARTDIAL VERSION ukpri 0 2 Internal 1 OPTION $ ds1sig n n 8 isdn stand n 315 4 network 70 64k 4 pt_pt n hdlc 87q931 user default $ n gwc CRLENGTH BCHNEG BCHGLARE IFCLASS CONFIG LOCATION SAT ECSTAT NSMATCH AUTOON TRKGRDTIM L1FLAGS PARMNAME PMTYPE GWCNO GWCNODENO GWCTRMNO DCHRATE HDLCTYPE PMTYPE
22
The above is an example of PRI or Integrated Services Digital Network (ISDN). For the above example the fields are: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. SGRPKEY
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 ECSTAT NSMATCH Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a satellite. If not, enter N, (no). Echo canceler status. Enter UNEQ to indicate that Echo canceler is not equipped on this subgroup. 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 10ms 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 Dchannel is in flagfill mode. Enter Y if the connection is between CS2000 and a different vendor. Enter N for CS2000-to-CS2000 PRA connections. 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 GWCNO GWCNODENO GWCTRMNO DCHRATE Peripheral module type. Gateway Controller Number Gateway Controller Node Number. Gateway Controller Terminal Number 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. HDLC for high level data link or INVHDLC for inverted high level data link.
PARMNAME ISDNPARM name Enter a name in table ISDNPARM.
HDLCTYPE High level data link type. Enter HDLC or INVHDLC.
23
Table LTDEF Example
TABLE: LTDEF LTKEY PRI 1 LTAP CLASSREF 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 CLASSREF . B PRA For circuit switching or for ISDN MFT terminals, enter B. 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. Class reference field consists of; LTCLASS
24
Table LTCALLS Example
TABLE LTCALLS LTID pri 7 pub XLARTE xlalec LINEATTR XLAPLAN 1 cs_nprt RATEAREA cs_nil LTCOPT $
25
For the above example the fields are; 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 PRI PRI PRI PRI PRI PRI 1 CLLI 2 CLLI 3 CLLI 4 CLLI 5 CLLI 6 CLLI MAPPING FRANCEPRI GERMANYPRI HOLLANDPRI ITALYPRI SPAINPRI UKPRI ( ( ( ( ( ( OPTION TEI 0) $ TEI 0) $ TEI 0) $ TEI 0) $ TEI 0) $ TEI 0) $
26
For the above example the fields are; LTKEY This field consists of subfields LTGRP and LTNUM. LTGRP LTNUM MAPPING MAPTYPE Logical terminal group datafilled in table LTGRP. Logical terminal number (1 to 1022 ) 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. 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.
This field consists of subfield MAPTYPE.
OPTION
TEI
26
27
PRI Bearer Capability Routing

PVG Gateway
CS2000
PVG PRI Gateway
64k Data
Incoming PRI Call
CS LAN
Voice
PSTN
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 SPEECH 64KDATA 64KX25 56KDATA DATAUNIT 64KRES 3_1KHZ 7_KHZ VOICE_DATA 64K_RATE_AD_DATA > BCDATA SPEECH CIRCUIT CCITT UNRESDIG CIRCUIT CCITT RESDIG CIRCUIT NETWORK DTU X25 Y AUTO UNRESDIG CIRCUIT NETWORK DTU NONE Y 56KBS UNRESDIG CIRCUIT NETWORK DTU TLINK Y 56KBS RESDIG CIRCUIT CCITT AU3_1KHZ CIRCUIT CCITT AU7KHZ CIRCUIT CCITT AU3_1KHZ CIRCUIT CCITT 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 64K 31K GROUPRC (BC 64KDATA $) $ (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 XLTR Name XLAMAP New XLTR Name IBNXLA Data Call To LINEATTR FOR PUBLIC CALLs
NCOS or CUSTHEAD XLTR Name IBNXLA Speech Call
OFRT /IBNRTE
OFRTMAP /IBNMAP Nil Entry
OFRT /IBNRTE
ROUTE A
ROUTE B
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 64K CXDEMO 64K PXDEMO1 64K PXDEMO2 ( ( ( DATA XLA CXDEMO1)$ XLA CXDEMO)$ 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 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 AIN_OFFICE_TRIGGRP NIL TABLE NCOS IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT) ( DFT )$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 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 CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL INAP Info Analyzed TDP: no subscribed trigger. 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 +++ TRAVER: SUCCESSFUL CALL TRACE +++
31
Private BC 64KDATA Call Traver

>TRAVER TR PRITG2 N CDN PVT 5028 BC 64KDATA B Warning: Routing characteristics are present. Originator must be able to send in characteristics specified. TABLE RTECHAR . 64K ( BC 64KDATA $)$ 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 AIN_OFFICE_TRIGGRP NIL TABLE NCOS IBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT) ( DFT )$ TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOL IBNDEMO NXLA CXDEMO FXDEMO 0 DCDEMO TABLE DIGCOL DCDEMO 5 COL S 3 TABLE XLAMAP . 64K PXDEMO0 ( XLA PXDEMO1)$ TABLE IBNXLA: XLANAME PXDEMO1 PXDEMO1 5 ROUTE N N N 0 N 4 4 NDGT N S NTDEMO2WNAT $ TABLE DIGCOL NDGT specified: digits collected individually TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL INAP Info Analyzed TDP: no subscribed trigger. +++ TRAVER: SUCCESSFUL CALL TRACE +++
DIGIT TRANSLATION ROUTES 1 NTDEMO2WNAT 5028 ST
TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT
32
Public Call (Centrex Translations)

FROM CENTREX XLAS or Table LTCALLS
LINEATTR PXHEAD PXCODE PXRTE Route Index OFRT /IBNRTE Speech Call ROUTE A
33
RCNAME eg 64k from Table RTECHAR Route Index
OFRTMAP /IBNMAP New Route Index OFRT /IBNRTE Data Call ROUTE B
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:Mapping Table Routing 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 Warning: Routing characteristics are present. Originator must be able to send in characteristics specified. TABLE TRKGRP PRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $ TABLE LTCALLS MMPRI 2 PUB XLALEC 782 $ TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL TABLE LINEATTR 782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE PXHEAD PRIUSER SDFLT NODFOP CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) ( CONSUME 4)$ INAP Info Analyzed TDP: no subscribed trigger. TABLE: PXRTE KEY: PRIUSER 682 . T IBNRTE 682 . . TABLE IBNRTE . . 682 DN 162 879 N 0 . . EXIT TABLE IBNRTE EXIT TABLE PXRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++ 66025014
34
Public BC 64KDATA Call Traver >TRAVER TR PRITG2 N CDN PUB 66025014 BC 64KDATA B Warning: Routing characteristics are present. Originator must be able to send in characteristics specified. TABLE RTECHAR . 64K ( BC 64KDATA $)$ TABLE TRKGRP PRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $ TABLE LTCALLS MMPRI 2 PUB XLALEC 782 $ TABLE CUSTSTN TUPLE NOT FOUND TABLE OFCVAR AIN_OFFICE_TRIGGRP NIL TABLE LINEATTR 782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$ LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPE TABLE PXHEAD PRIUSER SDFLT NODFOP CON STD THE DIGITS USED TO INDEX THE NEXT TABLE ARE: TABLE PXCODE PRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) $ INAP Info Analyzed TDP: no subscribed trigger. 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 IBNRTE EXIT TABLE PXRTE +++ TRAVER: SUCCESSFUL CALL TRACE +++ 66025014
DIGIT TRANSLATION ROUTES 1 NTDEMO2WNAT 66025014 ST
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. Obtain the following information from your instructor:Destination Customer Group A name__________________________ Destination Customer Group B name__________________________ TRKSGRP circuit info Destination A - GWCNO _____ GWCNODENO_____ GWCTRMNO____________ Destination B - GWCNO _____ GWCNODENO_____ GWCTRMNO____________ TRKMEM info Destination A - GWCNO _____ GWCNODENO_____ GWCTRMNO____________ Destination B - GWCNO _____ GWCNODENO_____ GWCTRMNO____________ 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 No__1__ GWC Node__8__ GWC TermNo_631__
GWC No__1__ GWC Node_8___ GWC TermNo__641__
Team 3
GWC No__1__ GWC Node__8__ GWC TermNo__630__
Team 4
Team 2
Team 5
Team 1
Team 6
38
39
Appendix B
CCS7 Information
nortel.com/training
V10.0
Appendix B
Purpose This section contains information in relation to CCS7 Signalling and is for information only.
CCS7 Tables
C7 Tables
C7NETWRK
C7TIMER
User Part Tables

CLLI TRKGRP
C7RTESET
C7LKSET
C7LINK
C7NETSSN TRKSGRP C7LOCSSN TRKMEM ISUPDEST C7TRKMEM
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.
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).
Trunk Provisioning Flowcharts (TDM-Side)
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 Bchannels in the group: Signalling type Protocol version Configuration ISDN 87Q931 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)
The following is an example of CCS7 datafill. TABLE: C7NETWRK NETNAME NODETYPE PTCODE NI SLSROT TFR MCS CLUSTERS RCTEST MTPRES CNGCONT SLSENH --------------------------------------------------------------------------------------------------------C7NETWRK1 SSP 1 CS2KNAT 1 TABLE: C7RTESET ROUTESET NETNAME TFPBCAST ROUTES ---------------------------------------------------------------------------SNODE_RS SNSEB_RS SPC_RS CS2KNAT CS2KNAT N N N CCITT7 CCITT7 CCITT7 BASIC 123 BASIC 345 BASIC 1212 (SNODE_LS 0)$ (SNSEB_LS 0)$ C7NETWRK1 ( SPC_LS 0)$ DPC SSP N N CCITT7 N N CCITT7 BASIC 6969 NATL Y Y N N N N N Y N N
BASIC 789 NATLSPARE
TABLE: C7LKSET LINKSET LSTYPE NETNAME SIGLKTST RSTEST FEPC INHTEST NIRPLMT FECLLI AUTOINH CONGENH ---------------------------------------------------------------------------SNODE_LS 0 Y 1 N FLINK 1 Y CS2KNAT N N N N CCITT7 N NATL CCITT7 N N N NIL N BASIC 1212 BASIC 345 SNSEB 0 Y SPC_LS 0 Y 1 N FLINK 1 N 1 C7NETWRK1 N N LINK_TO_SPC FLINK 1 N CS2KNAT N N N N NIL CCITT7 N BASIC 123 SNODE
Q704 CNGSTN NUMFLAGS MTPRES CHNGSLS SCCPONLY
SNSEB_LS
TABLE: C7LINK LINKNAME SNODE_LS 0 SNODE_LS 1 SNSEB_LS 0 SNSEB_LS 1 SPC_LS 0 LINKDATA CLASDATA Q707 LIUBASIC LIUBASIC LIUBASIC LIUBASIC LIUBASIC LIU7 13 MTP2 0 0 LIU7 23 MTP2 0 0 LIU7 25 MTP2 0 0 LIU7 36 MTP2 0 0 LIU7 1 MTP2 0 0 LINKOPT $ $ $ $ $ -----------------------------------------------------------------------------------------
TABLE: ISUPDEST DESTKEY GERMANYPVG 0 FRANCEPVG 0 SPAINPVG 0 HOLLANDPVG 0 ITALYPVG 0 UKPVG 0 ISUPROUT SNSEB_RS SNSEB_RS SNSEB_RS SNSEB_RS SNSEB_RS SNSEB_RS -----------------------------------------------------
TABLE: C7NETSSN PCNAME SPC_RS XUDTIND CGT1 CGT2 Y 0 0 SSNAMES ( ETSIIN 106)$ ----------------------------------------------------------------------------
10
11
11
Appendix C
Announcements
nortel.com/training
V10.0
Appendix C
Purpose This section contains example datafill on Announcements in a CS2k environment and is for information only.
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.
CS2k Announcements example datafill

Table CLLI CLLI ADNUM TRKGRSIZ ADMININF ----------------------------------------------------------------------WRONG_NUM 1000 10 WRONG_NUM_ANNC Table SERVRINV SRVRNAME SRVRADDR SRVREXEC SRVRTONE BEARNETS SRVROPTS --------------------------------------------------------------------------------------------------------------GWC 3 IP 47 163 43 40 (ABTRK GWCEX) $ UK100 (NET_IP Y) $ $
Table ANNAUDID PHRASEKY AUDID ---------------------------WRONG_NUM 3000
Segment ID on MS2010
Table SERVSINV SRVSNAME SRVRNAME NUMTERMS OPTIONS -------------------------------------------------------------------------------------------------------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 ) $
The above datafill is an example. The actual announcement would have to be recorded and uploaded to the MS2010 Audio Server. See course 2788.
Appendix D
Student Information
nortel.com/training
V10.0
Appendix D
Purpose This section contains additional information which the student may find useful.
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
10
11
12
12

CS2000 Universal Translations.3006A 5.0 SG

Încărcat de

Informații document

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 Translations.3006A 5.0 SG

Încărcat de

Drepturi de autor:

Formate disponibile

CS2000 Universal Translations

297-9051-350 297-9051-300 297-1001- 824 NE-10004-512

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Introduction to CS2000 Universal Translation course

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

CS2000 Universal Translations Course Introduction

Centrex Customer Group Tables

Universal Translations Tables

Trunk Group Tables

Call Control Tables

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

XLANAME CUSTENG CUSTHEAD

CS2000 Universal Translations Table Association Chart

IBNXLA NCOS IBNTREAT PXCODE

CLLI TRKGRP TRKSGRP TRKMEM PATH OF ENTRY LEAST COST ROUTING

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

CS2000 Network Overview

Core Billing Manager

Multimedia Server Announcements

Lawful Intercept CICM Centrex IP Phone Server

NAT and NATP Translation Cable Modem

Hosted PBX Centrex IP Derived Lines

HFC HFC PBX Cable Modem

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Module 1 Introduction to CS2000 Data Tables

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Table Editor Utility

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Navigating a Table (contd)

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Module 2 Centrex Translations Overview

CS2000 Universal Translations Course Navigation Map

Centrex Customer Group Tables

Universal Translations Tables

Trunk Group Tables

Call Control Tables

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

XLANAME CUSTENG CUSTHEAD

CS2000 Universal Translations Table Association Chart

IBNXLA NCOS IBNTREAT

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Program Store (PS) Programs software release e.g. ISN06 or ISN07

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

CS2000 Digital Centrex and CS2000 relationship

Introduction to Centrex Translations

Introduction to Centrex Translations

Centrex Translations Business Customer B

Universal Translations Business Customer C GRP_C Trunks PBX

NORTEL CONFIDENTIAL FOR TRAINING PURPOSES ONLY

Customer Group Dial Plans

Oil Customer Group

Features Extension calls Network Calls (PSTN) Attendant

CICM DNs