Sie sind auf Seite 1von 96
MSCDOCM14PDFCD MSC/HLR, Rel. M14.0, Product Documentation, v.3 User Plane Routing DN01163601 # Nokia Siemens Networks

MSCDOCM14PDFCD

MSC/HLR, Rel. M14.0, Product Documentation,

v.3

User Plane Routing

DN01163601

# Nokia Siemens Networks

1 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The information in this document is subject to change without notice and describes

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation 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 documentation 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 documentation 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 and finally 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 this documentation as soon as possible. IN NO EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY 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 documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The 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 2008. All rights reserved.

2 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Contents

Contents Contents Contents 3 List of tables 4 List of figures 5 Summary of changes 7

Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1

User plane routing 9

2

Call cases for user plane routing 11

3

Control plane signallings in MSC Server 19

4

User plane analysis 21

4.1

User plane analysis architecture 21

4.2

User plane analysis phases 26

4.3

User plane analysis attributes 33

4.4

User plane analysis results 37

4.5

User plane analysis execution 38

5

User plane topology database 41

5.1

User plane destination 42

5.2

User plane topology between MGWs 48

6

Relationship between user plane and control plane routing 53

7

MGW selection 57

7.1

MGW selection basic functionality 57

7.2

MGW selection optimisation based on BIWF address 72

7.3

MGW selection optimisation based on BCU-ID 73

7.4

Tandem operation in MGW selection 75

7.5

User plane control level MGW reselection 76

7.6

MGW selection in TDM routing 79

7.7

Call Mediation Node 80

8

Interconnecting BNC characteristics 83

8.1

Interconnecting BNC characteristics load sharing 83

8.2

Interconnecting BNC characteristics exclusion 86

9

Traffic separation between the MSS and MGW 89

10

Alarms and cause codes issued in user plane routing 91

DN01163601

# Nokia Siemens Networks

3 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing List of tables Table 1. Structure of subanalysis 23 Table 2. Normal and

List of tables

Table 1.

Structure of subanalysis 23

Table 2.

Normal and test sides in normal calls 24

Table

3.

Normal and test sides in test calls 24

Table

4.

Basic call cases 27

Table 5.

User plane analysis attributes 33

Table 6.

Call control logic of forming UPBREQ values 35

Table 7.

Possible results of the user plane analysis 37

Table 8.

Collecting load sharing weights in the MGW 61

Table 9.

Selecting MGW from UPD 61

Table 10. MGW reselection 77

4 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

List of figures

List of figures List of figures Figure 1. Decomposed network architecture 9 Figure 2. MGW selection

List of figures

Figure 1.

Decomposed network architecture 9

Figure 2.

MGW selection network architecture 11

Figure 3.

TDM to ATM/IP

12

Figure 4.

ATM to ATM, call case 1

13

Figure 5.

ATM to ATM, call case 2

13

Figure 6.

ATM to ATM, call case 3

14

Figure 7.

ATM to ATM, call case 4

14

Figure 8.

ATM to ATM, call case 5

15

Figure 9.

TDM to ATM/IP through MSS 15

Figure 10. TDM to TDM through ATM/IP/TDM 16 Figure 11. CMN transit call 16 Figure 12. User plane analysis structure 21 Figure 13. A general example of a subanalysis 23 Figure 14. The relationship of different user plane analysis phases 26 Figure 15. User plane analysis results 38 Figure 16. User plane topology information 41 Figure 17. User plane destinations 44 Figure 18. User plane routed through two MGWs 48 Figure 19. UPDR parameter on the outgoing side 54 Figure 20. LBCU-ID parameter in route selection 55 Figure 21. TDM usage optimisation 60 Figure 22. MGW selection based on load sharing weights 60 Figure 23. MGW selection from the same UPDs 63 Figure 24. MGW selection from different UPDs sharing MGWs in UE-UE calls Figure 25. MGW selection from different UPDs sharing MGWs in UE-CN calls

from different UPDs sharing MGWs in UE-UE calls Figure 25. MGW selection from different UPDs sharing

64

65

Figure 26. MGW selection from different UPDs sharing no MGWs 66 Figure 27. MGW selection from different UPDs with the same physical MGW 68 Figure 28. Congestion control 69

DN01163601

# Nokia Siemens Networks

5 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Figure 29. Traffic overflow control 70 Figure 30. Alternative routing 71 Figure 31.

Figure 29. Traffic overflow control 70 Figure 30. Alternative routing 71 Figure 31. MGW selection based on BIWF address 72 Figure 32. Delayed MGW selection based on the BCU ID Figure 33. Tandem operation 76 Figure 34. MGW reselection 78 Figure 35. MGW selection in TDM routing 80 Figure 36. Call mediation node operation 81 Figure 37. ICBNC load sharing example 84 Figure 38. Traffic separation between the MSS and MGW

node operation 81 Figure 37. ICBNC load sharing example 84 Figure 38. Traffic separation between the

74

90

6 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Summary of changes

Summary of changes Summary of changes Changes between document issues are cumulative. Therefore, the latest document

Summary of changes

Changes between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Changes made between issues 3 0 and 2 3

User plane topology database

The UPD-specific IPNWR parameter has been added to Sections Structure

of user plane destinations and Structure of interconnection data.

Changes made between issues 2 3 and 2 2

User plane topology database

The following UPD-specific parameters have been added to Section

Structure of user plane destinations: Audio call handling method

<option>, Codec Modification Support <option>, Incoming bearer redirection allowance <option>, MGW name, Outgoing bearer redirection capability <option>, and STOM <option>.

A new section has been added on codec preference list.

Changes made between issues 2 2 and 2 1

User plane topology between MGWs

Parameters Load sharing weight and ICBNC not in service flag have been added to the list of relevant properties related to interconnections.

DN01163601

# Nokia Siemens Networks

7 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Interconnecting BNC characteristics A new section has been added on the Interconnecting BNC

Interconnecting BNC characteristics

A new section has been added on the Interconnecting BNC characteristics

load sharing functionality and the Interconnecting BNC characteristics

exclusion functionality.

Traffic separation between the MSS and MGW

A new section has been added on the Traffic separation between the MSS

and MGW functionality.

8 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane routing

User plane routing 1 User plane routing In the MSC Server (MSS) system, the actual user

1 User plane routing

In the MSC Server (MSS) system, the actual user plane, that is, bearer connection is separated from the control plane, that is, 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 user plane transmission in the MSS in a network where media processing is decomposed to several network elements, that is, to MGWs.

Control plane MSS MSS MSS MGW MGW MGW MGW MGW MGW MGW MGW MGW MSS
Control plane
MSS
MSS
MSS
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MSS area
subnetworks
Core network
MGW
MGW
User plane

Figure 1.

Decomposed network architecture

DN01163601

# Nokia Siemens Networks

9 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing These sections cover only the basic functionality of user plane routing. The related

These sections cover only the basic functionality of user plane routing. The related procedures are available in User Plane Routing, Operating

instructions.

10 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Call cases for user plane routing

Call cases for user plane routing 2 Call cases for user plane routing The Multimedia Gateway

2 Call cases for user plane routing

The Multimedia Gateway (MGW) selection functionality in the MSC Server (MSS) enables user plane routing decisions as described in the following examples of different call scenarios.

The figure below shows the network architecture, connections and resources, from the point of view
The figure below shows the network architecture, connections and
resources, from the point of view of MGW selection in an MSS area.
TDM
TDM
BSC
MSS
PBX
TDM
TDM
TDM
TDM
ATM/IP/TDM
PSTN/PLMN
MGW
MGW
ATM/IP
AAL2
ATM/IP/TDM
ATM/IP/TDM
AAL2
ATM/IP
ATM/IP
RNC
MGW
core network

Figure 2.

MGW selection network architecture

DN01163601

# Nokia Siemens Networks

11 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Note ATM/IP (ephemeral resources that are hunted by the MGW) can be the
User Plane Routing Note ATM/IP (ephemeral resources that are hunted by the MGW) can be the

Note

ATM/IP (ephemeral resources that are hunted by the MGW) can be the following:

.

.

.

ATM AAL2

IPv4

IPv6

The physical resources located in the MGW are hunted by the MSS.

TDM to ATM/IP

Control plane routing handles the physical PCM circuits located in an MGW. MGW selection is dictated by the MGW to which the physical PCM circuit is connected. However, the MGW selection procedure is needed for directing 'outgoing media' to the MGW connected to the transmission network. In this case, no additional MGW is needed.

MSS
MSS
PSTN/PLMN
PSTN/PLMN

TDM

In this case, no additional MGW is needed. MSS PSTN/PLMN TDM MGW ATM/IP TDM BSC Figure

MGW

ATM/IP
ATM/IP
TDM
TDM
BSC
BSC

Figure 3.

TDM to ATM/IP

ATM to ATM

ATM to ATM call case 1

MGW selection makes a decision on which MGWs to use and detects the need for an interconnection between two MGWs.

12 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Call cases for user plane routing

Call cases for user plane routing MSS RNC AAL2 MGW ATM/IP/TDM MGW ATM Figure 4. ATM
MSS
MSS

RNC

AAL2

MGW

Call cases for user plane routing MSS RNC AAL2 MGW ATM/IP/TDM MGW ATM Figure 4. ATM

ATM/IP/TDM

MGW ATM
MGW
ATM

Figure 4.

ATM to ATM, call case 1

ATM to ATM call case 2

The MGW selection procedure finds the shortest path towards the succeeding network. For example, in call case 2, only that MGW is selected which is directly connected to both the RNC and the ATM.

MSS ATM/IP/TDM MGW MGW ATM AAL2 RNC possible connection real connection
MSS
ATM/IP/TDM
MGW
MGW
ATM
AAL2
RNC
possible connection
real connection

Figure 5.

ATM to ATM, call case 2

ATM to ATM handover

The mobile subscriber (UE) moves in a very early phase of the call setup, before the RAB Assignment Request is sent to the RNC. The MGW selection procedure has already selected MGWs for the connection, but the actual resource reservation is not performed yet. In the case of such an event, the original RNC passes the control of the UE to another RNC and a new RNC_ID is received on the control plane. Depending on the network configuration, it is possible that the already selected MGWs become obsolete.

 

However, the border MGW which is directly connected to the core network cannot be changed any more. The reason for this is that the MGW information may have already been sent to a succeeding MSS.

DN01163601

# Nokia Siemens Networks

13 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing ATM to ATM call case 3 In this case MGW selection adapts to

ATM to ATM call case 3

In this case MGW selection adapts to this changed situation by selecting a new MGW for an interconnection between the new RNC and the MGW connected to the core network.

the new RNC and the MGW connected to the core network. MSS   AAL2 MGW RNC
MSS
MSS
 

AAL2

MGW  AAL2

RNC

 
 

AAL2

MGW  AAL2

RNC

 
ATM/IP/TDM MGW ATM ATM/IP/TDM
ATM/IP/TDM
MGW
ATM
ATM/IP/TDM

Figure 6.

ATM to ATM, call case 3

ATM to ATM call case 4

In this case the MGW selection procedure determines that the new RNC also has a connection to the same, previously selected, border MGW, and thus, no interconnecting MGW is needed.

MSS RNC MGW MGW ATM AAL2 RNC MGW
MSS
RNC
MGW
MGW
ATM
AAL2
RNC
MGW

Figure 7.

ATM to ATM, call case 4

ATM to ATM call case 5

14 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Call cases for user plane routing

Call cases for user plane routing In this case the MGW selection procedure determines that the

In this case the MGW selection procedure determines that the new RNC also has a connection to the same, previously selected, border MGW, and thus, no interconnecting MGW is needed. In the figure below, the MGW between the RNC and the border MGW acts as an AAL2 layer ATM switch and, therefore, it is invisible to the MGW selection procedure.

therefore, it is invisible to the MGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC
MSS
MSS

RNC

RNC MGW
RNC MGW

MGWRNC

MGW

AAL2

to the MGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC MGW logical connection physical

MGW

ATM
ATM
the MGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC MGW logical connection physical connection
the MGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC MGW logical connection physical connection

RNC

MGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC MGW logical connection physical connection Figure

MGWMGW selection procedure. MSS RNC MGW AAL2 MGW ATM RNC logical connection physical connection Figure 8.

logical connection

physical connection

Figure 8.

ATM to ATM, call case 5

TDM to ATM/IP through MSS

MGW selection decides which MGW to use and detects a need for an interconnecting PCM circuit between the MSS and the MGW.

TDM BSC MSS TDM TDM PSTN/PLMN MGW ATM/IP
TDM
BSC
MSS
TDM
TDM
PSTN/PLMN
MGW
ATM/IP

Figure 9.

TDM to ATM/IP through MSS

TDM to TDM through ATM/IP/TDM

 

MGW selection decides which MGW to use and detects a need for an interconnecting PCM circuit between the MGW and the MSS. In addition, MGW selection detects a need for an interconnecting circuit between two MGWs.

DN01163601

# Nokia Siemens Networks

15 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing TDM BSC MSS BSC TDM TDM TDM ATM/IP/ TDM TDM PSTN/PLMN MGW MGW
TDM BSC MSS BSC TDM TDM TDM ATM/IP/ TDM TDM PSTN/PLMN MGW MGW PSTN/PLMN Figure
TDM
BSC
MSS
BSC
TDM
TDM
TDM
ATM/IP/
TDM
TDM
PSTN/PLMN
MGW
MGW
PSTN/PLMN
Figure 10. TDM to TDM through ATM/IP/TDM

CMN transit call

The following figure describes the network model for a basic Call Mediation Node (CMN) transit call. When the MSS acts as a CMN, it does not control any user plane resources. Practically, it only forwards control plane messages between its peer nodes.

MSS C1 BICC MSS C2 BICC BICC MSS A MSS B RANAP H.248 H.248 RANAP
MSS C1
BICC
MSS C2
BICC
BICC
MSS A
MSS B
RANAP
H.248
H.248
RANAP
MGW A1
MGW B1
RNC
RNC
ATM/IP
core network
MGW A2
MGW B2

Figure 11. CMN transit call

16 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Call cases for user plane routing

Call cases for user plane routing For example, a transit level MSS, acting as a Transit

For example, a transit level MSS, acting as a Transit MSC (TMSC) or Gateway MSC (GMSC), can operate in CMN mode. CMN mode operation is possible if no user plane resource is required by the MSS and the required type of user plane connection exists between the preceding and the succeeding nodes. Based on its configuration data, the MSS is able to determine during the call processing whether it should act as a CMN or a Transit Serving Node (TSN).

DN01163601

# Nokia Siemens Networks

17 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 18 (96) # Nokia Siemens Networks DN01163601   Issue 3-0 en

18 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Control plane signallings in MSC Server

Control plane signallings in MSC Server 3 Control plane signallings in MSC Server Bearer establishment can

3 Control plane signallings in MSC Server

Bearer establishment can be achieved with the following signalling protocols:

.

.

.

BICC

SIP

RANAP

For more detailed information about the signalling protocols and the bearer establishment-related functionality, see the feature descriptions of the following features:

.

.

.

.

.

Feature 1325: RANAP and BSSAP in MSC Server

Feature 1327: Basic Call Cases in MSC Server

Feature 1330: Bearer Independent Call Control (BICC)

Feature 1331: Session Initiation Protocol in the MSC Server

Feature 1335: Speech Transmission Optimisation in MSC Server

DN01163601

# Nokia Siemens Networks

19 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 20 (96) # Nokia Siemens Networks DN01163601   Issue 3-0 en

20 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis 4 User plane analysis 4.1 User plane analysis architecture The user plane analysis

4 User plane analysis

4.1 User plane analysis architecture

The user plane analysis consists of several subanalyses which can be chained and linked to different kinds of results. The structure of an analysis is described in the following figure.

Attribute

   

value

value subanalysis Default result

subanalysis

Default result

value subanalysis Default result
       

Result_subanalysis

 

Attribute

   

value

 

subanalysis

Default result

 
     
   

Result_subanalysis

 
 

Attribute

 
Attribute  

value

 

subanalysis

Default result

value   subanalysis Default result
 
     
   

Attribute

Result_subanalysis

 

value

 

subanalysis

Default result

value   subanalysis Default result
 
     
   
   
   

Final result

 

Figure 12. User plane analysis structure

DN01163601

# Nokia Siemens Networks

21 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The user plane analysis, like the extended preanalysis and the attribute analysis, has

The user plane analysis, like the extended preanalysis and the attribute analysis, has attributes to be analysed. Each attribute can be analysed in one or more subanalyses, and the subanalyses can be chained.

The attribute is a call-related variable. The value of the attribute is the value of the variable. In a subanalysis, there can be only one attribute, but the handling of the different values of this attribute varies. For example, the analysis may continue from the next subanalysis with one attribute value, but may go to the final result with another value.

Starting and continuation subanalyses

The starting subanalysis is a subanalysis from which the execution of the analysis chain starts. All the other subanalyses are continuation subanalyses. Each subanalysis includes the following:

.

.

.

A common part which includes the name of the subanalysis and an attribute identifier of the attribute to be analysed. A unique name is defined for every subanalysis and reference from one subanalysis to the next is made using this name.

A part for normal traffic in which the subanalyses are for normal traffic and which is called normal side.

A part for test traffic in which the subanalyses are for test traffic and which is called test side.

Normal and test sides of a subanalysis

The normal side includes the following information:

.

.

.

the starting point for the analysis of the attribute values

a default result

an unknown result

The structure of the test side is similar to the structure of the normal side.

test side is similar to the structure of the normal side. Note The test side can

Note

The test side can have its own analysis for attribute values, the default result, and the unknown result.

22 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis Table 1. Structure of subanalysis COMMON PART . Subanalysis name . Attribute identifier

Table 1.

Structure of subanalysis

COMMON PART

.

Subanalysis name

.

Attribute identifier

NORMAL SIDE

.

Pointer to normal analysis: analysis of values of attribute

.

Normal default result

.

Normal unknown result

TEST SIDE

.

Pointer to test analysis: analysis of values of attribute

.

Test default result

.

Test unknown result

The following figure is a general example of the normal and the test side of a subanalysis.

Subanalysis name: XXX Final result 1 Attribute identifier: aaa Normal call Normal side value 1
Subanalysis name: XXX
Final result 1
Attribute identifier: aaa
Normal call
Normal side
value 1
.
.
.
Next
subanalysis
value n
Default result
Unknown result
Test call
Test side
Final result 2
value 1
.
.
.
value n
Default result
Final result 3
Unknown result

Figure 13. A general example of a subanalysis

 

The following table shows which side is used in a normal call.

DN01163601

# Nokia Siemens Networks

23 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Table 2. Normal and test sides in normal calls TEST SIDE NORMAL SIDE

Table 2.

Normal and test sides in normal calls

TEST SIDE

NORMAL SIDE

Action

Not exist

Not exist

Alarm

Not exist

Exist

Use normal side

Exist

Not exist

Alarm

Exist

Exist

Use normal side

The following table shows which side is used in a test call.

Table 3.

Normal and test sides in test calls

TEST SIDE

NORMAL SIDE

Action

Not exist

Not exist

Alarm

Not exist

Exist

Use normal side

Exist

Not exist

Use test side

Exist

Exist

Use test side

For more information on analyses, attributes, and basic concepts, see Basic Routing Functions , Functional description.

Creation order of analysis components

Before the operator creates a subanalysis, the results of it have to be created the same way as in the case of the extended preanalysis and the attribute analysis. For more information, see the feature descriptions of

Feature 929: Extended Prenanalysis and Feature 597: Routing Based on Origin Attributes.

There are three types of results:

result

A result of a subanalysis is used when a call-related

default result

value of an attribute is equal to the value of the attribute in the analysis defined by the operator. A default result of the subanalysis is used in the following cases:

.

.

a call-related value of an attribute does not match any given value

the particular parameter does not exist and no unknown result is defined

24 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis unknown result An unknown result is used when a call-related value of an

unknown result

An unknown result is used when a call-related value of an attribute does not exist. For example, if the attribute is valid only when the patricular call is a mobile-originated or PBX-originated call. In the case of a trunk-originated call, the value is not determined. That is why the unknown result gives instructions on how to continue if the attribute value does not exist.

A subanalysis must have both a result and a default result, which are defined by their names. The operator can also create an unknown result for a subanalysis, however, this is not mandatory. If no unknown result is defined by the operator, the default result is used as the unknown result. After creating the results, the operator can create the subanalysis.

The creation, modification, and deletion principles for the user plane analysis are similar to the rules which apply for the extended preanalysis. For more information, see the command descriptions of Extended

Preanalysis Handling, CW command group and User Plane Analysis Handling, JU command group.

After creating the subanalysis, only the test side of the subanalysis exists until the operator changes the state of the subanalysis. The creation and the modification concern only the test side. A prerequisite for the modification of the subanalysis is the existence of the test side.

For more information on how to create or modify subanalyses and final results, see Section Configuring user plane analysis in User Plane

Routing, Operating instructions .

Testing and state changes

The operator can test the functionality of the user plane analysis with the help of test traffic. If the analysis functions as desired, the operator can change the side of the subanalysis. This means that subanalysis data is moved from test side to normal side, that is, only the normal side of the subanalysis exists afterwards. The test side of the subanalysis is deleted because the test traffic uses the normal side of the subanalysis if no test side exists.

For instructions and a description on the use of test calls, see Test Call

Handling, YC command group and Feature 215: Test Call and Digit Analysis Test State, Feature description.

DN01163601

# Nokia Siemens Networks

25 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Changing the state of the subanalysis from normal side to test side does

Changing the state of the subanalysis from normal side to test side does not transfer the data on the normal side to the test side: it only makes a copy of it. This way the normal traffic still uses the normal side of the subanalysis and the operator can modify the test side of the subanalysis with MML commands. The modifications can be tested safely in a live

network with the help of Feature 215: Test Call and Digit Analysis Test State.

4.2 User plane analysis phases

The user plane analysis is divided into different analysis phases. From an analysis configuration point of view, each phase is composed of an individual analysis chain with the attached final results. That is, each phase consists of a chain of subanalyses that lead to the final results. Both the subanalyses and the final results are specific to a certain analysis phase. The result of each analysis phase is the control information for user plane routing.

The different phases of the user plane analysis are related to each other. The result of an analysis phase can be an input parameter for another phase. User plane analysis phases and their maximal interrelation are presented in the following figure.

1. Preceding UPD determination 2. Succeeding BNC characteristics determination 3. CMN determination 5. Succeeding
1. Preceding UPD
determination
2. Succeeding BNC
characteristics
determination
3. CMN determination
5. Succeeding action
indicator determination
6. Inter-connecting
4. Succeeding UPD
determination
BNC characteristics
determination

Figure 14. The relationship of different user plane analysis phases

26 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis The numbers in the figure above represent the order in which the user

The numbers in the figure above represent the order in which the user plane analysis phases are executed. Not all the user plane analysis phases are needed in all the call cases; different control information is needed or can be available in different call cases, and thus also the executed user plane analysis phases depend on the call case.

The following table explains which analyses are executed in the various basic call cases.

Table 4.

Basic call cases

   

Outgoing

UE

MS

TRUNK

BICC

SIP

 

UE

6*

6*

6*

2,4,5,6*

2,4,6*

MS

6*

6*

6*

2,4,5,6*

2,4,6*

Incoming

TRUNK

6*

6*

6*

2,4,5,6*

2,4,6*

BICC

1,6*

1,6*

1,6*

1,2,3,4,5,6*

1,2,4,6*

SIP

1,6*

1,6*

1,6*

1,2,4,5,6*

1,2,3,4,6*

.

.

.

.

.

.

1 Preceding UPD determination (incoming side)

2 Succeeding BNC characteristics determination (outgoing side)

3 CMN determination (general)

4 Succeeding UPD determination (outgoing side)

5 Succeeding Action Indicator determination (outgoing side)

6 Interconnecting BNC characteristics determination (general)

Interconnecting BNC characteristics determination (general) Note The analyses which are marked with '*' in the

Note

The analyses which are marked with '*' in the table above are executed only in certain cases. Currently, only phase 6 is marked like that, and it is executed only if more than one MGWs are involved in the call in the same MSS area. Other analysis phases are always executed in such call cases.

All the analyses are marked as incoming, outgoing, or general. This means that the analyses are relevant only at the specified side, or irrelevant at a certain side if they are marked as general.

DN01163601

# Nokia Siemens Networks

27 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing There are a few special cases when analyses are executed also after basic

There are a few special cases when analyses are executed also after basic call setup procedures:

.

When call forwarding takes place, all the outgoing side analyses are executed again which are relevant to the signalling type on which the new leg is established. Also phase 6 can be executed again depending on the number of MGWs.

An addition to this rule is when the incoming side is BICC/SIP and the same signalling type is used in establishing the forwarded leg. Phase 3 (CMN determination) is also executed again.

.

For example, if there is a UE-MS call where the MS does not reply and the call is forwarded to the BICC core network, the analyses phases 2, 4, 5, and 6* are executed.

In inter-MSS handover both the incoming and the outgoing side subscribers can handover to different MSS areas. However, independent of the initiating side, in such cases, the succeeding determinations, phases 2, 4, and 5 for BICC and phases 2 and 4 for SIP, are always executed. Phase 1, on the other hand, is never executed. This means that when establishing a new core network connection, outgoing analyses are executed. As a difference to call forwarding, phase 3 is never executed in inter-MSS handover cases. However, phase 6* can still be executed if there is a new MGW for the handover leg establishment.

For example, in a UE-MS call, the UE (incoming subscriber) makes a handover to a different MSS area. The used signalling between the MSSs is BICC. Only outgoing side analyses are executed, that is, phases 2, 4, and 5. If there is a need for an additional MGW with interconnection, phase 6* is also executed.

The following overview to the different user plane analysis phases shows the available attributes and results. The attributes that are obligatory for a successful analysis in the specific phase are marked with (*).

Phase 1: 'Preceding UPD determination'

This phase is executed only if the incoming signalling is BICC or SIP. In UE-originating calls the UPD is defined in the radio network configuration data. In any other call cases this phase has no significance because no incoming UPD exists. For example, in the case of TDM resources the circuit also identifies the MGW and UPD is not needed.

 

The available attributes in this phase are the following:

28 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis . . . . . . . . Emergency call indicator Original dialling

.

.

.

.

.

.

.

.

Emergency call indicator

Original dialling class

Preceding action indicator

Preceding BCU-ID

Preceding BNC characteristics

Preceding signalling type

Preceding UPDR (*)

User plane bearer requirement

The result of this phase is the following:

. Preceding User Plane Destination, UPD

Phase 2: 'Succeeding BNC characteristics determination'

This phase is needed to figure out the bearer technology used towards the succeeding MGW. This phase is executed only if the outgoing signalling is BICC or SIP. In any other call cases this phase has no significance; in these cases there is only one available bearer technology that is dictated by the interface. For example, in UE terminating cases only ATM AAL2 can be used on the Iu-CS interface.

The available attributes in this phase are the following:

.

.

.

.

.

.

.

.

.

.

.

.

Emergency call indicator

Inter-MSS handover indicator

Original dialling class

Preceding action indicator

Preceding BCU-ID

Preceding BNC characteristics

Preceding signalling type

Preceding UPDR

Preceding user plane destination, UPD (from phase 1 if it exists)

Succeeding signalling type

Succeeding UPDR

User plane bearer requirement

DN01163601

# Nokia Siemens Networks

29 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The result of this phase is the following: . Succeeding BNC characteristics Phase

The result of this phase is the following:

. Succeeding BNC characteristics

Phase 3: 'CMN determination'

This phase is used to detect whether an MSS should act as a CMN node. This phase is executed only if the incoming and outgoing signalling are the same, either BICC or SIP, and no resource has been reserved from the MGW yet. CMN mode operation is possible only in these cases.

The available attributes in this phase are the following:

.

.

.

.

.

.

.

.

OLCM usage indicator

Original dialling class

Preceding BNC characteristics

Preceding signalling type

Preceding UPDR (*)

Succeeding BNC characteristics (from phase 2)

Succeeding signalling type

Succeeding UPDR (*)

The result of this phase is the following:

. CMN indicator

Phase 4: 'Succeeding UPD determination'

This phase is executed only if the outgoing signalling is BICC or SIP. In UE-terminating calls the UPD is defined in the radio network configuration data. In any other call cases this phase has no significance because in those cases no outgoing UPD exists.

The available attributes in this phase are the following:

.

.

.

.

.

Emergency call indicator

Original dialling class

Preceding action indicator

Preceding BCU-ID

Preceding UPDR

30 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis . . . . . Succeeding BCU-ID This parameter is valid only in

.

.

.

.

.

Succeeding BCU-ID

This parameter is valid only in the case of delayed MGW selection. It can be received from the succeeding MSS in APM.

Succeeding BNC characteristics (from phase 2)

Succeeding signalling type

Succeeding UPDR (*)

User plane bearer requirement

The result of this phase is the following:

. Succeeding user plane destination, UPD

Phase 5: 'Succeeding action indicator determination'

This phase is executed only if the outgoing signalling is BICC. The action indicator is specific to BICC call control signalling. It controls the used BICC bearer establishment method.

The available attributes in this phase are the following:

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Emergency call indicator

Inter-MSS handover indicator

Original dialling class

Preceding action indicator

Preceding BCU-ID

Preceding BNC characteristics

Preceding signalling type

Preceding UPDR

Preceding user plane destination, UPD (from phase 1 if it exists)

Succeeding BNC characteristics (from phase 2)

Succeeding signalling type

Succeeding UPDR

Succeeding user plane destination, UPD (from phase 4)

User plane bearer requirement

DN01163601

# Nokia Siemens Networks

31 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The result of this phase is the following: . Succeeding action indicator Phase

The result of this phase is the following:

. Succeeding action indicator

Phase 6: 'Interconnecting BNC characteristics determination'

This phase is executed when there are two MGWs involved in a call in one MSS area and an interconnection is needed between the two MGWs. If the IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter is active and the two selected MGWs are in the same physical MGW, the 'Interconnecting BNC characteristics determination' phase is skipped.

The available attributes in this phase are the following:

.

.

.

.

.

.

.

.

.

.

.

.

.

Emergency call indicator

Original dialling class

Preceding action indicator

Preceding BNC characteristics

Preceding signalling type

Preceding UPDR

Preceding user plane destination, UPD (from phase 1 if it exists)

Succeeding action indicator (from phase 5 if it exists)

Succeeding BNC characteristics (from phase 2 if it exists)

Succeeding signalling type

Succeeding UPDR

Succeeding user plane destination, UPD (from phase 4 if it exists)

User plane bearer requirement

The result of this phase is the following:

. Interconnecting BNC characteristics

For more information, see Section Configuring user plane analysis in User

Plane Routing, Operating instructions .

32 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis 4.3 User plane analysis attributes This section lists the analysis attributes involved in

4.3 User plane analysis attributes

This section lists the analysis attributes involved in user plane routing. The names of the attributes used in MMLs are also listed in the following table.

Table 5.

User plane analysis attributes

Attribute

Description: indication of

Emergency call indicator (EMCI)

Emergency call

Inter MSS handover indicator (IMSSHI)

Call leg is established for an inter-MSS handover

OLCM usage indicator 1 (OLCMI)

Subscriber monitored

Original Dialling Class (ODC)

Original dialling class defined in control plane analyses based on call- and subscriber-related data.

Preceding action

indicator (PAI)

Bearer establishment method used at incoming side

Preceding BNC characteristics (PBNC)

Type of bearer at the incoming side

Use: determination of

Preceding UPD

Succeeding BNC characteristics

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Succeeding BNC characteristics

Succeeding action indicator

Call mediation node

Preceding UPD

Succeeding BNC characteristics

Call mediation node

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Preceding UPD

Succeeding BNC characteristics

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Preceding UPD

Call mediation node

Succeeding action indicator

Succeeding BNC characteristics

Interconnecting BNC characteristics

DN01163601

# Nokia Siemens Networks

33 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Table 5. User plane analysis attributes (cont.) Attribute Description: indication of Preceding

Table 5.

User plane analysis attributes (cont.)

Attribute

Description: indication of

Preceding BCU-ID

(PBCU)

MGW used in the preceding node 2

Preceding signalling type (PSIGT)

Type of call control signalling at incoming side

Preceding UPD (PUPD) UPD identifier of incoming side

Preceding UPDR 3 (PUPDR)

Preceding user plane destinaton reference from control plane (defined in Incoming circuit group data)

Succeeding action

indicator (SAI)

Bearer establishment method at the outgoing side

Succeeding BNC characteristics (SBNC)

Type of bearer used at outgoing side

Succeeding BCU-ID 2 (SBCU)

MGW used in succeeding node

Succeeding signalling type (SSIGT)

Type of call control signalling at outgoing side

Use: determination of

Preceding UPD

Succeeding BNC characteristics

Succeeding UPD

Succeeding action indicator

Preceding UPD

Succeeding BNC characteristics

Call mediation node

Succeeding action indicator

Interconnecting BNC characteristics

Succeeding BNC characteristics

Succeeding action indicator

Interconnecting BNC characteristics

Call mediation node

Interconnecting BNC characteristics

Preceding UPD

Succeeding action indicator

Succeeding BNC characteristics

Succeeding UPD

Interconnecting BNC characteristics

Call mediation node

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Succeeding UPD

Succeeding BNC characteristics

Call mediation node

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Succeeding UPD (SUPD) UPD identifier of the outgoing Succeeding action indicator side

Interconnecting BNC characteristics

34 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis Table 5. User plane analysis attributes (cont.) Attribute Succeeding UPDR 3 (SUPDR) Description:

Table 5.

User plane analysis attributes (cont.)

Attribute

Succeeding UPDR 3 (SUPDR)

Description: indication of

Succeeding user plane destinaton reference from control plane (defined in outgoing route data)

User Plane Bearer

Requirement (UPBREQ) 4 for the call

Required transfer capability

Use: determination of

Succeeding BNC characteristics

Call mediation node

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

Preceding UPD

Succeeding BNC characteristics

Succeeding UPD

Succeeding action indicator

Interconnecting BNC characteristics

1

2

3

4

Table 6.

Whenever the CMN mode is used in a switch, the OLCM indicator parameter must be used in the user plane analysis configuration to force the MSS to act in a TSN node for subscribers to be monitored. When the MSS is configured in plain CMN mode without any user plane resources (MGWs), this parameter is not relevant. In this case online call monitoring is not possible.

The BCU ID is a parameter used by BICC signalling. Only the local part of the BCU ID is supported. The BCU ID can be defined, but is not mandatory, on an MGW basis in the Nokia MSC Server.

The UPDR is a parameter which ties the control plane direction component to the user plane analysis. It is mandatory to configure the UPDR parameter for both the incoming circuit group and the outgoing route data when the control plane signalling is BICC or SIP.

The UPBREQ parameter makes it possible to define which type of bearer connection is to be used for data calls. See also the table below.

Call control logic of forming UPBREQ values

TMR

UDI

BASIC SERVICE CODE

Any

UPBREQ

UDI

DN01163601

# Nokia Siemens Networks

35 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Table 6. Call control logic of forming UPBREQ values (cont.) TMR BASIC SERVICE

Table 6.

Call control logic of forming UPBREQ values (cont.)

TMR

BASIC SERVICE CODE

UPBREQ

RDI

Any

RDI

3.1

Any other than T61 or T62

Audio

3.1

T61 or T62

Facsimile group 3

Speech

Speech or alternative line service

Speech

Speech

Any other than speech or alternative line service

Audio

Not UDI, RDI, 3.1, or speech

Speech or alternative line service

Speech

Not UDI, RDI, 3.1, or speech

T61 or T62

Facsimile group 3

Not UDI, RDI, 3.1, or speech

Any bearer service

Audio

Not UDI, RDI, 3.1, or speech

Non-existing

Speech

In mobile-originated data calls, the call type information is received in the call setup message from the MS/UE.

In mobile-terminated data calls, there are three different scenarios:

.

.

.

Data call from ISDN:

The correct basic service is defined on the basis of the ISDN BC.

Data call from analog PSTN, multi-numbering:

The transmission medium requirement is set according to the called

party's basic service, which is received from the HLR. This requires

a multi-numbering scheme, that is, the mobile subscriber must have

a separate MSISDN for data calls.

Data call from a network which does not send BCIE, single

numbering:

In this case, the MS must have a pre-selected call type before it can receive data calls. The MS indicates the selected call type back towards the MSS in the signalling message. The transmission medium requirement is not set according to the data call when user plane analysis is carried out in the GCS because data call indication comes too late from a user plane routing point of view.

36 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis For more information, see Configuring user plane analysis in User Plane Routing, Operating

For more information, see Configuring user plane analysis in User Plane

Routing, Operating instructions .

4.4 User plane analysis results

The result of the user plane analysis can be one of the following:

Table 7.

Possible results of the user plane analysis

Analysis

Call mediation node

Interconnecting backbone network connection characteristics

Preceding user plane destination

Succeeding action indicator

Succeeding backbone network connection characteristics

Succeeding user plane destination

Results

Indicates whether the MSC Server must act as a TSN or as a CMN node.

Indicates what type of bearer is used between two MGWs controlled by one MSC Server.

Identifies the user plane destination for the incoming side.

Indicates what bearer establishment method is used at the outgoing side.

Indicates what type of bearer is used at the outgoing side.

Identifies the user plane destination for the outgoing side.

The following figure describes the relationship between the analysis results:

DN01163601

# Nokia Siemens Networks

37 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing CMN indicator MSC Server H.248 Control MSC Server H.248 Control MGW MGW MGW

CMN indicator

MSC Server H.248 Control
MSC Server
H.248 Control
MSC Server H.248 Control
MSC Server
H.248 Control
MGW MGW MGW MGW MGW MGW MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW

Inter-Connecting

BNC Characteristics

Preceding UPD

Succeeding UPD

Succeeding BNC

Characteristics MGW
Characteristics
MGW

Succeeding Action

Indicator

Figure 15. User plane analysis results

Fore more information, see Section Configuring user plane analysis in

User Plane Routing, Operating instructions .

4.5 User plane analysis execution

The user plane analysis is executed according to predefined rules and forms a chain of subanalyses.

1. User plane control collects the values of all call-related parameters which are possible attributes in the user plane analysis.

2. The execution of the user plane analysis always starts from a starting subanalysis, that is, from the source file.

3. User plane control reads the attribute of the starting subanalysis and the record number of the attribute values file, indicating where the analysis of the attribute values, defined by the operator, starts.

of the attribute values, defined by the operator, starts. Note There can be different pointers to

Note

There can be different pointers to the attribute values file, that is, to the default result, and to the unknown result for normal and test traffic.

38 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane analysis

User plane analysis 4. Test traffic-related data is in use only for test calls. Test traffic

4.

Test traffic-related data is in use only for test calls. Test traffic uses the normal side data of the subanalysis if no separate test side data

is available. Normal traffic never uses the test side data of the

subanalysis.

If no call case-related value of an attribute exists, there is nothing to be analysed, thus continuation instructions are read immediately from the unknown result field of the subanalysis in the source file.

A call-related value of an attribute is analysed against the values

defined for the subanalysis by the operator. If they are the same, that is, the call-related value of an attribute equals to the value defined in the analysis, user plane control reads the continuation instructions, an indicator towards the next subanalysis or towards the final result, from the attribute values file. In this case, the analysis may either continue from some other subanalysis in the source file or lead to a final result in the result file.

If no match is found, that is, the call-related value of the attribute

differs from those found in the analysis, user plane control reads the continuation instructions from the default result of the subanalysis in the source file.

the default result of the subanalysis in the source file. Note Although in a subanalysis several

Note

Although in a subanalysis several values can be defined for one attribute and all of them can have different results, that is, different continuation instructions, there is only a single default result and a single unknown result in each subanalysis. The default result cannot be the same as any of the results of the attribute values.

5. When the analysis continues from the next subanalysis, user plane control reads the data of the subanalysis from the record of the source file. An indicator is received from the attribute values file showing from where the subanalysis data must be read. The analysis continues in the same way as in the case of the starting subanalysis. If a value of an attribute matches a predefined value of the subanalysis, the result of the subanalysis is either the next subanalysis or the final result.

If the result of the next subanalysis and the final result do no match, the result of the subanalysis is the default result, that is, an indicator either to another subanalysis or to the final result.

6. The analysis continues until a final result is reached. User plane control reads the result information and does the required action when ordered by the analysis.

DN01163601

# Nokia Siemens Networks

39 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 40 (96) # Nokia Siemens Networks DN01163601   Issue 3-0 en

40 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database 5 User plane topology database The user plane topology database is a

5 User plane topology database

The 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 MSS H.248 AAL2 AAL2 MGW MGW AAL2 MGW Interconnection UPD
.
data records for interconnections
MSS
H.248
AAL2
AAL2
MGW
MGW
AAL2
MGW
Interconnection
UPD
UPD

Figure 16. User plane topology information

The operator enters the actual network configuration to the database using

MML commands. Furthermore, a database manager acts as an interface

towards the user plane control application for database inquiries.

For more information, see the command descriptions of User Plane

 

Destination Management, JF command group.

DN01163601

# Nokia Siemens Networks

41 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 5.1 User plane destination The UPD defines connections to (incoming side) and from

5.1 User plane destination

The UPD defines connections to (incoming side) and from (outgoing side) the MGWs controlled by an MSS. UPDs are created by the operator during network configuration. Physically, a UPD is a record in the topology database. The number of UPDs stored in the database is limited to 1000.

From the point of view of an MSS, 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 criteria are BNC characteristics and IP trunk capability. UPDs can be overlapping. This means that different UPDs, where the grouping principle is different, can contain the same MGWs.

Grouping can be different not only based on BNC characteristics, but also based on the IP trunk capability indicator. If this parameter is set, and the following conditions are fulfilled, call setup procedures are executed differently, which means that no Nb UP protocol is used and the packetisation period for Nokia MGWs is 20 ms:

.

.

.

signalling protocol is BICC, SIP-T, SIP-I, or 3GPP SIP

bearer type is IP

used speech codec is G.711 or the call is a data call

In other cases, the Nb UP framing protocol is used on the Nb interface and the packetisation period for G.711 codec is 5 ms.

and the packetisation period for G.711 codec is 5 ms. Note The Nokia proprietary Nb' UP

Note

The Nokia proprietary Nb' UP protocol is also supported for the interconnecting IP bearer between two MGWs that are controlled by the same MSS. The functionality can be activated with the NO_NBUP_ON_MGW_IC_LEG MSS-specific PRFILE parameter.

The Speech transmission optimisation method parameter is used in the case of speech calls to peer core network elements. The parameter has the following values:

. Codec negotiation

If this value is used, the MSS tries to perform codec negotiation in the specified direction.

42 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database . Default codec If this value is used, the MSS uses the

. Default codec

If this value is used, the MSS uses the UPD default codec parameter.

For more information, see Feature 1335: Speech Transmission Optimisation in MSC Server, Feature description and Speech Codecs in MSC Server,Functional description.

Example Defining UPD1

UPD1 is defined with MGW1, MGW3, and MGW17. The bearer network connection type (BNC characteristics) is set to ATM AAL2. This means that when the call is routed through this UPD, only the above listed MGWs can be used in the given direction and the connection type is ATM AAL2. The Speech transmission optimisation method parameter is set to the value 'codec negotiation'.

Example Defining UPD2

UPD2 is defined with MGW1 and MGW21. MGW1 is also included in UPD1. The bearer network connection type (BNC characteristics) is set to IPv4 in this case, so both selectable MGWs establish IPv4 connections towards the destination. The Speech transmission optimisation method parameter is set to the value 'codec negotiation'.

Example Defining UPD3

UPD3 is defined with the same MGWs as UPD2 but, in this case, the bearer network connection type (BNC characteristics) is set to IPv6. The trunk capability parameter is also set, which means that in call cases where BICC, SIP-T, or SIP-I control plane signalling is used, the bearer type is IP, and the used codec is G.711 no Nb UP framing protocol is used, and the packetisation period is 20 ms. The Speech transmission optimisation method parameter is set to the value 'default codec'.

The figure below shows an example of UPDs connected to neighbour MSSs. It is possible that several UPDs are used towards the same destination.

DN01163601

# Nokia Siemens Networks

43 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing MSS1 MSS2 MSS3 UPD3 UPD2 IPv6 IPv4 MGW-21 Trunk_cap=ON Trunk_cap=OFF STOM=DC STOM=CN MGW-1

MSS1

MSS2

MSS3

UPD3 UPD2 IPv6 IPv4 MGW-21 Trunk_cap=ON Trunk_cap=OFF STOM=DC STOM=CN MGW-1 AAL2 MGW-3 Trunk_cap=OFF STOM=CN
UPD3
UPD2
IPv6
IPv4
MGW-21
Trunk_cap=ON
Trunk_cap=OFF
STOM=DC
STOM=CN
MGW-1
AAL2
MGW-3
Trunk_cap=OFF
STOM=CN
MGW-17
UPD1

Figure 17. User plane destinations

Structure of user plane destinations

A UPD consists of parameters specific to the user plane destination itself.

In addition, part of the parameters are MGW-specific.

.

.

Accepting overload traffic redirection (RACC) (MGW- specific)

With this parameter, the operator can specify whether an MGW can accept redirected traffic in overload situations.

Audio call handling method <option>

It enables the usage of compressed speech codecs on the Nb/Mb interface if the received ITC is 3.1kHz (in Nc orginated case) or Speech (in Mg/Mj originated case) and no ISDN BC/LLC/HLC are available. The possible values are the following:

0

Calls are handled as data call

44 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database . . . Calls are handled as speech calls, ITC 3.1kHz is

.

.

.

Calls are handled as speech calls, ITC 3.1kHz is sent

2 Calls are handled as speech calls, ITC speech is sent The default value is 0.

Backbone network connection characteristics

1

With this parameter, the operator can define the Backbone Network Connection (BNC) characteristics of the UPD.

It indicates what type of bearer is used in the UPD (AAL2, IP, IPv4, or

IPv6).

Codec Modification Support <option>

With this parameter, the operator can set if codec modification can be started or accepted to/from the specified direction.

Default codec

It indicates the default codec used in the UPD if a more optimal codec cannot be negotiated. The possible values are the following:

.

.

.

.

G.711

GSM EFR

GSM FR

UMTS AMR 2

are the following: . . . . G.711 GSM EFR GSM FR UMTS AMR 2 Note

Note

In inter-MSS call cases between two MSS domains, the default UPD codec has an effect only on the Nb interface codec. The default codec used on the interconnecting leg between two MGWs controlled by the same MSS can be set with the DEFAULT_IC_LEG_CODEC PRFILE parameter. The possible values of this parameter are the following:

.

.

.

.

G.711

GSM EFR

GSM FR

UMTS AMR 2

The DEFAULT_AMR_CODEC_MODE PRFILE parameter defines the mode to be used with the AMR codec in the following cases:

The default codec in the UPD is UMTS AMR 2.

.

.

The interconnecting leg codec is specified as UMTS AMR 2 with the DEFAULT_IC_LEG_CODEC parameter.

DN01163601

# Nokia Siemens Networks

45 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The value of this parameter is only relevant in speech calls and in

The value of this parameter is only relevant in speech calls and in the UPDs that are defined towards the peer core network elements, not in the UE codec selection in the UPDs that are defined towards the RNCs.

.

Incoming bearer redirection allowance <option>

With this parameter, the operator can set if the incoming bearer redirection is allowed or not in the UPD.

.

.

.

.

.

.

.

.

IPNWR

The operator can define the IP Network Reference Identifier ( IPNWR ) to be used in UPD.

IPNWR is used only if the MGW supports the nokiaipnwr H.248 package. The parameter is valid only if the BNCC parameter is IPV4, IPV6, or IP.

Load sharing index (MGW-specific)

Weight value for user plane traffic sharing between MGWs in a UPD.

MGW identifiers list (MGW-specific)

It identifies the MGWs belonging to the UPD.

MGW name (MGW-specific)

With this parameter, the operator can give the name of the MGW which the operator wants to add to the specified UPD.

MGW re-selection provisioning status

It indicates the provisioning status of the MGW reselection procedure.

For more information, see Section User plane control level MGW re- selection .

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

Originating overload traffic redirection (RORIG) (MGW-specific)

With this parameter, the operator can specify whether overload traffic can be redirected from a congested MGW to other MGWs in congestion situations.

Outgoing bearer redirection capability <option>

With this parameter, the operator can set the outgoing bearer redirection capability of the UPD.

STOM <option>

46 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database . . . With this parameter, the operator can set the Speech

.

.

.

With this parameter, the operator can set the Speech Transmission Optimisation Method (STOM) of the UPD.

Trunk capability <option>

With this parameter, the operator can set the ATM/IP trunk capability of the UPD. It indicates if the Nokia proprietary Nb' UP protocol can be used.

User plane destination index

Numerical identifier of the user plane destination.

User plane destination name

Alphabetical identifier of the user plane destination.

For more information on codecs and on the Speech transmission optimisation method and Trunk capability parameters, see

Speech Codecs in MSC Server, Functional description and Feature 1335:

Speech Transmission Optimisation in MSC Server, Feature description .

For more information on the traffic redirection functionality, see Section Congestion handling.

See also Section Configuring user plane topology database in User Plane

Routing, Operating instructions .

When fax or modem signal is detected the MSS system performs the codec modification (from compressed codec to G.711 or clearmode codec) in order to enable the fax and modem data call.

For more information on UPD-specific parameters, see User Plane

Topology Data Handling, JF command group.

Codec preference list

When creating user plane destination, it is possible to set up UPD codec preference list.

If UPD codec preference list contains at least one codec it will be used in the following cases:

.

.

UE originating call: UE supported codecs will be ordered according to the incoming UPD codec preference list.

UE terminating call: UE supported codecs will be ordered according to the outgoing UPD codec preference list.

DN01163601

# Nokia Siemens Networks

47 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing . . . Creating supported codecs list (codec negotiation is initiated in the

.

.

.

Creating supported codecs list (codec negotiation is initiated in the MSS): Priority order of the supported codecs list will be determined according to the outgoing UPD codec preference list

Transit cases: Incoming supported codecs list shall be restricted according to the codecs in the incoming and outgoing UPD codec preference list. Only the codec support is checked, priority order does not matter.

Network side codec selection (codec negotiation is terminating in the MSS). Only the codec support is checked in the incoming UPD codec preference list, priority order does not matter.

The operator can create codec preference list with the JFF command.

For more information, see User Plane Topology Data Handling, JF Command Group.

5.2 User plane topology between MGWs

The interconnection data in the topology database enables configurations where the user plane is routed through two MGWs controlled by an MSC server. The interconnection data defines user plane connectivity between MGWs.

Control Plane MSC Server H.248 Control User Plane MGW MGW MGW MGW MGW MGW MGW
Control Plane
MSC Server
H.248 Control
User Plane
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW

Figure 18. User plane routed through two MGWs

48 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database Structure of interconnection data Interconnection data is organised on an MGW basis.

Structure of interconnection data

Interconnection data is organised on an 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 the following:

.

.

.

MGW identifier

It 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

It indicates a fully-meshed configuration. The full-meshed indication is MGW-specific and it means that the MGW has a connection to all other MGWs within the same MSS area with the given BNC characteristics. The possible interconnecting BNC characteristics in the full-meshed configuration are ATM AAL2, IPv4, and IPv6. 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 to those MGWs by defining the available BNC characteristics. The possible interconnecting BNC characteristics are ATM AAL2, IPv4, IPv6, and TDM. An interconnection can support one or more BNC characteristics simultaneously. In the case of TDM interconnections, the interconnection data also identifies up to three interconnecting TDM routes between the MGWs.

up to three interconnecting TDM routes between the MGWs. Note Regardless of whether the interconnected MGWs

Note

Regardless of whether the interconnected MGWs are physical or virtual MGWs, the operator always have to define interconnections between them if calls should be routed through the two MGWs.

. Load sharing weight

DN01163601

# Nokia Siemens Networks

49 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The operator can add the Load sharing weight if the Interconnecting BNC characteristics

The operator can add the Load sharing weight if the Interconnecting BNC characteristics load sharing functionality is enabled.

When a new MGW interconnection is created, the operator can add the load sharing weight value with the JFT MML command. It is possible to weight the distribution of calls among different transport technologies (IPv4, IPv6, AAL2, TDM).

The ICBNCC_EXCLUSION_TIMER PRFILE parameter controls the Interconnecting Backbone Network Connection (ICBNC) characteristics exclusion timer functionality. The parameter controls the timer which can automatically reset the ICBNC characteristics out of service flag for the faulty ICBNC characteristics if the ICBNCC_EXCLUSION PRFILE parameter is activated.

The ICBNCC_EXCLUSION PRFILE parameter activates the ICBNC characteristics exclusion functionality. If the parameter is active, the operator can mark that the configured ICBNC characteristics cannot be used as active ICBNC characteristics if the bearer connection cannot be established. In this case, other ICBNC characteristics are selected for the call instead of the earlier configured characteristics.

If an Nb UP initialisation failure happens several times, the ICBNCC fault counter contains the number of continuously indicated 'ICBNCC not in use' status. If the maximum allowed ICBNC characteristics exclusion attempt value is reached, the problem is indicated as a permanent failure. The ICBNCC_EXCLUSION_ATTEMP PRFILE parameter controls the two-level out of service flag behaviour of the ICBNC characteristics exclusion functionality.

.

ICBNC not in service flag

The operator can modify the Interconnecting BNC characteristics not in service flag if the Interconnecting BNC characteristics load sharing functionality is enabled and the Interconnecting BNC characteristics exclusion functionality is activated.

The flag shows if the actual interconnecting BNC characteristics is working properly or it is marked as 'not in service' by the Interconnecting BNC characteristics exclusion functionality. When an interconnecting BNC characteristics is marked as 'not in service', the MSS excludes it from the list of available connections. If the root cause of the fault is corrected, the interconnecting BNC characteristics can be marked as available with the JFS MML.

.

IPNWR for IP ICBNC

All IP interconnections between the MGW under the same MSS are considered to use the same IPNWR. The operator can set IPNWR for IP ICBNCs with MML command.

50 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

User plane topology database

User plane topology database For more information on creating interconnections, see User Plane Topology Data Handling,

For more information on creating interconnections, see User Plane

Topology Data Handling, JF command group.

See also Section Configuring MGW database in user plane routing in User

Plane Routing, Operating instructions .

DN01163601

# Nokia Siemens Networks

51 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 52 (96) # Nokia Siemens Networks DN01163601   Issue 3-0 en

52 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Relationship between user plane and control plane routing

Relationship between user plane and control plane routing 6 Relationship between user plane and control plane

6 Relationship between user plane and control plane routing

Despite being separate entities, the user plane and the control plane are linked in an indirect and flexible way through the Local Bearer Control Unit (LBCU), Original Dialling Class (ODC), User Plane Destination (UPD), and User Plane Destination Reference (UDPR) parameters.

RANAP signalling

The UPDs towards the radio access network are configured directly in the radio network configuration data. Therefore, in UE-originating or - terminating calls, neither the preceding nor the succeeding UPD determination phase is needed for the UE side of the call. For more information, see Cellular radio network management , Operating

instructions, Feature 1325: RANAP and BSSAP in MSC Server, Feature description, and Radio Network Controller Parameter Handling in MSS, E2 command group.

BICC and SIP signalling

The UPDR parameter is used as a link between the control plane and the user plane. In the case of incoming calls, you can configure the UPDR parameter for the circuit group data. In the case of outgoing calls, you can configure the UPDR parameter for the route data. On a call basis, the value of the UPDR is delivered to the 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. BICC and SIP signalling behave similarly in this respect.

DN01163601

# Nokia Siemens Networks

53 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Control Plane ROUTE data UPDR=5 MSC Server many other UPDR UPD 2 attributes
Control Plane ROUTE data UPDR=5 MSC Server many other UPDR UPD 2 attributes User Plane
Control Plane
ROUTE data
UPDR=5
MSC Server
many other
UPDR
UPD 2
attributes
User Plane
user plane
MGW
MGW
analysis
MGW
MGW
MGW
MGW
UPD=2
MGW
MGW
MGW
MGW

Figure 19. UPDR parameter on the outgoing side

In the figure above, UPDR value 5 is read from the outgoing ROUTE data. It is used as an input attribute for the user plane analysis with many other attributes as defined in user plane analysis attributes. The analysis result UPD=2 means that two MGWs belonging to UPD2 are allowed to be used for a call.

For more information, see Section Configuring UPD and UPDR values for

signalling in User Plane Routing, Operating instructions .

TDM routing

The LBCU-ID parameter can be used as a connection between the user plane and the control plane. For outgoing calls you can configure the LBCU-ID parameter for the route data. When the MGW is selected for the incoming side and the bearer is established before the outgoing route selection, the LBCU-ID of the selected MGW is delivered to the call control application to be used as an input attribute in route selection. This way a route is seleted, and the circuits of this route are connected to the MGW in which the incoming resources have been reserved.

54 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

Relationship between user plane and control plane routing

Relationship between user plane and control plane routing Control Plane MSC Server User Plane MGW MGW
Control Plane MSC Server User Plane MGW MGW MGW MGW MGW MGW MGW MGW MGW
Control Plane
MSC Server
User Plane
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
MGW
ROUTE data LBCU-ID=5 selected route selection outgoing route incoming MGW data LBCU-ID=5
ROUTE data
LBCU-ID=5
selected
route selection
outgoing route
incoming
MGW data
LBCU-ID=5

Figure 20. LBCU-ID parameter in route selection

For more information, see Section Configuring UPD and UPDR values for

signalling in User Plane Routing, Operating instructions .

For control plane-related information, see Routing and Analyses ,

Operating instructions.

DN01163601

# Nokia Siemens Networks

55 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 56 (96) # Nokia Siemens Networks DN01163601   Issue 3-0 en

56 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection 7 MGW selection MGW selection is a functionality in the MSC Server (MSS) which

7 MGW selection

MGW selection is a functionality in the MSC Server (MSS) which is necessary for selecting an optimal MGW for user plane transmission for a call.

7.1 MGW selection basic functionality

In the case of physical TDM resources, the circuits are hunted on the control plane level in the MSS. The circuit that has been assigned to the call directly identifies 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 the 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 a selection among them.

Taking the MSS user plane routing application into consideration, the MGW selection procedure consists of the following logical subtasks:

1. Collecting control plane- and user plane -related information from the signalling and call control applications.

2. Further processing of collected data in the user plane analysis. The 'preceding UPD determination' and 'succeeding UPD determination' user plane analysis phases are executed in order to find 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 it is provided for the user plane control application. In this case, the user plane analysis phases mentioned above are not executed for the UE side of the call.

DN01163601

# Nokia Siemens Networks

57 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing 3. Collecting updates and possible changes to control plane- and user plane -related

3. Collecting updates and possible changes to control plane- and user plane -related information from the 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.

4. 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 of MGW selection is that the user plane is routed through an MGW under the scope of an MSS. This is the 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, the same MGW can be selected for the incoming and the outgoing side user plane. For more information, see Example Selecting an MGW from the same UPDs .

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 the UPDs use the same MGW. In this case the user plane routing application is able to optimise selection by finding and selecting the MGW shared by the UPDs for the call. For more information, see Examples Selecting an MGW from different UPDs sharing MGWs in UE-UE calls and and Selecting an MGW from different UPDs sharing MGWs in UE-CN calls .

Depending on the network configuration, it is possible to have two MGWs under the scope of an MSS. This scenario is similar to the previous one, except that the UPDs do not always use the same MGW. When there is no shared MGW for the UPDs, an MGW is selected from the UPD belonging to the side which receives the resource reservation request first. Then the 'Interconnecting BNC characteristics determination' user plane analysis phase is executed, and to find the possible MGW candidates for the remaining, incoming or outgoing, side, the user plane control application makes a topology database inquiry to check the connectivity of MGWs in the UPDs. MGWs without connectivity are ruled out from MGW selection. For more information, see Example Selecting an MGW from different UPDs sharing no MGWs .

 

The MGW selection method might differ depending on the configuration (PRFILE setting). If the optimisation method is activated with the IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter, an MGW is selected from the UPD belonging to the side which receives the resource reservation request first, and a list of the possible MGW candidates is created. The list contains the virtual MGWs in the opposite UPD which belong to the same physical MGW as the already selected virtual MGW. If

58 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection there is such a virtual MGW in the opposite UPD, neither the 'interconnecting BNC

there is such a virtual MGW in the opposite UPD, neither the 'interconnecting BNC characteristics determination' user plane analysis is executed nor the topology database is inquired, but the 'interconnecting BNC characteristics' is set to AAL2 automatically. For more information, see Example Selecting an MGW from different UPDs with the same physical MGW.

If it is not possible to find a virtual MGW in the opposite UPD which belongs to the same physical MGW, the 'interconnecting BNC characteristics determination' analysis is executed and the topology database is inquired as described above.

TDM usage optimisation

The IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter is also used to activate the TDM usage optimisation functionality. In the case of a TDM- terminating call when the incoming side MGW is already selected and the outgoing side MGW, where the TDM circuit is connected, belongs to a different virtual MGW, but to the same physical MGW the MSS reserves the outgoing side TDM termination in the incoming side MGW. With the TDM usage optimisation functionality, it is not necessary to make a connection between these virtual MGWs.

The same functionality applies to both PSTN and MS-terminating call cases.

applies to both PSTN and MS-terminating call cases. Note TDM circuit pools are defined for virtual

Note

TDM circuit pools are defined for virtual MGWs. TDM circuits are reserved through the H.248 interface, which is used for controlling the virtual MGW.

To avoid backbone connections between virtual MGWs within a physical MGW, the Nokia MSC server controlling the Nokia MGW can also reserve TDM circuits belonging to another virtual MGW in the same physical MGW.

DN01163601

# Nokia Siemens Networks

59 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Physical MGW M1 M2 No interconnection is needed between M1 and M2 virtual

Physical MGW

M1 M2 No interconnection is needed between M1 and M2 virtual MGWs ECCS Access/Core PSTN/BSS
M1
M2
No interconnection
is needed between
M1 and M2
virtual MGWs
ECCS
Access/Core
PSTN/BSS
Network

Figure 21. TDM usage optimisation

Weight-based MGW selection

Normally, MGW selection from a UPD is done by using the load sharing weight-based method. A relative load sharing weight is assigned to each MGW in the UPD. When the UPD contains several MGW candidates that have adequate 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 Selecting an MGW based on load sharing weights

In a UE-originating call the early RAB assingment method is used and the incoming side MGW is selected first. The incoming side UPD is 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.

UPD in M 2 M M M 1 4 5 17 20 25 M 3
UPD in
M 2
M M
M 1
4 5
17
20
25
M 3
M 5
RNC Orig.
14 40
 

Figure 22. MGW selection based on load sharing weights

60 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection The weight-based selection process consists of the following steps: 1. Calculating the sum of

The weight-based selection process consists of the following steps:

1. Calculating the sum of the load sharing weights of each MGW.

Table 8.

Collecting load sharing weights in the MGW

MGW index

Load sharing weight

1

25

2

17

3

14

4

20

5

40

SUM

25+17+14+20+40=116

2. Generating a random number.

A random number is generated and scaled to the range of 1 to the sum of the load sharing weights. In this example, the random number is in the range of 1-116.

3. Selecting an MGW in the UPD.

Each MGW is assigned a number range depending on the index of the MGW and the load sharing weight.

Table 9.

Selecting MGW from UPD

MGW index

Load sharing weight

Number range

1

25

1-25

2

17

26-42

3

14

43-56

4

20

57-76

5

40

77-116

The MGW with the range matching the scaled random number is selected. For example, if the generated random number is 88, it falls to the range 77-116, and thus MGW 5 is selected.

DN01163601

# Nokia Siemens Networks

61 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing The load sharing weight-based MGW selection method provides a flexible mechanism for weighted

The load sharing weight-based MGW selection method provides a 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 among all the MGWs depending on their relative weight. Note that the 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 also has an effect on the amount 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.

If an MGW has a load sharing weight defined as 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 a 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.

MGW selection in different call cases

In the previous example simple weight-based selection from one UPD was described. This kind of logic is used, for example, in UE-originating calls towards another MSS with early RAB assignment, when only the preceding UPD is known at the time of the MGW selection. Normally, during the call setup, there are situations when both UPDs are known and MGW selection is made. In these cases an attempt to optimise the selection is made by trying to select an MGW that belongs to both UPDs. The task is to route the call only through one MGW. When optimisation is not possible, MGWs with suitable interconnection are selected. The different scenarios are discussed in the following examples.

Example Selecting an MGW from the same UPDs

In an intra-MSS UE-UE call both the preceding and the succeeding UPDs are known when MGW selection is made. The early RAB assignment method is always used in intra-MSS call cases and the incoming side MGW is always selected first. Both the preceding and the succeeding UPDs are obtained from the radio network configuration data. In this example, the incoming and the outgoing UPDs are the same.

62 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection UPD i n = UPD o u t M 2 M M M 1

UPD in = UPD out

M 2 M M M 1 4 5 M 3 M 6
M 2
M M
M 1
4 5
M 3
M 6
UPD i n = UPD o u t M 2 M M M 1 4 5

RNC Orig.

= UPD o u t M 2 M M M 1 4 5 M 3 M

RNC Term.

Figure 23. MGW selection from the same UPDs

The incoming side MGW selection process consists of the following steps:

1. Finding MGWs that belong to both UPDs.

The two UPDs are the same; the set of shared MGWs is {M1, M2, M3, M4, M5, M6}.

2. Making weight-based selection.

Weight-based selection is made from the set of selected MGWs. Load sharing weights are taken from the preceding, incoming, UPD.

It is assumed that MGW2 is selected in this example.

When the outgoing side MGW is selected, the selection is optimised by selecting the same MGW that was selected for the incoming side.

Example

Selecting an MGW from different UPDs sharing MGWs in UE- UE calls

In an intra-MSS UE-UE call, the preceding and succeeding UPDs are different, but share some of the MGWs. The early RAB assignment method is always used in intra-MSS call cases and the incoming side MGW is always selected first.

DN01163601

# Nokia Siemens Networks

63 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing UPD in UPD out M 2 M M M M M 1 4
UPD in UPD out M 2 M M M M M 1 4 5 5
UPD in
UPD out
M
2
M
M
M
M
M
1
4
5
5
5
M
M
3
6
RNC Orig.
RNC Term.

Figure 24. MGW selection from different UPDs sharing MGWs in UE-UE calls

The incoming side MGW selection process consists of the following steps:

1. Finding MGWs that belong to both UPDs.

The preceding and succeeding UPDs are different, but they share some MGWs. The set of shared MGWs is {M2, M4, M6}.

2. Making weight-based selection.

Weight-based selection is made among the set of selected MGWs. Load sharing weights are taken from the preceding, incoming, UPD.

It is assumed that MGW2 is selected in this example.

When the outgoing side MGW is selected, selection is optimised by selecting the same MGW that was selected for the incoming side.

Example Selecting an MGW from different UPDs sharing MGWs in UE- CN calls

In a UE-originating and core-network-terminating call the preceding and succeeding UPDs are different, but they share some MGWs. The late RAB assignment method is used and the outgoing side MGW is selected first.

64 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection UPD in UPD out M 2 M M M M M 1 4 5
UPD in UPD out M 2 M M M M M 1 4 5 5
UPD in
UPD out
M 2
M M
M M
M 1
4 5
5 5
Backbone
M 3
M 6
RNC Orig.

Figure 25. MGW selection from different UPDs sharing MGWs in UE-CN calls

The outgoing side MGW selection process consists of the following steps:

1. Finding MGWs belonging to both UPDs.

The preceding and the succeeding UPDs are different, but they share some MGWs. The set of shared MGWs is {M2, M4, M6}.

2. Making weight-based selection.

Weight-based selection is made among the set of selected MGWs. Load sharing weights are taken from the succeeding, outgoing, UPD.

It is assumed that MGW2 is selected in this example.

When the incoming side MGW is selected, selection is optimised by selecting the same MGW that was selected for the outgoing side.

From the examples above it can be seen that with a certain kind of configuration the optimisation functionality can lead to a situation where not all the MGWs in UPDs are used for certain traffic cases. For instance, in example 3, MGWs 1, 3, and 5 are not used in UE-originating calls that are routed to the core network. It is important to take the optimisation functionality into account when planning the user plane-level configuration.

 

Note that the source of the load sharing weights depends on the traffic case. Depending on whether the incoming or the outgoing side MGW is being selected, load sharing weights can be taken either from the preceding or the succeeding UPD. This is another issue to consider when planning the configuration.

DN01163601

# Nokia Siemens Networks

65 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing If there are no shared MGWs in the preceding and the succeeding UPD,

If there are no shared MGWs in the preceding and the succeeding UPD, weight-based selection is made separately from both UPDs and an interconnecting bearer is established between the selected MGWs. Only those MGWs are included in the weight-based selection that have the required interconnection.

Example Selecting an MGW from different UPDs sharing no MGWs

In a UE-originating and core-network-terminating call the preceding and the succeeding UPDs are different and do not share MGWs. However, interconnections between the MGWs in the preceding and the succeeding UPDs exist. The late RAB assignment method is used and the outgoing side MGW is selected first.

UPD in UPD out M M M 1 5 5 M M 5 3 Backbone
UPD in
UPD out
M
M
M
1
5
5
M
M
5
3
Backbone
M
M
M
6
4
2
RNC Orig.

Figure 26. MGW selection from different UPDs sharing no MGWs

The MGW selection process starts from selecting the outgoing side MGW. During the selection process the need for interconnection is recognised and a preselection for the incoming side MGW is already made based on the knowledge about the required interconnection. The selection process consists of the following steps:

1. Finding MGWs belonging to both UPDs.

The preceding and the succeeding UPDs are different and do not share any MGWs. No shared MGWs are found.

2. Making weight-based selection for the outgoing side.

Since there are no shared MGWs, weight-based selection is made among the set of all the MGWs in the succeeding UPD. The set of MGWs included in the selection is {M3, M6}. Load sharing weights for the selection are taken from the succeeding, outgoing, UPD. Interconnections between the MGWs in the UPDs are not yet considered in this phase.

66 (96)

# Nokia Siemens Networks

DN01163601

 

Issue 3-0 en

MGW selection

MGW selection It is assumed that MGW3 is selected in this example. 3. Finding interconnection characteristics.

It is assumed that MGW3 is selected in this example.

3. Finding interconnection characteristics.

The need for interconnection between the MGWs in the preceding and succeeding UPD is recognised. The 'interconnecting BNC characteristics determination' user plane analysis phase is executed to find out the required BNC characteristics for the interconnection.

4. Finding interconnected MGWs.

The set of MGWs with the required type of interconnection is composed using the information stored in the topology database. The MGWs without the required type of interconnection are excluded from the set assuming that all the MGWs in the preceding UPD have the right type of interconnection. The set of the interconnected MGWs is {M1, M2, M4, M5}.

5. Making weight-based selection for the incoming side.

Weight-based selection is made among the set of interconnected MGWs in the preceding UPD. Load sharing weights are taken from the preceding, incoming, UPD.

It is assumed that MGW4 is selected in this example.

UPD. It is assumed that MGW4 is selected in this example. Note In this example, the

Note

In this example, the whole MGW selection process takes place when the outgoing side resource reservation and MGW selection are needed.

Although also the incoming side MGW is selected, this selection is only

a preselection without actual resource reservation from the incoming

side MGW. Resource reservation is made later when the incoming side bearer establishment is started. The purpose of the preselection is to check if a sufficient incoming side MGW with the required interconnection is available for the call. If some changes regarding the incoming side resources take place during the call setup, before the incoming side resource reservation is made, the incoming side MGW selection can be repeated taking the changed information into account. For example, if the preceding UPD is changed because of the signalling phase handover, MGW selection is repeated for MGWs belonging to the new UPD when an incoming side resource reservation is needed.

If the result of the user plane analysis in Step Finding interconnection

characteristics is loadshare, the next step is to make a weight-based MGW selection for the incoming side, and after that to make a weight- based bearer selection for the interconnecting bearer types configured between the selected MGWs.

DN01163601

# Nokia Siemens Networks

67 (96)

Issue 3-0 en

User Plane Routing

User Plane Routing Example Selecting an MGW from different UPDs with the same physical MGW In

Example Selecting an MGW from different UPDs with the same physical MGW

In a UE-originating and core-network-terminating call the preceding and the succeeding UPDs are different and do not share MGWs. However, there are virtual MGWs in both UPDs which belong to the same physical MGW. The IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter is set to TRUE. The late RAB assignment method is used and the outgoing side MGW is selected first.

UPD in UPD out M M 1 6 M 4 Backbone M 3 M 5
UPD in
UPD out
M
M
1
6
M
4
Backbone
M
3
M
5
M
AAL2
M
2
7
RNC
(orig)