CS2000 Universal Translations.3006A 5.0 SG

CS2000 Universal Translations

Student GuideGuide release: 5.0Guide status: ReleasedDate: May 2006

Copyright © 2005 Nortel Networks. All rights reserved.

NORTEL NETWORKS CONFIDENTIAL: The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall not copy or otherwise reproduce, or modify, in whole or in part, this document or the information contained herein. The holder of this document shall keep the information contained herein confidential and protect same from disclosure and dissemination to third parties and use same solely for the training of authorized individuals.

THE INFORMATION PROVIDED HEREIN IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND. NORTEL NETWORKS DISCLAIMS ALL WARRANTIES, EITHER EXPRESSED OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL NORTEL NETWORKS BE LIABLE FOR ANY DAMAGES WHATSOEVER, INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, ARISING OUT OF YOUR USE OR RELIANCE ON THIS MATERIAL, EVEN IF NORTEL NETWORKS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Information subject to change without notice.Nortel Networks, and the Nortel Networks logo are trademarks of Nortel Networks.

Publication History

July 2005 Version 1.0 Initial IssueJuly 2005 Version 2.0 Updated, formatting

errorsAugust 2005 Version 3.0 Updated following

pilot delivery.August 2005 Version 4.0 Additional module and

appendix added.May 2006 Version 5.0 Update to ISN09

Contents revised.Additional material added.

DescriptionThe purpose of this course is to familiarise the student with the datafill requirements of CS2000 Universal Translations.

Intended audiencePersonnel responsible for the initial datafill and database management of CS2000 Universal Translations.

PrerequisitesThis course has the following prerequisites:• Familiarity with use of DMS / CS2000 Table Editor is recommended. • CS2000 Overview

ObjectivesAfter 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 CLI’s in Universal Translations and the use of White v Black lists.• Datafill Tables to screen CLI’s in Universal Translations.• Datafill Tables to screen calls using Call Control and Universal Screening• Use Traver to verify correct call routing through translations.

Course introduction

Overview

ReferencesThe following documents provide additional information:

Commands Reference Manual297-1001- 824

OSSGate Users GuideNE-10004-512

DMS-100 MMP Customer Data Schema297-9051-300

DMS-100 MMP Translations Guide297-9051-350

Document titleNTP 000-0000-000

Contents0. Course Introduction1. Introduction to Tables2. Centrex Translations Overview3. Lines Provisioning4. TRAVER5. Trunk Groups6. Route Tables7. Universal Translations Overview8. Universal Translations Datafill – International Calls9. Universal Translations Datafill – Local Calls10. Universal Translations Datafill – National Calls11. Time Of Day Routing12. Universal Translations Datafill – Service Calls13. Universal Translations – Indirect Access14. Call Control and Universal Screening15. Appendix A PRI Trunks16. Appendix B CCS7 Tables17. Appendix C Announcements18. Appendix D Student Information

0

V10.0 NORTEL CONFIDENTIAL – FOR TRAINING PURPOSES ONLY

nortel.com/training

Introduction

1

2

2 NORTEL CONFIDENTIAL – FOR TRAINING PURPOSES ONLY

Introduction to CS2000 Universal Translation coursePurposeThe 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

3

4


CS2000 Universal TranslationsCourse Introduction

Centrex Customer

GroupTables

TrunkGroupTables

RoutingTables

UniversalTranslations

Tables

Call ControlTables

Course IntroductionFor 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.

5

6


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

PXRTE

PXCODE

PXHEAD

LINEATTR

CLLI

TRKGRP

TRKSGRP

TRKMEM

TRKOPTS

CALLCNTL

UNIVERSALSCREENING

PATH OFENTRY

LEASTCOST

ROUTING

OVRx

OFRT

IBNRTE

IBNTREAT CTRTE

CTCODE

CTHEAD

OFCRTE

OFCCODE

OFCHEAD

FARTE

FACODE

FAHEAD

Centrex

Universals

Trunks

Routing

Call Control

CS2000 Universal TranslationsTable Association Chart

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.

7

8


VoiceServices

ElementManagement

IEMS

BackOffice MS20x0

• Announcements• Conferencing• Lawful Intercept

MG15K

Derived Lines

IADCPE

DSLAM

xDSLIAD

Hosted PBX

PBX CableModem

HFCHFC

VideoFeed

CMTS

Cable Modem

CS2000 Network Overview

Centrex IP

i2004 Etherset

m6350Softclient

PSTN

NetworkSignalling

SS7USP

IPNetwork

CS LAN

GWC

ERS 8600

CS2000cCS2000CS2000

or

CICM

BCP

MCS

Centrex IP Phone Server

NAT and NATP Translation

Multimedia Server

TDM Interface

CBM

Core Billing Manager

9


0


nortel.com/training

Module 1

Introduction to CS2000

Data Tables

1

2


Module 1 Introduction to CS2000 Data TablesPurposeThe 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

3

4


Introduction to Tables

HardwareResources

IBNTranslations

UniversalTranslationsTrunks

Lines

Call Processing

The Program Store’s 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.

5


> 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

Types of Tables

IntroductionIn 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.

6

Table StructureThe 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.

FieldsThe 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.

TuplesThe 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.

7


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

1st Field is usually Key Field(Must be Unique)

Table Structure

TUpLE 2

Data Entry

8


Table Editor Utility

The table editer help facility provides a list of table editing commands. Individual commands can be queried by using the q

<command> syntax.

The table editer utility is loaded into the Symbol

Table

The user enters a table

Table Editor FunctionsThe 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.

9


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 it’s current

positionNote: the field headers

are not displayed

The list command retains the current position

within the table but adds the fields headers

Navigating a TableIt 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.

10

Table Navigation CommandsThe following is a description of Table Navigation Commands, the characters in brackets define the accepted abbreviation. Where ever <n> is mentioned this represents a user selectable number.count displays the number of tuples within the current table.list (lis) Displays the currently positioned tuple.list all (lis all) Displays all tuples within the current table.list <n> (lis <n>) Display the defined number of tuples directly below my

current position.top Position cursor at the first tuple in the table and display the

tuple data.bottom (bot) Position cursor at the last tuple in the table and display the

tuple data.first Position the cursor to the first tuple in the table.last Position the cursor to the last tuple in the table.next Position the cursor to the tuple following the current tuple.prev position the cursor at the tuple previous to the current tuple. up <n> move the cursor up the specified number of tuples, display

tuple data.down <n> (dow <n>) move the cursor down the specified number of tuples, display

tuple data.Position <key field> position the cursor at the specified key field. (see note)pos <key field>

Note: When using the position command the CS2000 will search the key fields within the table for a match with the one requested by the user. In some tables more than one tuplewill 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.

11


Navigating a Table (cont’d)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

12


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.

Obtaining HelpOnce 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.

13


Adding a Tuple

The add command tells the CS2000 that a new tuple is to be added.


The CS2000 now presents each field in sequence for

the user to add the required parameters.

At any stage the ‘abort’ command will stop the process and return the

user to the table

After the input for the last field is complete the CS2000 presents the

complete tuple and seeks confirmation.

The tuple is now added to the table and a Journal

File is written

Adding a TupleTo 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.

14


Changing a Tuple


The user positions on the tuple to be changed.

The change command informs the DMS that the

tuple that we are currently positioned on

needs changing.

The DMS presents each field in turn with its current value. If no

change is required the return key moves onto

the next field. If a change to a field is needed the value followed by the

return key changes the value of the field.

After the input for the last field is complete the DMS

presents the amended tuple and seeks

confirmation.

Changing a TupleTo 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.

15


Deleting a Tuple

The CS2000 now seeks confirmation that this tuple is to be deleted. Once deleted the tuple cannot be recovered. There is no Recycling

Bin!

The delete command informs the CS2000 to

delete the tuple that the user is currently positioned on.

The list command retains the current position within the table and

displays the tuple with the field names.

The user positions on the tuple to be deleted.


Deleting a TupleTo 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.

16

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.

17

18

Table Commands Exercise1. 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 30What 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 numberADNUM – 500x (where x is your team number)TRKGRPSIZ – 100ADMININF – text stating demo datafill.

8. Change the TRKGRPSIZ to 110 for the tuple you have just entered.9. Delete your tuple.

19

0


nortel.com/training

Module 2

Centrex Translations Overview

1

2


Module 2 Centrex Translations OverviewPurposeThe purpose of this section is to introduce the student to; > CS2000 Digital Centrex base translations.


Name the base tables required to support basic Customer Group Translations.Describe the purpose of each of the tablesDescribe incoming Trunk default datafill actionDatafill an example Customer Group to support Network dialling.

3

4


CS2000 Universal TranslationsCourse Navigation Map

Centrex Customer

GroupTables

TrunkGroupTables

RoutingTables


Tables

Call ControlTables

Course NavigationThe above slide illustrates the area we are currently working in.

5


6


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

LINEATTR

IBNTREAT

Centrex

Universals


7

8


CM(cpu)

DSPSCM

(cpu)

release

Program Store (PS)

Programs softwaree.g. ISN06 or ISN07

Data Store (DS)

Data tables (1100+) and otherdata that contain the switch’sInformation

DS Duplicated

Centrex Introduction

PS

CS2000 Digital Centrex and CS2000 relationshipThe 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 TranslationsThe Program Store’s 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.

9

10


Introduction to Centrex Translations

BusinessCustomer

A

BusinessCustomer

B

BusinessCustomer

C

ResidentialCustomers

CS2k switch

RES

_GR

P

GR

P_AG

RP_B

GR

P_C Trun

ks

CentrexTranslations


PSTN

Trun

ks

PBX

Table LINEATTR

Customer GroupsThe 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.

11


Customer Group Dial Plans

BankCustomer

Group

OilCustomer

Group

TextileCustomer

Group

Dialling Instructions

*/# = Features5 = Extension calls9 = Network Calls (PSTN)0 = Attendant



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.

12

Table IBNXLAOne 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 IBNXLABank (BANK) 5 EXTNOil (OIL) 4 EXTNTextile (TEXT) 3 EXTN

Separating Instructions (Tuples) Among CustomersAll 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 CUSTHEADCUSTNAME CUSTXLABANK BANKCTOIL OILCTTEXT TEXTCTRES RESCT

13

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 tuple’scustomer translator name. Below are examples of how our tuples in Table IBNXLA should be entered:

Table IBNXLABANKCT 5 EXTN (further data dependant on selector)OILCT 4 EXTN “ “TEXTCT 3 EXTN “ “

In summary, the switch asks the following questions before it determines which tuple a particular line or trunk group should use:- What customer group is the telephone assigned to?- What customer translator does that customer group "own"?-What leading digits were dialed by the caller?

Lets simulate the translations sequence in which one bank phone (245-6000) dials another bank extension (56405). As shown in Figure 1 the call processing software first looks in a table called IBNLINES. Table IBNLINES provides information about the originating phone, including the customer group to which the telephone belongs. In Figure 1 the switch sees that this originator has been assigned to customer group Bank. Having obtained this information it can now go to table CUSTHEAD. In table CUSTHEAD the switch finds what customer translator the customer group called Bank owns. The switch learns that the customer translator for Bank is BANKCT. The switch will now proceed to table IBNXLA to find the tuple which begins with BANKCT AND the leading digit dialled (’5’) that the caller dialled. In Figure 1 the switch now finds the tuple which gives it instructions to route this call to an extension.

Figure 12456000 DIALLING EXTENSION 56405Table IBNLINESHOST 00 0 00 29 DT STN 2456000 BANK 0 1 214 $Table CUSTHEADCustname CustxlaBANK BANKCTTable IBNXLABANKCT 5 EXTN . . . . . . .

14

Preliminary TranslatorsThere 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, let’s 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 IBNXLABANKCT 5 EXTNBANKCT 5 TRMT

15

Preliminary TranslatorsJust 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 NCOSCUSTNAME NCOS No PRELMXLABANK 0 $ (none)BANK 1 BANKPT1BANK 2 BANKPT2

As you can see in the above example, the BANK phones in NCOSs 1 and 2 apparently have some special instructions (tuples) in Table IBNXLA, since they both have been assigned preliminary translators. (NCOS 0 has only a $ in this table, meeting that it does not have a preliminary translator assigned and thus does not have special instructions written in Table IBNXLA.) Lets go back to our earlier example and restrict bank phones in NCOS 2 from using the first tuple in Table IBNXLA (which permits extension dialing). We do this by beginning our second tuple with its preliminary translator (BANKPT2), as shown below.

Table IBNXLABANKCT 5 EXTNBANKPT1 5 TRMT

16

THE GOLDEN RULEWhen 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 tuple’s customer translator name) or to a listed NCOS (that owns a tuples’s 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 TranslatorsThus 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 NCOS’s. Let’s, 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 IBNXLABANKPT1 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.

17


Centrex Overview 3.00

Customer Group

Table

Lineattr

Universal

Translations

Customer GroupTrunks

Other Switches

TableLINEATTR

Universal Translations

CS2000

Connection of Trunks to the CS2000

Incoming Trunk Access TranslationsIncoming trunks are associated with a Customer Group.Incoming calls over these trunks use a Centrex Customer Group to access Universal Translations.

18


PRI Trunk incoming Routing options

Centrex TranslationsCustomer Group and NCOS

Table IBNXLA etc.

Table OFRT/IBNRTEe.g. Direct to a Trunk Group

Universal Translationsvia Table LINEATTR

Table PXCode etc.

Table LTCALLS

Table TRKGRP

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.

19

The role of Table XLANAMETable 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 TranslationsIn 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.

20

CENTREX base tablesIntroductionCalls 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 .

21

Table SNPANAMETo enable a new range of SNPA’s (Serving Number Plan Area codes) the new number must

first be entered into Table SNPANAME. Table SNPANAME allows the operating company to define a maximum of 127 variable-

length serving numbering plan areas.There is only 1 Field, the Key field which is the SNPA.Sample tuple

TABLE: SNPANAMEKEY---1621731611311410311234567

Table TOFCNAMETo add an office code, Table TOFCNAME (Terminating Office Name) must be datafilled.Software optionality control (SOC) options NPE00001 and NPE00002 implement duplicateoffice code and table TOFCNAME expansion capabilities.When NPE00001 is active, you can datafill one office code against more than one area codein 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 useon the switch.Sample tuple

TABLE: TOFCNAMEAREACODE OFCCODE OPTIONS031 345 $186 567 $162 870 $162 871 $

22

Table XLAPLANThis 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 upgradeSample tuple

TABLE: XLAPLANXLAPIDX SCRNCL HSTS PRTNM ZEROMPOS RESINF OPTIONS ADMININF------------------------------------------------------------------------------------------------------------CS_NPRT NSCR 101 NPRT NONE N $ $

Table RATEAREAThis table contains rate area information previously held in Table LINEATTR.The table has been introduced to alleviate the possibility of Table LINEATTR running outof tuples. This table is datafilled as part of the One Night Process (ONP) during a switch upgrade

Sample tuple

TABLE: RATEAREARTAIDX LCANAME MRSA LATANM ADMININF-----------------------------------------------------------------------------------------------CS_NIL NLCA NIL NILLATA $

23

Table XLANAMEThe Translation Name Table (XLANAME) controls the addition and deletion of translators to the IBN Translation Table (IBNXLA). Therefore all translators used by Centrex customer groups must first be listed in this table before they can be used to translate access codes in the IBNXLA Table. If we do not datafill any entries in Table IBNXLA, the default is used.The translator is assigned a one- to eight- character name plus optional default data. If default data is defined, it is used for that translator name whenever an access code is not specified in Table IBNXLA.

Refer to NTP 297-9051-350 for detailed information about Table XLANAME.Datafill for NET selector is in Table IBNXLA; NTP 297-9051- 350, not in XLANAME.

Sample tuple

XLANAME DEFAULT MAXDIG--------------------------------------------------------------------------------------------------------------CXDEMO (NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $

9

The following is an explanation of the above tuple’s fields

XLANAME DEFAULT (Note 1)TRSEL ACR SMDR NO_ACCODE_DIGITS SECOND_DIAL_TONE

cxdemo net n n 0 nDGCOLNM CRL INTRAGRP NET_TYPE SMDRB LINEATTR

ndgt n y dod n 1XLAPLAN RATEAREA TOLL_RESTRICTION NETRTOPT cs_nprt cs_nil none $MAXDIG

9

Note 1DEFAULT is descriptor of field, actual datafill field name is TRSEL and subsequent data is dependant on entry made at this point.

24

Table CUSTENGThe 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 CUSTHEADThe Customer Group Head (CUSTHEAD) Table defines the group options or system features that are available to the customer group. Once these features are assigned, they are available to the group. The required customer group translator is assigned in this table, however it must be built in XLANAME before you refer to them here.Refer to NTP 297- 9051- 350 for detailed information about Table CUSTHEAD.

Sample tuple

CUSTNAME CUSTXLA DGCOLNM IDIGCOL OPTIONS----------------------------------------------------------------------------------------------------------IBNDEMO CXDEMO NDGT NIL (VACTRMT 0)(EXTNCOS 0) $

25

Table NCOSThe Network Class of Service (NCOS) Table can define the dialing plans or levels of dialing restrictions available to a customer group.The amount of usable NCOSs for your CUSTGRP was assigned in CUSTENG.Refer to NTP 297-9051-350 for detailed information about Table NCOS.

Sample tuple

CUSTGRP NCOS NCOSNAME LSC TRAFSNO OPTIONS- - - - - - - - - - - - - - - -- - - - -- - - - - - - - - - - - - - - - -- - - - - - -- - - - - --IBNDEMO 0 $ 0 0 $

Table IBNXLAThe 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 IBNTREATThe IBN Treatment (IBNTREAT) Table lists and defines intercepts such as tones and announcements to which calls are routed that do not have translation information assigned. This IBNTREAT number is assigned in Table CUSTHEAD as the VACTRMT option.Refer to NTP 297-9051-350 for detailed information about Table IBNTREAT.

Sample tuple

CUSTGRP IBNTRTMT (ITDATA) LOG RTESEL TRMTID-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - -IBNDEMO 0 N TRMT GNCT

Treatments can be assigned to: - Vacant codes in table IBNXLA. See option VACTRMT in table CUSTHEAD and translation selector FLEXI in tables IBNXLA and XLANAME.

26

Summary

SNPANAMEThis table allows the addition of SNPA’s to the switch.TOFCNAMEThis table allows Office codes to be added and associated with SNPA’s.XLANAMEThe translation name table contains the names of all the necessary CENTREX translators.CUSTENGThe customer engineering table lists the values for the engineering parameters and optionsfor the CENTREX customer group.CUSTHEADThe customer group head table contains the values and options which apply to all lineswithin the CENTREX customer group.NCOSThe network class of service table assigns NCOS on a line basis. The main CENTREXtranslators are assigned in this table.IBNXLAThe IBN translation table stores the data for the digit translation of calls from a trunk orstation.IBNTREATThe IBN treatment table is used to route calls in the CENTREX customer group that donot have a default translator.

27

28


Universal Translations Course Exercise Naming Convention

Throughout this training course, the following regional naming convention will be used.

This allows multi regions to utilise the switch simultaneously.

> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........

Naming ConventionsThis 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.

29

CUSTOMER GROUP EXERCISEAdd 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.......DODLINEATTR index 1RATEAREA & XLAPLAN as per datafill example

• CUSTENG Customer Group type is to be PUBLIC, NONCOS + NOIBNTMT = 5, consoles are not required.

• CUSTHEAD Use VACTRMT 0

• NCOS Use NCOS 0, no options required.

• IBNXLA No entries required

• IBNTREAT Use TRMT GNCT for Vact_trmt.

Naming Convention for ExercisesEach Team will name their Customer Group using the following naming convention;[Region abbreviation] [Team number] [Additional identifier text]Where Region is EM = EMEA

CA = CALANA = North AmericaAP = AsiaPac

Team number is 1 to 8Additional identifier text is Text at Instructors discretion.

ExampleEM2CUSTGRPWhere EM is Region abbreviation for EMEA, Team 2 and CUSTGRP for Customer Group.

NOTEThe above naming convention will be followed for all subsequent exercises.

30

31

0


nortel.com/training

Module 3

Lines Provisioning

1

2


Module 3 Lines Provisioning

PurposeThe 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.


List the basic SERVORD and OSSGate commandsApply the Query commands to their own lines.Demonstrate selected basic OSSGate/SERVORD commands.

3

4


Table Flow ChartTable Flow Chart

IBNLINES

IBNFEAT

KSETINV

KSETFEAT

KSETLINE

SUBGRP

UPDATESDNINV

These tables are automatically updated These tables are automatically updated if you use SERVORD or SERVORD+ (if you use SERVORD or SERVORD+ (OSSGateOSSGate))

5

6

Line Provisioning IntroductionHistorically, lines on a DMS100 (the CS2k’s 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 theconfirmation screen seen in the TDM SERVORD prompt mode.

7


OSSGate interactions with Succession and Maintenance components in SN07

3rdParty OSS Applications

OSSGateAuthenticationand Authorisation

NodeProvisioning

Line Provisioning

TrunkProvisioning

CarrierProvisioning

ADSLProvisioning

TrunkMaintenanceManager

CS2k Core Manager(SDM/CBM)

Element Managers(GWC EM, MG9k EM,CICM EM)

XA-Core/COMPACT Trunk Gateways(PVG)

Line Gateways

OSSGate IntroductionOSSGate 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 OSSGateapplication. 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.

8

Using OSSGateThe 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). OSSGatecan be used by either an OSS or a standard telnet client.

Supported Provisioning ConnectionsFollowing 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.

9

Connecting to OSSGate via telnetA 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 10023Trying 42.120.94.57...Connected to znc0s0j6.Escape character is '^]'.Enter username and password> maint maintmaint 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*******************************************************************************>

10

OSS/Telnet Client RequirementsNon-Secure channel between client and OSSGateIn 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 ConfigurationA 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.

11

12


OSSGate ‘putty.exe’ settings

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 windowIn Saved Sessions window enter name for session. i.e, MOP-OSSGateClick on Save.Click on Load then Open.

13

OSSGate commandsThe 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.

• loginAllows 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? loginadmin logged out.Enter username and password> maint maintmaint 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*******************************************************************************>

14

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 maintUser Login Failed, Reason: Authentication failed. InvalidUsername / 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? logoutmaint logged out.>

The current or new user can login after a logout using the login command> ^B? loginEnter username and password>

• securityAllows the user to know what security service is being used by OSSGate.Example (User input is highlighted ):> ^B? securitySecurity service is JAAS/PAM based

• clearconvShort for “clear conversation”, it allows the user to end the OSSGatesession.> ^B? clearconvSESSION TERMINATED.Connection closed by foreign host.

• sesm_versionthis communicates and displays the version of CS2000 Management Tools> ^B? sesm_versionSN07 Build: Jul 22, 2004 12:26:02 PM

15

• 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? modeMode is XML.

Example of switching to CI mode>^B? mode ciMode is CI

Disconnecting from OSSGateTo 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? logoutuser1 logged out.> ^B? clearconvSESSION TERMINATED.Connection closed by foreign host.

Note: A user can terminate a session without explicitly logging out, since the clearconvcommand 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.

16

User AuthorizationUser GroupsUsers of OSSGate applications must belong to the primary user group “succssn” and to one or more secondary user groups listed in Table-1

Table 1: User groups

trkadm lnadm mgcadm mgadm emsadmtrkrw lnrw mgcrw mgrw emsrwtrksprov lnsprov mgcsprov mgsprov emsprovtrkmtc lnmtc mgcmtc mgmtc emsmtctrkro lnro mgcro mgro emsro

A secondary user group consist of a user group domain which defines the range of applications to which a user group applies. The following are valid domains for OSSGateapplications

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, rwor 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.

17

Line Provisioning with OSSGateOSSGate 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 CommandsFor 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 9000LENS or gateway/termination names may be used in SERVORD+ commands with certain limitations for MG9000 lines.• CICMLENS must be used for all (I)SN07 and later format Centrex IP lines.

18

DNH Huntgroup DEL command syntax exceptionAnother 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 CommandsWhen executing Line Provisioning commands that are greater than 75 characters long via a telnet session to OSSGate, the commands must be entered following the convention described in this paragraph. If a SERVORD+ command is greater than 75 characters, the user should put up to 75 characters on one line, then enter a ‘+’ symbol and a carriage return (new line) after the 75th character. The remaining portion of the command should be entered on the next line. Using this convention communicates to OSSGate that the command is continued on the next line. In the following example, the single SERVORD command is split over five lines of input. Each of the first four lines ends with a ‘+’ followed by a carriage return, and the prompt is given back to the user after each carriage return. Example

>EST $ DNH 9195200570 1FR LATA1 0 les24.mgcp.net aaln/16 9195200571+

>les24.mgcp.net aaln/17 9195200572 les24.mgcp.net aaln/18 9195200573+



>les24.mgcp.net aaln/23 9195200578 les24.mgcp.net aaln/24 $ $ 15

Note: The command when entered at OSSGate can be split at any position.

19

SERVORD commands supportedAppendix 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 supportThe 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 supportSERVORD+ 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 labellingconsistency 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.

20

Line provisioning commands sent to CICM gateway as part of flow through provisioning include : ADO, CDN, CHF, CHL, DEO, NEW, NEWACD, OUT. CICM client specific SERVORD+ commands (NEW, EST, OUT, etc..) may contain USERID and PASSWD option. The USERID and PASSWD options are used to specify CICM client information in the various SERVORD+ commands which create or modify lines. Datafill interaction include:

Data fill interaction include:1. Key feature addition overwrites any existing key feature on the CICM

terminal. No SERVORD equivalent data fill rules are applied to CICM data fill. CS 2000 SERVORD checking still applies.

2. Assignment of multiple features to a single key is not allowed (e.g., 4 rag 4 3WC). Duplicate feature assignments to key 1 only is allowed (e.g., 1 USERID 1234 $ 1 RAG).

3. CICM specific key features USERID and PASSWD must be assigned to key 1. Duplicate feature assignments to key 1 only is allowed (e.g., 1 USERID 1234 $ 1 RAG).

4. The USERID feature cannot be changed using the CHF command. Use DEO and ADO commands instead. Note that the password is also reset when the ADO command is executed.

5. The PASSWD feature can be added, changed or deleted at anytime providing that the USERID feature is provisioned. If the USERID feature isprovisioned, but the PASSWD feature has not been provisioned, there is no default PASSWD.

6. USERID and PASSWD features will never be sent to the CS 2000 SERVORD interface.

7. CICM and CICM EM applications must be running, otherwise the SERVORD+ command will fail. SERVORD+ commands are not saved or queued when CICM communications is unavailable. They will not beexecuted when connectivity to CICM is restored.

21


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 $ 1USERID 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

22


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

NEW line

Issued NOW

DN

LCC

customer group

subgroup

NCOS

LEN

new $ 6105000 m5316 cs2kcust 0 0 207 1 Y CICM 000 0 00 01 $

SNPA

Blank Directory Number

RingingKey

Option key = No

Example of OSSGate “new” command Fields:DN Directory NumberLCC Line Class Code (m5316 in CentrexIP)Group Customer GroupSubgroup Sub groupNCOS Network Class of ServiceSNPA Serving Number Plan AreaKey Which key DN shall be assigned to on the phoneRinging Will ringing be applied on this lineLEN Line Equipment Number – mapped to Media Gateway and terminal

point

23


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

NEW line

Issued NOW

DN

LCC

customer group

subgroup

NCOS

line number

new $ 6103101 ibn res_cust 0 0 207 mediatrix_1.net aaln/0012 dgt $

SNPA

Blank Directory Number

FQDN

Option

Example of OSSGate “new” command Fields:DN Directory NumberLCC Line Class CodeGroup Customer GroupSubgroup Sub groupNCOS Network Class of ServiceSNPA Serving Number Plan AreaFQDN Fully Qualified Domain Name of analogue lines gatewayAALN Analogue gateway line number.Option DGT – Digitone. Required for analogue IBN lines.

24

SERVORD+ Command Examples for SIP Lines ProvisioningSIP 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 dgtSIP_DATASIP_PACKAGE SIP Lines SIP_URI [email protected]_CLIENT_TYPE SIP Line SIP_LOCATION Nortel Networks.RTP.NC0SIP_PASSWD scott11 $ DPL Y 10 $

2. NEW $ 6195209998 1FR LATA1 0 vmg1 SCOT/000/0/0000 dgtSIP_DATASIP_PACKAGE SIP Lines SIP_URI [email protected]_CLIENT_TYPE SIP Line SIP_LOCATION Nortel Networks.RTP.NC0SIP_PASSWD scott11 $ DPL Y 10 $

CHF Command Examples

1. CHF $ SCOT 00 0 00 00 SIP_DATA SIP_PACKAGE siplinesSIP_PASSWD scott11 SIP_CLIENT_TYPE IBN SIP_LOCATION IBM.RTP $ $

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

OUT Command Examples

1. OUT $ 6195209998 SCOT 00 0 00 00 BLDN

2. OUT $ 6195209998 vmg1 SCOT/000/0/0000 BLDN

25

Query Examples1. > QLEN SCOT 00 0 00 00

LEN: SCOT 00 0 00 00END POINT: vmg1 SCOT/000/0/0000TYPE: SINGLE PARTY LINESNPA: 619DIRECTORY NUMBER: 5209998LINE CLASS CODE: 1FRSIGNALLING TYPE: DIGITONELINE TREATMENT GROUP: 0LINE ATTRIBUTE INDEX: 0CARDCODE: RDTLSG GND: N PADGRP: PKNIL BNV: NL MNO: YPM NODE NUMBER : 87PM TERMINAL NUMBER : 1OPTIONS:DGT DPL Y 10OFFICE OPTIONS:SRAEND POINT DATA:SIP_CLIENT_TYPE: sip lineSIP_EP_NAME: SCOT/000/0/0000SIP_VMG_NAME: vmg1SIP_DN: 6195209998SIP_LOCATION: nortel networks.rtp.nc0SIP_PACKAGE: sip linesSIP_URI: [email protected]

2. > QDN 5209998DN: 5209998TYPE: SINGLE PARTY LINESNPA: 619 SIG: DT LNATTIDX: 0LINE EQUIPMENT NUMBER: SCOT 00 0 00 00END POINT: vmg1 SCOT/000/0/0000LINE CLASS CODE: 1FRLINE TREATMENT GROUP: 0CARDCODE: RDTLSG GND: N PADGRP: PKNIL BNV: NL MNO: YPM NODE NUMBER : 87PM TERMINAL NUMBER : 1OPTIONS:DGT DPL Y 10OFFICE OPTIONS:SRAEND POINT DATA:SIP_CLIENT_TYPE: sip lineSIP_EP_NAME: SCOT/000/0/0000SIP_VMG_NAME: vmg1SIP_DN: 6195209998SIP_LOCATION: nortel networks.rtp.nc0SIP_PACKAGE: sip linesSIP_URI: [email protected]

26

SIP provisioning informationSIP provisioning information include:1. SIP_PACKAGE - Up to 30 characters.2. SIP_URI - Up to 60 characters.3. SIP_CLIENT_TYPE - The system come with a default value of ‘ONT’.

This element can be created on the Prov client. This is used to provision whether the user (sip line) has a static client that it will use to register or not.

4. SIP_PASSWD - The administrator defines the password rules. They include the following types or rules:

• Have a minimum password length between 4 and 10.

• Have a minimum of 0 to 10 numerical characters.

• Have a minimum of 0 to 10 non-numerical characters.

• Be made up of ASCII characters 0x20 through 0x73 hexadecimal or 32 through 126 decimal.

5. SIP_LOCATION - The location name, a brief description of the location being added. This field cannot be null. Maximum length = 30 characters.

6. SIP_SUBDOMAIN - Enter the name of the new local domain. The domain name must not be more then 60 chars in length and cannot contain the following symbols or characters:

• ‘ $ ( ) | ; ~ % [ ] / ! ^ { } ? @ & + “ , # * = : < >

SIP SERVORD examplesSee 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 [email protected] + 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 [email protected] + sip_client_type ont sip_location other2 sip_passwd scott11 sip_subdomain +sm1.nortelnetworks.com $ dpl y 10 dgt cwt $

27


Query System Commands

Query System CommandsThe 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.

28

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 ModeTo 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.

29

Query Directory Number (QDN)QDN queries information about hardware and software associated with a DN.

Example:

ENTRY:QDNDIRECTORY NUMBER8795530DN: 8795530TYPE: SINGLE PARTY LINESNPA: 162 SIG: N/A LNATTIDX: N/ALINE EQUIPMENT NUMBER: HOST 00 0 00 30LINE CLASS CODE: M5209KEY: 1CUSTGRP: IBNDEMO SUBGRP: 0 NCOS:0 RING:YCARDCODE: 6X21BC GND: N PADGRP: NPDGP BNV: NL MNO: YPM NODE NUMBER: 30PM TERMINAL NUMBER: 1OPTIONS: 3WC CFU CFB CFD LNRA RAG INSPECT CPU

30

Query Line Equipment Number (QLEN) from CS2000QLEN obtains a printout of line data related to a specified LEN.

Example:> QLEN CICM 0 0 0 30------------------------------------------------------------------------------------------LEN: CICM 00 0 00 30TYPE: SINGLE PARTY LINESNPA: 162DIRECTORY NUMBER: 8795530LINE CLASS CODE: M5316 SETCUSTGRP: IBNDEMO SUBGRP: 0 NCOS: 0 RING: YCARDCODE: GWLEBS GND: N PADGRP: NPDGP BNV: NL MNO: YPM NODE NUMBER: 30PM TERMINAL NUMBER: 1OPTIONS: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 DN1 87955302 87955403 GIC 7 SALES

KEY FEATURE1 CFK1 CPU 0 HOST 00 1 18 09 $1 SCL 0 L301 MCH1 PRK1 EBO1 DCPK3 RAG4 CNF C305 GIAC6 ICM HOST 00 1 19 04 7 N N7 EMW CLASSP 18 3WC

31

Query Line Equipment Number (QLEN) from OSSGateQLEN 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 30END POINT: CICM-000 tp/0/0030TYPE: SINGLE PARTY LINESNPA: 162DIRECTORY NUMBER: 8795530LINE CLASS CODE: M5316 SETCUSTGRP: IBNDEMO SUBGRP: 0 NCOS: 0 RING: YCARDCODE: GWLEBS GND: N PADGRP: NPDGP BNV: NL MNO: YPM NODE NUMBER: 30PM TERMINAL NUMBER: 1OPTIONS: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 DN1 87955302 87955403 GIC 7 SALES

KEY FEATURE1 CFK1 CPU 0 HOST 00 1 18 09 $1 SCL 0 L301 MCH1 PRK1 EBO1 DCPK3 RAG4 CNF C305 GIAC6 ICM HOST 00 1 19 04 7 N N7 EMW CLASSP 18 3WC

32

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

33

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

34

Query Group (QGRP)QGRP obtains a printout of all the members in the following group types: Call Pickup (CPU), Speed Call User (SCU), Query Busy Station (QBS), Multiple Appearance Directory Number (MDN), Group Intercom (GIC), Hunt (HNT), and Key Short Hunt (KSH).The optional feature Group Number Feature Control allows the assignment of group numbers to CPU, SCU and HNT groups. When this feature is activated, the prompt GRP_NUM replaces DN_or_LEN.

Query CPU Group example:ENTRY:>QGRP (CR) GRP_TYPE: >CPU (CR) LEN: >>00 0 18 08 (CR)SYSTEM RESPONSE:CPU GROUP- - - - - - - - - -LINKLEN: HOST 00 0 18 08 3625089

HOST 00 0 18 09 3625090 HOST 00 0 18 10 3625091 HOST 00 0 18 11 3625092 HOST 00 0 18 12 3625093 HOST 00 0 18 13 3625094

The number of members in the CPU GROUP is 6.

Query Group SCU example:ENTRY:>QGRP (CR) GRP_TYPE: >SCU (CR) LEN: >00 0 18 08 (CR)

SYSTEM RESPONSE:SCU GROUP- - - - - - - - - - -CONTROLLER: HOST 00 0 18 08

HOST 00 0 18 13HOST 00 0 18 12HOST 00 0 18 11HOST 00 0 18 10HOST 00 0 18 09The number of members in the SCU GROUP is 6.

35

36

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 DN’s on keys 1 & 2.Your instructor will advise of Media Gateway names, line numbers and LEN’s.Note down the information.

Analogue Line Info CICM LEN

Team 1__________________________ __________________________________

Team 2__________________________ __________________________________

Team 3__________________________ __________________________________

Team 4__________________________ __________________________________

Team 5__________________________ __________________________________

Team 6__________________________ __________________________________

Note down the DN’s for all the teams.Analogue DN CICM DN’s

Team 1__________________________ __________________________________

Team 2__________________________ __________________________________

Team 3__________________________ __________________________________

Team 4__________________________ __________________________________

Team 5__________________________ __________________________________

Team 6__________________________ __________________________________

37

0


nortel.com/training

Module 4

TRAVER

1

2


Module 4TRAVER

Purpose

The purpose of this section is to introduce you to the followingconcepts;

> The Translation Verification (TRAVER) toolAfter 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.

3

4

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 LineTo 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 TWhere the parameters are . . . . .L = lines ( other parameters are available too )8795301 = dialling number i.e. the calling line5302 = dialled number i.e. the called line

The last parameter comprises T, B, or NT where :T = a request to trace translations tables by listing each TUPLE of each TABLE

used during the translation process.B = a request to trace through translations tables by listing each TUPLE of each

TABLE used during the translation process, as well as displaying the actual routes ( trunks, etc. ) selected.

NT = no trace of TUPLES is to be displayed ; only digit translation routes are to be reported.

NOTE : You may also traver digits starting with * ( star ) or # ( hash ) by entering B for thestar 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 theterminating point, which in this example was a directory number on the CS2000. An

example of the output for this command is given overleaf.

5

In the example on page 1, the command entered is for a station to station call where line8795301 called 5302. An example of the result is given below.Traver L 8795301 5302 TTABLE IBNLINESHOST 00 0 01 01 0 DT STN IBN 8795301 IBNDEMO 0 0 162 $TABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 879 5301 5301( PUBLIC ( ADDRESS 162 897 NNNN ) $ ) $TABLE NCOSIBNDEMO 0 0 0 NO_REST ( XLAS PXDEMO NXLA NDGT ) $TABLE CUSTHEAD : custgrp, prexla, custxla, featxla, vactrmt, and digcolIBNDEMO NXLA CXDEMO FXDEMO 1 DCDEMOTABLE DIGCOLDCDEMO 5 COL S 3TABLE IBNXLA : XLANAME PXDEMO0TUPLE NOT FOUNDDefault is to go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA : XLANAME CXDEMOCXDEMO 5 EXTN N N Y 162 879 4 $TABLE TOFCNAME162 879TABLE DNINV162 879 5302 ILC HOST 00 0 01 02TABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 879 5302 5302( PUBLIC ( ADDRESS 062 879 NNNN ) $ ) $+++ TRAVER : SUCCESSFUL CALL TRACE +++An explanation of the result is given opposite.

6

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.

7

Traver TrunkTo 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 = Trunk ( other parameters are available too )CLLINAME = the Common Language Location Identity name assigned to the trunk group.DIGITS = dialled number i.e. the incoming digits received on the trunk The last parameter comprises T, B, or NT which were described

earlier.

An example of a trunk traver is given on the next page.

8

>traver tr ntdemo2wnat 01628795528 bTABLE TRKGRPNTDEMO2WNAT IBNT2 0 NPDGP NCRT MH4BGRP 0 LIDL 0 N ANSDISC 0 Y N N NN N N 0 0 N0 0 0 0 N N N N N N N N N NATL $TABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILINAP Origination Attempt TDP: no subscribed trigger.TABLE NCOSMH4BGRP 0 0 0 NOREST $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLMH4BGRP NXLA MH4BCXLA NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyINAP Info Collected TDP: no subscribed trigger.TABLE IBNXLA: XLANAME MH4BCXLATUPLE NOT FOUNDDefault from table XLANAME:MH4BCXLA(NET N N 0 N NDGT N Y DOD N 4 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR4 IBN NONE NT 0 0 NILSFC 0 PX MH4BXLA NIL 00 162_NPRT_4 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADMH4BXLA DFLT RTE ( MM 10 11) ( DEST 3)$ DFOP ( MM 10 11)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795528TABLE PXCODEMH4BXLA 016287955 016287955 RTE ( MM 11 11) ( DEST 79)$TABLE: PXRTE

9

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 28TABLE DNFEATTUPLE NOT FOUND. . . TABLE DNATTRS. . . TUPLE NOT FOUND. . . TABLE DNGRPS. . . 162 879 5528 5528. . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$. . EXIT TABLE IBNRTEEXIT TABLE PXRTEINAP Info Analyzed TDP: no subscribed trigger.+++ TRAVER: SUCCESSFUL CALL TRACE +++DIGIT TRANSLATION ROUTES1 LINE 1628795528 STTREATMENT ROUTES. TREATMENT IS: GNCT1 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.

10

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 = VFG ( other parameters are available too )VFGNAME = the name assigned to the Virtual Facility Group.DIGITS = dialled number i.e. the incomming digits received on the VFG.The last parameter comprises T, B, or NT which were described earlier.

An example of a VFG traver is given below.

>traver v alevfg 725101 bTABLE VIRTGRPSALEVFG SIZE 2 IBN N ALECGRP 0 0 4 N N N $TABLE NCOSALECGRP 4 0 0 VFG ( XLAS ALECPTV NXLA NDGT)$TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA,VACTRMT, AND DIGCOLALECGRP NXLA ALECCT ALECFET 10 ALECDCTABLE DIGCOLTUPLE NOT FOUNDDefault is RPTTABLE IBNXLA: XLANAME ALECPTVTUPLE NOT FOUNDDefault from table XLANAME:ALECPTV(NET N N 0 N NDGT N N DOD N 68 162_NPRT_4 NLCA_NILLA_1NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR68 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.

11

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 allAn example output for this command is shown below. The originating line is a business set.TABLE KSETLINEHOST 00 0 00 28 1 DN Y 8795528 IBNDEMO 0 0 162 (CWT) (3WC) (CWI) (CPU) (CFX)$TABLE DNATTRS162 879 5528(PUBLIC ( NAME KEITH_ROBERTS) $)$ $TABLE DNGRPSTUPLE NOT FOUNDTABLE KSETFEATTUPLE NOT FOUNDTABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILAIN Orig Attempt TDP: no subscribed trigger.TABLE NCOSIBNDEMO 0 0 0 NO_RST ( XLAS PXDEMO0 NXLA NDGT)$TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLIBNDEMO NXLA CXDEMO FXDEMO 0 DCDEMOTABLE DIGCOLDCDEMO 6 COL S 3TABLE IBNXLA: XLANAME PXDEMO0TUPLE NOT FOUNDDefault is to go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA: XLANAME CXDEMOCXDEMO 61 ROUTE N N N 2 N 1 6 NDGT Y T IBNRTE 61 $

12

TABLE DIGCOLNDGT specified: digits collected individuallyAIN Info Collected TDP: no subscribed trigger.AIN Info Analyzed TDP: no subscribed trigger.TABLE IBNRTE61 VFG N N N VFGDEM 0EXIT TABLE IBNRTE+++ TRAVER: SUCCESSFUL CALL TRACE +++DIGIT TRANSLATION ROUTES1 VFG: VFGDEM 5529 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++--->---> Resolving VFG: VFGDEM Route with calling digits 5529--->TABLE VIRTGRPSVFGDEM SIZE 2 IBN N MH4BGRP 0 0 0 Y N N $TABLE NCOSMH4BGRP 0 0 0 NOREST $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLMH4BGRP NXLA MH4BCXLA NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyNCOS PRELIM XLA name is NIL. Go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA: XLANAME MH4BCXLAMH4BCXLA 5 EXTN N N Y 162 879 4 $AIN Info Collected TDP: no subscribed trigger.AIN Info Analyzed TDP: no subscribed trigger.TABLE TOFCNAME162 879TABLE DNINV162 879 5529 L HOST 00 0 00 29AIN Term Attempt TDP: no subscribed trigger.TABLE DNATTRS

13

TUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUND+++ TRAVER: SUCCESSFUL CALL TRACE +++

DIGIT TRANSLATION ROUTES1 LINE 1628795529 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++

14

The following is an extract from the DMS Quick Reference Guide NTP TAM-1001-018TRAVER 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 OptionTR <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 OptionsThe "T" option uses parallel software to simulate a call and display the tables used to translate and route a call along with the appropriate tuple for each table. The "NT“ (no trace) option has its own setup processor which calls translation utilities to determine a result. This option displays digit translation routes, position routes, and the circuits and/or treatments on which the call would terminate. The "B" option invokes both the T and the NT option and displays both the call's route & treatment.Optional Parameters<authcode> for tracing LATA Equal Access System (LEAS) calls, mfst, billno, and

bill_mfst parameters are needed; enter nil value (N) for authcode before specifying other optional parameters.

<mfst> indicates the type of signalling on the trunk, the called number MF start signal. A LEAS call cannot be properly traced without this parameter.<billno> is the number to be billed (an information digit plus the calling digits). A

LEAS call cannot be properly traced without this parameter.<bill_mfst> indicates the type of signalling on the calling number trunk; a call involving

LEAS cannot be properly traced without this parameter.

15

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 TRAVERsBearer Capability Routing example travers:> traver l 4844015 94834035 bc 64kdata b % for BC 64kdata calls> traver l 4844016 94834036 bc 56kdata b % for BC 56kdata calls

Some PRI routing examples: (PUBlic call type is traver default)> traver tr PRITEST1 n cdn e164 19192384567 b % NPI:E164, NSF:nil, call type:PUBlic> traver tr PRITEST2 n cdn e164 2831199 prvt b % NPI:E164, NSF:PRVT, call

type:PriVaTe> traver tr PRITEST3 n cdn pvt 095 tie b % NPI:PVT, NSF:TIE, call type:PriVaTe

Note: The type of number (TON) is in the “Called Party Number” and “Calling Party Number” information element. According to the Nortel PRI protocol specifications, when the NPI is “Private” the TON is “Subscriber.” When the NPI is “E.164,” the TON is based on the number of digits dialed as follows:• less than 10 digits: TON is “Subscriber” (Local)• exactly 10 digits: ` TON is “National” (NAtional)• more than 10 digits: TON is “International” (INternational)

16

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?________________________________________________________________________________________________________________________________________________

17

0


nortel.com/training

Module 5

Trunk Groups

1

2


Module 5 Trunk Groups

PurposeThe purpose of this section is to introduce the student to the

concepts of;

> Trunk Groups and their datafill.


List the tables used to establish voice calls.

Describe the purpose of each of the tables

Complete a trunk group datafill exercise

3

4


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

LINEATTR

IBNTREAT


Centrex

Universals

CLLI

TRKGRP

TRKSGRP

TRKMEM

Trunks

5


6


Trunk Network – the big picture

Switch A

Switch B

PBXA

PBXB

Switch E

Switch C

R.O.W

Trunk GroupsTrunks 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.

7


VoiceServices

ElementManagement

IEMS

BackOffice MS20x0


MG15K

Derived Lines

IADCPE

DSLAM

xDSLIAD

Hosted PBX

PBX CableModem

HFCHFC

VideoFeed

CMTS

Cable Modem


Centrex IP

i2004 Etherset

m6350Softclient

PSTN

NetworkSignalling

SS7USP

IPNetwork

CS LAN

GWC

ERS 8600

CS2000cCS2000CS2000

or

CICM

BCP

MCS



Multimedia Server

TDM Interface

CBM


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 CS2000’s GWC’s.

Direct trunks from PBX’s would also be hosted in a similar method.

8


Trunk Groups – a simple view

Carrier

Carrier

CLLI

TRKGRPTRKSGRPTRKMEM

CLLI

TRKGRP

TRKSGRP

TRKMEM

Trunk GroupsTrunks 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

9

Table CLLITable 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 TRKGRPTable 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 TRKSGRPTable 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 TRKMEMTable 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.

10

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

11


Table CLLI Example (C7UP & PRI)

TABLE CLLI

CLLI ADNUM TRKGRSIZ ADMININF

UKPVG 155 31 PVG_TO_UKUKPRI 743 30 TOPVG

Table CLLI ExampleIn 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 CLLI’s.

12

TRKGRSIZ Trunk Group Size. A number in the range 0 - 2047. This field sizes the maximum number of trunks expected in the trunk group. This number may be greater than the actual number of trunks to allow for future expansion, however, it may not be decreased to a value other than 0 and only if all references to the CLLI have been deleted.

ADMININF Administration Information. This field is not used by the CS2000 but is there to enable a description of the CLLI to be added for information purposes. A description of up to 32 characters may be entered.

13


Table TRKGRP example (C7UP)

TABLE TRKGRPGRPKEY GRPTYP TRAFSNO PADGRP NCCLS CUSTNAME SUBGRPNOukpvg ibnt2 0 npdgp ncrt cs2kcust 0SELSEQ NCOS BILLDN SUPV DISCTSEL INTRAGRP DIGIT0aseq 0 n ansdisc 0 n nDIGIT1 DTI TES CDR SMDR TRC ALTNCOS TRKDSR LSCFN ALTLSCFN

n n n n n 0 0 N 0 0LSCINCPT ALSCINCP IGA FDN FDV FLASH DPX PREEMPT AIOD

0 0 n n n n n n nREORIG OFFNET COFFTYP OPTION

N n natl $

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 beenestablished in table CLLI before it can be entered here.

GRPTYP Group type. Enter the trunk group type. This may be IBNT2, IBNTO or IBNTI. In this example, IBNT2 has been used.

TRAFSNO Traffic separation number. A number used to give separate OM counts for traffic on this trunk group. If not required enter 0.

PADGRP Pad group. Enter the name of a Pad group assigned to the trunk group. The pad group must first be built in table PADDATA and is used to define transmission parameters for the trunks. Enter NPDGP (no pad group), if not required.

NCCLS Operational measurement no circuit class. Enter the OM class to indicate which register is to be incremented when treatment GNCT, (General no circuit class), occurs. GNCT occurs when all the available trunks in a route are busy and no alternative is datafilled. Enter NCRT if none apply.

14

CUSTNAME Customer group name. Enter the name of the Customer Group to which the trunk group belongs. Trunks forming part of the PSTN network often belong to a dummy customer group which is established specifically to route incoming calls directly to Universal translations. Private trunks to other sites will probably belong to the Business customer group owning them and may use centrex translations to handle the calls.

SUBGRPNO Subgroup number. This field specifies the attendant console subgroup to which attendant calls should route. It is important not to confuse this subgroup reference with trunk subgroup references specified later. Enter 0 if none apply.

SELSEQ Selection sequence. This field specifies how free trunks will be selected for use from within the trunk group. The terminating ends of each trunk group should be datafilled with the opposite sequence to help avoid dual seizure attempts.The selection sequences are:-ASEQ - Ascending sequence. Trunks will be selected in ascending order of trunk member number as assigned in table TRKMEM.DSEQ - Descending sequence. Trunks will be selected in descending order of trunk member number as assigned in table TRKMEM.LIDL - Least idle. Trunks will be selected on the basis of the least idle trunk will be used next.MIDL - Most idle. Trunks will be selected on the basis of the most idle trunk will be used next.An existing trunk group with ASEQ can be changed to DESQ and visa -versa, so long as the trunk group members are all in the INB state. The selection sequence may not be changed from ASEQ/DSEQ to MIDL/LIDL.

NCOS Network Class of Service. Enter the NCOS number assigned to the trunk group. The NCOS value is used on IBNTI and the incoming call of an IBNT2 trunk. The NCOS may be used to determine the translation path to be followed and can control routing options using the COSMAP system and conditional routing.

BILLDN Billing directory number. If the trunk is seize only, enter the DN to which the call will route. If the trunk receives incoming digits and a billing record is required for calls that tandem through the switch, enter the DN to which calls are to be billed. Enter N if none apply.

SUPV Supervision. Enter the type of call supervision required. Generally, this will be ANSDISC, (answer disconnect). This value allows for notification of far end answer and disconnect conditions.

DISCTSEL Disconnect timing selector. A value in the range 0 - 3 which determines the period of disconnection required to cause the trunk to disconnect. The value represents increments of 200 ms. 0 = 200ms.

INTRAGRP Intragroup. Enter Y, (yes), if the call is to be checked for intragroupnessotherwise enter N, (no).

15

DIGIT0 Digit 0. It is possible to prefix a digit onto the front of the incoming digit string using this field. A maximum of two digits may be prefixed, the second digit is assigned in the DIGIT1 field. Digits in the range 0-9, B or C may be assigned.NOTE: The default for this field is B which translates to * (star).If no prefix digits are required you must enter N in this field.

DIGIT1 Digit 1. As for Digit 0 above but for the second prefix digit.DTI Dial tone incoming. If second dial tone is sent to the incoming caller enter Y.

Generally, this field is set to N.TES Toll essential service. Not used, enter NCDR Call detail recording. If incoming calls are to be recorded using the SMDR

format enter Y.Generally, this field is set to N.SMDR Station Message Detail Recording. (call logging). If call logging records are

required enter Y, otherwise enter N.TRC Terminating restriction code. TRC codes work with the line feature DIN,

(Deny incoming). TRC codes assigned with the feature DIN allow calls from the trunks with matching codes to terminate on the line. Calls from trunk groups whose codes do not match will be denied.Avalue of 0 - 7 may be entered here. Generally, this field is set to 0.

ALTNCOS Alternate NCOS. Enter an NCOS value that will be applied if the attendant feature Attendant Control of Trunk Group Access is activated. Generally, this field is set to 0.

TRKDSR Trunk distinctive ringing. Generally, this field is set to N.LSCFN Line screening code flag number. This is a code number in the range 0 - 255.

This field is used in conjunction with the NCOS field LSC, (line screening code). The two values are mapped together in table LSCFLAGS and may be used to control access to trunks from lines or incoming trunks. Generally, this field is set to 0.

ALTLSCFN Used in conjunction with the above.Generally, this field is set to 0.LSCINCPT Line screening code flexible intercept. A value in the range 0 - 63 which is

an index into table IBNTREAT. Calls failing line screening will be routed to this treatment table.

ALSCINCP Alternate Line screening code flexible intercept. A value in the range 0 – 63 which is an index into table IBNTREAT. Calls failing line screening will be routed to this treatment table if the attendant feature Attendant Control of Trunk Group Access is activated.

IGA Generally, this field is set to N.FDN Generally, this field is set to N.FDV Generally, this field is set to N.FLASH Generally, this field is set to N.DPX Generally, this field is set to N.PREEMPT This field must be set to N.

16

AIOD Generally, this field is set to N.REORIG Generally, this field is set to N.OFFNET Generally, this field is set to N.COFFTYP Class of Office Type. Enter NATL for National.OPTION Options. Enter any options required. One example is the option NETXLA.

This is used to indicate that customer group information is to be sent in the NETINFO parameter of an ISUP trunk group.

17


TABLE TRKSGRP

SGRPKEY CARDCODE SGRPVAR DIR ESUPR SAT ECSTAT NSMATCHukpvg 0 ds1sig c7up 2w n n internal nAUTOON ABCNTL PROTOCOL CONTCHK COTREQ ADJNODE ACO OVLP

n none q767 thrl 0 dmsnode n yVARIANT VERSION OPTION TMRNAME GLARETYP

Base 100_blue $ nil cic

Table TRKSGRP Example (C7UP)

This is an example of a TRKSGRP entry for voice trunks using CCS 7 User Part signalling. Once again, the CLLI name forms the key into the table along with the subgroup number. If the type of pulsing is Common Channel Signaling 7 (CCS7), datafill table TRKSGRP as described in the following datafill table. This datafill also applies to DMS-300 CCITT No. 7 ISDN user part signaling (ISUP), the United Kingdom variant of national user part (BTUP), telephone user part (TUP), and telephone user part plus (TUPPLUS or TUP+) trunk groups.

For the C7UP example the fields are:-

SGRPKEY Subgroup key. This field comprises the subfields CLLI and SUBGRP, the CLLI name of the trunk group and the trunk subgroup number.

CARDCODE Enter the card type used to support the trunks. This may differ dependant on the signalling system. CCS 7 uses DS1SIG.

SGRPVAR Variable subgroup data. This field consists of subfields as describedbelow. Enter TUP here to indicate the U.K. CCS 7 signalling variant.

DIR Direction. Enter the trunk group direction 2W,(two way), IC (incoming), or OG (outgoing). The direction must be the same as defined in table TRKGRP.

ESUPR Echo suppression. Enter N to indicate that no echo suppressors are installed.

SAT Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a satellite. If not, enter N, (no).

18

ECSTAT Echo canceler status. Enter UNEQ to indicate that Echo canceler is not equipped on this subgroup.

NSMATCH Noise match control. Enter N to indicate that background noise is not maintained if internal echo canceler status is actively cancelling echoes.The default is N.

AUTOON Auto re-enable control. Enter N to indicate that the echo canceler status is not automatically turned on after the 2100-Hz tone control is removed. This option is similar to the END OF CALL option for tone disablers in external echo canceler status.The default is Y.

ABCNTL A-bit control. Enter NONE if this field is not used by call processing control software.

PROTOCOL Signalling protocol type. Enter the required signaling protocol and datafillany 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 AISUPtrunks, 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 thekey in table ADJNODE. Table ADJNODE also contains the adjacent node data used for this trunk subgroup. If the reference to table ADJNODE does not apply, enter NIL.

ACO Answer charge. This field determines if an answer charge is applied on BTUP to ISUP calls.

OVLP Overlap signaling. Enter Y if overlap signaling is permitted. Enter N if digits are outpulsed en bloc, that is, outpulsing does not begin until all digits have been received from the incoming trunk. The default is N.

VARIANT Variation. This field is used if the user part of ISUP is datafilled against the trunk subgroup to identify the variation of ISUP. The default is BASE.

VERSION Version. See the PROTOCOL parameter.

19

OPTIONS Options. Enter up to 7 options. See NTP’s 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.

20


Table TRKMEM (C7UP)

TABLE TRKMEM

CLLI EXTRKNM SGRP MEMVAR

UKPRI 1 0 GWC 1 8 300

UKPRI 2 0 GWC 1 8 301

UKPVG 1 0 GWC 1 8 332

UKPVG 2 0 GWC 1 8 333

The fields are:-

CLLI Common Language Location Identifier. Enter the CLLI name of the trunk group to which these trunks are to become members.

EXTRKNM External trunk number. A number in the range 0 to 9999. Each trunk must have a unique number and they usually run consecutively in ascending order. Remember, the total number of members is restricted by the TRKGRSIZ field in table CLLI.

SGRP Subgroup number. A value of 0 or 1 which represents the subgroup number, built in table TRKSGRP, to which these trunks are assigned. Table

TRKSGRP defines the signalling parameters for the trunks.PMTYPE Peripheral module type. Enter the type of peripheral module to which the

trunks connect. GWCNO Gateway Controller NumberGWCNODENO Gateway Controller Node NumberGWCTRMNO Gateway Controller Terminal Number

21

22

SUMMARYTrunks 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 TRKGRPTable 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 areIBNTI - Incoming only, IBNTO - Outgoing only and IBNT2 - Bothway.

Table TRKSGRPTable TRKSGRP defines the signalling parameters used. Two subgroups may be defined for a trunk group.

Table TRKMEMTable TRKMEM defines and allocates the resource used by each individual trunk within the trunk group.

23





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........







24

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 ExerciseDatafill 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 AsiaPacTeam Number – 1 to 8Signalling 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.

25

26

Trunk Group Exercise Room plan

Team 4Team 3

GWC No__1__GWC Node__8__GWC TermNo__630__

Team 2

GWC No_1___GWC Node__8__GWC TermNo_620___

Team 1

GWC No__1__GWC Node__8__GWC TermNo_610___

GWC No__1__GWC Node_8___GWC TermNo_640___

Team 5


Team 6



GWC No__1__GWC Node__8__GWC TermNo_631__

GWC No__1__GWC Node_8___GWC TermNo__641__




27

0


nortel.com/training

Module 6

Route Tables

1

2


Module 6 Route Tables


concepts of; > Route Table datafill procedures


List the Route TablesDescribe the format of a Route TableExplain the term ARSDefine the route element selectors and their purposesDatafill route lists

3

4


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

LINEATTR

CLLI

TRKGRP

TRKSGRP

TRKMEM

OVRx

OFRT

IBNRTE

IBNTREAT


Centrex

Universals

Trunks

Routing

5

6


Introduction to Routing Tables

IBRTxTables

ORTxTables

OVRxTables

Centrex Translations


DirectoryNumber Treatment

TrunkGroup/s

Introduction to Routing TablesThis 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 TablesIBNRTx (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.

7

Route ListsEach 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: OFRTRTE RTELIST60 (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 CLLI’s, route link and tone.

The Route selectors are discussed next.

8

Route Element SelectorsA 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 DescriptionsThere are many selectors available and they are all detailed in NTP Succession Networks Operational Configuration: Data Schema Reference NN10324-509.01.02. This module will concentrate on the selectors commonly used in the European market.

Route Selector S Points to a CLLI name. This may be the name of a trunk group, announcement or tone. This selector is used when the digits dialled are the digits outpulsed.

Route Selector T Points to another route list. The route list may be in the same Route table or a list in another Route table. The T selector is used when linking Route lists together. If you stay in the same Route table, the list pointed to must have a higher Route list number.

Route Selector ST Points to another index within the same route Table. The index pointed to must be a higher number.

Route Selector DN Resolves a call to a Directory Number on the same switch.Route Selector N Points to a CLLI name in the same way as an S selector. The

N selector additionally allows for digit modification of the outpulsed digits. The modification occurs after translation and does not affect the translation registers. The use of this selector in the IBNRTE tables will point to an index into the digit modification table DIGMAN. In the OFRT tables, digit modification occurs within the fields of the table itself.

Route Selector CND The conditional selector, CND, is used when a call is to proceed only if a certain condition is met. If the condition is not met, the call is routed as specified in the next element of the route list. The common conditions are:-TOD, Time of Day, where routing choices can be altered dependant upon the time, the day and special days of the year.RND, Random, where traffic can be split across routes on a random percentage basis.COSMAP, where calls can route dependant on their Class of Service.NRR, Network blocking Re-Route, where calls can route if a network busy condition is encountered from the next switch onwards.

9

Route Selector VFG Points to a Virtual Facility Group from an IBNRTE table. VFG’s are (IBNRTE only) software trunks and are used to limit access to “real” trunks as well as allowing the assignment of different Customer Group attributes and billing numbers.

Route Selector TRMT Points to a specified Office Treatment.Route Selector INS Allows new route elements to be inserted into existing route

lists at any route element position. Route Selector NIL This selector allows deletion of elements from the route list at

any route element position.Route Selector MEM Allows the selection of one or a number of trunks from the

trunk group. (Not IBNRTE) E.g. for testing purposes.Route Selector SG This selector in conjunction with Table SUPERTKG joins up

to 220 ISDN primary rate interface (PRI) trunk groups (defined in table TRKGRP) together into super-groups.

The following examples show typical table entries for some of the route selector options described. The ‘S’ & ‘N’ selectors are shown using both IBNRTE and OFRT (+OVR) tables to give a comparison of the differences in the fields when using these different routing tables.

10


Route Table Datafill ExampleIBNRTx S selector

Table IBNRTERTE IBNRTSEL OHQ CBQ EXP MBG CLLI11 s n n n n ntmdhddlog

IBNRTSEL OHQ CBQ EXP MBG CLLIs n n n n ntslghdlog

IBNRTSEL OHQ CBQ EXP MBG CLLIs n n n n busy

This example shows a route list of 3 elements. The first 2 elements point to trunk groups and the final element points to the tone busy. The fields are:-RTE The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.IBNRTSEL The route element selector. S in this example.OHQ Off hook queuing. Set to Y if Off hook queuing is allowed for this route

element, otherwise enter N.CBQ Call Back Queuing. Set to Y if Call back queuing is allowed for this route

element, otherwise enter N.EXP Expensive Route Warning Tone. Set to Y if this element is an expensive

route and warning tone is required.MBG Multi Switch Business Group. Enter NCLLI 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 datafillof ‘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.

11


Route Table Datafill ExampleOFRTx S selector

TABLE: OFRTRTE RTESEL CONNTYPE CLLI20 s d ntmdhddlog

RTESEL CONNTYPE CLLIs d ntslghdlog

RTESEL CONNTYPE CLLIs d busy

In this example, the S selector is used to point calls to a choice of two trunk group CLLI’swith 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 The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.RTESEL Route Selector. The route element selector. S in this example.CONNTYPE Connection type. The field is not used by the software, enter D to satisfy

table editor.RTE The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.RTESEL Route Selector. The route element selector. S in this example.CONNTYPE Connection type. The field is not used by the software, enter D to satisfy

table editor.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.

12


Route Table Datafill ExampleIBNRTx N selector

TABLE IBNRTERTE IBNRTSEL OHQ CBQ EXP MBG CLLI DMI12 n n n n n ntmdhddlog 0

IBNRTSEL$

In this example, route list 12 is used to point calls to the trunk group CLLI ntmdhddlog. The difference between using the N selector and S selector is that you may use digit modification to modify the digits sent out on the trunk group. The DMI field is set to 0 indicating that no modification is required.The fields are:-RTE The Route list number in the range 0 to 1023. IBNRTSEL The route element selector. N in this example.OHQ Off hook queuing. As seen before for IBNRTx.CBQ Call Back Queuing. As seen before for IBNRTx.EXP Expensive Route Warning Tone. As seen before for IBNRTx.MBG Multi Switch Business Group. As seen before for IBNRTx.CLLI Common Language Location Identifier. Enter the CLLI name to which the

translation is routed.DMI Digit Manipulation Index. 0 means no index, any number between 1-32767

will index Table Digman.Again the Centrex Features fields are present, however an extra field is added.This extra field, the DMI field is an index into table DIGMAN where digit manipulation may be performed on the dialled digits. Table DIGMAN is designed for use in Centrex applications, so it was designd to be accessed from different tables by the use of an index (DMI). Compare this with the following OFRT routing table datafill

13


Route Table Datafill ExampleOFRx N selector

RTE RTESEL CONNTYPE CLLI DELDIGS PRFXDIGS CANCNORC23 n d ntslghdlog 0 162 y

In this example, the N selector is used to point calls to a trunk group CLLI. The N selector gives the additional ability to manipulate the outpulsed digits. The manipulation occurs within the fields of the tuple as table OFRT cannot be used to index table DIGMAN. A further field allows for the cancellation of normal call charges. A common application for this is where termination of test calls to an announcement requires an answer condition and billing.The fields are:-RTE The Route list number in the range 0 to 1023. RTESEL Route Selector. The route element selector. N in this example.CONNTYPE Connection type. As seen before for OFRx.CLLI Common Language Location Identifier. As seen before for OFRx. DELDIGS Delete Digits. Enter the number of digits to be deleted from the digit string

prior to outpulsing. A maximum of 15 digits may be deleted. Enter 0 if no digits are to be deleted.

PRFXDIGS Prefix Digits. Enter the digits to be prefixed prior to outpulsing. A maximum of 11 digits may be specified. The specified digits will be prefixed to the front of the digit string once any deletion has occurred.

N.B. Enter N if no digits are to be prefixed.CANCNORC Cancel Normal Charge. This field may be set to Y, (yes) or N, (no). Calls

may have their normal charge cancelled using this field. Calls routing to an announcement ( these are not normally charged ) that require a charge to be raised will have this field set to Y. In general, when this field is set to Y, a non revenue call is assumed. If the field is set to N, a revenue call is assumed unless non revenue is indicated elsewhere.

14


Route Table Datafill ExampleIBNRTx T selector

Table IBNRTERTE IBNRTSEL OHQ CBQ EXP MBG CLLI10 s n n n n ntmdhddlog


IBNRTSEL EXTRTEID t ovr55 11

IBNRTESEL$

21 IBNRTSEL OHQ CBQ EXP MBG CLLIs n n n n ntrdgdlog

IBNRTSEL RTEREFst 22

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 The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.IBNRTSEL The route element selector. T in this example.EXTRTEID External Route I.D. The Route table, e.g. OFRT, and index number to which

the call will be routed.

Note; If staying in the same table, the ST Selector is easier to use.

The ST selector is limited to pointing to a higher index in the current Routing Table.The ST selector is available in OFRx and OVRx also.

In the example above calls routed to IBNRTE index 10 will search through CLLI’sNTMDHDDLOG then NTSLGHDLOG before going to OVR55 index 11 to continue.IBNRTE index 21searches CLLI NTRDGDLOG then goes to IBNRTE index 22.

15


Route Table Datafill ExampleIBNRTx DN selector

TABLE: IBNRTERTE IBNRTSEL SNPA NXX EXP DMI STNLEN211 dn 162 870 n 0 4

IBNRTSEL$

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 The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.IBNRTSEL The route element selector. DN in this example.SNPA Serving Number Plan Area also known as the Area Code. The first three

digits of the full 10 digit number.NXX The Office Code digits. The next three digits in the number.EXP Expensive Route Warning Tone. Set to Y if this element is an expensive

route and warning tone is required.DMI Digit Manipulation Index. An index into table DIGMAN where digit

manipulation may be performed on the dialled digits. Table DIGMAN usesindex numbers in the range 1 to 32767. In this example, the DMI index number is 0 to indicate that no digit manipulation is required. In this case, the last four digits of the dialled number are passed on transparently.

STNLEN Station length (1 to 8 digits). Used to identify the station code length of the terminating agent.

16


Route Table Datafill ExampleIBNRTx & OFRx TRMT selector

TABLE IBNRTE or OFRTRTE RTESEL RTETRMT212 trmt gnct

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 The Route list number in the range 0 to 1023. This field is entered for the

first instance of the route list.IBNRTSEL The route element selector. TRMT in this example.RTETRMT Route Treatment. A treatment name from table TMTCNTL.

17


Route Table Datafill ExampleIBNRTx CND - TOD selector

TABLE IBNRTERTE IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUM211 cnd tod demotod 1 sk 1

IBNRTSEL OHQ CBQ EXP MBG CLLIs n n n n ntmdhddlog


IBNRTSEL EXTRTEIDt ibnrte 300

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.

18


Route Table Datafill ExampleIBNRTx CND - COSMAP selector

TABLE IBNRTERTE IBNRTSEL CNDSEL COSMAP RTETYPE RTEREF212 cnd cosmap netcos st 300


IBNRTSEL OHQ CBQ EXP MBG CLLIs n n n n busy

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.

19


Route Table Datafill ExampleIBNRTx CND - RND selector

TABLE IBNRTERTE IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEID211 cnd rnd 50 t ibnrte 600

IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEIDcnd rnd 50 t ibnrte 601

IBNRTSEL CNDSEL PERCENT RTETYPE EXTRTEIDcnd rnd 50 t ibnrte 602


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 callsIBNRTE 601 – 250 callsIBNRTE 602 – 125 callsIBNRTE 604 – 125 calls.

As an alternative, for all the remaining calls are to be sent to IBNRTE 604 the above T selector could have been datafilled as follows;IBNRTSEL CNDSEL PERCENT RTETYPE INDEX

cnd rnd always st 604

In this instance Always send 100% of the remaining traffic to IBNRTE 604.

20

INS SelectorTo 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) $ $

( don’t 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 routeINCONSISTENT DATATUPLE 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.

21

22

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

23

24

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.

25

0


nortel.com/training

Module 7

Universal Translations Overview

1

2


Module 7 Universal Translations Overview


concepts of; > Universal Translations tables and their options.

After this module of instruction, you will be able toName 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

3

4


CS2000 Universal TranslationsCentrex

CustomerGroupTables

TrunkGroupTables

RoutingTables


Tables

Call ControlTables

5


6


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

PXRTE

PXCODE

PXHEAD

LINEATTR

CLLI

TRKGRP

TRKSGRP

TRKMEM

OVRx

OFRT

IBNRTE

IBNTREAT CTRTE

CTCODE

CTHEAD

OFCRTE

OFCCODE

OFCHEAD

FARTE

FACODE

FAHEAD

CS2000 Universal TranslationsTable Association ChartCentrex

Universals

Trunks

Routing

7

8


Universal Translations Universal Translations OverviewOverview

Centrex Centrex Customer Customer

GroupGroup

UniversalUniversalTranslationsTranslations

LINEATTR LINEATTR NET DODNET DOD

Other Other Customer Customer GroupsGroups

To Trunks to To Trunks to other switchesother switches

To To AnnouncementsAnnouncements

BILLINGBILLING

Universal Translation Tables Functional OverviewCS2000 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.

9


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 TranslationsThe 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).

10

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

11


Universal Translation Digit Registers

Outpulse Register

Translation Register

Billing Register

May change

Will probably change

May change - Careful !

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 RegisterThe 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 RegisterThe 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 RegisterThe 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 ManipulationDigit 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.

12


Universal Translation Systems & Tables

AC PX CT FA OFC FT NSC AMHEAD

CODE

RTE

HEAD HEAD HEAD HEAD HEAD HEAD HEAD

CODE CODE CODE CODE CODE CODE CODE

RTE RTE RTE RTE RTE RTE

Access Code

Prefix Code

Country Code

Foreign Area Code

Office Code

Utility Code

Number Service Code

Ambiguous code

Universal Translation SystemsUniversal 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).

13

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 segmentTo 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 tablesThe 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.

14


Universal Translation Head Tables

DFLT - Defaultaction if digitsare not in the Code table

DFOP - Defaultoptions to applywhen digits arematched in theCode table

CONConsume the digits used to index the Code table

MAXIDX9 or STD

XLANAME

Table xxHEAD

Universal Translation Head TablesHead Tables and Their OptionsAs 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>CONMAXIDX<hex digit>A description of each option follows:

15

DFLT - DefaultThis 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 OptionsIn 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

16


Universal Translation Code Tables

XLANAME

Table xxCODE

FROMD TOD XLADATA

Digit range to be matched Instructions to followif dialled digits fallwithin the FROMD and TOD range

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.

FROMDThe digit string of the first number range being screened ( 1 to 11 digits )TODThe digit string of the last number in the range being screened. (1 to 11 digits )XLADATAThis 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 XLTRTE DESTTRMT MMDMOD CLASSFEATINFO CONSUME

CALLCTRLAMAXLAID

17

Universal Translation Tables Routing OptionsIn 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 XLASELTable (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 originator’s 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 studiesconducted so far, the following options should be available:TRMT - route to treatmentA 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 translatingThis 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

18

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 foundA 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.

FEATINFOThe FEATINFO selector is used for specific screening purposes and will be covered in a later module.

19

DMOD - Digit ModifyThis 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 ite.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

20


Universal Translation Route Tables

XLANAME

Table xxRTE

RTEREF RTELIST

Index number pointed from xxCODE table

Route selector,as seen inearlier Route Tablemodule.

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.

21


Head and Code Table example

DFLT - Defaultaction if digitsare not in the Code table

DFOP - Defaultoptions to applywhen digits arematched in theCode table

CONConsume the digits used to index the Code table

MAXIDX9 or STD

XLANAME

XLANAME

Table PXHEAD

Table PXCODE

FROMD TOD XLADATA

Digit range to be matched Instructions to followif dialled digits fallwithin the FROMD and TOD range

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.

22



If there is a match in the FROMD TOD

field use these options.NODFOP no defaultoptions or DFOP e.g.

MIN MAX

DFOPDFOPWhat to do if the

digits do not match in FROMD TOD

SDFLT = vactrmtDFLT = xlasel to

process the call

DFLTSELDFLTSEL

The translation selectors you can use .

e.g.CONT, RTE,

DMOD & TRMT

XLASELXLASEL

Same translationSelectors as Code Table options

Digit range to bematched

e.g. from 00 to 00

FROMD TODFROMD TOD

If there is a match in the FROMD TOD

field, instructions on on how to

process the call.

XLADATAXLADATA

A reference number from the code table

into this table.

RTEREFRTEREF

Route selectorT

to point out to therouting tables

RTESELRTESEL

Routing table name

TABNAMETABNAME

Index number into therouting table

INDEXINDEX

CON - consume the digits

NOCON - do not consume the digits from the FROMD

TOD field

CONCON

9 or STD

MAXMAX

Translator name is the index into

the 3 tables

XLANAMEXLANAME

HEADHEADNOCON cannot be Overridden by the code table

Code table instructions overrides Head table instructions


the 3 tables

XLANAMEXLANAME

RTE RTE


the 3 tables

XLANAMEXLANAME

CODECODE

This diagram shows the relationship between the three tables that make up a Translation System.Note all the Translation Systems have the same relationship.

23

Translations ExpansionTranslations 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 restrictionsThe 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).

24


Functional diagram for the new xx2 translations systems

xxHEAD

xxRTE

xx2CODE xxCODE

CONTCONT

CONT

RTE RTE

Default DefaultRouting Routing

New translations systemsThe 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 optionExamples;From Table PXHEADEMERG DFLT CONT (XLT PX2 NATIONAL) $ DFOP (MM 3 5) (CLASS NATL) $ CON 9

From PXCODEEMERG 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;

25

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>addKEY:>emerg 5555 5555XLASEL:>contOSEL:>xltXLASYS:>ct2XLANAME:>danct2laOSEL:>$TUPLE TO BE ADDED:EMERG 5555 5555 CONT (XLT CT2 DANCT2LA) $ENTER Y TO CONFIRM, N TO REJECT OR E TO EDIT.>yTUPLE ADDEDWRITTEN TO JOURNAL FILE AS JF NUMBER 496RTE Selector option TERMThe 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 tableThe new TERM option allows the xxCODE tables to directly access the OFRx, IBNRTxand 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 xxRTEtable

The functional diagram for routing from a CODE table is shown in the following figure.

26


Functional diagram for routing from a CODE table

xxHEAD

xxCODE

Corresponding

xxRTE

IBNRTxOFRxOVRxxxRTE

27



Customer Group

Lines

Trunks

Other Switches

Table

Lineattr

Universal

Translations

Customer Group

Lines

Trunks

Other Switches

TableLINEATTR


CS2000

Table Lineattr – Entry point to Universals

Table LINEATTRTable 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 UNICTTUPLE NOT FOUNDDefault 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 LINEATTR1 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.

28

Table LINEATTR (another) Example:Table LineattrLNATTIDX LCC CHGCLSS COST LTG TRAFSNO SFC MDI PSTNXLA ibn none nt 0 0 nilsfc 0 XLASYS XLANAME DGCLNAME FANIDIGS DFLTXLP DFLTRA OPTION

px mh3pxla nil 00 CS_NPRT CS_NIL $

In this example, line attribute index PSTNXLA is used to point calls to the PX XLASYS, XLANAME mh3pxla. There are a number of fields that do not apply to the U.K. translation schemes and default values may be assigned. The fields are:-LNATTIDX Line Attribute Index. Alphanumeric (up to 16 characters)LCC Line Class Code. The line class code assigned to the line attribute index.

Enter IBN for IBN translations.CHGCLSS Enter NONE.COST Enter NT.LTG Enter 0, (zero)TRAFSNO Traffic Separation Number. Peg counts calls by type. Enter 0, (zero)SFC Enter NILSFCMDI Enter 0, (zero)XLASYS Translation System. Enter the XLASYS in which calls will start translation.

N.B. The PX system must be used for calls from Centrex translations using the NET - DOD selector.

XLANAME Translator name. Enter the translator name within the PX XLASYS in which calls will start translation.

DGCLNAME Enter NILFANIDIGS Enter 0 0, (zero) (zero)DFLTXLP Defaullt XLAPLAN, enter valid entries from Table XLAPLANDFLTRA Default RATEAREA, enter valid entries from Table RATEAREA

29


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.

30


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

31

0


nortel.com/training

Module 8

Universal Translations Datafill –

International Calls

1

2


Module 8 Universal Translations –International CallsPurposeThe purpose of this section is to introduce the student to the

concepts of; > Universal Translations datafill procedures.


Describe the call flow process in Universal TranslationsDatafill an exercise to handle International Calls, using the translation selector CONT and RTE with applicable OSEL optionsTraver the results of your datafillExplain the results of the Travers

3

4


PXPSTNPXLA

CTPSTNCTLA

Route for calls torest of the world

DFLTRoute for callsTo Europe

from table LINEATTR

SDFLT (temporarily)

Universal Translations Datafill – International Calls

IDD

Universal Translations Datafill ExamplesThe 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.

5

Datafill PlanningThe 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 EntryOnce 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 ExampleThe 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.

6

Head Table ExampleThe 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 PXHEADXLANAME DFLTSEL DFOPSEL CON MAXIDXpstnpxla 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 ExampleThe 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 PXCODEXLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGS OSELpstnpxla 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 dialleddigits. The field includes options, (OSEL), that are applied to the matched digits.

7

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 MAXAnother 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 .

8

CT Head and Code tableAs 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 CTHEADXLANAME DFLTSEL XLASEL OSEL MIN MAX OSEL DEST OSEL CLASS OSELpstnctla dflt rte mm 7 18 dest 3 class intl $DFOPSEL OSEL CLASS OSEL CON MAXIDXdfop class intl $ nocon std

The HEAD table tuple shows the fields in bold text.The field XLANAME declares the translator name PSTNCTLA.

The field DFLTSEL defines the action to take if the dialled digits are not matched in the associated CODE table. In this example the default action is to RTE (route) calls to a DEST (destination) of 3 and apply a MIN and MAX digit check of 7 to 18 digits. A further option CLASS has been applied. The CLASS type is INTL (international),which is the trigger for an AMA billing record. The options used where described in the Overview module.

The field DFOPSEL defines default options to be applied to all entries in the CODE table. In this instance the CLASS INTL (international) has been applied. Remember, DFOP options applied in the HEAD table can be overriden by options applied in the CODE table.

The field CON declares that nocon, (no consume), will be applied. This value applies as we are going to RTE calls without further translation applying.

The 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.

9

The CODE table will look like this:-

TABLE CTCODEXLANAME FROMD TOD XLASEL OSEL MIN MAX OSEL DEST OSELpstnctla 31 31 rte mm 12 12 DEST 6 $

CT RTE tableA 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 CTRTEXLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 3 t ibnrte 70 $XLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 6 t ibnrte 60 $

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 thecorresponding 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.

10

TABLE PXHEADXLANAME DFLTSEL DFOPSEL CON MAXIDXpstnpxla sdflt nodfop con std




TABLE CTRTEXLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 3 t ibnrte 70 $ Other InternationalXLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 6 t ibnrte 60 $ European

11

TABLE PXHEADXLANAME DFLTSEL DFOPSEL CON MAXIDXpstnpxla sdflt nodfop con std




TABLE CTRTEXLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 3 t ibnrte 70 $XLANAME RTEREF RTESEL TABNAME INDEX RTESELpstnctla 6 t ibnrte 60 $

12

Call SummaryCalls 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.

13

This page is intentionally left blank

14

Traver - European Call>TRAVER L 8795215 00331234567890 BTABLE KSETLINERM05 00 0 02 15 1 DN Y 8795215 CLASSDEM 0 0 162 $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 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 NCOSCLASSDEM 0 0 0 NO_BAR $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCLASSDEM NXLA CXCLASS FXDEMO 0 CLASSDIGTABLE DIGCOLTUPLE NOT FOUNDDefault is RPTTABLE IBNXLA: XLANAME CXCLASSTUPLE NOT FOUNDDefault from table XLANAME:CXCLASS(NET N N 0 N NDGT N Y DOD N 1 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $

15

TABLE PXHEADDEMOXLA SDFLT DFOP $ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 00331234567890TABLE PXCODEDEMOXLA 00 00 CONT ( CONSUME 2) ( XLT CT DANCTLA)$TABLE CTHEADDANCTLA DFLT RTE ( MM 10 18) ( DEST 2) ( CLASS INTL)$ DFOP ( MM 12 12) ( CLASS 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 331234567890TABLE CTCODEDANCTLA 3 3 RTE ( DEST 1)$TABLE: CTRTEKEY: DANCTLA 1. T OVR30 1. . TABLE OVR30. . 1 S D DANEURO. . EXIT TABLE OVR30EXIT TABLE CTRTEOriginator 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 ROUTES1 DANEUROTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT

16

Traver - Rest of the World>TRAVER L 8795215 0063334745255 BTABLE KSETLINERM05 00 0 02 15 1 DN Y 8795215 CLASSDEM 0 0 162 $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 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 NCOSCLASSDEM 0 0 0 NO_BAR $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCLASSDEM NXLA CXCLASS FXDEMO 0 CLASSDIGTABLE DIGCOLTUPLE NOT FOUNDDefault is RPTTABLE IBNXLA: XLANAME CXCLASSTUPLE NOT FOUNDDefault from table XLANAME:CXCLASS(NET N N 0 N NDGT N Y DOD N 1 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR1 IBN NONE NT 0 0 NILSFC 0 PX DEMOXLA NIL 00 031_NPRT_1 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $

17

TABLE PXHEADDEMOXLA SDFLT DFOP $ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0063334745255TABLE PXCODEDEMOXLA 00 00 CONT ( CONSUME 2) ( XLT CT DANCTLA)$TABLE CTHEADDANCTLA DFLT RTE ( MM 10 18) ( DEST 2) ( CLASS INTL)$ DFOP ( MM 12 12) ( CLASS 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 63334745255TABLE CTCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE: CTRTEKEY: DANCTLA 2. T OVR30 2. . TABLE OVR30. . 2 S D DANNONEURO. . EXIT TABLE OVR30EXIT TABLE CTRTEOriginator is not an EIN agent, therefore EIN info is not processed.Originator is not an EIN agent, therefore EIN info is not processed.


DIGIT TRANSLATION ROUTES1 DANNONEUROTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT

18


19





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........







20


PXPSTNPXLA

CTPSTNCTLA



from table LINEATTR

SDFLT (temporarily)

Universal Translations Datafill – International Calls Exercise

IDD

Universal Translations ExercisesThe 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.

21

Exercise 1The 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.

22

23

0


nortel.com/training

Module 9

Universal Translations Datafill –Local Calls

1

2


Module 9 Universal Translations Datafill – Local CallsPurposeThe purpose of this section is to introduce the student to the concepts of;

> Universal Translations datafill procedures


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

3

4


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

SDFLT (temporarily)

Terminate Local calls

SDFLT

Treatment

Universal Translations Datafill – Local Calls

IDD

Local

IntroductionIn 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.

5

Datafill Examples using DMODThe 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 insertionIn 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 CallsThe 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 ExampleThe 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 PXHEADXLANAME DFLTSEL XLASEL OSEL XLASYS XLANAME DFOPSEL OSEL CLASSpstnpxla dflt cont xlt fa pstnfala dfop class natlCON MAXIDX

con std

The HEAD table tuple show the fields in bold text. It can be seen that a translator name of PSTNPXLA has been created. The DFLT action will send codes not matched in the CODE table to the FA XLASYS using XLANAME - PSTNFALA.The DFOP, (Default options), field shows that the option CLASS NATL is to apply to codes in the CODE table.The CON field shows that digits are to be consumed before passing to another translation system.The MAXIDX field shows that any digit in the range 0 to 9 is valid in the CODE table.

6

Code Table ExampleThe 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 PXCODEXLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGSpstnpxla 016287 016287 cont xlt ofc 6287fla consume 4XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAMEpstnpxla 79 79 dmod insrt 01628 xlt px pstnpxla

OSEL CONDIGS OSEL consume 0 $

The CODE table tuple shows the fields in bold text.Field XLANAME contains the translator name used in the corresponding HEAD table and links the two tables together.Fields FROMD and TOD declare the range of digits to be matched.Field XLASEL determines the action to take if the digit range is matched by the dialleddigits. 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.

7

OFC table exampleThe 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 OFCHEADXLANAME DFLTSEL DFOPSEL OSEL CLASS CON MAXIDX6287fla 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 OFCCODEXLANAME FROMD TOD XLASEL OSEL DEST OSEL MIN MAX OSEL6287fla 879 879 rte dest 1 MM 7 7 $

The entry 6287FLA specifies any digits starting 879 are to RTE to DESTination index 1 in the OFCRTE table.The next table to consider is OFCRTE. It will look like this:-

TABLE OFCRTEXLANAME RTEREF RTESEL TABNAME INDEX6287fla 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.

8

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 PXHEADXLANAME DFLTSEL XLASEL OSEL XLASYS XLANAME DFOPSEL OSEL CLASSpstnpxla dflt cont xlt fa pstnfala dfop class natlCON MAXIDX

con std

TABLE PXCODEXLANAME FROMD TOD XLASEL OSEL XLASYS XLANAME OSEL CONDIGSpstnpxla 016287 016287 cont xlt ofc 6287fla consume 4XLANAME FROMD TOD XLASEL OSEL INSRDIGS OSEL XLASYS XLANAMEpstnpxla 79 79 dmod insrt 01628 xlt px pstnpxla

OSEL CONDIGS OSEL consume 0 $

TABLE OFCHEADXLANAME DFLTSEL DFOPSEL OSEL CLASS CON MAXIDX6287fla sdflt dfop class natl nocon std

TABLE OFCCODEXLANAME FROMD TOD XLASEL OSEL DEST OSEL MIN MAX OSEL6287fla 879 879 rte dest 1 MM 7 7 $

TABLE OFCRTEXLANAME RTEREF RTESEL TABNAME INDEX6287fla 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.

9

Traver - Local number full format>TRAVER L 7895215 01628795214 BINVALID DIRECTORY NUMBER>TRAVER L 8795215 01628795214 BTABLE KSETLINERM05 00 0 02 15 1 DN Y 8795215 CLASSDEM 0 0 162 $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 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 NCOSCLASSDEM 0 0 0 NO_BAR $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCLASSDEM NXLA CXCLASS FXDEMO 0 CLASSDIGTABLE DIGCOLTUPLE NOT FOUNDDefault is RPTTABLE IBNXLA: XLANAME CXCLASSTUPLE NOT FOUNDDefault from table XLANAME:CXCLASS(NET N N 0 N NDGT N Y DOD N 68 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR68 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_4 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( MM 3 18) ( CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795214TABLE PXCODEPSTNPXLA 01628 01628 CONT ( CLASS NATL) ( XLT OFC 628FLA)(CONSUME 4) $TABLE OFCHEAD628FLA SDFLT DFOP ( MM 7 7) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 8795214TABLE OFCCODE628FLA 879 879 RTE ( DEST 1) $

Continued overleaf

10

Traver - Local number full format - continued

TABLE: OFCRTEKEY: 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 14TABLE DNFEATTUPLE NOT FOUND. . . TABLE DNATTRS. . . TUPLE NOT FOUND. . . TABLE DNGRPS. . . 162 879 5214 5214. . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$. . EXIT TABLE IBNRTEEXIT TABLE OFCRTEOriginator is not an EIN agent, therefore EIN info is not processed.Originator is not an EIN agent, therefore EIN info is not processed.


DIGIT TRANSLATION ROUTES1 LINE 1628795214 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++

11

Traver - Local number short format>traver l 8795215 795214 bTABLE KSETLINERM05 00 0 02 15 1 DN Y 8795215 CLASSDEM 0 0 162 $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPS162 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 NCOSCLASSDEM 0 0 0 NO_BAR $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCLASSDEM NXLA CXCLASS FXDEMO 0 CLASSDIGTABLE DIGCOLCLASSDIG 7 COL L 5TABLE IBNXLA: XLANAME CXCLASSTUPLE NOT FOUNDDefault from table XLANAME:CXCLASS(NET N N 0 N NDGT N Y DOD N 68 162_NPRT_4 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR68 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_4 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADPSTNPXLA DFLT CONT ( XLT PX INTERNAT) $ DFOP ( CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 795214TABLE PXCODEPSTNPXLA 7 7 (DMOD INSRT 01628 XLT PX PSTNPXLA) (CONSUME 0) $TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( MM 3 18) ( CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795214TABLE PXCODEPSTNPXLA 01628 01628 CONT ( CLASS NATL) ( XLT OFC 628FLA)(CONSUME 4) $TABLE OFCHEAD628FLA SDFLT DFOP ( MM 7 7) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 8795214TABLE OFCCODE628FLA 879 879 RTE ( DEST 1) $

Continued overleaf

12

Traver - Local number short format - continued

TABLE: OFCRTEKEY: 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 14TABLE DNFEATTUPLE NOT FOUND. . . TABLE DNATTRS. . . TUPLE NOT FOUND. . . TABLE DNGRPS. . . 162 879 5214 5214. . . (PUBLIC ( ADDRESS 0162 879 NNNN) $)$. . EXIT TABLE IBNRTEEXIT TABLE OFCRTEOriginator 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 ROUTES1 LINE 1628795214 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++>

13

14





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........







15

16


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

DFLT (temporarily)


SDFLT

Treatment

Universal Translations Datafill – Local Calls

IDD

Local

Exercise 2The 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.

17

0


nortel.com/training

Module 10

Universal Translations Datafill –National Calls

1

2


Module 10 Universal Translations Datafill – National CallsPurposeThe purpose of this section is to introduce the student to the concepts of;

> National call handling, including specific Office Codes and Freephonenumbers


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

3

4


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

FAPSTNFALA

Route to adjacent switches

DFLT (non-IDD)


SDFLT

Treatment

DFLT

Default Route for calls to therest of the country

Universal Translations Datafill – National Calls

IDD

Local

IntroductionIn 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.

5


Universal Translations – Other National Destinations

FAPSTNFALA

DFLT (non-IDD) from PX

Adjacent known codes - Route to Trunks

Freephone numbers - Route to higher tandem switch for ‘real number’ resolution

Mobile numbers - 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 codesWithin 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 adatabase 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 numbersCalls 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.

6

Adjacent known codesKnown 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 moreinformation on applicable options.

TABLE FACODEXLANAME FROMD TODpstnfala 01628 01628 rte dest 162 .........................pstnfala 01753 01753 rte dest 175 .........................

TABLE FARTEXLANAME RTEREF RTESELpstnfala 162 t ofrt 162pstnfala 175 t ofrt 175

Freephone numbersAs 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 FACODEXLANAME FROMD TODpstnfala 0800 0800 rte dest 800 .........................pstnfala 0500 0500 rte dest 500 .........................

TABLE FARTEXLANAME RTEREF RTESELpstnfala 800 s DAN800pstnfala 500 s DAN500

7

Mobile Operator numbersCalls to and from mobile operators may need extra attention specifically in relation to Codecs.

Codec Selection via TranslationsThe 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.

8

xxCODE SETCODEC selectorThe following datafill example shows the SETCODEC selector.

TABLE: FACODEXLANAME 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: CODECCALLTYPE CODEC OPTIONS---------------------------------------------------

MOBILE ( PCMA) $ $INTL ( PCMA) $ $

The fields of Table CODEC are as follows;

CALLTYPE CODEC_KEY – 8 character alphanumeric value, customer defined.

CODEC CODEC_NAMES_VECTOR – One of the following codecs;PCMU – G711mLawPCMA – G711aLawOther choices are not valid at this time.

OPTIONS CODEC_OPTION_RANGE – Currently no options defined

The following pages show example Travers of National Calls.

9

Traver - National call ( different office routing via another carrier )traver l 8795301 01753456789 bTABLE IBNLINESHOST 00 0 01 01 0 DT STN IBN 8795301 UNIGRP 0 0 162 $TABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDTABLE IBNFEATTUPLE NOT FOUNDTABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILAIN Orig Attempt TDP: no subscribed trigger.TABLE NCOSUNIGRP 0 0 0 $ $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLUNIGRP NXLA UNICT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyNCOS PRELIM XLA name is NIL. Go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA: XLANAME UNICTTUPLE NOT FOUNDDefault from table XLANAME:UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_150 NSCR 150 NPRT NONE N $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01753456789TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE FAHEADPSTNFALA DFLT RTE ( MM 3 11)( DEST 3)(CLASS NATL) $ DFOP(CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01753456789TABLE FACODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USED

Continued overleaf

10

Traver - National call ( different office routing via another carrier ) continued

TABLE: FARTEKEY: PSTNFALA 3. T OFRT 628. . TABLE OFRT. . 628 S D NTMH4B2WNAT. . S D NTMH4B2WLOC. . TRMT BUSY

+++ TRAVER: TREATMENT SET +++

DIGIT TRANSLATION ROUTES1 NTMH4B2WNAT 01753456789 ST2 NTMH4B2WLOC 01753456789 ST

TREATMENT ROUTES. TREATMENT IS: BUSY1 ENGAGED+++ TRAVER: SUCCESSFUL CALL TRACE +++

11

Traver - 0800 calltraver l 8795301 0800234567 bTABLE IBNLINESHOST 00 0 01 01 0 DT STN IBN 8795301 UNIGRP 0 0 162 $TABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDTABLE IBNFEATTUPLE NOT FOUNDTABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILAIN Orig Attempt TDP: no subscribed trigger.TABLE NCOSUNIGRP 0 0 0 $ $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLUNIGRP NXLA UNICT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyNCOS PRELIM XLA name is NIL. Go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA: XLANAME UNICTTUPLE NOT FOUNDDefault from table XLANAME:UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_150 NSCR 150 NPRT NONE N $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0800234567TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USED

Continued overleaf

12

Traver - 0800 call - continued

TABLE FAHEADPSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0800234567TABLE FACODEPSTNFALA 0800 0800 RTE ( MM 10 10) ( DEST 3)$TABLE: FARTEKEY: PSTNFALA 3. T OFRT 628. . TABLE OFRT. . 628 S D NTMH4B2WNAT. . S D NTMH4B2WLOC. . TRMT BUSY

+++ TRAVER: TREATMENT SET +++

DIGIT TRANSLATION ROUTES1 NTMH4B2WNAT 0800234567 ST2 NTMH4B2WLOC 0800234567 ST

TREATMENT ROUTES. TREATMENT IS: BUSY1 ENGAGED+++ TRAVER: SUCCESSFUL CALL TRACE +++

13

Traver – Mobile network call>traver l 6105600 007345678901 bTABLE KSETLINECICM 07 0 00 06 1 DN Y 6105600 EMEA_G6 0 0 207 (3WC) (PRK) (CFX) $ MBSTABLE DNATTRS207 610 5600

(PUBLIC ( NAME TIDS_LINE) $)$ $TABLE DNGRPS207 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 NCOSEMEA_G6 0 0 0 $ $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLEMEA_G6 NXLA EMG6CT EMG6FET 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyTABLE IBNXLA: XLANAME EMG6CTEMG6CT 0 NET N N 1 N NDGT Y N DOD N 2 CS_NPRT CS_NIL NONE $TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR2 IBN NONE NT 0 0 NILSFC 0 PX PXDEMO NIL 00 CS_NPRT CS_NIL $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLANCS_NPRT NSCR 101 NPRT NONE N $ $TABLE RATEAREACS_NIL NLCA NIL NILLATA $

14

Traver – Mobile network call continuedTABLE PXHEADPXDEMO DFLT CONT ( CLASS NATL) ( CONSUME 0) ( XLT FA FADEMO)$ NODFOP CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 07745678901TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE FAHEADFADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 07745678901TABLE FACODEFADEMO 07 07 RTE ( MM 11 11) ( DEST 700) ( CLASS NATL) ( SETCODEC MOBILE)$TABLE: FARTEKEY: FADEMO 700. S UKPVGEXIT TABLE FARTEOriginator is not an EIN agent, therefore EIN info is not processed.


DIGIT TRANSLATION ROUTES

1 UKPVG 07745678901 ST SETCODEC option encountered. Codec Requested: PCMA

TREATMENT ROUTES. TREATMENT IS: GNCT1 UNOBT SETCODEC option encountered. Codec Requested: PCMA


>

15





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........

Naming ConventionsThis 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.





16

17


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

FAPSTNFALA

Routes to specific destinations

DFLT (non-IDD)


SDFLT

Treatment

DFLT

Default Route for calls to rest of the country

Universal Translations Datafill – National Calls

IDD

Local

Exercise – National CallsThe 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 DAN800Mobile Operator calls 07xxxxxxxxx to route to the CLLI MOBILEAll other national numbers are to route to OFRT (For CLLI DANNAT)

18

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.

19

0


nortel.com/training

Module 11

Time Of Day Routing

1

2


Module 11 Time Of Day Routing


concepts of;

> The Time of Day Route System feature.


> Describe the purpose of the Time of Day system.

> List the tables used by Time of Day system.

> Complete an exercise using Time of Day Routing.

3

4

IntroductionTime 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 OVRxusing the conditional selector CND TOD.

Table IBNRTE, 2, 3,4. Ibn RouteTable OFRT, 2,3,4. Office RouteTable OVR0 – OVR89 Overseas Routing

The Time of Day tables allows changes to routing choices during specific times of the day, week or year. This may be for route changes to occur at specific times to overcome congestion during busy periods. Once built, the changes will occur automatically unless overridden. The Time of Day system uses five tables to establish the times when changes are to occur, they are:-

Table DAYTYPES Type of DayTable DAYOWEEK Day of WeekTable DAYOYEAR Day of YearTable TODHEAD Time of Day HeadTable TIMEODAY Time of Day

These tables will be discussed first.

5


Table DAYTYPESTable DAYTYPES

DAYTYPE---------------HOLIDAYWEEKENDWEEKDAYSPARE1SPARE2SPARE3SPARE4SPARE5MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAY

Table DAYTYPESThe 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.

6


Table TODHEAD

Table TODHEADTODNAME TODTYPE TIME DAYTYPESdemotod rte 0 (holiday)(weekday)(weekend)

(spare1) (spare2) (spare3) (xmas)

Table TODHEADIn table TODHEAD, the TODTYPE field is RTE (Route), and a field specifies the default action. An example is given above.

The fields are:-TODNAME Time of Day Name. Enter a 1 to 8 character name assigned as the time of day

system name. This name is used in the Route tables with the Conditional selector CND TOD.

TODTYPE Time of day type. Enter RTE to indicate that this is a ROUTE time of day system.

TIME Times. Enter the Time element alphanumeric ( 1 to 14 ) characters from which applies if there are no instructions for the current time and daytype in table TIMEODAY.

DAYTYPES Types of day. Enter the daytypes on which changes are to occur. Up to 32 different daytypes may be listed here. It is advised that some extra daytypes are included in the list to allow for future growth or changes. The daytypes SPARE1, SPARE2 etc. are often used for this purpose. N.B. Existing DAYTYPE names can be changed, however, the CHANGE command cannot be used to add new daytypes not previously included in the list. Remember! Daytypes must be defined in Table DAYTYPES first.

7


Table DAYOWEEK

Table DAYOWEEKTODNAME WEEKDAY DAYTYPEdemotod mon weekdaydemotod tue weekdaydemotod wed weekdaydemotod thu weekdaydemotod fri weekdaydemotod sat weekenddemotod sun weekend

Table DAYOWEEKTable Day of Week (DAYOWEEK) is used to associate “real” days with the DAYTYPES defined in table DAYTYPES. The entries in this table are specific to a Time of Day system which means that a “real” Monday could be known as different DAYTYPES in different Time of Day systems. An example is given below.

In this example, the “real” day, MONDAY (MON), is associated with the daytype weekday. “REAL” Friday (FRI), will be known as HOLIDAY and SATURDAY (SAT) will be known as WEEKEND, but only in the DEMOTOD time of day system. The fields are:-

TODNAME Time of day name.Enter the 1 to 8 character name assigned as the time of day system name to which entries in this table are linked.

DAY Weekday. Enter the “real” name of a day of the week. Only 3 characters are used in this field e.g. MON,TUE,WED,THU,FRI,SAT or SUN.

DAYTYPE Type of Day. Enter the 1to 8 character name assigned as a DAYTYPE which the “real” day will be known as in the Time of Day system.

8


Table DAYOYEAR

Table DAYOEARTODNAME MONTH DAY DAYTYPEdemotod dec 25 xmasdemotod jan 01 holiday

Table DAYOYEARThe 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 aWeekday 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.

9


Table TIMEODAY

Table TIMEODAYTODNAME DAYTYPE TIME DATAdemotod weekday 00 00 rte 1demotod weekday 08 00 rte 2demotod weekday 12 00 rte 1

Table TIMEODAYThe Time of Day (TIMODAY) table defines the results for a given time and day. The result is the time element number that applies on a specific time and day.The time element is used in the route tables with the conditional selector CND TOD. If the condition applies i.e. it is the current time and day specified, the condition will be applied. If it is not, the condition is ignored and normal route selection continues. A day covers a 24 hour period between 00:00 and 23:59. A maximum of 16 changes (0-9, A-F) can be specified in one 24 hour period i.e. a day. To illustrate this, consider a customer who wants to implement some route changes during the daytype HOLIDAY.The Time of Day Routing System is to apply route changes between 00:00 to 08:00, 08:00 to 12:00 and 12:00 to 23:59. The changes can be represented in a chart, an example is given below.00:00 08:00 12:00 23:59< Time Rte 1 >< Time Rte 2 >< Time Rte 1 >

Table TIMEODAY would be datafilled as per the above slide to match the time chart aboveIn 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.

10


Routing Table Conditional Selector -TODTABLE IBNRTERTE 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




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.

11


Time of Day Route TablesTime of Day Route TablesTable DAYTYPESTable DAYTYPES

DAYTYPES

MONDAYWEEKENDWEEKDAYHOLIDAYXMAS

Table DAYOWEEKTable DAYOWEEK

TODNAME DAY DAYTYPE

DEMOTOD MON WEEKDAYDEMOTOD FRI HOLIDAYDEMOTOD SAT WEEKEND

Table DAYOYEARTable DAYOYEARTODNAME MONTH DAY DAYTYPE

DEMOTOD DEC 25 XMAS

Table TODHEADTable TODHEADTODHEAD TODTYPE TIMES DAYTYPES

DEMOTOD RTE 0 (WEEKDAY) (WEEKEND)(XMAS)(HOLIDAY)(SPARE1)

Table TIMEODAYTable TIMEODAYTODNAME DAYTYPE HOUR MIN TODTYPE TIME

DEMOTOD HOLIDAY 00 00 RTE 1DEMOTOD HOLIDAY 08 00 RTE 2DEMOTOD HOLIDAY 12 00 RTE 1

00:00 08:00 12:00 23:59

holiday

Time Rte 1Time Rte 1 Time Rte 2Time Rte 2 Time Rte 1Time Rte 1

Table IBNRTETable IBNRTERTE IBNRTSEL CNDSELRTE IBNRTSEL CNDSEL TODNAMETODNAME TIMES RTETYPE RTEREFTIMES RTETYPE RTEREF201 CND TOD DEMOTOD 2 ST 301

IBNRTSEL CNDSEL TODNAME TIMES RTETYPE SKIPNUMCND TOD DEMOTOD 1 SK 1




12

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 helpTDQ: 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 displayHELP: This Display.ALL: Current results for all TODNAMES.NAME: Current result for specified TODNAME.LIST: List of all TIMEODAY entries (time ordered) with some extra information displayed for each.TRAPS: Gives the number of traps since the last non-warm or manual restart.TEST: Gives the ALL display after making a few tests.THRESHOLDS: Used to reset the TRAP thresholds for the SYSTEM, FEATURES,

TODNAMES. (If these thresholds are exceeded, the system commits suicide.)DISABLE [todname]: Disable the whole TOD system, or just for the given TODNAME. TODRESET: [todname]: Restart the whole TOD system, or just for the given TODNAME. OVERRIDE: Override the scheduled result for a given TODNAME with a manually specified result. FEATURE: Turn the specified feature on, off, or off permanently (i.e. not enabled by restarts.) (Manually Disable a feature causing problems/ traps or enable a Disabled Feature.)

13

Datafill OrderIt 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

14

15





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........







16


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

FAPSTNFALA


DFLT (non-IDD)


SDFLT

Treatment

DFLT


Universal Translations Datafill –Time-Of-Day Routing

IDD

Local

Time Of DayRouting Tables

Route ARoute B

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.

17


0


nortel.com/training

Module 12

Universal Translations – Service Calls

1

2


Module 12 Universal Translations –Service CallsPurposeThe purpose of this section is to introduce the student to the

concepts of; > Handling of Service calls, i.e. Operator and Emergency calls.


> Describe the call flow process used in Universal Translations> Datafill an exercise to handle Service Calls, using the

translation selectors DMOD, CONT and RTE with applicable OSEL options

> Traver the results of their datafill> Explain the results of the travers

3

4


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

FAPSTNFALA


DFLT (non-IDD)


SDFLT

Treatment

DFLT


Universal Translations Datafill –Service Calls

IDD

Local


Route ARoute B

FAPSTNFALA

PXSRVCPXLA

SDFLT

Treatment

Service

IntroductionThis 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 datafillprocedures to accomplish the 1st scenario.Datafill example - Emergency and Operator callsThe 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.

5

Traver examplesThe 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 amaxlaidpoints 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.

6


7

Traver - 999 calltraver l 8795301 999 bTABLE IBNLINESHOST 00 0 01 01 0 DT STN IBN 8795301 UNIGRP 0 0 162 $TABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDTABLE IBNFEATTUPLE NOT FOUNDTABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILAIN Orig Attempt TDP: no subscribed trigger.TABLE NCOSUNIGRP 0 0 0 $ $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLUNIGRP NXLA UNICT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyNCOS PRELIM XLA name is NIL. Go to next XLA name.CUST PRELIM XLA name is NIL. Go to next XLA name.TABLE IBNXLA: XLANAME UNICTTUPLE NOT FOUNDDefault from table XLANAME:UNICT (NET N N 0 N NDGT N Y DOD N 150 162_NPRT_150 NLCA_NILLA_1 NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR150 IBN NONE NT 0 0 NILSFC 0 PX PSTNPXLA NIL 00 162_NPRT_150 NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_150 NSCR 150 NPRT NONE N $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $

8

TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 999TABLE PXCODEPSTNPXLA 999 999 CONT ( XLT PX SRVCPXLA)$TABLE PXHEADSRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 999TABLE PXCODESRVCPXLA 999 999 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$TABLE FAHEADPSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 99912TABLE FACODEPSTNFALA 99912 99912 RTE ( MM 5 5) ( DEST 1) ( CLASS EMRG) (CALLCTRL CALLED)(AMAXLAID 999AMA)$TABLE: FARTEKEY: PSTNFALA 1. T OFRT 999. . TABLE OFRT. . 999 S D NTMH4B2WEMG. . S D NTMH4B2WLOC. . TRMT BUSY+++ TRAVER: TREATMENT SET +++DIGIT TRANSLATION ROUTES1 NTMH4B2WEMG 99912 ST2 NTMH4B2WLOC 99912 STTREATMENT ROUTES. TREATMENT IS: BUSY1 ENGAGED+++ TRAVER: SUCCESSFUL CALL TRACE +++

9


10

TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 112TABLE PXCODEPSTNPXLA 112 112 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$TABLE PXHEADSRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 112TABLE PXCODESRVCPXLA 112 112 DMOD ( DEL 3) ( INSRT 99912) ( XLT FA PSTNFALA)$TABLE FAHEADPSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 99912TABLE FACODEPSTNFALA 99912 99912 RTE ( MM 5 5) ( DEST 1) ( CLASS EMRG) (CALLCTRL CALLED)(AMAXLAID 999AMA)$TABLE: FARTEKEY: PSTNFALA 1. T OFRT 999. . TABLE OFRT. . 999 S D NTMH4B2WEMG. . S D NTMH4B2WLOC. . TRMT BUSYDIGIT TRANSLATION ROUTES1 NTMH4B2WEMG 99912 ST2 NTMH4B2WLOC 99912 ST

11


12

TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 100TABLE PXCODEPSTNPXLA 100 100 CONT ( XLT PX SRVCPXLA)$TABLE PXHEADSRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 100TABLE PXCODESRVCPXLA 100 100 DMOD ( INSRT 12) ( AFTER 3) ( XLT FA PSTNFALA)$TABLE FAHEADPSTNFALA DFLT RTE ( MM 3 11) ( DEST 3)$ DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 10012TABLE FACODEPSTNFALA 10012 10012 RTE ( MM 5 5) ( DEST 1)$TABLE: FARTEKEY: PSTNFALA 1. T OFRT 999. . TABLE OFRT. . 999 S D NTMH4B2WEMG. . S D NTMH4B2WLOC. . TRMT BUSYDIGIT TRANSLATION ROUTES1 NTMH4B2WEMG 10012 ST2 NTMH4B2WLOC 10012 ST

13


14

TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 151TABLE PXCODEPSTNPXLA 151 151 CONT ( XLT PX SRVCPXLA) ( CONSUME 0)$TABLE PXHEADSRVCPXLA SDFLT DFOP ( CLASS NATL)$ NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 151TABLE PXCODESRVCPXLA 151 151 DMOD ( DEL 3) ( INSRT 01628795616) ( XLT PX PSTNPXLA)$TABLE PXHEADPSTNPXLA DFLT CONT ( XLT FA PSTNFALA)$ DFOP ( CLASS NATL)$ CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795616TABLE PXCODEPSTNPXLA 0162879 0162879 CONT ( XLT OFC 6287FLA) ( CONSUME 7)$TABLE OFCHEAD6287FLA DFLT RTE ( MM 4 4) ( DEST 1) ( CLASS NATL)$ DFOP ( CLASS NATL)$ NOCONSTDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 5616TABLE OFCCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE: OFCRTEKEY: 6287FLA 1. T IBNRTE 79. . TABLE IBNRTE. . 79 DN 162 879 N 0. . EXIT TABLE IBNRTEEXIT TABLE OFCRTE+++ TRAVER: SUCCESSFUL CALL TRACE +++DIGIT TRANSLATION ROUTES1 LINE 1628795616 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++

15


16





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........







17

18

Service Calls - ExerciseThe 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.

19


PXPSTNPXLA

CTPSTNCTLA



OFC628FALA

from table LINEATTR

FAPSTNFALA

Route to adjacent switches

DFLT (non-IDD)


SDFLT

Treatment

DFLT


Universal Translations Datafill –Service Calls

IDD

Local


Route ARoute B

FAPSTNFALA

PXSRVCPXLA

SDFLT

Treatment

Service

20

0


nortel.com/training

Module 13

Universal Translations – Indirect Access

1

2


Module 13 Universal Translations –Indirect AccessPurposeThe 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.

3

4

The Purpose of Indirect AccessIndirect 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 operator’s 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.

5


Call Completion Scenarios

Call routedto B only ifrequested

Transitswitch

Terminatingswitch

Network ADefault network, e.g. PTT

Callorigination

Calltermination

Calltermination

Callorigination

MediaGateway

CS2000 CS2000

Network BAlternative national operator

using IP or ATM packet backbone

Requestedingress withauthorisationchecks

Default ingresstypically for calls

terminatingwithin network B

Egress for callsterminating to network A lines

MediaGateway

MediaGateway

MediaGateway

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 operator’s 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.

6

Simple Scenarios: Indirect Access Involving One AOFor 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 signallingover 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.

7


Different types of Indirect Access

Access method Table Used

CLI Checked?

Initialinformation

provided2nd

tone?

Furtherinformation

provided

Mainadvantage

Single-stage

Carrierselectionscreening

Accountcoderequired

DNSCRN YesAccess code+ destination

numberNo N/A

Speed/conveniencefor voice calls;support for data calls

Speed/conveniencefor voice calls;support for data calls

MONA viaambiguoustranslations

CLI_basedaccess

Authcodeaccess

DNSCRN

DNSCRN

DNSCRN

Yes

Yes

Yes

Carrier ID+ destination

number

Access code

Access code

Access code

No

Yes

Yes

Yes

N/A

Account code+ destination

number

Destinationnumber [1]

Authorisationcode +

destinationnumber [2]

AUTHCDE No

Account code billingfor business customers

Confirmation of accessto alternative network

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 AccessCS2000 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 caller’s Calling Line Identification (CLI) or on the basis of an explicitly dialled authorisation code (authcode).

Which items of information have to be provided by the caller.How the caller is prompted to provide information.

A caller is prompted to provide additional information by the playing of a tone. For TDM-side access, tones are applied in-band to the incoming TDM-side bearer channel by the originating media gateway.Note: In ISN09, it is not possible for indirect access services to prompt the user for additional information by means of announcements provided by a media server.In both cases, additional information provided by a caller when prompted is collected as in-band DTMF digits. These are collected by the originating media gateway (or via a TDM-side looparound), and H.248 is then used to pass the information on to the GWC.

Note: The types of screening described above can be complemented by standard COS screening on a trunk group basis, as follows:

TRKOPTS option COS can specify a COS value (0-1023) for a trunk group.Table COSBLK specifies combinations of orginating trunk group COS and terminating

trunk group COS for which call completion will be permitted.

8

Indirect Access Screening OptionsThree 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 accessSingle-stage access is so called because the calling party provides theaccess 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 requiredWith this method, the DNSCRN table entry for the caller’s CLI specifies that an account code must be provided as well as the destinationnumber.

Meridian Off-Net Access (MONA) via ambiguous translationsWith 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 theoriginating 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.

9


Indirect AccessCLI based – Single stage

Table LINEATTR

PXCODE

XLASYS FROMD TOD XLASEL FTR XLASYS XLANAMEcs2kpx 0901 0901 featinfo validate px2 cs2kpx

VALDATOPSUBSCRN – Check for CLI in DNSCRN

Pass screening –Continue translating

CLIscreening

check

CLI Triggers in Universal TranslationsThe screening function is triggered by the XLASEL selector FEATINFO in the universal translation tables.Enter FEATINFO and datafill its sub-option VALIDATE to trigger the screening function.Selector FEATINFO makes use of table DNSCRN to store information against DNs, which is used during call processing to determine how to proceed with the call. As shown in the above example the FTR option of VALIDATE enables screening via sub-options.For CLI screening to occur the SUBSCRN sub-option is used.CLI screening will be dealt with first using the FEATINFO/VALIDATE/SUBSCRN sub-option.There are other Sub-Options available for the VALIDATE option, which include;BCSCRN identifies Bearer Capability.CLDTOCLG copies digits from the calling to the called digit stream.CLISERV The CLISERV field indicates the name of the CLI Screening Services index

in Table CLISERV.CUSTMOD alters the NCOS and Customer Group to a new value for a given DN

based on the CUSTINFO attributes in table DNSCRN.For this module however we will only be dealing with the two CLI related options;FEATINFO/VALIDATE – SUBSCRNFEATINFO/VALIDATE - CLISERV.

10


FEATINFO option VALIDATE - SUBSCRN

xxCODE

XLASYS FROMD TOD XLASEL FTR XLASYS XLANAMEcs2kpx 0901 0901 featinfo validate px2 cs2kpx

VALDATOP SUBSCTYP WHITLIST CHKUNPD CHBLKCL CHKCCRsubscrn general N N Y N

SUBSCTYP$

VALDATOP$

PFDIGS MINDIGS MAXDIGS0 11 11

Continue translating

Table DNSCRN

DN ATTROPTS01182345678 (UNPAID) (BLCKCALL) $

FEATINFO option VALIDATE, Sub-option SUBSCRNSUBSCRN 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 refinementsWHITLIST, CHKBLKCL, CHKUNPD, and CHKCCR.

WHITLIST Y or N Whether it is a white or Black list. Enter Y (yes) to indicate that the subscriber’s 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 CLI’s 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.

11

CHKCCR Y or N Check cumulative call restriction. Enter Y to check the subscriber’s cumulative charge limit. Otherwise, enter N.

PFDIGS 0 to 24 Prefix digits. Enter the number of prefix digits present at this point in the call. Prefix digits are not used to index any further translation tables and are not outpulsed, but they remain stored in call detail records (CDR).

MINDIGS 0 to 30 Minimum digits. Enter the minimum number of digits expected. This value includes the digits used to index the current tuple and must also include the prefix digits specified in the current tuple.

MAXDIGS 0 to 30 Maximum digits. Enter the maximum number of digits expected. This value includes the digits used to index the current tuple and andmust also include the prefix digits specified in the current tuple.

TABREF see subfields Table reference. This field consists of subfields XLASYS and XLANAME.

White List v Black list.A White List is a CLI screening list where the CLI MUST be entered or the call will fail i.e. the CLI must match an entry in Table DNSCRN for the call processing to continue. With this feature a call can subsequently be failed or other actions taken as a result of further datafill, if required.A Black List is a CLI screening list where a CLI that matches will cause the call processing to stop i.e. the call will Fail. So a CLI that does NOT match will continue call processing through translations.

12

Table DNSCRNThe fields within this table are as followsDN ATTROPTS

Within table DNSCRN, numerous attributes can be used as a screening basis.Some are listed below;UNPAID Check unpaid. Enter Y to check if the subscribers bills are paid. For

other conditions, enter N.BLCKCALL indicates that the DN cannot make or receive calls.CLISERV allows the use of CLI service screening and CLI based routing

An example tuple is shown below.TABLE: DNSCRNDN ATTROPTS----------------------------------------------------------------------------1628795352 ( UNPAID ) ( BLCKCALL ) $

In this datafill example the specified CLI has not paid their bill and are blocked from making or receiving calls.

Use of Multiple DNSCRN TablesIt 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 thetype 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 beforescreening

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.

13


FEATINFO option VALIDATE - CLISERV

xxCODE

XLASYS FROMD TOD XLASEL FTR XLASYS XLANAMEcs2kfa 0901 0901 featinfo validate fa2 cs2kfa

fa scrnfail

VALDATOP SUBSCTYP WHITLIST CHKUNPD CHBLKCL CHKCCRSUBSCRN GENERAL N N Y N

SUBSCTYP$

VALDATOP SERVNAMECLISERV CLIDEMO

VALDATOP$

PFDIGS MINDIGS MAXDIGS0 11 11

Table CLISERV

SERVNAME SERVNUM SERVOPTSCLIDEMO 2 ( PARTIAL ) ( FAILAMA ) ( SERVAMA ) ( FAILRTE FA SCRNFAIL ) $

Continue translating

Fail Screening

FEATINFO option VALIDATE, Sub-option CLISERVThe 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 indexSERVNUM 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 CLI’s 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.

14

Table CLISERV SERVOPTS continued.

SERVSCRN This option provides the ability to fail screening if the CLI has not subscribed to the CLI Screening service. In order for screening to succeed, the CLI matched in table DNSCRN must have the CLISERV option present indicating the CLI Screening profile, PROFIDX, to be used. A SERVNAME listed against the PROFIDX in table CLISRVPF must also match the SERVNAME provided in the CLISERV option of the FEATINFO VALIDATE selector encountered in Universal translations.

DNSCRMAP This option enables screening based on the NOA parameter.

CLICNTL This option enables the use of table CLICNTL to select the address to screen and the address to capture in the AMA billing record.

ACCTREQ ACCTREQ is request for account code collection and validation. This field specifies that a CLI must collect cost center code (CCC) digits. Enter data in subfields ACCTLEN, ACCTTONE and ACCTVAL.

15

TRAVER to a CLI Screened number with CLI listed in DNSCRN.>traver l 8885000 0898123456 bTABLE KSETLINERM05 00 0 02 17 1 DN Y 8885000 BOB 0 0 111 (LNR) $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDOriginator is not an EIN agent, therefore EIN info is not processed.TABLE NCOSBOB 0 0 0 CLASS $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLBOB NXLA BOBCT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyTABLE IBNXLA: XLANAME BOBCTTUPLE NOT FOUNDDefault from table XLANAME:BOBCT(NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $)$ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTRDANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA NIL 00 162_NPRT_4NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADBOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE FAHEADBOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11)(CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE FACODEBOBFALA 0898 0898 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y Y N N) $)$ 0 10 10 FA VALIDXLAPLEASE ENTER CLI DIGITS:>1118885000TABLE DNSCRN. 1118885000 $

16

TABLE FAHEADVALIDXLA SDFLT NODFOP NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 123456TABLE FACODEVALIDXLA 1 1 RTE ( DEST 5)$TABLE: FARTEKEY: VALIDXLA 5. S NTEDILONBTUPEXIT TABLE FARTEOriginator 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 ROUTES1 NTEDILONBTUP 0898123456 STTREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT+++ TRAVER: SUCCESSFUL CALL TRACE +++

17

TRAVER of a call with a CLI that does not exist in Table DNSCRN>traver l 8885555 0898123456 bTABLE KSETLINERM05 00 0 02 18 1 DN Y 8885555 BOB 0 0 111 (LNR) $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDOriginator is not an EIN agent, therefore EIN info is not processed.TABLE NCOSBOB 0 0 0 CLASS $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLBOB NXLA BOBCT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyTABLE IBNXLA: XLANAME BOBCTTUPLE NOT FOUNDDefault from table XLANAME:BOBCT(NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $)$ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTRDANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA NIL 00 162_NPRT_4NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADBOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE FAHEADBOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11)(CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE FACODEBOBFALA 0898 0898 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y Y N N) $)$ 0 10 10 FA VALIDXLAPLEASE ENTER CLI DIGITS:>1234567890TABLE DNSCRN. No match found

18

. Screening failed+++ TRAVER: TREATMENT SET +++TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLEDTREATMENT ROUTES. TREATMENT IS: CNAD1 UKREORDER+++ TRAVER: SUCCESSFUL CALL TRACE +++

19

TRAVER of a call from a phone number with an UNPAID bill.>traver l 8885000 0898123456 bTABLE KSETLINERM05 00 0 02 17 1 DN Y 8885000 BOB 0 0 111 (LNR) $ MBSTABLE DNATTRSTUPLE NOT FOUNDTABLE DNGRPSTUPLE NOT FOUNDOriginator is not an EIN agent, therefore EIN info is not processed.TABLE NCOSBOB 0 0 0 CLASS $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT,AND DIGCOLBOB NXLA BOBCT NXLA 0 NDGTTABLE DIGCOLNDGT specified: digits collected individuallyTABLE IBNXLA: XLANAME BOBCTTUPLE NOT FOUNDDefault from table XLANAME:BOBCT(NET N N 0 N NDGT N Y DOD N DANNY 162_NPRT_4 NLCA_NILLA_1 NONE $)$ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTRDANNY IBN NONE NT 0 0 NILSFC 0 PX BOBPXLA NIL 00 162_NPRT_4NLCA_NILLA_1 $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLAN162_NPRT_4 NSCR 162 NPRT NONE N $ $TABLE RATEAREANLCA_NILLA_1 NLCA NIL NILLATA $TABLE PXHEADBOBPXLA DFLT CONT ( CONSUME 0) ( XLT FA BOBFALA)$ NODFOP CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE FAHEADBOBFALA DFLT RTE ( MM 10 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 10 11)(CLASS NATL) $ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 0898123456TABLE FACODEBOBFALA 0898 0898 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y Y N N) $)$ 0 10 10 FA VALIDXLAPLEASE ENTER CLI DIGITS:>1118885000TABLE DNSCRN. 1118885000 (UNPAID )

20

. CLI unpaid

. Screening failed+++ TRAVER: TREATMENT SET +++TABLE TMTCNTL SUB OFFTREAT NOT DATAFILLEDTREATMENT ROUTES. TREATMENT IS: CNAD1 UKREORDER+++ TRAVER: SUCCESSFUL CALL TRACE +++

21

TRAVER of a successful call to CLI screened number using CLISERV option.>traver tr ukpvg 01252855111 bTABLE TRKGRPUKPVG 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 CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP ETSIGRPINAP Origination Attempt TDP: no subscribed trigger.TABLE NCOSCS2KCUST 0 0 0 NO_RST $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCS2KCUST NXLA CXDEMO NXLA 0 CSDIGTABLE DIGCOLCSDIG 0 RPTINAP Info Collected TDP: no subscribed trigger.TABLE IBNXLA: XLANAME CXDEMOTUPLE NOT FOUNDDefault from table XLANAME:CXDEMO

(NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLANCS_NPRT NSCR 101 NPRT NONE N $ $TABLE RATEAREACS_NIL NLCA NIL NILLATA $TABLE PXHEADCS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS INTL)$ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USED

22

TABLE FAHEADFADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE FACODEFADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) ( CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMOPLEASE ENTER CLI DIGITS:>1312345000TABLE CLISERV. CLIDEMO 1 ( PARTIAL ) ( FAILRTE FA SCRNFAIL) ( FAILAMA ) ( SERVAMA )$TABLE DNSCRN. 1312345 $TABLE FAHEADFADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE FA2CODEDefault from head table usedTABLE: FARTEKEY: FADEMO 5. S PBX_SITE_AEXIT TABLE FARTETABLE TRIGGRPETSIGRP INFOANAL. GENTRIG ( CDPN ETSITRIG)$ NILTrigger INAPV8 GENTRIG is applicable to office.INAP Info Analyzed TDP: trigger criteria not met.INAP Route Select Failure TDP: no subscribed trigger.



1 PBX_SITE_A 01252855111 ST

TREATMENT ROUTES. TREATMENT IS: GNCT1 UNOBT


23

TRAVER of an un successful call to CLI screened number using CLISERV option.>traver tr ukpvg 01252855111 bTABLE TRKGRPUKPVG 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 CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP ETSIGRPINAP Origination Attempt TDP: no subscribed trigger.TABLE NCOSCS2KCUST 0 0 0 NO_RST $TABLE CUSTHEAD: CUSTGRP, PRELIMXLA, CUSTXLA, FEATXLA, VACTRMT, AND DIGCOLCS2KCUST NXLA CXDEMO NXLA 0 CSDIGTABLE DIGCOLCSDIG 0 RPTINAP Info Collected TDP: no subscribed trigger.TABLE IBNXLA: XLANAME CXDEMOTUPLE NOT FOUNDDefault from table XLANAME:CXDEMO

(NET N N 0 N NDGT N Y DOD N 1 CS_NPRT CS_NIL NONE $) $ 9TABLE DIGCOLNDGT specified: digits collected individuallyTABLE LINEATTR1 IBN NONE NT 0 0 NILSFC 0 PX CS2KPX NIL 00 CS_NPRT CS_NIL $LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE XLAPLANCS_NPRT NSCR 101 NPRT NONE N $ $TABLE RATEAREACS_NIL NLCA NIL NILLATA $TABLE PXHEADCS2KPX DFLT CONT ( MM 3 11) ( CONSUME 0) ( XLT FA FADEMO)$ DFOP ( MM 7 14) ( CLASS INTL)$ CON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE PXCODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USED

24

TABLE FAHEADFADEMO DFLT RTE ( MM 11 11) ( DEST 5) ( CLASS NATL)$ DFOP ( MM 5 11) ( CLASS NATL)$ NOCON 9THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE FACODEFADEMO 01252855 01252855 FEATINFO VALIDATE ( SUBSCRN ( GENERAL Y N N N)$) ( CLISERV CLIDEMO)$ 0 11 11 FA2 FADEMOPLEASE ENTER CLI DIGITS:>1343214000TABLE CLISERV. CLIDEMO 1 ( PARTIAL ) ( FAILRTE FA SCRNFAIL) ( FAILAMA ) ( SERVAMA )$TABLE DNSCRN. No match found. Screening failedTABLE FAHEADSCRNFAIL DFLT RTE ( DEST 1)$ NODFOP NOCON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01252855111TABLE FACODETUPLE NOT FOUNDDEFAULT FROM HEAD TABLE USEDTABLE: FARTEKEY: SCRNFAIL 1. S CLI_FAIL_ANNCEXIT TABLE FARTETABLE TRIGGRPETSIGRP INFOANAL. GENTRIG ( CDPN ETSITRIG)$ NILTrigger INAPV8 GENTRIG is applicable to office.INAP Info Analyzed TDP: trigger criteria not met.INAP Route Select Failure TDP: no subscribed trigger.



1 CLI_FAIL_ANNC

TREATMENT ROUTES. TREATMENT IS: GNCT1 UNOBT


>

25

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 TaskYour 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 = NTest 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?

26

27

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 TaskYour task is to screen calls to a specific number range – 01252855xxx, based on their CLI.Each team will screen for the specified partial CLI’s below;

Team 1 – 1312221Team 2 – 1312222Team 3 – 1312223Team 4 – 1312224Team 5 – 1312225Team 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.

28


Indirect Access – Account Code Required

Table DNSCRN

DN ATTROPTS01182005000 (ACCTREQ 4 DT N ) $

Account Code Required

Account Code length

Account Code Prompt Tone Type

Account Code validation

Single-stage CLI-based access - Account code requiredWith this method, the DNSCRN table entry for the caller’s CLI specifies that an account code must be provided as well as the destination number.

Table DNSCRNWithin 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 ).

29


Indirect Access – Meridian Off-Net Access (MONA) via ambiguous translations

Table DNINVUniversalsroutingdecision

Pass Screening?Continue translating

Table AUTHPART

Table AUTHCDE

Table DIALPLAN

Table DNROUTE

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 caller’s 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.

30

Authcode Checking via Table AUTHCDEDigit CollectionAuthcode 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:

DESTONLYOnly destination digits are collected

AUTHONLY FIRSTAuthcode digits are collected first, optionally followed by an account code and/or security digits, and finally the destination digits.

AUTHONLY LASTDestination digits are collected first, followed by authcode digits, which are in turn optionally followed by an account code and/or security digits.

31

Table Dial Plan

Table DIALPLAN example

DIALPLAN CUTHRUTY ORDER AUTHPRMT DESTPRMT ACCTPRMTDEFAULT AUTHONLY FIRST CDT SDT N OPTIONS

$

Order – Authcode FIRST or LAST Type of tone prompt

32

The Screening ProcessFor 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 originatingexchange. This provides a secondary level of checking to prevent fraud. If theAUTHCDE table entry for the authorisation code provided (see below) also specifiesan NNGP code, the call attempt will be rejected if this does not match the NNGP inthe IAM or if the IAM contains no NNGP.A single-digit Inter-Administration Accounting Single Digit (IAASD) codeindicating the interconnect tariff band that applies to the call attempt. This is notverified 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 intable 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 screeningThe 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 numberThe HOTLINE option and the HOTLN_NUM field can be used to specify a hotline number for automatic connection.

33

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

CALLBLKAllows calls to be blocked in spite of successful screening (e.g. if the subscriber’s 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 screeningA customer group may be assigned (and thus restricted) to a particular region.

Restricted usage screeningThe Time Of Day (TOD) routing feature may be used to implement call restrictions based on date, day or time of day.

34


Indirect Access – MONA via ambiguous translations example

Table DNROUTEAREACODE OFCCODE STNCODE DNRESULT

207 620 6000 FEAT MONA DEFAULT $

Table DIALPLANDIALPLAN CUTHRUTY OPTIONSDEFAULT AUTHONLY FIRST CDT SDT N $

Table AUTHPARTPARTNM INFOCS2KAUTH IBN 4 100

Table AUTHCDEAUTHPART AUTHCODE INFOCS2KAUTH 1234 IBN 0 N $ SW (HOTLINE 01618880000) $

Code Authorised – dial this number automatically

The above example shows the table flow of a MONA call.The following pages describe the datafill.

35

To invoke Indirect Access through MONA, the following tables require datafill;They are listed in datafill order.Table AUTHPARTTable AUTHCDETable CUSTHEADTable DIALPLANTable DNROUTE

Table AUTHPARTThis table defines the Authorisation Partition name and is referenced from CUSTHEAD and AUTHCDE.

Table AUTHCDEThis 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 CUSTHEADThis 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 DIALPLANSpecifies the cut-through access type.

Table DNROUTEThis table defines software Directory Numbers, i.e, numbers that do not relate to actual lines but to software features such as UCD, ACD etc.

36


Indirect Access – MONA via ambiguous translations - continued







Table AUTHPARTTable 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 AUTHPARTPARTNM FORMAT LENGTH MAXSIZE cs2kauth ibn 4 100

In this example, the name AUTHDEM is defined along with the format of IBN, length of code 4 and maximum number of codes 100.

37

The fields are:-PARTNM Partition name. Enter a 1 to 16 character name to be used by the

customer Group as the index into the AUTHCDE table. This name will be used in table CUSTHEAD to link the Customer Group to the Authorisation Codes that it may use.

FORMAT Format. Enter the format of the Authorisation Partition. The format may be:- CFRA, Call Forward remote Access, or IBN. Enter IBN if the codes are to be usable.

LENGTH Length of Authorisation Code. Enter the number of digits in the Authorisation Code. Codes may be between 2 and 10 digits in length and the number entered here fixes the code length for the Customer Group.

MAXSIZE Maximum Size. Enter the maximum number of codes (0-1000000) that the Customer group may use. The maximum number of codes that may be used also depends on thelength of the code. E.G. if the length = 3, the maximum range of codes can only be between 000 & 999

38









Table AUTHCDETable 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 TONEBURSTPrivate Speed Calling PSCAuthcode Hotline HOTLINECustomer group CUSTGRP

An example tuple is given below:-

TABLE AUTHCDEAUTHPART AUTHCODE FORMAT NCOS ACCT SECDIGS AUTHTYPEcs2kauth 12567 ibn 0 n $ swOPTION

$

39

In this example, The authorisation code 12567 has been assigned to the Authorisationpartition name cs2kauth. The format of the code is IBN and NCOS 0 has been attached to the code. Account code and Security digits are not required. The authorisation code is an SW type and no options apply.

The fields are:-AUTHPART Partition name. Enter the name of the Authorisation Partition table to

which this code is linked. This name must exist in an AUTHPART table first.

AUTHCDE Authorisation Code. Enter the actual authorisation code number. The number of digits must be the same as defined in the field LENGTH in the associated AUTHPART table. Up to 12 digits.

FORMAT Format. Enter the format of the code. The format may be CFRA, EXEMPT or IBN. The fields following the format entry will differ depending on the format chosen. Enter IBN if the code is assigned to the Customer group and is usable. The following fields must be datafilled if FORMAT is IBN.

NCOS Network Class of Service. Enter the NCOS assigned to the AuthorisationCode.The NCOS value must be valid for the customer group. The line from which the authorisation code is used will assume this NCOS value for the duration of the call.

ACCT Account Option. Enter Y (yes), if the authorisation code is to include a combined account code. Otherwise enter N (no). If an account is required, the ACCT option must be assigned to the Customer group in table CUSTHEAD.

SECDIGS Security Digits. The authorisation code can be given extra security by the inclusion of up to four extra security digits. Enter the actual digits required as the security digits. Enter $ in this field if security digits are not required.

AUTHTYPE Authorisation code type. Enter one of the following types:-SSAC – Station Specific Authorisation Code – Used in CentrexTranslationsSW – 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.

40

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 AUTHTYPEcs2kauth 12469 ibn 3 y 5643 swOPTION

$

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.

41

Table CUSTHEADTable Custhead is used to assign the Authorisation and Account Code options to a Customer Group. Four Customer Group options can be assigned, they are AUTH, ACCT, ACR and ACRANN. Each of the options assign particular operating parameters to the features which are then fixed on a customer group wide basis.

Option AUTH.The AUTH option is used to assign the AUTHPART table name to the Customer Group. Assignment of this name links the Customer Group to the Authorisation codes assigned to it. Other fields determine how the user indicates the end of the Authorisation code and whether a combined account code is required. An example is given below, however, the leading fields are not repeated.

Table CUSTHEAD

CUSTNAME - - - - - - - - - - OPTION PARTNM SECRECY COMB cs2kcust - - - - - - - - - - - - - auth authdem y y

In this example, the option AUTH has been added to the cs2kcust customer group. The option consists of the following fields:-

OPTION Option. Enter the name of the required option, AUTH in this example.

PARTNM Authorisation Partition Name. Enter the name of the Authpart table used by the Customer Group.

SECRECY Security. Enter the method used to indicate the end of an authorisationcode entry.There are two methods. Enter N(no) if the user has to dial a # (octothorpe) OR wait for the expiry of interdigit time-out to indicate the end of an authorisation code entry. Otherwise enter Y(yes).

COMB Combined Authorisation and Account Code. Enter Y (yes) if the code is a combined authorisation and account Code. Otherwise enter N (no).N.B. if the code is a combined authorisation and account code the option ACCT must also be defined for the customer group.

42

Option ACCTThe 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 CUSTHEADCUSTNAME - - - - -OPTION DIGINACC NOTIMOUT STARACPT ACCTVALcs2kcust - - - - - - - acct 3 y y nPOTSDGT

n

In this example, the option ACCT has been assigned to the cs2kcust customer group. The account codes are to be 3 digits long and an end of code indication has been defined. The option consists of the following fields:-

OPTION Option. Enter the name of the required option, ACCT in this example.

DIGINACC Digits in account code. Enter the number of digits in the account code. In this example 3, i.e.account codes must be 3 digits long. Range from 2 to 14digits.

NOTIMOUT Time Out. Enter the method used to indicate the end of an account codeentry. There are two methods. Enter N(no) if the user has to dial a #(octothorpe) OR wait for the expiry of interdigit time-out to indicate the end of an authorisation code entry. Otherwise enter Y(yes).

STARACPT Star accept. Enter Y (yes ) if the star * is to be a valid digit for the account code first. Otherwise enter N (no ) if the star * is to be used for reset dialing.

ACCTVAL Account code validation. Enter Y (yes) if the account codes are to be validated for content. Only codes of 2 or 3 digits may be validated. Otherwise enter N.

POTSDGT POTS Digit collection. Y or N. Only answer is N.

43


Indirect Access – MONA via ambiguous translations – continued







Table DIALPLANFor each dial plan, table DIALPLAN specifies that cut-through access is permitted only on authorisation, and specifies the secondary tone that should be used to prompt the user for authorisation information as Carrier Dial Tone (CDT), Special Dial Tone (SDT) or Dial Tone (DT). The fields are;DIALPLAN Dial Plan Name. 1-16 alphanumeric

CUTHRUTY Cut Through Type, the choices are; AUTHONLY – Auth Code only,

ORDER – First or LastAUTHPRMT – SDT, CDT, DT or NDESTPRMT - SDT, CDT, DT or NACCTPRMT - SDT, CDT, DT or N

or DESTONLY – Auth Code and destination digitsINITPRMT - SDT, CDT, DT or NACCT – Account code required Y or NACCTPRMT - SDT, CDT, DT or N

44

Additional options may be specified for a given dial plan. Some of them are:

AUTHRAN Allows variable-length authcodes (2-14 digits)AUTHPART Allows the authcode partition associated with the caller’s

customer group to be overriddenPARTIAL Allows partial authcode screeningCONFTONE Causes a confirmation tone to be played to the caller after

successful authcode screeningCUSTGRP / NCOS Allows the csutomer group and/or NCOS associated with

the caller to be overriddenMASK Allows authcode digits that would normally appear in the

AMA record to be masked

45









Table DNROUTE

The Directory Number route (DNROUTE) table contains directory numbers not associated with a L.E.N. (Line Equipment Number). The DNs datafilled in this table may point to a treatment, route list or special Centrex features. The DNROUTE table uses selectors to point the DN to the appropriate termination. The commonly used selectors are:-

D TreatmentMM Meet Me Conference (Datafilled in Table MMCONF )T Route list in table OFRT or IBNRTEFEAT Centrex Feature.

The special Centrex features accessed by DNs in table DNROUTE are:-

ACD Automatic Call DistributionDISA Direct Inward System AccessMONA Meridian Offnet AccessUCD Uniform Call Distribution

46

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 DNROUTEAREACODE OFCCODE STNCODE DN_SEL FEATURE DIALPLAN

207 620 6000 feat mona defaultOPTION

$

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. Thismust be a valid Area Code (SNPA) for the switch.

OFCCODE Office Code. Enter the three digit Office Code portion of the DN. The Office Code must be specified in table TOFCNAME first.

STNCODE Station Code. Enter the digits of the Station code.

DN_SEL Directory Number Selector. Enter the appropriate selector. TheFEAT selector is used in this example.

FEATURE Feature. Enter the required feature acronym. MONA in this example.

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

The following pages have an example of a call to a MONA number.This shows the links through these tables.

47

>traver tr ukpvg 02076206000 bTABLE 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 NCOSTUPLE 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 DIGCOLNDGT specified: digits collected individually AUTH option associated to CustGrpINAP 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 DNROUTETABLE DIALPLAN DEFAULT AUTHONLY FIRST CDT SDT N $ DIALPLAN cut-thru typeTABLE AUTHPART CS2KAUTH IBN 4 100 Link to CUSTGRP

48

ENTER AUTHCODE DIGITS >1234TABLE AUTHCDE CS2KAUTH 1234 IBN 0 N $ SW (HOTLINE 01628795888) $ Auth Code check and optionsTABLE NCOS CS2KCUST 0 0 0 NO_RST $ Call continues with possible new CustGrp and NCOSTABLE 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: 01628795888TABLE PXCODE TUPLE NOT FOUND Call enters Universals with HOTLINE numberDEFAULT FROM HEAD TABLE USED and processed as normalTABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01628795888 TABLE FACODE TUPLE NOT FOUND DEFAULT FROM HEAD TABLE USED

49

TABLE: FARTE KEY: 01628FA 1 . 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.



1 FEATURE 2076206000 ST

TREATMENT ROUTES. TREATMENT IS: GNCT 1 UNOBT


>

50

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.

51

0


nortel.com/training

Module 14

Universal Translations – Call Control and Universal Screening

1

2


Module 14 Universal Translations –Call Control and Universal ScreeningPurposeThe 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

3

4


Call Control and Universal Screening


Trunk Groupoption

EnhancedCLI Screening

TableCALLCNTL

Universal Screening

IntroductionUniversal 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.

5


Universal Screening Tables

TablesDNSCRN +CLISRVPF

TableTRKOPTS

CCNTLRXSelector

Entry to US viaEnhanced CLI screening

Entry to US ontrunk group basis

Entry to US from translations

TableCCNTLGRP

TableDTMFSCRN

TableACCTSCRN

IBNXLAprocessing

DIGMANmanipulation

Table CALLCNTL

TableCGPNSCRN

TableCDNNSCRN

TableCKTSCRN

TableCDPNSCRN

TableNOASCRN

TableIPISCRN

TableCDPNLSCR

TableBCSCRN

TableCPCNSCRN

TableNCOSSCRN

TableCICSSCRN

TableOLISCRN

TableCGRPSCRN

TableRDRISCRN

TableSINTSCRN

TableVARDEF

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 digitsCalled party number lengthNetwork Class of Service (NCOS)Customer groupUser-defined variablesCalled party number NOA and NPICalling party number digitsCalling party number NOABearer capabilityCarrier Identification Code (CIC)Redirecting informationISDN Preference IndicatorCalling Party’s Category (CPC)FGD ISUP Originating Line Information (OLI)FGD ISUP CKT

6

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 basisFor a given trunk group, the CCNTLIDX option in table TRKOPTS can specify an index into table CALLCNTL. Alternatively, to simplifyservice 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 translationsThe 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 screeningFor a call being screening on the basis of the caller’s 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.

7


Call Control and Universal Screening –entry from Trunks

Table TRKOPTSOPTKEY OPTINFO ------------------------------------------------------------------------------------HOLLANDPVG CCNTLIDX CCNTLIDX SCRN_4_64KDATA

Table CALLCNTL

Table TRKGRPGRPKEY 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 TRKOPTSThe 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 datafilledin table TRKOPTS.

8


Call Control and Universal Screening –entry from translations

Universal TranslationsxxRTE tablesXLANAME 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.

9


Call Control and Universal Screening –entry from enhanced CLI screening

Table CALLCNTL

Table DNSCRNDN ATTROPTS ----------------------------------------------------------------------------01483891111 ( CLISERV 1) $

PROFIDX PROFOPTS ----------------------------------------------------------------------------

1 (TEST (CCNTLIDX SCRN_4_64KDATA) $ )$

Table CLISRVPF

Call Control and Universal Screening – entry from enhanced CLI screening.For a call being screening on the basis of the caller’s 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.

10

Table CALLCNTLTable 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 CCNTLGRPUsing 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.

11

Universal ScreeningScreening 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.

12


Universal Screening Tables

TablesDNSCRN +CLISRVPF

TableTRKOPTS

CCNTLRXSelector

Entry to US viaEnhanced CLI screening

Entry to US ontrunk group basis

Entry to US from translations

TableCCNTLGRP

TableDTMFSCRN

TableACCTSCRN

IBNXLAprocessing

DIGMANmanipulation

Table CALLCNTL

TableCGPNSCRN

TableCDNNSCRN

TableCKTSCRN

TableCDPNSCRN

TableNOASCRN

TableIPISCRN

TableCDPNLSCR

TableBCSCRN

TableCPCNSCRN

TableNCOSSCRN

TableCICSSCRN

TableOLISCRN

TableCGRPSCRN

TableRDRISCRN

TableSINTSCRN

TableVARDEF

Universal Screening tablesThere 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.

13

Table CDPNSCRNTable CDPNSCRN is organized using a headtable and subtable format. All called-party-number screening tuples that are associated with a given CALLCNTL index are grouped together. The head table contains only the CALLCNTL index (1- to 32-character string); the subtable (CDPNDATA) contains the actual digits.The subtable CDPNDATA contains the actual called party number digits to be screened. If a match is found, the CALLCNTL index is updated to the new value specified by the CDPNINDX option. The CALLCNTL options are set as datafilled, and the CDPNSCRN subfields CONTINUE with CONSUME are performed as datafilled. The CDPNSCRN subfields provide the flexibility to consume a specified number of digits and continue screening in CDPNSCRN with the remaining digits without having to perform digit manipulation on the incoming number or without returning to CALLCNTL.Table CDPNLSCRTable 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 NCOSSCRNTable NCOSSCRN enables screening of the network class of service that is associated with a given call.Table VARDEFTable VARDEF allows the additions of strings up to 8 characters in length.These strings become variables usable by tables SINTSCRN, CALLCNTL and OUTPULSE.Table SINTSCRNTable SINTSCRN is used to screen small integer user-defined variables with the screening option of Call Control. It is organized using a head/sub-table architecture. With this approach, all the variable values associated with a given variable name (from table VARDEF) are grouped together. The head table contains only the Variable name. The sub-table (SINTDATA) contains the actual values and SCRN_INDX pairs.Table CGPNSCRNTable 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 CICSCRNTable 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 CGRPSCRNTable 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.

14

Table OLISCRNTable 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 CKTSCRNTable 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 RDRISCRNTable 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 IPISCRNTable 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 NOASCRNTable 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 CPNNSCRNTable 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 CPCNSCRNTable 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 BCSCRNTable 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.

15


Incoming Trunk

Table TRKGRPGRPKEY

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 TRKOPTSOPTKEY OPTINFO

----------------------------------------------------------------------------HOLLANDPVG CCNTLIDX CCNTLIDX SCRN_4_64KDATA

Table CALLCNTLCALCTL_KEY CALCTL_OPTIONS

----------------------------------------------------------------------------CHG_CUSTGRP ( CUSTGRP GRP1)$

SCRN_4_64KDATA ( SCRN ( BC ) $)$

Table BCSCRNBCKEY NEWSCRN_KEY CCOPTION -----------------------------------------------------------------------------------------------------------------SCRN_4_64KDATA 64KDATA CHG_CUSTGRP $

Call Control and Universal Screening –entry from Trunks example 1

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 $

16

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).

17

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 $

18

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) ( CLASSATL)$ 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.


PLEASE ENTER VALUE FOR BEARER CAPABILITY: >64kdata


1 DANNAT 01234567890 ST



>

19


Incoming Trunk

Table TRKGRPGRPKEY

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 $


----------------------------------------------------------------------------FRANCEPVG CCNTLIDX CCNTLIDX SCRN_4_GOLD_CUSTOMER


----------------------------------------------------------------------------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 CGPNSCRNCGPNSCRN_KEY CGPNDATA -----------------------------------------SCRN_4_GOLD_CUSTOMER ( 1)

Call Control and Universal Screening –entry from Trunks example 2

TABLE: CGPNSCRN SCRN_4_GOLD_CUSTOMER: CGPNDATA FROMDIGS TODIGS CGPNINDX CCOPTION CGPNOPT ----------------------------------------------------------------------------1483890000 1483890000 CHG_CUSTGRP_CUST_B $ $ 1628792000 1628792000 CHG_CUSTGRP_CUST_A $ $

The 2nd above example shows the link through the data tables for a call originating from a trunk, this time screening for CLI’s.

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.

20

The instruction here is to screen for Callers CLI’s.The fields consist of a FROMDIGS and TODIGS, where the CLI’s 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.

21

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

22

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) ( CLASATL)$ 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.



1 DANNAT 01234567890 ST



23

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

24

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) ( CLASATL)$ 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.



1 DANNAT 01234567890 ST



25





> EMEA..... or EM......

> CALA..... or CA......

> APAC.... or AP.....

> NA........

Naming ConventionsThis training event includes many exercises. To enable the switch database to be kept tidy and assist instructors in removing datafillpost-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.





26

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 ScreeningScreen 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 ScreeningCalls from your 2nd partner trunks are to be screened for the following CLI’s;2083005000. These calls are to enter Centrex Translations with the Customer Group name of DEFAULT, all other CLI’s 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]xSCREENWhere [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.

27


28


Call Control and Universal Screening –Path of Entry Screening

Incoming Trunk

CS2000

Voice Call

Data Call

Carrier X

Carrier Y

Carrier Y

Carrier Z

Carrier Z

PSTN

IntroductionWhen translating or routing calls through a network, multiple variables, such as call’s 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.

29

Path of Entry ScreeningPath 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 InformationThe 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 InformationDestination 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 ControlIn 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.

30


Path Of Entry (POE) screening/routing

Table Trkopts

Centrex Translations

Callcntl/bcscrn tables

POE tables


Xxcode table (Dest) (Destname)

Route(s) 1 Route(s) 2

Table Trkgrp

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: 01234567890Received Bearer Capability indicates "Data Call"

31


Incoming TrunkTable TRKGRPGRPKEY

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 $


----------------------------------------------------------------------------ITALYPVG CCNTLIDX CCNTLIDX INITIAL_SCREEN


----------------------------------------------------------------------------INITIAL_SCREEN (SCRN (BC) $ ) $ SET_VOICE_CUSTGRP (CUSTGRP DEFAULT) $ SET_DATA_POE (POECNAME (POECGRP POE_DATA) (POECIDX 5) $ ) $

Table BCSCRNBC_KEY NEWSCRN_KEY CCOPTION -------------------------------------------------------------------------------------------INITIAL_SCREEN SPEECH SET_VOICE_CUSTGRP $ INITIAL_SCREEN 64KDATA SET_DATA_POE $

Path Of Entry Screening example

TABLE xxCODEXLANAME FROMD TOD XLASEL ----------------------------------------------------------------------------xxxXLA 012345 012345 RTE (DEST 1) (DESTNAME DATA_POECRTE) $

Table POECNMVALUE SYMBOL

---------------------------------------------3 POE_DATA

TABLE xxRTEXLANAME RTEREF----------------------------------------------------------------------------xxxXLA 1 S ROUTE1

Table POECRTEPOECGRP POECIDX DESTNAME NEWROUTE

--------------------------------------------------------------------------------POE_DATA 5 DATA_POECRTE T OVR1 1

Table DESTNAMEVALUE SYMBOL

---------------------------------------------3 DATA_POECRTE

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 64KDATAIf 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.

32

If the call is 64KDATA, the call returns to CALLCNTL with the index name of SET_DATA_POE.This specifies the option of POECNAME.The 2 options set are;•POECGRP POE_DATA with the POECGRP previously specified in Table POECNM.•POECIDX 5 This index number will be the link to Table POECRTE later.

The above options are stored in memory ready for use later on if required.The call continues to Centrex Translations with the original Customer Group (CS2KCUST) and NCOS (0).

On reaching a routing decision in a xxCODE Table, the tuple specifies that the call will RTE to DEST 1, however the extra option of DESTNAME is the trigger to recall any POE information stored in memory.

The DESTNAME of DATA_POECRTE, combined with the POECGRP and POECIDX from Table CALLCNTL is then used to access Table POECRTE.The key of POE_DATA 5 DATA_POECRTE specifies the NEWRTE of Table OVR1, index 1.Therefore the original routing from the xxCODE table is overridden with the Table POECRTE data.

33


34

Information about the POE tables are as follows;Table POECNMThis table specifies valid POE names to be used within the POE system.The fields are VALUE – numeric, 0-32767SYMBOL – 1-32 alphanumeric characters

Table DESTNAMEThis table specifies valid names for use in Tables xxCODE and POECRTEThe fields are VALUE – numeric, 0-32767SYMBOL – 1-32 alphanumeric characters

Table POECRTEThis table combines the valid POE name from POECNM with the POECIDX and DESTNAME.Fields are:POECKEY, consisting of;POECGRP – from Table POECNMPOECIDX – from Table CALLCNTL option POECNAME, POECIDXDESTNAME – from table DESTNAMENEWROUTE – Values are T – Routing Table name and index

D - Treatment to be set for the callP – Continue the call with the previous route choice

The following pages show example TRAVERS of a SPEECH call and 64KDATA call.

35

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 $

36

TRAVER of SPEECH call using POE Screening/Routing - continuedTABLE 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 NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890 TABLE FACODE 01628FA 012345 012345 RTE ( DEST 1) ( DESTNAME DATA_POECRTE)$ TABLE: FARTE KEY: 01628FA 1 . S DANNAT EXIT TABLE FARTE TABLE TRIGGRP ETSIGRP INFOANAL . GENTRIG ( CDPN ETSITRIG)$ NIL Trigger INAPV8 GENTRIG is applicable to office. INAP Info Analyzed TDP: trigger criteria not met.


PLEASE ENTER VALUE FOR BEARER CAPABILITY: >speech


1 DANNAT 01234567890 ST



>

37

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 $

38

TRAVER of 64KDATA call using POE Screening/Routing - continuedTABLE PXHEAD CS2KPX DFLT CONT ( MM 11 11) ( CLASS NATL) ( XLT FA 01628FA)$ DFOP ( MM 6 1CLASS NATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890TABLE 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) ( CLATL)$ NOCON 9 THE DIGITS USED TO INDEX THE NEXT TABLE ARE: 01234567890TABLE 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.




1 SPAINPVG 01234567890 ST



>

39


40

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)

NOTEThis 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.

41


42


Least Cost Routing Engine

CS2000

£

££

£££

Switch A

Switch B

Switch C

Incomingcalls

??

?

IntroductionThe CS2000 currently has a very flexible translation system which can support almost any dialing plan in any network. The routing of a call is controlled from many different sources such as trunk group, CLI, authorization code, access code, calling party category, etc.Least Cost Routing (LCR) means routing calls to a route which represents the best value based on cost, quality, availability of carriers. The operator must consider these criteria and provision CS2000 with all possible combinations of carriers for each destination in existing CS2000 translations.The factors that affect LCR can change frequently. For example, a carrier may change its pricing which may no longer make that carrier the best value. So the operator must monitor these factors and update translations frequently. This process can be slow and inefficient using the existing translations and routing tables on the CS2000 , which creates a need for a simple, flexible interface for creating and manipulating routing plans based upon origination and destination. This interface is the Least Cost Routing (LCR) Engine.The LCR engine is a generic translations and routing function that incorporates the flexibility of existing CS2000 translations with the requirements of an efficient, low-maintenance LCR database.

43

The LCR engine includes the following:quick and efficient updates to routing datasingle point of interface for changing routingability to change multiple routes in few stepsautomatic updates of routing using off-board equipmentimplementation of all routing changes simultaneouslygroup 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 functionsUniversal 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 xxCODEtables.

44


LCR Engine Components

ActiveActive

Standby Standby

Incoming Call Existing CS2000

Screening FunctionsUniversal Translations(Digit Analysis)

Input 1:Path Of Entry

Input 2:Destination

OriginationMapping

DestinationMapping

MappingFunction

SWACTingFunction

SWACTingFunction

Output:List ofRoute Lists

Route List 1

Route List 2

Route List 3

CS2000 LCR EngineCS2000

The LCR engine includes two databases:Origination MappingDestination 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.

45

Origination Mapping DatabaseThe origination mapping database consists of 2 tables:

the active table LCRORIGthe 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 LCRORIGLCROKEY RTEPLIDX

----------------------- -----------------------------POE_BC 2 1000

The POE information (POECNAME) has two parts: POECGRP and POECIDX. POECGRP has a string value which is defined in table POECNM, and POECIDX is an integer between 0 and 255. The output of this table is a route plan index RTEPLIDX, which is used as one of two inputs to the destination mapping database.

46

Destination Mapping DatabaseThe destination mapping database consists of 2 tables:

the active table LCRDESTthe 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 LCRDESTLCRKEY LCR_ROUTE_LIST

----------------------------------------------------------------------------100 NATL_CALL ( OVR1 4) ( OVR1 5) ( OVR1 6)$

RTEPLIDX is the value obtained from table LCRORIG which represents the originating information. DESTNAME has a string value defined in table DESTNAME, the value of which obtained from xxCODE and xx2CODE tables.If more than one DESTNAME are datafilled in the xx/xx2CODE tuple, the most recent DESTNAME will be used in LCR processing. The output of this table is a route list consisting of the name of the routing table and its reference index. Multiple routes can be datafilled to the route list.Note that the reference index must first exist in the routing table before it can be datafilledinto the destination mapping tables.

47

Establishing an LCR CallThe following information is required for a call accessing the LCR database:

POECNAME - Includes POECGRP and POECIDX, obtained from table CALLCNTLDESTNAME - 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.

48


LCR Call Flow

Table TRKOPTS

Table CALLCNTLindex?

Y

N

POECNAMEexists?

Table TRKGRP

CentrexTranslations

YUpdate

POECNAME


DESTNAMEoption exists?

Table xxCODE

LCRoption exists?

Table LCRORIG

LCRORIGindex exists?

Table LCRDEST

LCRDESTindex exists?

Continueas regular

call

Y

Y

Y

YRoute call

usingRTELIST

N

N

N

N

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

49

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

50

TRAVER of an LCR Data call – Standby tables continuedTABLE FAHEAD 01628FA DFLT RTE ( MM 11 11) ( DEST 1) ( CLASS NATL)$ DFOP ( MM 11 11) ( CLASS NATL)$ 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 200TABLE 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.




1 GERMANYPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH

2 FRANCEPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH

3 HOLLANDPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH

4 ITALYPRI N CDN E164 NA 01234567890 NIL_NSF BC SPEECH



51

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

52

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 NATL)$ 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 LCRORIG NO MAPPING ENTRYTABLE 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.




1 SPAINPVG 01234567890 ST



53

Database Update and ManipulationThe LCR engine includes functions designed for quick and efficient manipulation of all routing data. These functions include:

switch active and standby databasesquery / select data based on: Path of Entry, Route Plan, Destination or Individual routeadd / remove Path of Entry, Route Plans, or Destinationsadd / remove routes at any position in the list of route listsreplace / remove full route listscopy entire route plans to new route plansdatabase synchronization (copy the active database to standby)

LCRSWACT CommandA “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.

54


LCRTM ToolCI:

> LCRTM

User enters CI command

LCRORIG2

LCRDEST2

LCRSYNCINSERT

SELECT

LCRSYNCINSERT

SELECT

UPDATE DELETE

UPDATE DELETE ADDRTE CHGRTE DELRTE

INSERT SELECT

LCRSYNC

INSERT SELECT

LCRSYNC

User prompted for table selection

LCRDEST2LCRORIG2

Insert

Select

Synchronise InsertSynchronise

Select

User can update or delete values in a selected field

CI:

> LCRTM

User enters CI command

LCRORIG2

LCRDEST2

LCRSYNCINSERT

SELECT

LCRSYNCINSERT

SELECT

UPDATE DELETE

UPDATE DELETE ADDRTE CHGRTE DELRTE

INSERT SELECT

LCRSYNC

INSERT SELECT

LCRSYNC

User prompted for table selection

LCRDEST2LCRORIG2

Insert

Select

Synchronise InsertSynchronise

Select

User can update or delete values in a selected field

Rudimentary Hierarchy for Table Management

LCRTM ToolThe LCR engine can be manipulated simply by editing the tables LCRORIG2 and LCRDEST2 then using the command LCRSWACT to update the active database.However, the LCRTM (LCR Table Management) tool allows quick and efficient manipulation of all routing data using a list of available commands:

•INSERT•SELECT

— UPDATE

— DELETE

— ADDRTE (LCRDEST2 table only)

— CHGRTE (LCRDEST2 table only)

— DELRTE (LCRDEST2 table only)

•LCRSYNC

55

Table SelectionBefore 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:> LCRTMNext par is: <Table name> {LCRORIG2, LCRDEST2}Enter: <Table name>> LCRORIG2LCRORIG2:>Or if table LCRDEST2 is chosen:

Next par is: <Table name> {LCRORIG2, LCRDEST2}Enter: <Table name>> LCRDEST2LCRDEST2:>

56

Subcommand DefinitionINSERT 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 22LCRORIG2:

LCRDEST2:> INSERT 22 LONDON OFRT 1 OFRT 3 OFRT 5LCRDEST2:

57

SELECT CommandThe 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 100Tuples Successfully Selected = 3

**** WARNING * WARNING * WARNING * WARNING ****This operation could potentially overwriteexisting tuples in LCRORIG2.**** WARNING * WARNING * WARNING * WARNING ****

POECGRP POECIDX RTEPLIDX------------------------POEGRP1 12 100POEGRP1 15 100POEGRP5 9 100

LCRORIG2:SELECT:>

58

LCRDEST2:> SELECT RTELISTS EQ OFRT 1Tuples Successfully Selected = 5

**** WARNING * WARNING * WARNING * WARNING ****This operation could potentially overwriteexisting 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


LCRORIG2:SELECT:>

59

UPDATE CommandOnce 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.

60

LCRDEST2:> SELECT RTPLIDX EQ 120 AND DESTNAME EQ UKTuples Successfully Selected = 1


RTEPLIDX DESTNAME RTELISTS--------------------------120 UK (OVR8 3)(OFRT 1)(OFRT 10)(OFR4 1)

LCRDEST2:SELECT:> UPDATE RTELISTS EQ OFRT 12Tuples Successfully Updated = 1

RTEPLIDX DESTNAME RTELISTS--------------------------120 UK (OFRT 12)

LCRDEST2:>

LCRDEST2:> SELECT DESTNAME EQ UKTuples Successfully Selected = 2


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:>

61

DELETE CommandThe 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 100Tuples Successfully Selected = 3


POECGRP POECIDX RTEPLIDX--------------------------POEGRP1 12 100POEGRP1 15 100POEGRP5 9 100

SELECT:> DELETETuples Successfully Deleted = 3

LCRORIG2:>

62

ADDRTE CommandThe 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)



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:>

63

CHGRTE CommandThe 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


RTEPLIDX DESTNAME RTELISTS------------------------------------------------120 UK (OFRT 1)(OFRT 10)

LCRDEST2:> CHGRTE OFRT 10 OVR3 3


RTEPLIDX DESTNAME RTELISTS--------------------------120 UK (OFRT 1)(OVR3 3)

LCRDEST2:>

64

DELRTE CommandThe 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)



RTEPLIDX DESTNAME RTELISTS-----------------------------------------------120 UK (OVR8 3)(OFRT 1)(OFR2 2)(OFRT 10)(OFR4 1)

SELECT:> DELRTE OFRT 1


RTEPLIDX DESTNAME RTELISTS-----------------------------------------------120 UK (OVR8 3)(OFR2 2)(OFRT 10)(OFR4 1)

LCRDEST2:>

65

LCRSYNC CommandThe 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 changedPlease 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% completed50% completed75% completedLCRORIG database is synchronized.>LCRORIG2:>LCRDEST2:> LCRSYNC***WARNING: Active table is empty. LCRSYNC will erase***WARNING: all existing datafill in the inactive tablePlease confirm (“YES”, “Y”, “NO”, “N”)> NLCR database is not changed

LCRORIG2:>

66

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.

67


68

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.

69

0


nortel.com/training

Appendix A

PRI Trunk Groups

1

2


Appendix A PRI Trunk Groups


concepts of;

> PRI Trunk Groups and their datafill.


List the tables used to establish PRI voice calls.

Describe the purpose of each of the tables

Optional PRI trunk group datafill exercise

3

4


XLANAME

CUSTENG

CUSTHEAD

NCOS

IBNXLA

LINEATTR

IBNTREAT


Centrex

Universals

CLLI

TRKGRP

TRKSGRP

TRKMEM

LTMAP

LTCALLS

LTDEF

Trunks

5


6


Trunk Network – the big picture

Switch A

Switch B

PBXA

PBXB

Switch E

Switch C

R.O.W

PRI Trunk GroupsPRI (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.

7


VoiceServices

ElementManagement

IEMS

BackOffice MS20x0


MG15K

Derived Lines

IADCPE

DSLAM

xDSLIAD

Hosted PBX

PBX CableModem

HFCHFC

VideoFeed

CMTS

Cable Modem


Centrex IP

i2004 Etherset

m6350Softclient

PSTN

NetworkSignalling

SS7USP

IPNetwork

CS LAN

GWC

ERS 8600

CS2000cCS2000CS2000

or

CICM

BCP

MCS



Multimedia Server

TDM Interface

CBM


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 CS2000’s GWC’s.

Direct trunks from PBX’s would also be hosted in a similar method.

8


Outgoing PRI Translations

Routing Tables(IBNRTE & OFRT)

Line Originated

Call

CentrexTranslations


PRIOutgoing

Trunk CLLI

Routing Tables(IBNRTE & OFRT)

Public Call

Private Call

Outgoing PRI Translations

A line has a Customer Group and NCOS which links the line into Centrex translations for the purpose of analysing the dialled digits and translating them into an outgoing routing conclusion. From here there is one of three things that can take place based on the digits dialled and the way in which translations have been set up:-

1. The call routes direct from Centrex translations to the outgoing PRI trunk CLLI. In this case the called number (CDN) that may be sent over the outgoing PRI trunk will be of the type “PVT”.

2. The call routes from Centrex translations to routing tables (IBNRTE or OFRT) and then to the outgoing PRI trunk CLLI. In this case the called number (CDN) that may be sent over the outgoing PRI trunk will be of the type “PVT”.

3. The call routes from Centrex translations, through Universal translations & routing tables (IBNRTE or OFRT), and then to the outgoing PRI trunk CLLI. In this case the called number (CDN) that may be sent over the outgoing PRI trunk will be of the type “PUBLIC (E.164)”.

9

TRAVER of Outgoing Private call>TRAVER L 8795507 66015028 BTABLE 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.



1 PRITG1 N CDN PVT L 5028 NIL_NSF BC SPEECH

TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT


>

10

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: 66025028 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


DIGIT TRANSLATION ROUTES 1 PRITG1 N CDN E164 L 66025028 NIL_NSF BC SPEECH

TREATMENT ROUTES. TREATMENT IS: GNCT 1 GNCT +++ TRAVER: SUCCESSFUL CALL TRACE +++

11


Incoming PRI Translations

Table TRKGRP

Table LTCALLS

CENTREX TRANSLATIONS(Table IBNXLA etc)

UNIVERSAL TRANSLATIONS(Table PXCODE etc)

PRIVATE CALL

PUBLICCALL

Table OFRT/IBNRTE

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.

12


Private Incoming Calls> 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

PRIVATE CALL

Table OFRT/IBNRTE

CENTREX TRANSLATIONS(Table IBNXLA etc)

XLAIBN RTEREF

Table LTCALLS

Table LTCALLS provides initial translations for the calls incoming from the trunk group. The table is datafilled with the trunk group’s LTID (the LTID is defined in Table LTDEF), the call type (i.e. PUB or PVT) and the initial translations route for the call.

Table LTCALLS used for Private Translations

>TABLE LTCALLS

LTID XLARTSEL OPTIONS-------------------------------------------------------------------------------------------------QNSX 230 PVT XLAIBN 204 QUEENSX00MEL 0 10 $>

Note you cannot use the XLALEC selector with Private calls.

13

TRAVER of Incoming Private (PVT) call>TRAVER TR PRITG2 N CDN PVT 5505 BTABLE 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



1 LINE 1628795505 ST



14


Public Incoming Calls

• 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 Universal translations. NCOS may also be used for COSMAPPING (See Later)

• RTEREF :- Links E.164 calls direct to Table OFRT or IBNRTE

• XLALEC:-LINEATTR links E.164 calls into Universal translations. No NCOS for COSMAPPING (See later)

Table TRKGRP

Table LTCALLS

PUBLIC CALL

Table OFRT/IBNRTE

XLAIBN RTEREF


XLALEC


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

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

Note 1:- with XLAIBN the NCOS value datafilled in LTCALLS can be used for COSMAPPING later.

Note 2:- The customer group specified in LTCALLS against a public tuple cannot be used to link public calls into Centrex translations; it only works with Private calls.

RTEREF allows a Table Name & Index to be specified linking the calls direct to Table OFRT or Table IBNRTE without routing through Centrex or Universal Translations.

>TABLE LTCALLS

LTID XLARTSEL OPTIONS--------------------------------------------------------------------QNSX 230 PUB XLALEC 204 $>

15

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: 66025505 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



1 LINE 1628795505 ST


+++ TRAVER: SUCCESSFUL CALL TRACE +++ >

16


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)$

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.

17

TRAVER for Public (E164) call>TRAVER TR PRITG1 N CDN PUB 67825028 BTABLE TRKGRPPRITG1 PRA 0 PRAC NCRT MIDL N (MMPRI 1) $ $TABLE LTCALLSMMPRI 1 PUB RTEREF IBNRTE 692 $TABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILINAP Info Analyzed TDP: no subscribed trigger.TABLE IBNRTE692 RX IBNDEMO 0 0 25 $. TABLE DIGMAN. 25 (REM 4). EXIT TABLE DIGMAN

EXIT TABLE IBNRTE



1 LINE 1628795028 ST

TREATMENT ROUTES. TREATMENT IS: GNCT1 ENGAGED


>

Note: Traver does not show the retranslation, but the result is correct.

18


Table LTCALLS summary

PVT

CentrexXLA

Bypass Universal XLA

CentrexXLA

LINEATTR

CUST GRP

NCOS

Bypass CentrexXLA

OFRT/IBNRTE

INDEX

Universal XLA(No COSMAPPING)

XLALEC

LINEATTR OFRT/IBNRTE

INDEX

RXCust Grp

+NCOS

PUB

UniversalXLA

XLAIBN

LINEATTR

CUST GRP

NCOS

RTEREFXLAIBN RTEREF

19

Table CLLITable 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 TRKGRPTable 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 TRKSGRPTable 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 TRKMEMTable 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 LTMAPTable LTMAP maps logical terminals to trunk span DS-0 location and the terminal equipment interface.

Table LTCALLSTable LTCALLS stores service-related data, such as translations, that the CS2000 switch associates with the call type.

20

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.

21


Table TRKGRP Example (PRI)

TABLE TRKGRP

GRPKEY GRPTYP TRAFSNO PADGRP NCCLS SELSEQ BILLDN

ukpri pra 0 npdgp ncrt aseq n

LTID OPTION

$ $

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 beenestablished in table CLLI before it can be entered here.

GRPTYP Group type. Enter the trunk group type. For PRI trunks this is PRA.TRAFSNO As per C7UP TRKGRP examplePADGRP As per C7UP TRKGRP exampleNCCLS As per C7UP TRKGRP exampleSELSEQ As per C7UP TRKGRP exampleBILLDN As per C7UP TRKGRP exampleLTID Logical terminal identifier This subfield consists of subfields LTGRP and

LTNUM. These read-only subfields display the LTID that has been mapped to the trunk group by table LTMAP. Subfield LTID cannot be datafilled by operating company personnel. Enter $.

OPTION Options. Enter any options required.

22


Table TRKSGRP Example (PRI)

TABLE TRKSGRPSGRPKEY CARDCODE SGRPVAR PSPDSEIZ PARTDIAL VERSIONukpri 0 ds1sig isdn 4 4 87q931CRLENGTH BCHNEG BCHGLARE IFCLASS CONFIG LOCATION SAT

2 n stand network pt_pt user nECSTAT NSMATCH AUTOON TRKGRDTIM L1FLAGS PARMNAME PMTYPEInternal n n 70 n default gwcGWCNO GWCNODENO GWCTRMNO DCHRATE HDLCTYPE PMTYPE

1 8 315 64k hdlc $OPTION

$

The above is an example of PRI or Integrated Services Digital Network (ISDN).

For the above example the fields are:-

SGRPKEY Subgroup key. This field comprises the subfields CLLI and SUBGRP, the CLLI name of the trunk group and the trunk subgroup number.

CARDCODE Enter the card type used to support the trunks. This may differ dependant on the signalling system. ISDN uses DS1SIG.

SGRPVAR Enter ISDN for ISDN type trunks.PSPDSEIZ Permanent signal or partial dial on seizure timing. Enter the time, in seconds,

that the trunk waits for reception of the first digit.PARTDIAL Partial dial timing. Enter the time, in seconds, that the trunk has to wait for

reception of each digit, excluding the first digit.VERSION Protocol version. Enter the version of the protocol. Value for all PRI variants.

Value for all QSIG variants.CRLENGTH Call reference length. Enter the number of octets in the call reference. BCHNEG B-channel negotiation. Enter Y (yes) if B-channel negotiation is allowed.

Otherwise, enter N (no). BCHGLARE B-channel glare. Enter YIELD if the B-channel is used in set-up messages,

simultaneously in both directions, or if the call must be taken down by this switch. Enter STAND if the switch must wait for the other switch to yield.

IFCLASS Interface class. Enter NETWORK if it is the network end. Enter USER if the PRA link is considered the user end of the protocol.

23

CONFIG Configuration. If broadcast procedures are to be used on this interface, enter PT_MLT_PT (point-to-multipoint). Otherwise, enter PT_PT (point-to-point).

LOCATION Location. Enter the location to be used if creating CAUSE information elements. The following CAUSE information elements are contained in release messages that map to a specific treatment: • LOCALEO - local end office (public network) location • PVTNET – private network location• USER - user location• LOC_MAP – location map

SAT Satellite. Enter Y, (yes), if the trunksgrp is configured to switch through a satellite. If not, enter N, (no).

ECSTAT Echo canceler status. Enter UNEQ to indicate that Echo canceler is not equipped on this subgroup.

NSMATCH Noise match control. Enter N to indicate that background noise is not maintained if internal echo canceler status is actively cancelling echoes.The default is N.

AUTOON Auto re-enable control. Enter N to indicate that the echo canceler status is not automatically turned on after the 2100-Hz tone control is removed. This option is similar to the END OF CALL option for tone disablers in external echo canceler status.The default is Y.

TRKGRDTIM Trunk lock-out timeout. If the entry in field DIR is OG, enter the time, in 10-ms intervals, that the trunk waits to receive on-hook from the far-end before reporting lock-out on the trunk. The timer begins on sending an on-hook signal to the far-end.

L1FLAGS Layer 1 flags. This field is used by ISDN primary rate access (PRA) trunks to indicate whether or not the ISDN DTC (DTCI) sends layer 1 flags if the D-channel is in flagfill mode. Enter Y if the connection is between CS2000 and a different vendor. Enter N for CS2000-to-CS2000 PRA connections.

PARMNAME ISDNPARM name Enter a name in table ISDNPARM.This field associates the information found in table ISDNPARM with the primary rate interface defined by the table TRKSGRP tuple. The default is DEFAULT.

PMTYPE Peripheral module type. GWCNO Gateway Controller NumberGWCNODENO Gateway Controller Node Number.GWCTRMNO Gateway Controller Terminal NumberDCHRATE D-channel data rate. Enter the data rate of the D-channel, 56K or 64K. The

data transmission rate of the carrier (DS-1) and of the D-channel on it must be compatible. If the carrier is datafilled to transmit at 56K, then the entry in field DCHRATE must also be 56K.

HDLCTYPE High level data link type. Enter HDLC or INVHDLC. HDLC for high level data link or INVHDLC for inverted high level data link.

24


Table LTDEF Example

TABLE: LTDEFLTKEY LTAP CLASSREFPRI 1 B PRA 30 ETSIPRI 1990 NIL (NOPMD ) $

For the above example the fields are;

LTKEY Logical terminal key. This field consists of subfields;LTGRP - alphanumeric (up to 8 characters) Logical

terminal group. LTNUM - 1 to 1022 Logical terminal number.

LTAP B For circuit switching or for ISDN MFT terminals, enter B.CLASSREF Class reference field consists of; LTCLASS

PRA For primary rate access, enter PRA.. NUMBCHNL 1 to 479

VARISSUE see subfields This field consists of subfields VARIANT and ISSUE.ETSIPRI - ETSI PRI (Europe)1990

PROFNAME (alphanumeric to 8 characters)OPTION Up 4 Options may be added. See NTP for details.

25


Table LTCALLS Example

TABLE LTCALLSLTID XLARTE LINEATTR XLAPLAN RATEAREA LTCOPT

pri 7 pub xlalec 1 cs_nprt cs_nil $

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 XLARTE’s are available, see NTP for details.LINEATTR - alphanumeric (1 to 16 characters) Line

attributes index.XLAPLAN - valid entry from Table XLAPLANRATEAREA - valid entry from Table RATEAREA

LTCOPT Logical terminal option. See NTP for details.

26


Table LTMAP Example

TABLE: LTMAP LTKEY MAPPING OPTIONPRI 1 CLLI FRANCEPRI ( TEI 0) $ PRI 2 CLLI GERMANYPRI ( TEI 0) $ PRI 3 CLLI HOLLANDPRI ( TEI 0) $ PRI 4 CLLI ITALYPRI ( TEI 0) $ PRI 5 CLLI SPAINPRI ( TEI 0) $ PRI 6 CLLI UKPRI ( TEI 0) $

For the above example the fields are;LTKEY This field consists of subfields LTGRP and LTNUM.

LTGRP Logical terminal group datafilled in table LTGRP.LTNUM Logical terminal number (1 to 1022 )

MAPPING This field consists of subfield MAPTYPE.MAPTYPE CLLI, LEN or XSG

Logical terminal mapping type Enter the type of mapping being used. Enter CLLI and datafill refinement CLLI. Enter LEN and datafill refinement LEN. Enter XSG and datafill refinement XSG. For primary rate access (PRA), the logical terminal identifier must be mapped to a CLLI.

CLLI Common language location identifier Enter the CLLI of the PRA trunk to which the logical terminal is assigned.

OPTION TEI 0 to 63 Terminal endpoint identifier Enter the terminal endpoint identifier that is specified for static TEI terminals.

Other options are available, see NTP’s for details.

27

28


PRI Bearer Capability Routing

CS2000

PSTN

PVG PRI

Gateway

CS LAN

PVG Gateway

PVG Gateway

Incoming PRI Call

64k Data

Voice

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 BCDEFTable RCNAMETable RTECHAR

29

Table BCDEFTable BCDEF contains all the valid bearer capability names. Each tuple in the table lists a BCNAME and it’s associated transmission characteristics, which include the trunk’s transfer capability, transfer mode, and coding standard. The BCNAME is used in table RTECHAR to represent it’s associated transmission characteristics.

>TABLE BCDEFKEY BCDATA

-----------------------------------------------------------------------------------------------------SPEECH SPEECH CIRCUIT CCITT64KDATA UNRESDIG CIRCUIT CCITT64KX25 RESDIG CIRCUIT NETWORK DTU X25 Y AUTO56KDATA UNRESDIG CIRCUIT NETWORK DTU NONE Y 56KBSDATAUNIT UNRESDIG CIRCUIT NETWORK DTU TLINK Y 56KBS64KRES RESDIG CIRCUIT CCITT3_1KHZ AU3_1KHZ CIRCUIT CCITT7_KHZ AU7KHZ CIRCUIT CCITTVOICE_DATA AU3_1KHZ CIRCUIT CCITT64K_RATE_AD_DATA UNRESDIG CIRCUIT CCITT>

Table RCNAMETable 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 it’s associated routing characteristics.

>TABLE RCNAMENAMEKEY---------------------

64K31K

Table RTECHARTable 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 RTECHARRCKEY GROUPRC

----------------------------------------------------------------------------64K (BC 64KDATA $) $31K (BC 3_1KHZ $) $

The way that subsequent translations are datafilled for BC routing differ from Private and Public calls and will be discussed separately next.

30


Private Call (Centrex Translations)

OFRT /IBNRTE

CUSTGRP + NCOS

ROUTE A

NCOS or CUSTHEAD

IBNXLA

XLTR Name XLAMAP

IBNXLA

RCNAME eg 64k fromTable RTECHAR

XLTR Name New XLTR Name

To LINEATTRFOR PUBLICCALLs

OFRT /IBNRTE

ROUTE B

OFRTMAP /IBNMAP

Nil Entry

Speech Call Data Call

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 XLAMAPXLAKEY DATA

---------------------------------------------------------------------------------64K CXDEMO ( XLA CXDEMO1)$64K PXDEMO1 ( XLA CXDEMO)$64K PXDEMO2 ( XLA DATA)$

31

Private BC Speech Call Traver>TRAVER TR PRITG2 N CDN PVT 5028 BC SPEECH BWarning: 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



1 LINE 1628795028 ST



32

Private BC 64KDATA Call Traver>TRAVER TR PRITG2 N CDN PVT 5028 BC 64KDATA BWarning: 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.



1 NTDEMO2WNAT 5028 ST


33


Public Call (Centrex Translations)

LINEATTR

PXHEAD

PXCODE

PXRTE

OFRT /IBNRTE

OFRTMAP /IBNMAP

OFRT /IBNRTE

FROM CENTREX XLAS or Table LTCALLS

Route Index

RCNAME eg 64k fromTable RTECHAR

New Route IndexRoute Index

Speech Call Data CallROUTE A 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:-

Routing Table Mapping TableOFR2 OFRTMA2OFR3 OFRTMA3OFR4 OFRTMA4IBNRT2 IBNMAP2IBNRT3 IBNMAP3IBNRT4 IBNMAP4

>TABLE OFRTMAPKEY NEWINDEX------------------------------------64K 20 2164K 602 612

34

Public BC Speech Call Traver>TRAVER TR PRITG2 N CDN PUB 66025014 BC SPEECH BWarning: Routing characteristics are present.

Originator must be able to send incharacteristics specified.

TABLE TRKGRPPRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $TABLE LTCALLSMMPRI 2 PUB XLALEC 782 $TABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILTABLE LINEATTR782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE PXHEADPRIUSER SDFLT NODFOP CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 66025014TABLE PXCODEPRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) ( CONSUME 4)$INAP Info Analyzed TDP: no subscribed trigger.TABLE: PXRTEKEY: PRIUSER 682. T IBNRTE 682. . TABLE IBNRTE. . 682 DN 162 879 N 0. . EXIT TABLE IBNRTEEXIT TABLE PXRTE



1 LINE 1628795014 ST

TREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT


35

Public BC 64KDATA Call Traver>TRAVER TR PRITG2 N CDN PUB 66025014 BC 64KDATA BWarning: Routing characteristics are present.

Originator must be able to send incharacteristics specified.

TABLE RTECHAR. 64K ( BC 64KDATA $)$TABLE TRKGRPPRITG2 PRA 0 PRAC NCRT MIDL N (MMPRI 2) $ $TABLE LTCALLSMMPRI 2 PUB XLALEC 782 $TABLE CUSTSTNTUPLE NOT FOUNDTABLE OFCVARAIN_OFFICE_TRIGGRP NILTABLE LINEATTR782 IBN NONE NT NSCR 0 162 NPRT NLCA NONE 0 NIL NILSFC NILLATA 0 PX PRIUSER NIL$LCABILL OFF - BILLING DONE ON BASIS OF CALLTYPETABLE PXHEADPRIUSER SDFLT NODFOP CON STDTHE DIGITS USED TO INDEX THE NEXT TABLE ARE: 66025014TABLE PXCODEPRIUSER 6602 6602 RTE ( MM 8 8) ( DEST 682) $INAP Info Analyzed TDP: no subscribed trigger.TABLE: PXRTEKEY: 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 IBNRTEEXIT TABLE PXRTE



1 NTDEMO2WNAT 66025014 ST

TREATMENT ROUTES. TREATMENT IS: GNCT1 GNCT

+++ TRAVER: SUCCESSFUL CALL TRACE +++>

36

37

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 infoDestination A - GWCNO _____ GWCNODENO_____ GWCTRMNO____________ Destination B - GWCNO _____ GWCNODENO_____ GWCTRMNO____________

TRKMEM infoDestination 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 CLLI’s

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 AsiaPacTeam Number – 1 to 8Signalling 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.

38

Trunk Group Exercise Room plan

Team 4Team 3

GWC No__1__GWC Node__8__GWC TermNo__630__

Team 2


Team 1



Team 5


Team 6



GWC No__1__GWC Node__8__GWC TermNo_631__

GWC No__1__GWC Node_8___GWC TermNo__641__




39

0


nortel.com/training

Appendix B

CCS7 Information

1

2


Appendix B

PurposeThis section contains information in relation to CCS7 Signalling

and is for information only.

3

4


CCS7 Tables

User Part Tables

CLLI

TRKGRP

TRKSGRP

TRKMEM

ISUPDEST

C7NETSSN

C7NETWRK

C7RTESET C7LKSET C7LINK

C7LOCSSN

C7TRKMEM

C7TIMER

C7 Tables

Signalling Link ProvisioningThis 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 toensure that the signalling channels entering the CS 2000 are routed to appropriate signallingterminations.

5

CCS7 Signalling LinksThe 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 routesetavailability.

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).

6

Trunk Provisioning Flowcharts (TDM-Side)

7

ISDN Signalling LinksSignalling links for ISDN PRI are provisioned using table TRKSGRP, as used to define the signalling characteristics of a given trunk group. QSIG signalling links are datafilled in the same way. A PRI trunk group has no subgroups as such, but table TRKSGRP defines the signalling characteristics of the D-channel that conveys the ISDN signalling for the B-channels in the group:• Signalling type ISDN• Protocol version 87Q931• Configuration PT_PT

In conceptual terms, there is a logical terminal (LT) at either end of an ISDN PRI trunk interface. Each logical terminal has an identifier and belongs to a logical terminal group. On CS 2000, logical terminal attributes are datafilled in tables LTGRP, PRIPROF, LTDEF and LTMAP, as follows:

• Table LTGRP is used to define group numbers to be assigned to ISDN logical terminals. Only one option is available per group, this being SAPI16. SAPI16 is the Service Access Point Identifier used for communication between Layers 2 and 3.•Table PRIPROF is used to create profiles that can be used by ISDN logical terminal groups. The key field is PROFNAME, which is referenced in table LTDEF. Profiles are used when interworking with a PBX that uses an implementation of ETSI PRI that differsfrom 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)

8

9

The following is an example of CCS7 datafill.

TABLE: C7NETWRKNETNAME NODETYPE PTCODE NI SLSROT TFR MCS CLUSTERS

RCTEST MTPRES CNGCONT SLSENH---------------------------------------------------------------------------------------------------------C7NETWRK1 SSP CCITT7 BASIC 6969 NATL N N

1 N N Y N NCS2KNAT SSP CCITT7 BASIC 789 NATLSPARE N N

1 N N Y N Y

TABLE: C7RTESETROUTESET NETNAME TFPBCAST DPC

ROUTES----------------------------------------------------------------------------SNODE_RS CS2KNAT N CCITT7 BASIC 123

(SNODE_LS 0)$SNSEB_RS CS2KNAT N CCITT7 BASIC 345

(SNSEB_LS 0)$SPC_RS C7NETWRK1 N CCITT7 BASIC 1212

( SPC_LS 0)$

TABLE: C7LKSETLINKSET LSTYPE NETNAME FEPC

FECLLI SIGLKTST RSTEST INHTESTQ704 CNGSTN NUMFLAGS MTPRES CHNGSLS SCCPONLY NIRPLMT

AUTOINH CONGENH----------------------------------------------------------------------------SNODE_LS FLINK CS2KNAT CCITT7 BASIC 123

SNODE N N N0 1 1 N N N NILY N

SNSEB_LS FLINK CS2KNAT CCITT7 BASIC 345SNSEB N N N

0 1 1 Y N N NATLY N

SPC_LS FLINK C7NETWRK1 CCITT7 BASIC 1212LINK_TO_SPC N N N

0 1 1 N N N NILY N

10

TABLE: C7LINKLINKNAME LINKDATA CLASDATA Q707 LINKOPT-----------------------------------------------------------------------------------------SNODE_LS 0 LIUBASIC LIU7 13 MTP2 0 0 $SNODE_LS 1 LIUBASIC LIU7 23 MTP2 0 0 $SNSEB_LS 0 LIUBASIC LIU7 25 MTP2 0 0 $SNSEB_LS 1 LIUBASIC LIU7 36 MTP2 0 0 $SPC_LS 0 LIUBASIC LIU7 1 MTP2 0 0 $

TABLE: ISUPDESTDESTKEY ISUPROUT-----------------------------------------------------GERMANYPVG 0 SNSEB_RSFRANCEPVG 0 SNSEB_RSSPAINPVG 0 SNSEB_RSHOLLANDPVG 0 SNSEB_RSITALYPVG 0 SNSEB_RSUKPVG 0 SNSEB_RS

TABLE: C7NETSSNPCNAME XUDTIND CGT1 CGT2 SSNAMES----------------------------------------------------------------------------

SPC_RS Y 0 0 ( ETSIIN 106)$

11


0


nortel.com/training

Appendix C

Announcements

1

2


Appendix C

PurposeThis section contains example datafill on Announcements in a

CS2k environment and is for information only.

3

4

Announcement DatafillThe 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 CLLIDefines 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 ANNSFor 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 ANNMEMSAn 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 ANNPHLSTThis 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 consituentphrases from table ANNPHLST.

• Table ANNAUDIDBecause the media server does not recognise the CS 2000 names for announcement phrases, table ANNAUDID maps the phrase identifiersdatafilled 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.

5

6


Table CLLICLLI ADNUM TRKGRSIZ ADMININF-----------------------------------------------------------------------WRONG_NUM 1000 10 WRONG_NUM_ANNC

Table ANNAUDIDPHRASEKY AUDID ----------------------------WRONG_NUM 3000

Table ANNSCLLI ANNARCH TRAFSNO CYTIME MAXCYC DATA

-------------------------------------------------------------------------------------------WRONG_NUM NETWK 0 10 1 STND N 10

Table ANNMEMSANNMEM HDWTYPE CARD MEMINFO

------------------------------------------------------------------------WRONG_NUM 0 UAS AUD 2 AUD 2

CS2k Announcements example datafill

Table ANNPHLSTANNPHKEY PHSLIST

-------------------------------------------------------------------WRONG_NUM 2 ( BLACK ) $

Table SERVRINVSRVRNAME SRVRADDR SRVREXEC SRVRTONE BEARNETS SRVROPTS ---------------------------------------------------------------------------------------------------------------GWC 3 IP 47 163 43 40 (ABTRK GWCEX) $ UK100 (NET_IP Y) $ $

Table SERVSINVSRVSNAME SRVRNAME NUMTERMS OPTIONS --------------------------------------------------------------------------------------------------------AUD 1 GWC 2 2048 ( ANNC 300)$ AUD 2 GWC 3 4095 (3PORT 30) (6PORT 60) (ANNC 90) $

Segment ID on MS2010

The above datafill is an example.

The actual announcement would have to be recorded and uploaded to the MS2010 Audio Server.

See course 2788.

7

0


nortel.com/training

Appendix D

Student Information

1

2


Appendix D

PurposeThis section contains additional information which the student

may find useful.

3

4

Datafill Order

XLANAMECUSTENGAUTHPARTAUTHCDECUSTHEADNCOSDIALPLANDNROUTEIBNXLAIBNTREATCLLITRKGRPTRKSGRPTRKMEMDPNSSLKDAYTYPESTODHEADDAYOWEEKDAYOYEARTIMEODAYCODECOFRT/IBNRTE/OFRxFAHEAD/CODE/RTEOFCHEAD/CODE/RTECTHEAD/CODE/RTEPXHEAD/CODE/RTELINEATTRPOECNMCALLCNTLUniversal Screening Tables – i.e; CGPNSCRN, BCSCRN, NCOSSCRN etcTRKOPTSDESTNAMEPOECRTELCRORIG/LCRORIG2LCRDEST/LCRDEST2

5

6

7

8

9

10

11

12


Date post:	11-Nov-2014
Category:	Documents
Upload:	manolo-balboa
View:	776 times
Download:	58 times

CS2000 Universal Translations.3006A 5.0 SG

Documents