Sie sind auf Seite 1von 92

CN34017EN30GLN1

Nokia Siemens Networks



1 (92)


3G Rel4 SCNOM


Routing in MSS







Routing in MSS

2 (92) Nokia Siemens Networks

CN34017EN30GLN1

Legal notice
Intellectual Property Rights
All copyrights and intellectual property rights for Nokia Siemens Networks training documentation, product
documentation and slide presentation material, all of which are forthwith known as Nokia Siemens Networks training
material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying,
modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens
Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the
Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their
own personal self-development only, those same individuals cannot subsequently pass on that same Intellectual
Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks
training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of
groups without the prior written agreement of Nokia Siemens Networks.
Indemnity
The information in this document is subject to change without notice and describes only the product defined in the
introduction of this documentation. This document is intended for the use of Nokia Siemens Networks customers only for
the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced,
modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The
document has been prepared to be used by professional and properly trained personnel, and the customer assumes full
responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of
continuous development and improvement of the documentation.
The information or statements given in this document concerning the suitability, capacity, or performance of the
mentioned hardware or software products are given as is and all liability arising in connection with such hardware or
software products shall be defined conclusively in a separate agreement between Nokia Siemens Networks and the
customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained
in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed
necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.
Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT WILL NOKIA SIEMENS
NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT
LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARY
LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS
OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT
This document and the product it describes are considered protected by copyrights and other intellectual property rights
according to the applicable laws.
Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation.
Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective owners, and they are
mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2009. All rights reserved.

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

3 (92)

Contents
1 Objectives...............................................................................................5
2 MSS Server Concept ..............................................................................6
3 Control Plane Routing ...........................................................................8
3.1 The Routing Concept ...............................................................................9
3.2 Dialling Pre-analysis...............................................................................11
3.2.1 General view of pre-analysis..................................................................11
3.2.2 Types of pre-analysis .............................................................................13
3.2.3 Use of pre-analysis.................................................................................15
3.3 Origin Analysis .......................................................................................22
3.3.1 Input .......................................................................................................23
3.3.2 Results ...................................................................................................24
3.4 End of Selection Analysis.......................................................................25
3.4.1 Input .......................................................................................................26
3.4.2 Results ...................................................................................................26
3.5 Digit Analysis..........................................................................................27
3.5.1 Input .......................................................................................................28
3.5.2 Results ...................................................................................................30
3.5.3 Routing and Charging Components.......................................................42
3.5.4 Creation of Digit Analysis .......................................................................44
3.6 Area Service Analysis ............................................................................45
3.6.1 Input .......................................................................................................45
3.6.2 Process ..................................................................................................46
3.6.3 Results ...................................................................................................46
3.7 Attribute Analysis....................................................................................49
3.7.1 Attributes ................................................................................................49
3.7.2 Final result for attribute analysis.............................................................51
3.8 AIF Attribute Analysis.............................................................................55
3.9 Summary................................................................................................56
4 User Plane Routing..............................................................................57
4.1 User Plane Analysis ...............................................................................59
4.1.1 Parameters of User Plane Analyses ......................................................59
60
4.1.2 Six Phases in User Plane Analyses .......................................................61
4.2 User Plane Topology Database .............................................................64
4.2.1 User Plane Destination...........................................................................64
4.2.2 User plane topology between MGWs.....................................................67
5 Relationship Between User Plane and Control Plane
Routing..................................................................................................70
5.1 RANAP Signalling ..................................................................................70
5.2 BICC and SIP Signalling ........................................................................71

Routing in MSS

4 (92) Nokia Siemens Networks

CN34017EN30GLN1

6 MGW Selection .................................................................................... 73
6.1 MGW Selection Basic Functionality....................................................... 73
6.1.1 Weight-based MGW selection............................................................... 75
6.2 Call Mediation Node .............................................................................. 77

APPENDIX A: OPTIONAL ANALYSES................................................................. 79
1 Bearer Capability Analysis..................................................................... 79
1.1 Input....................................................................................................... 79
1.2 Process................................................................................................. 80
1.3 Output................................................................................................... 80
2 Call Barring Analysis ............................................................................. 80
2.1 Input...................................................................................................... 81
2.2 Process.................................................................................................. 82
2.3 Results.................................................................................................. 83
3. Priority Analysis..................................................................................... 84
5. Function Analysis .................................................................................. 86
5. A and Iu Multipoint (additional) .............................................................. 88





Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

5 (92)

1 Objectives
On completion of this module, you should be able to:
Draw the routing hierarchy in MSS concept and compare route
concept in ATM, IP and TDM transport alternatives
MGW routing data creation in MSS
Integrate BICC routing data configuration towards a MSS
Integrate SIP and ISUP routing data configuration

Routing in MSS

6 (92) Nokia Siemens Networks

CN34017EN30GLN1

2 MSS Server Concept
MSC Server (MSS) can be deployed in an operator's 2G network by integrating the MSS
functionality into an existing MSCi, or as a standalone network element. The MSC
functionality is split into two distinct logical entities. The MSS handles call control and
controls Multimedia Gateways (MGW). The MGW, on the other hand, handles user plane
traffic.


Figure 1 Routing connections in Rel.4

The following figure illustrates the network architecture. Separating the control plane from the
user plane makes it easier for the operator to configure the network in one MSC server area.


Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

7 (92)

MSCi - M11 MSCi - M11
Rel99 Rel99
A' A'
Iu-CS Iu-CS
MSS
M12
MSS
M12
Rel 4 Rel 4
Packet based
Backbone (IP/ ATM)
& TDM based PSTN
Packet based
Backbone (IP/ ATM)
& TDM based PSTN
TDM based
Backbone & PSTN
TDM based
Backbone & PSTN
A A
A & Iu-CS A & Iu-CS
user lane user lane
control plane control plane
H.248/ Megaco
Sigtran
MSCi - M11 MSCi - M11
Rel99 Rel99
A' A'
Iu-CS Iu-CS
MSS
M12
MSS
M12
Rel 4 Rel 4
Packet based
Backbone (IP/ ATM)
& TDM based PSTN
Packet based
Backbone (IP/ ATM)
& TDM based PSTN
TDM based
Backbone & PSTN
TDM based
Backbone & PSTN
A A
A & Iu-CS A & Iu-CS
user lane user lane
control plane control plane
H.248/ Megaco
Sigtran


Figure 2 MSS Routing in Rel99 & Rel4
The MSS handles the following types of resources:
Time Division Multiplex (TDM) resources. There are two types of
TDMs, that is, Local TDMs, connected to the MSS and Quasi
TDMs, connected to the MGW.
Asynchronous Transfer Mode (ATM) resources
Internet Protocol (IP) resourcesOn completion of this module, you should be able to:

Routing in MSS

8 (92) Nokia Siemens Networks

CN34017EN30GLN1

3 Control Plane Routing
In UMTS Rel4, the control plane and user plane routing functions have been separated. The
control plane routing closely corresponds to the current routing and analysis functions.
A new attribute (BNC characteristic) is introduced which can be used to affect the control
plane analysis with the help of routing, charging and EOS attribute analyses, and extended
pre-analysis. A new result parameter in the control plane routing, User Plane Destination
Reference (UPDR) is added to provide input to the user plane routing functions and
analyses. UPDR is defined on the circuit group or route level.
This functionality is common both to the MSC and the MSC Server and applies to 2G and 3G
networks. It is implemented according to Release 4 specifications.
The functionality is as follows:
Support for the existing call control functionality
Provision of the necessary information for user plane control
Inter-working with new call control signalling such as SIP and
BICC
The analysis services of the MSC/MSS are offered by the programs of the central memory
(CM) and the call control, and they are used by the call control program blocks. The
exchange may execute the following analyses:
Internal call control analyses: origin analysis, priority analysis,
dialling pre-analysis, extended pre-analysis, bearer capability
analyses (GSM and ISDN), end-of-selection analysis, function
analysis, charging attribute analysis, routing attribute analysis,
end-of-selection attribute analysis, and AIF attribute analysis.
Routing and charging analysis in the CM
Charging modification analysis in the CM (Optional)
Call barring analysis in the CM
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

9 (92)

3.1 The Routing Concept
Characteristics of
Incoming Circuit Group
Characteristics of
Subscriber A
Dialled Digits
Analysis
Outgoing
speech route
Special
Handling
Hunting
Outgoing circuit
1 Obtain information
about a call 2. Perform
various
analyses
3. Obtain
destination
4. Route out the call

Figure 3 Routing Concepts
The routing concept is illustrated in Figure 3. It basically consists of four parts:
Obtain information about a call
Perform various analyses
Obtain destination
Route out the call.

Based on the origin of the call, it can be categorised into one of the two groups:
1. Mobile Originating Call (MOC); the call has originated from a cell
under the current MSS/MSC.
2. Trunk Originating Call (TOC); the call has been routed to the
current MSS/MSC from the PSTN, another MSS/MSC or a PABX
connected to the current MSS/MSC.
In order to select the proper destination for the call, several different analyses are performed
in the MSS/MSC. However, it should be noted that not all calls have to undergo all the
analyses. Depending on the nature of the call it might undergo only some of the analyses.
The explanations are based for four different types of calls:
1. Normal calls: These are the ordinary types of call where A party
desires to have a conversation with B party.
2. Service calls, where A party dials a short code, which he knows
will connect him to a certain service provider.

Routing in MSS

10 (92) Nokia Siemens Networks

CN34017EN30GLN1

3. Emergency calls, where A party dials a short code, which
connects him to a certain emergency centre.
4. Data calls, where data is being transferred between the two
parties with at least one of them being a UMTS/GSM subscriber.
DIGIT
ANALYSIS
CM
BEARER
CAPABILITY
ANALYSIS
DIALLING
PREANALYSIS
AIF
ANALYSIS
ROUTING &
CHARGING
ATTRIBUTE
ANALYSIS
CALL
BARRING
ANALYSIS
CM
EOS
ATTRIBUTE
ANALYSIS
REASON
CODE (CD_T)
OR
FACILITY
CODE
REASON
CODE (CD_T)
FUNCTION
ANALYSIS
*2
EOS
ANALYSIS
*1
ORIGIN
ANALYSIS
*3
*1 can be executed in several different call phases
*2 can be executed only in speech state
*3 is executed only in mobile originated calls
CHARGING
MODIFICATION
ANALYSIS
*4
*4 is executed in MOC and MTC in the call setup phase

Figure 4 Routing Analyses.

Figure 4 shows different analyses in the MSC and gives the order in which the analyses are
performed. Some of the analyses are compulsory, see Figure 5, which means that without
these analyses all calls are dropped. In this module, the main focus lies on the functions of
the following compulsory analyses:
Bearer Capability Analysis (optional)
Dialling Pre-analysis
Origin Analysis
Digit Analysis
End-Of-Selection Analysis.
The other analyses in Figure 45 are utilised according to the user networks.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

11 (92)

Dialing
Preanalysis
Digit
analysis
Area
service
analysis
Service/
Emergency
call
Normal call
Destination
Tree
selection
Normal call
Origin
analysis
EOS
analysis

Figure 5 Execution Orders of Analyses
3.2 Dialling Pre-analysis
The purpose of pre-analysis is to examine the numbers being dialled in order to establish the
type of call being made.


For voice calls, the call can be identified as:
Normal
Emergency
Service
Normal calls can be local, national, or international. The other types of calls are local calls.
3.2.1 General view of pre-analysis
As illustrated in Figure 66, the parameters used as inputs to pre-analysis are:
The dialled digits
Numbering Plan Indicator (NPI)

Routing in MSS

12 (92) Nokia Siemens Networks

CN34017EN30GLN1

Type Of Number (TON)

DIALLED DIGITS
ANALYSIS
FILES
ANALYSIS
RESULT
FILE
TYPE OF NUMBER
NUMBERING PLAN INDICATOR
RESULT IDENTIFIER
CALL CHARACTERISTICS
SERVICE TYPE
NBR OF REMOVED DIGITS
START POINT OF REMOVAL
CHARACTERISTIC OF NUMBER
NUMBERING PLAN ID.
ODC
ESTP
CLIR INFO

Figure 6 Dialling Pre-analysis

The tasks of pre-analysis are to:
Identify the type of call: a normal call, an emergency call, or a
service call
Send the dialled digits' modification instructions to call control; for
example, to remove or add dialled digits
Translate the nature of the address information, specified with
prefixes and TON values, based on Characteristics Of Number
(CON)
Identify whether a call made from a mobile phone is a local call.
Recognise a certain dialling pattern from a mobile phone in order
to proceed to routing based on Calling Line Identity (CLI)
Recognise certain prefixes carrying information about the calling
subscriber, such as whether the CLI is allowed to be shown to the
called party
Classify dialling with Original Dialling Class (ODC)
Order the execution of extended pre-analysis
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

13 (92)

Example
A subscriber dials the following number in Finland: 050-1234567. The information displayed
in Figure 7 is sent by the signalling interface to the MSC/MSS:

Number of removed digits
Characteristic of number
Numbering Plan
Call Characteristic
Result Identifier
Numbering Plan
Type Of Number
Dialled Digits
Dialling
Preanalysis
050 1234567
UNKNOWN
E.164
(ISDN/Telephony)
Continue call setup
Normal call
E.164 (ISDN/Telephony )
National
1
Digits after preanalyis = 50 1234567

Figure 7 Example of Dialling Pre-analysis Input and Output Parameters
3.2.2 Types of pre-analysis
Pre-analysis is divided into two types: normal pre-analysis and default pre-analysis. Both
MOC and TOC require both types of pre-analysis.
Number formats provide information to decide on further action.
3.2.2.1 Number formats
A telephone number is made up of five main component parts:
1. International prefix. Also called the international access code. It
varies from country to country. It is often 00 or 001 or something
similar.
2. Country code (CC). Every country in the world is assigned a
number to identify it in telephone calls. For example, the USA is 1,
Great Britain is 44, and Australia is 61.
3. National Prefix. Used only when making calls inside the home
country. Usually 0.
4. National Destination Code (NDC). Also called the area code.
Identifies different areas of a country or region.

Routing in MSS

14 (92) Nokia Siemens Networks

CN34017EN30GLN1

5. Subscriber Number (SN). The number of the called party.

When a subscriber makes a call, there are three main ways to dial the
number.
1. International call. Subscribers calling outside of their own
countries use the following format:
International
Prefix+CC+NDC+SN
2. National call. This is a call that is made within the home country,
but outside of the callers local area. The dialled number must
start with the national prefix, which is usually "0". The format looks
like this:
National Prefix + NDC + SN
3. Local call. Subscribers calling within the same NDC area dial the
subscriber number without any prefix, as in the following format:
SN

Methods of dialling depend on country and operator. It is not compulsory
to follow these three formats. For example, Singapore and Hong Kong
do not have different network destinations, and therefore no NDCs,
because of the small network area.
Also note that the format of the dialled number is different for the North
American Numbering Plan.
3.2.2.2 Normal pre-analysis
Incoming digits from a call setup are first examined for any exceptional cases, where the
dialled digits do not follow the main three formats. The analysis of these digits is called
normal pre-analysis.
In TOC, the normal pre-analysis only needs definitions for call-forwarding (CFW) numbers.
In MOC, Normal Pre-analysis handles digits as follows:
Service numbers
Emergency numbers (112 is NOT handled by pre-analysis)
Exceptional dialling (International prefix + OWN country code or
OWN country code following the + sign).

Note
The emergency number, 112, does not need pre-analysis, but still needs
area service analysis.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

15 (92)

3.2.2.3 Default pre-analysis
If the incoming digit combination is not found in the normal pre-analysis definitions, then it is
searched for in the international and national prefix analyses. This part of the pre-analysis is
called Default Pre-analysis. In Default Pre-analysis, the rest of the digit combinations
(incoming digits without any national or international prefix) should also be handled. Default
Pre-analysis is needed for both MOC and TOC.
Table 1 Use of Normal and Default Pre-analysis
MOC TOC
Normal pre-analysis - service calls
- emergency calls (except 112)
- exceptional dialling (see above)
- CFW-numbers
Default pre-analysis - normal calls (handling prefixes,
e.g. 0, 00 or no prefix at all)
- handles prefixes and
various values of TON

3.2.3 Use of pre-analysis
If normal and default pre-analysis do not have a matching entry, the system generates an alarm, see
Figure 8 Mismatch Dialled Digits in Pre-analysis
Figure 8, and the call is dropped. This process is shown in Figure
9.


MSC-CSC BSU-1 SWITCH 2000-12-12 15:06:27.23
** ALARM BSU-1 1F109-00 IC2_SS
(0102) 2186 CALL CONTROL ANALYSIS MISSING
02 0002 00 0F 55 35 85 A5 AA AA A1 D0 00 00 00

Routing in MSS

16 (92) Nokia Siemens Networks

CN34017EN30GLN1

MOC TOC
Normal preanalysis
Default preanalysis
ALARM

Figure 8 Mismatch Dialled Digits in Pre-analysis
Figure 9 2186 Alarm
3.2.3.1 The input of the pre-analysis
The different values of each input parameter for MOC and TOC are displayed in
Table 2.
Table 2 The Different Pre-analysis Input Parameters for MOC and TOC
Pre-analysis
Input parameter
MOC TOC
1. Dialled digits Obtained from the MS Obtained from incoming trunk
signalling
2. TON Can be only two values
INT (International): if the
sign + is dialled
UNK (unknown): all
dialled numbers without
the sign +
Varies. TON depends on
incoming trunk signalling.
NOE (no TON provided)
UNK (unknown number)
INT (international number)
MSC-CSC BSU-1 SWITCH 2000-12-12 15:06:27.23
** ALARM BSU-1 1F109-00 IC2_SS
(0102) 2186 CALL CONTROL ANALYSIS MISSING
02 0002 00 0F 55 35 85 A5 AA AA A1 D0 00 00 00
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

17 (92)

NAT (national number)
NET (network-specific number)
SUB (subscriber number)
ABB (abbreviated number)
DPA (dedicated PAD access,
short code)
NOA (number not allowed)
CAC (carrier access code
included)
3. NPI - E.164
(ISDN/Telephony)

- Does not exist
- Unknown numbering plan
- ISDN/Telephony numbering
plan (E.164)
- Data numbering plan (X.121)
- Telex numbering plan (F.69)
- National standard numbering
plan
- Private numbering plan


Note
If the option North American Numbering Plan is used, the TON
parameter can have four more types: OP (no number present, operator
requested), SUBOP (subscriber number, operator requested), NATOP
(national number, operator requested), and INTOP (international
number, operator requested). For more information, see Functional
descriptions.
3.2.3.2 Tasks performed during pre-analysis
The pre-analysis have four main tasks:
1. The TON is checked to see if it is international, national or local.
For MOC, the TON comes from the MS itself. If a user dials a
number that is prefixed by the + sign, the MS will remove that sign
and set the parameter TON to International.
In all other cases, the MS sets the TON parameter to unknown.
Then the dialling pre-analysis must decide if the TON is
international, national or local.
This task results in items 6 (numbering plan), 7 (CON), and 9
(ODC) on the results list.
2. If the called number is an international or national call, then
modification information goes to call control.

Routing in MSS

18 (92) Nokia Siemens Networks

CN34017EN30GLN1

If further routing does not require these prefixes, then they should
be removed. This task identifies if removal or modification of the
number is necessary.
For example, if the called numbers include the international access
code, then those digits should be taken away for further
processing.
This task results in items 4 (number of removed digits) and 5 (start
point of removed digits) on the results list.
3. The calling subscriber may temporarily, on a call-by-call basis,
allow or restrict the presentation of the CLI by dialling prefixes that
are recognised by pre-analysis.
This task results in items 1 (result identifier), 8 (CLIR), and 10
(ESTP).
4. Pre-analysis identifies whether the call is a service call. If so, the
result will be a service index, which identifies a particular service
type. The service index shows that the call is not a normal call, but
needs to access some network operator-defined services.
This task results in items 2 (call characteristics) and 3 (service
type).
Emergency calls to the international standard number 112 are not defined in the pre-
analysis. However, if there is another number used for this purpose, then it must be defined
as a service call.
3.2.3.3 The results of the pre-analysis
The results of pre-analysis are:
1. Result Identifier. The result identifier can have one of the following
values:
CONTINUE CALL.
STOP CALL.
RE-EXECUTE PRE-ANALYSIS. The "CLIR info" parameter is
used for the dialled prefix. The dialled prefix is removed and
the modified called number is reanalysed.
2. Call Characteristics. The call characteristic can be one of the
following values:
NORMAL CALL. Call control routes the call in the normal way
by using the CM digit analysis for the called number.
EMERGENCY CALL. Call control routes the call to Area Service
Analysis.
SERVICE CALL. Call control routes the call to Area Service
Analysis.
SERVICE GROUP CALL. Call control routes the call to Area
Service Analysis.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

19 (92)

3. Service Type. When the call characteristic is anything other than a
normal call, the call requires a service type.
Types 1 to 23 are for service calls. 0 is reserved for emergency
calls.
4. Number of removed digits. Call control receives information about
the number of digits that should be removed for further call
processing.
5. Start point of removed digits. This parameter indicates the point at
which numbers should be taken away. If the parameter is not
given in the pre-analysis result, the removing starts from the
beginning of the dialled number.
6. Numbering Plan. The numbering plan can be one of the following
values:
DOES NOT EXIST
UNKNOWN
ISDN/TELEPHONY (E.164)
DATA (X.121)
TELEX (F.69)
NATIONAL STANDARD
PRIVATE
7. Characteristics of Number (CON). The value of the number can
be one of the following.
INTERNATIONAL. When the CC is not for the callers own
country. The TON can be either:
UNKNOWN, with an international prefix, or
INTERNATIONAL, without an international prefix.
NATIONAL. CC is for the callers own country, or there is no
country code. The TON can be either:
UNKNOWN, with national prefix, or
NATIONAL, without a national prefix.
LOCAL. When no national or international prefix is used and
the TON is UNK, SUB, or ABB.
8. Adding point of calling line identity <option> The parameter
indicates the point in the dialled number to which CLI is added if
the call is routed on the basis of the calling number. The value can
range from 1 to 16.
9. Adding info of area code <option> The parameter indicates
whether the local area code is added to the dialled digits as a
result of the pre-analysis. The value can be:

Routing in MSS

20 (92) Nokia Siemens Networks

CN34017EN30GLN1

Y Area code is added to the beginning of the dialled digits.
N No area code is added to the dialled digits.
The value can be Y only when call origin is MOC and
characteristics of number is NAT.
10. Controlled feature <option> FEAT determines the handling of a
supplementary service whose status can be changed on a per call
basis. The value can be:
INVCLIR Activate CLIR supplementary service and keep it
active until the end of the call.
SUPCLIR Suppress CLIR supplementary service and keep
is suppressed until the end of the call.
# The parameter has not been defined.
The parameter can have values only if analysis result identifier is
PREANA.
11. CCBS control <option> CCBS determines whether the
supplementary service Call Completion On Subscriber Busy can
be requested. The value can be:
PREV CCBS prevented
ENAB CCBS enabled
The parameter cannot be given if analysis result identifier is STOP
or PREANA, or if call characteristics is EMERG. In both cases, the
value is automatically PREV. If the parameter is not given, the
value found in the previous analysis result is used in the new
analysis result.
12. Original Dialling Class (ODC). This parameter can be analysed in
attribute analyses, and thus it enables the classification of the call
case for easier handling in attribute analyses. ODC may also be
used for statistical purposes, because it is shown both in the
charging record and trace report.
13. Extended pre-analysis Starting Point (ESTP). The ESTP indicates
the starting point of the extended pre-analysis sub-analysis chain.
This parameter is optional if you want to use pre-analysis to
analyse more input parameters than you usually do.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

21 (92)


RWO:ORIG=MOC;

MSCi DX220-LAB 2007-12-12 12:20:36

DEFAULT PRE-ANALYSIS INTERROGATION RESULTS

--- DEFAULT PRE-ANALYSIS INFORMATION ---

CALL ORIGIN =MOBILE
TON =UNKNOWN
PREFIX =348

NUMBER CHARACTERISTIC: NATIONAL
NBR OF REMOVED DIGITS: 0
STP OF REMOVED DIGITS: 1
CIC LENGTH : NOT SPECIFIED
NUMBERING PLAN : ISDN/TELEPHONY
CELL BASED AREA CODE : NOT SPECIFIED
PICI : SUBSCRIBERS PIC USED
CACI : ALLOWED
ESTP : NOT SPECIFIED
ODC : NOT SPECIFIED
Figure 10 Example of a MOC Default Pre-analysis

RWI:ORIG=MOC;

MSCi DX220-LAB 2007-12-12 12:23:47
DIALLING PRE-ANALYSIS INTERROGATION RESULTS

--- NORMAL PRE-ANALYSIS DATA ----
CALL ORIGIN =MOBILE
TON =UNKNOWN
NPI =ISDN/TELEPHONY
DIGITS =111

RESULT IDENTIFIER : CONTINUE CALL SETUP
CALL CHARACTERISTICS : SERVICE CALL
SERVICE TYPE : 8
NBR OF REMOVED DIGITS: NOT SPECIFIED
STP OF REMOVED DIGITS: NOT SPECIFIED
CIC LENGTH : NOT SPECIFIED
NUMBER CHARACTERISTIC: NATIONAL
NUMBERING PLAN : ISDN/TELEPHONY
CLI ADDITION POINT : NOT SPECIFIED
CELL BASED AREA CODE : NOT SPECIFIED
CONTROLLED FEATURE : NOT SPECIFIED
PICI : SUBSCRIBERS PIC USED
CACI : ALLOWED
EMLPP INVOCATION REQ : NOT SPECIFIED
CCBS POSSIBLE : ENABLED
ESTP : NOT SPECIFIED
ODC : NOT SPECIFIED
Figure 11 Example of a MOC Normal Pre-analysis

Routing in MSS

22 (92) Nokia Siemens Networks

CN34017EN30GLN1

< RWO:ORIG=TOC;
LOADING PROGRAM VERSION 6.4-0

MSCi DX220-LAB 2007-12-12 12:31:25
DEFAULT PRE-ANALYSIS INTERROGATION RESULTS

--- DEFAULT PRE-ANALYSIS INFORMATION ---
CALL ORIGIN =TRUNK
TON =UNKNOWN
PREFIX =3482

NUMBER CHARACTERISTIC: NATIONAL
NBR OF REMOVED DIGITS: 0
STP OF REMOVED DIGITS: 1
CIC LENGTH : NOT SPECIFIED
NUMBERING PLAN : ISDN/TELEPHONY
CELL BASED AREA CODE : NOT SPECIFIED
PICI : SUBSCRIBERS PIC USED
CACI : ALLOWED
ESTP : NOT SPECIFIED
ODC : NOT SPECIFIED
Figure 12 Default Pre-analysis Examples for TOC
A TOC pre-analysis procedure is nearly the same as that of a MOC. A TOC pre-analysis
differs from a MOC pre-analysis in the following ways:
1. The NPI is an input to the normal pre-analysis because, besides
ISDN/TELEPHONY, it can be NON-EXISTENT, UNKNOWN, and so
on. This depends on the signalling interface.
2. A TOC cannot be an emergency or service call.
3. A TOC cannot be a service call. The result of the pre-analysis has
no provision for a service index.
4. The TON can have values such as UNK, INT, NAT, or NN. This
depends on the signalling interface.
3.3 Origin Analysis
The purpose of origin analysis is to find the charging data needed in the CM digit analysis.
Origin analysis applies only to MOC.
As illustrated in Figure 3, the parameters used as inputs to origin analysis are:
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

23 (92)

MS category (calling party category)
Cell tariff
MS power capability (class mark)

ANALYSIS
FILES ANALYSIS
RESULT
FILE
CHARGING ORIGIN (CORG)
ordinary
payphone
priority
test
1. CALLING PARTY CAT.
2. CELL TARIFF
3. MS CLASS MARK
0..3
1..5
0..254

Figure 13 Origin Analysis
The main task of origin analysis is to produce a charging origin (CORG) parameter to identify
the calling party.
3.3.1 Input
This section explains the sources of information to perform the analysis.
The three input parameters for origin analysis are listed below, along with their
corresponding values. These input parameters come from the MS itself.
1. Calling Party Category (CPC). Says what the category of the
calling party MS is. It can have any of these values:
a. ORDINARY
b. PAYPHONE
c. PRIORITY
d. TEST PHONE
2. Cell Tariff. Obtained from the cell data file (CDAFIL), based on the
geographical location of the cell from where the call originated.
The possible values are 0, 1, 2, and 3.
3. Mobile Station class mark. The MS broadcasts the MS class
mark, based on its power rating. These values are shown in Table
3


Routing in MSS

24 (92) Nokia Siemens Networks

CN34017EN30GLN1

Table 3 MS Class Mark Values ( Power Classes)
Power rating
Class Mark Value MS Class Mark
900MHz 1.8GHz
Nokia category
000 1 - 1W Vehicle/Portable
001 2 8W( +39dBm ) 0.25 W Portable
010 3 5W( +37dBm ) - Handheld
011 4 2W( +33dBm ) - Handheld
100 5 0.8W (+29dBm ) - Handheld
Table 4 UE Class Mark (Power Classes)
Power Class Nominal maximum
output power
Tolerance
1 2W(+33 dBm) +1/-3 dB
2 0.5W(+27 dBm) +1/-3 dB
3 0.25W(+24 dBm) +1/-3 dB
4 0.13W(+21 dBm) 2 dB
3.3.2 Results
The result of an origin analysis is the CORG variable, whose value lies in the range 0...254.
Figure 4 shows an origin analysis printout from the MSS.
ZRVI;
LOADING PROGRAM VERSION 7.1-0
MSCi DX220-LAB 2007-12-12 15:43:27
ORIGIN ANALYSIS INTERROGATION RESULTS

SUBSCRIBER CATEGORY=ORDINARY CELL TARIFF=0 MS CLASSMARK=1
RESULT IDENTIFIER : CONTINUE CALL SETUP
CHARGING ORIGIN : 0

Figure 14 Origin Analysis Results for a MOC

Despite the fact that an origin analysis applies only to MOCs, it is still used with all calls. In
TOCs, the CORG is associated with the circuit group. Figure5 shows a CORG value for a
TOC.
The CORG information is used in determining the cost for the subscriber and keeping
charging records used between network operators.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

25 (92)

Charging attribute analysis can be used to change the value of the CORG.
< RCI:SEA=3:NCGR=MSC01:PRINT=3:;

CIRCUIT GROUP(S)
CGR : 150 NCGR : MSC01
AREA : - STD : -
MAN : - AAN : -
SSET : - CLI : -
CAC : - CACI : -
REMN : - RFCL : -
ICLI : - CHRN : -
ATV : -
EC : 0 DBA : 1 PRI : 1 CORG : 0 DCC : -
LOC : - DNN : - RDQ : - DDQ : - IGOR:
ECAT : - EOS : - UPDR : 0
Figure15 CORG for TOC
3.4 End of Selection Analysis
The purpose of end of selection analysis (EOS) is to determine the next course of action
after certain call events.
As illustrated in Figure 76, the parameters used as inputs in EOS analysis are the cause
codes that result from call events.

ANALYSIS
FILES
ANALYSIS
RESULT FILE
CAUSE CODE (CD_T)
INFORMATION ON CALL PROGRESS
ANALYSIS TREE
ANNOUNCEMENT DATA
<NEW CAUSE CODE CD_T>
TIME SLOT OF THE SIGNAL TONE
CHARGING ORIGIN
NOTIFICATION
EVENT DETECTION POINT
SIGNALLING SYSTEM

Figure 76 EOS Analysis
The task of the EOS analysis is to analyse the cause code, which then defines what should
be done next.

Routing in MSS

26 (92) Nokia Siemens Networks

CN34017EN30GLN1

3.4.1 Input
During the process of call setup, two events can occur that will alter the call or abandon the
call entirely.
If a call is cleared, then there will be no further processing
required.
If a call has reached its destination MSS/MSC (in an MTC), only to
find that the B subscriber has activated a conditional call
forwarding, then the entire process of finding a new destination
must be repeated.
These things can happen at any stage during call setup.
Associated with each such occurrence is the Cause Code (Cd_t), which (partially) informs
the call control as to why the event occurred. The EOS analysis examines these cause
codes.
Signalling system program blocks based on signalling system messages, such as the MAP
blocks, or call control set cause codes.
3.4.2 Results
Several outputs from EOS analysis are possible:
1. Continue call setup.
2. Stop call setup. This will happen if the call has to be cleared. If the
result identifier is the result of the EOS, then the cause code will
be mapped on to a cause code of the signalling message.
3. Execute digit analysis. If call forwarding has taken place, or if an
MSRN has been obtained from the HLR, then the destination must
be found and a tree must be associated with this result.
4. Execute alternative route analysis.
5. Execute re-hunting of outgoing circuits.
6. Execute repeat attempt procedure.
7. Execute EOS attribute analysis.

Depending on the type of result, there may be other actions required as well. Some
examples of these actions are: notifying the calling party, connecting tones (for example,
congestion tone if no circuits are available), connecting to an announcement, and so on.
Figure 87 shows a sample EOS analysis.

<RXI:RESGR=2,CAUSE=1009;
MSCi DX220-LAB 2007-12-12 18:12:47

END OF SELECTION ANALYSIS INTERROGATION RESULTS

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

27 (92)

RESGR=2 CAUSE=00001009 NODE INFO=NOT SPECIFIED

RESULT IDENTIFIER : EXECUTE CM ANALYSIS
CM ANALYSIS TREE : 50
CHARGING ORIGIN : 0
NOTIFICATION INFO : NOT SPECIFIED
TIMESLOT OF TONE : NOT SPECIFIED
ANNOUNCEMENT NUMBER : NOT SPECIFIED
ANNOUNCEMENT CHARGING: NOT SPECIFIED
FORWARD RELEASE INFO : NOT SPECIFIED
NEW DX CAUSE CODE : NOT SPECIFIED
IN DETECTION POINT : NOT SPECIFIED


COMMAND EXECUTED

Figure 87 EOS Analysis Printout
Cause Codes
Cause codes can take two forms:
Clear codes. Inside the exchange, these signify different call
clearing reasons, such as subscriber busy (5).
Event codes. These indicate various other events during the call,
such as HLRENQ (1009) or call forwarding (100D~1014).
Different signalling systems in which the call originates set the cause codes. Some of these
systems are the RANAP, the BICC or the ISUP.
Therefore, the same cause code that is set or generated by different signalling systems has
its own different result record. Thus, when we interrogate the cause codes, we have to
identify the signalling system that set those cause codes.
3.5 Digit Analysis
The purpose of digit analysis is to find a destination for the call.

Routing in MSS

28 (92) Nokia Siemens Networks

CN34017EN30GLN1

As illustrated in
ANALYSIS TREE
ANALYSIS
RESULT
FILE
CHARGING ORIGIN
TYPE OF NUMBER
DIALLING (after preanalysis)
CM
ANALYSIS
FILES
ANALYSIS
RESULT
FILES HLR INQUIRY
GSM-TERMINATING CALL
HANDOVER BETWEEN TWO EXCHANGES
CALL TO DDA
NUMBER MODIFICATION
IN CALL
BICC ROUTE OR TDM ROUTE
ANNOUNCEMENT
1. OUTGOING ROUTE
2. SPECIAL ROUTE
HLR INQUIRY
GSM-TERMINATING CALL
HANDOVER BETWEEN TWO EXCHANGES
CALL TO DDA
NUMBER MODIFICATION
IN CALL
BICC ROUTE OR TDM ROUTE
ANNOUNCEMENT
1. OUTGOING ROUTE
2. SPECIAL ROUTE

Figure 98, the inputs used in digit analysis are:
Analysis tree
Charging origin
TON
Dialled digits (after the pre-analysis)
The main task of the digit analysis is to find a destination. Then the analysis chooses a route
in order to forward the call to the selected destination.

ANALYSIS TREE
ANALYSIS
RESULT
FILE
CHARGING ORIGIN
TYPE OF NUMBER
DIALLING (after preanalysis)
CM
ANALYSIS
FILES
ANALYSIS
RESULT
FILES HLR INQUIRY
GSM-TERMINATING CALL
HANDOVER BETWEEN TWO EXCHANGES
CALL TO DDA
NUMBER MODIFICATION
IN CALL
BICC ROUTE OR TDM ROUTE
ANNOUNCEMENT
1. OUTGOING ROUTE
2. SPECIAL ROUTE
HLR INQUIRY
GSM-TERMINATING CALL
HANDOVER BETWEEN TWO EXCHANGES
CALL TO DDA
NUMBER MODIFICATION
IN CALL
BICC ROUTE OR TDM ROUTE
ANNOUNCEMENT
1. OUTGOING ROUTE
2. SPECIAL ROUTE

Figure 98 Digit Analysis
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

29 (92)

3.5.1 Input
This section explains the sources of information to perform the analysis.
The four input parameters for digit analysis are listed below, along with their corresponding
values and/or sources.
1. Analysis tree. A chain of records in an analysis file, used for
analysing different types of digits.
The basic tree is received from five possible sources:
Circuit group (TOC and PBX calls)
General Parameter file PRFILE (in MOC)
End-of-selection analysis (forwarding and roaming calls)
MSISDN digit analysis (some roaming calls)
CM (if the digit analysis is sent back for reanalysis)
2. CORG. The charging origin can come from two different sources:
Circuit group (TOC and PBX calls)
Origin analysis (in MOC)
3. TON. The Type of Number can have four different values:
INT
NAT
SUB
UNK
4. Dialled digit. The dialled digits that are left after a pre-analysis.
Table 5 Analysis Trees
Call Case Number Tree TON Source
MOC B-number - national 2 NAT PRFILE
B-number -
International
2 INT
B-number - Local 2 SUB
Call forwarding C-Nbr. national 20 NAT EOS-analysis, cause code
C-Nbr.-International 20 INT 100E (CFU) and 100F (conditional
CFW)
Service call Service Numbers 30 NAT Area serv. numb.handling
Announcement Announcement
number
48 UNK PRFILE

Routing in MSS

30 (92) Nokia Siemens Networks

CN34017EN30GLN1

Automatic call
redirection
Automatic call
redirection number
49 NAT PRFILE
Roaming MSRN-
National/Handover
nbr.
50 NAT EOS, cause code 1009
MSRN-International 50 INT
TOC TOC-number -
National
70
>>
NAT Circuit group (can be
TOC-number
International
70
>>
INT Changed easily)
2
50
48
30
20 70
Digit Analysis
MOC
MSRN (From HLRENQ)
/ HON (From HO_REQ)
Service
number
Announcement
number
C-number
TOC

Figure 109 Analysis Tree

3.5.2 Results
Associated with each of the numbers is a result set containing a number of parameters
pointing towards a destination.
Destination indicates the desired result of routing. It provides the reference to the set of
routing alternatives, sub-destinations, on the basis of the digit analysis. For instructions, see
Creating sub-destination and destination . Sub-destination is used to route the call to the
desired connection (destination). There may be up to five sub-destination alternatives
connected to the same destination component, each using a different call control alternative.
For instance, there may be four sub-destinations using different outgoing routes, and a fifth
one connected to an announcement, in case the other connections are congested.

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

31 (92)


Pre-
analysis
Digit
Analysis
MS classmark Origin
Analysis
2. Dialled digits
3. TON, NPI
Destination
(Outgoing route
or Special route)
MS cat.
Tree selection
normal call
1. CGR
2. PRFILE
3. EOS
1. C_ORG
Cell tariff
CGR (TOC)
(MOC)
4. TREE

Figure 20 Input Parameters for Digit Analysis
Digit
analysis
Destination
Subdestination 1
(primary route)
Subdestination 2
(Alternative route)
Subdestination 3
(Alternative route)
Subdestination 4
(Alternative route)
Subdestination 5
(Alternative route)
Spectial route or
Outgoing route
Spectial route or
Outgoing route
Spectial route or
Outgoing route
Spectial route or
Outgoing route
Spectial route or
Outgoing route


Figure 21 Destination and Sub-destination
When you create a sub-destination, you must indicate the sub-destination result, that is, the
type of connection to be used for the call. The result can be one of the following:

Routing in MSS

32 (92) Nokia Siemens Networks

CN34017EN30GLN1

Outgoing route, which is used to connect calls out of the
exchange to another exchange.
Special route, which is used to manage a set of special functions
in the exchange. The special route is recorded in the sub-
destination data to give instructions on how to continue the call,
which needs special treatment.
Announcement specified to direct calls to announcements.
Service set for IN services in SSP <option>.
3.5.2.1 Sub-destination leading to outgoing route
Sub-destination is used to route the call to the desired outgoing connection. There may be up
to five sub-destinations connected to the same destination component, each using a different
external route (BICC or TDM route). Each sub-destination is assigned to one route, but each
route can be assigned to several sub-destinations.
RRI: GSW: ROU=14;
ROU TYPE OUTR STP TSG TMT SAT ATME DCME ECHO CONT TON SEQH ICR
14 EXT OMZ00 1 - - N N N N N UNK N
N
RCR MCR OCR RPR PBX ISDN STATE NCGR
N N N N Y N WO-EX HEL1L
APRI ASTC NCCP T_IND ENBLOC ATV CLISET
NCLISET
N N BSSAP 0 - - 0
DEFAULT
AICR PNR RNPR RFCL PCLI
NEF
- - - - -
MSS
UPDR
1000
FCL
-

Figure 22 Route Example
Routes in MSS/GCS have two types,
Control Plane Route, such as BICC route. Use control plane
CGRs.
User Plane Route: TDM route. Use TDM CGRs.
Control Plane CGRs are created to connect Control planes between two exchanges. The
control plane group identifies the destination, direction, call control parameter set, used
register signalling and user plane reference for incoming calls.
Circuit Group types for Control Plane Routing are:
BICC, CGR for Bearer Independent Call Control
SIP, CGR for Session Initiation Protocol
For user plane, the external resources that have to be configured to the MSS and the MGW
are TDM resources, that is, physical terminations. All other resources such as ATM or IP are
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

33 (92)

ephemeral terminations, which are configured only in the MGW. Circuit Group types for User
Plane Routing are:
CCS: TDM resources located in MSS (Integrated MSS)
ECCS: TDM resources located in MGW
Figure 23 Route & CGR in MSS/GCS


ZRCI:SEA=3:CGR=320&&593:PRINT=5;
CIRCUIT GROUP(S)

CGR : 320 NCGR : BSC02

TYPE : ECCS STATE : WO-EX HUNTED : YES
FORMAT : TERMID HM1 : LF HM2 : LF
NBCRCT : 15 TREE : - DIR : OUT
LSI : AIF01 INR : - NCCP : -
METHOD : - NET : NA0 SPC(H/D) : 0320/00800
ASI : -
UPART : BSSAP MGW : MGW01

FQDN : -


AUTOMATIC CONGESTION CONTROL

REJ11 : - REJ12 : - REJ21 : - REJ22 : -
ACT11 : NO ACTION ACT12 : NO ACTION ACT21 : NO ACTION ACT22 : NO ACTION

SELECTIVE CIRCUIT RESERVATION

TRES1 : - TRES2 : -
DR1A : - DR2A : - ART1A : - ART2A : - ACTA : NO ACTION
DR1B : - DR2B : - ART1B : - ART2B : - ACTB : NO ACTION
DR1C : - DR2C : - ART1C : - ART2C : - ACTC : NO ACTION

CIRCUIT(S)

TERMID ORD CTRL HGR STATE CCSPCM UNIT

NIWU
NIS1
CCSU
NIWU
SIGU ET
MGW1 MGW1
MSS/VLR
PSTN
MGW2 MGW2
GCS
BSC
RNC
Control Plane ROUTE
CGR TYPE=BICC
CIC: Call Instance Code
User Plane ROUTE
CGR TYPE=CCS
CRCT: Circuit
CCSPCM
User Plane ROUTE
CGR TYPE=ECCS
TERMID: Termination ID
CCSPCM

Routing in MSS

34 (92) Nokia Siemens Networks

CN34017EN30GLN1

14-1 1 X 1-1 WO-EX 0 BSU , 0
14-2 2 X 1-2 WO-EX 0 BSU , 0
14-3 3 X 1-3 WO-EX 0 BSU , 0
14-4 4 X 1-4 WO-EX 0 BSU , 0
14-5 5 X 1-5 WO-EX 0 BSU , 0
14-6 6 X 1-6 WO-EX 0 BSU , 0
14-7 7 X 1-7 WO-EX 0 BSU , 0
14-8 8 X 1-8 WO-EX 0 BSU , 0
14-9 9 X 1-9 WO-EX 0 BSU , 0
14-10 10 X 1-10 WO-EX 0 BSU , 0
14-11 11 X 1-11 WO-EX 0 BSU , 0
14-12 12 X 1-12 WO-EX 0 BSU , 0
14-13 13 X 1-13 WO-EX 0 BSU , 0
14-14 14 X 1-14 WO-EX 0 BSU , 0
14-15 15 X 1-15 WO-EX 0 BSU , 0


CGR : 370 NCGR : BSC07

TYPE : CCS STATE : WO-EX HUNTED : YES
FORMAT : PCM-TSL HM1 : LF HM2 : LF
NBCRCT : 26 TREE : - DIR : OUT
LSI : AIF01 INR : - NCCP : -
METHOD : - NET : NA0 SPC(H/D) : 0370/00880
ASI : -
UPART : -

FQDN : -


AUTOMATIC CONGESTION CONTROL

REJ11 : - REJ12 : - REJ21 : - REJ22 : -
ACT11 : NO ACTION ACT12 : NO ACTION ACT21 : NO ACTION ACT22 : NO ACTION

SELECTIVE CIRCUIT RESERVATION

TRES1 : - TRES2 : -
DR1A : - DR2A : - ART1A : - ART2A : - ACTA : NO ACTION
DR1B : - DR2B : - ART1B : - ART2B : - ACTB : NO ACTION
DR1C : - DR2C : - ART1C : - ART2C : - ACTC : NO ACTION

CIRCUIT(S)

PCM-TSL ORD CTRL HGR STATE CCSPCM

594-1 1 X 1-1 WO-EX 0
594-2 2 X 1-2 WO-EX 0
594-3 3 X 1-3 WO-EX 0
594-4 4 X 1-4 WO-EX 0
594-5 5 X 1-5 WO-EX 0
594-6 6 X 1-6 WO-EX 0
594-7 7 X 1-7 WO-EX 0
594-8 8 X 1-8 WO-EX 0
594-9 9 X 1-9 WO-EX 0
594-10 10 X 1-10 WO-EX 0
594-11 11 X 1-11 WO-EX 0
594-12 12 X 1-12 WO-EX 0
594-13 13 X 1-13 WO-EX 0
594-14 14 X 1-14 WO-EX 0
594-15 15 X 1-15 WO-EX 0
594-16 16 X 1-16 WO-EX 0
594-17 17 X 1-17 WO-EX 0
594-18 18 X 1-18 WO-EX 0
0
Figure 24 User Plane CGRs
CIRCUIT GROUP(S)
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

35 (92)

CGR : 372 NCGR : BICC_BI
AREA : - STD : -
MAN : - AAN : -
SSET : - CLI : -
CAC : 123451 CACI : -
REMN : - RFCL : -
ICLI : - CHRN : -
ATV : -

EC : 0 DBA : 1 PRI : 1 CORG : 0 DCC : -
LOC : - DNN : - RDQ : - DDQ : - IGOR : -
ECAT : - EOS : - UPDR : 133

CIC ORD CTRL HGR STATE UNIT
101 2 X 1-1 WO-EX SIGU, 0
103 4 X 1-2 WO-EX SIGU, 0
105 6 X 1-3 WO-EX SIGU, 0
107 8 X 1-4 WO-EX SIGU, 0
109 10 X 1-5 WO-EX SIGU, 0
100 1 Y 2-1 WO-EX SIGU, 0
102 3 Y 2-2 WO-EX SIGU, 0
104 5 Y 2-3 WO-EX SIGU, 0
106 7 Y 2-4 WO-EX SIGU, 0
Figure 25 Control Plane CGR
Once a circuit group within the route is chosen, the procedure for selecting a free circuit,
termination or CIC within the circuit group is initiated. This is known as hunting. Three
different directions are possible.
Outgoing circuit groups
Incoming circuit groups
Bi-directional circuit groups.
Each circuit group has one or two hunting groups that depend on the direction of the circuit
group.
Outgoing circuit groups have only one hunting group, because only
this network element is allowed to select a free circuit.
Incoming circuit groups have also only one hunting group, but the
network element is not allowed to select a free circuit. An example
is the circuit group in the BSC.
Bi-directional circuit groups have two hunting groups that divide all
circuits into two groups. The own network element is allowed to
select circuits in one of the hunting groups, the adjacent network
element selects circuits in the other one. If one of the network
elements does not find any free circuit in its own hunting group, it
will search for a free circuit in the hunting group under the control
of the other network element.


Routing in MSS

36 (92) Nokia Siemens Networks

CN34017EN30GLN1

Subdestination
Circuit
group
Circuit
group
Circuit
group
Circuit
group
External
route
Special
route
Digit
Analysis
Destination
Hunting group 1
Hunting group 2
AL0
Has
max. 5
AL4
Which contains
max. 2048
Consistsof
max. 8 CGRs
Which is
either
-

Figure 26 Hunting Concepts
An example of dividing the circuits into two hunting groups is to assign the even numbered
circuits to one group and the odd numbered circuits to another.
After the hunting procedure, one free circuit will be selected inside the hunting group. There
are four different hunting methods for a free circuit:
Fixed Rotating (FR), also known as circulating hunting. Hunting
begins from the next circuit where it was stopped last time.
Fixed Start Point (FF), also known as sequential hunting. Hunting
begins always from the same circuit.
Longest Free (LF), selection of the longest free circuits. The
circuit, which has not been used for the longest time, will be
selected.
Shortest Free (RF), selection of the shortest free circuits. The
circuit, which has not been used for the shortest time, will be
selected.
3.5.2.2 Sub-destination leading to special route
Special routes are used to manage a set of special functions in the exchange. The special
route gives instructions on how to continue the call, which needs special treatment. The
treatment indicated by the special route may be:
number modification, telling how the received dialling needs to be
modified before sending it forward, or before reanalysing it
inter-MSC handover, providing data needed in the handover
number analysis
PAD access, enabling the routing of DDA calls
HLR enquiry and GSM end, providing data needed for the routing
of mobile terminating calls
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

37 (92)

announcements, in which case the special route conveys
information about the desired announcement
3.5.2.3 Sub-destination leading to IN service set
Sub-destination is connected to an IN service set to route IN calls. To connect a service set
to sub-destination, use the command RDE . The service set can also be defined for the
destination component. For information on creating the analysis of IN services, see Defining
IN service on circuit group .
3.5.2.4 HLR_ENQ SPR
During every MTC, an HLR_ENQ must be performed to find out the MSC/VLR where the
subscriber is located at the moment. The required signalling messages from the MSC to the
HLR can be routed using the two main principles:
Routing on label
Routing on Global Title (SCCP routing).
This enquiry is indicated in the specific trees by an SPR for HLR_ENQ.
In this case the definition for the SPR HLR_ENQ must contain the signalling point code from
the HLR, as shown in Figure 117.
< ZRPI:SPR=2;
SPECIAL ROUTE FOR HLR ENQUIRY
STP NETWORK SIGNALLING TREE CORG CLI SPR
POINT CODE
1 NA1 210 00000 0 OFF 00002
COMMAND EXECUTED
Figure 117 HLR_ENQ SPR on Label
Different HLRs should be handled with a separate line for the specific range of numbers
pointing to a unique SPR, all containing a different signalling point code.
This allows the most flexible and elegant way of routing HLR_ENQs to the HLRs. Only one
SPR for HLR_ENQ, as shown in Figure 128, has to be created..




RPI:SPR=2;

SPECIAL ROUTE FOR HLR ENQUIRY

STP DIG TON NP CORG CLI SPR
1 - NAT E164 0 ON 00002

Routing in MSS

38 (92) Nokia Siemens Networks

CN34017EN30GLN1

Figure 128 HLR_ENQ SPR on Global Title

< RII:TREE=2&70;
MSCi DX220-LAB 2007-12-12 17:40:47

TREE= 2 ATYPE=N TON=INT
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
3934822 0 2 SPR NC 0 32 APR 1 1 N 1

TREE= 70 ATYPE=N TON=NAT
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
34822 0 2 SPR NC 0 32 APR 1 1 N 1

COMMAND EXECUTED
COMMAND EXECUTED
Figure 139 Digit Analysis HLR_ENQ
3.5.2.5 Mobile terminating call SPR (GSMEND)
For a mobile-terminated call, the MSC receives its own MSRN back from the HLR after
HLR_ENQ requests. The MSC performs digit analysis in tree 50 to analyse its own MSRN
number. If the result of the analysis is to terminate the call to a BSC, the correct SPR is
called GSMEND. In case the MSC receives its own MSRN back from the trunk, it has to
perform digit analysis in tree 70 and the result is GSMEND.

< ZRII:TREE=50;
LOADING PROGRAM VERSION 13.2-0
MSCi DX220-LAB 2007-12-12 17:46:10

TREE= 50 ATYPE=N TON=NAT
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
3483003 0 1 SPR NC 0 32 APR 2 1 N 2

Figure 30 Digit Analysis Example for GSMEND SPR

< ZRPI:SPR=1;
LOADING PROGRAM VERSION 4.1-0

SPECIAL ROUTE FOR GSM END
OUTROUTE STP SPR
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

39 (92)

SIGNALLING

OMCGB 1 00001
COMMAND EXECUTED
Figure 31 GSMEND SPR Definition
3.5.2.6 CM number modification SPR
If the sub-destination of the CM number analysis leads to number modification, the result
may require a reanalysis of the modified digits. In this case, the CM gives the analysis start
point (basic tree) of the modified digits to the call control. You provide the basic tree with the
help of the number modification MML commands.

Digit
Analysis
Number
Modification
Analysis Digit
TREE
or
Outgoing
Route
TREE
Note: Result after Number Modification Analysis can be either outgoing
route or sending back to new TREE to analyse again
Modified Digit
ModifiedDigit

Figure 32 Number Modification Analysis
3.5.2.7 Announcement SPR
For specific cases it is necessary to assign an announcement to certain subscribers. The
Verbal Announcement Generator (VANG) can generate the announcement.
Announcements are assigned in tree 48, as shown in Figure 3 below.

< RII:TREE=48;

DX 200 MSC03 2000-12-12 11:52:08

TREE= 48 ATYPE=N TON=UNK
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
00300 0 2047 SPR NGC 5 32 APR 8 1 N 7
03300 0 2047 SPR NC 1 32 APR 25 1 N 21
09234 0 501 SPR NGC 5 32 APR 28 7 N 22
09235 0 502 SPR NGC 5 32 APR 29 7 N 23
09236 0 503 SPR NGC 5 32 APR 30 7 N 24

Routing in MSS

40 (92) Nokia Siemens Networks

CN34017EN30GLN1

09237 0 504 SPR NGC 5 32 APR 31 7 N 25

COMMAND EXECUTED
Figure 33 Digit Analysis in Tree 48
Figure 4 displays a list of digits, which point to an SPR for an announcement. This SPR
contains a set of specific parameters for this announcement.

< ZRAI:SPR=501&504;
DX 200 MSC03 2007-12-12 11:54:19
ANNOUNCEMENTS:
SPR PHA DEV STATE AIND ALLO FICH ANAM BTO TXIND AFIL
501 MAI INT ON 501 OND - VAMG0 - - 1 ,

SPR PHA DEV STATE AIND ALLO FICH ANAM BTO TXIND AFIL
504 MAI INT ON 504 OND - VANG0 - - 1 ,

COMMAND EXECUTED
Figure 34 Announcement SPR Printout

Figure35 shows a general announcement parameter set for the VANG.


< RAL:ANAM=VANG0;
ANNOUNCEMENT PARAMETERS:
ANAM DEV MLC LCL LTL PTIM
VANG0 INT - 2 - -
Figure35 Announcement Parameter Printout


RXI:RESGR=2,CAUSE=5;

MSCi DX220-LAB 2007-12-12 17:55:40

END OF SELECTION ANALYSIS INTERROGATION RESULTS

RESGR=2 CAUSE=00000005 NODE INFO=NOT SPECIFIED

RESULT IDENTIFIER : STOP CALL SETUP
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

41 (92)

CM ANALYSIS TREE : NOT SPECIFIED
CHARGING ORIGIN : NOT SPECIFIED
NOTIFICATION INFO : NOT SPECIFIED
TIMESLOT OF TONE : NOT SPECIFIED
ANNOUNCEMENT NUMBER : NOT SPECIFIED
ANNOUNCEMENT CHARGING: NOT SPECIFIED
FORWARD RELEASE INFO : NOT SPECIFIED
NEW DX CAUSE CODE : NOT SPECIFIED
IN DETECTION POINT : NOT SPECIFIED

COMMAND EXECUTED
Figure 146 EOS Analysis Printout

There are several ways the switch can obtain one of the numbers in Tree 48:
1. EOS cause-code. Figure 146 shows a cause-code analysed by
the EOS. The result in this example is STOP CALL SETUP.
Announcement Number equalling 100. This number refers to the
digits in tree 48.
2. Direct Announcement.


< RII:TREE=2,TON=SUB;
MSCi DX220-LAB 2003-01-15 17:57:30
TREE= 2 ATYPE=N TON=SUB
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
6767 0 300 ANN SC 3 0 APR 26 8 N 30
Figure 157 Digit Analysis for Direct Announcement in Tree 2
Although the announcement number usually contains three digits,
such as 500, the related digits in tree 48 start with two more
leading digits, such as 00500 or 03500.
The first digit specifies the announcement language with value 0.4.
The value 0 indicates the default language used in the exchange.
The second digit refers to the announcement case. This describes
in which call phase the announcement is given, for example:
0 direct call to announcement
3 intermediate announcements.
3. Call barring analysis. The result of call barring analysis can be the
provision of an announcement.

Routing in MSS

42 (92) Nokia Siemens Networks

CN34017EN30GLN1

4. Attribute analysis. When using attribute analysis, one of the
possible final results can be an announcement.
5. Function analysis. A typical example here is the call-drop
announcement.
3.5.3 Routing and Charging Components
The second part of digit analysis is the charging component. Routing cannot be completed
without charging. Somebody has to pay the bill.
Figure 168, Figure 179 and Figure40, illustrate the relationship between the routing
component and the charging component.

Figure 168 Routing and Charging Components
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

43 (92)

Figure 179 Digit Analysis Components
< RIA:TREE=2,DIG=34822,ATYPE=N,TON=NAT,:;

MSCi DX220-LAB 2007-12-12 18:05:02

DIG = 34822
TON = NAT
FIRST ANALYSIS
TREE: STATE: FOLLOWING DIGITS:
ENDS
ALT = 0

NAME OF DESTINATION : HLRENQ
NAME OF SUB-DESTINATION : HLRENQ

NBR RT CT SP NL CNT MNL DCA
ROUTING DATA 2 SPR NC 0 32 - 0 -

SELO DSTATE SRCL QA RC PC CNP EC CDRS
ADDITIONAL DATA PAD A N N APR ORD N N 0

CAT MDC

DESTINATION SSET = 0

ATTR(DEST) : - ATTN(DEST) : -
ATTR(ALT) : - ATTN(ALT) : -

CHARGING INDEX : 1 CHARGING ORIGIN: 0

NAME OF CHARGING CASE: 00001 CHA: 1

NAME OF CHARGING MODIFICATION: - ICAM: -

DC SPM SPA TCI NCB PT HC CP MCZ ACZ IAZ OAZ
NDC N N N CHA 0 CI OE 0 0 0 0

CM
PLS

ICC 00000000 OCC 00000000

COMMAND EXECUTED
Figure 40 Routing and Charging Component Printout
< RII:TREE=2,TON=NAT;
MSCi DX220-LAB 2007-12-12 18:00:42
TREE= 2 ATYPE=N TON=NAT
DIGITS AL NBR RT CT SP NL RC DEST CHI CNT SDEST
34822 0 2 SPR NC 0 32 APR 1 1 N 1
COMMAND EXECUTED
< RIH:TREE=2,TON=NAT;
MSCi DX220-LAB 2003-01-15 18:01:54
TREE= 2 ATYPE=N TON=NAT
DIGITS AL NDEST CHI CNT NSDEST CORG NCHA
34822 0 HLRENQ 1 N HLRENQ 0 00001
COMMAND EXECUTED

Routing in MSS

44 (92) Nokia Siemens Networks

CN34017EN30GLN1

The digit analysis produces a destination with one or more sub-destinations. Each
destination of an individual digit analysis gives a charging index.
The CORG gives the calling party information. The CORG and the charging index together
are a charging case.
Associated with each charging case is a set of parameters called charging zone, which is
used for accounting purposes between network operators and the supplementary service
Advice Of Charge.
If a charging component in the digit analysis does not exist for a certain CORG, even though
the destination component exists, that call will not be successful.
Thus, it is essential that all possible CORGs have been included in the charging component.
This will avoid the alarm shown in Figure41.

Figure 41 Generated Alarm in Case of Missing Charging Case
3.5.4 Creation of Digit Analysis
1. create the necessary circuit group(s)

ZRCC:NA0:NCGR=TEST_CGR,.........:;
2. create route(s)

ZRRC:EXT:ROU=222,.........NCGR=TEST_CGR:;
3. create subdestination
ZRDE:NSDEST=SDEST_TEST :(Routing data: - ROUTE=222,.....):;
4. create charging component

ZRDE: NCHA=CHEAP :(Charging data):;
5. create destination
ZRDE:NDEST=DEST_TEST:(Routing data: - NSDEST=SDEST_TEST )(Charging data: - NCHA=CHEAP ):;
6. create digit analysis
ZRDC:TREE=x,TON=y,DIG=z:NDEST=DEST_TEST:;

Figure 42 Creation of Digit Analysis
MSC-CSC BSU-1 SWITCH 2007-10-15 15:16:22.53
** ALARM BSU-1 1F109-00 IC2_SS
(0105) 2532 ANALYSIS(MSRN) OR CHARGING CASE IS MISSING
0003 08 00 00 00 12 34 00 00 00 00 00
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

45 (92)

3.6 Area Service Analysis
The purpose of area service analysis is to decide where to send a service call.
As illustrated in Figure 18, the parameters used as inputs to area service analysis are:
Zone code
Service number

ANALYSIS
FILES
ANALYSIS
RESULT
FILE ZONE CODE
SERVICE TYPE NUMBER
ANALYSIS TREE
EMERGENCY/SERVICE CENTRE NO.

Figure 18 Area Service Analysis

The main task of the area service analysis is to produce a service centre number to locate
the nearest service centre.
3.6.1 Input
The two input parameters for area service analysis are listed below.
1. Zone Code. A certain number of cells are grouped together, and a
service centre will be associated with that particular service area,
known as the routing zone.
When a MOC starts, it also contains information about the
geographical cell location, which is required for the CORG.
2. Service Type Number. This is a result of the pre-analysis. Once
the call has been identified as a service call, its type is also
identified.

Routing in MSS

46 (92) Nokia Siemens Networks

CN34017EN30GLN1

3.6.2 Process
The service number analysis is generally done in tree 30 (but it can vary depending on the
definition within the area service number analysis).
A service call is routed to a destination where the service can be provided to the subscriber,
such as a service centre.
Service centres are located in a number of different places in the network. Depending on the
location of the subscriber, the call will be routed to the nearest service centre.


Figure 19 Source of Zone Code
3.6.3 Results
The result will be the number of the service centre nearest to the geographical location of the
subscriber. These two analyses together form the output for the area service number
analysis.
The parameter SERVICE TYPE is the output of the normal pre-analysis for a MOC. The
values for routing zones are part of the cellular-network database in the MSS/MSC.
A combination of these two parameters refers to the correct service number which is
analysed in tree 30, TON=NAT.
The result of digit analysis, as demonstrated Figure 21, is that the call is forwarded to the
nearest requested service centre.

< EPO:NO=9,;

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

47 (92)

MSCi DX220-LAB 2007-12-12 18:13:42

BASE TRANSCEIVER STATION DATA FOR BTS09 NUMBER 00009
=========================================================

BSC NAME :BSC04 NUMBER :00001
LA NAME :LAC130 LAC :00130
MOBILE COUNTRY CODE ....................(MCC)... :222
MOBILE NETWORK CODE ....................(MNC)... :11
CELL IDENTITY ..........................(CI).... :00130
BTS ADMINISTRATIVE STATE ....................... :UNLOCKED

ROUTING ZONE ...........................(RZ).... : 3
TARIFF AREA ............................(TA).... :000

Figure 20 Routing Zone Example
< ZRUI;


MSCi DX220-LAB 2007-12-12 18:51:10

INTERROGATING AREA SERVICE NUMBERS

AREA SERVICE ROUTING SERVICE ANALYSIS TYPE OF SERVICE
NUMBER ZONE TYPE TREE NUMBER NUMBER
IN CM INDEX

A 3 17 30 NATIONAL 1

COMMAND EXECUTED

Figure 21 Area Service Number Analysis

Other types of Control Plane Analyses is concluded in the following figure:

Routing in MSS

48 (92) Nokia Siemens Networks

CN34017EN30GLN1

65 Nokia Siemens Networks Presentation / Author / Date
Soc Classification level
DIGIT
ANALYSIS
CM
BEARER
CAPABILITY
ANALYSIS
DIALLING
PREANALYSIS ANALYSIS
ROUTING &
CHARGING
ATTRIBUTE
ANALYSIS
CALL
BARRING
ANALYSIS
CM
EOS
ATTRIBUTE
ANALYSIS
REASON
CODE (CD_T)
OR
FACILITY
CODE
REASON
CODE (CD_T)
FUNCTION
ANALYSIS
*2
EOS
ANALYSIS
*1
ORIGIN
ANALYSIS
*3
*1 can be executed in several different call phases
*2 can be executed only in speech state
*3 is executed only in mobile originated calls
CHARGING
MODIFICATION
ANALYSIS
*4
*4 is executed in MOC and MTC in the call setup phase
AIF

Figure 47 Other Control Plane Analysis

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

49 (92)

3.7 Attribute Analysis
Pre-analysis
Digit
analysis
Tree
selection
Routing
Attribute
Analysis
Origin
Analysis
Charging
Attribute
Analysis
C_ORG C_ORG'
TREE'
TREE
EOS
Attribute
Analysis
Attributes
Attributes

Figure 22 Order of Attribute Analysis
There are three types of attribute analysis, which can influence the digit analysis.
Routing attribute analysis
Charging attribute analysis
EOS attribute analysis

3.7.1 Attributes
The purpose of all these attribute analyses is to analyse different attribute values and provide
the final results, which can affect the digit analysis to obtain different destinations. Most of
the attribute values used as input parameters for different types of attribute analysis are the
same.
The following table is an example of attributes that each attribute analysis can use as input
parameters.

Routing in MSS

50 (92) Nokia Siemens Networks

CN34017EN30GLN1

Table 6 Example of Attributes Used for Different Attribute Analyses
Attribute analyses Attributes
1.Routing Attribute
Analysis
-Incoming Signalling
-Subscriber Category
-IMSI Indicator
-Channel type
-MS Power Capability
-Routing Category
-Etc.
2.Charging
Attribute Analysis

-Incoming Signalling
-Subscriber Category
-IMSI Indicator
-Channel type
-MS Power Capability
-Routing Category
-Etc.
3. EOS analysis -Incoming signalling
-Cause Code
-Subscriber category
-IMSI indicator
-Etc.


Note
For a complete list of the attributes, see Appendix C: Attributes.

The basic structure of each attribute analysis is the same. Attribute analysis consists of
different attributes. The operator can freely decide which attributes have to be analysed
together with the desired values in a different attribute analysis. The operator can also decide
in which order the analysis is to be done.
Attribute analysis does not influence call set-up if the analysis has not been created. Attribute
analysis is created step by step, so that the analysis is built up of different sub-analysis
names. Each sub-analysis consists of an analysis of one attribute. The link to another
attribute is just the sub-analysis name. The following figure shows the steps of attribute
analysis, which uses three attributes to analyse the different final results.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

51 (92)

Attribute1
An attribute and its values
What is the wanted value?
Result of subanalysis
What is the corresponding
result?
Value2
Value3
Value4
Value1
Result1
Result 2
Result 3
Result 4
Default
Attribute2
Value2
Value1
Attribute3
Value2
Value1
Result 5
Subanalysis1
Subanalysis2
Subanalysis3
Final result

Figure 48 Attribute Analysis
3.7.2 Final result for attribute analysis
The final result of the analysis depends on the type of attribute analysis. The final results of
the routing, charging and EOS attribute analyses are presented in the following paragraphs.
3.7.2.1 The final result of routing attribute analysis
The result can be defined with the following information:
New digit analysis tree or original digit analysis tree (before routing
attribute analysis)
Intermediate announcement to calling (or redirecting) subscriber
with a chargeable / free announcement indication.
The default result is that the analysis does not change the digit analysis tree and there is no
announcement for the subscriber.

Routing in MSS

52 (92) Nokia Siemens Networks

CN34017EN30GLN1

Digit
analysis tree
Intermediate
annoucement
Attributes
Digit
analysis
Routing Attribute
analysis
Destination
Hello

Figure 49 Final Results of Routing Attribute Analysis
3.7.2.2 The final result of charging attribute analysis
By means of this analysis the charging origin information (C_ORG) can be changed. The
default result is that the analysis does not change the charging origin.
The charging attribute analysis is very flexible and powerful. With this application the regional
subscriber could, for example, be charged differently depending on his location. If he is
inside his home area, the call can be cheaper, but if not, the call can be more expensive or
the subscriber can't make / receive the call at all.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

53 (92)

Charging
Origin
Attributes
Charging Attribute
analysis
Charging
Destination
Charging
analysis

Figure 50 Final Result of Charging Attribute Analysis
Charging attribute analysis only affects mobile originating calls, PSTN originating calls, PBX
originating calls and call forwarding calls, but it does not affect emergency calls.


Note
Charging attribute analysis and routing attribute analysis are not
processed for the alternative route analysis, for the number modification
and for a roaming number.

3.7.2.3 The final result of End Of Selection (EOS) attribute analysis
The result of the EOS attribute analysis can influence the continued processing of a call
beside the EOS analysis by using attributes.
The results of EOS attribute analysis are the same as the results of EOS Analysis, but the
strength of the attribute analysis is that the input parameter for the analysis does not
necessary have to be only the 'cause code'. Thus, the proceeding of a call can be affected
with the aid of several attributes (parameters).
The EOS attribute analysis is processed if the user defines the result of the EOS analysis to
be ' EOS attribute executed'.

Routing in MSS

54 (92) Nokia Siemens Networks

CN34017EN30GLN1

The main result of EOS attribute analysis is:
Stop call
Execute the digit analysis with MSRN or for a call forwarding
number
Execute the digit analysis with a called number
Execute the digit analysis again for default routing purposes
Execute re-hunting of an outgoing circuit
Execute alternative sub-destination analysis
Execute repeat attempt procedure.
EOS Attribute
analysis
Attributes
Execute Alternative
subdestination analysis
Execute Digit
analysis
Stop call
Execute Rehunting of
an outgoing circuit
Execute Repeat
Attempt procedure
EOS analysis
Cause code

Figure 51 The Final Result of EOS Attribute Analysis
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

55 (92)

3.8 AIF Attribute Analysis
The AIF attribute analysis is an optional feature where the MSC performs the analysis. As a
result the Priority Information Element (PIE) is sent to the BSC, if the BSC parameters allow
this event. The BSC uses the PIE to determine whether an assignment request or a
handover request has to be performed unconditionally and immediately. If this is the case, it
may lead to a forced release or a forced handover of an existing connection of a lower
priority.
MSC
Attributes
AIF
Attributes
Analysis
Priority
Information
Element (PIE)
Assignment
Request
Handover
Request
BSC

Figure 52 AIF Attribute Analysis

Routing in MSS

56 (92) Nokia Siemens Networks

CN34017EN30GLN1

3.9 Summary
Area service
numbers
Dialling
preanalysis
TREE selection
CM Digit analysis
EOS Analysis EOS Analysis
Charging
attribute analysis
Origin Analysis
MOC
TON
NPI
digits
MS_Class mark
MSCAT
Cell Tariff
Circuit group (TOC)
CORG
attributes
Cause code
CORG'
DESTINATION
TREE'
Routing attribute
analysis
attributes
circuit group
PRFILE
routing zone
service type
digits/TON
normal call
TREE
TREE/ TON/ digits
TREE
EOS Attribute
Analysis
attributes
Call bar analysis
Cont. or Stop
Signalling System


Figure 53 Analysis Summary
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

57 (92)

4 User Plane Routing
In the MSC Server (MSS) system, the actual user plane (bearer) connection is separated
from the control plane (call control and signalling) connection. In a circuit-switched network
this separation is partial. With the user plane routing functionality and the related MMLs, it is
possible to control and use the ATM , IP , and TDM user plane resources provided by
external Multimedia Gateways (MGWs).
User plane routing is responsible for controlling the user plane transmission in the MSS in a
network where media processing is decomposed to several network elements, to MGWs.

Figure 54. Decomposed Network Architecture
Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

59 (92)


4.1 User Plane Analysis
One part of the user plane routing configuration is User Plane Analysis. It consists several
analysis chains, which are itemized by phase names. The operator can define the
relationship of parameters (call's and network's) and analysis phases by User Plane Analysis'
MML.
User Plane Analysis and its components are created by UANHAN MML. The analysis
consists several sub analysis, which can be linked to chain and the different kind of results.
The structure of one analysis is in figure13.
4.1.1 Parameters of User Plane Analyses


















Routing in MSS

60 (92) Nokia Siemens Networks

CN34017EN30GLN1

s u b a n a l y s is
s u b a n a l y s is
s u b a n a l y s is
D e f a u l t r es u l t
R e s u l t _s u b a n a l y s is
U n k n o w n
r e s u l t
D e f a u l t r e s u l t
D e f a u l t r e s u l t
R e s u l t _s u b a n a l y s is
s u b a n a l y s is
R e s u l t _s u b a n a l y s is
.
.
F i n a l r e s u lt
P a r a m e t e r
P a r a m e t e r
P a r a m e t e r
P a r a m e t e r
D e f a u l t r e s u l t

Figure 55 Example of User Plane Analysis structure


The six phases involved respectively to the User Plane Routing in the user plane analyses:
4. Succeeding UPD determination
1. Preceeding UPD determination
2. Succeeding BNC Characteristics
determination
3. CMN determination
5. Succeeding Action indicator
determination
6. Inter-Connecting BNC
Characteristics determination

Figure 56 User Plane Analysiss' relationship
Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

61 (92)

4.1.2 Six Phases in User Plane Analyses
The different phase of User Plane Analysis have relationship to each other. The result of an
analysis can be the input parameter for the next phase. Maximal interrelation is presented in
figure 56.
Note: Those parameters, which are obligatory for the successful analysis in a specific
phase, are marked with (*)
4.1.2.1 Phase Preceding UPD determination
This Phase is needed only for BICC and SIP signallings. RANAP signalling is able to figure
out appropriate UPD for a call.
Significant parameters:
Phase
User Plane Bearer Requirement, UPBREQ
Emergency call indicator
Preceding Signalling type
Preceding BNC Characteristics
Preceding Action Indicator
Preceding BCU-ID
Preceding UPDR (*)
Preceding User Plane Destination, UPD (result)
4.1.2.2 Phase Succeeding BNC Characteristics determination
This Phase is needed to figure out bearer technology used towards succeeding MGW. This
Phase is valid with BICC and SIP signallings.
Significant parameters:
Phase
User Plane Bearer Requirement, UPBREQ
Emergency call indicator
Preceding User Plane Destination, UPD (from phase 1, if exists)
Preceding Signalling type
Succeeding Signalling type
Preceding BNC Characteristics
Preceding Action Indicator
Preceding BCU-ID
Preceding UPDR
Succeeding UPDR
Inter MSS handover indicator

Routing in MSS

62 (92) Nokia Siemens Networks

CN34017EN30GLN1

Succeeding BNC Characteristics (result)
4.1.2.3 Phase CMN determination
This Phase is used to detect whether a MSC Server should act as a CMN node. Pre-
condition for this analysis execution is that Phase Succeeding BNC Characteristics
determination has been executed.
Significant parameters:
Phase
OLCM usage indicator
Preceding Signalling type
Succeeding Signalling type
Preceding BNC Characteristics
Succeeding BNC Characteristics (from phase 2)
Preceding UPDR (*)
Succeeding UPDR (*)
CMN indicator (result)
4.1.2.4 Phase Succeeding UPD determination
This Phase is needed only for BICC and SIP signallings. RANAP signalling is able to figure
out appropriate UPD for a call.
Significant parameters:
Phase
User Plane Bearer Requirement, UPBREQ
Emergency call indicator
Succeeding Signalling type
Succeeding BNC Characteristics (from phase 2)
Preceding Action Indicator
Preceding BCU-ID
Preceding UPDR
Succeeding BCU-ID (This parameter has meaning only in case
of delayed MGW selection. It can be received from the
succeeding MSS in APM.)
Succeeding UPDR (*)
Succeeding User Plane Destination, UPD (result)
4.1.2.5 Phase Succeeding Action indicator determination
Significant parameters:
Phase
Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

63 (92)

User Plane Bearer Requirement, UPBREQ
Emergency call indicator
Preceding User Plane Destination, UPD (from phase 1, if exists)
Succeeding User Plane Destination, UPD (from phase 4)
Preceding Signalling type
Succeeding Signalling type
Preceding BNC Characteristics
Succeeding BNC Characteristics (from phase 2)
Preceding Action Indicator
Preceding BCU-ID
Preceding UPDR
Succeeding UPDR
Inter MSS handover indicator
Succeeding Action Indicator (result)
4.1.2.6 Phase Inter-Connecting BNC Characteristics determination
Significant parameters:
Phase
User Plane Bearer Requirement, UPBREQ
Emergency call indicator
Preceding User Plane Destination, UPD (from phase 1, if exists)
Succeeding User Plane Destination, UPD (from phase 4, if
exists)
Preceding Signalling type
Succeeding Signalling type
Preceding BNC Characteristics
Succeeding BNC Characteristics (from phase 2, if exists)
Preceding Action Indicator
Succeeding Action Indicator (from phase 5, if exists)
Preceding UPDR
Succeeding UPDR
Inter-Connecting BNC Characteristics list (result)

Routing in MSS

64 (92) Nokia Siemens Networks

CN34017EN30GLN1

4.2 User Plane Topology Database
User plane topology database is a separate structural element in the MSC Server (MSS). Its
main purpose is to store user plane topology information and when requested, deliver this
information to the user plane control application. The user plane control application uses
topology data to route the user plane to the proper destination.
There are two kinds of data in the topology database:
Data records for User Plane Destinations (UPDs)
Data records for interconnections

Figure 57 User Plane Topology Information
The operator enters the actual network configuration to the database using MML commands.
Furthermore, a database manager forms the interface towards the user plane control
application for database inquiries.
4.2.1 User Plane Destination
The User Plane Destination (UPD) defines connections to (incoming side) and from
(outgoing side) the MGW which controlled by an MSS. The UPDs are created by the
operator during network configuration. Physically, a UPD is one record in the topology
database. The number of UPDs stored in the database is limited to 1000. From one MSS'
point of view, the UPDs are a set of MGWs, which are grouped based on certain criteria.
Additionally, UPDs reflect the operator's intention about the planned routing schemes. The
typical grouping criterion is BNC characteristics and IP Trunk capability. UPDs can be
overlapping. This means that different UPDs can contain the same MGWs where the
grouping viewpoint is different.
The grouping can be different not only based on BNC characteristics, but also based on the
IP Trunk capability indicator. In case such a parameter is set, call setup procedures are
executed differently. In case the IP Trunk indicator is ON, it means that the UPD is targeted
to Nokia M11 IPET (IP Trunk) and acts accordingly.
Example 1.
Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

65 (92)

UPD_1 is defined with MGW_1, MGW_3, and MGW_17. The UPD BNC characteristics are
defined as ATM AAL2 . This means that when the call is routed through this UPD, only the
above listed MGWs can be used towards the given direction and the connection type will be
ATM AAL2 eventually.
Example 2.
UPD_2 is defined with MGW_1 and MGW_21. MGW 1 is included also in UPD_1. The BNC
characteristics is IPv4 in this case, so both selectable MGWs establish IP connections
towards the destination.
Example 3.
UPD_3 is defined with the very same configuration like UPD_2. The BNC characteristics is
IPv4, the MGWs are the same. The IP Trunk capability is also set, which means that the
UPD points to M11 IP Trunk. In that case the call setup operation will be different compared
to UPD_2. For example, no Iu/Nb Framing Protocol (FP) is used in the user plane
connection.
The figure below shows an example of UPDs towards the succeeding MSS B. In this
example there are several UPDs used towards the same destination.


Figure 58 User Plane Destinations

A User Plane Destination (UPD) consists of parameters specific for the user plane
destination itself. In addition, part of the parameters are MGW-specific.
Backbone network connection characteristics
It indicates what type of bearer is used in the UPD (AAL2, IPv4).
Default codec
It indicates the default codec used in the UPD in case more
optimal codec cannot be negotiated (the possible values are
G.711, EFR, FR).

Routing in MSS

66 (92) Nokia Siemens Networks

CN34017EN30GLN1

List of MGW identifiers (MGW-specific)
It identifies the MGWs belonging to the UPD.
MGW re-selection provisioning status
It indicates the provisioning status of the MGW reselection
procedure.

Note
This parameter can be set for both normal and emergency calls.

Trunk capability
It indicates if the UPD provides interworking towards the Nokia IP
Trunk (IPET).

User plane destination index
Numerical identifier of the User Plane Destination
User plane destination name
Alphabetical identifier of the user plane destination (15
characters)
Load Sharing Index (MGW-specific)
Weight value for user plane traffic sharing between MGWs in the
scope of one UPD
You can use MML command to interrogate the UPDs defined in the MSS.
ZJFL;
DX 200 DX220-LAB 2007-12-12 17:33:12
NAME ID BNCC
---- -- ----
UPD1 000 AAL2
UPD2 001 IPV4
UPD3 002 AAL2
UPD4 003 IPV4
UPD5 004 IPV4

COMMAND EXECUTED

Figure 59 UPDs Defined in MSS

ZJFI:NUPD=UPD1;
DX 200 DX220-LAB 2002-04-29 11:28:42
NAME: UPD1 ID: 000
RESELECTION PROVISION
NORMAL CALLS: PREPARE BNC
EMERGENCY CALLS: ESTABLISH BNC
BNC CHARACTERISTICS: IPV4
UPD CAPABILITIES
TRFO: SUPPORTED
TRUNK: NOT SUPPORTED
DEFAULT CODEC: G711
-----------------------------------------------------------------
Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

67 (92)

MGW LIST:
NAME ID REG LDSH
---- -- --- ----
MGW1 0 Y 25
COMMAND EXECUTED
Figure 60 UPD Printout
4.2.2 User plane topology between MGWs
The interconnection data in the topology database gives a possibility to make configurations
where user plane is routed through two MGWs controlled by one MSC Server. The
interconnection data defines user plane connectivity between MGWs.

Figure 61 User plane routed through two MGWs

Interconnection data is organised on per MGW basis. For each MGW the interconnection
data consists of a list of interconnection data elements that identify existing interconnections
from a particular MGW towards other MGWs and an indication about full-meshed
connectivity.
The relevant properties related to interconnections are:
MGW identifier
Identifies the MGW in question, which is connected to one or
several other MGWs. The other MGWs are identified either by
the full-meshed connectivity or interconnection data.
Full meshed connectivity
Indicates fully-meshed configuration. The full-meshed indication
is MGW- specific and it means that the MGW has connectivity to
all other MGWs within the same MSS area with the given BNC

Routing in MSS

68 (92) Nokia Siemens Networks

CN34017EN30GLN1

characteristics. Possible interconnecting BNC characteristics in
the full-meshed configuration are ATM AAL2 and IPv4 . The full-
meshed configuration can be supported with one or more BNC
characteristics simultaneously.
Interconnection data
Interconnection data defines interconnections towards one or
more other MGWs that are controlled by the same MSS. In
addition to identifying other MGWs, it also identifies what kind of
bearer connections exist towards those MGWs by defining the
available BNC characteristics. Possible interconnecting BNC
characteristics are ATM AAL2, IPv4, and TDM. An
interconnection can support one or more BNC characteristics
simultaneously. In case of TDM interconnections, the
interconnection data also identifies up to three interconnecting
TDM routes between the MGWs.
Note
Regardless of whether the interconnected MGWs are physical or virtual MGWs, you always
have to define interconnections between them if calls should be routed through the two
MGWs.

ZJFG:MGW=1:NMGW=ALL;
DX 200 DX220-LAB 2007-12-12 14:52:14
INTERROGATED MGW:
NAME ID
---- --
MGW2 1
CONNECTED MGWS:
NAME ID REG BNCC ROUTE
---- -- --- ------------------- -------------
---
MGW3 2 Y AAL2 IPV4
MGW4 3 Y AAL2 IPV4
MGW6 5 Y AAL2 IPV4 TDM 22, 23, 348
COMMAND EXECUTED
Figure 62 MGW Interconnection Printout

You can find the MGW information with ZJGI:








Fehler! Verweisquelle konnte nicht gefunden werden.

CN34017EN30GLN1

Nokia Siemens Networks

69 (92)


MGW DATA:
MGW ID........5
MGW NAME......KL_MGW1
MGW ADDRESS...111.111.111.111
PORT NUMBER...11111
DOMAIN NAME...
ROUTE.........4095
MGW TYPE......GENERAL
UNIT TYPE.....CCSU
UNIT INDEX....35
CTRL ADDRESS..255.255.255.255
E164 ADDRESS..88888888
LOCAL BCU-ID..0
TRFO..........NOT ALLOWED
IPATM.........NOT ALLOWED
REG...........ALLOWED
REG STATUS....REGISTERED


Figure 63 MGW Information in MSS

Routing in MSS

70 (92) Nokia Siemens Networks

CN34017EN30GLN1

5 Relationship Between User Plane and
Control Plane Routing
Despite being separate entities, the user plane and the control plane is linked in an indirect
and flexible way via the User Plane Destination (UPD) and User Plane Destination
Reference (UDPR) parameters.
5.1 RANAP Signalling
The UPDs towards the radio access network are configured directly in the radio network
configuration data. Therefore, in the UE originating or terminating calls neither the preceding
nor the succeeding UPD determination phase is needed for the UE side of the call.

RNC CREATED TO OWN RADIO NETWORK
===========================================
RNC IDENTIFICATION:
RNC IDENTIFICATION............. RNCID ... : 0001
MOBILE COUNTRY CODE............ MCC ..... : 123
MOBILE NETWORK CODE............ MNC ..... : 321
RNC NAME....................... RNCNAME . : FIRST

RNC PARAMETERS:
RNC STATE...................... STATE ... : LOCKED
USER PLANE DESTINATION INDEX... UPD ..... : 001
USER PLANE DESTINATION NAME.... NUPD .... : USERPLANE1
RNC VERSION.................... VER ..... : R4
AMR SPEECH CODEC MODE COUNT.... AMR ..... : 1
RNC GLOBAL TITLE ADDRESS....... DIG ..... : 12345
NUMBERING PLAN................. NP ...... : E164
TYPE OF NUMBER................. TON ..... : INT
NETWORK INDICATOR.............. NI ...... :
SIGNALLING POINT CODE.......... SPC ..... :

Figure 64 RNC Information in MSS
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

71 (92)

5.2 BICC and SIP Signalling
The UPDR parameter is used as a link between the control plane and the user plane. For the
incoming calls, the operator configures the UPDR parameter to the circuit group data. For the
outgoing calls, the operator configures the UPDR parameter to the route data. On per call
basis, the value of UPDR is delivered to user plane control application to be used as an input
attribute in several phases of the user plane analysis along with many other input attributes.
Both the BICC and the SIP signalling behave similarly in this respect.

Figure 65 UPDR parameter on outgoing side
In this figure the UPDR value 5 is read from the outgoing ROUTE data. It is used as an input
attribute for user plane analysis with many other attributes as defined in User plane analysis
attributes. Analysis results to UPD=2 means that two MGWs belonging to the UPD2 are
allowed to be used for a call.
RCI:SEA=13:UPDR=133:PRINT=3:;
CIRCUIT GROUP(S)
CGR : 372 NCGR : BICC_BI
AREA : - STD : -
MAN : - AAN : -
SSET : - CLI : -
CAC : 123451 CACI : -
REMN : - RFCL : -
ICLI : - CHRN : -
ATV : -

EC : 0 DBA : 1 PRI : 1 CORG : 0 DCC :
-
LOC : - DNN : - RDQ : - DDQ : - IGOR :
-
ECAT : - EOS : - UPDR : 133

Figure 66 CGR Information in MSS

RRI: GSW: ROU=14;

Routing in MSS

72 (92) Nokia Siemens Networks

CN34017EN30GLN1

ROU TYPE OUTR STP TSG TMT SAT ATME DCME ECHO CONT TON SEQH ICR
14 EXT OMZ00 1 - - N N N N N UNK N
N
RCR MCR OCR RPR PBX ISDN STATE NCGR
N N N N Y N WO-EX HEL1L
APRI ASTC NCCP T_IND ENBLOC ATV CLISET
NCLISET
N N BSSAP 0 - - 0
DEFAULT
AICR PNR RNPR RFCL PCLI
NEF
- - - - -
MSS
UPDR
1000
FCL
-

Figure 67 Route Information in MSS
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

73 (92)

6 MGW Selection
An MGW selection is a functionality in the MSC Server (MSS), which is necessary for
selecting an optimal MGW for the user plane transmission for a call.
6.1 MGW Selection Basic Functionality
In case of physical TDM resources the circuits are hunted at the control plane level in the
MSS. The circuit that has been assigned for the call directly identifies also the MGW where
the resource is configured. In this case, the MGW selection for the call is dictated by the
TDM circuit. The MGW where the circuit is configured is always selected.
In case of ephemeral resources, like ATM AAL2 or IP, the situation is different. There can be
several MGW candidates that are suitable for user plane transmission for the call. The user
plane level MGW selection procedure is then invoked to find the available MGW candidates
and to make the selection among them.
Taking the MSS user plane routing application into consideration, the MGW selection
procedure consists of the following logical subtasks:
Collecting control plane and user plane-related information from
signalling and call control applications.
Further processing of collected data in user plane analysis. The
'preceding UPD determination' and 'succeeding UPD
determination' user plane analysis phases are executed in order
to solve UPDs, which contain the MGW candidates for a call. In
UE- -originating or -terminating calls, the UPD is directly defined
in the radio network configuration data and is provided to the
user plane control application. In this case the user plane
analysis phases mentioned are not executed for the UE side of
the call.
Collecting updates and possible changes to control plane- and
user plane- related information from signalling and call control
applications. If the user plane control application receives new
information, data processing is done again on condition that the
actual resources of an MGW have not been reserved yet.
Template for NET customer documents written with Word 2000

74 (92) Nokia Siemens Networks

CN34017EN30GLN1

Selecting an MGW from the UPD. Selection can be done, for
example, by using load sharing weight values as specified in the
following sections.
The most optimal result for an MGW selection is that the user plane is routed via one MGW
under the scope of one MSS. This is a preferred functionality that the user plane control
application targets during MGW selection. In such cases, the 'preceding UPD determination'
and the 'succeeding UPD determination' user plane analysis phases result in the same UPD,
and from that, a common MGW can be selected for the incoming and the outgoing side user
plane.



Figure 68 Example of MGW selection between different UPD

Another optimal scenario is when the 'preceding UPD determination' and the 'succeeding
UPD determination' user plane analysis phases do not result in the same UPD but there is a
common MGW in the UPDs. In this case the user plane routing application is able to optimise
the selection by finding and selecting the common MGW for the call.
Depending on the network configuration, it is possible to have two MGWs under the scope of
one MSS. This scenario is similar to the previous one, except that there is no common MGW
in the UPDs. An interconnection has to be created between the MGWs and, therefore, the
'inter-connecting BNC characteristics determination' user plane analysis phase is executed.
After the analysis one MGW is selected from the UPD belonging to the side where the
resource reservation request is received first. Then, to find possible MGW candidates for the
remaining (incoming or outgoing) side, the user plane control application makes a topology
database inquiry to check the connectivity between the MGWs in the UPDs. The MGWs
without connectivity are ruled out from the MGW selection.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

75 (92)

6.1.1 Weight-based MGW selection
Normally, the MGW selection from a UPD is done by using the load sharing weight-based
method. A relative load sharing weight is assigned for each MGW in the UPD. When the
UPD contains several MGW candidates that have sufficient capabilities for the call, the load
sharing weight values are used to distribute traffic between the MGWs.
You must configure the load sharing weights for each MGW in the UPD.

Example:
In a UE-originating call the early RAB assignment method is used and the incoming side
MGW is selected first. The incoming side UPD has been obtained from the radio network
configuration data. In the UPD there are five MGWs configured that are all capable of
handling the call and each has an individual load sharing weight.

Figure 69 MGW Selection Based on Load Sharing Weights
The weight-based selection process consists of the following steps:
1. Calculate the sum of the load sharing weights of each MGW
Table 7 Collecting Load Sharing Weights in the MGW
Template for NET customer documents written with Word 2000

76 (92) Nokia Siemens Networks

CN34017EN30GLN1


2. Generate a random number
A random number is generated and scaled to the range from 1 to the sum of the load sharing
weights. In this example, the random number is in range [1-116].
3. Select MGW from UPD
Each MGW is assigned a number range depending on the index of the MGW and the load
sharing weight.
Table 8 Selecting MGW from UPD

The MGW with the range matching to the scaled random number is selected. For example, if
the generated random number is 88, then it falls to MGW_5 range [77-116], and MGW_5 is
selected.
The load sharing weight-based MGW selection method provides flexible mechanism for
weighted traffic distribution between MGWs. When new MGWs are added to a UPD or
MGWs are removed from a UPD, the traffic is automatically distributed between all the
MGWs depending on their relative weight. Note that relative load sharing weights of the other
MGWs in a UPD remain unchanged when a new MGW is added to a UPD or an MGW is
removed from a UPD. This means that adding or removing an MGW has effect also on the
percentage of traffic that is routed through the other MGWs. The traffic from the other MGWs
is either directed to the new MGW or it is directed from the removed MGW to other MGWs.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

77 (92)

If an MGW has load sharing weight defined to zero in a certain UPD, no traffic that is directed
to that UPD is routed through that MGW.
The same MGW can belong to several different UPDs and can have different load sharing
weight in each UPD. The total traffic directed to an MGW is the sum of the substreams of
traffic that is directed to the MGW from each UPD.
6.2 Call Mediation Node
The Call Mediation Node (CMN) mode operation is possible if no user plane resource is
required by the MSS and the required type of user plane connectivity exists between the
preceding and succeeding nodes controlling the user plane. During call processing, based on
its configuration data, the MSS is able to determine whether it should act as a CMN or a TSN
node. The CMN detection is carried out by a user plane control application via executing user
plane analysis phase 3, CMN determination.
When the MSC Server is in CMN mode, it is no longer possible to return to TSN mode. The
CMN functionality can be used with the BICC and SIP call control signalling.
Call control signalling interworking is not allowed in CMN mode. This restriction means that
the incoming and the outgoing signalling used in the CMN node must be the same.
In the figure below MSS CMN acts as a CMN between MSS A and MSS B.
The BCU-ID-based MGW selection optimisation can be especially useful when CMN nodes
are involved in the call between the MSSs that control user plane resources. In this case
determining an optimal preceding or succeeding UPD towards the peer MSS can be
problematic because the CMN node can hide the identity of the peer MSS that controls user
plane resources. The BCU-ID can be used to overcome the problem. It can identify the MGW
that was selected for the call by the peer MSS. This information can be used in user plane
analysis to select an optimal UPD that provides connectivity towards the MGW selected by
the peer MSS.
Template for NET customer documents written with Word 2000

78 (92) Nokia Siemens Networks

CN34017EN30GLN1


Figure 70 Call Mediation Node Operation

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

79 (92)

APPENDIX A: OPTIONAL ANALYSES
1 Bearer Capability Analysis
The purpose of bearer capability analysis is to determine whether the call is a data or fax call
and select the right handling for those calls.

BCIE
Modem
Fax/Modem
Data interface unit
Bearer
Capability
Analysis
Internal route to
....

Figure 71 Bearer Capability Analysis
1.1 Input
This section explains the sources of information to perform the analysis.
Here are some examples of BCIE information, used in BCIE analyses for data calls:
Information Transfer capability
Radio Channel Requirement
Number of Data bit/Stop bit
User rate
Parity information
Modem type
Connection element.
In speech calls only the radio channel requirement is checked. The radio channel
requirement has the following information attached:
Half rate
Full rate
Template for NET customer documents written with Word 2000

80 (92) Nokia Siemens Networks

CN34017EN30GLN1

Dual/half rate preferred
Dual/full rate preferred.
1.2 Process
In a MOC, the BCIE is obtained from the MS itself on a SETUP signalling
message, while in mobile-terminating calls it is received from the HLR as
a basic service associated with the dialled MSISDN.
The bearer capability analysis checks the validity of the BCIE, which
contains information about the required bearer and tele-services.
1.3 Output
The bearer capability analysis produces an internal route in the
MSS/MSC as an output. The route contains a set of required entities (for
example, facsimile modems and data interface units).
If the BCIE is invalid, the call is cleared.
2 Call Barring Analysis
The purpose of call barring analysis is to detect possible outgoing
call restrictions.
As illustrated in Figure 72, the parameters used as inputs to call barring
analysis are:
Supplementary service barring classes (SS)
Operator-determined barring classes (ODB)
Called number with TON
Roaming status
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

81 (92)

ANALYSIS
FILES
ANALYSIS
RESULT
FILE
BARRING INFO
SUPP. SERVICE BARRING CLASSES
OPERATOR DETERMINED BARRING C.
CALLED NUMBER WITH TON(TON)
ROAMING STATUS
CM

Figure 72 Call Barring Analysis
The main tasks of call barring analysis are to find out in what way calls
are restricted to this subscriber and instruct the exchange to take action
based on this.
2.1 Input
This section explains the sources of information to perform the
analysis.
1. SS barring classes have four possible values:
Barring of all outgoing calls
Barring of all international outgoing calls
Barring of all international outgoing calls, except when the call
is directed to the subscriber's home country
Barring of all outgoing calls if the subscriber is abroad.
2. ODB classes. These specify the barring conditions of outgoing
calls, roaming, or supplementary service management.
The ODB classes apply only to your own subscribers, who are
either located in the home PLMN or roaming in the visited PLMN.
The operator-specific categories do not apply to the roaming
subscribers of foreign operators.
Several ODB categories can be in use simultaneously. For
outgoing calls, the subscriber can have up to seven categories
active at the same time.
You can activate one of the following categories:
Barring of outgoing calls
Barring of outgoing international calls
Barring of outgoing international calls, except for those directed
to the home PLMN country
Template for NET customer documents written with Word 2000

82 (92) Nokia Siemens Networks

CN34017EN30GLN1

Barring of outgoing calls when roaming outside the home
PLMN country.
The first three categories above are invoked in the MSS/VLR.
The last category is sent as barring of outgoing calls to the
MSS/VLR when the subscriber is roaming outside the home
PLMN.
When barring premium rate calls (operator-determined barring),
you can activate one or both of the following categories:
Barring of outgoing premium rate calls (information)
Barring of outgoing premium rate calls (entertainment).
The categories are invoked in the MSS/VLR.
Four types of operator-specific barring categories (operator-
determined barring) can be invoked in the MSS/VLR when the
subscriber is registered in the home PLMN.
You define the effect of the categories by creating a
corresponding analysis in the MSS/MSC of the HPLMN. The
categories can be activated all at the same time; some of them
can also be left inactive.

3. Called number with TON. This is the familiar TON used in many
analyses. It can have the following values:
INT
NAT
SUB
UNK

4. Roaming status may be listed as:
Subscriber in home PLMN country
Subscriber from another country
2.2 Process
There are two ways to activate call barring:
By the subscriber, using an SS
By the operator, using an ODB

When a barring category is invoked during a MOC in the MSC, there
are three possibilities. The call is:

Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

83 (92)


Cleared
Connected to an announcement
Routed to another B party (for example, a network operator)
2.3 Results
This section explains the output of call barring analysis.
The result of the Call Barring Analysis for the call control produces
barring information with values as follows:
3. Continue call setup. This happens when the barring analysis does
not satisfy the barring conditions.
5. Stop call. This value indicates that the analysis satisfies the
barring conditions.
5. Check the country code. This is possible if the subscriber has
activated the "all international calls barred, except his home
PLMN." The result will be to check whether the B SUB is in the
barred country. The result of this further analysis will then be either
Continue Call setup or Stop call.
5. Number modification. When a barring category is invoked during
the call, the called number is modified according to the call barring
analysis and the call is rerouted to the new destination.

When the call is barred, the mobile subscriber receives one of the
following responses:
Announcement / tone;
GSM notification;
Announcement / tone and a GSM notification.











Template for NET customer documents written with Word 2000

84 (92) Nokia Siemens Networks

CN34017EN30GLN1


RKI:SS=BAOC,;

OUTGOING CALL BARRING ANALYSES:

SS TON ATYPE DIG TC ANNC TONE ANN NOTIF SPR
BAOC NAT N 1 N N 0 0 Y
BAOC NAT N 2 N N 0 0 Y
BAOC NAT N 3 N N 0 0 Y
BAOC NAT N 4 N N 0 0 Y
BAOC NAT N 5 N Y 10 0 N
BAOC NAT N 6022 Y N 3 0 N
Figure 73 Call Barring Analysis Printout
In addition to producing these responses, the analysis sends a release
cause code indicating outgoing call barring to the mobile station.
Note
The routing of emergency calls is not affected by call barring functions.
There is no reason for defining restrictions for an emergency
number.
3. Priority Analysis
The priority analysis is used by the call control to analyse different
working states of the exchange. It offers preferential handling in
the traffic handling of a telephone call of a certain type, so that
other calls are barred and/or the priority call in question receives
preferential handling in circuit hunting. The handling of the call in
the exchange depends on the subscriber categories, the
subscriber's selection, and the working state of the exchange.
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

85 (92)

ANALYSIS
FILES
ANALYSIS
RESULT
FILE
PRIORITY INFO
B-SUBSCRIBER CATEGORY
CALL TYPE
WORKING STATE OF THE EXCHANGE
A-SUBSCRIBER CATEGORY

Figure 74 Priority Analysis
The operator can change the working state of the exchange with
MML commands. This feature (Feature 435) is optional.

< ZWOI:13;

LOADING PROGRAM VERSION 7.8-0

EXECUTION STARTED

PARAMETER CLASS: 13 PRIORITY_CALLS

IDENTIFIER NAME OF PARAMETER VALUE CHANGE POSSIBILITY

00000 EXCHANGE_MODE 0000 YES
00003 QUE_SEARCH_TI_OF_OUTCRC 000A NO
00007 QUE_SEA_TI_CODE_EQUIP 0006 NO
00010 OVERLOAD_MSG_USE 0000 YES

COMMAND EXECUTED
Figure 75 Exchange Mode Parameter Printout
Table 9 Exchange Mode Values
Exchange Mode
Values

0000 Normal operation: All calls are allowed during high
traffic.
0001 Only emergency calls and calls, in which one or both
subscribers (sub-A and sub-B) are priority subscribers,
are allowed.
0002 Only emergency calls are allowed.
0003 Only calls in which one or both subscribers (sub-A and
sub-B) are priority subscribers are allowed.
Template for NET customer documents written with Word 2000

86 (92) Nokia Siemens Networks

CN34017EN30GLN1




Note
A priority subscriber is a subscriber who has defined his category as
'primary' (CAT=PR) in HLR.
5. Function Analysis
The function analysis is used by call control to analyse subscriber
facility or subscriber clear codes. The analysis is initiated in the
call active state (speech).
The clear code informs the clearing cause of the call. The facility
code informs of services or events used by the subscriber, or
occurred to the user, for example call drop.
The clear code to be analysed is fetched from a clear message at
the location where the analysis is done.
In the same way the facility code is fetched from a notification
message.
ANALYSIS
FILES
ANALYSIS
RESULT
FILE CD_T (clear code) or DX_SS_T (facility code)
ANALYSIS TARGET (clear or facility event)
SIGNALLING TYPE
ANNOUNCEMENT DATA
TIME SLOT OF THE SIGNAL TONE
NOTIFICATION INFO

used to analyse subscriber's facility or subscriber clear codes


in the ACTIVE call state
RESULT IDENTIFIER
DETECTION POINT

Figure 76 Function Analysis

The parameters used in the function analysis are:
1. Used signalling type (signalling_type_t)
This information is received from the Incoming Register Signalling
File (INSIGN) or the Outgoing Register Signalling File (OUSIGN).
Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

87 (92)

Different signallings, for instance BSSAP and ISUP0, can have
different analyses.

2. Target of the analysis; clear event or facility event
3. Clear code (cd_t) or facility code (dx_ss_t)

The result of Function analysis:
1. The analysis identifier result is always 'continue call' when the
subscriber facility code is analysed.
In the clear code analysis, the analysis result is either 'continue
call' or 'stop call'.
2. Connect tone
This can be the result of clear code and facility code analyses. The
time slot number of the tone is also given to hear some special
tone.
3. Connect speech path
This can be an analysis result of a facility code analysis. This
result is used to disconnect a tone. For instance, when a tone is
connected to a remaining party while the other subscriber is out of
radio coverage, this analysis result is used to disconnect tone and
connect speech paths after successful re-establishment.
4. Connect announcement
This additional result can be defined only in a clear code analysis.
The announcement can be connected to the incoming or outgoing
circuit (MOC or MTC). An index of the announcement is given by
the analysis result. The announcements are not chargeable for the
subscriber.
5. Do not send the received notification
This can be the result of the facility code analysis only.
6. Detection point (DP)
This additional data is used by the system if the related code
(dx_ss_t) is defined to the detection point of IN.






Template for NET customer documents written with Word 2000

88 (92) Nokia Siemens Networks

CN34017EN30GLN1

5. A and Iu Multipoint (additional)

In the new delivery M14, we have such existing functionality:
Feature 1449: Multipoint Iu in MSC Server system feature
introduces a routing mechanism and other related functions
which enable the RAN nodes to route information to different
core network nodes, that is, MSSs.
Feature 1564: Multipoint A interface permits one BSS to be
connected to several core network elements. This feature also
introduces a routing mechanism and other related functions
which enable the BSCs to route information to different MSCs
or MSC Servers.
With this enhancement, Nokia Siemens Networks multipoint
features fully comply with the 3GPP Rel-6 Multipoint
specifications (3GPP TS 23.236). The changed specifications
introduce re-distribution of user equipment in A-, Gb- and
IuFlex-based pool configurations.
With this improvement, the operator can remove load from one
core network node in an orderly and effective way for
scheduled maintenance or load-distribution purposes without
causing service breaks for the end users or additional load on
other entities.
Each core network node in a pool is assigned one unique non-
broadcast Location Area Identification (LAI) and a null-NRI
(Network Resource Identifier) value that are used when
removing load from the core network. When the core network
receives a location update or an attach request, it returns a
new TMSI/P-TMSI with a null-NRI, and a non-broadcast LAI in
the accept message. The non-broadcast LAI will cause the
terminal to immediately send a new location update, which the
RAN node will then route to a new MSC due to the null-NRI.











Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

89 (92)

Figure 77 Example of A Multipoint


Template for NET customer documents written with Word 2000

90 (92) Nokia Siemens Networks

CN34017EN30GLN1


Template for NET customer documents written with Word 2000

CN34017EN30GLN1

Nokia Siemens Networks

91 (92)

Appendix B: The BCIE

The trace below shows the BCIE, which comes to the MSC in the SETUP message on the
DTAP interface.
Bearer Capability
00000100 IE Name Bearer Capability
00000111 IE Length 7
-----010 Info transfer capability 3.1 kHz audio, ex PLMN
----0--- Transfer mode Circuit mode
---0---- Coding standard GSM standardised coding
-01----- Radio channel requirement Full rate channel
1------- Extension bit No Extension
-------0 Establishment Demand
------0- Neg of Intermed Rate Req
-----0-- Configuration Point-to-point
----1--- Duplex Mode Full duplex
--00---- Structure Service Data Unit Integrity
-0------ Spare
1------- Extension bit No Extension
-----001 Signalling access protocol I.440/450
---00--- Rate adaption No rate adaptation
-00----- Access ID Octet identifier
1------- Extension bit No Extension
-------1 Synchronous/asynchronous Asynchronous
---0000- User Info L1 Protocol Default layer 1 Protocol
-01----- Layer 1 ID Octet identifier
0------- Extension bit Extension
----0101 User rate 9.6 kbit/s Rec. X.1 & V.110
---1---- Number of data bits 8 bits
--0----- Negotiation In-band not possible
-0------ Number of stop bits 1 bit
0------- Extension bit Extension
-----011 Parity information None
----0--- NIC on Rx Cannot accept, not supported
---0---- NIC on Tx Not required
-11----- Intermediate rate 16 kbit/s
0------- Extension bit Extension
---01000 Modem type Autobauding type 1
-01----- Connection element Non transparent (RLP)
1------- Extension bit
called party BCD number
01011110 IE Name called party BCD number
00000111 IE Length 7
----0001 Number plan ISDN/telephony numbering plan
-000---- Type of number Unknown
1------- Extension bit No Extension
******** Called party number 01779100101
1111---- Filler

The sections in bold show those parts of the BCIE that are used in the BCIE analysis.
Template for NET customer documents written with Word 2000

92 (92) Nokia Siemens Networks

CN34017EN30GLN1

Appendix C: Attributes
CFC: Call forwarding
ATTRIBUTES ATTRIBUTE ANALYSIS
Charging/Routing EOS attribute
attribute analysis
non-CFC CFC non-CFC CFC
GENERAL ATTRIBUTES
Incoming signalling X X X X
Call Forwarding Leg Indicator X X
Cause Code X X
Phase of Incoming signalling X X
ATTRIBUTES OF CALLING SUBSCRIBER
CLI with TON or only TON X X X X
Subscriber Category X X X X
IMSI Indicator X X
Channel type X X
Cell Dependent Routing Category X X
MS Power Capability X
MS Location Type, Feature 526 X X
Routing Category, Feature 503 X X
ATTRIBUTES OF CALLED SUBSCRIBER
Called number with TON or only TON X X
Routing Category, Feature 503 X
ATTRIBUTES OF REDIRECTING SUBSCRIBER
Redirecting number with TON or only TON X X
IMSI Indicator
X X
Routing Category, Feature 503
X X
Digit analysis tree
Carrier Identification code
( Roaming Subscriber) feature 818
Carrier Selection (Roaming Subscriber)
Feature 818
Reanalysis choice
Carrier Identification Code, Feature 818
Carrier Selection, Feature 818
X
X
X
X
X
X X
X
X
X