Routing & translation

5060 WCS (Wireless Call
Server)
W 5.1 Translation & Routing
TMO18326 D0 SG DEN Issue 2.0

STUDENT GUIDE

All Rights Reserved © Alcatel-Lucent @@YEAR

All rights reserved © Alcatel-Lucent @@YEAR
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent

W 5.1 Translation & Routing - Page 1

Empty page
Switch to notes view!

2


5060 WCS (Wireless Call Server)

This page is left blank intentionally


Terms of Use and Legal Notices
1. Safety Warning
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.

2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including AlcatelLucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.

3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3
written consent of Alcatel-Lucent.

All rights reserved © Alcatel-Lucent @@YEAR

4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not AlcatelLucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. AlcatelLucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature

5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.


Blank Page

4





Course Outline
1. This Course
AboutT&R Process Theory

4. Topic/Section is Positioned Here

Course outline Process
1. T&R
Technical support
2. Translation provisioning
Course objectives


1. Normalization

2. Prefix Positioned
1. Topic/Section is Translation Here
Xxx
Xxx
Xxx


3. National Translation
4. International Translation


5. Modifier Based Translation

3. Routing provisioning

1. Route Liste & Bundles
2. Outpulse Maps

3. Orig Routing
4. Modifier Based Routing
4. Appendix
1. Appendix

5




Course Outline [cont.]

6




Course Objectives

Welcome to W 5.1 Translation & Routing

Upon completion of this course, you should be able to:

Identify the main uses of Translation & Routing process in the WCS
List and order the steps of T&R process
State the main purposes of each step of T&R Process
State the WCS system logic for each step of Translation
Provision translation objects
State the WCS system logic for each step of Routing
Provision routing objects

7




Course Objectives [cont.]

8




About this Student Guide
Conventions used in
Switch to notes view! this guide
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.

Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.

Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.

9


Where you can get further information


If you want further information you can refer to the following:
Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com


About this Student Guide [cont.]

10




Self-assessment of Objectives
Contract number :

At the end of each section you will be asked to fill this questionnaire
Please, return this sheet to the trainer at the end of the training

Course title :

Client (Company, Center) :
Language :
Switch

to notes view!

Number of trainees :

Dates from :

to :

Location :

Surname, First name :
Did you meet the following objectives ?
Tick the corresponding box
Please, return this sheet to the trainer at the end of the training

Instructional objectives

11

Yes (or
globally
yes)

No (or
globally
no)




Comments

Self-assessment of Objectives [cont.]
Instructional objectives

12

Yes (or
Globally
yes)

No (or
globally
no)



Other comments

Thank you for your answers to this questionnaire


Comments

Do not delete this graphic elements in here:

1—1

Section 1
T&R Process Theory
Module 1
T&R Process
3JK10613AAAAWBZZA Edition 4

5060 WCS (Wireless Call Server) — W 5.1 Translation & Routing
All Rights Reserved © Alcatel-Lucent 2007

All Rights Reserved © 2007, Alcatel-Lucent
Section 1 — Module 1 — Page 1

Blank Page
T&R Process Theory — T&R Process

1—1—




Document History
Edition

Date

Author

Remarks

2006-10-20

LAPIERRE, Laurent

First version

2007-01-22

LAPIERRE, Laurent

Updates & minor correction

2007-07-23

LAPIERRE, Laurent

New template. Minor corrections.

01

2007-08-01

LAPIERRE, Laurent

3JK reference with ED1.

02

2008-07-30

LAPIERRE, Laurent

Updated 4.4w with CLI inpulse map

03

2009-08-31

LAPIERRE, Laurent

Updated 5.0

04

2011-03

LAPIERRE, Laurent

Updated 5.1


2

Objectives

1—1—

After the completion of this module, you should be able to:

Identify the main uses of Translation & Routing process in the WCS
List the steps of T&R process
Order the steps of T&R process
State the main purposes of each step of T&R Process
List the main objects used in the GUI for T&R




3

Objectives [cont.]


1—1—




4

Table of Contents

1—1—

1 Overview
1.1 Translation & Routing environment
1.2 Process principle
1.3 Main steps
1.4 Relationship with IN-CS2 Call Model
1.5 Main objects manipulated in the GUI
2 Translation process
2.1 Translation steps
2.2 Normalization
2.3 Prefix Translation
2.4 International & National Translation
3 Routing Process
3.1 Routing steps and Origination Routing
3.2 Other Routings
4 Outpulse Map
4.1 Outpulse Map definition
4.2 Regular Outpulse Map versus Digit Outpulse Map
4.3 Regular Outpulse Maps for ISUP/BICC IAM message
4.4 Regular Outpulse Maps for DTAP, CAP and INAP msgs
4.5 Digit Outpulse Maps
4.6 Source Number manipulation
5 Modifiers
5.1 Definition and Principles
5.2 System defined and user-defined modifiers
5.3 Table of all modifiers
6 Complete process overview
6.1 notes
6.2 Complete Process Overview
7 Starting Translation Trees
7.1 Starting Translation Trees
7.2 Starting Translation Trees provisioning
7.3 Starting Translation Trees rules


Page
7
8
9
10
11
12
14
15
16
17
18
22
23
24
26
27
28
29
30
32
33
34
35
37
38
39
40
41
42
43
44
45

5

Table of Contents [cont.]

1—1—






6


1—1—

1 Overview




7

1 Overview

1.1 Translation & Routing environment

1—1—

PSTN
NETWORK

PSTN

8

ISUP Trunk Group
BSS Trunk Group
SS7/MAP

HLR

NPDB



The WCS acts as a GMSC or a VMSC.
The WCS is connected to Network Elements such as GMSC, VMSC, PSTN switches, BSCs, RNCs, ...
The WCS may process Mobile-Mobile, Mobile-Land, Land-Mobile and Land-Land calls, thanks to the
Translation & Routing process.
When the Call Server performs Translation & Routing process, as a result it routes the call or performs
a call control action.
At the end of the Translation process, an outgoing trunk group may be selected for routing the call to
the next network element (Mobile/PSTN switch or BSS).


1 Overview

1.2 Process principle

1—1—

9

2 main steps:
Translation
Routing
MSISDN, ISDN
MSRN, IMSI

Call Control Action

…

Call Context

Translation
Translation

Routing
Routing

« Destination Found »,
cont. at Orig. Routing

Outgoing Trunk Group & resources chosen



The Translation & Routing process involves two main steps:
1/ Translation Step: The call server analyze the called number and the call context to find a result
which is either:
A call control action: for example in the case of a call to a HPLMN subscriber, the call server will find
that the called number is a local MSISDN, so the right HLR has to be contacted with the « Send Routing
Information message ». This case involves the « MSISDN to HLR » table, one HLR network node and/or
the SGW configuration.
A destination: For example in the case of a mobile Originating Call to a foreign subscriber, the
translation process may set the destination to « International PSTN ». This case involves the Prefix
Tree, the International Table and Orig Routing with a route index/Orig Route descriptor « International
PSTN ». Then the call server can continue the process at the Routing step.
2/ Routing Step:
With a given destination, the call server will combine the destination of the call with the origination
modifier, to choose a Route List, then an outgoing trunk group, then a circuit (or an equivalent
resource in the case of Voice over Packet communication).
Other types of « routing modifier » do exist, for example depending of the LAC/Cell ID origination of a
Mobile Originated call.


1 Overview

1.3 Main steps

1—1—

10

Translations
MO Call

Normalization
VLR
Prefix
Translations

ISUP/BICC Call

MSRN Mobility
Check
MSISDN
Check

HLR

Routing
Route
Selection
Paging
MS term
Outpulse
Map
MS


BICC

ISUP


The Translation & Routing process involves the following steps:
Normalization (only in case of Mobile Originating Call). The number is normalized into a format that is
acceptable for VLR processing, thanks to digit manipulations. VLR processing is done: ODB, CB, CAMEL
O-CSI triggers (for prepaid calls for example).
Prefix Translation: digits can be manipulated, as well as NOA (Nature of Address). In this step, the
system logic also performs MSRN mobility check, MSISDN check (and NPDB).
Route Selection: when the destination is found, the route selection can be done. This route selection is
usually based on the destination and the Origination (from which MG or which site the call is coming ?),
but it may be based on other modifiers (e.g. CPC, IMSI calling, …).
Outpulse Map: just before the outgoing IAM is sent, outpulse maps can be used to allow additional digit
manipulations of the Called Party Number, Calling Party Number, etc.

Note that depending of the type of call (Mobile Originating Call or Network Originating
Call (ISUP)), the Translation process is not entered at the same step.


1 Overview

1.4 Relationship with IN-CS2 Call Model

1—1—

PIC: Null
DP0
Example
IN/CAMEL
Services

PIC: Collect Info
Normalization
OM

The Originating Basic
Call Model can be used
to describe the Translation &
Routing process

Prepaid
SCP

OM

DP2

11

VPN
SCP

PIC: Analyse Info
Prefix
Translations

Mobility
Checks

DP3
PIC: Select Route
Route Selection
Paging/MS Term

OM

Outpulse MAP
capability

Outpulse
Map



The O-BCSM is used to describe the actions for VMSC/GMSC during originating (VMSC) or forwarded
(VMSC or GMSC) calls.
PIC – Point in Call (O-BCSM)
The following states are applicable in this model.
>

Null

>

Collect Info

>

Analyze Info

>

Select Route

Normalization is performed in the Collect Info State. Prefix translations and Mobility checking are
performed in the Analyze Information State. Route Selection/Paging and Outpulse Map are performed
in the Selected Route state. Outpulse MAP is also performed for the SCP query.
DP2 – Collected Info
For the DP2 Trigger, the O-CSI is obtained during VLR check and DP2 TDPs are triggered at this point.
DP3 – Analyzed Info
For the DP3 trigger, the D-CSI obtained earlier from VLR check (or from the SCP after a previous DP2
query) and DP3 TDPs are triggered at this point. N-CSI triggers (switch-wide triggers, not subscription
based) are also triggered at this point.


1 Overview

1.5 Main objects manipulated in the GUI

1—1—

12

Translations
MOC

ISUP

Normalization

Normalization

Prefix
Translations

VLR

Prefix Translation

MSRN Mobility
Check

MSRN-HON Distribution table

MSISDN
Check

HLR

MSISDN to HLR table

Routing
Paging
MS term

Route
Selection

Orig Routing

Outpulse
Map
MS

Outpulse Maps
ISUP

BICC


The above drawing show you the main WEM GUI items (in the Configuration tree) associated with the
main Translation & Routing steps.


Answer the Questions – Main translation & routing steps

1—1—

Find the right place for:

13

?

ISUP Originating Call

?

Mobile Originating Call

SCP

Prefix Translation

VLR checks

?
MSRN check

Route Selection

?

SCP
HLR

Paging

Mobility check

Normalization

10 min

?


IAM Outgoing Message


1—1—





14


2.1 Translation steps

1—1—

Translations
MOC

Normalization
VLR

ISUP
paging

Prefix
Translations
MSRN Mobility
Check
MSISDN
Check

HLR

National
or
International
Translation

Routing


This draw shows an overview of the different Translation steps.


15


2.2 Normalization

1—1—

16

Only in case of MOC

Digit Tree Index
<201>

Normalization
Normalization

Called Number
in E164I

digit manipulation

« Call Control » result

ODB Check

SCP

IN OCSI DP2

Finally going
to next step


ODB, prepaid checks

V
L
R

Go at
Prefix
Tree

Possibility to loop to
other Normalization
trees


Normalization content:
Normalization is processed for Mobile Originating Calls only.
The T&R process is usually entered in the Normalization D-Tree <201>.
The “Starting translation trees” system parameters may change this default value.
One normalization entry is triggered according to the called number parameters (digit pattern,
min/max number of digits,...)
the called number is normalized, usually to comply with the E164 International format.
Other parameters (outgoing NOA, etc.) can be set.
In a simple example only one Normalization D-Tree is used, but on request the system can loop to the
same or another Normalization D-Tree (analyze based on Called Party Number), or to a Normalization
M-Tree (analyze based on other modifiers such as IMSI calling party, LAC/CellID, etc).
The system logic perform VLR checks: ODB checks, CB checks and OCSI check. If calling party has
CAMEL trigger on OCSI-DP2, the SCP will be queried. (this is a call control action)
ODB checks and OCSI checks may be bypassed on request if needed.
The next action is to go to the Prefix Translation step.
For full details on Normalization system logic and provisioning see Section 2 Module 1.
For details on Modifiers based normalization see Section 1 Module 5, and Section 2 Module 5.



2.3 Prefix Translation

1—1—

IS UP Orig inating Call

From
Norm a liza tion

NOA Routing flag
NOA
routing ?
<1>

local MSRN

incoming NOA

NOA
in IAM

Yes

No
Prefix Translation
Prefix Translation
digit manipulation
No

Paging

17

Release with
Cause Code
Prefix translator <x>

MSRN/HON Check

SCP

IN NCSI

HLR

MSISDN Check

Continue
Trans


To Routing Step


Prefix Translation content:
The MOC enters the Prefix Translation after the Normalization step, usually in the Standard Prefix Tree
<1>. The “Starting translation trees” system parameters may change this default value.
The ISUP enters first in NOA Routing. If NOA Routing is enabled in the incoming ISUP Trunk Group, the
Prefix translation step may be bypassed, or the call released, depending on the digits and incoming
NOA.
The ISUP calls do not use always the Prefix Translation D-Tree <1>. If another Prefix Translation <x> is
set in in the incoming ISUP trunk group properties, this one will be used.
One Prefix Translation entry is triggered according to the called number parameters (digit pattern,
The called number may be modified. Other parameters (outgoing NOA, etc.) can be set.IN NCSI may be
triggered on request. If yes, one SCP will be queried.
MSRN/HON check is processed. If the called number is a local MSRN (previously allocated by the same
VMSC), the mobile will be paged.
Mobility check is performed: NPDB and MSISDN check. If portability is not used only the „MSISDN to
HLR“ table is needed. The Mobility check can be bypassed on request if needed.
In a simple example only one D-Tree is used, but on request the system can loop to the same or
another Prefix Translation D-Tree (analyze based on Called Party Number), or to a Prefix Translation MTree (analyze based on other modifiers such as IMSI calling party, LAC/CellID, etc).
The next action is usually to continue translation at the National or International translation, or to go
directly at Routing step, if the destination is found. (end of translation step with destination found).
From W5.0, it is possible to play a tone or an announcement, before any repeat translation, continue
translation or go at routing step options.
For full details on Prefix Translation system logic and provisioning see Section 2 Module 2.
For details on Modifiers based Prefix Translation see Section 1 Module 5 and Section 2 Module 5.


2.4 International & National Translation

1—1—

18

From Prefix Translation

<202>
Internation
Prefix Tree

International
&
Translation

National
National
Translation
Translation

Translation
group

To Routing Step



From the Prefix Translation step, a „Continue National Translation“ will lead to National Translation
step, and a „Continue International Translation“ will lead to International Translation step.
For the International Translation:
First, the International Prefix Tree (usually D-Tree <202>) is entered. This is an optional tree where
CCNDC can be analyzed, mainly to select a dedicated destination for the call.
If a match is not found, the International Translation table is entered. This is a unique table that
contains only CC. If the called party match a CC entry (with min/max number of digits), the call will
be routed to a dedicated destination. (end of translation step with destination found).
For the National Translation:
There is one National Translation table per Translation Group.
Usually the Standard National Translation Group is used, but another National Translation may be
used if provisioned in the incoming trunk group parameters.
The National Translation table will only analyze NDC, to find a destination. (end of translation step
with destination found).
No Digit Manipulation is allowed in the International or National Translation.
No loop back to Prefix Translation step is allowed in the International or National Translation.


Answer the Questions – Normalization

1—1—

19

True or False ? Tick the following statements if they are true :
Normalization is the first mandatory Translation step
in case of Mobile Originating Call
Normalization is used, among others, to trigger the
SCP in case of prepaid call with OCSI mark DP2
Normalization is the only step in Translation & Routing
where the SCP may be triggered.

5 min
(Correct answer may require more than one choice)




Answer the Questions – Prefix Translation

1—1—

20

True or False ? Tick the following statements if they are true :
Prefix Translation is the only Translation step that
allows digit manipulation of the Called Party
for ISUP originating calls.
Prefix Translation is used only for ISUP originating calls:
for MOC, Normalization is used.
Prefix Translation is the translation step where the
called number may be recognized as a MSISDN of our
HPLMN.
5 min




Answer the Questions – National & Intern. Translation

1—1—

21

Choose the right answer:

National and International translation is a mandatory
step in Translation & Routing process, to find the
destination of the call.
National and International translation is a optional
step: the Prefix Translation may determine directly the
destination of the call, without the need of International
or National Translation.

5 min
(Correct answer requires only one choice)





1—1—

3 Routing Process




22

3 Routing

3.1 Routing steps and Origination Routing

Translation result,
destination found

1—1—

Orig Descriptor / Route Index

From Trans lation

Orig Route Modifier

Orig Routing

An Orig Routing entry combines the
origination and the destination

Route Action:
Route Immediately

The call server can choose an outgoing resource

Route List
(Bundles,
Trunk groups
and
Cause Code)

Ress ource & translated number

Outgoing NOA and digits can be modified

23

Outpuls e MAP


The Routing process is entered if the translation has ended with a „destination found“ result.
The Routing process is always entered with the Origination Routing.
The Orig Descriptor / Route Index is the destination, given from the last step of translation,
The Orig Route Modifier give the origination of the call, given in the incoming trunk group properties,
The Orig Routing will combine the destination and the origination of the call,
The result is usually a Route List if we decide to route the call immediately.
A Route List will help the system to choose an outgoing resource:
A Route List is a list a resources given with priority order. Each resource can be:
An outgoing Trunk Group,
A Bundle, which is a group of outgoing Trunk Groups in load sharing fashion,
A release with a cause code, use to release the call with a specific cause code / announcement, if
no outgoing resource is available.
Finally, with the Outpulse Map, the outgoing Nature of Address can be override, and the outgoing digits
can be modified.


3 Routing

3.2 Other Routings

1—1—

Orig Routing is the first routing,
Orig
and can be followed by:
Descriptor /

From Translation

Route Index
Orig Routing

-R3.1 legacy routings

Orig Route Modifier

Cont at (...) Routing
Routing based
on Modifiers

-Routing based
on modifiers

R3.1 legacy
Routings

CIC routing
IMSI routing
CPC routing

M-Selector with (CIC,
Routing with (CIC, IMSI,
IMSI,LAC,SAI,CLI,ToD)*,
LAC, SAI, CLI, ToD),
(CPC, OSSS, OCSI,
(CPC, OSSS, OCSI,
STL, Codec, Service)**
STL, Codec, Service,
NOA, OICK, ST, TICK)

LAC routing
OSSS routing
OCSI routing
Route
Immediately

Routing based on modifiers
is more powerful and
easier to provision.

Route List
(Bundles, Trunk groups
and Cause Code)

Ressources & translated number


ToD routing
Route
Immediately



Other routings steps can be used between the Orig Routing Step and the final step.


24

Answer the Questions – Orig Routing

1—1—

25

Right or False ? Orig Routing may be used to:
Choose next step of routing depending of the
Translation result and the Origination of the call
Choose a Route List for routing the call, depending on
the Translation result and the IMSI of the calling party
Choose a Route List for routing the call, depending on
the Translation result and the Origination of the call

5 min





1—1—

4 Outpulse Map




26

4 Outpulse Map

4.1 Outpulse Map definition

1—1—

Outpulse Map allows additional digit manipulation:
For Called Party Number, Calling Party Number, etc.
After all translation & routing steps
Just before one message is sent to another Network Element.

Main example:
To change NOA + digits of the Called Party
Just before sending the outgoing IAM.

2 different kinds of Outpulse Map objects:
Regular Outpulse Maps.
Digit Outpulse Maps.




27

4 Outpulse Map

4.2 Regular Outpulse Map versus Digit Outpulse Map

1—1—

28

Regular Outpulse Map:
One Outpulse Map for one kind of number to change.
Example: Change NOA and digit of ISUP Called Party Number.

Digit Outpulse Map:
One Outpulse Map may contain many changes in different fields, for
different numbers. (example change ISUP Called Party and Calling Party
Numbers).
More possibilities to change the number (example: insertion of LAC/CI, part
of IMSI, etc. at any part of the current number).

These 2 ways are mutually exclusive.
(one operator should use either regular OM or Digit OM - See note).
Compared to Regular Outpulse Maps, Digit Outpulse Maps are:
More efficient to use from provisioning point of view, in complex networks.
Give more possibilities to change and format the numbers.



Note:
Each operator should use either regular OM or Digit OM, for the fields (numbers) that are common to
Regular and Digit Outpulse Maps.
If there is a provioning conflict risk between the two Outpulse Map systems, a warning is displayed on the
GUI screen.
Conflicts may arise when two manipulations (regular OM and digit OM) are provisioned for the same digit
pattern. in this case digit manipulation in digit Outpulse Map takes precedence on "regular" outpulse
map.


4 Outpulse Map

4.3 Regular Outpulse Maps for ISUP/BICC IAM message

1—1—

ISUP Outpulse Map:
Change NOA and digit format of ISUP/BICC Called Party Number.

CLI Outpulse Map:
Change NOA and digit format of ISUP/BICC Calling Party Number.

RN Outpulse Map:
Change NOA and digit format of ISUP/BICC Redirecting Party Number.

OCN Outpulse Map:
Change NOA and digit format of ISUP/BICC Original Called Party Number.

These Outpulse Maps are chosen in Route List objects.




29

4 Outpulse Map

4.4 Regular Outpulse Maps for DTAP, CAP and INAP msgs

1—1—

30

Mobile Outpulse Map (for DTAP Setup message):
Change NOA/TON and digit format of DTAP Calling Party Number.

Mobile Outpulse Map (for CAP or INAP Initial DP message):
Change NOA and digit format of CAP/INAP Called Party Number.
Change NOA and digit format of CAP/INAP Calling Party Number.

For CAP/INAP, Outpulse Maps may be indexed on per SCP address basis.




Answer the Questions – Regular Outpulse Map

1—1—

10 min

In the following process, place each
regular outpulse map at the right place

?

CLI Outpulse Map

31

MOC

Normalization

CAP Called Party

SCP

?

VLR checks

? IS UP call

CAP Calling Party

MSRN check
SCP

DTAP Calling Party

?

HLR

? Paging

P refix Translation

Mobility check

?
ISUP Outpulse Map

?

Route S election




?

4 Outpulse Map

4.5 Digit Outpulse Maps

1—1—

32

One Outpulse Map may change (or not) the following fields:
Redirecting Party Number – ISUP, BICC, CAP, INAP
Original Called Party Number – ISUP, BICC, CAP, INAP
Calling Party Number – ISUP, BICC, CAP, INAP, DTAP
Location Number – ISUP, BICC, CAP, INAP
Called Party Number – ISUP, BICC, CAP, INAP
Connected Number – DTAP
Interrogate SS Forward to Number List – DTAP

One Digit Outpulse Map entry takes care of one specific change of
number, in one specific case. (like a regular Outpulse Map entry):
Change of NOA,
Insert/delete digits,
Various changes (number-dependant: APRI, SI, NI indicators, billing records)
Up to 5 Source Number Manipulation.




4 Outpulse Map

4.6 Source Number manipulation

1—1—

33

A Source number manipulation is an object that:
Extract (grab) some digits from one of the following field:
MSISDN, Redirecting Number, Original Called Number,
LAC, Cell ID/SAC, IMSI, Carrier ID, CLI, MCC, MNC, IMEI;
Will insert these digits at a specific position of an other number, when it will
be used.
Example: « extract 5 first digits of the MSISDN, insert them at position 1 »
will just « Insert the MCCMNC in front ».

The same Source Number manipulation may be reused for various
numbers in Digit Outpulse Map entries.
The Source Number manipulation may be used also for digit
manipulation of the Called Number during Normalization and Prefix
Translation.





1—1—

5 Modifiers




34

5 Modifiers

5.1 Definition and Principles

1—1—

A modifier :
is an abstracted integer, or an index;
this index represents a value or a group of values for a specific call
parameter: location of the call (LAC/CellID, SAI), calling party identity
(IMSI, CLI…), etc;
can be used to modify the translation & routing process:
In Normalization and Prefix Translation, mainly to change the called
number.
In Routing, to change to Route List that will be used.




35

5 Modifiers

5.1 Definition and Principles [cont.]

1—1—

The list of usable modifiers is not the same for Normalization, Prefix
Translation and Routing steps.
For Normalization and Prefix translation steps:
Modifiers are used in Modifier-Trees (M-Tree).
M-Trees and D-trees are sharing the same IDs; typically trees ID from <2> to
<200> may be used for user-defined Digit-Trees or Modifier-Trees.

For Routing step:
Modifiers are used in Modifier Based Routing tree objects.

An M-Tree or a Modifier Based Routing tree is analysing from 1 to 5
modifiers in a single table.




36

5 Modifiers

5.2 System defined and user-defined modifiers

1—1—

Some Modifiers are System-defined, when the values are normalized:
CPC: Calling Line Party Category
OSSS: Operator Supplementary Service Support codes
OCSI: Originating Camel Subscriber Information value
STL: Satellite Link Modifier
Codec: Incoming Codec used
Service: Bearer capability
NOA: Nature of Address

Some Modifiers are user-defined for flexibility purposes:
IMSI: IMSI pattern
LAC: LAC/cellID ranges
SAI: LAC/SAC ranges
CLI: Calling Line Identity pattern
IN Service: SCP addresses and Service Keys
ToD: Time of Day: Day and Time
CIC: Carrier Instance Code, for equal access feature
ORM: Origination Modifier (multi-site multi-MG environment)



37

5 Modifiers

5.3 Table of all modifiers

1—1—

Called Party Number Nature of Address
M obile originator’s IM SI

CLIM

Calling Line Identity

N, PT, R X
Nature of Address Routing
N, PT, R
X X X M odify translations and routing based on which PLM N
originating subscriber belongs to
N, PT, R
X X X Similar to IM SI – used to alter translations and routing
based on CLI.
N, PT, R
X X X Location Area Code + Cell Range M odifier
N, PT, R
X X X Service Area Indicator M odifier (3G)
PT, R
X
Origin or WM G modifier. Note: PT, from W4.2
PT
X X
Different translations based on Service Key and SCP adr.
PT, R
X
Calling Party Category modifier. R (ISUP only) ,PT (VLR
only), from W4.2 R (ISUP and VLR)
PT, R
X
Operator Supplementary Service Support M odifier
PT, R
X
O-CSI based modifier
R
X
X For equal access feature
R
X
Satellite Link M odifier
R
X
try to select route using same type of codec
R
X
X Time of Day modifier
R
X
X Allows non-emergency calls (e.g. NA 611, 311) to use
same location –based routing as for emergency calls.
R
X
Bearer Capability

LACM
SAIM
ORM
INM
CPCM

CGI received from BSC
SAI received from RNC
Originating Trunk Properties
SCP Address and Service Key
CPC in subscriber's profile (M OC), or in
incoming IAM (ISUP originating call)
OSSSM
OSSS code in VLR
CAM ELM IN trigger information in the VLR
CICM
Dialed CAC or subscriber profile
STLM
connection indicators received in IAM
CODECM originating trunk properties or codec
TODM
System Time
EM Z
Emergency Zone M odifier

SERVICEM bearer service or teleservice from SETUP

Purpose
usr-d for R

NOAM
IM SIM

usr-d. for N&PT

Used In
User-def.

Obtained from

System-def.

Code


This table is given for reference.
N=Normalization
PT=Prefix Translation
R=Routing

Note: EMZ modifier is only available for North America.


38


1—1—

6 Complete process overview




39

6 Complete Process Overview

6.1 notes

1—1—

40

Please see the next full comment page.
This Complete Process Overview can help you to do the exercises, and
to understand the details of the training.
Please note that :
All the loops, features, links and bypasses of the Translation&Routing
process are not given in this drawing.
This draw gives list of Digit Outpulse Maps used, not the Regular Outpulse
Maps.



Note: since W4.20, a new optional feature “International Translation Prevention” may be used:
With this option off:
For MOC and ISUP/BICC incoming calls, an International number with destination international (CC do
not match your default Country Code) will be analysed in the International Prefix Tree, typically
<202>.
For a number coming from HLR/SCP/VLR, for example a Forwarded To Number, an International
number with destination international (CC do not match your default Country Code) will be analysed
in the International Prefix Tree, typically <202>.
With “International Translation Prevention” options on:
For MOC and ISUP/BICC incoming calls, all numbers will be analyzed in the “standard” prefix trees,
for example <1>.
All numbers coming from HLR/SCP/VLR, even International, will be analyzed in the “standard” return
tree, for example the HLR Prefix Tree for a MSRN, or the CFW Prefix Tree for a Forwarded-toNumber.
This option is an internal option of the system, not dynamically configurable.


6.2 Complete Process Overview

1—1—

A5060WCS – Translation & Routing
5060 WCS W4.x - TRANS LATION & ROUTING
Process Overviews view!
Co mple te PronotesOve rvie w
Switch to c e s
L. LAPIERRE / Alcatel University Lannion
-All loops, links and features are not written.
-Tree's Index are given as examples, they
depend on Starting Translation Trees.
-Ed8 dated July 30, 2008.

Starting
<201> Starting
< 1 > Starting
<202> Starting
<203> Starting
<205> Starting
<204> Starting

Mo bile Orig inating Call
<201>
Normalization
digit manipulation
ODB Check

2

<204> SCP PT (Connect or ETC)
Resume Route Action (Continue)

SCP

IN OCSI DP2

Normalization D-Tree or
Normalization D-Tree
Normalization D-TreeI,oror
M-Tree with IMS LAC,
M-Tree with with I, LAC,
M-Tree IMS
S AI, CLI modifiers
(IMSS AI, CLI modifiers
I, LAC, S AI, CLI)*,
(NOA)**
Multiple Trees can be looped

1

Parameter set by a previous
translation step, used in this
translation/routing step


P refix trans D-Tree or
P refix trans D-Tree or
P refix tr. D-Tree or M-tree
M-Tree with IMS I, CP C,
M-Tree with IMS S AI,
with (IMS I, LAC,I, CP C,,
LAC, S AI, CLI, OS S S
LAC, AI, erv. OS S S
CLI, INI,SIN s CLI, modifiers
OCS s ervice, ORM)*, ,
OCS I, OSs erv.Camel,
(CP C, IN S S , modifiers
NOA, OICK, S T, TICK)**

Multiple Trees
5060 WCS (Wireless Call Server)can be looped
Cont. to Nat / Intern trans / Orig
Routing (only from D-Tree)

x

Digit Outpuls e Map us ed
(s ee bottom-left key)

NOA Routing flag

(only from
D-Tree)

Go at
P refix
Tree

NOA
routing ?

<1>

Translation group

No

NOA Routing
NOA Routing

Yes

Prefix Translation
digit manipulation
No

<2> to <200>
* user-defined,
** system-defined
modifiers

Repeat
Norm.

Trees used:
Normalization tree
Prefix Tree
International tree
HLR tree
CFW tree
SCP tree

incoming trunk group
parameter impacting
a translation/routing step.

V
L
R

<2> to <200>
* user-defined,
** system-defined
modifiers

41

Key

Intercept

MSRN/HON Check

local MSRN 4
Paging

IN NCSI

SCP

MSISDN Check

Repeat
P refix Tr.

NOA in IAM

HLR

2

Continue at
Orig Routing
(to Blocked CC
then Orig Routing)

Resume Route Action (Continue)
<203> HLR PT (MSRN)
<201> Normalization, then
<205> Call Forwarding PT (FTN)


Cont. to
Nat. Trans

Continue at
Orig Routing

Cont. to
Intern. Trans

Termination
Type

Screening
Class
call permission: No

Screening

Intercept

Blocked CC
match
National
National
Translation
Translation

Intercept

<202>
<202>
Internation
Internation
Prefix Tree
Prefix Tree

Translation
group

& Intern.
Translation

Orig Descriptor
(Route Index)

Orig Route Modifier
(ORM)

Orig Routing
Route
Immediately

Routing based on Modifiers

* user-defined,
** system-defined
modifiers

LAC routing
OSSS routing
Route
Immediately

2
3

4

Calling P arty Number (inpuls e map)
Calling P arty Number
Called P arty Number
Original Called P arty Number
Redirecting P arty Number
Location Number
Calling P arty Number
Connected Number
Inter. S S Forward to Number Lis t

R3.1 legacy
Routings

CPC routing

Digit Outpuls e Maps may be us ed to change:
1

CIC routing
IMSI routing

M-S elector with (CIC,
Routingelector with IMS I,
M-S with (CIC, (CIC,
IMS I,LAC,S AI,CLI,ToD)*,
LAC, S AI, CLI, ToD)*,
IMS I,LAC,S AI,CLI,ToD)*,
(CP C, OS S S , OCS I,
(CP C, C, OS S S , OCS I,
(CP OS S S , Camel,
S TL, Codec, S ervice)**
SS TL,Codec, SS ervice)**
TL, Codec, ervice,
NOA, OICK, S T, TICK)**
S ingle Modifier bas ed
routing after Orig Routing

Cont at (...) Routing

Route List

Camel routing
ToD routing
Route
Immediately

(Bundles, Trunk groups
and Cause Code)
Intercept
3
Ressources & translated number




1—1—





42


7.1 Starting Translation Trees

1—1—

43

The previous complete process overview draw gives commonly used Trees
IDs for the Translation & Routing Process.
Now it is possible to choose more freely the Starting Translation Trees:
To be able to replace usual first Normalization tree <201> and/or first
Prefix Tree <1> by other user-defined trees.
To be able to start translation with a Modifier-Tree (not only a DigitTree).
To be able to replace usual System-Trees (<204> SCP PT, <203> HLR
PT…) by other user-defined trees.



Note: Trees <1>, <201> and <202> are still predefined to provide a default handling of existing trees.



7.2 Starting Translation Trees provisioning

1—1—

44

Starting translation trees can be defined in the WEM, as
System Parameters / Call Manager:



Prefix Translation Starting Tree:
For ISUP calls, the Prefix Translation starting tree is defined in the Trunk Group Parameters.
Note: Trees <1>, <201> and <202> are always predefined to provide a default handling of existing trees.

The following pages details the rules for choosing starting translation trees.



7.3 Starting Translation Trees rules

1—1—

45

MO-SMS B-party Starting Tree :
Optional, used to block MO-SMS based on the translation result of analyzing the Bparty number

SMS Prefix Tree :
Used for SMS-SC translations
Default is <1>; modifiable to any user defined tree, typically <207>
This tree allows the translation of SMS-SC address. It is possible to use the SMS
starting tree to perform SMS-SC translations based on modifiers .

Starting Normalization Tree:
Used as First Normalization Tree for Mobile Originating Calls.
Default is <201>; modifiable to any user-defined tree.

Starting Prefix Tree:
Used as First Prefix Translation tree for Mobile Originating Calls, after Normalization.

Starting HLR Prefix tree:
Used to analyse any MSRN returned by the HLR as response of the Send Routing
Information message.
Default is <1>; modifiable to any user-defined tree, typically <203>



MO-SMS B-party Starting Tree (new from 5.0 SP7)
By default MO-SMS B-party checking is not done, The B-party check is performed only if the provisioning
flag “SmsBparty Active” is enabled. By default all MO-SMS B-party numbers are allowed.
The MSC analyzes the MO-SMS B-party number contained in RP-UserData in the prefix translations tree. If
the B-party number matches an entry during the analysis, the MO-SMS is to be blocked, and the
rejection sent to the user with RP-Cause 21 (Short Message Transfer Rejected). Otherwise, if the Bparty number does not match an entry in the prefix tree, the MO-SMS is allowed to proceed.
The B-party check is performed after the analysis of the SC address and prior to any CAMEL or INAP MOSMS query. If the result of the B-party check is to block the SMS, the CAMEL/INAP action is not
performed. If the result of the B-party check is to allow the SMS, then MSC performs the CAMEL/INAP
query. If SCP modifies the B-party address, then MSC does not reanalyze the modified digits. Note that
any digit manipulation of the SMS destination number in the prefix tree(s) does NOT change the value
of the B-party address in the MO-SMS that is sent to the SC, nor in the CDR that is generated. The
routing action upon a match in the SMS B-party prefix tree is also not relevant.
SMS Prefix Tree
This tree allows the translation of SMS-SC address in a tree separate from other translations. The
primary function of SMS-SC translations is to analyze the SMS-SC digits. Any digit manipulation or NOA
modification is preserved in the output of SMSC translation and subsequent GT routing. IMSI modifiers
are supported, but no other modifiers are supported for SMS.



7.3 Starting Translation Trees rules [cont.]

1—1—

46

Starting SCP Prefix tree:
Used to analyse the DestinationRouting Address returned by the SCP as response of
the Initial-DP message, in case of « Connect » or « ETC » message.

Starting Call ForWarding Prefix Tree:
Used to analyse any Forwarded-To-Number received from HLR or VLR.

Starting NPDB Prefix Tree:
Used to analyse a LRN from a number portability result, so that the LRN can be
concatenated with the dialed digits for ported-out numbers.

Starting OSSS Prefix Tree (to be renamed Starting PRBT Prefix Tree):
Used for the PRBT service to add the MSISDN.

Starting International Tree:
Used as first step of International Translation, before International Translation table
is invoked.



SCP Starting Translation Tree
In case of « Continue » message, the standard Prefix Translation Starting Tree is used.
It is also possible to use a M-tree based on IN modifier to perform translation differently according to
SCP address and Service Key.
NPDB Starting Translation Tree
It is used for example in New Zealand Number Portability applications so that the LRN can be
concatenated with the dialed digits for ported-out numbers.
Note that NPDB start tree cannot be provisioned (it is not used) for the North-America market.
WPS Start Tree
This tree allows the operator to populate WPS entries in a separate tree. It may be used in the NAR
(Noth-America Region) market, for the Wireless Priority Service.
E911 Start Tree (new from 4.32 SP1 or 5.1)
When the MSC is handling a mobile origination for a E911 type 1 or type 2 call, the MSC uses the E911
start tree to analyze the resulting E911 digits (ESRK, ESRD, etc). If the start tree has default value 0,
then the MSC uses the standard prefix tree 1 as the default start prefix tree. The specified tree
applies for all E911 originations, regardless of whether a GMLC, INAP, or local translations are used to
determine the routing number to the PSAP. For GMLC case, the E911 digits to be translated and
routed are contained in the MAP Subscriber Location Report Result. For INAP, the digits to be
translated/routed are contained in the Connect message; in case no digits are returned (continue
operation or timeout/error), the fallback emergency number digits are analyzed in the ESRK starting
prefix tree. The prefix tree is also used in case of timeout or error in receiving GMLC or INAP based
E911 digits.


Answer the Questions – Translation Trees IDs

1—1—

47

Associate each Tree ID to the possible usage(s)

Firs t Norm a liz a tion Tre e for MO ca lls
<2 0 1 >
Us e r-d e fin e d Tre e for Norm a liza tion

F irs t P re fix Tra n s la tion Tre e for MO ca lls
<1 >
F irs t P re fix Tra n s la tion Tre e for IS UP ca lls

<2 0 2 >

<2 > to <2 0 0 >

Us e r-d e fin e d Tre e for P re fix Tra n s la tion

S ta rtin g Tre e : In te rn a tion a l P re fix Tre e
<2 0 3 > to <2 0 5 >
S ta rtin g Tre e : HLR , S C P , CF P re fix Tre e

10 min



Answer the Questions – Trunk Group Parameters

1—1—

Can you select the ISUP trunk group parameters which have
an impact on the Translation & Routing process ?


48

10 min


Note: The incoming BSS Trunk Group parameters are similar, except for the Prefix Translator:
for MOC, the Prefix Translator used after Normalization is the Starting Prefix Tree, usually <1>.


Exercise

1—1—

Please do the exercise 1 of your Exercise Book:
„Terminating Call received at the GMSC“

Time allowed: 1h




49

Self-Assessment on the Objectives

1—1—

Please be reminded to fill in the form
for this module
The form can be found in the first part
of this course documentation




50


1—1—

End of Module
T&R Process




51


2—1

Section 2
Translation provisioning
Module 1
Normalization



Blank Page
Translation provisioning — Normalization


2—1—



Document History
Edition

Date

Author

Remarks

2006-10-20

LAPIERRE, Laurent

First version

2007-01-22

LAPIERRE, Laurent


2007-07-23

LAPIERRE, Laurent


01

2007-08-01

LAPIERRE, Laurent

3JK reference with ED1.

02

2011-03

LAPIERRE, Laurent

Update for 5.1.


2

Objectives

2—1—


Provision Normalization Digit-Tree entry.
State the purpose of Source Modifiers.
Provision Normalization Tree.
State the content of the WCS system logic
for the Normalization process.




3

Objectives [cont.]


2—1—



4

Table of Contents

2—1—

Page

1 Normalization
1.1 Normalization Content (review)
1.2 Normalization D-Tree entry: overview
1.3 Normalization D-Tree entry: identification
1.4 Normalization D-Tree entry: identif. – wild card
1.5 Normalization D-Tree entry: manipulations
1.6 Source Modifiers objects
1.7 Source Modifiers: use in Normalization entry
1.8 Normalization D-Tree entry: output
1.9 Normalization D-Tree entry: System logic
1.10 Normalization D-Tree entry: CBOI & CBOIexHC
1.11 Normalization D-Tree object




7
8
10
11
12
13
15
17
18
20
21
22
23

5


2—1—





6


2—1—

1 Normalization




7

1 Normalization

1.1 Normalization Content (review)

2—1—

8

<201>

Normalization
Normalization
digit manipulation
ODB Check

SCP

IN OCSI DP2

V
L
R

Go at
Prefix
Tree



Normalization is processed for Mobile Originating Calls only.
The T&R process is usually entered in the Normalization D-Tree <201>.
One normalization entry is triggered according to the called number parameters: digit pattern, min/max
number of digits.
The called number is normalized, usually to comply with the E164 International format.
Other parameters (outgoing NOA, etc.) can be set.
The system logic perform VLR checks: Operator Determined Barring checks, Call Barring checks and OCSI
check. If calling party has CAMEL trigger on OCSI-DP2, the SCP will be queried. (this is a call control action)
ODB checks and OCSI checks may be bypassed on request if needed.
The next action is usually to go to the Prefix Translation step, but it‘s possible to loop again to the same or
another Normalization D-Tree (analyze based on Called Party Number), or to a Normalization M-Tree
(analyze based on other modifiers such as IMSI calling party, LAC/CellID, etc).
It‘s also possible to release the call with a cause code directly in the Normalization step.


Exercise

2—1—

Please do the exercice 2 of your Exercice Book:
„Short number translation for Mobile Originating Calls“

Time allowed: 1 h 30




9

1 Normalization


2—1—

10

New D-Tree “Query & table view” in WEM GUI



The Normalization D-Tree entries are found in the WEM GUI in the context:
Office Parameters / Routing and Translation / Wireless Translation / Wireless Normalization / Digit
Translation / <Tree_Id>
The standard Normalization D-Tree is usually the Tree <201>.
This value can be changed in System Parameters: Call Manager / ‘Starting Tree Parameters’ properties.
From the release 5.1, the Digit-Trees entries are now presented with a table in the User Interface, not in the
navigation tree. You may query all entries or display only a subset of entries. It changes only the way to
access, add or modify an entry. The principle and content of a D-tree entry is the same.


1 Normalization


2—1—

11

identification

manipulations

output



In a Normalization D-Tree entry, we can split the object into 3 groups of parameters:
Identification: used to select an entry of the Tree,
Manipulations: digit manipulations, modification of called party number and other characteristics of the
call context,
Output: system logic and output of the Normalization entry.
The Manipulations and the Output parameters may have an impact on the system logic.
These parameters are detailed in the following pages.


1 Normalization

1.3 Normalization D-Tree entry: identification

2—1—

identification


12

Digit pattern,
Min and max number of digits
must match together
To select a Normalization D-Tree entry


To use one D-Tree entry, the incoming Called Number must match
The Digit String (digit pattern).
The Min digit count: minimum number of digits.
The Max digit count: maximum number of digits.
The name represent a free name, for example „National“ or „0+9D“ (for „0 plus 9 digits“).
After the entry is created, the Name and/or the Max Digit Count may be modified, but not the Digit String
or the Min Digit Count.
The system will refuse the creation of 2 overlapping entries.
If one incoming call matches more than one entry, the entry with the longest digit pattern will be selected.


1 Normalization

1.4 Normalization D-Tree entry: identif. – wild card

2—1—

identification

13

Digit String may contain
the ‘?’ wildcard.

The ‘?’ wildcard can be used for each Digit String identification
in Normalization and Prefix Translation entries



The Digit String (Digit Pattern) may contain now the ‘?’ wildcard.
So it is possible for example to create an entry that matches numbers based on the middle or last digits.
The current example: Digit String: ‘??00’, min=4, max=4 will match all the 4 digits-short numbers with ’00’
at the end.
Rules for selecting the best match are:
"the longest pattern" match is chosen.
an explicit single digit is more prioritary than the wildcard digit.
Example 1:
incoming number: 1234.
Entry A: Pattern 123, min 3, max 4.
Entry B: Pattern 12?4, min 4, max4.
The entry B is chosen since it matches 4 digits and not only 3.
Example 2:
incoming number: 1234
Entry A: Pattern 12?4, min 4, max 4.
Entry B: Pattern 1234, min 4, max 5.
The entry B is chosen since the explicit digit “3” is more prioritary than the wildcard.


Answer the question - wild card

2—1—

Look at the two following Normalization entries:

If the incoming
number is ‚1234‘,
which entry will
be selected by the
system?




5 min

14

1 Normalization

1.5 Normalization D-Tree entry: manipulations

manipulations


2—1—

15

Add/Remove digits, Start Position: modify called number.
Digit String Type: set type of call or invoque specific logic.
Echo Cancellation: override incoming trunk group specification.
Tarrif Group & Destination type: choose CDR fields content.


Manipulations allowed in a Normalization D-Tree entry are:
Digit Manipulations:
Add leading Digit Type: system defined for most countries. (NPA-NXX is US-specific)
Digit String Type: characterize the type of call: National / International / Emergency…, or modify the
system logic to invoke a Service: CLIP / CLIR...
Start Position: used in conjunction with Remove/Add leading digits to remove or add digits in the current
cumber. Start Position 1: at beginning, Start Position 255: at the end.
Remove Leading digits: number of digits to remove in the number.
Add Leading digits: digits to add in the number.
The ‚remove digits‘ action is always performed BEFORE the ‚add digits‘ action.
Country Code: the default country code and be quickly added in front of the number with this feature.
Other Manipulations:
International Prefix Length: if not 0, give the length of the International Prefix in the number, so the
system can check properly the International Barings, even if the number still contains a Prefix before the
Country Code.
Echo cancellation: ‚Default As Trunk CFG‘ means that the use of echo cancellation is determined by the
incoming trunk group properties. But it‘s possible to force at on or off the echo cancellation, and to
override the incoming trunk parameter.
CDR / Tariff Group and Destination Type: the Tariff Group and Destination Type will be written in the CDR
for this call. It‘s possible to select them with the Normalization.
Tariff Groups and Destination Types are created in ‚Office Parameters/Billing Parameters‘.
Other steps of Translation may select Tariff Group and Destination Type. During the
Translation&Routing process for one call, if Tariff Group and Destination Types are modified several
times, only the last values will be recorded in the CDR.

1 Normalization

1.5 Normalization D-Tree entry: manipulations [cont.]

manipulations

2—1—

16

Modify Digit Source is a way to insert values from the call context
in the current analyzed called number.
Source Number x are references to Source Modifiers objects.



Manipulations allowed in a Normalization D-Tree entry are:
Digit Manipulations / Modify Digit Source:
Digit Source manipulation is a way to insert values from the call context in the current analyzed called
number.
The following numbers (or parts of) can be added:
MSISDN
Redirecting Number (Forwarding Number)
Original Called Number
Original Dialed Number (pre-translated dialed Number)
CLI
LAC (5 Digits BCD representation)
SAC (5 Digits BCD representation)
Cell ID (5 Digits BCD representation)
MCC (of the originating cell)
MNC (of the originating cell)
IMSI
Carrier ID
IMEI
The digits from the above numbers can be added at the beginning, end of, or anywhere in between the
Called Number in translations.
This is provisioned with “Source Modifier” objects.
Up to 5 different source numbers from above can be selected to modify the specified called party number
in specific order.

1 Normalization

1.6 Source Modifiers objects

2—1—

17

Source Modifiers are created in Outpulse Maps / Digits Manipulations.
Then they can be used in Digit Outpulse Map entries, and in Normalization or Prefix
Translation entries.



Source Modifiers are created in Outpulse Maps / Digits Manipulations.
Each Source Modifier object:
Extract some digits from a given Source Number (example: IMSI).
Digit to grab: number of digit to grab.
Start Position: define where to grab digits (1=at the beginning).
Default Digits: indicates the digits to use in place of grabbing digits if the Source Number is not available.
Insert position: define where to insert the grabbed digits, when the Source Modifier is used.
Maximum values for Start Position and Digit to grab are:

If no digits are found at the start position then
the provisioning entry is ignored.
If only partial digits are present at the start position then
only the partial digits are inserted.
LAC, Cell ID/SAC are two bytes fields, value from 0 to 65535.
These numbers will be converted to 5 ASCII digits format by
padding leading 0 to make up 5 digits.
For example, if the Cell ID is 1, then the padded Cell ID is ’00001’.

MS IS DN
LAC
Cell ID/S AC
IMS I
Carrie r ID
Redire cting Number
Original Ca lled Numbe r
Original Dia led Numbe r
Calling P arty Number (CLI)
MCC
MNC
IMEI


32
5
5
15
4
32
32
32
32
3
2 or 3
15

1 Normalization

1.7 Source Modifiers: use in Normalization entry

2—1—

18

manipulations

« Insert MCCMNC of the
calling subscriber in front
of the current called
number »


When used in a Normalization tree entry, a Modify Source Number modification refers to an Source Modifier
object defined in “Outpulse Map / Digit Manipulation / Source Modifier”.


Exercise – Source numbers

2—1—

Please do the exercise 3 of your Exercise Book:
„ Source Modifiers “

Time allowed: 0 h 15




19

1 Normalization

1.8 Normalization D-Tree entry: output

2—1—

20

output

Next translation action


Optional Output NOA change


The Route Action will modify the system logic and determine the next step of T&R process:
Check VLR, start at Prefix Trans: check CB and ODB, check IN OCSI, if both passes, go to Prefix
Translation. (usual case)
No VLR check, start at Prefix Trans: do not check CB neither ODB, do not check IN OCSI DP2, go directly to
Prefix Translation (for example for emergency calls).
Skip OCSI-DP2, start at Prefix Trans: check CB and ODB, do not check IN OCSI DP2, go to Prefix Trans.
Skip barring, start at Prefix Tree: do not check CB neither ODB, check IN OCSI DP2, then go to Prefix Tr.
For the 4 above cases, the Prefix Translation Tree used will be the “Starting Prefix Tree”, usually <1>.
Intercept: a cause code must be selected. In most of cases it leads to a call release.
Repeat Wireless Normalization: loop to a Normalization D-Tree or M-Tree. A Tree Index must be selected.
The Outgoing NOA can be modified or chosen:
No Change: not change, the actual NOA value will be kept.
Translated: the NOA value will be determined by the system logic according to the incoming NOA value,
Digit String Type and digit manipulations.
Other value: the NOA can be manually chosen.
International Destination (only if the system is internally configured with
“International Translation Prevention” option off):
If NOA is set to International, and the destination is International (CC do not match default Country
Code), after the Normalization step, the system logic will go directly in the International Prefix Tree
(usually <202>). See Section 2 Module 4 „International Translation“ for more details.


1 Normalization

1.9 Normalization D-Tree entry: System logic

2—1—

21

<201>
Normalization
digit manipulation
ODB Check

OM
Resume Route Action (continue)

SCP

IN OCSI DP2

V
L
R

Release with
Cause Code

<2> to <200>
Normalization D-Tree or
Normalization D-Tree
* user-defined, Normalization D-Tree oror
M-Tree with IMSI, LAC,
M-Tree withwith LAC,
** system-defined
M-Tree IMSI,
SAI, CLI modifiers
SAI, CLI modifiers
modifiers (IMSI, LAC, SAI, CLI)*,
(NOA)**

Repeat
Norm.

Multiple Trees can be looped
(only from D-Tree)


Go at
Prefix
Tree

Release with
Cause Code


Depending of the Route Action, the system will perform this logic:
CB and ODB checks: VLR check of Call Barings and Operator Determined Barings, with the modified number.
IN OCSI DP2: VLR check of OCSI triggers. If OCSI DP-2 trigger is armed:
Digit Outpulse Maps (for Redirecting Party Number, Original Called Party Number, Location Number,
Called Party Number) or Mobile Outpulse Maps: CAP/INAP Calling Party and CAP/INAP Called Party are
used.
The SCP is queried. (Note: query can be done with the dialed number thanks to the internal system
parameter "DP2useDialedNumber")
Depending of the result of the query:
SCP answers „Continue“: the system resume the route action, typically with Prefix Translation Starting
Tree, usually Standard Prefix Tree <1>.
SCP answers „Connect“ or „ETC“: the system jump to Prefix Translation with SCP Starting Translation
Tree (for example SCP Prefix Tree <204>).
If Route Action is set to „Repeat Prefix Translation“, the same or another Normalization tree is used.
The system allows up to 8 trees in a loop.
Please refer to Module 2 Section 5 for details about Normalization based on Modifiers.
‚+‘ dialing: in case of Mobile Incoming Call with ‚+‘ dialing, the system automatically adds the International
Prefix (for example “00” or “011” before the number) and replace the Type of Number INTERNATIONAL with
an input NOA "Unknown" before entering Normalization.


1 Normalization

1.10 Normalization D-Tree entry: CBOI & CBOIexHC

2—1—

22

FPLMN
FPLMN

MS
MS

HPLMN

Outgoing
international
calls (CBOI)

FPLMN

Outgoing international calls except
to the home country (CBOIEXHC)



CBOI: Call Barring Outgoing International Calls.
CBOICexHC: Call Barring Outgoing International Calls except those directed to the Home Country
If the „Home Country“ is only determined by your CC, no other provisioning is needed:
For CBOI and CBOIexHC, the system will compare the CC of the Called party with any “Own MSC” CC. If
a match is found, the call is National, and is allowed.
For CBOIexHC only, the system will compare the CC of the Called Party with the CC of the Calling Party
Number. If a match is found, the call is to the Home Country, and is allowed.
If a country/region CCNDC must be considered „Foreign“ even if CC=your Home Country CC:
in Office Parameters/Mobility Config Parameters/Country Info:
Create one ‚Country/Region ID‘ with barring = International
In Office Parameters/Mobility Config Parameters/Digit Prefix:
Create one or more ‚Digit Prefix‘ associated with the previous Country/Region ID.
If a country/region CCNDC must be considered „Home Country“ even if CC is different from your Home
Country CC:
in Office Parameters/Mobility Config Parameters/Country Info:
Create one ‚Country/Region ID‘ with barring = National
In Office Parameters/Mobility Config Parameters/Digit Prefix:
Create one or more ‚Digit Prefix‘ associated with the previous Country/Region ID.

Note: this logic is used for the corresponding ODB as well.


1 Normalization

1.11 Normalization D-Tree object

2—1—


23


Normalization D-Trees are created in the following context:
Routing and Translation / Wireless Translation / Wireless Normalization / Digit Translation
Normalization D-Tree is identified by:
A unique ID, in the range [1-255]. Typically, ID <2> to <200> can be used for user-defined Trees.
A free name.
The Tree Type is always “Wireless Normalization”.
Once a Normalization D-Tree is created, only the name can be modified, not the ID.
To delete a Normalization D-Tree, it‘s mandatory to have this tree not used by the translation process
actually. (that is, no Normalization entry that loops to this Normalization D-Tree).

Note: for Normalization M-Tree, creation please refer to Section 2 Module 5.



2—1—

Please be reminded to fill in the form
for this module
The form can be found in the first part
of this course documentation




24


2—1—

End of Module
Normalization




25


2—2

Section 2
Translation provisioning
Module 2
Prefix Translation



Blank Page
Translation provisioning — Prefix Translation


2—2—



Document History
Edition

Date

Author

Remarks

2006-10-20

LAPIERRE, Laurent

First version

2007-01-22

LAPIERRE, Laurent


2007-07-23

LAPIERRE, Laurent


01

2007-08-01

LAPIERRE, Laurent

3JK ref ED1. MNP SRF introduced.

02

2008-07-04

LAPIERRE, Laurent

MNP Ported-in modifications for W4.21,
Inpulse map for W4.4x

03

2009-08-31

LAPIERRE, Laurent

Updated for W5.0

04

2011-03

LAPIERRE, Laurent

Updated for W5.1


2

Objectives

2—2—


Provision Prefix Translation Digit-Tree entry.
Provision Prefix Translation D-Tree.
State the content of the WCS system logic
for the Prefix Translation process.




3

Objectives [cont.]


2—2—




4

Table of Contents

2—2—

Page

1 Prefix Translation
1.1 Prefix Translation content (review)
1.2 NOA Routing
1.3 Prefix Tree entered & CLI inpulse manipulation
1.4 PT D-Tree entry: overview
1.5 PT D-Tree entry: identification
1.6 PT D-Tree entry: manipulations
1.7 System logic: overview
1.8 System Logic: MSRN/HON Check
1.9 PT D-Tree entry: IN NCSI
1.9 PT D-Tree entry: IN NCSI / SCP Node and Bundles
1.10 PT D-Tree entry: Output
1.10 PT D-Tree entry: Output – Call Gapping
1.10 PT D-Tree entry: Output – Insert tone / announcement
1.11 Mobile Number Portability - overview
1.12 System Logic: Mobility Check: NPDB IN solution
1.13 System Logic: Mobility Check: NPDB SRF solution
1.14 System Logic: MSISDN to HLR table
1.15 System Logic: Screening
1.16 System Logic: Blocked Country Code + NPA
1.17 PT D-Tree object




7
8
9
10
12
14
15
17
18
19
20
21
22
23
24
26
27
29
30
31
32

5


2—2—






6


2—2—





7


1.1 Prefix Translation content (review)

2—2—


From
Norm a liza tion

NOA Routing flag
NOA
routing ?
<1>

local MSRN

NOA
in IAM

incoming NOA
Yes

No
Prefix Translation
Prefix Translation
digit manipulation
No

Paging

8

Release with
Cause Code

MSRN/HON Check

SCP

IN NCSI

HLR

MSISDN Check

Continue
Trans


To Routing Step


Prefix Translation content:
The MOC enter the Prefix Translation Starting Tree (usually <1>) after the Normalization step.
The ISUP enters first in NOA Routing. If NOA Routing is enabled in the incoming ISUP Trunk Group, the
Prefix translation step may be bypassed, or the call release, depending of the digits and incoming NOA.
The ISUP calls do not use always the Prefix Translation Starting Tree. If another Prefix Translation <x>
is set in in the incoming ISUP trunk group properties, this one will be used.
One Prefix Translation entry is triggered according to the called number parameters (digit pattern,
the called number may be modified. Other parameters (outgoing NOA, etc.) can be set.
IN NCSI may be triggered on request. If yes, one SCP will be queried.
MSRN/HON check is processes. If the called number is a local MSRN (previously allocated by the same
VMSC), the mobile will be paged.
Mobility check is performed: NPDB and MSISDN check. If portability is not used only the „MSISDN to
HLR“ table is needed. The Mobility check can be bypassed on request if needed.
In a simple example only one D-Tree is used, but on request the system can loop again to the same or
another Prefix Translation D-Tree (analysis based on Called Party Number), or to a Prefix Translation MTree (analysis based on other modifiers such as IMSI calling party, LAC/CellID, etc).
The next action is usually to continue translation at the National or International translation, or to go
directly at Routing step, if the destination is found. (end of translation step with destination found).
The next pages will detail all the system logic associated with Prefix Translation, and the Prefix
Translation Digit Tree provisioning.



1.2 NOA Routing

2—2—

9

Nature of Address Routing is a way to modify or bypass translation:
Only for ISUP incoming calls.
Only for specified ISUP trunk groups with ‘NOA Routing=Enabled’,
Depending on the NOA field in the incoming IAM.

Now NOA Routing may be replaced by NOA Modifier Translation, which
is more efficient and more powerful.


NOA Routing is provisioned in this context:
Office Parameters/Routing and Translation/NOA Routing/Route/
One table can be created for each Translation Group (usually only Translation Group 1 is created).
Each entry in the table :
Is identified by the incoming NOA. (description is a free name).
May modified the called number by removing and/or adding digits.
Modify the translation process with one Route Action:
No Mob. Check Cont. At Orig Routing: bypass the translation process
(Digit Type and Route Index must be provided),
Intercept: release the call (a Cause Code must be provided).
Cont. At prefix Translation: resume the normal Translation process at the Prefix Tree.
If one NOA is not provided in the tree, (or if the tree itself is not created), the call will be accepted
and will go to the Prefix Tree.
Now NOA Routing may be replaced by NOA Modifier Translation, which is more efficient and more
powerful. For NOA Modifier translation details please refer to Section 2 Module 5 « Modifier Based
Translation ».



1.3 Prefix Tree entered & CLI inpulse manipulation

2—2—

10

For Mobile Originating Call: Starting Prefix Tree
(usually Standard Prefix Tree <1>) is used after Normalization.
For ISUP Originating Call: depends on the incoming Trunk:



For an ISUP/BICC incoming call, the Prefix Translator entered if one important parameter of the
incoming Trunk.
Note also that for an ISUP/BICC incoming call, prior to enter the Prefix Translator, it is possible to
modify the Calling Party Number (Calling Line Identity):
Depending on the incoming ISUP/BICC trunk and incoming digits/NOA of the Calling Party Number :
Cli Inpulse Map Index used is a parameter of the incoming Trunk, see above.
For example of CLI Inpulse Map entry, see next slide.
The first purpose of the Cli Inpulse Map is for Local Large Network (LLN – used in China), to be able to
add the area code in the calling party for incoming PSTN call.



1.3 Prefix Tree entered & CLI inpulse manipulation [cont.]

2—2—

CLI inpulse Map entry example:

identification


manipulations


In this CLI Inpulse Map entry example:
If the call is coming from an ISUP/BICC Trunk with CliInpulseMap Index = 2,
If the incoming calling number is NOA=National, begin by digit 8, and has from 8 to 10 digits,
Then:
The incoming calling number is prefixed with leading digits 511,
The NOA is not change,
The CDR will contain the initial Calling Number, not the modified one.
Note that:
Inpulse Digit Type is always „CLI Inpulse map“.
Inpulse Node ID and Inpulse Service Key are not significant and are reserved for a future use.


11

Routing & translation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Routing & translation

Similar to Routing & translation (20)

Recently uploaded

Recently uploaded (20)

Routing & translation