01-05 Configuring MGW Data

HUAWEI MSOFTX3000 Configuration Guide Contents

Issue 06 (2007-08-08) Huawei Technologies Proprietary i

Contents

5 Configuring MGW Data...........................................................................................................5-1 5.1 Background Information ...............................................................................................................................5-2

5.1.1 Types of MGW.....................................................................................................................................5-2 5.1.2 Media Stream Codec Algorithms .........................................................................................................5-2 5.1.3 MGW Connection Mode......................................................................................................................5-4 5.1.4 Announcement Type ............................................................................................................................5-5 5.1.5 Announcement Principle ......................................................................................................................5-6

5.2 Configuring MGW Data................................................................................................................................5-9 5.2.1 Overview of Configuration ..................................................................................................................5-9 5.2.2 Adding Media Gateway .....................................................................................................................5-12 5.2.3 Adding H.248 Link ............................................................................................................................5-18 5.2.4 Adding Internal TDM Circuits (Optional) .........................................................................................5-21 5.2.5 Adding Path Information Between MGWs (optional) .......................................................................5-23 5.2.6 Adding Media Connection Between MGWs (optional) .....................................................................5-24 5.2.7 Setting Bearer Control Protocol Parameter (Optional) ......................................................................5-25

5.3 Configuring Announcement Data................................................................................................................5-27 5.3.1 Adding Tone ID Configuration ..........................................................................................................5-27 5.3.2 Adding Tone Playing by LAI Configuration......................................................................................5-29 5.3.3 Modifying Mapping Between Default Cause Value and Tone ID......................................................5-32 5.3.4 Adding Mapping Between Release Cause Value and Tone ID...........................................................5-33

Figures HUAWEI MSOFTX3000

Configuration Guide

ii Huawei Technologies Proprietary Issue 06 (2007-08-08)

Figures

Figure 5-1 Ring MGW Connection ....................................................................................................................5-4

Figure 5-2 Star MGW Connection .....................................................................................................................5-5

Figure 5-3 Tone ID encoding format .................................................................................................................5-9

Figure 5-4 Parameter referencing relationship .................................................................................................5-12

HUAWEI MSOFTX3000 Configuration Guide Tables

Issue 06 (2007-08-08) Huawei Technologies Proprietary iii

Tables

Table 5-1 Common media stream codec algorithms...........................................................................................5-2

Table 5-2 Input Parameters required for configuring MGW data.....................................................................5-10

Table 5-3 Output parameters defined in MGW data.........................................................................................5-10

Table 5-4 Configuration preparation.................................................................................................................5-10

Table 5-5 Configuration steps...........................................................................................................................5-11

HUAWEI MSOFTX3000 Configuration Guide 5 Configuring MGW Data

Issue 06 (2007-08-08) Huawei Technologies Proprietary 5-1

5 Configuring MGW Data

About This Chapter

The following table lists the contents of this chapter.

Section Describes

5.1 Background Information The MGW.

5.2 Configuring MGW Data How to configure the MGW data.

5.3 Configuring Announcement Data

How to configure the announcement data.

5 Configuring MGW Data HUAWEI MSOFTX3000

Configuration Guide

5-2 Huawei Technologies Proprietary Issue 06 (2007-08-08)

5.1 Background Information 5.1.1 Types of MGW

In the networking of 3GPP R4 or higher, based on the equipment connection in the media gateway (MGW) , MGWs can be classified as follows:

Mobile Access MGW

It is used to access to the base station controller (BSC) or radio network controller (RNC). When accessing to the BSC, it is the MGW between the TDM-bearer BSS and the IP/ATM/TDM-bearer core switching network. When accessing to the RNC, it is the MGW between the ATM-bearer RAN and the IP/ATM/TDM-bearer core switching network.

Mobile Trunk MGW

It is used for interworking with traditional exchanges such as the mobile switching center (MSC) and public switched telephone network (PSTN). That is, it is the MGW between the IP/ATM/TDM-bearer core switching network and the TDM-bearer MSC and PSTN.

In actual networking, an MGW can be an independent mobile access MGW or mobile trunk MGW. It can also be the combination of the mobile access MGW and mobile trunk MGW.

5.1.2 Media Stream Codec Algorithms MGW is used to convert the media stream (such as audio, video, or fax) in one bearer network to the media stream in the format required by another bearer network. For example, the MGW between the TDM-bearer BSS and the IP-bearer core switching network needs to convert G.711 media stream to G.729/AMR.

To implement the functions, MGW should support the media stream codec modes as listed in Table 5-1.

Table 5-1 Common media stream codec algorithms

Codec Algorithm

Brief Description

G.711 A

G.711 µ

G.711 is a non-compressed, waveform codec algorithm. The data is directly derived from PCM with the sampling rate of 8,000 Hz and bit rate of 64 kbit/s. According to the different rates of compression and expansion, G.711 can be further classified as A law and μ law. A law uses a compandored curve with 13 broken lines, and μ law uses a compandored curve with 15 broken lines.

G.723.1 G.723.1 is a compressed, parameter codec algorithm at the sampling rate of 8,000 Hz, and there are two kinds of bit rates after compression: 6.3kbit/s and 5.3kbit/s. The advantage of this algorithm is good voice quality, and the disadvantage is rather long processing delay.



Codec Algorithm

Brief Description

G.729 A G.729.A is a compressed, parameter codec algorithm at the sampling rate of 8,000 Hz, and there are two kinds of bit rates after compression: 6.3 kbit/s and 5.3 kbit/s. The voice quality of G.729 A is between that of G.711 and G.723.1. Its capability to prevent random bit error is the same as that to prevent random burst loss of subracks. Thus, in a noisy environment, its voice quality is still good.

GSM FR GSM FR is a compressed, hybrid codec algorithm. It adopts RPE-LTP, and the bit rate after compression is 13 kbit/s. Its advantage is stability. That is, even in the environment with different mobile noises and under the instable wireless transfer conditions, it still can provide relatively stable voice quality.

GSM HR GSM HR is a compressed, hybrid codec algorithm based on the GSM. It adopts VSELP, and the bit rate after compression is 13 kbit/s. The bandwidth of GSM HR is half of GSM FR. Through the advanced algorithm, GSM HR can decrease radiation and power consumption with the same conversation quality.

GSM EFR GSM EFR is a compressed, hybrid codec algorithm based on the GSM. It adopts VSELP, and the bit rate after compression is 13 kbit/s. The voice quality over this algorithm is clearer. It has improved the algorithm of voice originating codec. Through the advanced algorithm, GSM EFR improved the conversation quality under the weak signaling conditions.

PDC EFR PDC EFR is a compressed, hybrid codec algorithm based on PDC mobile telecommunication network (Japan), and the bit rate after compression is 6.7 kbit/s.

TDMA EFR TDMA EFR is a compressed, hybrid codec algorithm based on EIA/IS-641 TDMA mobile telecommunication network (North America), and the bit rate after compression is 6.7 kbit/s.

HR AMR AMR is an algorithm over adaptive rate. It adopts ACELP. HR AMR is half rate of AMR codec algorithm, which only applies to the GSM. The bit rate of HR AMR is 4.75 kbit/s, 5.15 kbit/s, 5.90 kbit/s, 6.70 kbit/s, 7.40 kbit/s, and 7.95 kbit/s.

FR AMR AMR is an algorithm over adaptive rate. It adopts ACELP. FR AMR is full rate of AMR codec algorithm, which only applies to the GSM. The bit rate of HR AMR is 4.75 kbit/s, 5.15 kbit/s, 5.90 kbit/s, 6.70 kbit/s, 7.40 kbit/s, 7.95 kbit/s, 10.2 kbit/s, and 12.2 kbit/s.

FR AMR-WB AMR-WB is full rate of broadband AMR codec algorithm, which is also called G.722.2 algorithm. It only applies to the GSM. The bit rate of FR AMR-WB is 6.60 kbit/s, 8.85 kbit/s, 12.65 kbit/s, 14.25 kbit/s, 15.85 kbit/s, 18.25 kbit/s, 19.85 kbit/s, 23.05 kbit/s, and 23.85 kbit/s.

UMTS AMR AMR is an algorithm over adaptive rate. It adopts ACELP. UMTS AMR is full rate of AMR codec algorithm, which only applies to the UMTS. The bit rate of UMTS AMR is 4.75 kbit/s, 5.15 kbit/s, 5.90 kbit/s, 6.70 kbit/s, 7.40 kbit/s, 7.95 kbit/s, 10.2 kbit/s, and 12.2 kbit/s.


Configuration Guide


Codec Algorithm

Brief Description

UMTS AMR 2 The major difference between UMTS AMR 2 and UMTS AMR is the mode of rate control. In the coding direction, UMTS AMR 2 changes rate once two subracks, which is the same as the AMR algorithm of GSM. In the decoding direction, UMTS AMR 2 changes rate once a subrack. UMTS AMR 2 is compatible with UMTS AMR, FR AMR and HR AMR. When 2G subscribers interwork with 3G subscribers, UMTS AMR 2 can be used for TFO and TrFo functions.

UMTS AMR-WB

AMR-WB is full rate of broadband AMR codec algorithm, which is also called G.722.2 algorithm. It only applies to the UMTS. The bit rate of UMTS AMR-WB is 6.60 kbit/s, 8.85 kbit/s, 12.65 kbit/s, 14.25 kbit/s, 15.85 kbit/s, 18.25 kbit/s, 19.85 kbit/s, 23.05 kbit/s, and 23.85 kbit/s.

5.1.3 MGW Connection Mode When the MSOFTX3000 controls several MGWs, each MGW needs to interconnect exchanges such as BSC, RNC, MSC and PSTN. Besides, the MGWs need to interconnect with each other according to the network topology. According to the media type adopted by MGWs, the MGWs networking on the bearer network platform can be classified into two types:

Ring MGW Connection In this connection, when any two MGWs interchange media streams, part of the media stream can go from this MGW to that one directly; meanwhile part of the media stream needs to be forwarded by other MGWs. See Figure 5-1.

Figure 5-1 Ring MGW Connection

MGW B

MGW A

MGW C MGW D

MGW E

TDM TDM

TDM TDM

TDM

If the media type among MGWs is TDM, the bearer network (that is, the TDM circuit network) cannot provide the switching function itself. Therefore, MGWs are connected as a ring, unless



the MGWs interconnect with each other according to the network topology. For example, in Figure 5-1, MGW A and MGW B can interchange media streams directly. If MGW A wants to interchange media streams with MGW C, the media streams have to be forwarded by either MGW B or MGW E and MGW D.

Star MGW Connection In this connection, any two MGWs can interchange media streams directly. The networking is as shown in Figure 5-2.

Figure 5-2 Star MGW Connection

MGW B

MGW A

MGW C MGW D

MGW EIP/ATM

Packet Network

If the media type among MGWs is AAL 1, AAL 2, AAL 1 structure or IP, the bearer network (that is, the ATM/IP packet network) can provide the switching function. Therefore, any two MGWs can interchange media streams over the bearer network. Under this condition, MGWs are connected as a star. For example, in Figure 5-2, any two MGWs can interchange media streams with each other without the third party's forwarding.

5.1.4 Announcement Type The announcement is divided into different types.

Announcement Type Based on Playing Modes Based on the playing modes, the announcement is divided into the following two types:

Synchronous announcement: The MGW always plays a digital announcement from beginning when receiving an announcement request. This kind of digital announcement is the synchronous tone. Therefore, a subscriber always hears a complete announcement from beginning. The MGW always plays an announcement for a single subscriber instead of playing a broadcast announcement for multiple subscribers at a time. The Intelligent service announcement and the supplementary service announcement are common synchronous announcements.


Configuration Guide


Asynchronous announcement: The MGW does not always play a digital announcement from beginning when receiving an announcement request. This kind of digital announcement is the asynchronous announcement. Therefore, a subscriber might hear a section of an announcement played repeatedly from beginning or middle. The MGW can play a broadcast announcement for multiple subscribers (no limit to the number of subscribers) at a time. The basic service announcement is a common asynchronous announcement.

Announcement Type Based on Contents Based on the contents, the announcement is divided into the following three types:

Signal tone: The signal tone is a kind of digital announcement played with the specific frequency and cadence ratio, and represents the specific meanings. The dial tone, busy tone, ring back tone, test code tone and mute tone are signal tones.

Fixed announcement: The fixed announcement is the digital announcement with fixed contents when played each time. The most part of the basic service tone, the supplementary service tone and the intelligent service tone is the fixed announcement.

Variable announcement: The variable announcement is the digital announcement that changes dynamically when broadcasted each time. According to internal lexical analysis programs and a certain rule, the MGW uses elements such as telephone numbers, integers, time, date and prices to create a variable announcement that represents the specific meanings. The time announcement, the malicious call tracing success tone, and the billing tone are common variable announcements.

Announcement Type Based on Services Based on the services, the announcement is divided into the following three types:

Basic service announcement: The basic service announcement is the digital announcement (asynchronous announcement usually) mainly used in basic services. The mobile call-in/call-out restriction tone, the mobile callee busy tone, and the mobile callee shutdown tone are basic service announcements.

Supplementary service announcement: The supplementary service announcement is the digital announcement (synchronous announcement usually) mainly used in supplementary services. The call waiting tone, the call forwarding restriction tone and the do-not-disturb tone are supplementary service announcements.

Intelligent service announcement: The intelligent service announcement is the digital announcement (synchronous announcement usually) mainly used in intelligent services. The prompts "Please enter the language type, one for mandarin, two for English" and "Please enter your number, and then press #" are intelligent service announcements. Subscribers always hear the intelligent service announcement from beginning. Parameters, such as the start/end announcement time, the times of playing an announcement and the announcement duration, depend on intelligent services.

5.1.5 Announcement Principle

Overview of Announcement Principle In the network of the 3GPP R4 version (or a later version), the MGW stores all digital announcements and plays the digital announcements under the control of the MSC through the H.284 protocol as required by services.



According to Huawei's solution, when an announcement request is generated, the MSOFTX3000 sends parameters such as Package ID, Signal ID and Ann ID to the UMG8900 through H.248 to instruct the UMG8900 to play an announcement. After receiving the parameters, the UMG8900 searches for the digital tone clips to be played according to the mapping defined in the UMG8900 announcement configuration file and the parameters carried in H.248. Then the UMG8900 plays the corresponding announcement for subscribers.

Therefore, the manual introduces the announcement principle in the following two aspects:

UMG8900 Announcement Configuration File Tone ID Interface Parameter Between MSOFTX3000 and UMG8900

UMG8900 Announcement Configuration File The UMG8900 announcement configuration file is a formatted text file such as tonefilecfg_Thailand_ TAO.ini. The announcement configuration file instructs the UMG8900 on how to make a toneclip or a dynamic toneclip. The following is an example of the announcement configuration file:

..\output\tone\source\DTMF_0.pcm , 0005, 0010, 00000000

..\output\tone\source\DTMF_1.pcm , 0005, 0011, 00000000

..\output\tone\source\fffff803.001 , 0007, 0030, 00000000

..\output\tone\source\fffff806.001 , 0007, 0031, 00000000

..\output\tone\source\fffff60e.001 , 001D, 0001, F0010006

..\output\tone\source\TMSC1.1.pcm , 001D, 0001, F00B0128

..\output\tone\source\01400001.000 , 001D, 0001, 01400001

..\output\tone\source\03400001.000 , 001D, 0001, 03400001

..\output\tone\source\00000101.002 , 001D, 0002, 000000C8

..\output\tone\source\00000102.002 , 001D, 0002, 000000C9

..\output\tone\source\dollar.002 , 001D, 0002, 0000011A

..\output\tone\source\hour.002 , 001D, 0002, 0000011E

An announcement configuration file consists of multiple configuration lines. Each configuration line is divided into the following four parts by ",":

Announcement file path and name Package ID Signal ID Ann ID

The following is the description of the four parts:

Announcement file path and name

The announcement file path and name, such as ..\output\tone\ source\DTMF_0.pcm and ..\output\tone\source\fffff803.001 in the previous example, is the first part of the configuration line. It indicates the path and the content of the toneclip currently configured. The path can be the absolute path and the relative path (relative to the LMT installation path)

Package ID and Signal ID

Package ID, such as 0005 and 001D in the previous example, is the second part of the configuration line. It is a hexadecimal number with four bits. Signal ID, such as 0010, 0030 and 0001 in the previous example, is the third part of the configuration line. It is also a hexadecimal


Configuration Guide


number with four bits. For different announcement types, the MSOFTX3000 processes an announcement in different modes as follows:

− For signal tones, the MSOFTX3000 can correctly instruct the UMG8900 to play an announcement by sending different combination of Package ID and Signal ID. It is because each announcement corresponds to unique combination of Package ID and Signal ID according to protocols such as H.248. For example, 0007, 0030 indicates the dial tone, 0007, 0032 indicates the busy tone and 0007, 0037 indicates call waiting announcement.

− For non-signal tone, the MSOFTX3000 instructs the UMG8900 to play an announcement according to requirements in Appendix K of H.248. In this case, Package ID can be 001D only.

Ann ID

Ann ID, such as 00000000, F0010006, 01400001 and 0000011A in the previous example, is a hexadecimal number with eight bits. The following introduces configuration of Ann ID in different cases:

− If Package ID is not set to 001D, the configuration line indicates a signal tone. Therefore, you need not set Ann ID to a valid value. Otherwise, set Ann ID to 00000000 (invalid value).

− If Package ID is set to 001D and Signal ID is set to 0001, the configuration line indicates a fixed announcement. In this case, Ann ID needs setting to indicate a piece of fixed announcement to be played.

− If Package ID is set to 001D and Signal ID is set to 0002, the configuration line indicates a variable announcement. In this case, Ann ID needs setting to indicate a variable announcement to be played.

Tone ID Interface Parameter Between MSOFTX3000 and UMG8900 To control the announcement materials in the UMG8900, the MSOFTX3000 must send correct parameters such as Package ID, Signal ID and Ann ID to the UMG8900 through H.248.

On the MSOFTX3000 side, when you use the command ADD TONECFG to configure announcement data for intercommunicating with the UMG8900, a negotiated interface parameter Tone ID is required. For different announcements, Tone IDs are different.

The following introduces configuration of Tone ID in different cases:

To play signal tone: The MSOFTX3000 sends Package ID (not 001D) and Signal ID but does not send Ann ID, that is, the combination of Package ID and Signal ID indicates a unique signal tone. In this case, Tone ID = Package ID + Signal ID.

To play fixed announcement: When Package ID is set to 001D and Signal ID is set to 0001 (It is the value recommended in the protocol, and is different from the setting in the MSOFTX3000), the MSOFTX3000 sends Ann ID to indicate a piece of fixed announcement. In this case, Tone ID = Ann ID. In addition, Ann ID corresponds to Announcement Name (AN) in apf of H.248.

To play variable announcement: When Package ID is set to 001D and Signal ID is set to 0002, the MSOFTX3000 sends Ann ID to indicate a variable announcement. In this case, Tone ID = Ann ID. In addition, Ann ID corresponds to AN in apv of H.248.

The setting, Package ID=001D, Signal ID=0002, is used for both fixed announcement and variable announcement between the MSOFTX3000 and UMG8900 at present.



Tone ID is a hexadecimal number with eight bits. When Tone ID is Ann ID, the Tone ID encoding format complies with Huawei internal encoding rules. In this case, Tone ID consists of Service key, Language location and Announcement number. The three parts jointly identify a unique announcement that helps the UMG8900 select a correct announcement on the VPU and play the announcement for a subscriber. Figure 5-3 shows the Tone ID encoding format.

Figure 5-3 Tone ID encoding format

SS LL XXXX

(4 bits)

Language location

Service key(2 bits)

Announcement number

(2 bits)

Service key: It is a hexadecimal number with two bits indicating a service type of an announcement. For example, F0 indicates the basic service announcement and the supplementary service announcement, while others indicate the intelligent service announcement.

Language location: It is a hexadecimal number with two bits indicating the language type of an announcement. The parameter complies with Huawei internal language encoding rules. For example, 01 indicates English and 02 indicates Chinese.

Announcement number: It is a hexadecimal number with four bits indicating the serial number of an announcement.

5.2 Configuring MGW Data 5.2.1 Overview of Configuration

Configuration Relationship MGW data is an interworking data of the MSOFTX3000. It specifies the following items:

H.248 links between the MSOFTX3000 and MGWs Media connections among MGWs Path information among MGWs

While the MGW data is configured, certain key parameters defined in hardware data and office information data are used in the MGW data. These key parameters are module number of board, IP address of FE port and SPC of local office.

Table 5-2 lists the referencing relationship among the parameters.


Configuration Guide


Table 5-2 Input Parameters required for configuring MGW data

Name Defined in Source Data Category

Referenced in

ADD MGW Module number of board

ADD BRD Hardware data

ADD H248LNK

IP address of FE port

ADD FECFG Hardware data ADD H248LNK

SPC of local office SET OFI / ADD OFI Office information data

ADD H248LNK

The MGW index is defined in the MGW data. During the follow-up configuration of the signaling data, trunk data and mobile service data, this parameter is used.

Table 5-3 lists the referencing relationship among the parameters.

Table 5-3 Output parameters defined in MGW data

Name Defined in Referenced in Destination Data Category

ADD ESG Signaling data

ADD AIETG

ADD N7TG

ADD BICCTG

ADD CASTG

ADD PRATG

Trunk data

MGW index ADD MGW

ADD RANMGW Mobile service data

Preparation Before configuring the MGW data, ensure that all preparations are done as specified in Table 5-4.

Table 5-4 Configuration preparation

Number Item Remark

1 Bearer and transmission way of the H.248 protocol

It is a parameter used for interworking between the MSOFTX3000 and the MGW.

2 IP address of the MGW port It is a parameter used for interworking between the MSOFTX3000 and the MGW.



Number Item Remark

3 SPC of the MGW It is a parameter used for interworking between the MSOFTX3000 and the MGW.

4 The port number of the local UDP or SCTP at the MSOFTX3000 side


5 The port number of the local UDP or SCTP at the MGW side


6 Media stream codec algorithm that the MGW supports


7 Encryption algorithm and key that the MGW supports


8 Resource capabilities of the MGW

Through it, the MSOFTX3000 controls and allocates the resources in the MGW.

9 The network topology structure of MGWs

10 The call path plan among the MGWs.

It is used to configure the interworking data of media stream.

Configuration Steps Table 5-5 lists the steps for configuring the MGW data.

Table 5-5 Configuration steps

Step Description Command

1 Add Media Gateway. ADD MGW

2 Add H.248 link. ADD H248LNK

3 Add Internal TDM Circuit (optional). ADD INTTDM

4 Add path information between MGWs (optional).

ADD MGWPATH

5 Add media connection between MGWs. ADD MGWCONN

6 Set Bearer control protocol parameters (optional).

SET BCPARA


Configuration Guide


Parameter Referencing Relationship During the configuration, the key fields of the data tables are used as shown in Figure 5-4.

Figure 5-4 Parameter referencing relationship

ADD MGW

Transport protocol

MGW index

WMGC modulenumber

ADD H248LNK

MGW index

Transport protocol

Local IP address

ADD INTTDM

Global E1 number

MGW1 index

MGW2 index

ADD MGWPATH

MGW path ID

Source MGW index

Destination MGWindex

ADD MGWCONN

MGW1 index

MGW2 index

Inter MGWn index

5.2.2 Adding Media Gateway

Related Commands

Command Function

ADD MGW To add a media gateway

RMV MGW To remove a media gateway

MOD MGW To modify a media gateway



Command Function

LST MGW To list media gateways

Parameter Description MGW index

It specifies a unique MGW. It ranges from 0 to 299.

Transport protocol

It specifies the type of the transport protocol between the MSOFTX3000 and the MGW. The value options are as follows:

UDP protocol: It means that the structure of the protocol stack is H.248/UDP/IP. When the MSOFTX3000 interworks with the MGW through IP, it is not recommended to select UDP as the transport protocol.

SCTP protocol: It means that the structure of the protocol stack is H.248/SCTP/IP. When the MSOFTX3000 interworks with the MGW through IP, it is recommended to select SCTP as the transport protocol.

MTP3B protocol: It means that the structure of the protocol stack is H.248/MTP3B/SAAL/ATM. When the MSOFTX3000 interworks with the MGW through the ATM 155M, IMAE1 or ATM 2M, the transport protocol must be MTP3B.

WMGC module number

It specifies the module number of the WMGC board that manages the MGW. This parameter must be defined by ADD BRD before it can be used here. The function of the WMGC includes:

Managing the registration of the MGW Auditing the status of the MGW Maintaining the MGW Maintaining the H.248 link

MGW description

It identifies an MGW with a string of characters.

BCU ID

When the MSOFTX3000 interworks with an MSC server through the BICC protocol, BCU ID uniquely specifies the MGW in the BICC message. It cannot be selected at random, and should be numbered by network carriers. That is, each MGW has a unique BCU ID.

BNC characteristic

It specifies the bearer type supported by the MGW when it interworks with other MGWs. The default value is IP.

The value options are as follows:

TDM: It specifies that the PCM code stream serves as the media stream, that is, the MGWs interworks with each other over TDMIP: It specifies that the IP packet serves as the media stream, that is, the MGWs interworks with each other over IP.AAL1_Struct: It indicates that the ATM packet after the adaptation of structured AAL1 serves as the media stream.


Configuration Guide


That is, the MGWs interwork with each other over ATM. AAL1 supports the transmission of media stream that is real-time and connection-oriented. In addition, the bit rate is constant, such as the non-compressed audio or video data packet. The structured AAL1 not only supports to map an entire E1 link to ATM cells but also supports to map certain timeslots of an E1 link to ATM cells. That is, the structured AAL1 supports services at the rate of N x 64 kbit/s.

AAL2: It indicates that the ATM packet after the adaptation of AAL2 serves as the media stream. That is, the MGWs interwork with each other over ATM. The AAL2 is mainly used in the transmission of media stream that is real-time and connection-oriented. In addition, the bit rate is constant, such as the non-compressed audio or video data packet.

AAL1: It specifies that the ATM packet after the adaptation of unstructured AAL1 serves as the media stream. That is, the MGWs interwork with each other over ATM. AAL1 supports the transmission of media stream that is real-time and connection-oriented. In addition, the bit rate is constant, such as the non-compressed audio or video data packet. The unstructured AAL1 only supports to map an E1 link to ATM cells. That is, it does not support the services at the rate of N x 64 kbit/s.

Special attributes

It specifies some special attributes of the MGW.

The value options are as follows:

SDP HEX: It indicates whether the SDP packets sent by the MSOFTX3000 to the MGW are in the HEX format. Most MGWs only identify SDP packets in text format but not in hex format. Thus, when the MGW is the TMG8010 (supporting SDP packets in hex format) of Huawei, you can select this option. In other cases, you cannot select it.

No BNC characteristic: It indicates whether the H.248 protocol messages sent by the MSOFTX3000 to the MGW do not carry a BNC character field. The character field defines whether the bearer network is ATM network (The BNC character field is carried in H.248 protocol messages) or IP network (The BNC character field is not carried in H.248 protocol messages). If you select the option, the bearer network can only be the IP network. In other cases, the bearer network can be the IP, ATM or TDM network. In general, it is recommended not to select the option.

No Echo cancellation: It indicates whether the H.248 protocol messages sent by the MSOFTX3000 to the MGW do not carry an Echo canceller field. Echo canceller specifies the EC mode of the media stream such as not started, G.165 or G.168. At present, most MGWs support the Echo canceller field. Therefore, do not select this option for these MGWs.

No jitter: It indicates whether the H.248 protocol messages sent by the MSOFTX3000 to the MGW do not carry a Jitter buffer field. Jitter buffer specifies the duration (in millisecond) of the jitter buffer of the media stream. At present, most MGWs do not support the Jitter buffer field. Therefore, select this option for these MGWs.

No fax: It indicates whether the H.249 protocol messages sent by the MSOFTX3000 to the MGW do not instruct the MGW to detect the fax signal tone of the terminal devices. This parameter is reserved at present.

No modem: It indicates whether the H.249 protocol messages sent by the MSOFTX3000 to the MGW do not instruct the MGW to detect the Modem signal tone of the terminal devices. This parameter is reserved at present.

Local SDP address present: It indicates whether the Add/Modify messages carry the local IP address when the MGW modifies the local codec. When modifying the local codec, most MGWs need not have the local IP address. Select this option only when the MGW is such special GW as the MGW using waveform coding mode. In other cases, do not select this option.



Support H.248 V2 protocol: It specifies whether the MGW supports the H.248 V2 protocol. By default, the MSOFTX3000 considers the MGW not to support the H.248 V2 protocol. If the MGW supports the H.248 V2 protocol, select the option.

Not support H.248 version negotiation: It specifies whether the MGW supports the automatic H.248 version negotiation. By default, the MSOFTX3000 considers the MGW to support the automatic H.248 version negotiation. If the MGW does not support the automatic H.248 version negotiation, select the option.

Support codec rate configuration: It indicates whether the MGW supports the codec rate configuration. By default, the codec rate configuration is not supported. If the MGW supports the codec rate configuration, you can select this option.

Support Noise removing benefit local end: It indicates whether the MGW supports the function that the local end benefits from the noise removing. By default, the function is not supported. If the function is supported, you can select Support Noise removing benefit local end. If both the local and the peer ends can benefit from the noise removing, select both Support Noise removing benefit local end and Support Noise removing benefit peer end. The options of the parameter are used in the MSOFTX3000 V100R005C05 and V100R005C06 version.

Support Noise removing benefit peer end: It indicates whether the MGW supports the function that the peer end benefits from the noise removing. By default, the function is not supported. If the function is supported, you can select Support Noise removing benefit peer end. If both the local and the peer ends can benefit from the noise removing, select both Support Noise removing benefit local end and Support Noise removing benefit peer end. The options of the parameter are used in the MSOFTX3000 V100R005C05 and V100R005C06 version.

MGW attribute

It specifies the the MGW attribute to local network. Keep the default value Local office.

Domain name

It is valid only when UDP is used as the transport protocol between the MSOFTX3000 and the MGW. When the MGW sends the H.248 messages to the MSOFTX3000, this parameter specifies the value of the domain name that is carried in the Message ID field. It is used to manage the registration of the MGW and requires the negotiation with the MGW. The value type of this parameter is character string, and the maximum number of character is 63.

Device name

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. When the MGW sends the H.248 messages to the MSOFTX3000, this parameter specifies the value of the device name that is carried by the Message ID field. It is used to manage the registration of the MGW and requires the negotiation with the MGW. The value type of this parameter is character string, and the maximum number of character is 65.

Server/Client

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. This parameter specifies that the MSOFTX3000 serves as a server or a client. The default value is Server. It requires coordination with the MGW. If the MSOFTX3000 is set to Server, the MGW should be set to Client. If the MSOFTX3000 is set to Client, the MGW should be set to Server.

MTP name

It is valid only when MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW. When the MGW sends the H.248 messages to the MSOFTX3000, this parameter


Configuration Guide


specifies the value of the MTP name that is carried by the Message ID field. It is used to manage the registration of the MGW and requires the negotiation with the MGW. The value type of this parameter is character string, and the maximum number of character is 4.

Encryption type

It indicates whether the H.248 message header between the MSOFTX3000 and the MGW should be encrypted and authenticated. The default value is Not support. The value options are as follows:

MD5: Encryption is required and the MD5 algorithm is adopted. SHA1: Encryption is needed and the SHA1 algorithm is adopted.

Both the MD5 and the SHA1 algorithm are unidirectional. That is, a plain text can be encrypted, but an encrypted text cannot be decrypted.

Security parameter index

It is valid only when the H.248 messages between the MSOFTX3000 and the MGW need to be transmitted in encryption mode. This parameter, an interworking between the MSOFTX3000 and the MGW, specifies the value required by the MD5/SHA1 encryption algorithm.

Key

It is valid only when the H.248 messages between the MSOFTX3000 and the MGW need to be transmitted in encryption mode. This parameter, an interworking between the MSOFTX3000 and the MGW, specifies the key adopted by the MD5/SHA1 encryption algorithm. The value type is character string, and the maximum number of characters is 16 (in MD5 encryption algorithm) or 20 (in SHA1 encryption algorithm).

Resource capability

It specifies the resource capability of the MGW.

The resources include:

Basic tone and ordinary service voice Variable tones and intellegent service voice Sending DTMF signal tone Detecting DTMF signal tone Multi-party conversation IWF functions

EC resource ratio, TC resource ratio, IWF resource ratio, Service tone resource ratio, Multiparty resource ratio, Detect DTMF resource ratio, Send DTMF resource ratio

These parameters specify the ratio of the above resources. The value range of each parameter is from 0 to 99999. The default value of each parameter is 300. Set them according to the following principles:

If the ratio of a kind of resource is set to 0, the MGW does not provide that kind of resource or the MGW is not capable of providing that kind of resources.

If the ratio of a resource is set to an integer rather than 0, the MGW is capable of providing that kind of resource. Thus, the MGW must be capable of providing the resource. Otherwise, the MSOFTX3000 may fail to allocate the resource.

At the MSOFTX3000 side, it is recommended to set the ratio of resources to the ration within the capability of the MGW. If the parameter is set to be less than the ration which the MGW can provide, the capability of the MGW is not used fully. If the parameter is set



to be greater than the ratio which the MGW can provide, the MSOFTX3000 may fail to allocate the resources.

When a MGW requires resources through the H.248 messages, the MSOFTX3000 always prefers that kind of resources of the MGW. The MSOFTX3000 selects and allocates resources of MGWs according to their resource capabilities only when the resources of the MGW are not available.

For example, three MGWs are able to provide Detect DTMF resource. The MGW1 at most can provide A. The MGW2 at most can provide B. The MGW3 can provide C. When the MGW1 requires the Detect DTMF resources, the MSOFTX3000 always select the Detect DTMF resources of the MGW1. If the resources of the MGW1 are unavailable, the MSOFTX3000 selects the resources of the MGW2 or MGW3 according to the ratio. Thus, the probability to select the resources of the MGW2 is B / (B+C), and the probability to select the resources of the MGW3 is C / (B+C). In other cases, it can be deduced in the same way.

HR AMR rate, UMTS AMR2 rate, FR AMR rate, UMTS AMR rate

These parameters specify the AMR codec supported by the MGW.

IWF modem list

It specifies the Modem type supported by the MGW.

Codec list

It specifies the codec type supported by the MGW. Set it by the following principles:

At the MSOFTX3000 side, the codec list configured for a MGW must meet the codec capabilities supported by the MGW. Otherwise, the services of the MGW fail to operate normally.

The codec list configured for a MGW need to meet the codec capabilities supported by the MGW. If network carriers expect higher quality to voice and fax, it is recommended to select G.711A, UMTS AMR and UMTS AMR2.

Server node index

It specifies that the data record is the data of local server node or the data of assistant virtual server node. Set it according to the following principles:

If it is set to 0, the data record is the data of local server node. That is, the data record is valid only when the local server node works in standalone work mode or activated state in mutual assistance.

If it is set to an integer rather than 0, the data record is the data of virtual server node aided by the local office. That is, the data record is valid only when the local virtual server node works in activated state in mutual assistance. This parameter must be defined by ADD SRVNODE before it can be used here.

Under the 3GPP R4 networking, if the network carrier adopts the dual-homing networking such as the 1+1 or N+1, and the local MSOFTX3000 (MSC server) works as the assistant server node for an MSOFTX3000, then you must configure the dual-homing data for the local MSOFTX3000.

Assistant MGC domain name

It indicates the domain name of the spare home MGC of the MGW in dual-homing networking. It is valid only when Transport protocol is set to UDP protocol. It is used to manage the registration of the MGW. It is the same as the spare MGC address defined in the MGW. The value is of the character string type, and the maximum number of character is 63.


Configuration Guide


Assistant MGC device name

It indicates the device name of the spare home MGC of the MGW in dual-homing networking. It is valid only when Transport protocol is set to SCTP protocol. It is the same as the spare MGC address defined in the MGW. The value is of the character string type, and the maximum number of character is 65.

Assistant MGC MTP name

It indicates the MTP identity of the spare home MGC of the MGW in dual-homing networking. It is valid only when Transport protocol is set to MTP3B protocol. It is the same as the spare MGC address defined in the MGW. The value is of the character string type, and the maximum number of character is 4.

5.2.3 Adding H.248 Link

Related Commands

Command Function

ADD H248LNK To add an H.248 link

RMV H248LNK To remove an H.248 link

LST H248LNK To list H.248 links

Configuration Description Read the following description carefully before running the command.

When SCTP is used as the transport protocol between the MSOFTX3000 and the MGW, ensure that the algorithm adopted by SCTP at the MSOFTX3000 side and SCTP at the MGW side are same. By default, SCTP at the MSOFTX3000 adopts the CRC32 algorithm. If SCTP at the MGW side adopts the ADLER32 algorithm, set SCTP by SET SCTPPARA at the MSOFTX3000 side.

When MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW, you must configure the ATM signaling data and the MTP3B signaling data according to the real networking. See Chapter 6 "Configuring Signaling Transmission Data."

172.20.XXX.XXX and 172.30.XXX.XXX are the internal IP addresses used by the MSOFTX3000, (inter-subrack communication and communication between the host and the BAM). Therefore, avoid using these IP addresses when you plan the IP address of the WIFM board and the MGW.

Parameter Description MGW index

It specifies the MGW to which the MSOFTX3000 is connected. This parameter must be defined by ADD MGW before it can be used here.

Transport protocol

It specifies the type of the transport protocol between the MSOFTX3000 and the MGW. SCTP is usually used in the mobile network. It must be consistent with the parameter Transport protocol defined by ADD MGW. Otherwise, the MGW cannot register in the MSOFTX3000.



If SCTP is used as the transport protocol between the MSOFTX3000 and the MGW, you can add at most 30 H.248 links between them. If MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW, you can add only one H.248 link between them.

Local IP address

It is valid only when UDP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the IP address of the FE port. This parameter must be defined by ADD FECFG before it can be used here.

Local port number

It is valid only when UDP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the number of the UDP port that is used to communicate with the MGW. The default value is 2945.

Remote IP address 1–Remote IP address 5

They are valid only when UDP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the IP address of the MGW. The remote IP address 1 is mandatory. From the remote IP address 2 to the remote IP address 5, whether they should be defined depends on the real situation (They are mainly used for interworking with the UMG8900 of Huawei.)

Remote port number

It is valid only when UDP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the number of the UDP port that is used to communicate with the MSOFTX3000. That is, the local UDP port number at the MGW side. The default value is 2945.

Link number

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies a unique H.248 link between them. The value of this parameter ranges from 0 to 29. The principles of data configuration for the connection between the MSOFTX3000 and the UMG8900 of Huawei are as follows:

Configure multiple H.248 links between the MSOFTX3000 and the UMG8900 (at least 2). If the UMG8900 does not support the centralized distribution mechanism of IP message capsule, the number of the H.248 links should be at least twice of the number of the PPUs in the UMG8900.

All H.248 links should be allocated to each WBSG equally to implement the load-sharing mechanism.

If the UMG8900 adopts multiple subracks (including the central switching subrack), all H.248 links should work in the centralized transfer mode. That is, the OMC port in the NET in subrack 0 of the UMG8900 transfers H.248 messages centrally, and the PPU does not provide the network port.

WBSG module number

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the module number of the WBSG that processes the SCTP link protocol. This parameter must be defined by ADD BRD before it can be used here.

Local IP address 1, Local IP address 2

They are valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the IP address of the FE port that is used to communicate with the MGW. This parameter must be defined by ADD FECFG before it can be used here. The local IP address 1 is mandatory.


Configuration Guide


If the MSOFTX3000 is configured with multiple WIFM boards, you can also specify the local IP address 2. It is mainly used to support the multi-homing function based on SCTP, which can improve the reliability of the system.

Local port number

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the number of the UDP port that is used to communicate with the MGW. The default value is 2945. Set it according to the following principles:

If the MSOFTX3000 acts as the server, and multiple H.248 links exist between the MSOFTX3000 and the MGW, it is recommended that those H.248 links adopt the same local port number.

If the MSOFTX3000 acts as the client, and multiple H.248 links exist between the MSOFTX3000 and the MGW, the local port number of each H.248 link must be unique.

Since the M2UA, M3UA, IUA, H.248 and BICC protocols all adopt SCTP as the transport protocol, it is recommended to plan the range of the local port number for each protocol. Avoid allocating the same local port number for multiple protocols.

In the dual-homing mode, if the MSOFTX3000 acts as the server, it is recommended to allocate the same local port number for all H.248 links that belong to the virtual server node. The local port number for H.248 links that belong to different virtual server node cannot be same.

Remote IP address 1, Remote IP address 2

They are valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the IP address of the MGW. The local IP address 1 is mandatory.

If the MGW supports the dual-homing function based on SCTP, you can also specify the remote IP address 2, which can improve the reliability of the system.

Remote port number

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the number of the SCTP port that is used to communicate with the MSOFTX3000. That is, the local SCTP port number at the MGW side. The default value is 2945. Set it according to the following principles:

If the MGW acts as the server, and multiple H.248 links exist between the MSOFTX3000 and a MGW, those H.248 links can adopt the same remote port number.

If the MGW acts as the client, and multiple H.248 links exist between the MSOFTX3000 and a MGW, the remote port number of each H.248 link must be unique.

Maximum incoming flow of SCTP association

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the maximum incoming flow of the SCTP association. The value ranges from one to five. The default value is 1. Do not change the configuration except for any special requirements. Keep the default value.

Maximum outgoing flow of SCTP association

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the maximum outgoing flow of the SCTP association. The value ranges from one to five. The default value is 1. Do not change the configuration except for any special requirements. Keep the default value.



Maximum sending packets per second

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. When the MSOFTX3000 sends H.248 signaling messages to signaling equipment on the peer end over the H.248 link, this parameter specifies the maximum number of packets allowed to be sent by the MSOFTX3000 per second. It aims at controlling the signaling flow in the sending direction, and hence avoiding impacts on the MGW caused by the burst signaling flow from the MSOFTX3000. The value range is 0–65534 and the default value is 1500.

Maximum receiving packets per second

It is valid only when SCTP is used as the transport protocol between the MSOFTX3000 and the MGW. When the MSOFTX3000 receives H.248 signaling messages from signaling equipment on the peer end over the H.248 link, this parameter specifies the maximum number of packets allowed to be received by the MSOFTX3000 per second. It aims at controlling the signaling flow in the receiving direction, and hence avoiding impact on the MSOFTX3000 caused by the burst signaling flow from the MGW. The value range is 0–65534 and the default value is 1500.

Network indicator

It is valid only when MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the signaling network to which the SPC of that MGW belongs. The signaling network can be:

International network International standby network National network National standby network

DPC

It is valid only when MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the destination SPC of the MGW.

When MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW, you also need to configure the related ATM and MTP3B signaling data. See Chapter 6 "Configuring Signaling Transmission Data."

OPC

It is valid only when MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW. It specifies the originating SPC of the MGW.

When MTP3B is used as the transport protocol between the MSOFTX3000 and the MGW, you also need to configure the related ATM and MTP3B signaling data. For details, refer to Chapter 6 "Configuring Signaling Transmission Data." In addition, the network indicator of the OPC (defined by SET OFI or ADD OFI) should be consistent with that of the DPC (defined by ADD H248LNK). Otherwise, the H.248 link cannot work normally.

5.2.4 Adding Internal TDM Circuits (Optional)

Related commands

Command Function

ADD INTTDM To add an internal TDM circuit

RMV INTTDM To remove an internal TDM circuit


Configuration Guide


Command Function

MOD INTTDM To modify an internal TDM circuit

LST INTTDM To list internal TDM circuits

Configuration Description This configuration step is optional. Read the following description carefully before running the command.

When the MSOFTX3000 controls multiple MGWs, each MGW needs to interconnect exchanges such as BSC, RNC, MSC and PSTN. In addition, the MGWs need to interconnect with each other according to the network topology structure. If the media type is TDM, you must add TDM connection for interworking MGWs by ADD INTTDM. The principles for adding the inter-MGW connection are as follows:

Both MGWs should be controlled by the same MSOFTX3000. Both MGWs should support TDM as the bearer. If not, use MOD MGW and configure the

parameter BNC characteristic. The inter-MGW media type should support TDM. If not, use MOD SRVNODE and

configure the parameter Internal MGW media type. The connection type between two MGWs should be Not all MGW connection. If not, use

MOD SRVNODE and configure the parameter Internal MGW connection type. This command can configure only one E1 each time. If there are n E1 circuits, you must

run ADD INTTDM n times.

Parameter Description Global E1 number

It uniquely specifies one internal E1 circuit in the MSOFTX3000 configuration database. The value ranges from 0 to 3124. The system allocates a number for a new internal TDM circuit automatically. Therefore you need not specify it.

MGW1 index

It specifies the index number of the first MGW. This parameter must be defined by ADD MGW before it can be used here.

Terminal ID of MGW1 slot 0

If the E1 M of the MGW1 interconnects the E1 N of the MGW2, this parameter is used to specify the terminal ID of time slot 0 in the E1 M of the MGW1. The configuration principle is as follows:

This parameter is expressed in decimal. The value range is from 0 to 536870880. The terminal ID here must not be the same as any termination ID used by A interface

circuits, ISUP circuits, PRA circuits and CAS circuits.

MGW2 index

It specifies the index number of the second MGW. This parameter should be defined by ADD MGW before it can be used here.



Terminal ID of MGW2 slot 0

In actual cases, suppose the E1 M of the MGW1 interconnect the E1 N of the MGW2, this parameter is used to specify the terminal ID of time slot 0 in the E1 N of the MGW2.

The configuration principle is as follows:

This parameter is expressed in decimal. The value range is from 0 to 536870880. The terminal ID here must not be the same as any termination ID used by A interface

circuits, ISUP circuits, PRA circuits and CAS circuits.

5.2.5 Adding Path Information Between MGWs (optional)

Related Commands

Command Function

ADD MGWPATH To add path information between MGWs

RMV MGWPATH To remove path information between MGWs

MOD MGWPATH To modify path information between MGWs

LST MGWPATH To list path information between MGWs


When the MSOFTX3000 controls multiple MGWs, each MGW needs to interconnect exchanges such as BSC, RNC, MSC and PSTN. Besides that, the MGWs need to interconnect with each other according to the network topology structure. If the media type between MGWs is TDM, the default connection mode is Not all MGW connection, and the system chooses the communication path according to Automatic mode.

When you change the value of Internal MGW path select mode to Percent by MOD SRVNODE, you need to specify the selected percent for each path by ADD MGWPATH. Additionally, in Not all MGW connection, you need to configure the TDM connection for two contiguous MGWs by ADD INTTDM.

Parameter Description MGW path ID

It specifies one MGW path in the MSOFTX3000 configuration database. It ranges from 0 to 65535.

Source MGW index

It specifies the index number of the source MGW. This parameter should be defined by ADD MGW before it can be used here.

The path information configured by ADD MGWPATH is unidirectional. For example, you set MGW A to the source MGW and set MGW B to the destination MGW. Therefore, you must only specify the path information of A→B. If you want to specify the path information of B→A,


Configuration Guide


you must use ADD MGWPATH and set MGW B to the source MGW and set MGW A to the destination MGW.

Destination MGW index

It specifies the index number of the destination MGW. This parameter must be defined by ADD MGW before it can be used here.

Inter MGW1 index–Inter MGW3 index

In the path from the source MGW to the destination MGW, these three parameters specify the index number for each MGW that is used for transit call. The three parameters must be defined by ADD MGW before it can be used here. Set them according to the following principles:

When the straight TDM circuit exists between the source MGW and the destination MGW, and you need to configure the straight path between the two MGWs, you cannot enter any inter MGW index number.

When the straight TDM circuit exists between the source MGW and the destination MGW, and you need to configure the alternative path between the two MGWs, you need to enter the corresponding inter MGW index number.

When no straight TDM circuit exists between the source MGW and the destination MGW, you must enter the corresponding inter MGW index number.

Path selection percentage

It specifies the selected percentage for the MGW path defined by ADD MGWPATH. Its value rangs from 0 to 100. The default value is 1. If three paths for interworking media stream exist between two MGWs, and the selection percentage of each path is A, B and C, this parameter is used as follows:

The selection percentage of the first path is A/(A+B+C). The selection percentage of the second path is B/(A+B+C). The selection percentage of the third path is C/(A+B+C). In other cases, it can be deduced in the same way.

By default, when the connection type between two MGWs is Not all MGW connection, and two or more paths exist between the two MGWs, the system chooses a path in Automatic mode. That is, the system always prefers the shortest path. If multiple shortest paths exist, the system conducts the rotate selection. If all the shortest paths are unavailable, the system selects the path second to the short path. In other cases, it can be deduced in the same way.

5.2.6 Adding Media Connection Between MGWs (optional)

Related Commands

Command Function

ADD MGWCONN To add a media connection between MGWs

RMV MGWCONN To remove a media connection between MGWs

LST MGWCONN To list media connections between MGWs




When the MSOFTX3000 controls several MGWs, each MGW has to interwork with the BSC, RNC, MSC and PSTN switch in the access layer. In addition, the MGWs must interwork with each other for media communication according to a certain topology in the bearer layer. You can add an inter-gateway media connection with ADD MGWCONN only when the media type between MGWs is IP or ATM, and ring MGW connection mode is adopted.

Parameter Description MGW1 index, MGW2 index

They specify the indexes of the two MGWs between which a media connection is to be set up. This parameter is defined by ADD MGW before it can be used here. Note that the original MGW and destination MGW are not designated. In this command, either can be the original one or destination one.

5.2.7 Setting Bearer Control Protocol Parameter (Optional)

Related Commands

Command Function

SET BCPARA To set a bearer control protocol parameter

LST BCPARA To list bearer control protocol parameters


In the 3GPP R4 (or later versions) networking architecture, the Mc interface, between the MSC server and MGW, adopts H.248, which is a bearer control protocol. The protocol is used for the MSC server to communicate with the MGW, and helps the MSC server control the MGW. In actual networking, you may need to adjust some operation parameters of H.248 with SET BCPARA to ensure normal interworking between the MSOFTX3000 (MSC server) and MGW and meet some special requirements, because of complexity of bearer networks or different understandings on some details of H.248.

Do not modify operation parameters of H.248 with SET BCPARA without special requirements of network carriers. If it is necessary, contact Huawei technical support team.

Parameter Description Maximum number of link reselections

This parameter is valid only when the User Datagram Protocol (UDP) is used to send H.248 messages between the MSOFTX3000 and MGW.


Configuration Guide


When the MSOFTX3000 times out in repeatedly sending an H.248 message to the MGW through a UDP link (maximum times of resending a message is determined by Maximum number of single UDP link retransmissions of the command), the parameter defines the maximum times of reselecting UDP links for sending the same H.248 message. Its value ranges from 0 to 5, and the default value is 0.

Note that, if the H.248 message between the MSOFTX3000 and the MGW is transmitted through the SCTP protocol or the MTP3B protocol, Maximum number of link reselections is 0 and cannot be modified, that is, link reselection is not allowed. If the H.248 message between the MSOFTX3000 and the MGW is transmitted through the UDP protocol, the recommended value of Maximum number of link reselections is 5.

Maximum number of UDP link status checks

This parameter is valid only when the UDP protocol is used to send H.248 messages between the MSOFTX3000 and MGW.

When the MSOFTX3000 sends a heartbeat message to the MGW, and the MSOFTX3000 does not receive the related response from the MGW within the specified time (determined by transaction timer duration), the parameter defines the maximum times of resending the heartbeat message from the MSOFTX3000 to the MGW. Its value ranges from 1 to 5, and the default value is 2.

Maximum number of single UDP link retransmissions

This parameter is valid only when the UDP protocol is used to send H.248 messages between the MSOFTX3000 and MGW.

When the MSOFTX3000 sends an H.248 message to the MGW through a UDP link, and the MSOFTX3000 does not receive the related response from the MGW within the specified time (determined by transaction timer duration), the parameter defines the maximum times of resending the same H.248 message through the UDP link from the MSOFTX3000 to the MGW. Its value ranges from 0 to 255, and the default value is 5.

The relation between Maximum number of link reselections of the command and the parameter: Suppose Maximum number of link reselections is set to M and Maximum number of single UDP link retransmissions is set to N, when the MSOFTX3000 fails to send an H.248 message to the MGW through a UDP link, the total number of times of resending the same H.248 message is (M + 1) x N.

Transaction timer (ms)

When the MSOFTX3000 sends an H.248 message to the MGW, the parameter defines the maximum period during which the MSOFTX3000 waits for the related response from the MGW. Its value ranges from 0 to 99999999 in unit of ms and default value is 3000.

If not receiving the related response of the H.248 message within the specified time from the MGW, the MSOFTX3000 enables related message retransmission mechanisms.

Maximum retransmission timer (ms)

When the MSOFTX3000 enables related message retransmission mechanisms and needs to resend an H.248 message to the MGW from time to time, the parameter defines the maximum interval of retransmission. Its value ranges from 0 to 99999999 in unit of ms and default value is 4000.

Minimum retransmission timer (ms)

When the MSOFTX3000 enables related message retransmission mechanisms and needs to resend an H.248 message to the MGW time after time, the parameter defines the minimum



interval of retransmission. Its value ranges from 0 to 99999999 in unit of ms and default value is 3000.

Long timer (ms)

When the MGW sends a response to the MSOFTX3000, the parameter defines the maximal period during which the MSOFTX3000 buffers the response in the memory. Its value ranges from 0 to 99999999 in unit of ms and default value is 30000.

Response reserved timer (ms)

When the MSOFTX3000 sends an H.248 message and the MGW returns a Pending message to the MSOFTX3000, the parameter defines the maximum period during which the MSOFTX3000 needs to wait for the related response of the H.248 message from the MGW. Its value ranges from 0 to 65535 in unit of ms and default value is 4000.

MGW detection timer (ms)

It is reserved.

MGW registration timer (ms)

It is reserved.

Periodic audit timer (ms)

It is reserved.

Assist MGC IP address

It specifies the IP address of the standby MSC server which controls the MGW. The parameter is not used at present.

BC software parameter 0–BC software parameter 9

It is reserved.

5.3 Configuring Announcement Data 5.3.1 Adding Tone ID Configuration

Related Commands

Command Function

ADD TONECFG To add tone ID configuration

RMV TONECFG To remove tone ID configuration

MOD TONECFG To modify tone ID configuration

LST TONECFG To list tone ID configuration


Configuration Guide



To improve the flexibility for the MSOFTX3000 to control the announcement, the command ADD TONECFG is used to configure the mapping between Tone ID on the MSOFTX3000 side (internal Tone ID) and Tone ID on the UMG8900 side (external Tone ID).

By default, the mapping between Tone ID on the MSOFTX3000 side (except the reserved announcement) and Tone ID on the UMG8900 side has been configured during the system initialization. You can run the command LST TONECFG to query the mapping configuration, which can satisfy most requirements of playing the signal tone, the basic service announcement and the supplementary service announcement. Therefore, generally, you need not carry out the command ADD TONECFG. You must run the command ADD TONECFG or MOD TONECFG to configure the parameters only when there are some special requirements of network carriers. For example, a network carrier needs to add the mapping of Tone ID or modify the default language type of an announcement.

Parameter Description Tone ID

Tone ID, also internal announcement ID, specifies the announcement encoding of the signal tone, fixed announcement or variable announcement in the MSOFTX3000. Contents in brackets indicate meanings of the tone ID.

MGW tone ID

MGW tone ID, also external announcement ID, specifies the announcement encoding of the signal tone or announcement on the MGW side (such as the UMG8900). It is an interworking parameter between the MSOFTX3000 and MGW.

MGW tone ID is a hexadecimal number with eight bits. From the first bit to the last bit (that is, left through right), it consists of three parts: service key (two bits), language location (two bits), and announcement number (four bits). All of the three parts indicate a piece of announcement and instruct the UMG8900 to play an announcement obtained from the VPU, that is, the UMG8900 plays the specified announcement for a subscriber. For example, F0010135 indicates the call waiting tone. From the first bit to the last bit, the service key F0 indicates the basic service announcement or the supplementary service announcement; the language location 01 indicates English; the announcement number 0135 indicates the call waiting tone. Note that the language location in MGW tone ID is not the field value sent to the UMG8900 by the MSOFTX3000, that is, the language location is for reference only. The field value of the language location is determined by such parameters as Language 1 and Language 2 in the command.

MGW tone content

It specifies the content of an MGW tone. The field type is character string.

Use dummy terminal

It is an interworking parameter between the MSOFTX3000 and the MGW, determines whether the MSOFTX3000 supports the dummy terminal function during the signaling process of instructing the MGW to play an announcement. That is to say, the parameter determines whether to support the seamless handover. The default value is Yes.

For example, instructed by the MSOFTX3000 through H.248, the MGW is playing an announcement (not signal tone) for a mobile subscriber. If the mobile subscriber hands over and



Use dummy terminal is set to Yes, the mobile subscriber can hear the continual announcement (in this case, the MGW also needs to support the dummy terminal function. Otherwise, the mobile subscriber cannot hear the continual announcement).

Use dummy terminal is set to No, the mobile subscriber hears the announcement from the beginning.

Number of cycles

The parameter specifies the times of playing an announcement. The parameter, carried in the apf/apv message, is sent to the MGW through H.248 by the MSOFTX3000. The value ranges from 1 to 65535 and the default value is 2.

Duration (sec)

The parameter specifies the duration of an announcement to be played. The parameter, carried in the position of the field DI (Announcement Direction) in the apf/apv message, is sent to the MGW through H.248 by the MSOFTX3000. The value, in unit of second, ranges from 0 to 655 and the default value is 0.If it is set to 0, the MGW plays an announcement for the times that the MSOFTX3000 requires.

Language 1–Language 5

The parameter specifies the language of an announcement. Set the parameters according to the following principles:

If only one language is involved in an announcement, define Language 1 only. In this case, when the MSOFTX3000 sends an announcement indication to the MGW through H.248, only one announcement information unit is carried in the message. For the announcement information unit, the language location field is the value set for Language 1.

If two languages are involved in an announcement, define both Language 1 and Language 2. In this case, when the MSOFTX3000 sends an announcement indication to the MGW through H.248, two announcement information units are carried in the message. For the first announcement information unit, the language location field is the value set for Language 1. For the second announcement information unit, the language location field is the value set for Language 2.

The same rule applies to other cases.

Note that the binary code of Language location, related to Language, complies with Huawei internal rules. The system automatically searches the configuration database for the binary code, so you need not configure it. For example, 01 stands for English, 02 for Chinese, 03 for German and 08 for Russian.

5.3.2 Adding Tone Playing by LAI Configuration

Related Commands

Command Function

ADD LAIPT To add tone playing by LAI configuration

RMV LAIPT To remove tone playing by LAI configuration

MOD LAIPT To modify tone playing by LAI configuration

LST LAIPT To list tone playing by LAI configuration


Configuration Guide



In nations or areas that practice Islam, mobile network carriers might want to play the prayer time announcement of an area for mobile subscribers according to the location area where the subscriber is locating, when they dial a special service number. For example, the prayer time announcement might be "The first prayer time is xx:xx a.m., the second prayer time is xx:xx a.m., and …".

To enable the prayer time playing function, perform the following steps:

Step 1 Set the announcement index with ADD LAIPT.

Step 2 Add a location area with ADD LAIGCI or ADD LAISAI, and set Tone playing index to a value defined with ADD LAIPT.

Step 3 Add a special service number with ADD CNACLD and set DN processing flag to Yes.

Step 4 Add call prefix processing data with ADD PFXPRO. To enable the prayer time playing function, set Call prefix to the special service number added in the previous step, Tone playing mode to Play tone, and Tone type to Play tone by location area.

----End

Parameter Description Tone playing index

The parameter specifies a unique announcement index in the MSOFTX3000 configuration database. The parameter is used in the command ADD LAIGCI or ADD LAISAI. The value ranges from 0 to 254.

Tone 1–Tone 40

Tone 1–Tone 40, an interworking parameter between the MSOFTX3000 and the MGW, specifies the code of an announcement on the MGW side (such as the UMG9800). Therefore, "Tone" means the MGW tone ID. The default value is FFFFFFFF which indicates an invalid parameter.

MGW tone ID is a hexadecimal number with eight bits. From the first bit to the last bit (that is, left through right), it consists of three parts: service key (two bits), language location (two bits), and announcement number (four bits). All of the three parts indicate a piece of announcement and instruct the UMG8900 to play an announcement obtained from the VPU, that is, the UMG8900 plays the specified announcement for a subscriber. For example, F0010136 stands for 0 (a number of the variable announcement). From the first bit to the last bit, the service key is F0 (indicating basic service announcement or supplementary service announcement), the language location is 01 (indicating English), the announcement number is 0136. The combination of the three parts stands for 0 (a number of the variable announcement). On the UMG9800 side, the mapping between the MGW tone ID and announcements is as follows:

F0010136–F001013F: numbers 0–9 F0010140–F0010149: numbers 10–19 F001014A–F0010153: numbers 20–29 F0010154–F001015D: numbers 30–39 F001015E–F0010167: numbers 40–49



F0010168–F0010171: numbers 50–59 F0010172: second (time) F0010173: minute (time) F0010174: hour (time) F0010175: point (time) F0010176: day (date) F0010177: month (date) F0010178: year (date) F0010179: morning (time period) F001017A: noon (time period) F001017B: afternoon (time period) F001017C: evening (time period) F001017D: night (time period) F001017E: early morning (time period) F001017F: January (month) F0010180: February (month) F0010181: March (month) F0010182: April (month) F0010183: May (month) F0010184: June (month) F0010185: July (month) F0010186: August (month) F0010187: September (month) F0010188: October (month) F0010189: November (month) F001018A: December (month) F001018B: today is (special announcement) F001018C: The first prayer time today is (special announcement) F001018D: the second prayer time is (special announcement) F001018E: the third prayer time is (special announcement) F001018F: the fourth prayer time is (special announcement) F0010190: the fifth prayer time is (special announcement)

The announcement played for mobile subscribers is an announcement sequence configured depending on the command. The announcement sequence, strictly complying with the command, is combination of a serial of announcement elements (40 to the maximal) starting from Tone 1.For example, an announcement sequence is from Tone 1 to Tone 5, and announcement elements are F001018C, F001013B, F0010174, F0010136 and F0010173, so that the announcement played for mobile subscribers is "The first prayer time today is 5:00".

Note that in an announcement sequence, all announcement elements after FFFFFFFF are regarded as invalid parameters by default, that is, an announcement sequence cannot contain the invalid parameter (FFFFFFFF). For example, an announcement contains Tone 1–Tone 6. The announcement elements from the first to the last are F001018C, FFFFFFFF, F001013B, F0010174, F0010136, F0010173. In this case, only Tone 1 can be played, that is, subscribers can hear "The first prayer time today is" only.


Configuration Guide


5.3.3 Modifying Mapping Between Default Cause Value and Tone ID

Related Commands

Command Function

MOD CAUSETONE To modify mapping between default cause value and Tone ID

LST CAUSETONE To list mapping between default cause value and Tone ID


For any call, that has been successful or failed, when the MSOFTX3000 releases it, the call processing software of the MSOFTX3000 always receives a release cause code automatically generated by the local office or sent by another office through inter-office signaling.

By default, the mapping between all release cause codes and Tone IDs has been preset during the system initialization. Therefore, for each release cause code, the MSOFTX3000 announcement control software can find a corresponding Tone ID in the configuration database. Then the MSOFTX3000 instructs the UMG8900 to play an announcement for callers according to the Tone ID and prompt the current status of the call. Therefore, if a call is failed to be connected, the caller hears the announcement played according to a specific release cause code (failure cause code) instead of the busy tone. In this case, the call completion rate is effectively increased.

For example, for a call with the release cause code as No reply from mobile subscriber, the default announcement is "Mobile callee not answer tone"; for a call with the release cause code as No free circuit, the default announcement is "Invalid tone" (that is, no announcement is played).If network carriers want to modify the mapping between a release cause code and Tone ID, carry out the command MOD CAUSETONE to reconfigure.

Parameter Description Failure cause code

The parameter specifies the specific cause of releasing a call. Note that the specified Failure cause code must completely matches the release cause code generated by the local office or sent from another office to the local office through the inter-office signaling. If the release cause code cannot be correctly distinguished, enable the corresponding interface trace function to obtain the correct release cause code.

Tone type

Tone type, related to Failure cause code, specifies an announcement played for a mobile subscriber by the MGW under the control of the MSOFTX3000.The parameter, actually, is the announcement code of the signal tone, the fixed announcement and the variable announcement in the MSOFTX3000. The mapping between MGW tone ID on the MGW side (such as the UMG8900) and the parameter is preset during the system initialization, or added or modified with ADD TONECFG or MOD TONECFG.



5.3.4 Adding Mapping Between Release Cause Value and Tone ID

Related Commands

Command Function

ADD CST To add mapping between release cause value and Tone ID

RMV CST To remove mapping between release cause value and Tone ID

MOD CST To modify mapping between release cause value and Tone ID

LST CST To list mapping between release cause value and Tone ID


If you configure a service check data for a call prefix with ADD SRVCHK and ADD CNACLD, when a local mobile subscriber dials the call prefix, the MSOFTX3000 checks the service attribute of the local mobile subscriber according to the service check data. If the subscriber passes the check, then the MSOFTX3000 allows the call to be connected. If the subscriber does not pass the check, the MSOFTX3000 releases the call and generate Disconnection Cause differing from a common Failure cause code.

During the system initialization, the mapping between Disconnection cause and Tone ID is not preset. Therefore, for the call release due to the service check failure, the MSOFTX3000 does not instruct the MGW to play an announcement for a caller according to Disconnection cause. Therefore, the MSOFTX3000 automatically converts Disconnection cause into Failure cause code according to the preset mapping, and then instructs the MGW to play an announcement for the caller according to the mapping between Failure cause code and Tone ID.

If a network carrier needs the MGW to play an announcement according to Disconnection cause generated through the service check, add the mapping between Disconnection cause and Tone ID with ADD CST. For example, for a call with Disconnection cause as CFU-Prohibited, if a network carrier wants the MGW to play the call forwarding restriction tone, you must run the command ADD CST to add the mapping between Disconnection cause and Tone ID.

Parameter Description Disconnection cause

The parameter specifies the specific cause of a call release due to the service check failure. Actually, the specified Disconnection cause corresponds to Service check type set through the command ADD SRVCHK. Therefore, if the service check data is configured for a call prefix with ADD SRVCHK and ADD CNACLD, when a local mobile subscriber dials the call prefix, but the subscriber does not pass the check, the MSOFTX3000 releases the call and generate a disconnection cause, and the disconnection cause is the related service type.

Tone type

Tone type, related to Disconnection cause, specifies an announcement played for a mobile subscriber by the MGW under the control of the MSOFTX3000.


Configuration Guide


The parameter, actually, is the announcement code of the signal tone, the fixed announcement and the variable announcement in the MSOFTX3000. The mapping between MGW tone ID on the MGW side (such as the UMG8900) and the parameter is preset during the system initialization, or added or modified with ADD TONECFG or MOD TONECFG.

01-05 Configuring MGW Data

Documents