User Plane Routing

MSCDOCM14PDFCD MSC/HLR, Rel. M14.0, Product Documentation, v.
User Plane Routing
DN01163601 Issue 3-0 en
# Nokia Siemens Networks
1 (96)
User Plane Routing
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)
DN01163601 Issue 3-0 en
Contents
Contents
Contents 3 List of tables 4 List of figures 5 Summary of changes 7 1 2 3 4 4.1 4.2 4.3 4.4 4.5 5 5.1 5.2 6 7 7.1 7.2 7.3 7.4 7.5 7.6 7.7 8 8.1 8.2 9 10 User plane routing 9 Call cases for user plane routing 11 Control plane signallings in MSC Server 19 User plane analysis 21 User plane analysis architecture 21 User plane analysis phases 26 User plane analysis attributes 33 User plane analysis results 37 User plane analysis execution 38 User plane topology database 41 User plane destination 42 User plane topology between MGWs
48
Relationship between user plane and control plane routing 53 MGW selection 57 MGW selection basic functionality 57 MGW selection optimisation based on BIWF address MGW selection optimisation based on BCU-ID 73 Tandem operation in MGW selection 75 User plane control level MGW reselection 76 MGW selection in TDM routing 79 Call Mediation Node 80 Interconnecting BNC characteristics 83 Interconnecting BNC characteristics load sharing 83 Interconnecting BNC characteristics exclusion 86 Traffic separation between the MSS and MGW 89 Alarms and cause codes issued in user plane routing 91
72
DN01163601 Issue 3-0 en
3 (96)
User Plane Routing
List of tables Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. Structure of subanalysis 23 24
Normal and test sides in normal calls Normal and test sides in test calls Basic call cases 27 33 24
User plane analysis attributes
Call control logic of forming UPBREQ values Possible results of the user plane analysis Collecting load sharing weights in the MGW Selecting MGW from UPD 77 61
35
37 61
Table 10. MGW reselection
4 (96)
DN01163601 Issue 3-0 en
List of figures
List of figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Decomposed network architecture MGW selection network architecture TDM to ATM/IP 12 9 11
ATM to ATM, call case 1 13 ATM to ATM, call case 2 ATM to ATM, call case 3 ATM to ATM, call case 4 ATM to ATM, call case 5 13 14 14 15 15 16
TDM to ATM/IP through MSS
Figure 10. TDM to TDM through ATM/IP/TDM Figure 11. CMN transit call 16 21
Figure 12. User plane analysis structure
Figure 13. A general example of a subanalysis
23 26
Figure 14. The relationship of different user plane analysis phases Figure 15. User plane analysis results 38 41
Figure 16. User plane topology information Figure 17. User plane destinations 44
Figure 18. User plane routed through two MGWs Figure 19. UPDR parameter on the outgoing side Figure 20. LBCU-ID parameter in route selection Figure 21. TDM usage optimisation 60
48 54 55
Figure 22. MGW selection based on load sharing weights Figure 23. MGW selection from the same UPDs 63
60
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 Figure 26. MGW selection from different UPDs sharing no MGWs 66
64 65
Figure 27. MGW selection from different UPDs with the same physical MGW Figure 28. Congestion control 69
68
DN01163601 Issue 3-0 en
5 (96)
User Plane Routing
Figure 29. Traffic overflow control Figure 30. Alternative routing 71
70
Figure 31. MGW selection based on BIWF address
72 74
Figure 32. Delayed MGW selection based on the BCU ID Figure 33. Tandem operation Figure 34. MGW reselection 76 78 80 81 84
Figure 35. MGW selection in TDM routing Figure 36. Call mediation node operation Figure 37. ICBNC load sharing example
Figure 38. Traffic separation between the MSS and MGW
90
6 (96)
DN01163601 Issue 3-0 en
Summary of changes
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 30 and 23

User plane topology database The UPD-specific IPNWR parameter has been added to Sections Structure of user plane destinations and Structure of interconnection data.

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.

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 Issue 3-0 en
7 (96)
User Plane Routing
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)
DN01163601 Issue 3-0 en
User plane routing
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 area subnetworks MGW
Core network MGW
User plane
Figure 1.
Decomposed network architecture
DN01163601 Issue 3-0 en
9 (96)
User Plane Routing
These sections cover only the basic functionality of user plane routing. The related procedures are available in User Plane Routing, Operating instructions.
10 (96)
DN01163601 Issue 3-0 en
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 of MGW selection in an MSS area.
TDM BSC TDM MSS TDM
TDM PBX
TDM
TDM PSTN/PLMN
ATM/IP/TDM
MGW
MGW
AAL2
ATM/IP/TDM
ATM/IP/TDM
ATM/IP
RNC
AAL2
MGW
ATM/IP
ATM/IP core network
Figure 2.
MGW selection network architecture
DN01163601 Issue 3-0 en
11 (96)
User Plane Routing
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 TDM
PSTN/PLMN
MGW
ATM/IP
BSC
TDM
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)
DN01163601 Issue 3-0 en
MSS AAL2
RNC
MGW
ATM/IP/TDM
MGW
ATM
Figure 4.
ATM to ATM, call case 1

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
MGW AAL2 RNC
ATM/IP/TDM
MGW
ATM
possible connection real connection
Figure 5.
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 Issue 3-0 en
13 (96)
User Plane Routing

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.
MSS AAL2
RNC
MGW
ATM/IP/TDM
MGW AAL2 ATM/IP/TDM
ATM
RNC
MGW
Figure 6.

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
AAL2
MGW
ATM
RNC
MGW
Figure 7.
14 (96)
DN01163601 Issue 3-0 en
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.
MSS
RNC
MGW
AAL2
MGW
ATM
RNC
MGW
logical connection physical connection
Figure 8.
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
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 Issue 3-0 en
15 (96)
User Plane Routing
BSC TDM ATM/IP/ TDM
TDM MSS TDM MGW TDM
BSC
PSTN/PLMN
TDM
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.
BICC
MSSC1
BICC
MSSC2
BICC
MSS A
MSS B
RANAP
H.248
H.248
RANAP
MGWA1
MGWB1
RNC
ATM/IP core network
RNC
MGWA2
MGWB2
Figure 11.
CMN transit call
16 (96)
DN01163601 Issue 3-0 en
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 Issue 3-0 en
17 (96)
User Plane Routing
18 (96)
DN01163601 Issue 3-0 en
Control plane signallings in MSC Server
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 Issue 3-0 en
19 (96)
User Plane Routing
20 (96)
DN01163601 Issue 3-0 en
User plane analysis
4
4.1
User plane analysis

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
subanalysis
Default result
Result_subanalysis Attribute value subanalysis Default result
Result_subanalysis
Attribute value
subanalysis
Default result
Result_subanalysis Attribute value
subanalysis
Default result Final result
Figure 12.
User plane analysis structure
DN01163601 Issue 3-0 en
21 (96)
User Plane Routing
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.
Note
The test side can have its own analysis for attribute values, the default result, and the unknown result.
22 (96)
DN01163601 Issue 3-0 en
User plane analysis
Table 1.
COMMON PART
. .
Structure of subanalysis
Subanalysis name Attribute identifier Pointer to normal analysis: analysis of values of attribute Normal default result Normal unknown result Pointer to test analysis: analysis of values of attribute Test default result Test unknown result
NORMAL SIDE
. . .
TEST SIDE
. . .
The following figure is a general example of the normal and the test side of a subanalysis.
Subanalysis name: XXX Attribute identifier: aaa Normal call Normal side value 1
Final result 1
.. .
value n Default result Unknown result Test call Test side value 1
Next subanalysis
Final result 2
.. .
value n Default result Unknown result Final result 3
Figure 13.
A general example of a subanalysis
The following table shows which side is used in a normal call.
DN01163601 Issue 3-0 en
23 (96)
User Plane Routing
Table 2. TEST SIDE

Not exist Not exist Exist Exist
Normal and test sides in normal calls NORMAL SIDE

Not exist Exist Not exist Exist
Action
Alarm Use normal side Alarm Use normal side
The following table shows which side is used in a test call.
Table 3. TEST SIDE

Not exist Not exist Exist Exist
Normal and test sides in test calls NORMAL SIDE

Not exist Exist Not exist Exist
Action
Alarm Use normal side Use test side 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 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
default result
24 (96)
DN01163601 Issue 3-0 en
User plane analysis
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 Issue 3-0 en
25 (96)
User Plane Routing
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 action indicator determination 4. Succeeding UPD determination 6. Inter-connecting BNC characteristics determination
Figure 14.
The relationship of different user plane analysis phases
26 (96)
DN01163601 Issue 3-0 en
User plane analysis
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 UE MS Incoming TRUNK BICC SIP 6* 6* 6* 1,6* 1,6*
MS 6* 6* 6* 1,6* 1,6*
TRUNK 6* 6* 6* 1,6* 1,6*
BICC 2,4,5,6* 2,4,5,6* 2,4,5,6* 1,2,3,4,5,6* 1,2,4,5,6*
SIP 2,4,6* 2,4,6* 2,4,6* 1,2,4,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)
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 Issue 3-0 en
27 (96)
User Plane Routing
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)
DN01163601 Issue 3-0 en
User plane analysis
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 Issue 3-0 en
29 (96)
User Plane Routing

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

.
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)
DN01163601 Issue 3-0 en
User plane analysis
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

.
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 Issue 3-0 en
31 (96)
User Plane Routing

.
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

.
Interconnecting BNC characteristics
For more information, see Section Configuring user plane analysis in User Plane Routing, Operating instructions.
32 (96)
DN01163601 Issue 3-0 en
User plane analysis
4.3

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.
Attribute
Emergency call indicator (EMCI)
Description: indication of
Emergency call
Use: determination of
Preceding UPD Succeeding BNC characteristics Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
Inter MSS handover indicator (IMSSHI) OLCM usage indicator (OLCMI) Original Dialling Class (ODC)
1
Call leg is established for an inter-MSS handover Subscriber monitored Original dialling class defined in control plane analyses based on call- and subscriber-related data.
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 action indicator (PAI)
Bearer establishment method Preceding UPD used at incoming side Succeeding BNC characteristics Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
Preceding BNC characteristics (PBNC)
Type of bearer at the incoming side
Preceding UPD Call mediation node Succeeding action indicator Succeeding BNC characteristics Interconnecting BNC characteristics
DN01163601 Issue 3-0 en
33 (96)
User Plane Routing
Table 5.
User plane analysis attributes (cont.)
Attribute
Preceding BCU-ID (PBCU)
MGW used in the preceding node 2
Preceding UPD Succeeding BNC characteristics Succeeding UPD Succeeding action indicator
Preceding signalling type (PSIGT)
Type of call control signalling at incoming side
Preceding UPD Succeeding BNC characteristics Call mediation node Succeeding action indicator Interconnecting BNC characteristics
Preceding UPD (PUPD)
UPD identifier of incoming side
Succeeding BNC characteristics Succeeding action indicator Interconnecting BNC characteristics
Preceding UPDR (PUPDR)
Preceding user plane destinaton reference from control plane (defined in Incoming circuit group data)
Call mediation node Interconnecting BNC characteristics Preceding UPD Succeeding action indicator Succeeding BNC characteristics Succeeding UPD
Succeeding action indicator (SAI) Succeeding BNC characteristics (SBNC)
Bearer establishment method Interconnecting BNC characteristics at the outgoing side Type of bearer used at outgoing side Call mediation node Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
Succeeding BCU-ID (SBCU)
MGW used in succeeding node Type of call control signalling at outgoing side
Succeeding UPD Succeeding BNC characteristics Call mediation node Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
Succeeding signalling type (SSIGT)
Succeeding UPD (SUPD) UPD identifier of the outgoing Succeeding action indicator side Interconnecting BNC characteristics
34 (96)
DN01163601 Issue 3-0 en
User plane analysis
Table 5.
User plane analysis attributes (cont.)
Attribute
Succeeding UPDR (SUPDR)
3
Succeeding user plane destinaton reference from control plane (defined in outgoing route data)
Succeeding BNC characteristics Call mediation node Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
User Plane Bearer Required transfer capability Requirement (UPBREQ)4 for the call
Preceding UPD Succeeding BNC characteristics Succeeding UPD Succeeding action indicator Interconnecting BNC characteristics
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.
Table 6. TMR
UDI
Call control logic of forming UPBREQ values UPBREQ

UDI
BASIC SERVICE CODE

Any
DN01163601 Issue 3-0 en
35 (96)
User Plane Routing
Table 6. TMR
RDI 3.1 3.1 Speech Speech Not UDI, RDI, 3.1, or speech Not UDI, RDI, 3.1, or speech Not UDI, RDI, 3.1, or speech Not UDI, RDI, 3.1, or speech
Call control logic of forming UPBREQ values (cont.) UPBREQ

RDI Audio Facsimile group 3 Speech Audio Speech Facsimile group 3 Audio Speech
BASIC SERVICE CODE

Any Any other than T61 or T62 T61 or T62 Speech or alternative line service Any other than speech or alternative line service Speech or alternative line service T61 or T62 Any bearer service Non-existing
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)
DN01163601 Issue 3-0 en
User plane analysis
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. Analysis
Call mediation node
Possible results of the user plane analysis 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.
Interconnecting backbone network connection characteristics Preceding user plane destination Succeeding action indicator Succeeding backbone network connection characteristics Succeeding user plane destination
The following figure describes the relationship between the analysis results:
DN01163601 Issue 3-0 en
37 (96)
User Plane Routing
CMN indicator
MSC Server
H.248 Control Preceding UPD MGW MGW MGW MGW Inter-Connecting BNC Characteristics MGW MGW MGW Succeeding BNC Characteristics Succeeding UPD
MSC Server
H.248 Control
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. 2. 3. User plane control collects the values of all call-related parameters which are possible attributes in the user plane analysis. The execution of the user plane analysis always starts from a starting subanalysis, that is, from the source file. 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.
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)
DN01163601 Issue 3-0 en
User plane analysis
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. 4. 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.
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 Issue 3-0 en
39 (96)
User Plane Routing
40 (96)
DN01163601 Issue 3-0 en
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 MGW MGW AAL2
AAL2 Interconnection UPD MGW 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 Issue 3-0 en
41 (96)
User Plane Routing
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.
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)
DN01163601 Issue 3-0 en
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 Issue 3-0 en
43 (96)
User Plane Routing
MSS1
MSS2
MSS3
UPD3 IPv6 Trunk_cap=ON STOM=DC
UPD2 IPv4 Trunk_cap=OFF STOM=CN
MGW-21
MGW-1
AAL2 Trunk_cap=OFF STOM=CN
MGW-3
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) (MGWspecific) 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)
DN01163601 Issue 3-0 en
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 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
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 Issue 3-0 en
45 (96)
User Plane Routing
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 reselection. 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)
DN01163601 Issue 3-0 en
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 Issue 3-0 en
47 (96)
User Plane Routing
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 MGW MGW
MGW
MGW
Figure 18.
User plane routed through two MGWs
48 (96)
DN01163601 Issue 3-0 en
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.
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 Issue 3-0 en
49 (96)
User Plane Routing
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)
DN01163601 Issue 3-0 en
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 Issue 3-0 en
51 (96)
User Plane Routing
52 (96)
DN01163601 Issue 3-0 en
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 Issue 3-0 en
53 (96)
User Plane Routing
Control Plane
ROUTE data UPDR=5 UPD 2 many other attributes UPDR
MSC Server
User Plane MGW MGW MGW MGW MGW MGW MGW MGW MGW MGW
user plane analysis
UPD=2
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)
DN01163601 Issue 3-0 en
Control Plane
ROUTE data LBCU-ID=5
MSC Server
User Plane MGW MGW MGW MGW MGW MGW MGW MGW MGW MGW incoming MGW data LBCU-ID=5
route selection
selected outgoing route
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 Issue 3-0 en
55 (96)
User Plane Routing
56 (96)
DN01163601 Issue 3-0 en
MGW selection
7
7.1
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.
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. 2. Collecting control plane- and user plane -related information from the signalling and call control applications. 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 Issue 3-0 en
57 (96)
User Plane Routing
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. Selecting an MGW from the UPD. Selection can be done, for example, by using load sharing weight values as specified in the following sections.
4.
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)
DN01163601 Issue 3-0 en
MGW selection
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 TDMterminating 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.
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 Issue 3-0 en
59 (96)
User Plane Routing
Physical MGW
Access/Core Network
M1
No interconnection is needed between M1 and M2 virtual MGWs
M2
ECCS PSTN/BSS
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
M1
25
M2
17
M4 5
20
RNCOrig.
M3
14
M5
40
Figure 22.
MGW selection based on load sharing weights
60 (96)
DN01163601 Issue 3-0 en
MGW selection
The weight-based selection process consists of the following steps: 1. Calculating the sum of the load sharing weights of each MGW.
Table 8. MGW index

1 2 3 4 5 SUM
Collecting load sharing weights in the MGW Load sharing weight

25 17 14 20 40 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. MGW index

1 2 3 4 5
Selecting MGW from UPD Load sharing weight

25 17 14 20 40
Number range
1-25 26-42 43-56 57-76 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 Issue 3-0 en
61 (96)
User Plane Routing
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)
DN01163601 Issue 3-0 en
MGW selection
UPD in = UPDout
M1
M2
M4 5
RNC Orig.
M3
M6
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 UEUE 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 Issue 3-0 en
63 (96)
User Plane Routing
UPD in
UPD out
M1 M3
M2
M4 5 M6
M5
RNCOrig.
RNCTerm.
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 UECN 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)
DN01163601 Issue 3-0 en
MGW selection
UPD in
UPD out
M1 M3
M2
M4 5 M6
M5
Backbone
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 Issue 3-0 en
65 (96)
User Plane Routing
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
M1
M5
M3 5 Backbone M6
RNC Orig.
M4
M2
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)
DN01163601 Issue 3-0 en
MGW selection
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.
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 weightbased bearer selection for the interconnecting bearer types configured between the selected MGWs.
DN01163601 Issue 3-0 en
67 (96)
User Plane Routing
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
M1
M4 M3 M5
M6
Backbone
M7
M2
AAL2
RNC (orig) virtual MGWs belong to the same physical MGW
Figure 27.
MGW selection from different UPDs with the same physical MGW
The MGW selection process starts with selecting the outgoing side MGW. During the selection process, the need for interconnection is recognised and the incoming side MGW is pre-selected. The selection process consists of the following steps: 1. Finding MGWs belonging to both UPDs. The preceding and succeeding UPDs are different and they 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, M7}. Load sharing weights for the selection are taken from the succeeding, outgoing, UPD. Interconnections among the MGWs in the UPDs are not yet considered at this phase. It is assumed that M3 is selected.
68 (96)
DN01163601 Issue 3-0 en
MGW selection
3.
Finding interconnected MGWs. The MSS collects the virtual MGWs from the preceding UPD, which belong to the same physical MGW as the already selected one (MGW3). In this example, the set of the MGWs which fulfill this requirement is {M4, M5}. The 'interconnecting BNC characteristics determination' user plane analysis is not executed, but the interconnecting bearer network connection type (BNC characteristics) is set to AAL2.
4.
Making weight-based selection for the incoming side. Weight-based selection is made among the set of interconnected MGWs. Load sharing weights are taken from the preceding, incoming, UPD. It is assumed that MGW4 is selected in this example.
Congestion handling If the congestion handling functionality is activated, and the MSS has loaded the MGW Congestion event at startup, the MGW can indicate its congestion situation to the MSS by sending the load reduction percentage value. As in the MGW selection procedure, this value is checked by the MSS, and a certain percent of the load of the specific MGW is redirected to other MGWs, which have not requested load reduction. Before making the actual traffic redirection, the Overflow Traffic Redirection parameters of the MGWs involved are checked. For more information, see Example Controlling overflow traffic redirection. Congestion handling does not affect emergency and priority calls and OLCM resources. Example Controlling congestion situations
UPD in = UPDout
M2 M1
RNCOrig.
M4 M3 5 M6
Backbone
Figure 28.
Congestion control
DN01163601 Issue 3-0 en
69 (96)
User Plane Routing
In the scenario presented in Figure Congestion control, M2 and M4 are congested. 1. Finding MGWs belonging to both UPDs. The set of shared MGWs is {M1, M2, M3, M4, M6}. 2. 3. 4. 5. 6. Selecting the outgoing side MGW from the shared set (in this case, M2). Checking congestion in the MGWs. Dropping congested MGWs from the shared set (in this case, M2 and M4). Selecting the outgoing side MGW from the remaining set (in this case, M6). Selecting the incoming side MGW from the remaining set (in this case, M6). Controlling overflow traffic redirection
UPD in = UPD out
Example
UPD in = UPD out
NCOrig
M1
M2
M4
RNCOrig
M1
M2
M4
x
M6
x
M6
NCTerm
RNC Term
Figure 29.
Traffic overflow control
1.
In this example, overflow from M2 to other MGWs is denied (UPD parameter RORIG=FALSE). In a congestion situation, the call is rejected as shown on the left side of the figure.
2.
Overflow from other MGWs to M6 is denied (UPD parameter RACC=FALSE).
70 (96)
DN01163601 Issue 3-0 en
MGW selection
In a congestion situation, an MGW from the set {M1, M4} is selected as shown on the right side of the figure. Alternative routing If no suitable MGW is found in the UPD during the MGW selection procedure, the `MGW_load_reduction` cause code is set. If alternative routing is performed on the control plane level for the `MGW_load_reduction` cause code, that is, the End-of-Selection (EOS) analysis or EOS Attribute analysis has the main result Execute Alternative Subdestination analysis (ALTROU), and the additional result is MGW Overload Congestion (MGWOC), then MGW selection in the new UPD only concerns not overloaded MGWs. For more information, see Sections End-of-Selection analysis and Routing, charging, and EOS attribute analyses in Basic Routing Functions, Functional description. Example Using alternative routing
If MGW selection is unsuccessful in UPD1, it is possible to use alternative routing. However, in the case of alternative routing, during MGW selection in UPD2, overloaded MGWs cannot be taken into account.
UPD in UPD out-1
M1
M3 5
RNCOrig.
M2
M4
Backbone
M5
M6
UPD out-2
Figure 30.
Alternative routing
1.
In this example, UPDout-1 corresponds to the first control-plane-level routing alternative. MGW selection fails due to congestion control.
DN01163601 Issue 3-0 en
71 (96)
User Plane Routing
2.
Control plane executes alternative routing. UPDout-2 corresponds to the second control-plane-level routing alternative.
3.
M4 is dropped because it is congested. MGW selection must be done among the remaining set {M5, M6}. If M5 is congested, it must also be dropped from the set.
7.2
MGW selection optimisation based on BIWF address

In the Nokia implementation, the BIWF address represents the address of a physical MGW. When a physical MGW is split up to several virtual MGWs, like in the following example, each virtual MGW is identified with the same BIWF address. The individual virtual MGWs belonging to the same physical MGW can be controlled either by the same or a different MSS.
MSS A RANAP RNC
BIWF address of MGWV1 H.248 H.248
MSS B RANAP RNC
Virtual MGWV1
Virtual MGWV2 Physical MGWP12
Figure 31.
MGW selection based on BIWF address
When BICC call control signalling is used between the MSSs or in intraMSS call cases, the BIWF addresses of the virtual MGWs can be used in the MGW selection process to select virtual MGWs from the same physical MGW for the call. This kind of optimisation benefits from a resource usage point of view. In the Nokia MGW implementation no external bearer connection is required between the virtual MGWs belonging to the same physical MGW. In call cases, between MSSs with BICC call control signalling, the steps in the selection process are the following:
72 (96)
DN01163601 Issue 3-0 en
MGW selection
1.
The BIWF address is received from the preceding node in the IAM or from the succeeding node in the APM, depending on the used BICC bearer establishment method. In the case of backward establishment or forward establishment with non-delayed MGW selection, MSS A first selects an MGW for the call. In this case MSS B receives the BIWF address of the selected MGW in the IAM. In the case of forward establishment with delayed MGW selection, MSS B first selects an MGW for the call. In this case, MSS A receives the BIWF address of the selected MGW in the APM.
2.
The received BIWF address is analysed by the MSS during the MGW selection procedure. The MSS recognises that a virtual MGW with the same BIWF address is included in the previously determined UPD towards the other node. Since the BIWF addresses of the MGWs are the same, this means that the used virtual MGWs are physically located in the same network element. The MSS selects the virtual MGW from the same physical MGW for the call.
3.
Note
If there are several virtual MGWs in the UPD which belong to the same physical MGW, the MSS selects one of the MGWs that are based on the defined load sharing value. For more information, see Section 7.1 MGW selection basic functionality.
7.3
MGW selection optimisation based on BCU-ID

When BICC call control signalling is used, the MGW selection can also be optimised using the BCU-ID that is received from the peer MSS. The BCUID is a logical identifier of the MGW that has been selected for user plane traffic by the peer MSS. In the Nokia implementation, it can be configured to be unique on a virtual MGW basis. The BCU-ID can affect MGW selection through the user plane analysis, where it is available as an attribute. Depending on the call case and the used BICC bearer establishment method, it can be used to optimise the preceding or succeeding UPD selection. This way it can be used to select an optimal set of MGWs, identified by the UPD, among which the MGW for the user plane traffic is selected.
DN01163601 Issue 3-0 en
73 (96)
User Plane Routing
Example
Using delayed MGW selection based on the BCU-ID
Forward establishment with delayed MGW selection is used towards the succeeding MSS. No MGW is selected for the call before sending an IAM message towards the succeeding MSS. The succeeding MSS selects an MGW and sends the BCU-ID and the necessary bearer information for the bearer establishment back in the APM message. The BCU-ID identifies the selected MGW and it is used in the user plane analysis for determining the succeeding UPD.
5. MSS A selects MGW2 from the UPD. 2. MSS B selects MGW1.
1. IAM MSS A 3. APM (bcu-id of MGW1) MSS B
RNC
MGW 2 4. BCU-ID of MSSB is used in user plane analysis to determine succeeding UPD in MSSA. MGW 3
MGW 1
Figure 32.
Delayed MGW selection based on the BCU ID
The steps during bearer establishment are the following: 1. MSS A determines the succeeding UPD using the user plane analysis, but does not select an MGW for the call. An IAM message is sent to MSS B without a BCU-ID. If codec negotiation is used, the supported codec list in the IAM is composed based on the minimum set of codecs supported by the MGWs belonging to the succeeding UPD. MSS B selects MGW1 for the call. It sends back the BCU-ID of the selected MGW and the necessary bearer information for bearer establishment in a backward APM message.
2.
74 (96)
DN01163601 Issue 3-0 en
MGW selection
3.
MSS A re-determines the succeeding UPD by re-executing the user plane analysis. Re-execution of the user plane analysis can result either in the same succeeding UPD as the one determined in the first step or in a different one. MSS A selects an MGW from the succeeding UPD. Note that MGW selection inside the UPD can be further optimised using the BIWF address. For more information, see Section 7.2 MGW selection optimisation based on BIWF address.
4.
Note
If the succeeding UPD is changed, codec negotiation is used, and no MGW supporting the selected codec is available in the new UPD, the call is released.
Similar optimisation is possible when other bearer establishment methods are used. In the case of backward establishment or forward establishment with non-delayed MGW selection, the preceding UPD selection in the succeeding MSS can be optimised by using the BCU-ID in the user plane analysis.
7.4
Tandem operation in MGW selection

When a special resource is not available in the MGW where the user plane connection has been created, a tandem operation is used to direct the user plane to an appropriate MGW. In the following case a special resource is needed and that is an interconnection PCM line to MSS A. There is no such connection between MSS A and MGW1, and therefore, a tandem operation is needed to find an MGW tandem which is able to provide the special resource in question.
DN01163601 Issue 3-0 en
75 (96)
User Plane Routing
ISUP MSSA RANAP
H.248
H.248
RNC
MGW1
MGWtandem
Figure 33.
Tandem operation
In this case, the special resource for the tandem operation is an interconnection PCM line between the MSS and the MGW. When the tandem resource is needed, the MSS collects the list of those MGWs which have an interconnecting TDM to the MSS. If there are several such MGWs, one of them is randomly selected and the resource is reserved for that one. MGWs are evenly weighted in the selection, that is, no load sharing is taken into consideration. On the other hand, the tandem MGW is not selected randomly in an OLCM case. If the location of the OLCM delivery function is known, the interconnecting resources are reserved for that MGW.
7.5
User plane control level MGW reselection

In the case of a failed resource reservation event, the user plane control application makes an MGW reselection in accordance with the provisioning status defined in the UPD data. In addition to this, there must be several MGW candidates in the UPD, equal in capabilities, which can be used for user plane transmission. A certain number of MGWs that have been defined in the UPD are tried before a negative acknowledgement is returned to the call control application. The exact number of reselection attempts depends on a UTPFIL parameter (family: URQ, parameter ID: 6, default value: 5).
76 (96)
DN01163601 Issue 3-0 en
MGW selection
Different reselection methods are applicable for different BICC bearer establishment methods. Depending on the bearer establishment method, the reselection method can also depend on the call establishment direction. Reselection parameters are not applicable when SIP call control signalling is used. The provisioning of MGW reselection for BICC call control signalling can be controlled through the topology database MML interface. The following UPD-specific provisioning options are available in accordance with the Prepare Bearer or the Establish Bearer procedure, or in accordance with both procedures:
.
Normal category calls Emergency category calls
It is recommended that reselection in accordance with both of the above mentioned procedures is used. This means that reselection is always attempted, regardless of the used BICC bearer establishment method. The following table summarises which reselection methods are applicable for the different BICC bearer establishment methods. When reservation is successfully done for the MGW, no reselection is allowed any more.
Table 10. BNC characteristics

AAL2
MGW reselection Originating side

Prepare BNC Establish BNC Prepare BNC Prepare BNC
Bearer establishment method

Forward, non-delayed MGW selection Forward, delayed MGW selection Backward
Terminating side
Prepare BNC Prepare BNC Establish BNC Prepare BNC
IP
All establishment methods
In the figure below, MGW FAIL is not able to create a connection to the RNC. User plane control reselects MGW A for the call instead of the malfunctioning or overloaded MGW FAIL.
DN01163601 Issue 3-0 en
77 (96)
User Plane Routing
MSS A
BICC
MSS B
H.248 RANAP MGWA H.248 ATM/IP core network
MGWFAIL RNC
Figure 34.
MGW reselection
MGW reselection is also possible in the case of a tandem operation, when the selected MGW, which has an interconnecting TDM to the MSS, is unable to reserve the necessary resource for the call. The MSS excludes the problematic MGW from the list of those MGWs which have an interconnecting TDM to the MSS and executes MGW reselection from the reduced list. MGW reselection works slightly differently if the IC_CONF_OPT_IN_PHYS_MGW PRFILE parameter is activated and the resource reservation problem occurs in a call case where MGW selection optimisation is executed by the MSS. In this case, the original candidate list contains those virtual MGWs which are in the same physical MGW as the already selected one. In a congestion situation, the result of the normal reselection method can be that all the instances of reselection is unsuccessful because of the common resource pool in the physical MGW. To avoid this, the MSS creates a new candidate list from the original UPD, which contains only those MGWs, which are in a different physical MGW than the originally selected one. The new MGW is selected with the normal selection method, described in Section 7.1 MGW selection basic functionality.
78 (96)
DN01163601 Issue 3-0 en
MGW selection
7.6
MGW selection in TDM routing

When TDM is used as an outgoing resource and the incoming resources are already reserved before route selection, MGW selection can also be optimised using the BCU-ID of the already reserved MGW. In the Nokia implementation, the BCU-ID can be configured to be unique on a virtual MGW basis. The BCU-ID is assigned to a virtual MGW in the MGW database. The BCU-ID can affect MGW selection through route selection in call control analysis, where it is available as an attribute. Outgoing TDM routes can be configured with the BCU-ID of the MGW to which their circuits are connected. The route selection procedure uses the BCU-ID of the already reserved MGW as an input attribute and tries to find a route with the matching BCU-ID. This way MGW selection can be optimised in the case of TDM routing. For more information, see Section Configuring MGW database in user plane routing in User Plane Routing, Operating instructions. If already reserved resources are in the MSS, the BCU-ID of the MSS is used by route selection. For more information on the BCU-ID in route selection, see Basic Routing Functions, Functional description. Example Selecting an MGW in TDM routing
In the case of mobile-originated calls, the BSC is connected to the MGW. The incoming side bearer is reserved before outgoing route selection, that is, the incoming MGW is selected. The BCU-ID of the incoming MGW is delivered from the user plane to the control plane and is used in route selection. There are two TDM routes towards the destination. Both routes are configured with the BCU-ID of the MGW to which their circuits are connected. Route selection selects the route the circuits of which are connected to MGW1.
DN01163601 Issue 3-0 en
79 (96)
User Plane Routing
MSS
BSC
MGW 1 (LBCU-ID=1)
TDM Destination
AAL2
MGW 2 (LBCU-ID=2)
TDM
Figure 35.
MGW selection in TDM routing
7.7
Call Mediation Node

The Call Mediation Node (CMN) mode operation is possible if no user plane resource is required by the MSS and the required type of user plane connection exists between the preceding and succeeding nodes controlling the user plane. During call processing, based on its configuration data, the MSS is able to determine whether it must act as a CMN or a TSN node. CMN detection is carried out by a user plane control application through executing the 'CMN determination' user plane analysis phase. When the MSC Server is in CMN mode, it is no longer possible to return to the TSN mode. The CMN functionality can be used with BICC and SIP call control signalling. BICC and SIP call control signalling interworking is allowed in CMN mode, but only with fast forwarding tunnelling. In the figure below, MSS CMN acts as a CMN between MSS A and MSS B.
80 (96)
DN01163601 Issue 3-0 en
MGW selection
BICC MSS A
MSSCMN
BICC MSS B
RANAP
H.248
H.248
RANAP
MGWA
ATM/IP core network
MGWB
RNC
RNC
Figure 36.
Call mediation node operation
BCU-ID-based MGW selection optimisation can be especially useful when CMN nodes are involved in the call between the MSSs that control user plane resources. In this case, determining an optimal preceding or succeeding UPD towards the peer MSS can be problematic because the CMN node can hide the identity of the peer MSS that controls user plane resources. The BCU-ID can be used to overcome the problem. It can identify the MGW that was selected for the call by the peer MSS. This information can be used in the user plane analysis to select an optimal UPD that provides a connection to the MGW selected by the peer MSS.
DN01163601 Issue 3-0 en
81 (96)
User Plane Routing
82 (96)
DN01163601 Issue 3-0 en

The Interconnecting BNC characteristics load sharing functionality makes it possible to share the traffic load on the connecting Multimedia Gateways (MGWs) between the configured Interconnecting Backbone Network Connection (ICBNC) characteristics based on the associated ICBNC Characteristics (ICBNCC) weights. With the Interconnecting BNC characteristics exclusion functionality, you can significantly decrease the amount of unsuccessful calls when the Nb User Plane (Nb UP) protocol initialisation fails since with this enhancement, it is possible to handle the MGW-MGW interconnecting leg independently as a separate call leg and to make alternative interconnecting leg reservation.
8.1
Interconnecting BNC characteristics load sharing

With this enhancement, multiple MGW-MGW interconnecting Backbone Network Connection (BNC) values can be associated for one MGW-MGW interconnecting leg. The traffic load between two MGWs can be shared among more ICBNC characteristics. There are maximum of four possible values as ICBNC characteristics:
.
ATM AAL2 IPv4 IPv6 TDM
Additionally, a weight value is associated for each ICBNC characteristics value. The weight value for the ICBNC characteristics ranges from 0 to 250.
DN01163601 Issue 3-0 en
83 (96)
User Plane Routing
Nc MSS
Nc
Iu CP
Mc
Mc
Iu CP
RNC-A UE-A
Iu MGW1
ATM AAL2: 99 IPv4: 1
Iu MGW3
RNC-B UE-B/ MS-B
ATM AAL2: 100 IPv4: 100
TDM: 249 IPv4: 1
Iu Nb
MGW2
ATM AAL2: 49 TDM: 49 IPv4: 1 IPv6: 1
MGW4
Iu Nb
Figure 37.
ICBNC load sharing example
The calculated percentage based division between the different bearers is the following in the example:
.
MGW1 to MGW3 . ATM: 99% . IPv4: 1% MGW1 to MGW4 . ATM: 50% . IPv4: 50% MGW2 to MGW3 . TDM: 99.6% . IPv4: 0.4% MGW2 to MGW4 . ATM: 49% . TDM: 49%
84 (96)
DN01163601 Issue 3-0 en
. .
IPv4: 1% IPv6: 1%
The ICBNC characteristics load sharing functionality can be activated for an MGW-MGW ICBNC characteristics selection by using the LOADSHARE value as a result of the interconnecting BNC characteristics determination analysis. For more details, see the User Plane Analysis settings. When the ICBNC characteristics load sharing functionality is used, the MGW selection happens by applying the User Plane Destination (UPD) load sharing weights first. The ICBNC characteristics weights adjust the traffic of each backbone network. Thus, you can build more reliable core network. The traffic load is shared between the configured ICBNC characteristics based on the associated ICBNC characteristics weights. With this enhancement, parallel backbone networks can be used simultaneously for the same MGW to MGW connection. Additionally, this functionality enables you to share the traffic between different backbone networks in a variable ratio, which can be useful during backbone migration works. You can use one backbone network for the majority of the calls but the others can use the new backbone network which is under live verification. Ext-IP load sharing functionality The EXTIP_ICBNC PRFILE parameter determines the constant interconnection BNC characteristics between the MGW to which an External Intelligent Peripheral (ext-IP) is connected and the other MGWs. The LOADSHARE parameter value enables load sharing-based ICBNC characteristics selection among the available BNC characteristics. If the EXTIP_ICBNC PRFILE parameter sets the load sharing based ICBNC characteristics selection functionality for Ext-IP services while the ICBNC characteristics load sharing feature is not activated, a simplified functionality works. In case of interconnecting legs for Ext-IP services, the MSC Server (MSS) provides a more flexible and safer functionality for ICBNC characteristics selection to ensure that the Ext-IP calls will be successful. In this case, the load sharing weights are not configured and both MGWs have already selected the Ext-IP connected MGW context and the subscriber MGW. The MSS determines the ICBNC characteristics among the possible ICBNC characteristics between the two MGWs. If multiple ICBNC characteristics are configured between the two MGWs, evenly distributed ICBNC characteristics selection is applied.
DN01163601 Issue 3-0 en
85 (96)
User Plane Routing
8.2
Interconnecting BNC characteristics exclusion

With this enhancement, you can significantly decrease the amount of unsuccessful calls. When the Nb User Plane (Nb UP) protocol initialisation fails because of some backbone network unavailability, the status of the given ICBNC characteristics bearer is stored and checked when the ICBNC characteristics is selected to be reserved. When the Nb UP initialisation failure happens on a given ICBNC characteristics, a flag is set in the User Plane Topology Database to indicate that the given interconnecting BNC characteristics is currently not available. When an interconnecting BNC characteristics is selected for reservation, this availability flag is checked first and the bearer reservation can happen only if the interconnecting BNC characteristics is available. If the interconnecting BNC characteristics is currently not available, an alternative interconnecting BNC characteristics is selected. You can activate the interconnecting BNC characteristics exclusion functionality with the ICBNCC_EXCLUSION PRFILE parameter. The ICBNC characteristics exclusion functionality cannot be used on MGW-MGW interconnecting legs when the Nokia proprietary Nb' interface is used while the Nb' does not use the Nb UP framing protocol. The ICBNC unavailability status is described by one flag and one counter as a two-level error handling solution. They are stored in the User Plane Topology Database.
.
'ICBNCC not in use' flag With the JFS MML command, you can release manually the unavailability flag of the ICBNC characteristics. You can also configure the timer which can automatically reset the 'ICBNCC not in use' flag for the faulty ICBNC characteristics. You can set the timer with the ICBNCC_EXCLUSION_TIMER PRFILE parameter.
ICBNCC fault count This counter shows the continuous 'ICBNCC not in use' cases and indicates the permanent fault status. The highest value of the counter is 7 and it is used as an 'ICBNCC faulty' flag. This flag indicates that a permanent fault situation has happened on the ICBNC characteristics, so the ICBNC characteristics is marked as faulty ICBNC characteristics.
86 (96)
DN01163601 Issue 3-0 en
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. The value of the parameter defines how many attempts are enabled before the ICBNC characteristics is marked as faulty. When the 'ICBNCC faulty' flag is set, no timer is started. You can make the ICBNC characteristics available only with the JFS MML command. Alarm 3263 is printed out when one of the ICBNC characteristics unavailability flags is set. It indicates the network resource outage and the printout contains details about the faulty ICBNC characteristics (MGW1, MGW2, BNC) and the fault status (fault count value). The alarm subtype informs about the ICBNC characteristics fault situation: Interworking with calls when no load sharing is used When the load sharing based ICBNC characteristics selection and ICBNC characteristics exclusion functionalities are enabled and activated and used in the MSS, the exclusion of the faulty and not used ICBNC characteristics are done also for normal calls. If the ICBNC characteristics determination analysis gives an ICBNC characteristics value other than LOADSHARE, the MGWs which have the selected ICBNC characteristics with 'ICBNCC not in use' or with 'ICBNCC faulty' flag set are filtered out from the MGW candidates. With this enhancement, the ICBNC characteristics not available information can be used at normal call cases to avoid unsuccessful interconnecting leg reservation cases.
DN01163601 Issue 3-0 en
87 (96)
User Plane Routing
88 (96)
DN01163601 Issue 3-0 en
Traffic separation between the MSS and MGW

With the Traffic separation between the MSS and MGW functionality, you can create maximum three routes separately for speech and data calls and you can route the transferred speech and data calls separately between the MSS and the MGW. It can be beneficial if different transportation method is used for speech and data calls. It gives the benefit of saving capacity when the speech is compressed on its route while the data traffic route remains intact. The differentiation of routes for speech and data calls and the compression of speech calls is beneficial when speech and data calls go through over large distances and it becomes necessary to enable the compression of speech calls for capacity reasons. The compression can be done by devices of some 3rd party vendors. The Traffic separation between the MSS and MGW functionality has an effect on the MSS to MGW interconnecting TDM route selection. Different routes for different traffic types are enabled between the MSS and MGW. Three different route types are used on the MSS to MGW interconnecting TDM routes: speech route for speech calls, audio route for TMR=3.1kHz audio calls, and UDI route for calls using TMR=UDI. Other TMR values are mapped to these three types of routes. For detailed information, see Table Call control logic of forming UPBREQ values in Section User plane analysis attributes. Calls with different Transmission Medium Requirement (TMR) are directed to the route with the ideal Transmission Medium Type (TMT). Thus, speech and audio calls can be compressed to save capacity. You can define three different TDM routes between an MGW and the controlling MSS in the MGW database.
DN01163601 Issue 3-0 en
89 (96)
User Plane Routing
A MSS
A BSC-B MS-B
route 1
route 2 route 3
BSC-A MS-A
MGW
Figure 38.
You can set and display the three different MSS interconnecting routes for the same MGW with the JGM and JGI MML commands. When IWF MGW is used, only one route can be given with the JGM MML command.
90 (96)
DN01163601 Issue 3-0 en
Alarms and cause codes issued in user plane routing
10

Alarms related to user plane configuration
.
1259 TOO MANY SUBANALYSES IN USER PLANE ANALYSIS This disturbance indicates that some analysis chains at the normal side include so many subanalyses that it can decrease the capacity of the switch. The limit of the number of subanalyses to be executed in one chain can be defined with a PRFILE parameter. This disturbance occurs if the number of the executed subanalyses exceeds the value of the corresponding PRFILE parameter value.
3178 INFINITE LOOP IN USER PLANE ANALYSIS This alarm indicates that the execution of the analysis has gone through too many subanalyses. It is treated as an analysis loop. The limit of the number of subanalyses to be executed in a call case is defined with a PRFILE parameter. In this case, the limit is (2 * parameter value) + 10. If this alarm occurs, a call which goes through a particular subanalysis path is not set up.
3179 INTER-CONNECTION BETWEEN TWO MEDIA GATEWAYS IS UNDEFINED This problem originates from faulty or inadequate configuration. This alarm is issued when two MGWs are selected for the call and the user plane has to be conveyed through them, or if there are no interconnections defined between the two MGWs.
3180 USER PLANE ANALYSIS IS MISSING The required user plane analysis does not exist. There has to be one analysis per phase at the normal side.
DN01163601 Issue 3-0 en
91 (96)
User Plane Routing
3185 USER PLANE CONTROL IS UNABLE TO RESOLVE USER PLANE DEST. DATA The problem originates from faulty or inadequate configuration. This alarm is set in the following cases: . The 'preceding UPD determination' or the 'succeeding UPD determination' user plane analysis phase determines a wrong value for the UPD. . The UPD data is not defined in the topology database.
3263 CALL ESTABLISHMENT FAILURE IN USER PLANE CONTROL This alarm indicates the different configuration problems related to user plane-level routing.
Alarms related to user plane topology database

.
0018 DATABASE RECOVERY IS IN PROGRESS Recovery based on an event log is in progress in the management system of the database.
0660 DATABASE TRANSACTIONS OR DISK UPDATES PREVENTED Database transactions or disk updates are prevented in the database management system.
1661 DATABASE MANAGER IN FATAL ERROR STATE An error occurred in the database management system, and the system has been set to the 'fatal error' state. In the 'fatal error' state the management system program block does not accept supervision messages. In this case, the system resets the database unit.
1662 DATABASE LOADING ERROR The loading of the database fails. If several load attempts fail, the management system is set to the 'fatal error' state. Because of this, the system resets the database unit.
1663 HAND RESERVATION ERROR IN DATABASE MANAGER The reservation of a transaction or fastread hand fails in the database management system.
1664 ERROR IN DATABASE SYSTEM An error occurred in the database management system during the operation of a database procedure.
92 (96)
DN01163601 Issue 3-0 en
2259 DATABASE IS INCONSISTENT Inconsistencies have been found in the database during database integrity checking. Because of these faults the functioning of the database may be disturbed.
2261 NO CONSISTENT COPY OF DATABASE ON DISK Neither of the disks has a consistent copy of the database. If there is a properly functioning copy of the database in the memory, the operation of the system is not in immediate danger. However, if the copy of the database is lost from the memory, the fault situation may prevent the restart of the database.
2397 DATABASE FILE IS IN DANGER TO GET FULL The threshold of the capacity of a database file has been exceeded.
2399 DATABASE DISK UPDATES ARE PREVENTED Database disk updates have been prevented with an MML command. The database disk copy is not updated. Updates saved in the memory can be lost if the system is restarted.
2663 DUMPING ERROR IN DATABASE MANAGER The dumping of a database fails in the database management system.
2664 DATABASE COPY STAYS INCONSISTENT ON SAME DISK Database disk updating is based on one disk. Even if the other disk contains a consistent copy of the database, in the case of a failure, the two copies might be inconsistent.
2268 DATABASE BACKUP PROCESS IS TERMINATED Taking a backup of the database has lasted too long, and the management system terminates the process.
2447 DATABASE TRANSACTION SAVING FAILED The database events performed by the database management system have been defined to be recorded in an event log with a parameter in the DBPARA file. The database management system sets this alarm if it cannot contact the event log management program block when it tries to start recording events. In this case, the system cannot record data that is necessary for database recovery and in an error situation the state of the database cannot be restored as accurately as when database events have been recorded
DN01163601 Issue 3-0 en
93 (96)
User Plane Routing
successfully. If the system cannot record database events in the event log, the state of the database can only be restored to the level of the previous backup copy. Updates that have taken place after backup copying cannot be reloaded to the database.
.
2662 NO CONSISTENT DATABASE ANYWHERE Neither disk has a consistent copy of the database, and the database management system fails in trying to load the database from a disk. The database cannot be used.
2665 DATABASE LOG BUFFER SIZE ERROR This is an internal error in the database management system. The Disk Updating System Management program block (DBSMAN) thinks there is an error in the size of the database log buffer. In the initialisation phase of the DBSMAN a log buffer is deemed faulty if it is smaller than the minimum size, and also when the size of the work file designated for handling the log buffer is smaller than that of the log buffer. After the initialisation, a possible error is detected when the family handling the database, DBMANA, requests the DBSMAN to transfer to the disk log a log buffer whose length is different from which the DBSMAN can handle. The error prevents database updating on the disk. Automatic recovery measures are taken; either the unit that contains the DBSMAN, or the one that has the DBMANA, or both of them are restarted. In addition to this, it is possible to modify the DBPARA and the DBINFO files on the disk.
3069 DATABASE REMOTE COPY UPDATING PREVENTED The database management system of the database primary copy sets this alarm when remote copy updating has been prevented by the DBT MML command. When this alarm is on, updates to the database primary copy are done but the delivery of those updates to the remote copy is prevented. This means that the data in the remote copy is inconsistent with the data in the primary copy. However, updates that must be delivered to the database remote copy are cached and when the remote copy updating is resumed again with the DBT MML command, the updates are delivered to the remote copy and the remote copy is consistent with the primary copy. The reasonable time for the duration of preventing remote copy updating depends on the database in question and the application which uses it. For example, if there are plenty of updates to the database primary copy and the application in the remote unit needs to read upto-date information from the remote copy, the updating of the remote copy should be prevented for as short an interval as possible.
3070 DATABASE REMOTE COPY LOADING FAILED
94 (96)
DN01163601 Issue 3-0 en
Loading of the database remote copy failed from the unit shown in the additional information of the alarm. The remote copy is not available in the object unit of the alarm. The reason for the remote copy load failure can be, for example, that the database manager of the main database is not ready to receive service requests or that the unit that contains the main database is not functioning properly. Cause codes
.
call_interrupt_in_up_ana This cause code is set when the user plane analysis results in stopping the call result. When the user plane analysis results in stopping the call result, the URQPRB returns this cause code in a negative resource reservation acknowledgement.
cd_t_configuration_error This cause code is set in several cases when the system configuration is inadequate to complete the calls. The following cases are possible: . MGW is not correctly configured in the MGW database. . Topology database could not provide a reasonable value. . Virtual circuit conversion to MGW-PCM/TSL combination is unsuccessful. . No MGW with an interconnecting TDM is configured in the MGW database despite the need for them. . Incorrect bearer establishment method is configured in the user plane analysis. . Incorrect controlling CCSU/SIGU unit information is stored in the MGW database. . Bearer network connection type (BNC characteristics) defined by the operator is unknown. . Bearer network connection type (BNC characteristics) defined in the 'succeeding BNC characteristics' user plane analysis phase is contradictory to the value defined in the UPD.
resource_not_avail_in_cmn This problem occurs only in CMN mode. This cause code is set if the MSC server is functioning as a CMN and either signalling or the call control requires the reservation of user plane resources for a call.
undefined_inter_connection
DN01163601 Issue 3-0 en
95 (96)
User Plane Routing
This cause code is set if there are no interconnections defined between two MGWs and a user plane should be conveyed through them.
.
unknown_user_plane_destination This cause code is set if the 'preceding UPD determination' or the 'succeeding UPD determination' user plane analysis phases lead to an unknown result, or if user plane destination data is not defined in the topology database.
user_plane_ana_problem This cause code is set if some part of user plane analysis is undefined, or if the structure of the user plane analysis is inconsistent.
For more information, see Clear Code List.
96 (96)
DN01163601 Issue 3-0 en

User Plane Routing

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

User Plane Routing

Enviado por

Direitos autorais:

Formatos disponíveis

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