Feature Description - (V200R008C02 01, NGN)

HUAWEI UMG8900 Universal Media Gateway
V200R008C02
Feature Description
Issue 01
Date 2010-01-12
Huawei Proprietary and Confidential

Copyright © Huawei Technologies Co., Ltd.
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any
assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Proprietary and Confidential

Feature Description Contents
Contents
About This Document.....................................................................................................................1

1 Basic Services..............................................................................................................................1-1
1.1 Overview of Basic Services............................................................................................................................1-2
1.2 Availability of Basic Services.........................................................................................................................1-2
1.3 Principle and Flow of Basic Services..............................................................................................................1-3
1.3.1 Voice Services........................................................................................................................................1-3
1.3.2 Data Services........................................................................................................................................1-11
1.4 Data Configuration of Basic Services...........................................................................................................1-13
1.5 Protocol and Specification of Basic Services................................................................................................1-14
2 UAM-Accessed Narrowband User Service...........................................................................2-1

2.1 Overview of the UAM-Accessed Narrowband User Service..........................................................................2-2
2.2 Availability of the UAM-Accessed Narrowband User Service......................................................................2-3
2.3 Principle and Flow of the UAM-Accessed Narrowband User Service...........................................................2-4
2.4 Data Configuration of the UAM-Accessed Narrowband User Service..........................................................2-4
2.5 Protocol and Specification of the UAM-Accessed Narrowband User Service...............................................2-9
3 Videotelephony Service............................................................................................................3-1
3.1 Overview of the Videotelephony Service.......................................................................................................3-2
3.2 Availability of the Videotelephony Service....................................................................................................3-2
3.3 Principle and Flow of the Videotelephony Service.........................................................................................3-3
3.4 Configuring the Videotelephony Service........................................................................................................3-6
3.5 Protocol and Specification of the Videotelephony Service.............................................................................3-8
4 Voice Codec.................................................................................................................................4-1
4.1 Overview of Voice Codec...............................................................................................................................4-2
4.2 Availability of Voice Codec............................................................................................................................4-4
4.3 Principle and Flow of Voice Codec ...............................................................................................................4-4
4.3.1 G.711 A/Mu Codec................................................................................................................................4-5
4.3.2 G.723.1 Codec........................................................................................................................................4-5
4.3.3 G.726 Codec...........................................................................................................................................4-6
4.3.4 G.729A Codec........................................................................................................................................4-6
4.3.5 DTMF Signal Transmission and Detection Through RFC2833............................................................4-7
4.4 Data Configuration of Voice Codec................................................................................................................4-7
4.5 Protocol and Specification of Voice Codec....................................................................................................4-8
Issue 01 (2010-01-12) Huawei Proprietary and Confidential i

Contents Feature Description
5 Voice Quality Enhancement.................................................................................................... 5-1

5.1 Overview of Voice Quality Enhancement.......................................................................................................5-2
5.2 Availability of Voice Quality Enhancement...................................................................................................5-3
5.3 Principle and Flow of Voice Quality Enhancement........................................................................................5-4
5.3.1 Electrical Echo Cancellation..................................................................................................................5-5
5.3.2 Acoustic Echo Cancellation...................................................................................................................5-6
5.3.3 Voice Quality Enhancement...................................................................................................................5-6
5.3.4 Comfort Noise Generation.....................................................................................................................5-7
5.3.5 Voice Activity Detection........................................................................................................................5-7
5.3.6 Packet Loss Concealment.......................................................................................................................5-8
5.3.7 IP Jitter Buffer........................................................................................................................................5-8
5.4 Data Configuration of Voice Quality Enhancement ......................................................................................5-9
5.5 Protocol and Specification of Voice Quality Enhancement .........................................................................5-10
6 Narrowband Common Channel Signaling Adaptation......................................................6-1

6.1 Overview of Narrowband Common Channel Signaling Adaptation ..............................................................6-2
6.2 Availability of Narrowband Common Channel Signaling Adaptation ..........................................................6-3
6.3 Principle and Flow of Common Channel Signaling Adaptation ....................................................................6-4
6.3.1 64-kbit/s MTP2-M2UA Signaling Gateway..........................................................................................6-5
6.3.2 64-kbit/s MTP3-M3UA Signaling Gateway..........................................................................................6-7
6.3.3 2-Mbit/s MTP2-M2UA Signaling Gateway...........................................................................................6-9
6.3.4 2-Mbit/s MTP3-M3UA Signaling Gateway.........................................................................................6-11
6.3.5 IUA-Based PRI Message Transfer ......................................................................................................6-13
6.3.6 V5UA-Based LAPV5 Message Transfers ...........................................................................................6-15
6.4 Data Configuration of Narrowband Common Channel Signaling Adaptation.............................................6-17
6.4.1 Data Configuration of 64-kbit/s MTP2-M2UA Signaling Gateway....................................................6-18
6.4.2 Data Configuration of 64-kbit/s MTP3-M3UA Signaling Gateway....................................................6-20
6.4.3 Data Configuration of 2-Mbit/s MTP2-M2UA Signaling Gateway....................................................6-22
6.4.4 Data Configuration of 2-Mbit/s MTP3-M3UA Signaling Gateway....................................................6-24
6.4.5 Data Configuration of IUA-Based PRI Message Transfer...................................................................6-27
6.4.6 Data Configuration of V5UA-Based LAPV5 Message Transfer ........................................................6-29
6.5 Protocol and Specification of Narrowband Common Channel Signaling Adaptation..................................6-30
7 Channel Associated Signaling Adaptation...........................................................................7-1

7.1 Overview of Channel Associated Signaling Adaptation ................................................................................7-2
7.2 Availability of Channel Associated Signaling Adaptation ............................................................................7-3
7.3 Principle and Flow of Channel Associated Signaling Adaptation .................................................................7-3
7.4 Data Configuration of Channel Associated Signaling Adaptation .................................................................7-6
7.5 Protocol and Specification of Channel Associated Signaling Adaptation .....................................................7-8
8 TDM Semi-permanent Connections...................................................................................... 8-1

8.1 Overview of TDM Semi-permanent Connections..........................................................................................8-2
8.2 Availability of TDM Semi-permanent Connections.......................................................................................8-3
8.3 Principle and Flow of TDM Semi-permanent Connections............................................................................8-3
ii Huawei Proprietary and Confidential Issue 01 (2010-01-12)

8.4 Data Configuration of TDM Semi-permanent Connections...........................................................................8-5

8.5 Protocol and Specification of TDM Semi-permanent Connections..............................................................8-10
9 Announcement Playing and Digit Collecting......................................................................9-1

9.1 Overview of Announcement Playing and Digit Collecting............................................................................9-2
9.2 Availability of Announcement Playing and Digit Collecting.........................................................................9-5
9.3 Principle and Flow of Announcement Playing and Digit Collecting..............................................................9-6
9.3.1 DTMF Code Detecting and Sending......................................................................................................9-6
9.3.2 Basic Tone Playing.................................................................................................................................9-6
9.3.3 Intelligent Tone Playing.........................................................................................................................9-7
9.3.4 Local Language Adaptation...................................................................................................................9-7
9.3.5 Dynamic Tone File Loading..................................................................................................................9-8
9.3.6 Non-Customized Color Ringback Tone.................................................................................................9-8
9.4 Data Configuration of Announcement Playing and Digit Collecting.............................................................9-8
9.5 Protocol and Specification of Announcement Playing and Digit Collecting..................................................9-9
10 Syntax Adaptation..................................................................................................................10-1
10.1 Overview of Syntax Adaptation..................................................................................................................10-2
10.2 Availability of Syntax Adaptation...............................................................................................................10-4
10.3 Loading a Syntax Adaptation Script...........................................................................................................10-4
10.4 Rolling Back a Syntax Adaptation Script...................................................................................................10-9
10.5 Checking the Syntax Adaptation Script....................................................................................................10-10
10.6 Querying the Syntax Adaptation Script....................................................................................................10-12
10.7 Protocol and Specification of Syntax Adaptation.....................................................................................10-13
11 Multi-Level Overload Control.............................................................................................11-1

11.1 Overview of Multi-Level Overload Control...............................................................................................11-2
11.2 Availability of Multi-Level Overload Control............................................................................................11-3
11.3 Principle and Flow of Multi-Level Overload Control.................................................................................11-3
11.4 Configuring Congestion and Overload Protection for the System..............................................................11-4
11.5 Protocol and Specification of Multi-Level Overload Control.....................................................................11-5
12 IP Interface Protection...........................................................................................................12-1
12.1 Overview of IP Interface Protection............................................................................................................12-2
12.2 Availability of IP Interface Protection........................................................................................................12-3
12.3 Implementation Principles and Service Flow of IP Interface Protection....................................................12-4
12.3.1 FE Interface Protection.......................................................................................................................12-7
12.3.2 GE Interface Protection......................................................................................................................12-9
12.3.3 IP Enhanced Fault Detection BFD...................................................................................................12-10
12.3.4 Route Backup...................................................................................................................................12-12
12.4 Data Configuration of IP Interface Protection .........................................................................................12-14
12.4.1 Data Configuration of BFD..............................................................................................................12-14
12.4.2 Data Configuration of Route Backup...............................................................................................12-15
12.5 Protocol and Specification of IP Interface Protection ..............................................................................12-16
13 SDH/SONET Interface Protection......................................................................................13-1
Issue 01 (2010-01-12) Huawei Proprietary and Confidential iii

13.1 Overview of SDH/SONET Interface Protection.........................................................................................13-2

13.2 Availability of SDH/SONET Interface Protection......................................................................................13-2
13.3 Principle and Flow of SDH/SONET Interface Protection .........................................................................13-3
13.4 Data Configuration of SDH/SONET Interface Protection..........................................................................13-5
13.5 Protocol and Specification of SDH/SONET Interface Protection ..............................................................13-8
14 StandAlone..............................................................................................................................14-1
14.1 Overview of StandAlone.............................................................................................................................14-2
14.2 Availability of StandAlone .........................................................................................................................14-3
14.3 Principle and Flow of StandAlone..............................................................................................................14-4
14.3.1 UAM StandAlone...............................................................................................................................14-4
14.3.2 V5 StandAlone...................................................................................................................................14-6
14.3.3 StandAlone Bill..................................................................................................................................14-7
14.4 Data Configuration of StandAlone............................................................................................................14-10
14.5 Protocol and Specification of StandAlone ...............................................................................................14-12
15 IP QoS.......................................................................................................................................15-1
15.1 Overview of IP QoS....................................................................................................................................15-2
15.2 Availability of IP QoS.................................................................................................................................15-2
15.3 Principle and Flow of IP QoS ....................................................................................................................15-3
15.3.1 ToS DSCP..........................................................................................................................................15-3
15.3.2 VLAN Priority....................................................................................................................................15-4
15.4 Data Configuration of IP QoS.....................................................................................................................15-5
15.4.1 Configuring the DiffServ Function....................................................................................................15-5
15.4.2 Configuring the VLAN Priority Function..........................................................................................15-5
15.5 Protocol and Specification of IP QoS.........................................................................................................15-6
16 RTP Multiplexing...................................................................................................................16-1
16.1 Overview of RTP Multiplexing...................................................................................................................16-2
16.2 Availability of RTP Multiplexing...............................................................................................................16-3
16.3 Configuring RTP Multiplexing...................................................................................................................16-4
16.4 Protocol and Specification of RTP Multiplexing......................................................................................16-16
17 IVCP..........................................................................................................................................17-1
17.1 Overview of IVCP.......................................................................................................................................17-2
17.2 Availability of IVCP...................................................................................................................................17-3
17.3 Configuring IVCP on the IP over E1 Interface...........................................................................................17-4
17.4 Protocol and Specification of IVCP............................................................................................................17-8
18 NTP Network Time................................................................................................................18-1

18.1 Overview of NTP Network Time................................................................................................................18-2
18.2 Availability of NTP Network Time............................................................................................................18-3
18.3 Principle and Flow of NTP Network Time.................................................................................................18-3
18.4 Data Configuration of NTP Network Time.................................................................................................18-6
18.5 Protocol and Specification of NTP Network Time ....................................................................................18-7
iv Huawei Proprietary and Confidential Issue 01 (2010-01-12)

19 GPS Clock Synchronization.................................................................................................19-1

19.1 Overview of GPS Clock Synchronization...................................................................................................19-2
19.2 Availability of GPS Clock Synchronization...............................................................................................19-2
19.3 Principle and Flow of GPS Clock Synchronization....................................................................................19-3
19.4 Data Configuration of GPS Clock Synchronization...................................................................................19-4
19.5 Protocol and Specification of GPS Clock Synchronization........................................................................19-5
20 VMGW.....................................................................................................................................20-1
20.1 Overview of VMGW...................................................................................................................................20-2
20.2 Availability of VMGW...............................................................................................................................20-3
20.3 Principle and Flow of VMGW....................................................................................................................20-4
20.4 Data Configuration of VMGW.................................................................................................................20-10
20.5 Protocol and Specification of VMGW......................................................................................................20-11
21 MGC Dual Homing...............................................................................................................21-1

21.1 Overview of MGC Dual Homing................................................................................................................21-2
21.2 Availability of MGC Dual Homing............................................................................................................21-3
21.3 Principle and Flow of MGC Dual Homing.................................................................................................21-3
21.4 Data Configuration of MGC Dual Homing.................................................................................................21-6
21.5 Protocol and Specification of MGC Dual Homing ....................................................................................21-9
22 SCTP Multi-homing..............................................................................................................22-1
22.1 Overview of SCTP Multi-homing...............................................................................................................22-2
22.2 Availability of SCTP Multi-homing...........................................................................................................22-4
22.3 Principle and Flow of SCTP Multi-homing................................................................................................22-4
22.4 Data Configuration of SCTP Multi-homing................................................................................................22-6
22.5 Protocol and Specification of SCTP Multi-homing....................................................................................22-9
23 IPSec..........................................................................................................................................23-1
23.1 Overview of IPSec......................................................................................................................................23-2
23.2 Availability of IPSec...................................................................................................................................23-2
23.3 Principle and Flow of IPSec........................................................................................................................23-3
23.4 Configuring IPSec ......................................................................................................................................23-5
23.5 Protocol and Specification of IPSec............................................................................................................23-7
24 SSH............................................................................................................................................24-1
24.1 Overview of SSH .......................................................................................................................................24-2
24.2 Availability of SSH.....................................................................................................................................24-2
24.3 Configuring SSH.........................................................................................................................................24-3
24.4 Protocol and Specification of SSH ...........................................................................................................24-14
25 Operation and Maintenance................................................................................................25-1

25.1 Overview of Operation and Maintenance...................................................................................................25-2
25.2 Availability of Operation and Maintenance................................................................................................25-2
25.3 Operation of Operation and Maintenance ..................................................................................................25-3
25.3.1 Fault Management..............................................................................................................................25-3
Issue 01 (2010-01-12) Huawei Proprietary and Confidential v

25.3.2 Configuration Management................................................................................................................25-5

25.3.3 Performance Management..................................................................................................................25-7
25.3.4 Security Management.......................................................................................................................25-16
25.3.5 Device Management.........................................................................................................................25-22
26 Time Localization...................................................................................................................26-1
26.1 Overview of Time Localization..................................................................................................................26-2
26.2 Availability of Time Localization...............................................................................................................26-2
26.3 Configuring the Time Localization Function..............................................................................................26-3
27 Offline Test.............................................................................................................................27-1
27.1 Overview of Offline Test............................................................................................................................27-2
27.2 Availability of Offline Test.........................................................................................................................27-2
27.3 Operation of Offline Test ...........................................................................................................................27-3
28 Upgrade Without Service Interruption..............................................................................28-1

28.1 Overview of Upgrade Without Service Interruption...................................................................................28-2
28.2 Availability of Upgrade Without Service Interruption................................................................................28-2
29 Basic BootROM Online Upgrade........................................................................................29-1

29.1 Overview of Basic BootROM Online Upgrade..........................................................................................29-2
29.2 Availability of Basic BootROM Online Upgrade ......................................................................................29-4
29.3 Operation of Basic BootROM Online Upgrade .........................................................................................29-4
30 JTAG Upload Through MML Command..........................................................................30-1

30.1 Overview of JTAG Uploading Through MML Command.........................................................................30-2
30.2 Availability of JTAG Upload Through MML Command...........................................................................30-2
30.3 Operation of JTAG Upload Through MML Command .............................................................................30-3
31 Backup and Restoration of Configuration Files on the LMT........................................31-1

31.1 Overview of Backup and Restoration of Configuration Files on the LMT.................................................31-2
31.2 Availability of Backup and Restoration of Configuration Files on the LMT.............................................31-3
31.3 Operation of Backup and Restoration of Configuration Files on the LMT................................................31-3
32 Password Configuration Policy...........................................................................................32-1

32.1 Overview of Password Configuration Policy .............................................................................................32-2
32.2 Availability of Password Configuration Policy..........................................................................................32-2
32.3 Setting Password Policy..............................................................................................................................32-3
33 Transmission Quality Check in the IP Bearer Network.................................................33-1

33.1 Overview of the Transmission Quality Check in the IP Bearer Network...................................................33-2
33.2 Availability of Transmission Quality Check in the IP Bearer Network......................................................33-3
33.3 Locating Faults of the IP Bearer Network Through Monitoring IP Addresses...........................................33-4
34 IP CAC......................................................................................................................................34-1
34.1 Overview of IP CAC...................................................................................................................................34-2
34.2 Availability of IP CAC................................................................................................................................34-3
34.3 Configuring the IP CAC Function..............................................................................................................34-4
vi Huawei Proprietary and Confidential Issue 01 (2010-01-12)

34.3.1 Automatic Discovery and Detection of Faulty IP Address Pairs.......................................................34-4

34.3.2 Static CAC Optimization...................................................................................................................34-7
34.3.3 Dynamic CAC Optimization............................................................................................................34-10
34.3.4 Dynamic Adjustment of the DSCP Flag..........................................................................................34-12
35 Characteristic Location Method with Dialing Tests.......................................................35-1

35.1 Data Configuration of Dialing Fault Location for a Specified User...........................................................35-2
35.1.1 Overview of Dialing Fault Location for a Specified User.................................................................35-2
35.1.2 Availability of Dialing Fault Location for a Specified User..............................................................35-3
35.1.3 Data Configuration of Dialing Fault Location for a Specified User..................................................35-3
35.2 Dialing Test for the Specified Resource......................................................................................................35-9
35.2.1 Overview of Dialing Test for the Specified Resource.......................................................................35-9
35.2.2 Availability of Dialing Test for the Specified Resource..................................................................35-14
35.2.3 Dialing Test for the Specified TC/EC Resource..............................................................................35-14
36 Electronic Label......................................................................................................................36-1
36.1 Overview of Electronic Label.....................................................................................................................36-2
36.2 Availability of Electronic Label..................................................................................................................36-2
36.3 Operation of Electronic Label.....................................................................................................................36-3
37 Power Consumption Reduction..........................................................................................37-1

37.1 Overview of Power Consumption Reduction..............................................................................................37-2
37.2 Availability of Power Consumption Reduction..........................................................................................37-3
37.3 Configuring the IP CAC Function..............................................................................................................37-4
37.4 Related Performance Measurement Items...................................................................................................37-4
A Glossary.....................................................................................................................................A-1
Issue 01 (2010-01-12) Huawei Proprietary and Confidential vii

Feature Description Figures
Figures
Figure 1-1 AG networking...................................................................................................................................1-4

Figure 1-2 Call flow between two terminations of the same MGW.................................................................... 1-5
Figure 1-3 TG networking....................................................................................................................................1-8
Figure 1-4 TG call flow........................................................................................................................................1-9
Figure 1-5 Fax service flow in AG networking.................................................................................................1-12
Figure 1-6 Fax service flow in TG networking..................................................................................................1-13
Figure 2-1 UMG8900 accessing narrowband users.............................................................................................2-2
Figure 2-2 Networking diagram when the UMG8900 acts as an AG and is connected to a high-density frame
...............................................................................................................................................................................2-5
Figure 2-3 High-density UA frame and board..................................................................................................... 2-6
Figure 2-4 Connection between the high-density UA frame and the SSM frame................................................2-7
Figure 2-5 Connection between the main frame and the subframe......................................................................2-7
Figure 3-1 Interworking between UMTS and H.323 video terminals..................................................................3-3
Figure 3-2 Interworking between UMTS and NGN video terminals...................................................................3-5
Figure 3-3 Network diagram of videotelephony service......................................................................................3-6
Figure 5-1 Generation of electrical echoes...........................................................................................................5-5
Figure 5-2 Principle of jitter buffer......................................................................................................................5-9
Figure 6-1 UMG8900 supporting the embedded SG function ............................................................................6-4
Figure 6-2 Structure of protocol stack adapting the SS7 signaling over M2UA..................................................6-6
Figure 6-3 SS7 signaling transfer path in an SSM-256 frame............................................................................. 6-7
Figure 6-4 Structure of protocol stack adapting the SS7 signaling over M3UA..................................................6-8
Figure 6-5 SS7 signaling transfer path in an SSM-256 frame............................................................................. 6-9
Figure 6-6 Structure of protocol stack adapting the SS7 signaling over M2UA................................................6-10
Figure 6-7 SS7 signaling transfer path in an SSM-256 frame ..........................................................................6-11
Figure 6-8 Structure of protocol stack adapting the SS7 signaling over M3UA................................................6-12
Figure 6-9 SS7 signaling transfer path in an SSM-256 frame ..........................................................................6-13
Figure 6-10 Structure of protocol stack adapting the DSS1 signaling over IUA ..............................................6-14
Figure 6-11 DSS1 signaling transfer path in an SSM-256 frame.......................................................................6-15
Figure 6-12 Structure of protocol stack adapting the V5 signaling over V5UA................................................6-16
Figure 6-13 V5 signaling transfer path in an SSM-256 frame...........................................................................6-17
Figure 6-14 Index mapping of main parameters in M2UA-based signaling gateway ......................................6-18
Figure 6-15 Network diagram............................................................................................................................6-19
Figure 6-16 Index mapping of configuration commands of the signaling transfer based on M3UA................6-20
Figure 6-17 Network diagram of the signaling transfer over M3UA.................................................................6-21
Issue 01 (2010-01-12) Huawei Proprietary and Confidential ix

Figures Feature Description
Figure 6-18 Index mapping of main parameters in M2UA-based signaling gateway ......................................6-23
Figure 6-20 Index mapping of configuration commands of signaling transfer over M3UA.............................6-25
Figure 6-21 Network diagram of the signaling transfer over M3UA.................................................................6-26
Figure 6-22 Index mapping of main parameters in IUA-based signaling gateway ...........................................6-27
Figure 6-24 Index mapping of main parameters in V5UA-based signaling gateway .......................................6-29
Figure 7-1 R2/CNo.1 CAS processing flow in an SSM-256 frame.....................................................................7-4
Figure 7-2 No.5 CAS processing flow.................................................................................................................7-5
Figure 7-3 Index mapping of configuration commands in CAS-based signaling transfer...................................7-6
Figure 7-4 Network diagram................................................................................................................................7-7
Figure 8-1 Signaling transparent transmission of the TDM semi-permanent connection....................................8-4
Figure 8-2 Common networking of semi-permanent connections in the dedicated service................................8-5
Figure 8-3 SS7 signaling transferring of the semi-permanent connection...........................................................8-6
Figure 8-4 DDN dedicated line service................................................................................................................8-7
Figure 8-5 Networking of the audio dedicated line service.................................................................................8-9
Figure 10-1 Networking for syntax adaptation..................................................................................................10-3
Figure 12-1 Networking for the LAN................................................................................................................12-5
Figure 12-2 VRRP diagram................................................................................................................................12-6
Figure 12-3 Networking of the FE interface......................................................................................................12-7
Figure 12-4 Networking for FE interface protection..........................................................................................12-8
Figure 12-5 Networking of IP trunk...................................................................................................................12-9
Figure 12-6 Networking of the GE interface......................................................................................................12-9
Figure 12-7 Networking for GE interface protection.......................................................................................12-10
Figure 12-8 Route backup diagram 1...............................................................................................................12-13
Figure 12-9 Route backup diagram 2...............................................................................................................12-14
Figure 12-10 IP bearer network diagram .........................................................................................................12-15
Figure 12-11 Network diagram for route backup.............................................................................................12-16
Figure 13-1 1+1 backup protection mode..........................................................................................................13-4
Figure 13-2 1:N backup working mode.............................................................................................................13-5
Figure 13-3 Index mapping of main parameters of SDH/SONET interface protection.....................................13-6
Figure 14-1 UAM StandAlone networking diagram..........................................................................................14-5
Figure 14-2 V5 StandAlone networking diagram..............................................................................................14-7
Figure 14-3 System networking diagram ..........................................................................................................14-8
Figure 15-1 Definition of the IP TOS field .......................................................................................................15-3
Figure 15-2 Definition of the IP DSCP field .....................................................................................................15-4
Figure 15-3 802.1Q tag header...........................................................................................................................15-4
Figure 16-1 Application scenarios of RTP multiplexing...................................................................................16-2
Figure 16-2 Process of multiplexing non-compressed RTP packets..................................................................16-4
Figure 16-3 Structure of the RTP MUX header.................................................................................................16-5
Figure 16-4 Structure of the RTP packet header................................................................................................16-6
x Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Feature Description Figures
Figure 16-5 Format of the non-compressed RTP multiplexing packet..............................................................16-8

Figure 16-6 Process of multiplexing compressed RTP packets.........................................................................16-9
Figure 16-7 Format of the compressed RTP multiplexing packet...................................................................16-10
Figure 16-8 Format of the compressed RTP multiplexing packet in the SIP networking...............................16-11
Figure 16-9 RTP multiplexing process............................................................................................................16-13
Figure 16-10 Bandwidth usage of the RTP multiplexing.................................................................................16-14
Figure 17-1 DCME networking.........................................................................................................................17-2
Figure 17-2 IVCP networking............................................................................................................................17-4
Figure 17-3 Index mapping of the configuration command parameters when the UMG8900 supports the IVCP
function................................................................................................................................................................17-5
Figure 17-4 IVCP networking............................................................................................................................17-7
Figure 18-1 NTP networking diagram...............................................................................................................18-4
Figure 18-2 Principle diagram of clock synchronization...................................................................................18-5
Figure 18-3 Calculating method for time offset and delay.................................................................................18-6
Figure 19-1 Architecture of the clock system in SSM-256 self-cascading........................................................19-3
Figure 19-2 Architecture of the clock system in SSM-32 self-cascading..........................................................19-4
Figure 20-1 VMGW...........................................................................................................................................20-2
Figure 20-2 One physical gateway shared by multiple MGCs...........................................................................20-4
Figure 20-3 One physical gateway shared by multiple MGCs...........................................................................20-5
Figure 20-4 IGW networking in the ATG & IGW integrated architecture........................................................20-6
Figure 20-5 Realization principle of the VMGW...............................................................................................20-7
Figure 20-6 Streams carried by the VMGW through the IP interworking mode in the case of TDM input and TDM
output...................................................................................................................................................................20-8
Figure 20-7 Streams carried by the VMGW through the IP interworking mode in the case of TDM input and IP
output...................................................................................................................................................................20-9
Figure 20-8 Streams carried by the VMGW through the TDM interworking mode in the case of TDM input and
TDM output.........................................................................................................................................................20-9
Figure 21-1 1+1 mutual-aid dual homing networking diagram ........................................................................21-5
Figure 21-2 1+1 master/slave dual homing networking diagram ......................................................................21-6
Figure 21-3 Networking diagram of link priority..............................................................................................21-7
Figure 21-4 Networking diagram of route priority.............................................................................................21-8
Figure 22-1 Two-path application scenario of the SCTP multi-homing............................................................22-3
Figure 22-2 Four-path application scenario of the SCTP multi-homing............................................................22-3
Figure 22-3 Two-path and four-path application scenarios of the SCTP multi-homing....................................22-3
Figure 22-4 Principle of the SCTP multi-homing..............................................................................................22-5
Figure 22-5 Internal processing of the SCTP multi-homing..............................................................................22-6
Figure 22-6 Typical networking of the SCTP multi-homing.............................................................................22-8
Figure 23-1 Data encapsulation formats in different security protocols............................................................23-4
Figure 23-2 Index mapping of main parameters in IPSec configuration ..........................................................23-6
Figure 25-1 MML command input window ......................................................................................................25-6
Figure 25-2 UI panel........................................................................................................................................25-27
Figure 26-1 Networking application..................................................................................................................26-3
Figure 26-2 Service flow of time localization at the MML interface ................................................................26-4
Issue 01 (2010-01-12) Huawei Proprietary and Confidential xi

Figures Feature Description
Figure 26-3 Service flow of time localization at the binary interface ...............................................................26-4
Figure 29-1 Loading the BootROM software to the hard disk of the OMU......................................................29-5
Figure 30-1 Loading buffer ...............................................................................................................................30-4
Figure 31-1 Interface of the wftpd32 tool..........................................................................................................31-4
Figure 31-2 User setting.....................................................................................................................................31-5
Figure 31-3 Adding a user .................................................................................................................................31-5
Figure 31-4 Setting the password ......................................................................................................................31-5
Figure 31-5 Setting the default directory...........................................................................................................31-6
Figure 31-6 Backing up the configuration data..................................................................................................31-6
Figure 31-7 Backing up the configuration data at the local end.........................................................................31-7
Figure 31-8 Backing up the configuration data on the specified server.............................................................31-8
Figure 31-9 Backing up the configuration data..................................................................................................31-8
Figure 31-10 Backing up the configuration data regularly ...............................................................................31-9
Figure 31-11 Restoring the configuration data ..................................................................................................31-9
Figure 31-12 Restoring the configuration data at the local..............................................................................31-10
Figure 31-13 Restoring the configuration data on the specified server............................................................31-11
Figure 33-1 Networking diagram.......................................................................................................................33-5
Figure 34-1 Messages exchanged for the function of automatic discovery and detection of faulty IP address pairs
.............................................................................................................................................................................34-5
Figure 34-2 CAC algorithm based on the outgoing interface............................................................................34-7
Figure 34-3 Optimized CAC algorithm..............................................................................................................34-8
Figure 34-4 Bandwidth calculation by using the optimized static CAC algorithm...........................................34-8
Figure 34-5 Service flow chart...........................................................................................................................34-9
Figure 35-1 Inloop and outloop..........................................................................................................................35-4
Figure 35-2 Loopback initiated on the UMG8900 side.....................................................................................35-5
Figure 35-3 Networking diagram.......................................................................................................................35-6
Figure 35-4 GSM 2G networking of the dialing test for calls between users on the same MGW...................35-11
Figure 35-5 Networking of the dialing test for number receiving TC in TG networking................................35-11
Figure 35-6 GSM 2G networking of the dialing test for calls between users on different MGWs..................35-12
Figure 35-7 Networking of the dialing test for inconsistent codecs of the Iu and Nb interfaces in inter-office calls
in 3G networking...............................................................................................................................................35-12
Figure 35-8 Networking of the dialing test for the specified EC for two users on the same MGW in AG networking
...........................................................................................................................................................................35-13
Figure 35-9 Parameter settings for creating a full flow call tracing task on the MGW...................................35-15
Figure 35-10 Creating a full flow call tracing task...........................................................................................35-16
Figure 37-1 Relation between the resource usage and each threshold...............................................................37-3
xii Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Feature Description Tables
Tables
Table 1-1 Required NEs for basic services..........................................................................................................1-2

Table 1-2 Versions supporting basic services......................................................................................................1-3
Table 1-3 Protocols and specifications of basic services....................................................................................1-14
Table 2-1 Modes of the UA frames......................................................................................................................2-2
Table 2-2 Required NEs for the UAM-accessed narrowband user service..........................................................2-4
Table 2-3 Versions supporting the UAM-accessed narrowband user service......................................................2-4
Table 2-4 Protocol and specification of the UAM-accessed narrowband user service........................................2-9
Table 3-1 Required NEs for the videotelephony service......................................................................................3-2
Table 3-2 Versions supporting the videotelephony service..................................................................................3-2
Table 3-3 Parameters between the UMG8900 and the MGC...............................................................................3-7
Table 3-4 Protocols and specifications of the videotelephony service.................................................................3-8
Table 4-1 Service benefits of voice codec............................................................................................................4-2
Table 4-2 Description of codec set ......................................................................................................................4-2
Table 4-3 Required NEs for voice codec .............................................................................................................4-4
Table 4-4 Versions supporting voice codec.........................................................................................................4-4
Table 4-5 Technical specifications of the G.711 A/Mu codec ............................................................................4-5
Table 4-6 Technical specifications of the G.723.1 codec.....................................................................................4-5
Table 4-7 Technical specifications of the G.726 codec .......................................................................................4-6
Table 4-8 Technical specifications of the G.729 codec........................................................................................4-6
Table 4-9 Protocols and specifications of voice codec.........................................................................................4-8
Table 5-1 Service benefits of voice quality enhancement ...................................................................................5-2
Table 5-2 Function restrictions of voice quality enhancement.............................................................................5-3
Table 5-3 Required NEs for voice quality enhancement .....................................................................................5-3
Table 5-4 Versions supporting voice quality enhancement .................................................................................5-4
Table 5-5 Protocol and specification of voice quality enhancement .................................................................5-10
Table 6-1 Service benefits of narrowband common channel signaling adaptation .............................................6-3
Table 6-2 Function restrictions of narrowband common channel signaling adaptation ......................................6-3
Table 6-3 Required NEs for narrowband common channel signaling adaptation ...............................................6-3
Table 6-4 Versions supporting narrowband common channel signaling adaptation ...........................................6-4
Table 6-5 Protocols and specifications of narrowband common channel signaling adaptation.........................6-31
Table 7-1 Service benefits of channel associated signaling adaptation ...............................................................7-2
Table 7-2 Function restrictions of channel associated signaling adaptation .......................................................7-2
Table 7-3 Required NEs for channel associated signaling adaptation ................................................................7-3
Issue 01 (2010-01-12) Huawei Proprietary and Confidential xiii

Tables Feature Description
Table 7-4 Versions supporting channel associated signaling adaptation ............................................................7-3

Table 7-5 Protocols and specifications of channel associated signaling adaptation ...........................................7-8
Table 8-1 Service benefits of the TDM semi-permanent connection...................................................................8-2
Table 8-2 Required NEs for the TDM semi-permanent connection.....................................................................8-3
Table 8-3 Versions supporting the TDM semi-permanent connection................................................................8-3
Table 8-4 Data planning.......................................................................................................................................8-6
Table 9-1 Service benefits of announcement playing and digit collecting...........................................................9-4
Table 9-2 Function restrictions of announcement playing and digit collecting...................................................9-5
Table 9-3 Required NEs for announcement playing and digit collecting............................................................9-5
Table 9-4 Versions supporting announcement playing and digit collecting........................................................9-5
Table 9-5 Protocols and specifications of announcement playing and digit collecting.......................................9-9
Table 10-1 Protocol and specification of syntax adaptation.............................................................................10-13
Table 11-1 Service benefits of multi-level overload control..............................................................................11-3
Table 11-2 Required NEs for multi-level overload control................................................................................11-3
Table 11-3 Versions supporting multi-level overload control............................................................................11-3
Table 11-4 Protocols and specifications of multi-level overload control ..........................................................11-5
Table 12-1 Service benefits of IP interface protection.......................................................................................12-2
Table 12-2 Function restrictions of IP interface protection................................................................................12-3
Table 12-3 Required NEs for IP interface protection ........................................................................................12-3
Table 12-4 Versions supporting IP interface protection ....................................................................................12-3
Table 12-5 Protocols and specifications of IP interface protection .................................................................12-17
Table 13-1 Service benefits of SDH/SONET interface protection.....................................................................13-2
Table 13-2 Required NEs for SDH/SONET interface protection ..................................................................... 13-2
Table 13-3 Versions supporting SDH/SONET interface protection..................................................................13-3
Table 13-4 Protocols and specifications of SDH/SONET interface protection ................................................ 13-8
Table 14-1 Service benefits of StandAlone........................................................................................................14-2
Table 14-2 Function restrictions of StandAlone.................................................................................................14-3
Table 14-3 Required NEs for StandAlone .........................................................................................................14-3
Table 14-4 Versions supporting StandAlone .....................................................................................................14-3
Table 14-5 Protocols and specifications of StandAlone...................................................................................14-12
Table 15-1 Service benefits of IP QoS ..............................................................................................................15-2
Table 15-2 Function restrictions of IP QoS .......................................................................................................15-2
Table 15-3 Required NEs for IP QoS ................................................................................................................15-3
Table 15-4 Versions supporting IP QoS.............................................................................................................15-3
Table 15-5 Protocols and specifications of IP QoS............................................................................................15-6
Table 16-1 Service benefits of RTP multiplexing..............................................................................................16-3
Table 16-2 Function restrictions of RTP multiplexing.......................................................................................16-3
Table 16-3 Required NEs for RTP multiplexing................................................................................................16-3
Table 16-4 Version supporting RTP multiplexing.............................................................................................16-4
Table 16-5 Meanings of the fields in the RTP packet header.............................................................................16-6
xiv Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Table 16-6 Meanings of the fields in the RTP multiplexing packet header.......................................................16-9
Table 16-7 Meanings of the fields in the compressed RTP multiplexing packet header.................................16-12
Table 16-8 Input parameters.............................................................................................................................16-15
Table 16-9 Data planning.................................................................................................................................16-15
Table 16-10 Protocols and specifications of RTP multiplexing.......................................................................16-16
Table 17-1 Service benefits of IVCP..................................................................................................................17-3
Table 17-2 Function restrictions of IVCP..........................................................................................................17-3
Table 17-3 Required NEs for IVCP...................................................................................................................17-3
Table 17-4 Versions supporting IVCP...............................................................................................................17-4
Table 17-5 Compression ratios of different codecs for IVCP............................................................................17-5
Table 17-6 Input parameters...............................................................................................................................17-6
Table 17-7 Data planning...................................................................................................................................17-6
Table 18-1 Service benefits of NTP network time.............................................................................................18-2
Table 18-2 Required NEs for NTP network time...............................................................................................18-3
Table 18-3 Versions supporting NTP network time...........................................................................................18-3
Table 18-4 Protocols and specifications of NTP network time .........................................................................18-7
Table 19-1 Service benefits of GPS clock synchronization...............................................................................19-2
Table 19-2 Function restrictions of the GPS clock synchronization..................................................................19-2
Table 19-3 Required NEs for GPS clock synchronization.................................................................................19-2
Table 19-4 Versions supporting GPS clock synchronization.............................................................................19-3
Table 19-5 Protocol and specification of GPS clock synchronization...............................................................19-5
Table 20-1 Service benefits of VMGW .............................................................................................................20-3
Table 20-2 Function restrictions.........................................................................................................................20-3
Table 20-3 Required NEs for VMGW ..............................................................................................................20-4
Table 20-4 Versions supporting VMGW ..........................................................................................................20-4
Table 20-5 Protocols and specifications of VMGW........................................................................................20-11
Table 21-1 Service benefits of MGC dual homing.............................................................................................21-2
Table 21-2 Function restrictions of MGC dual homing.....................................................................................21-2
Table 21-3 Required NEs for MGC dual homing .............................................................................................21-3
Table 21-4 Versions supporting MGC dual homing..........................................................................................21-3
Table 22-1 Service benefits of the SCTP multi-homing....................................................................................22-4
Table 22-2 Required NEs for SCTP multi-homing............................................................................................22-4
Table 22-3 Versions supporting SCTP multi-homing........................................................................................22-4
Table 22-4 Configuration information about the SCTP multi-homing..............................................................22-8
Table 22-5 Compliance protocols and specifications of SCTP multi-homing...................................................22-9
Table 23-1 Service benefits of IPSec ................................................................................................................23-2
Table 23-2 Required NEs for IPSec...................................................................................................................23-2
Table 23-3 Versions supporting IPSec...............................................................................................................23-3
Table 23-4 Compliance protocols and specifications of IPSec .........................................................................23-7
Table 24-1 Service benefits of SSH ..................................................................................................................24-2
Table 24-2 Function restrictions of SSH ...........................................................................................................24-2
Table 24-3 Required NEs for SSH ....................................................................................................................24-3
Issue 01 (2010-01-12) Huawei Proprietary and Confidential xv

Tables Feature Description
Table 24-4 Versions supporting SSH ................................................................................................................24-3

Table 24-5 Compliance protocols and specifications of SSH .........................................................................24-14
Table 25-1 Service benefits of operation and maintenance................................................................................25-2
Table 25-2 Required NEs for operation and maintenance .................................................................................25-2
Table 25-3 Versions supporting operation and maintenance............................................................................. 25-2
Table 25-4 Meaning of shortcut icons in the command input area ................................................................... 25-6
Table 25-5 Parameter description.....................................................................................................................25-21
Table 25-6 List of frame parameters ...............................................................................................................25-24
Table 26-1 Service benefits of time localization................................................................................................26-2
Table 26-2 Function restrictions of time localization.........................................................................................26-2
Table 26-3 Required NEs for time localization .................................................................................................26-3
Table 26-4 Versions supporting time localization .............................................................................................26-3
Table 27-1 Service benefits of offline test .........................................................................................................27-2
Table 27-2 Function restrictions of offline test .................................................................................................27-2
Table 27-3 Required NEs for offline test .......................................................................................................... 27-2
Table 27-4 Versions supporting offline test ......................................................................................................27-3
Table 28-1 Service benefits of upgrade without service interruption.................................................................28-2
Table 28-2 Required NEs for upgrade without service interruption.................................................................. 28-2
Table 29-1 Board PCB versions and corresponding logical application relations ............................................29-2
Table 29-2 Service benefits of basic BootROM online upgrade .......................................................................29-3
Table 29-3 Required NEs for basic BootROM online upgrade .........................................................................29-4
Table 29-4 Versions supporting basic BootROM online upgrade .................................................................... 29-4
Table 30-1 Service benefits of JTAG upload ....................................................................................................30-2
Table 30-2 Function restrictions of JTAG upload .............................................................................................30-2
Table 30-3 Required NEs for JTAG upload ......................................................................................................30-3
Table 30-4 Versions supporting JTAG upload ..................................................................................................30-3
Table 31-1 Service benefits of backup and restoration of configuration files on the LMT .............................. 31-2
Table 31-2 Function restrictions of backup and restoration of configuration files on the LMT........................31-2
Table 31-3 Required NEs for backup and restoration of configuration files on the LMT.................................31-3
Table 31-4 Versions supporting backup and restoration of configuration files on the LMT.............................31-3
Table 32-1 Service benefits of password configuration policy .........................................................................32-2
Table 32-2 Function restrictions of password configuration policy ..................................................................32-2
Table 32-3 Required NEs for password configuration policy ...........................................................................32-3
Table 32-4 Versions supporting password configuration policy .......................................................................32-3
Table 32-5 Parameter description.......................................................................................................................32-3
Table 33-1 Required NEs for transmission quality check in the IP bearer network.......................................... 33-3
Table 34-3 Default mappings between priority levels and DSCP values in normal situation.........................34-13
Table 34-4 Default mappings between priority levels and DSCP values during dynamic adjustment............34-13
Table 34-5 Mappings between priority levels and DSCP values in normal situation......................................34-14
Table 34-6 Mappings between priority levels and DSCP values during dynamic adjustment........................34-14
xvi Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Table 35-1 Required NEs for dialing fault location for a specified user............................................................35-3
Table 36-1 Service benefits of electronic label..................................................................................................36-2
Table 36-2 Function restrictions of electronic label...........................................................................................36-2
Table 36-3 Required NEs for electronic label ...................................................................................................36-2
Table 36-4 Versions supporting electronic label ...............................................................................................36-3
Issue 01 (2010-01-12) Huawei Proprietary and Confidential xvii

Feature Description About This Document
About This Document
Purpose
This document describes the functions of the UMG8900.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI UMG8900 V200R008C02
Intended Audience
The intended audiences of this document are:
l System engineers
l Technical support engineers
l Operation and maintenance engineers
Update History
Updates between document versions are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Updates in Issue 01 (2010-01-12)
Initial commercial release
Organization
This document describes the functions of the UMG8900.
1 Basic Services
Issue 01 (2010-01-12) Huawei Proprietary and Confidential 1

Organization Feature Description
This chapter provides the definition and describes the required network elements (NEs), function
restrictions, implementation principles, service flow, data configuration, and compliance
protocols and specifications of basic services.
2 UAM-Accessed Narrowband User Service
protocols and specifications of the UAM-accessed narrowband user service.
3 Videotelephony Service
This chapter describes the definitions, required network elements (NEs), function restrictions,
implementation principles, service flow, data configuration, and compliance protocols and
specifications of the videotelephony service.
4 Voice Codec
protocols and specifications of the voice codec.
5 Voice Quality Enhancement
protocols and specifications of voice quality enhancement.
6 Narrowband Common Channel Signaling Adaptation
protocols and specifications of narrowband common channel signaling (CCS) adaptation.
7 Channel Associated Signaling Adaptation
This chapter describes the definition, involved required network elements (NEs), function
protocols and specifications of channel associated signaling (CAS) adaptation.
8 TDM Semi-permanent Connections
protocols and specifications of time division multiplex (TDM) semi-permanent connections.
9 Announcement Playing and Digit Collecting
protocols and specifications of announcement playing and digit collecting.
10 Syntax Adaptation
restrictions, and compliance protocols and specifications of syntax adaptation.
11 Multi-Level Overload Control
2 Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Feature Description Organization
protocols and specifications of multi-level overload control.
12 IP Interface Protection
protocols and specifications of Internet Protocol (IP) interface protection.
13 SDH/SONET Interface Protection
protocols and specifications of synchronous digital hierarchy (SDH)/synchronous optical
network(SONET) interface protection.
14 StandAlone
protocols and specifications of StandAlone.
15 IP QoS
This chapter describes the definition, required network elements (NEs), function restrictions,
specifications of IP QoS.
16 RTP Multiplexing
This chapter provides the definition and describes the application scenarios, required network
elements (NEs), function restrictions, implementation principles, and data configuration of RTP
multiplexing.
17 IVCP
restrictions, data configuration, and compliance protocols and specifications of IP voice
compressor plus (IVCP).
18 NTP Network Time
protocols and specifications of NTP network time.
19 GPS Clock Synchronization
protocols and specifications of global positioning system (GPS) clock synchronization.
20 VMGW
protocols and specifications of virtual media gateway (VMGW).
21 MGC Dual Homing

protocols and specifications of media gateway controller (MGC) dual homing.
22 SCTP Multi-homing
protocols and specifications of the Stream Control Transmission Protocol (SCTP) multi-homing.
23 IPSec
protocols and specifications of IP Security (IPSec).
24 SSH
protocols and specifications of secure shell (SSH).
25 Operation and Maintenance
This chapter provides the definition and describes the required network elements (NEs), and
operation of operation and maintenance.
26 Time Localization
restrictions, and operation of time localization.
27 Offline Test
restrictions, and operation of offline test.
28 Upgrade Without Service Interruption
This chapter provides the definition and describes service benefits for carriers and users, and
function restrictions of this feature.
29 Basic BootROM Online Upgrade
restrictions, and operation of basic BootBOM online upgrade.
30 JTAG Upload Through MML Command
restrictions, and operation of joint test action group (JTAG) upload through man-machine
language (MML) commands.
31 Backup and Restoration of Configuration Files on the LMT
restrictions, and operation of backup and restoration of configuration files on the local
maintenance terminal (LMT).
32 Password Configuration Policy

restrictions, and operation of password configuration policy.
33 Transmission Quality Check in the IP Bearer Network
restrictions, operations, and alarms of transmission quality check in the IP bearer network.
34 IP CAC
This chapter provides general information, availability, configuration method, and related alarm
of the IP CAC feature.
35 Characteristic Location Method with Dialing Tests
This chapter describes the characteristic location method with dialing tests.
36 Electronic Label
restrictions, and operation of electronic label.
37 Power Consumption Reduction
restrictions, data configuration, and related performance measurement items of power
consumption reduction.
A Glossary
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided,will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not

avoided,could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save

time.
Provides additional information to emphasize or supplement

important points of the main text.
General Conventions

The general conventions that may be found in this document are defined as follows.
Convention Description
Times New Roman Normal paragraphs are in Times New Roman.
Boldface Names of files, directories, folders, and users are in

boldface. For example, log in as user root.
Italic Book titles are in italics.

Courier New Examples of information displayed on the screen are in
Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by

vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by

vertical bars. Several items or no item can be selected.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Boldface Buttons, menus, parameters, tabs, window, and dialog titles

are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"

signs. For example, choose File > Create > Folder.
Keyboard Operations

The keyboard operations that may be found in this document are defined as follows.
Format Description
Key Press the key. For example, press Enter and press Tab.
Key 1+Key 2 Press the keys concurrently. For example, pressing Ctrl+Alt
+A means the three keys should be pressed concurrently.
Key 1, Key 2 Press the keys in turn. For example, pressing Alt, A means
the two keys should be pressed in turn.
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Action Description
Click Select and release the primary mouse button without moving
the pointer.
Double-click Press the primary mouse button twice continuously and

quickly without moving the pointer.
Drag Press and hold the primary mouse button and move the
pointer to a certain position.

Feature Description 1 Basic Services
1 Basic Services
About This Chapter
protocols and specifications of basic services.
1.1 Overview of Basic Services

This section provides the definition and describes service benefits for carriers and users, and
1.2 Availability of Basic Services
This section describes the required network elements (NEs) and version support of this feature.
1.3 Principle and Flow of Basic Services
This section describes the implementation principles and service flow of this feature.
1.4 Data Configuration of Basic Services
This section describes data configuration for enabling and maintaining this feature.
1.5 Protocol and Specification of Basic Services
This section describes the compliance protocols and specifications of this feature.
Issue 01 (2010-01-12) Huawei Proprietary and Confidential 1-1

1 Basic Services Feature Description
1.1 Overview of Basic Services

Feature Definition
Basic services refer to basic telecommunication services, including the voice service and data
service, supported by the UMG8900. The UMG8900, controlled by the media gateway controller
(MGC), provides bearer resources for basic services.
Voice services refer to basic call services. Data services consist of the fax service and data
transmission service.
Service Benefits
Feature For Carriers For Users
Voice service Voice services are provided, which Users can initiate and receive
increases the operating revenue. calls through a terminal.
Data service Data services are provided, which Users can send and receive faxes.
increases the operating revenue. Data transmission is also
available.
1.2 Availability of Basic Services

Required NEs
Table 1-1 Required NEs for basic services

Feature Required NE
Voice service MGC (the UMG8900 acting as an AG) and

MGC and PSTN switch (the UMG8900 acting as a trunk gateway
(TG))
Data service MGC (the UMG8900 acting as an AG) and

MGC and PSTN switch (the UMG8900 acting as a TG)
1-2 Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Version Support
Table 1-2 Versions supporting basic services

Feature Version Support
Voice service V100R002 and later
Data service V100R002 and later
License Restrictions
This feature is available only when the license is obtained.
A license is required only for IWF function.
1.3 Principle and Flow of Basic Services

1.3.1 Voice Services

1.3.2 Data Services
1.3.1 Voice Services

AG Call Flow
The UMG8900 supports hairpin calls that save the Internet Protocol (IP) termination and
transcoder (TC) resources.
A hairpin call refers to the communication between two time division multiplex (TDM)
terminations added in a context. In a non-hairpin call, two TDM terminations cannot directly
communicate. Two contexts in which an IP termination and a TDM termination are respectively
added must be added. The contexts interwork through the IP termination. At the same time, TC
resources must be added in both the contexts for bearer conversion.
The following takes the call between two terminations of the same media gateway (MGW) as
an example. Figure 1-1 shows the access gateway (AG) networking. The call flow between two
terminations of different MGWs is basically the same and thus not described here.

Figure 1-1 AG networking
Figure 1-2 shows the call flow between two terminations of the same MGW.

Figure 1-2 Call flow between two terminations of the same MGW

In the flow, assume that:
l The physical termination ID of the Termination1 is A0 that is connected to UserA.

l The physical termination ID of the Termination2 is A1 that is connected to UserB.
l The UserA makes a call to the UserB, and the caller hangs up first.
l The IP address and port number of the media gateway controller (MGC) are
191.169.200.61:2944.
l The IP address and port number of the MGW are 191.169.150.122:2944.
The call process on the AG calling side is as follows:
1. A user reports an off-hook event to the MGW.

Event 1: Upon detecting that the UserA in termination A0 picks up the phone, the MGW
sends the NTFY_REQ command to notify the MGC of the off-hook event. The MGC
acknowledges the receipt of the off-hook event in the NTFY_REPLY message.
2. The MGC sends the announcement playing and digit collecting notification.
Event 2: After receiving the off-hook event, the MGC sends the MOD_REQ command to
instruct the MGW to play the dial tone to the UserA at termination A0 and request the
MGW to detect on-hook events. In addition, the MGC notifies termination A0 of the digit
map (dmap1), based on which digits are collected. Termination A0 sends MOD_REPLY
to the MGC as the response of the MOD_REQ command and sends the dial tone to the
UserA.
3. The MGW reports the digit collecting message.
Event 3: UserA dials the phone. Termination A0 collects the dialed digits and tries to match
the digit map. In the case of a successful match, Termination A0 sends the NTFY_REQ
command to the MGC. The MGC acknowledges the receipt of the NTFY_REQ command
sent by termination A0, with NTFY_REPLY.
4. The MGC creates a new context in the MGW.
Event 4: The MGC creates a new context in the MGW and adds a TDM termination and a
Real Time Transport Protocol (RTP) termination in the context. The MGW responds with
ADD_REPLY to allocate a new connection descriptor and a new RTP termination
descriptor.
5. The MGC sends the message indicating playing the ringback tone to the caller.
Event 7: The MGC sends the MOD_REQ command to the termination A0 to modify the
attributes of termination A0 and request the MGW to play the ringback tone to the UserA.
The MGW acknowledges with MOD_REPLY, and meanwhile plays the ringback tone to
the UserA.
6. The MGC sends a command for modifying the media stream attributes.
Event 10: Through the MOD_REQ command, the MGC sends the connection description
of the RTP termination A100000035 associated with termination A1 to the RTP termination
A100000034 associated with termination A0. The MGC modifies the mode of the RTP
termination A100000034 to receiving/sending. The MGW acknowledges with
MOD_REPLY. Then, terminations A0 and A1 learn about the connection information
between the local end and the peer end. The conversation conditions are satisfied, and a
conversation is started.
7. The MGW reports the on-hook event of the caller.

Event 11: The caller UserA hangs up. The MGW sends the NTFY_REQ command to notify
the MGC. The MGC responds with NTFY_REPLY to notify the MGW that the
NTFY_REQ command is received.
8. The MGC sends a command to modify the attributes of termination A0.
Event 12: After receiving the on-hook event of the UserA, the MGC sends the MOD_REQ
command to modify the attributes of termination A0. The MGC also requests the MGW to
detect events such as off-hook events that happen on termination A0, and modify the mode
of the RTP termination A100000034 to inactive. The MGW sends MOD_REPLY to
acknowledge the receipt and execution of the MOD_REQ command.
9. The MGC sends a command for deleting the association and releasing the call.
Event 13: After receiving the on-hook event of the UserA, the MGC sends the SUB_REQ
command to the MGW to delete all semi-permanent terminations and temporary RTP
terminations from association 286 and thus to delete the association and disconnect the call.
The MGW sends SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
10. The MGC sends a command to monitor the events that occur on terminal A0.
Event 15: After the associations and calls between termination A0, the RTP termination
and the MGC are released, the MGC sends the MOD_REQ command to request the MGW
to monitor the events such as off-hook events on termination A0. The MGW sends
MOD_REPLY to acknowledge the receipt of the MOD_REQ command. Then, the
association is null.
The call process on the AG called side is as follows:
1. The MGC sends a command for creating a new association.

Event 5: The MGC analyzes the called number and determines that the called UserB is
connected to the physical termination A1 of the MGW. Therefore, the MGC sends the
ADD_REQ request, requesting the MGW to add the physical termination A1 and an RTP
termination to a new context. The MGW responds with ADD_REPLY to allocate a new
connection descriptor 287 and a new RTP termination descriptor A100000035. Requested
by the MGC, the MGW determines G.711A as the codec type for termination A100000035
of the MGW. The MGW sets the RTP port number to 18296, the local IP address to
191,169,150,122, and termination A100000035 to inactive.
2. The MGC sends a command for modifying the termination attributes.
Event 6: The MGC sends the MOD_REQ command to termination A1 to modify the
attributes of termination A1 and request the MGW to play the ringing tone to the UserB.
The MGW acknowledges with MOD_REPLY, and meanwhile plays the ringing tone to
the UserB.
3. The MGW reports the off-hook event.
Event 8: The called UserB picks up the phone. The MGW notifies the MGC of the off-
hook event with the NTFY_REQ command. The MGC acknowledges with
NTFY_REPLY.
4. The MGC sends the RTP connection description and modifies the mode of the RTP
termination.
of the RTP termination A100000034 associated with termination A0 to the RTP termination
A100000035 associated with termination A1. The MGC modifies the mode of the RTP
termination A100000035 to receiving/sending. The MGW acknowledges with
MOD_REPLY.
5. The MGC sends a command to modify the termination attributes.

Event 14: the MGC sends the MOD_REQ command to the MGW to modify the attributes
of termination A1. The MGC requests the MGW to monitor the events such as on-hook
events on termination A1, and to play the busy tone to termination A1. The MGW returns
MOD_REPLY to acknowledge the receipt of the MOD_REQ command and plays the busy
tone to the UserB.
6. The MGW reports the on-hook event of the callee.
Event 16: The called UserB hangs up. The MGW sends the NTFY_REQ command to notify
the MGC. The MGC responds with NTFY_REPLY to notify the MGW that the
NTFY_REQ command is received.
Event 17: After receiving the on-hook event of the UserB, the MGC sends the SUB_REQ
command to the MGW to delete all semi-permanent terminations and temporary RTP
The MGW sends SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
8. The MGC sends a command for monitoring the events that occur on termination A1.
Event 18: After the associations and calls between termination A1, the RTP termination
and the MGC are released, the MGC sends the MOD_REQ command to request the MGW
to monitor the events such as off-hook events on termination A1. The MGW sends
MOD_REPLY to acknowledge the receipt of the MOD_REQ command. Then, the
association is null.
TG Call Flow
Assume that a call is connected through the trunk gateway (TG) and MGW and make a call from
a user in the public switched telephone network (PSTN) to another user under the AG. Figure
1-3 shows the TG networking.
Figure 1-3 TG networking
Figure 1-4 shows the process flow of a TG call.

Figure 1-4 TG call flow
In the flow, assume that:
l The IP address of the MGC is 191.169.150.170.

l The IP address of the TG is 191.169.150.10.
l The IP address of the AG is 191.169.150.172.
l The PSTN user is the caller, and the PSTN switch is connected to the MGC through a TG.
l The AG user is the callee, and the callee hangs up first.
The call process on the TG calling side is as follows:


Event 1: The PSTN user picks up the phone and dials the called number. An initial address
message (IAM) is sent to the MGC through the signaling gateway (SG) built in the TG.
After receiving the IAM, the MGC sends the ADD_REQ command, requesting the TG to
add the physical termination A29 and an RTP termination to a new context. The TG
responds with ADD_REPLY to allocate a new connection descriptor 15 and a new RTP
termination descriptor A2147489806. Requested by the MGC, the TG determines G.723
as the codec type for termination A2147489806 of the TG. The TG sets the RTP port number
to 13388, and the local IP address to 191.169.150.10.
2. The MGC sends the announcement notification.
Event 4: The MGC sends the MOD_REQ command to the TG, requesting the TG to play
the ringback tone to the PSTN user. The TG acknowledges with MOD_REPLY.
Subsequently, the MGC sends an address complete message (ACM) to the SG. After
receiving the message, the SG transfers it to the PSTN switch through the MTP2 User
Adaptation Layer (M2UA) protocol and requests the switch to send the ringback tone to
the PSTN user.
of the RTP termination A100000379 associated with termination A0 of the AG to the RTP
termination A2147489806 associated with termination A29 of the TG. The TG
acknowledges with MOD_REPLY.
Then, termination A29 of the TG and termination A0 of the AG learn about the connection
information between the local end and the peer end. Subsequently, the MGC sends an
answer message (ANM) to the SG. After receiving the message, the SG transfers it to the
PSTN switch through the M2UA protocol and requests the switch to stop sending the
ringback tone to the PSTN user and set up a conversation.
Event 11: After receiving the SUB_REQ command from the AG, the MGC sends a release
(REL) message to the SG. After receiving the message, the SG transfers it to the PSTN
switch through the M2UA protocol and requests the switch to send the busy tone to the
PSTN user and release the voice circuit.
On receipt of the REL message, the PSTN switch acknowledges with a release completed
(RLC) message that triggers the release of the voice circuit. After receiving the RLC
message, the SG transfers it to the MGC through the M2UA protocol.
After receiving the RLC message, the MGC sends the SUB_REQ command to the TG to
delete all semi-permanent terminations and temporary RTP terminations from context 15
and thus to delete the context and disconnect the call. The TG sends SUB_REPLY to
acknowledge the receipt of the SUB_REQ command.
The call process on the TG called side is as follows:

Event 2: The MGC analyzes the called number and determines that the called UserB is
connected to the physical termination A0 of the AG. Therefore, the MGC sends ADD_REQ,
requesting the AG to add the physical termination A0 and an RTP termination to a new
context. The AG responds with ADD_REPLY to allocate a new connection descriptor 218
and a new RTP termination descriptor A100000379. Requested by the MGC, the AG
determines G.723 as the codec type for termination A100000379 of the AG. The AG sets

the RTP port number to 18300, the local IP address to 191,169,150,172, and termination
A100000379 to inactive.
Event 3: The MGC sends MOD_REQ to the AG to request the AG to modify the attributes
of termination A0. The AG detects events such as off-hook events on termination A0, and
plays the ringing tone to the UserB. The AG acknowledges with MOD_REPLY, and
meanwhile plays the ringing tone to the UserB.
3. The AG reports the off-hook event.
Event 5: The UserB hangs up the phone. The AG sends the NTFY_REQ command to notify
the MGC. The MGC sends NTFY_REPLY to acknowledge the receipt of the NTFY_REQ
command.
of the RTP termination A2147489806 associated with termination A29 of the TG to the
RTP termination A100000379 associated with termination A0 of the AG. The MGC
modifies the mode of the RTP termination A100000379 to receiving/sending. The AG
acknowledges with MOD_REPLY.
5. The AG reports the on-hook event of the callee.
Event 8: The called UserB hangs up. The AG sends the NTFY_REQ command to notify
the MGC. The MGC sends NTFY_REPLY to acknowledge the receipt of the NTFY_REQ
command.
Event 9: After receiving the on-hook event of the UserB, the MGC sends the MOD_REQ
command to the AG to modify the attributes of termination A0. The MGC also requests
the MGW to detect events such as off-hook events on termination A0 and modifies the
mode of the RTP termination A100000379 to inactive. The AG sends MOD_REPLY to
acknowledge the receipt and execution of the MOD_REQ command.
Event 10: After receiving the on-hook event of the UserB, the MGC sends the SUB_REQ
command to the AG to delete all semi-permanent terminations and temporary RTP
The AG sends SUB_REPLY to acknowledge the receipt of the SUB_REQ command.
1.3.2 Data Services

Data services consist of fax service and modem data transmission service. The UMG8900
supports the G.711 transparent transmission and T.38 modes for the fax service and the G.711
transparent transmission mode for the modem data service.
l The transparent transmission mode indicates that data signals of the UMG8900 are carried
over G.711. That is, fax signals are processed as voice and transmitted without loss through
the G.711 codec. This transmission mode is simple and has short delay; however, it occupies
high bandwidth (fixed as 64 kbit/s) and can be easily influenced if the network in unstable.
l The T.38 mode indicates that the UMG8900 converts the T.30 fax signals sent by the fax
machine into T.38 fax packets that can be transmitted on the IP bearer network. This
transmission mode occupies little bandwidth and cannot be easily influenced if the network
is unstable; however, it is complex.

The UMG8900 transparently transmits the modem data service. That is, the UMG8900 processes
the data signals as voice and transmits the signals without loss through the G.711 codec.
The following describes the fax service flow when the UMG8900 acts as an access gateway
(AG) and a trunk gateway (TG).
Figure 1-5 shows the fax service flow in AG networking.
Figure 1-5 Fax service flow in AG networking
1. After the voice service call is established, the caller or the callee sends faxes to establish
the indication message CNG. The following takes the caller as an example. AG1 of the
caller detects the message and reports the Notify message to the media gateway controller
(MGC). The fax channel can be established after the CNG, CED, or V.21 message is
received. In addition, the process can also be initiated by the callee.
2. After receiving the Notify message reported by AG1, the MGC responds with a Reply
message. The MGC sends the Modify message to both AG1 of the caller and AG2 of the
callee, instructing them to modify the termination attribute of the voice channel as the fax
mode to establish the fax channel. Before the fax begins, the caller and the callee perform
fax capability negotiation. After the negotiation succeeds, they begin to transfer data.
3. After the data transmission is complete, the caller sends the EOP message. AG1 of the
caller detects the message and sends the Notify message to the MGC. The MGC then returns
a Reply message.
4. The MGC sends the Modify message to both the caller and the callee to modify the
termination attribute as the voice service mode.
5. After receiving the EOP message, the callee returns an MCF message through the voice
channel. The fax process is complete.
Figure 1-6 shows the fax service flow in TG networking.

Figure 1-6 Fax service flow in TG networking
1. The caller sends the CNG fax signal. After detecting the signal, TG1 reports a Notify
message indicating that the CNG signal is detected to the MGC. After receiving the
message, the MGC responds with a Reply message. TG1 does not process the CNG message
and directly sends it to the callee through the established voice channel. When the caller
sends the CNG, CED or V.21 message, the system begins to establish the fax channel. In
addition, the process can also be initiated by the callee.
2. The MGC sends the Modify message to both TG1 of the caller and TG2 of the callee,
instructing TG1 and TG2 to modify the termination attribute of the voice channel as the
fax mode to establish the fax channel. Before the fax begins, the caller and the callee
perform the fax capability negotiation. If the negotiation succeeds, they begin to transfer
data.
3. After the data transmission is complete, the caller sends the EOP message. TG1 of the caller
detects the message and sends the Notify message to the MGC, indicating the fax process
is complete. Meanwhile, the MGC responds with a Reply message.
4. The MGC sends the Modify message to both TG1 and TG2 to modify the termination
attribute as the voice mode and switch to the voice channel.
5. After receiving the EOP message, the callee returns an MCF message through the voice
channel. The fax process is complete.
1.4 Data Configuration of Basic Services

Procedure
l Configure voice services.
Generally, the default service and resource parameters can be used to implement the normal
service connections. You do not need to modify the parameters. Modifying the service and

resource parameters may affect the normal service connections. Therefore, read the man-
machine language (MML) help carefully before modifying a parameter.
1. (Optional) Run SET CODECCAP to set the codec capability supported by the
UMG8900.
2. (Optional) Run SET TCPARA to set the transcoder (TC) work parameters.
3. (Optional) Run SET ECPARA to set the echo cancellation (EC) work parameters.
l Configure data services.
1. (Optional) Run SET FAXPARA to set the fax work parameters.
2. (Optional) Run SET FAXRDNT to set the number of fax redundancy packets.
----End
1.5 Protocol and Specification of Basic Services

Table 1-3 Protocols and specifications of basic services

Feature Protocol and Specification
Voice service ITU-T Recommendation H.248: "Gateway

Control Protocol"
Data service V.152, T.38, V.150, and CLEANMODE

(rfc4040)

Feature Description 2 UAM-Accessed Narrowband User Service
2 UAM-Accessed Narrowband User Service
About This Chapter
protocols and specifications of the UAM-accessed narrowband user service.
2.1 Overview of the UAM-Accessed Narrowband User Service

This section describes the definition and service benefits for carriers and users of this feature.
2.2 Availability of the UAM-Accessed Narrowband User Service
2.3 Principle and Flow of the UAM-Accessed Narrowband User Service
2.4 Data Configuration of the UAM-Accessed Narrowband User Service
2.5 Protocol and Specification of the UAM-Accessed Narrowband User Service

2 UAM-Accessed Narrowband User Service Feature Description
2.1 Overview of the UAM-Accessed Narrowband User

Service
Feature Definition
When acting as an access gateway (AG), the UMG8900 can access plain old telephone service
(POTS) users, integrated services digital network (ISDN) users, and digital data network (DDN)
users through the user access (UA) frame. See Figure 2-1.
Figure 2-1 UMG8900 accessing narrowband users
Table 2-1 lists the modes of the UA frames.
Table 2-1 Modes of the UA frames

Mode Description
Main frame The main frame is connected to the service switching module (SSM) frame
and can be attached with subframes. A main frame refers to the frame that
has the PV8, PV4, RSU8 or RSU4 main control board.
The frames that can be configured as the main frames include the UAFM,
UAM, HABA_UP, HABD, HABL, RSP_10, and RSP_12 frames.

Mode Description
Subframe It is connected to the main frame directly. It cannot be subordinated by

other subframes. The main control board of the subframe of the low-
density UA frame is the RSP. No main control board is configured in the
subframe of the high-density UA frame.
The frames that can be configured as the subframes include the UAFS,
UAS, HABA_UP, HABA_DOWN, HABB_UP, HABB_DOWN, HABE,
HABF, RSP_10, RSP_12, RSP_14, RSP_15, and RSP_19 frames.
Direct frame A direct frame is the frame that has the RSP or RSA main control board.
It connects to the SSM frame but cannot attach other types of subframes.
The main control board in the RSB or RSB_HK frame is the RSA.
Frames that can be configured to direct frames consist of UAFM, UAFS,
UAM, UAS, RSP_10, RSP_12, RSP_14, RSP_15, RSP_19, RSP_60A,
RSP_160B, RSB, and RSB_HK.
RSA frame The RSA frame can be directly connected to the SSM frame. It can also
attach to the RSA subframe or the UAM frame of which the main control
board is the RSA.
Only the RSA_22 and RSA_26 frames can be configured to the RSA main
frame.
RSA subframe An RSA subframe can be directly connected to the RSA main frame. It
cannot attach subframes or the UAM frame of which the main control
board is the DRV.
Only the USR16 and USR19 frames can be configured to the RSA
subframe.
Service Benefits
UAM-accessed This feature provides the Users can initiate and receive
narrowband user narrowband access service and calls through a terminal.
service increases the operation revenue.
2.2 Availability of the UAM-Accessed Narrowband User

Service

Required NEs
Table 2-2 Required NEs for the UAM-accessed narrowband user service
Feature Required NE
UAM-accessed narrowband user service MGC and user terminal
Version Support
Table 2-3 Versions supporting the UAM-accessed narrowband user service
UAM-accessed narrowband user service V100R002 and later
This feature is a basic feature and is available even if no license is obtained.
2.3 Principle and Flow of the UAM-Accessed Narrowband

User Service
For details, see the access gateway (AG) service flow in 1.3 Principle and Flow of Basic
Services.
2.4 Data Configuration of the UAM-Accessed Narrowband

User Service
Procedure
Step 1 Run ADD ATONE to configure the asynchronous tone.
Step 2 Run ADD TDMIU to configure the TDM timeslot. Set Relay type to Inside.
Step 3 Run ADD UAFRM to add user access (UA) frames..
Step 4 Run ADD UABRD to add UA boards.
Step 5 Run ADD UACFG to add E1s on the RSP/RSA/PV8/DRV/RSU.
----End

Example
Network diagram
When acting as an access gateway (AG), the UMG8900 accesses telephone users by using two
HABA frames, including two HABA_UP frames and two HABA_DOWN frames. Figure 2-2
shows the networking.
Figure 2-2 Networking diagram when the UMG8900 acts as an AG and is connected to a high-
density frame
Data planning
l Data planning of the high-density UA frame and the board
Two HABA frames, that is, two HABA_UP frames and two HABA_DOWN frames, are
configured in the example. Figure 2-3 shows the device configuration panel.

Figure 2-3 High-density UA frame and board
l Connection between the high-density UA frame and the service switching module (SSM)
frame
Connect the SSM frame to HABA_UP frame 7 in the main frame through the internal E1
cable. Through W1, the four front E1s of the RSU8s in slots 4 and 5 are connected to E32
board 0. Through W2, the four back E1s of the RSU8s in slots 4 and 5 are connected to
E32 board 1.

Figure 2-4 Connection between the high-density UA frame and the SSM frame
l Connection between the main frame and the subframe

Connect HABA_UP frame 7 to HABB_UP frame 9 through the highway (HW) cable of
the HWCB.
The system automatically allocates the cascading interface PORT0 of the HABA_UP frame
to the preceding HABA_DOWN frame 8. It also automatically allocates PORT1 to
HABA_UP frame 9 and PORT2 to HABA_DOWN frame 10.
Figure 2-5 Connection between the main frame and the subframe
Configuration scripts
//Configure the asynchronous tone.
ADD ATONE: BT=VPU, BN=0, TONEID=RT;
ADD ATONE: BT=VPU, BN=0, TONEID=BT;
ADD ATONE: BT=VPU, BN=0, TONEID=INITRINGTONE;
//Configure the TDM bearer.

ADD TDMIU: BT=E32, BN=0, TIDFV=0, TIDLV=1023, VMGWID=0, HOSTID=30, RT=INSIDE,
CASNO=0, DCMESUP=NO;

ADD TDMIU: BT=E32, BN=1, TIDFV=1024, TIDLV=2047, VMGWID=0, HOSTID=30, RT=INSIDE,

CASNO=0, DCMESUP=NO;
//Configure the hardware data of the UA frame.

//Add the UA frame.
ADD UAFRM: FN=7, PN=0, RN=2, RFN=0, FT=HABAUP, FM=MAIN, BN=30, VMGWNO=0, FLG=NO;
ADD UAFRM: FN=9, PN=0, RN=2, RFN=0, FT=HABAUP, FM=MAIN, BN=30, VMGWNO=0, FLG=NO;
//Configure the boards in HABA_UP frame 7.

ADD UABRD: FN=7, SN=0, BT=PWX04;
ADD UABRD: FN=7, SN=4, BT=RSU;
ADD UABRD: FN=7, SN=5, BT=RSU;
ADD UABRD: FN=7, SN=6, BT=ASL;
//Configure the boards in HABA_DOWN frame 8.

//Configure the boards in HABA_UP frame 9.

//Configure the boards in HABA_DOWN frame 10.



//Configure the connection from the SSM frame to HABA_UP frame 7 in the main
frame.
ADD UACFG: FN=7, E1SRC=E32, SN=4, BN=0, SBN=0, BN0=0, PN0=16, BN1=0, PN1=17, BN2=0,
PN2=18, BN3=0, PN3=19, BN4=1, PN4=20, BN5=1, PN5=21, BN6=1, PN6=22, BN7=1, PN7=23;
ADD UACFG: FN=7, E1SRC=E32, SN=5, BN=1, SBN=0, BN0=1, PN0=16, BN1=1, PN1=17, BN2=1,
PN2=18, BN3=1, PN3=19, BN4=0, PN4=20, BN5=0, PN5=21, BN6=0, PN6=22, BN7=0, PN7=23;
//Configure the connections from HABA_DOWN frame 8, HABA_UP frame 9 and HABA_DOWN
frame 10 to HABA_UP frame 7 in the main frame.
ADD UACFG: FN=8, E1SRC=RSU, RSUFN=7, RSUHW=PORT0;
2.5 Protocol and Specification of the UAM-Accessed

Narrowband User Service
Table 2-4 Protocol and specification of the UAM-accessed narrowband user service
UAM-accessed narrowband user service Internal protocols of Huawei

Feature Description 3 Videotelephony Service
3 Videotelephony Service
About This Chapter
This chapter describes the definitions, required network elements (NEs), function restrictions,
specifications of the videotelephony service.
3.1 Overview of the Videotelephony Service

This section describes the definitions, service benefits for carriers and users, and function
restrictions of this feature.
3.2 Availability of the Videotelephony Service
3.3 Principle and Flow of the Videotelephony Service
3.4 Configuring the Videotelephony Service
3.5 Protocol and Specification of the Videotelephony Service

3 Videotelephony Service Feature Description
3.1 Overview of the Videotelephony Service

This section describes the definitions, service benefits for carriers and users, and function
restrictions of this feature.
Feature Definitions
A videotelephony call can be realized when both the caller and the callee have network cameras.
The video quality can be adjusted based on the network bandwidth.
Terminals that can provide the videotelephony service include the video Session Initiation
Protocol (SIP) phone, H.323 phone, SIP SoftPhone, and H.323 SoftPhone.
Service Benefits
Videotelephony This feature provides the video This feature meets the
service communication service in the requirements of users for video
circuit switched domain (CS), communication.
which increases the operating
revenue. This service attracts
fashionable users and business
users.
3.2 Availability of the Videotelephony Service

Required NEs
Table 3-1 Required NEs for the videotelephony service
Feature Required NE
Videotelephony MGC and user terminal
Version Support
Table 3-2 Versions supporting the videotelephony service
Videotelephony service V100R003 and later

3.3 Principle and Flow of the Videotelephony Service

Typical Networking
The UMG8900 supports the voice codec, video codec, multiplexing, and call control protocols
stipulated in the H.324M and H.323 suites to realize the interworking of multimedia services
between different networks.
Typical networking of the UMG8900 includes the following:
l Interworking between universal mobile telecommunications system (UMTS) and H.323
video terminals
l Interworking between UMTS and next generation network (NGN) video terminals
l Interworking between UMTS, H.323, and NGN video terminals
Interworking Between UMTS and H.323 Video Terminals

To perform multimedia communications, an H.324M video terminal in a UMTS CS domain and
a video terminal in an H.323 network for multimedia services. See Figure 3-1.
Figure 3-1 Interworking between UMTS and H.323 video terminals
GK: gatekeeper UMTS: universal mobile GMSC: gateway mobile switching

telecommunications system center
MCU: multipoint control unit ISUP: ISDN user part RAS: registration, admission and
status
In this networking mode, the UMG8900 interworks with the MGC through H.248 messages.
For a multimedia call between an H.324M terminal and an H.323 terminal, the basic process is
as follows:
1. An H.324M terminal initiates a call and the local mobile switching center (MSC) forwards
the call to the corresponding GMSC.

2. The GMSC interworks with the MGC through the Telephone User Part (TUP) or ISUP
protocol, sending the user information to the MGC.
3. The MGC registers with the GK of the H.323 network through RAS. After receiving the
multimedia call from the UMTS, the MGC forwards the call to the GK through RAS
messages.
4. The GK initiates a call to the specified H.323 terminal after receiving the user call
information about the UMTS from the MGC.
5. After the call connection is set up, the UMG8900 establishes a service channel on the service
bearer plane. If audio or video codec conversion is required during the call control
interworking, the MGC assigns appropriate service resources at the establishment of the
service bearer according to the call negotiation result.
In this networking mode, the UMG8900 achieves interworking on the three layers.
l Interworking on the media control layer
The UMG8900 implements interworking of the multimedia control protocol between the
H.324M video terminal in a UMTS CS domain and the H.323 video terminal.
The multimedia control protocols adopted by the H.324M video terminal and the H.323
video terminal are both the H.245 protocol.
The H.324M video terminal uses the different media bearer format and media codes from
the H.323 video terminal. Therefore, the H.324M and H.323 video terminals cannot directly
interwork through H.245. The UMG8900 realizes the interworking on the media control
layer.
l Interworking on the media bearer layer
The UMG8900 can convert media bearer formats between the H.324M video terminal in
a UMTS CS domain and the H.323 video terminal.
An H.324M video terminal adopts H.223 as the media bearer mode. It multiplexes control,
audio and video streams into one 64-kbit/s, 56-kbit/s or 32 kbit/s channel and then transports
them through that channel.
An H.323 video terminal adopts RTP as the media bearer mode. Audio and video streams
are encapsulated into RTP packets and then transported over Internet Protocol (IP)
networks.
The UMG8900 implements the interworking on the media bearer layer. After receiving
multiplexed H.223 streams from an H.324M video terminal, the UMG8900 de-multiplexes
them into audio and video streams, encapsulates them into RTP packets, and then transports
the packets to an H.323 terminal.
l Interworking on the media layer
The UMG8900 can convert codec formats between an H.324M mobile terminal and an H.
323 terminal.
An H.324M video terminal usually uses adaptive multirate (AMR) for audio coding, and
H.263 and MPEG-4 for video coding. An H.323 video terminal usually uses G.711 and G.
723.1 for audio coding and H.263 for video coding.
If an H.324M terminal and an H.323 terminal support different codec types during a call,
the UMG8900 realizes interworking on the media layer, for example, between AMR and
G.723.1.
Interworking Between UMTS and NGN Video Terminals

To perform multimedia communications, an H.324M video terminal in a UMTS CS domain and
a Session Initiation Protocol (SIP) terminal in an NGN interwork. See Figure 3-2.

Figure 3-2 Interworking between UMTS and NGN video terminals
NGN: next generation network UMTS: universal mobile GMSC: gateway mobile
telecommunications system switching center
SIP: Session Initiation Protocol ISUP: ISDN user part
In this networking mode, the UMG8900 can work as an entity in the NGN, the public switched
telephone network (PSTN), or the UMTS CS domain.
The UMG8900 implements interworking between the SIP video terminal in the NGN and the
H.324M terminal in the UMTS CS domain, in terms of signaling, call control, and bearer
services.
In this networking mode, the UMG8900 realizes interworking on the three layers.
l Interworking on the media control layer
The UMG8900 can implement multimedia control protocol interworking between the H.
324M video terminal in a UMG8900S CS domain and the SIP terminal in an NGN.
The H.324 video terminal adopts H.245 as the multimedia control protocol, and the SIP
terminal adopts SIP.
The UMG8900 implements the interworking on the media control layer.
l Interworking on the media bearer layer
a UMTS CS domain and the SIP terminal in an NGN.
An H.324M video terminal adopts H.223 as the media bearer mode. It multiplexes control,
audio and video streams into one 64-kbit/s, 56-kbit/s or 32-kbit/s channel and then
transports them through that channel. An SIP terminal adopts RTP as the media bearer
mode. It encapsulates audio and video streams into RTP packets and then transports them
over IP networks.
The UMG8900 implements the interworking on the media bearer layer. After receiving
multiplexed H.223 streams from an H.324M video terminal, the UMG8900 de-multiplexes
them into audio and video streams, encapsulates them into RTP packets, and then transports
the packets to an SIP terminal.
l Interworking on the media layer
a UMG8900S CS domain and the SIP terminal in an NGN.
An H.324M video terminal usually uses AMR for audio coding, and H.263 and MPEG-4
for video coding. An SIP terminal usually uses G.711 and G.723.1 for audio coding and
H.263 for video coding.

If an H.324M video terminal and an SIP terminal support different codec types during a
call, the UMG8900 realizes interworking at the media layer, for example, between AMR
and G.723.1.
Interworking Between UMTS, H.323 and NGN Video Terminals

In this mode, the NGN and H.323 networks usually take the form of an overlay network.
When the H.324M, H.323 and SIP terminals support different codec types, the UMG8900 is
used to perform service stream format conversion and transport mode adaptation. This
networking mode is equivalent to the integration of the previous two networking modes.
3.4 Configuring the Videotelephony Service

Procedure
Step 1 Run SET VMGW to set the virtual media gateway (VMGW).
Step 2 Run ADD MGC to add a media gateway controller (MGC).
Step 3 Run ADD H248LNK to add an H.248 link for transmitting control packets.
Step 4 Run ADD H245LNK to add an H.245 link for transmitting control packets.
Step 5 Run ADD GWADDR to add an IP address for the gateway for forwarding bearer packets.
----End
Example
Network diagram
Figure 3-3 shows the networking of videotelephony service.
Figure 3-3 Network diagram of videotelephony service
NOTE
The following takes the SoftX3000 as an example to describe the interconnection.

Data planning

Before configuring data, negotiate the following interconnection parameters between the
UMG8900 and the media gateway controller (MGC). See Table 3-3.
Table 3-3 Parameters between the UMG8900 and the MGC

No. Interconnection Parameter Parameter Value
1 Control protocols used between the H.248 and H.245

MGC and the UMG8900
2 Codec type of H.248 ASN.1 (binary mode)
3 IP address of the IFMI in the MGC 191.169.150.30/24
4 IP address for H.248/H.245 of the 211.169.150.41/24

UMG8900
5 IP address of the interface on the 211.169.150.254/24

router which is directly connected to
the E8T of the UMG8900
6 UDP port number of the H.248 link on 2944

the MGC
7 Local UDP port number of the H.248 2945

link on the UMG8900
8 SCTP port number of the H.245 link 4000

on the UMG8900
9 SCTP port number of the H.245 link 4000

on the MGC
10 Gateway address 192.168.0.1
11 TDM bearer to the MSC Ports 0 and 1 of E32 board 0
NOTE
When the H.248 protocol and User Datagram Protocol (UDP) transmission mode are adopted, the port
number of the MGC can only be set to 2944. When the UMG8900 uses the binary coding, it is recommended
to set its port number to 2945. When the UMG8900 uses the text coding, it is recommended to set the port
number to 2944.
//Configure the IP address and route.
//Configure the IP address of the first interface on the E8T board to carry the H.
248/H.245 link.
ADD IPADDR: BT=HRB, BN=0, IFT=ETH, IFN=0, IPADDR="211.169.150.41",
MASK="255.255.255.0", FLAG=MASTER, INVLAN=NO;
NOTE
Run ADD RSVPORT to reserve some ports of the IP interface for non-bearer services.
ADD RSVPORT: BT=HRB, BN=0, IPADDR="211.169.150.41", SPORT=0, EPORT=65535;
ADD GWADDR: BT=HRB, BN=0, IPADDR="211.169.150.41", GWIP="211.169.150.254",
TIMEOUT=NoAging;
//Configure the MGW ID.

SET VMGW: VMGWID=0, MIDTYPE=IP, MID="211.169.150.41:2945", LNKMAXHBLOSS=30,

NETTYPE=NGN;
//Configure the MGC ID.

ADD MGC: VMGWID=0, MGCIDX=0, MIDTYPE=IP, MID="191.169.150.30:2944", MSS=MASTER;
//Configure the H.248 protocol parameter.

SET H248PARA: VMGWID=0, CT=BINARY, TT=UDP;
//Configure the H.248 link.

ADD H248LNK: LINKID=0, VMGWID=0, MGCIDX=0, TT=UDP, LOCALIP="211.169.150.41",
LOCALPORT=2945, PEERIP="191.169.150.30", PEERPORT=2944, LINKNAME="To-Master MGC";
//Configure the H.245 link.

ADD H245LNK: LINKID=0, VMGWID=0, MGCIDX=0, LOCALIP="211.169.150.41",
LOCALPORT=4000, PEERIP="191.169.150.30", PEERPORT=4000, FN=1, SN=0, BP=FRONT;
//Activate the VMGW.

ACT VMGW: VMGWID=0;
//Add a gateway address for forwarding IP bearer packets.

ADD IPADDR: BT=HRB, BN=0, IFT=ETH, IFN=1, IPADDR="192.168.0.10",
TIMEOUT=NoAging;
//Add TDM bearer to the mobile switching center (MSC).

ADD TDMIU: BT=E32, BN=0, TIDFV=0, TIDLV=63, VMGWID=0, RT=EXTERN;
3.5 Protocol and Specification of the Videotelephony

Service
Table 3-4 Protocols and specifications of the videotelephony service

Videotelephony service 3GPP TS 24.008: "Mobile radio interface

layer 3 specification; Core Network Protocols
- Stage 3"

Feature Description 4 Voice Codec
4 Voice Codec
About This Chapter
protocols and specifications of the voice codec.
4.1 Overview of Voice Codec

4.2 Availability of Voice Codec
4.3 Principle and Flow of Voice Codec
4.4 Data Configuration of Voice Codec
This section describes the data configuration for enabling and maintaining this feature.
4.5 Protocol and Specification of Voice Codec

4 Voice Codec Feature Description
4.1 Overview of Voice Codec

Feature Definition
The UMG8900, a service bearer device, is required to provide the network interworking
function. The UMG8900 must convert the service stream format, because different networks
use different protocols and bearer modes.
Different voice codecs are defined in different networks and evolution stages. Thus, the codec
conversion is required if the terminals in different networks or evolution stages interwork. The
UMG8900 supports the following media stream codec algorithms, including: G.711A/μ, G.
723.1, and G.729A.
The UMG8900 performs the voice codec conversion through an independent service resource
board which is comprised of a mother board and subboards. The service resource board can
support multiple voice codecs and processing capabilities with different subboards configured.
You can select the subboards based on the actual networking requirements.
Service Benefits
Table 4-1 Service benefits of voice codec
Voice codec It enables the conversion of service It enables the conversion of the
stream format and provides the media stream format through the
network interworking function. MGW, allows the users to make
The diverse compression adaptive communication between different
algorithms can help the carriers to networks, and avoids the problems
save the bandwidth. caused by the differences in codec
formats.
Function Restrictions
Table 4-2 lists the codec set and the application supported by the UMG8900.
Table 4-2 Description of codec set
Name of Codec Description of Codec Set Application

Set
NGN Mixed codec set in the fixed network (G. Fixed network
711/G.729/G.723/G.726, T.38, fax over G.
711, (modem), V.152, RFC2833, FSK
sending, and universal features)

Name of Codec Description of Codec Set Application

Set
GSM GSM codec set (G.711A, G.711u, FR/EFR, Fixed and mobile
TFO, and universal features) network
VIG H.324M, audio codec such as AMR, G.723, Video in the fixed and
G.711A/U, and G.729, and video codec mobile networks
such as H.263 and MPEG-4
G.711_CAS_FIX G.711 and channel associated codec set (G. Fixed network
711A, G.711u, fax over G.711, modem, V.
152, RFC2833, FSK sending, universal
features, R1, and R1.5)
MPTY It provides the audio mixing function for Multiparty service in the
multiparty call, PMR call, and audio- fixed and mobile
mixing announcement playing networks
CAS R2, R1, and R1.5 Fixed and mobile

networks
G711_G729 G.711_G.729 optimized codec set (G.711/ Fixed network

G.729, T.38, Fax over G.711, modem, V.
152, RFC2833, FSK sending, and universal
features)
TDM_TONE TDM-only announcement playing codec Fixed and mobile

set (G.711) networks
General attributes include announcement playing (on the TDM side and IP side), G.711 (VAD),
DTMF digit collecting, continuity tone, R2 (MFC), R2(NMFC), TDM fax/modem tone
detection, G.711 bypass, G.711 ClearMode, RFC2833 bypass, RFC2833 DTMF, digit collecting
and playing.
l The codec function is provided by the VPU. Thus, the running VPU is reset and is restarted
if the codec capability set is modified. In this case, all sessions of the VPU are lost.
l The VIG video codec set is mutually exclusive with other codec sets.
l In one configuration command, only one codec set can be selected among NGN, VIG, G.
711_CAS_FIX, G.711_G.729, TDM_TONE, and CAS.
l Up to two types of codec set can be configured for the VPB board.
l Up to three types of codec set can be configured for the VPD board.
l The G.711_G.729 codec set can be set only when the VPD or VPE is inserted with the
VDD subboard. Otherwise, the VPD or VPE cannot start.
l If CODEC is set to MPTY, MPTYCHN is mandatory.
l If CODEC is set to CAS, CASCHN is mandatory.
l In one configuration command, the packet TC codec set is mutually exclusive with other
codec sets.
l The VPB does not support the packet TC codec set.

4.2 Availability of Voice Codec

Required NEs
Table 4-3 Required NEs for voice codec
Feature Required NE
All codecs Peer MGW
Version Support
Table 4-4 Versions supporting voice codec
G.711 A/μ codec R002 and later
G.723.1 codec
G.726 codec
G.729A codec
DTMF signals transmitted and detected with

the RFC2833 protocol
4.3 Principle and Flow of Voice Codec

4.3.1 G.711 A/Mu Codec

This section describes the implementation principles and service flow of G.711 A/Mu codec.
4.3.2 G.723.1 Codec
This section describes the implementation principles and service flow of G.723.1 codec.
4.3.3 G.726 Codec
This section describes the implementation principles and service flow of G.726 codec.
4.3.4 G.729A Codec
This section describes the implementation principles and service flow of G.729A codec.

4.3.5 DTMF Signal Transmission and Detection Through RFC2833

This section describes the implementation principles and service flow of dual tone multi-
frequency (DTMF) signal transmission and detection through RFC2833.
4.3.1 G.711 A/Mu Codec

This section describes the implementation principles and service flow of G.711 A/Mu codec.
The G.711 codec is non-compression waveform codec algorithm. Its data is from pulse code
modulation (PCM). The sampling frequency is 8000 Hz and the coding rate is 64 kbit/s. Based
on the different companding rates used in quantification, the G.711 algorithm can be classified
into A-law and Mu-law. A-law is the 13-fold-line companding rate, and Mu-law is the 15-fold-
line companding rate. The G.711 codec features easy algorithm, compression through non-linear
quantization, short delay, and high voice quality. Its disadvantage is the high data rate and high
sensitivity to the transmission channel error.
The UMG8900 supports G.711 voice codec and Mu-law/A-law conversion. It can interwork
with the public switched telephone network (PSTN).
Table 4-5 Technical specifications of the G.711 A/Mu codec
Codec Type Rate PTime Algorithm
G.711 64 kbit/s 5 ms, 10 ms, 20 ms, PCM coding of A-

and 30 ms law or Mu-law
4.3.2 G.723.1 Codec

This section describes the implementation principles and service flow of G.723.1 codec.
G.723.1 is a compressed parameter encoding mode. The sampling frequency is 8000 Hz. The
G.723.1 codec has two coding rates: 5.3 kbit/s and 6.3 kbit/s. The 5.3-kbit/s encoder adopts the
multi-pulse maximum likelihood quantization (MP-MLQ) technology. The 6.3-kbit/s encoder
adopts the algebraic code excitation linear prediction (ACELP) technology, a hybrid coding
scheme.
The G.723 codec is mainly used in multimedia communication. It is a part of the multimedia
communication standard prepared by the International Telecommunication Union (ITU). It can
also be applied in the IP telephone system. The G.723 codec features low coding rate and high
voice quality. But its delay is longer than that of other voice codec algorithms. At present, the
G.723 codec is used in the next generation network (NGN). The UMG8900 supports the G.723
codec for IP voice interworking with the NGN.
Table 4-6 Technical specifications of the G.723.1 codec
G.723.1 5.3 kbit/s 30 ms MP-MLQ
6.3 kbit/s CELP

4.3.3 G.726 Codec

This section describes the implementation principles and service flow of G.726 codec.
The G.726 codec was promoted based on G.721 and G.723 codecs in 1990 by the Consultative
Committee of International Telegraph and Telephone (CCITT), an organization named before
the International Telecommunication Union (ITU). The G.726 codec is a standard on converting
64-kbit/s non-linear pulse code modulation (PCM) signals into 40-kbit/s, 32-kbit/s, 24-kbit/s,
and 16-kbit/s adaptive differential PCM (ADPCM) signals. The G.726 codec adopts the
ADPCM, a waveform coding scheme. The coding rate can be 16 kbit/s, 24 kbit/s, 32 kbit/s, or
40 kbit/s. Each rate has four packetization durations: 5 ms, 10 ms, 20 ms, and 30 ms.
The algorithm of G.726 codec is simple, and the voice quality is high. The voice quality can be
guaranteed for multiple conversions. The voice quality at the network level can be realized from
low bit rate. And therefore, the G.726 codec is widely used in voice storage and transmission.
The G.726 codec is mainly used in the next generation network (NGN). The UMG8900 supports
the G.726 codec in IP voice interworking with the NGN.
Table 4-7 Technical specifications of the G.726 codec
G.726 16 kbit/s 5 ms, 10 ms, 20 ms, ADPCM

and 30 ms
24 kbit/s
32 kbit/s
40 kbit/s
4.3.4 G.729A Codec

This section describes the implementation principles and service flow of G.729A codec.
The G.729A algorithm is a compressed parameter encoding algorithm. The sampling frequency
is 8000 Hz. The compressed coding rate is 8 kbit/s. The G.729 codec is capable of high voice
quality for toll calls and low algorithm delay. The voice quality is the same as that of 32-kbit/s
adaptive differential pulse code modulation (ADPCM). It is widely used in the data
communications such as IP phone and H.323 system.
At present, the G.729 codec is used in the next generation network (NGN). The UMG8900
supports the G.729 codec for IP voice interworking with the NGN.
Table 4-8 Technical specifications of the G.729 codec
G.729 8 kbit/s 10 ms CS-ACELP

4.3.5 DTMF Signal Transmission and Detection Through RFC2833

frequency (DTMF) signal transmission and detection through RFC2833.
The UMG8900 supports DTMF signal transmission and detection through RFC2833.
In the application of Voice over IP (VoIP), the low-rate codec is often used to obtain the higher
bandwidth utilization. The current low rate voice encoding such as G.729 and Adaptive Multi-
Rate (AMR), however, is designed for the voice signal. The single tone signal such as DTMF
and dial tone signals can suffer from the quality loss after the low-rate voice codec, disabling
the peer end to correctly receive the single tone and affecting the performance of the services
that rely on the single tone. In other words, the IP packets in the voice encoding format are not
suitable for transmitting the single tone signal.
The Internet Engineering Task Force (IETF) formulated the RFC2833 standard to effectively
transmit the single tone signal with the high bandwidth utilization. RFC2833 provides a solution
that enables the inband transmission of single tone signal over the Real-time Transfer Protocol
(RTP). RFC2833 supports the inband transmission of multiple tones: DTMF, fax, data modem,
telephony tone, and trunk tone.
RFC2833 falls into two modes: named signal mode and tone representation mode. When the
RFC2833 transmission mode is enabled, if DTMF signals are detected in the pulse code
modulation (PCM) stream at the sending end, the UMG8900 sends the appropriate RFC2833
packets to the peer end based on the level and length of DTMF numbers.
Each DTMF signal is composed of two overlay sine waves of different frequencies. For instance,
697 Hz and 1209 Hz are used for the number 1. If the named signal mode is used, the currently
transmitted DTMF number is identified as 1 in the RFC2833 packets. If the tone representation
mode is used, the currently transmitted DTMF number is not specified in the RFC2833 packets;
the frequencies 697 Hz and 1209 Hz that are contained in the single tone signal are specified.
Based on the received frequency, the peer end determines the DTMF number as 1, and then
generates the PCM signals.
In the direction in which the packets are received, the receiving function of RFC2833 packets
is always valid. Therefore, as long as the UMG8900 receives the RFC2833 packets, it generates
the PCM data that corresponds to the DTMF number.
4.4 Data Configuration of Voice Codec

Context
To configure the codec, the key point is to choose the proper codec capability set based on the
application scenarios.
Procedure
Step 1 Run SET CODECCAP to choose the appropriate codec capability set. For the choosing method
and the precautions, see the online help for this command.
Step 2 Run SET TCPARA to set some parameters for the codec. Normally, the default values are used.
This step is optional.

Step 3 To use the RFC2833 packet to transmit the dual tone multi-frequency (DTMF) signals, run SET
RFC2833 to set the RFC2833 parameters. In general, the default settings are retained. This step
is optional.
Step 4 Run SET VMGW to set CODEC. This parameter specifies the codec format used by the MGW.
If the MGC does not specify a codec format for the UMG8900, the UMG8900 uses the codec
format specified by this parameter. This step is optional.
----End
4.5 Protocol and Specification of Voice Codec

Table 4-9 Protocols and specifications of voice codec

Codec Type Protocol and Specification
G.711 A/μ codec ITU-T Recommendation G.711
G.723.1 codec ITU-T Recommendation G.723.1
G0.726 codec ITU-T Recommendation G.726
G.729 codec ITU-T Recommendation G.729
DTMF signal transmission and detection RFC 2833

through RFC2833

Feature Description 5 Voice Quality Enhancement
5 Voice Quality Enhancement
About This Chapter
protocols and specifications of voice quality enhancement.
5.1 Overview of Voice Quality Enhancement

5.2 Availability of Voice Quality Enhancement
5.3 Principle and Flow of Voice Quality Enhancement
5.4 Data Configuration of Voice Quality Enhancement
5.5 Protocol and Specification of Voice Quality Enhancement

5 Voice Quality Enhancement Feature Description
5.1 Overview of Voice Quality Enhancement

Feature Definition
The voice quality enhancement technology is a method to enable the digital signal processing
for the pulse code modulation (PCM) stream to subjectively enhance the voice quality. The voice
quality enhancement technology includes echo cancellation (EC), voice quality enhancement
(VQE), comfort noise generation (CNG), voice activity detection (VAD), packet loss
concealment (PLC), and IP jitter buffer.
Service Benefits
Table 5-1 Service benefits of voice quality enhancement

EC EC can cancel the echo in a call, EC can effectively reduce the

improve the service quality, and echo.
enhance the customer's satisfaction
with the network service.
VQE VQE can enhance the voice quality, The voice quality is improved.
provide a reliable and good network,
and improve the competitiveness.
CNG CNG can enhance the voice quality The voice quality is improved.
VAD VAD saves about 50% of the VAD, combined with CNG, does
transmission bandwidth. not affect the call quality.
PLC PLC can enhance the voice quality The voice quality is improved.
IP jitter buffer Jitter buffer is one of the key The voice quality is improved.
technologies that guarantee the
quality of service (QoS) of the IP
network. Jitter buffer can effectively
eliminate the effects of jitter on the
quality of the real-time services.

Table 5-2 Function restrictions of voice quality enhancement
Feature Function Restriction
EC The independent ECU must be configured, or the VPU equipped with the
EC subboard must be configured. The UG01 ECU can be used only in the
SSM-256 frame.
VQE EEC, AEC and VQE cannot be converted.

The VQE subboard cannot intermix with EEC and AEC subboards. At
present, only the ECU provides 1K VQE.
The mini-UMG8900 does not support VQE and configuring the VQE
subboard on the VPD.
Only when the media gateway controller (MGC) delivers the VQE
attribute, the UMG8900 applies for VQE resources. Otherwise, the
UMG8900 applies for different ECs.
CNG None.
VAD None.
PLC None.
IP jitter buffer The jitter buffer function allows a maximum depth that can be adjusted for
the disorder of the data packet. If the maximum depth is exceeded, the
UMG8900 loses packets.
5.2 Availability of Voice Quality Enhancement

Required NEs
Table 5-3 Required NEs for voice quality enhancement
Feature Required NE
EC MGC
VQE MGC
CNG MGW
VAD MGW
PLC None
IP jitter buffer None

Version Support
Table 5-4 Versions supporting voice quality enhancement

EC R002 and later
VQE R006 and later
CNG Versions depending on the codec mode
VAD
PLC
IP jitter buffer R006 and later
5.3 Principle and Flow of Voice Quality Enhancement

5.3.1 Electrical Echo Cancellation

This section describes the implementation principles and service flow of electrical echo
cancellation (EEC).
5.3.2 Acoustic Echo Cancellation
This section describes the implementation principles and service flow of acoustic echo
cancellation (AEC).
5.3.3 Voice Quality Enhancement
This section describes the implementation principles and service flow of voice quality
enhancement (VQE).
5.3.4 Comfort Noise Generation
This section describes the implementation principles and service flow of comfort noise
generation (CNG).
5.3.5 Voice Activity Detection
This section describes the implementation principles and service flow of voice activity detection
(VAD).
5.3.6 Packet Loss Concealment
This section describes the implementation principles and service flow of packet loss concealment
(PLC).
5.3.7 IP Jitter Buffer
This section describes the implementation principles and service flow of IP jitter buffer.

5.3.1 Electrical Echo Cancellation

This section describes the implementation principles and service flow of electrical echo
cancellation (EEC).
In the communication networks, signals are usually transmitted over four wires: one signal wire
for sending signal, one signal wire for receiving signals, and two earth wires. This is a four wire
system. The users access the communication network through two wires: one signal wire for
sending and receiving the signals, plus one earth wire. This is a two wire system. Thus, at the
access point where the users access the network, a 2-wire/4-wire converter (hybrid) must be
installed to perform the conversion between two wire and four wire.
The impedance matching, however, is not ideal in the 2-wire/4-wire converter in actual
applications. Consequently, some of the signals received at the receiving end are disclosed to
the sending end on the side of the 4-wire network to generate the feedback signals. For local
telephone conversations, due to the low end-to-end delay, the echoes reach the ears of the speaker
very quickly, and therefore cannot be perceived. But for the toll calls, in particular the
international toll, the end-to-end delay is high. Therefore the echoes must be controlled by the
echo canceller.
Figure 5-1 shows the generation of electrical echoes.
Figure 5-1 Generation of electrical echoes
Red arrows in Figure 5-1 mark the transmission path of signals. The echoes are called electrical
echoes.
In the packet voice network, the voice compression and the transmitted voice packets require
longer time, so the echoes are very obvious. The echo canceller must be installed. The function
of echo canceller is implemented in the gateway. The design of the echo canceller is restricted
by entire duration for waiting for the reflected voice. This duration, which is the back end delay,
is the delay of the echoed signals from the local end of Sin end relative to the signals that Rout
end delivers to the local end.
The EEC technology supported by the UMG8900 features the following:
l The EEC technology complies with the updated G.168 2002 standard, and therefore, it
provides higher key specifications such as the convergence rate than G.168.

l The tail length of EEC can be configured from 16 ms to 128 ms to meet the requirements
on different networking conditions.
l The import delay of the echo canceller is low (< 1 ms), and therefore it can be ignored in
the overall end-to-end delay.
5.3.2 Acoustic Echo Cancellation

This section describes the implementation principles and service flow of acoustic echo
cancellation (AEC).
Owing to the design of the telephone, echoes are reflected from the speaker to the tone collector,
and echoed signals occur. The echoes are called acoustic echoes.
Generally, the echo delay is about 30 ms, and it can be felt. If the delay is longer than 50 ms,
session quality is severely affected. International Telecommunication Union -
Telecommunication Standardization Sector (ITU-T) G.131 and ITU-T G.161 deems that when
the echo delay is longer than 25 ms, the echo can be felt, and the echo control device needs to
be installed.
5.3.3 Voice Quality Enhancement

This section describes the implementation principles and service flow of voice quality
enhancement (VQE).
The VQE technology is a method that is designed to enable the digital signal process for the
pulse code modulation (PCM) stream to subjectively enhance the voice quality. The VQE
technology includes: adaptive noise restraint (ANR), adaptive noise compensation (ANC),
adaptive gain control (AGC), and adaptive acoustic echo cancellation (AEC).
ANR restrains the input noise according to the volume of the input noise when the speaker is in
a noisy environment, such as the bus stop, square and street. Subjectively, the speaker does not
feel the input voice quality is decreased. In this way, the voice articulation and the
understandability is enhanced, and the discomfort caused by the background noise is eliminated.
ANR in the preceding diagram is unidirectional. The background noise on only the mobile phone
side is eliminated, which is good to the public switched telephone network (PSTN) side. ANR
of the UMG8900 can be bidirectional. Thus, when the two ends have greater background noise,
both ends benefit.
ANC can either be used jointly with ANR or be used separately. ANC functions like this: When
one end is within noisy background, ANC can improve the strength of the voice signal from the
remote end to make this local end hear the remote end more clearly. Generally, people feel
comfortable during the call when the voice energy is around -18 dBm.
AGC adaptively adjusts the energy of the input and output voice signals, manages the stronger
and weaker voice signals effectively, improves the listening comfort, and enhances the subjective
voice quality.
AEC is mainly applied in the acoustic echo environment. The typical environment is the radio
communication, handsfree call and conference call. AEC cancels the acoustic echoes caused by
the multipath effect and improves the voice quality. In particular, AEC can cancel the acoustic
echoes between the tone collector and the earpiece of the mobile phone.
Under the softswitch separate architecture, MGC delivers the VQE feature to the UMG8900
under the management of the Mc interface. The MGC delivers the packet attribute to the
UMG8900 to indicate the need for increasing the VQE resources. The packet definitions are:
switch and direction (beneficial for the local end, the remote end, or both ends) of ANR and

AGC, and the switch of ANC. In the case of poor communication environment, increasing the
VQE resources can improve the session quality effectively.
The VQE resources are provided through the VQE subboard on the ECU. The VQE subboard
also provides the electrical echo cancellation (EEC) and AEC functions. Run DSP
MEDIARES to check the availability of the VQE resources in the system.
5.3.4 Comfort Noise Generation

This section describes the implementation principles and service flow of comfort noise
generation (CNG).
CNG works with voice activity detection (VAD). On condition that VAD is supported, complete
silence occurs if no packet is sent during the silent period. In this case, receivers feel unnatural
like the call is disconnected. Thus, CNG must be installed at the receiving end.
CNG is a device of the receiving end. Receivers use a mechanism to regenerate the main features
of the comfort noise. Parameters of comfort noise are designated by the transmitting end.
The design of comfort noise generation must ensure the synchronization between a coder and a
decoder. Even if the coder sends no bit in a period, the decoder can interpret it correctly to
implement the smooth transition between the voice segment and no-voice segment of the restored
voice.
5.3.5 Voice Activity Detection

This section describes the implementation principles and service flow of voice activity detection
(VAD).
The purpose of VAD is to identify and eliminate the long period of silence from the voice signal
flow to save the voice channel resources without degrading the service quality. VAD is an
important component of the IP call application.
VAD can save the valuable bandwidth resources, and helps to reduce the end-to-end delay
perceived by the users.
A user does not always occupy the voice channel during a call. The statistics of conventional
telephony services indicate that one party actually occupies the voice channel no more than 40%
of the whole session, because this party:
l Listens to the other party
l Thinks, rests or pauses for a while during the conversation
l Hesitates and breathes during the conversation
In the first case, the pause is longer and occurs less. In the third case, the pause is shorter and
occurs more. In the second case, the pause duration and its occurrence frequency are between
the first and the third case.
The basic principle of VAD is to assess the voice signal energy. The silence state indicates that
the voice signal energy is below a certain threshold. If a silence segment is detected in the session,
the sending end instructs the decoder of the peer end through the silence descriptor (SID). If the
encoder sends the SID, it does not send the voice packets until it detects the voice activity again.
The CNG technology is introduced on the decoder side to prevent users from thinking that the
call is disconnected when the decoder has no voice output during the silence. When receiving
the SID, the decoder synthesizes the background state based on the background noise features
of the encoder side specified in the SID. In this way, the user perceives the presence and

continuity of the session. VAD/DTX/CNG work together as a unity. They improve the
bandwidth utilization by reducing the transmission bandwidth.
VAD faces two technical difficulties: One is how to detect the silence in noisy environment, and
the other is clipping. The clipping means there are time threshold and assessment threshold from
communication to silence or from silence to communication. Thus, when a user speaks after the
silence, the first words may be discarded because they are weak and regarded as the silence
segment. To solve this problem, a voice packet must be added before a burst voice packet for
migration. The clipping after the burst voice can also be solved by this method.
5.3.6 Packet Loss Concealment

This section describes the implementation principles and service flow of packet loss concealment
(PLC).
Due to the network congestion, buffer overflow, and error bit, packets are frequently lost in the
connectionless IP network. The real-time data flows, such as voice packets, has a strict sequence,
and therefore, discarding them is better than re-transmitting them.
The algorithm of the voice compression encoding technology used by the IP call takes the frame
as the unit, and it is sensitive to packet loss. Continuous frame loss can substantially affect the
understandability, naturalness and clarity of the synthesized voice at the receiving end.
To avoid the effect of the packet loss, the PLC algorithm is used. According to the relevance of
the previous and succeeding voice, the lost frames are regenerated during the decoding to ensure
the quality of the received voice.
The International Telecommunication Union - Telecommunication Standardization Sector

(ITU-T) stipulates that the maximum length of PLC is 60 ms, because the theory of "Short time
and stability" is meaningless after 60 ms.
5.3.7 IP Jitter Buffer

This section describes the implementation principles and service flow of IP jitter buffer.
The IP network is an unreliable transmission network, and thus when different packets are
transmitted over the IP network, they are delayed differently. Therefore, the interval and
sequence of the packets reaching the receiving end cannot be guaranteed to be the same as those
when the packets are sent from the transmitting end, and as a result, jitter occurs. If the packets
are directly encoded without being buffered, the voice quality decreases. If jitter happens to data
services, they are affected without the jitter elimination.
To address the issue of jitter and confused order of the IP network, the jitter buffer algorithm of
the UMG8900 is used to ensure the decoder decodes in sequence without jitter. All jitter buffer
algorithms involve delay while eliminating network jitter. The jitter buffer algorithm of the
UMG8900 can rapidly trace network jitter and dynamically self-adjust the depth of buffer. Thus,
voice quality is ensured and end-to-end delay is decreased to the least in different network
conditions. The jitter buffer algorithm of the UMG8900 ensures the delay does not occur due to
out-of-synchronization of gateway clocks of two parties in long time session.
The basic principle of jitter buffer is to buffer received messages and then play and process them
to eliminate jitter.
Figure 5-2 shows the basic function of jitter buffer.

Figure 5-2 Principle of jitter buffer
After data packets are transmitted through the IP network to the MGW, the sequence of data
packets changes. The MGW puts the received data packets in jitter buffer and adjusts them to
the original sending sequence based on header indications. Then, the MGW performs further
processing.
Jitter buffer can be classified into static jitter buffer and dynamic jitter buffer.
l Static jitter buffer
The static jitter buffer indicates the buffer depth is a fixed preset value. Received messages
must be buffered for a fixed time before they are played. The buffer depth does not change
with network condition. If the buffer depth is less than network jitter, the jitter cannot be
completely eliminated. Conversely, the jitter can be completely eliminated. At the same
time, the end-to-end delay is increased. The static jitter buffer is used for the data service
that is sensitive to packet loss.
l Dynamic jitter buffer
The dynamic jitter buffer calculates the network delay based on the time of sending and
receiving messages and performs statistical average on the change of message delay. The
dynamic jitter buffer predicts network jitter based on the history statistic result and adjusts
the depth of jitter buffer to trace network condition and eliminate jitter with the minimum
delay.
Assume that Si is the RTP timestamp, that is, sending time of message, of message i. Ri is
the time when the message is received by the receiving end. The jitter of message i and
message j is:
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (R i- Si)
The value D is calculated when each message is received. Then, the value D is performed
statistical average according to the following formula to obtain the estimated value J of
network jitter, that is, the depth of jitter buffer.
J = J + (|D(i,j)| - J) x v. The value v is a weighting factor. The v = 1/16 is recommended in
RFC3550.
The dynamic jitter buffer is applicable to such real-time service as the voice service that is
insensitive to packet loss because packet loss may occur during the adjustment process of
jitter buffer depth.
5.4 Data Configuration of Voice Quality Enhancement


Context
All functions involved in the voice quality enhancement feature are optional. Normally, the
default values shall be used. To change the feature parameters, perform the following steps.
Procedure
Step 1 By default, the electrical echo cancellation (EEC) tail length of the system is 64 ms, the acoustic
echo cancellation (AEC) tail length is 400 ms, and the network layer packet (NLP) and comfort
noise generation (CNG) functions are supported. For the echo cancellation, the default value of
the system shall be used. In the networking application, if the echo occurs with the default
configuration, the tail length value may be increased. Run SET ECPARA to modify the EC
parameters. This step is optional.
Step 2 For the voice quality enhancement (VQE) function, the default value of the system is used. Run
SET VQEPARA to modify the VQE parameters, including the noise restraint level, the noise
compensation amount and rate, and auto gain capability and rate. This step is optional.
Step 3 The UMG8900 works with the media gateway controller (MGC) to enable the tandem free
operation (TFO) without other configurations. The UMG8900 provides a switch for TFO
optimization mode. To support the TFO function, the switch must be set to Enable. Run SET
TCPARA to set TFO optimize mode to Enable. This step is optional.
Step 4 Run SET TCPARA to set VAD option and Packet Loss compensation. This step is optional.
Step 5 For the jitter buffer function, the default value of the system shall be used. Run SET
JBUPARA to set 3G transcoder free operation (TrFO). Run SET TCPARA to configure others.
This step is optional.
----End
5.5 Protocol and Specification of Voice Quality

Enhancement
Table 5-5 Protocol and specification of voice quality enhancement
EC AEC: International Telecommunication Union - Telecommunication

Standardization Sector (ITU-T) G.131 and ITU-T G.161
EEC: G.168 2002
VQE Draft of ITU-T G.160
CNG Defined by the appropriate voice codec algorithm
VAD
PLC
IP jitter buffer None

Feature Description 6 Narrowband Common Channel Signaling Adaptation
6 Narrowband Common Channel Signaling

Adaptation
About This Chapter
protocols and specifications of narrowband common channel signaling (CCS) adaptation.
6.1 Overview of Narrowband Common Channel Signaling Adaptation
6.2 Availability of Narrowband Common Channel Signaling Adaptation
6.3 Principle and Flow of Common Channel Signaling Adaptation
6.4 Data Configuration of Narrowband Common Channel Signaling Adaptation
6.5 Protocol and Specification of Narrowband Common Channel Signaling Adaptation

6 Narrowband Common Channel Signaling Adaptation Feature Description
6.1 Overview of Narrowband Common Channel Signaling

Adaptation
Feature Definition
When a softswitch is applied in the public switched telephone network (PSTN) networking, the
access network device or external network switch that is connected to the softswitch often adopts
the narrowband signaling and uses the traditional time division multiplexing (TDM) interface
for connection. In this case, the softswitch needs to support the TDM interface.
When acting as a local exchange in networking, a softswitch is connected to several PSTN
switches. If every PSTN switch is directly connected to the softswitch, the networking topology
is complicated and the cost for network construction is high.
The UMG8900 supports the function of embedded signaling gateway (SG). The adaptation of
narrowband signaling to the broadband packet mode can be realized and thus narrowband
signaling can be sent by the IP packet network of the core network (CN) to the softswitch. In
this case, the networking mode is simple.
Narrowband common channel signaling (CCS) adaptation is mainly used in the traditional TDM
networking, including PSTN networking. The adaptation of the narrowband CCS to the
broadband packet mode is realized.
The UMG8900 supports various narrowband CCS adaptation functions. These functions are
realized through independent boards. Thus, capacity expansion is flexible and convenient. The
supported functions include:
l 64 kbit/s MTP2 signaling link packet adaptation
l 64 kbit/s MTP3 signaling link packet adaptation
l 2 Mbit/s MTP2 signaling link packet adaptation
l 2 Mbit/s MTP3 signaling link packet adaptation
l Q.921 signaling link packet adaptation
l LAPV5 signaling link packet adaptation
The narrowband CCS adaptation function is mainly for the lower-layer adaptation, not the upper-
layer application messages. Standard protocols are adopted at the transport layer and no
interworking exists.

Service Benefits
Table 6-1 Service benefits of narrowband common channel signaling adaptation

Narrowband common This feature provided by the This function is invisible

channel signaling UMG8900 can simplify the network to the users.
adaptation topology structure and thus help reduce
the cost for network construction and
maintenance.
Table 6-2 Function restrictions of narrowband common channel signaling adaptation

Narrowband common The SPF must be configured for the narrowband CCS adaptation
channel signaling function.
adaptation
6.2 Availability of Narrowband Common Channel

Signaling Adaptation
Required NEs
Table 6-3 Required NEs for narrowband common channel signaling adaptation
Feature Required NE
MTP2-M2UA signaling gateway MGC, MGW, and PSTN switch
MTP3-M3UA signaling gateway MGC, MGW, and PSTN switch
IUA-based PRI message transfer MGC, MGW, and PBX
V5UA transferring LAPV5 messages MGC, MGW, and AN

Version Support
Table 6-4 Versions supporting narrowband common channel signaling adaptation

MTP2-M2UA signaling gateway V100R002 and later
MTP3-M3UA signaling gateway V200R002 and later
IUA-based PRI message transfer V100R002 and later
V5UA-based LAPV5 message transfer V100R002 and later
6.3 Principle and Flow of Common Channel Signaling

Adaptation
The UMG8900 and media gateway controller (MGC) appear as one device. The UMG8900
works as the embedded signaling gateway (SG) for signaling adaptation and conversion for
further processing in the MGC.
Figure 6-1 UMG8900 supporting the embedded SG function

The embedded SG function means that the media gateway (MGW) acts as an SG. When users
access the network, the embedded SG forwards the subscriber signaling. This networking mode
is flexible, and the networking architecture is simplified. The UMG8900 supports the embedded
SG mode, as well as the semi-permanent connection for signaling conversion.
The UMG8900 uses the same core processing board and signaling processing path to process
the and V5 protocols, signaling system No. 7 (SS7) and digital subscriber signaling No.1 (DSS1).
6.3.1 64-kbit/s MTP2-M2UA Signaling Gateway
This section describes the implementation principles and service flow of 64-kbit/s MTP2-M2UA
signaling gateway (SG).
This section describes the implementation principles and service flow of the 64-kbit/s MTP3-
M3UA signaling gateway (SG).
6.3.3 2-Mbit/s MTP2-M2UA Signaling Gateway
This section describes the implementation principles and service flow of 2-Mbit/s MTP2-M2UA
6.3.5 IUA-Based PRI Message Transfer
This section describes the implementation principles and service flow of ISDN Q.921-User
Adaptation Layer (IUA) based primary rate interface (PRI) message transfer.
6.3.6 V5UA-Based LAPV5 Message Transfers
This section describes the implementation principles and service flow of how V5 User
Adaptation Layer (V5UA) transfers V5 signaling processing board (LAPV5) messages.

This section describes the implementation principles and service flow of 64-kbit/s MTP2-M2UA
Implementation Principles
For the signaling system No.7 (SS7), the independent SG can be used for interworking between
the SS7 and the media gateway controller (MGC), or the media gateway (MGW) can be used
to forward the SS7 so that the SG function is realized in the MGW. In this networking mode,
the SS7 is accessed to the MGW, and forwarded through the Signaling Transport (SIGTRAN)
protocol between the MGW and the MGC.
The UMG8900 supports the signaling adaptation function based on the SIGTRAN protocol. The
adaptation of the SS7 from the access network side to the MGC in the core network is processed
through MTP2 User Adaptation layer (M2UA).
Figure 6-2 shows the structure of the protocol stack for the SS7 signaling adaptation based on
the M2UA protocol.

Figure 6-2 Structure of protocol stack adapting the SS7 signaling over M2UA
M2UA: MTP2 User Adaptation MTP: Message Transfer Part SEP: signaling endpoint
Layer
S7UP: SS7 user part NIF: node interworking function MGC: media gateway controller
MAC: media access control SCTP: Stream Control Transmission

Protocol
The UMG8900 resolves signaling at the MTP2 and lower layers, and adapts the application
signaling at the MTP3 and upper layers through M2UA. Reliability management for the
signaling network is realized through the MTP3 on the MGC. Through the M2UA protocol, the
MTP2 links are adapted on the UMG8900. The UMG8900 only needs to process the SS7
signaling at the MTP2 layer and then forward the signaling through M2UA protocol to the MGC.
When the MTP2 link is MTP2_64K, the link occupies one timeslot only. You only need to set
Start Timeslot No..
Service Flow
Figure 6-3 shows the forwarding flow for the SS7 signaling in the SSM-256 frame.

Figure 6-3 SS7 signaling transfer path in an SSM-256 frame
The following lists the SS7 signaling transfer process in M2UA mode in the SSM-256 frame:
1. After accessing the narrowband signaling of the time division multiplexing (TDM) side
through a TDM interface board such as the back E32, the UMG8900 resolves the signaling
at MTP1. Then, the UMG8900 forwards the narrowband signaling at and above MTP2 to
an SPF through the switching of internal TDM timeslots.
2. After receiving the signaling from the TDM side, the SPF resolves and exchanges the
messages at MTP2 through its subboards. Then, the subboards extract signaling messages
at and above MTP3 on the TDM side and forward them to the SPF mother board.
3. Based on the device configuration, the SPF mother board adapts the received signaling
messages at and above MTP3 in M2UA mode. In addition, the SPF mother board
encapsulates the messages based on Simple Control Transmission Protocol (SCTP) or
Internet Protocol (IP). Then, the SPF mother board sends the messages to the MPU or OMU
through the internal FE bus.
4. After receiving the SIGTRAN messages, the MPU or OMU modifies the media access
control (MAC) addresses in the data packets. Then, it forwards the packets to the MGC
through the back NET.
5. For the signaling messages from the MGC, the handling process is the same, but in the
reverse direction.

This section describes the implementation principles and service flow of the 64-kbit/s MTP3-
M3UA signaling gateway (SG).

through M3UA.
M3UA.
M3UA: MTP3 User Adaptation MTP: Message Transfer Part MGC: media gateway controller
Layer
S7UP: SS7 User Part NIF: node interworking function SCTP: Stream Control Transmission
Protocol
MAC: media access control
The UMG8900 resolves signaling at and above MTP3, and forwards the application layer
signaling after adapting the signaling through M3UA. Reliability management for the signaling
network is realized through MTP3 of the UMG8900.
When the MTP2 link is MTP2_64K, the link occupies one timeslot only. You only need to set
Start Timeslot No..
Service Flow

The following lists the process of forwarding the SS7 signaling in M3UA adaptation mode.
1. After accessing the narrowband signaling of the local exchange (LE) side through a TDM
interface board such as the back E32 or S2L, the UMG8900 resolves the signaling at MTP1.
Then, the UMG8900 forwards the narrowband signaling at and above MTP2 to an SPF
through the switching of internal TDM timeslots.
2. After receiving the TDM side signaling, the SPF resolves and exchanges the messages at
MTP2 through its subboards. Then, the SPF subboards extract signaling messages at MTP3
and forward them to the SPF mother board.
3. According to the device configuration, the SPF mother board adapts the received signaling
messages at MTP3 and encapsulates the messages above MTP3 based on M3UA. In
addition, the SPF mother board encapsulates the messages based on Simple Control
Transmission Protocol (SCTP) or Internet Protocol (IP). Then, the SPF mother board sends
them to the MPU or OMU through the internal FE bus.
through the back interface board.
reverse direction.


through MTP2 User Adaptation layer (M2UA).
the M2UA protocol.
M2UA: MTP2 User Adaptation MTP: Message Transfer Part SEP: signaling endpoint
Layer
S7UP: SS7 user part NIF: node interworking function MGC: media gateway controller

Protocol
The UMG8900 resolves signaling at the MTP2 and lower layers, and adapts the application
signaling at the MTP3 and higher layers through M2UA. Reliability management for the
signaling network is realized through the MTP3 on the MGC. Through the M2UA protocol, the
MTP2 links are adapted on the UMG8900. The UMG8900 only needs to process the SS7
signaling at the MTP2 layer and then forward the signaling through M2UA protocol to the MGC.
When the MTP2 link is MTP2_2M, the link occupies multiple 64 kbit/s timeslots. In this case,
End Timeslot No. must be configured.
Service Flow

The following lists the SS7 signaling transfer process in M2UA mode in the SSM-256 frame.
1. After accessing the narrowband signaling of the time division multiplexing (TDM) side
through a TDM interface board such as the back E32, the UMG8900 resolves the signaling
at MTP1. Then, the UMG8900 forwards the narrowband signaling at and above MTP2 to
an SPF through the switching of internal TDM timeslots.
2. After receiving the signaling from the TDM side, the SPF resolves and exchanges the
messages at MTP2 through its subboards. Then, the subboards extract signaling messages
at and above MTP3 on the TDM side and forward them to the SPF mother board.
messages at and above MTP3 in M2UA mode. In addition, the SPF mother board
encapsulates the messages based on Simple Control Transmission Protocol (SCTP) or
Internet Protocol (IP). Then, the SPF mother board sends the messages to the MPU or OMU
through the internal FE bus.
reverse direction.


through M3UA.
M3UA.
M3UA: MTP3 User Adaptation MTP: Message Transfer Part MGC: media gateway controller
Layer
S7UP: SS7 User Part NIF: node interworking function SCTP: Stream Control Transmission
Protocol
MAC: media access control
The UMG8900 resolves signaling at and above MTP3, and forwards the application layer
signaling after adapting the signaling through M3UA protocol. Reliability management for the
signaling network is realized through MTP3 of the UMG8900.
When the MTP2 link is MTP2_2M, the link occupies multiple 64 kbit/s timeslots. In this case,
End Timeslot No. must be configured.
Service Flow

The following lists the process of forwarding the SS7 signaling in M3UA adaptation mode.
1. After accessing the narrowband signaling of the TDM side through a TDM interface board
such as the back E32 or S2L, the UMG8900 resolves the signaling at MTP1. Then, the
UMG8900 forwards the narrowband signaling at and above MTP2 to an SPF through the
switching of internal TDM timeslots.
2. After the SPF receives the forwarded TDM side signaling, it first resolves and exchanges
the messages at MTP2 through its subboards. Then, the SPF subboards extract signaling
messages at MTP3 and forward them to the SPF mother board.
messages at MTP3 and encapsulates the messages above MTP3 based on M3UA. In
addition, the SPF mother board encapsulates the messages based on Simple Control
Transmission Protocol (SCTP) or Internet Protocol (IP), and sends them to the OMU or
MPU through the internal FE bus.
4. After receiving the SIGTRAN messages, the OMU or MPU modifies the media access
reverse direction.
6.3.5 IUA-Based PRI Message Transfer

This section describes the implementation principles and service flow of ISDN Q.921-User
Adaptation Layer (IUA) based primary rate interface (PRI) message transfer.
The UMG8900 uses the standard Signaling Transport (SIGTRAN) protocol for adaptation and
forwarding of time division multiplexing (TDM) based DSS1 signaling to the Internet Protocol
(IP) packet mode. The UMG8900 uses IUA for adaptation of digital subscriber signaling No.1

(DSS1) signaling from the access network to the media gateway controller (MGC) of the core
network.
Figure 6-10 shows the structure of the protocol stack adapting the DSS1 signaling based on
IUA.
Figure 6-10 Structure of protocol stack adapting the DSS1 signaling over IUA
IUA: ISDN Q.921-User Adaptation Q.921: Data Link Layer Protocol over Q.931: Layer 3 Protocol over the
Layer the ISDN User Network Interface ISDN User Network Interface
PBX: private branch exchange NIF: node interworking function MGC: media gateway controller

Protocol
The SPF of the UMG8900 performs adaptation of the DSS1 common channel signaling. In
addition, the SPF resolves the transport layer messages on the narrowband TDM side and
performs adaptation on the IP packet side.
The SPF includes subboards and the mother board. The SPF mother board is referred to as the
SPF hereinafter. The subboards resolve and exchange the narrowband TDM side signaling at
the transport layer while the SPF adapts the signaling to the IP packet mode.
Service Flow
Figure 6-11 shows the forwarding flow for the DSS1 signaling in the SSM-256 frame.

Figure 6-11 DSS1 signaling transfer path in an SSM-256 frame
The forwarding process of DSS1 signaling in the IUA mode is described as follows:
1. After receiving the narrowband signaling of the TDM side through a TDM interface board
such as the back E32 or S2L, the UMG8900 resolves the signaling at MTP1. Then, the
UMG8900 forwards the narrowband signaling at and above MTP2 to an SPF through the
internal TDM timeslots.
MTP2 through its subboards. Then, the SPF subboards extract signaling messages at MTP3
and forward them to the SPF.
3. The SPF performs IUA adaptation for the narrowband signaling messages based on the
configuration. The SPF performs SCTP/IP encapsulation and sends the packets to the
specified interface through the internal fast Ethernet (FE) bus.
reverse direction.
6.3.6 V5UA-Based LAPV5 Message Transfers

This section describes the implementation principles and service flow of how V5 User
Adaptation Layer (V5UA) transfers V5 signaling processing board (LAPV5) messages.
Working Principles
The UMG8900 uses the standard Signaling Transport (SIGTRAN) protocol for adaptation and
forwarding of time division multiplexing (TDM) based V5 signaling to the Internet Protocol
(IP) packet mode. The UMG8900 uses V5UA for adaptation of V5 signaling from the access
network to the media gateway controller (MGC) of the core network.
Figure 6-12 shows the structure of the protocol stack adapting the V5 signaling based on V5UA.

Figure 6-12 Structure of protocol stack adapting the V5 signaling over V5UA
V5UA: V5.2 User Adaptation Layer LAPV5: LAPV5 Data Link Layer AN: access network
Protocol
NIF: node interworking function MGC: media gateway controller MAC: media access control
SCTP: Stream Control Transmission

Protocol
The SPF of the UMG8900 performs adaptation of the V5 common channel signaling. In addition,
the SPF resolves the transport layer messages on the narrowband TDM side and performs
adaptation on the IP packet side.
The SPF includes subboards and the mother board. The SPF mother board is referred to as the
SPF hereinafter. The subboards resolve and exchange the narrowband TDM side signaling at
the transport layer while the SPF adapts the signaling to the IP packet mode.
Service Flow
Figure 6-13 shows the forwarding flow for the V5 signaling in the SSM-256 frame.

Figure 6-13 V5 signaling transfer path in an SSM-256 frame
The forwarding process of V5 signaling in V5UA mode is described as follows:

1. After receiving the V5 protocol of the public switched telephone network (PSTN) switch
through a TDM interface board such as the back E32 or S2L, the UMG8900 resolves the
signaling at layer 1. Then, the UMG8900 forwards the narrowband signaling at and above
LAPV5 to an SPF through the internal TDM timeslots.
LAPV5 through its subboards. Then, the SPF subboards extract signaling messages and
forward them to the SPF.
3. The SPF performs V5UA adaptation for the narrowband signaling messages based on the
configuration. The SPF performs Simple Control Transmission Protocol (SCTP) or IP
encapsulation and sends the packets to the specified interface through the internal fast
Ethernet (FE) bus.
reverse direction.
6.4 Data Configuration of Narrowband Common Channel

6.4.1 Data Configuration of 64-kbit/s MTP2-M2UA Signaling Gateway

This section describes the data configuration for enabling and maintaining 64-kbit/s MTP2-
M2UA signaling gateway.
6.4.2 Data Configuration of 64-kbit/s MTP3-M3UA Signaling Gateway
6.4.3 Data Configuration of 2-Mbit/s MTP2-M2UA Signaling Gateway

This section describes the data configuration for enabling and maintaining 2-Mbit/s MTP2-
6.4.4 Data Configuration of 2-Mbit/s MTP3-M3UA Signaling Gateway
6.4.5 Data Configuration of IUA-Based PRI Message Transfer
This section describes the data configuration for enabling and maintaining IUA-based PRI
message transfer.
6.4.6 Data Configuration of V5UA-Based LAPV5 Message Transfer
This section describes the data configuration for enabling and maintaining V5UA-based LAPV5
message transfer.
6.4.1 Data Configuration of 64-kbit/s MTP2-M2UA Signaling

Gateway
Prerequisite
The Signaling Transport (SIGTRAN) interface is correctly configured on the UMG8900.
Index Mapping of Configuration Command Parameters

Figure 6-14 shows the index mapping of the configuration command parameters of the SG over
M2UA.
Figure 6-14 Index mapping of main parameters in M2UA-based signaling gateway

Procedure
l Configuring the data to the MGC
1. Run SET SCTPINIT to set the SCTP protocol parameters.
2. Run ADD L2UALKS to add an L2UA link set. Use only one link set to the master
and slave MGCs. Set Protocol type to M2UA.
3. Run ADD L2UALNK to add an L2UA link to the master MGC. Set Protocol type
to M2UA, and Priority to 0.
4. Run ADD L2UALNK to add an L2UA link to the slave MGC. Set Protocol type to
M2UA, and Priority to 1.
5. When the remote address is identified in the domain name, run SET DNSSVR to
configure the domain name server (DNS).
l Configuring the data to the access network device
1. Run ADD MTP2LNK to add an MTP2 link. Set Link type to M2UA 64K LINK.
----End
Example
Network diagram
Figure 6-15 shows the network diagram of the signaling transfer over M2UA in the SSM-256
frame.
Figure 6-15 Network diagram
Configuration script
SET SCTPINIT: BT=SPF, BN=0, CHKSUM=CRC32;
//Add an L2UA link set.

ADD L2UALKS: PROTYPE=M2UA, LKSNAME="AMGC1", LKS=0, TM=LOADSHARE, DLP=DISCARD;
ADD L2UALNK: PROTYPE=M2UA, BN=0, LNKNO=0, LNKNAME="M2UALNK-1", LKS=0,
LOCALPN=2000, LOCALIP1="10.1.1.1", REMOTEPN=2000, REMOTEIP1="192.168.0.1",
PRIO=0;


PRIO=1;
l Configuring the data to the PSTN switch

ADD MTP2LNK: LNKNO=0, IFBT=E32, IFBN=0, E1T1N=0, STRTTS=16, SPFBN=0, SUBBN=0,
LNKTYPE=M2UA64 kbit/s, LKS=0, BINIFID=2;
6.4.2 Data Configuration of 64-kbit/s MTP3-M3UA Signaling

Gateway
Prerequisite
l The Signaling Transport (SIGTRAN) interface is correctly configured on the UMG8900.

Figure 6-16 shows the index mapping of the major configuration command parameters of the
signaling transfer over M3UA.
Figure 6-16 Index mapping of configuration commands of the signaling transfer based on
M3UA

Procedure
1. Run ADD M3LE to add an M3UA local entity. Set Local Entity Type to SG
(signaling_Gateway).
2. Run ADD M3DE to add an M3UA destination entity. Set Destination Entity Type
to AS (Application_Server). The master and slave MGCs share one signaling point.
3. Run ADD M3LKS to add an M3UA link set. If dual homing is configured, set Discard
messages from lower priority link to DISCARD (YES). Otherwise, use the default
value of the parameter.
4. Run ADD M3RT to add an M3UA route.
5. Run ADD M3LNK to add an M3UA link to the master MGC. Set CS Mode to
SERVER, Active Standby Flag to Active, and Priority to 0.
6. If dual homing is configured, run ADD M3LNK to add an M3UA link to the slave
MGC. Set CS Mode to SERVER and Active Standby Flag to Active. The priority
level of the M3UA link to the slave MGC must be lower than that of the M3UA link
to the master MGC. Thus, set Priority to 1.
l Configuring the data to the interconnected device
1. Run ADD N7DSP to add a destination signaling point. Set Network indicator to
National reserved network.
2. Run ADD N7LKS to add an N7 link set.
3. Run ADD N7RT to add an N7 route.
4. Run ADD MTP2LNK to add an MTP2 link. Set Link type to MTP3 64K LINK.
5. Run ADD N7LNK to add an N7 link.
----End
Example
Network diagram
Figure 6-17 shows the network diagram of the signaling transfer over M3UA.
Figure 6-17 Network diagram of the signaling transfer over M3UA

ADD M3LE: LEX=0, LEN="AUMG89001", LET=SG, NI=NAT, OPC=H'aaaaaa;
ADD M3DE: DEX=0, DEN="AMGC1", DET=AS, NI=NAT, DPC=H'bbbbbb, LEX=0;
//Configure dual homing, and set Discard messages from lower priority link to
YES.
ADD M3LKS: LSX=0, LSN="AMGC1", ADX=0, DLP=DISCARD;
ADD M3RT: RN="AMGC1_1", DEX=0, LSX=0;
//Add an M3UA link to the master MGC.

ADD M3LNK: LNK=0, BT=SPF, BN=0, LKN="AMGC_1", LIP1="10.1.1.5", LP=4000,
RIP1="192.168.0.1", RP=4000, CS=SERVER, PR=0, LSX=0, ASF=ACTIVE;
//Add an M3UA link to the slave MGC. The priority level of the M3UA link to the
slave MGC must be lower than that of the M3UA link to the master MGC.
ADD M3LNK: LNK=1, BT=SPF, BN=0, LKN="AMGC1_2", LIP1="10.1.1.1", LP=5000,

ADD N7DSP: INDEX=0, NAME="APSTN1", NI=NAT, DPC=H'cccccc, OSPINDEX=0;
ADD N7LKS: INDEX=0, NAME="APSTN1", DSPIDX=0;
//Use timeslot 16 of port 16 on E32 board 0.

ADD MTP2LNK: LNKNO=0, LNKNAME="APSTN1_1", IFBT=E32, IFBN=0, E1T1N=16,
STRTTS=16, SPFBN=0, SUBBN=0, LNKTYPE=MTP364K, LKS=0;
//Configure the MTP3 route.

ADD N7RT: INDEX=0, NAME="APSTN1", LKSIDX=0, DSPIDX=0;
ADD N7LNK: INDEX=0, NAME="APSTN1_1", LKSIDX=0, SLC=0, MTP2NO=0;
6.4.3 Data Configuration of 2-Mbit/s MTP2-M2UA Signaling

Gateway
Prerequisite

M2UA.

Figure 6-18 Index mapping of main parameters in M2UA-based signaling gateway
Procedure
1. Run SET SCTPINIT to set the SCTP protocol parameters.
and slave MGCs. Set Protocol type to M2UA.
to M2UA, and Priority to 0.
M2UA, and Priority to 1.
1. Run MOD SPFSUBRD. Set Configure mode to PRO_2M.
2. Run ADD MTP2LNK to add an MTP2 link. Set Link type to M2UA 2M LINK.
----End
Example
Network diagram
Figure 6-19 shows the network diagram of the signaling transfer over M2UA in the SSM-256
frame.


ADD L2UALKS: PROTYPE=M2UA, LKSNAME="AMGC1", LKS=0, TM=LOADSHARE, DLP=DISCARD;
PRIO=0;
PRIO=1;

MOD SPFSUBRD: SPFBN=0, SUBBN=0, CM=PRO_2M;
ADD MTP2LNK: LNKNO=0, LNKNAME="MTP2-1", IFBT=E32, IFBN=0, E1T1N=0, STRTTS=16,
ENDTS=18, SPFBN=0, SUBBN=0, LNKTYPE=M2UA2M, LKS=0, BINIFID=0;
6.4.4 Data Configuration of 2-Mbit/s MTP3-M3UA Signaling

Gateway
Prerequisite
l The Signaling Transport (SIGTRAN) interface is correctly configured on the UMG8900.

Figure 6-20 shows the index mapping of the major configuration command parameters of the
signaling transfer over M3UA.

Figure 6-20 Index mapping of configuration commands of signaling transfer over M3UA
Procedure
1. Run ADD M3LE to add an M3UA local entity. Set Local Entity Type to SG
(signaling_Gateway).
2. Run ADD M3DE to add an M3UA destination entity. Set Destination Entity Type
to AS (Application_Server). The master and slave MGCs share one signaling point.
3. Run ADD M3LKS to add an M3UA link set. If dual homing is configured, set Discard
messages from lower priority link to DISCARD (YES). Otherwise, use the default
value of the parameter.
4. Run ADD M3RT to add an M3UA route.
5. Run ADD M3LNK to add an M3UA link to the master MGC. Set CS Mode to
Server, Active Standby Flag to Active, and Priority to 0.
6. If dual homing is configured, run ADD M3LNK to add an M3UA link to the slave
MGC. Set CS Mode to Server and Active Standby Flag to Active. The priority level
of the M3UA link to the slave MGC must be lower than that of the M3UA link to the
master MGC, and thus set Priority to 1.
l Configuring the data to the interconnected device

1. Run ADD N7DSP to add a destination signaling point. Set Network indicator to
National reserved network.
2. Run ADD N7LKS to add an N7 link set.
3. Run ADD N7RT to add an N7 route.
4. Run MOD SPFSUBRD. Set Configure mode to PRO_2 Mbit/s.
5. Run ADD MTP2LNK to add an MTP2 link. Set Link type to MTP3 2M LINK.
6. Run ADD N7LNK to add an N7 link.
----End
Example
Network diagram
Figure 6-21 shows the network diagram of the signaling transfer over M3UA.
Figure 6-21 Network diagram of the signaling transfer over M3UA
ADD M3LE: LEX=0, LEN="AUMG89001", LET=SG, NI=NAT, OPC=H'aaaaaa;
ADD M3DE: DEX=0, DEN="AMGC1", DET=AS, NI=NAT, DPC=H'bbbbbb, LEX=0;
//Configure dual homing, and set Discard messages from lower priority link to
YES.
ADD M3LKS: LSX=0, LSN="AMGC1", ADX=0, DLP=DISCARD;
ADD M3RT: RN="AMGC1_1", DEX=0, LSX=0;
//Add an M3UA link to the master MGC.

ADD M3LNK: LNK=0, BT=SPF, BN=0, LKN="AMGC_1", LIP1="10.1.1.5", LP=4000,
//Add an M3UA link to the slave MGC. The priority level of the M3UA link to the
slave MGC must be lower than that of the M3UA link to the master MGC.
ADD M3LNK: LNK=1, BT=SPF, BN=0, LKN="AMGC1_2", LIP1="10.1.1.5", LP=5000,

//Configure the destination signaling point (DSP).
ADD N7DSP: INDEX=0, NAME="BSC02", NI=NAT, DPC=H'cccccc, OSPINDEX=0;

//Configure the MTP3 link set.

ADD N7LKS: INDEX=0, NAME="APSTN1", DSPIDX=0;
//Use timeslot 16 of port 16 on E32 board 0.

ADD MTP2LNK: SPFBN=0, SUBBN=0, CM=PRO_2M;
ADD MTP2LNK: LNKNO=0, LNKNAME="APSTN1_1", IFBT=E32, IFBN=0, E1T1N=16,
STRTTS=16, ENDTS=18, SPFBN=0, SUBBN=0, LNKTYPE=MTP32M;
//Configure the MTP3 route.

ADD N7RT: INDEX=0, NAME="APSTN1", LKSIDX=0, DSPIDX=0;
//Configure the MTP3 link.

ADD N7LNK: INDEX=0, NAME="APSTN1_1", LKSIDX=0, SLC=0, MTP2NO=0;
6.4.5 Data Configuration of IUA-Based PRI Message Transfer

This section describes the data configuration for enabling and maintaining IUA-based PRI
message transfer.
Prerequisite

Figure 6-22 shows the index mapping of the configuration command parameters of the signaling
gateway (SG) over ISDN Q.921-User Adaptation Layer (IUA).
Figure 6-22 Index mapping of main parameters in IUA-based signaling gateway
Procedure

1. Run SET SCTPINIT to set the SCTP protocol parameter.

and slave MGCs. Set Protocol type to IUA.
to IUA, and Priority to 0.
IUA, and Priority to 1.
1. Run ADD Q921LNK to add a Q.921 link.
----End
Example
Network diagram
Figure 6-23 shows the network diagram of the signaling transfer over IUA.
//Add an L2UA link set to the MGC.

ADD L2UALKS: PROTYPE=IUA, LKSNAME="AMGC1", LKS=0, TM=LOADSHARE, DLP=DISCARD;
ADD L2UALNK: PROTYPE=IUA, BN=0, LNKNO=0, LNKNAME="IUALNK-1", LKS=0,
PRIO=0;
ADD L2UALNK: PROTYPE=IUA, BN=0, LNKNO=0, LNKNAME="IUALNK-1", LKS=0,
PRIO=1;
l Configuring the data to the PBX

ADD Q921LNK: LNKNO=0, LNKNAME="To PBX", LKS=0, BINIFID=101, IFBT=E32, IFBN=0,
E1T1N=6, TS=16, SPFBN=0, SUBBN=0, NETUSER=NET;

6.4.6 Data Configuration of V5UA-Based LAPV5 Message Transfer

This section describes the data configuration for enabling and maintaining V5UA-based LAPV5
message transfer.
Prerequisite

V5UA.
Figure 6-24 Index mapping of main parameters in V5UA-based signaling gateway
Procedure
Step 1 Run SET SCTPINIT to set the SCTP protocol parameters.
Step 2 Run ADD L2UALKS to add an L2UA link set. Use only one link set to the master and slave
MGCs. Set Protocol type to V5UA.
Step 3 Run ADD L2UALNK to add an L2UA link to the master MGC. Set Protocol type to IUA, and
Priority to 0.

Step 4 Run ADD L2UALNK to add an L2UA link to the slave MGC. Set Protocol type to IUA, and
Priority to 1.
Step 5 When the remote address is identified in the domain name, run SET DNSSVR to configure the
domain name server (DNS).
Step 6 Run ADD V5E1 to add a V5 E1 link.
Step 7 Run ADD V5LNK to add an LAPV5 link.
----End
Example
Network diagram
Figure 6-25 shows the network diagram of the signaling transfer over V5UA.

ADD L2UALKS: PROTYPE=V5UA, LKS=0, TM=LOADSHARE, DLP=DISCARD;
ADD L2UALNK: PROTYPE=V5UA, BN=0, LNKNO=0, LNKNAME="V5UALNK-1", LKS=0,
PRIO=0;
ADD L2UALNK: PROTYPE=V5UA, BN=0, LNKNO=0, LNKNAME="V5UALNK-1", LKS=0,
PRIO=1;
l Configuring the data to the V5 access network device

ADD V5E1: E1ID=0, LKS=0, E1LNKID=0, IFBT=E32, IFBN=0, E1N=2;
ADD V5LNK: LNKNO=0, E1ID=0, TS=16, SPFBN=1, SUBBN=0;
6.5 Protocol and Specification of Narrowband Common

Channel Signaling Adaptation

Table 6-5 Protocols and specifications of narrowband common channel signaling adaptation
Narrowband common channel signaling SIGTRAN

adaptation

Feature Description 7 Channel Associated Signaling Adaptation
7 Channel Associated Signaling Adaptation
About This Chapter
This chapter describes the definition, involved required network elements (NEs), function
protocols and specifications of channel associated signaling (CAS) adaptation.
7.1 Overview of Channel Associated Signaling Adaptation
7.2 Availability of Channel Associated Signaling Adaptation
7.3 Principle and Flow of Channel Associated Signaling Adaptation
7.4 Data Configuration of Channel Associated Signaling Adaptation
7.5 Protocol and Specification of Channel Associated Signaling Adaptation

7 Channel Associated Signaling Adaptation Feature Description
7.1 Overview of Channel Associated Signaling Adaptation

Feature Definition
The UMG8900 provides the embedded signaling gateway (SG) function In addition to the
common channel signaling adaptation and transparent transmission based on the standard
Signaling Transport (SIGTRAN) protocol, the UMG8900 supports channel associated signaling
(CAS) processing. The UMG8900 encapsulates the received CAS as H.248 packets and sends
the CAS to the media gateway controller (MGC), and meanwhile decapsulates the H.248 packets
from the MGC as CAS to send to the peer CAS switch. Thus, the interconnection of CAS between
the MGC and the public switched telephony network (PSTN) is realized.
The UMG8900 supports the following CAS: R1, R1.5, No.5 and R2 signaling. The ESU
completes signaling message interaction and resolution for line signaling and register signaling
of No.5 signaling.
The UMG8900 supports R2 CAS multinational adaptation. The R2 CAS varies in applications
in different countries. This is reflected in the different mapping between the physical signal and
logical signal. For example, the seizure signal is 0001 in the standard R2 signaling. It may be a
130 ms pulse in bit A in Iran. In Indonesia, the request calling number is A6, whereas that in
Iraq is A5. The UMG8900 defines a CAS translation table to realize the mapping between
physical signals and logical signals through data configuration. The host software processes
logical signals only. This method shields the differences of R2 CAS in different countries.
The R2 CAS adaptation function performs adaptation based on the signal differences of R2
signaling in different countries. At present, adaptation processing of R2 signaling for many
countries is supported.
Service Benefits
Table 7-1 Service benefits of channel associated signaling adaptation

CAS adaptation This feature supports interconnection This function is invisible

with multiple signaling switches to to the users.
improve the networking capability of
the network.
Table 7-2 Function restrictions of channel associated signaling adaptation

CAS adaptation The ESUs must be available for this function.

7.2 Availability of Channel Associated Signaling

Adaptation
Required NEs
Table 7-3 Required NEs for channel associated signaling adaptation

Feature Required NE
CNo.1 MGC, MGW, PSTN switch, and PBX
R2 MGC, MGW, PSTN switch, and PBX
No.5 MGC, MGW, PSTN switch, and PBX
Version Support
Table 7-4 Versions supporting channel associated signaling adaptation

CNo.1 R002 and later
R2 R002 and later
No.5 R002 and later
7.3 Principle and Flow of Channel Associated Signaling

Adaptation
The channel associated signaling (CAS) includes R2, No.5, and CNo.1 signaling. The R2
signaling may be different in different countries. The UMG8900 supports the multinational
adaptation function for R2 CAS to shield the differences.
The UMG8900 terminates the CAS, and then maps the CAS messages to the H.248 messages.
The H.248 messages are forwarded to the media gateway controller (MGC) through the media
gateway (MGW) control interface.

NOTE
The following section describes the processing flow for the CAS that the UMG8900 accesses from the
time division multiplexing (TDM) side. Assume that the CMU is used and the HRB provides the upstream
interface for the MGC.
Service Flow
R2/CNo.1 signaling processing
The UMG8900 processes R2 and CNo.1 signaling in the same mode.
Figure 7-1 shows the processing flow for R2 or CNo.1 CAS in the SSM-256 frame.
Figure 7-1 R2/CNo.1 CAS processing flow in an SSM-256 frame
MGC: media gateway controller LE: local exchange
FE: fast Ethernet TDM: time division multiplexing
In the SSM-32 frame, the TDM switching board used on the TDM side is the MTNC rather than
the MTNU. Except this difference, the processing flow for R2 or CNo.1 CAS in the SSM-32
frame is the same as that in the SSM-256 frame.
The R2 or CNo.1 CAS includes line signaling and register signaling. The E32 processes the line
signaling and a service resource board such as the VPU processes the register signaling.
The processing flow for R2 or CNo.1 CAS is described as follows.
1. After the UMG8900 accesses the R2 or CNo.1 CAS through a back E32 interface board,
the E32 directly exchanges and resolves the line signaling. Then, the E32 sends the signaling
to the CMU through the internal FE bus.
NOTE
The E32 or the T32 can process line signaling.

2. After receiving the R2 or CNo.1 register signaling, the E32 forwards the signaling to the
VPU through connections of internal TDM timeslots under the control of the CMU. The
VPU exchanges and resolves the register signaling and then forwards the signaling to the
CMU through the internal FE bus.
NOTE
The service resource board VPU processes register signaling.

3. After receiving the line signaling from the E32 or the register signaling from the VPU, the
CMU maps the signaling to H.248 messages and then forwards the messages to the HRB
through the internal bus and finally to the MGC.
NOTE
The MCMF, MCMB, and MMPU can map the CAS to H.248 messages.
reverse direction.
No.5 signaling processing
The No.5 CAS is audio signaling. It is transmitted over the speech path. The UMG8900 processes
the No.5 CAS through the E32/T32, whose physical board is the MESU/MTSU.
Figure 7-2 shows the processing flow of No.5 signaling.
Figure 7-2 No.5 CAS processing flow
MGC: media gateway controller LE: local exchange
FE: fast Ethernet TDM: time division multiplexing
After the UMG8900 receives No.5 signaling through the E32, the E32 exchanges and resolves
both No.5 line signaling and register signaling. Then, the E32 sends the signaling to the MCMF
through the internal FE bus. The CMU maps the signaling to H.248 messages, and then forwards
them to the MGC through the back interface board of the HRB.

7.4 Data Configuration of Channel Associated Signaling

Adaptation
Prerequisite
The bearer data is correctly set on the UMG8900.

Figure 7-3 shows the index mapping of the configuration command parameters of signaling
transfer over channel associated signaling (CAS).
Figure 7-3 Index mapping of configuration commands in CAS-based signaling transfer

Procedure
Step 1 Modify the configuration script based on actual requirements. The parameters are modified as
follows:
l Set Charge pulse mode of the ADD PCMPLS command based on actual requirements.
l Neither value of Pulse index nor PCM pulse index can be the same as the index of other
R2 signaling.
Step 2 Run the configuration scripts of the CAS signaling to adapt line signaling and register signaling.
Function Location in the Software Installation

Package
Add line signaling adaptation, and set the Vx00R00xCxx\R2 Adapt Data\
pulse width of the line signaling.
Add register signaling adaptation.
NOTE
Adaptation scripts of R2 line signaling and register signaling for different countries are available in
Vx00R00xCxx\R2 Adapt Data\. You can set the related parameters for R2 signaling of different countries
by referring to the adaptation scripts in the corresponding folder. For example, select the script in
Vx00R00xCxx\R2 Adapt Data\Brazil for Brazil R2 (5S) signaling.
Step 3 Run ADD CASSIGNAL to add the CAS type.
Step 4 Run ADD CASATTR to configure the CAS attributes.
Step 5 Run ADD TDMIU to add a CAS timeslot, and set Relay type to R2.
----End
Example
Network diagram
Figure 7-4 shows the network diagram in CAS-based signaling transfer mode.

ADD PULSE: PID=0, BIT=A_BIT, PP=valid_1;
ADD PCMPLS: ID=1, CPM=0;
ADD LRPT: ID=1, PEVT=LINE_SIG, PARA=0, CRS=IDL, LEVT=SZ;
ADD LSND: ID=1, LCMD=SZ, PCMD=LINE_SIG, PARA=1, SNDTIM=10;
ADD REGRPT: ID=1, RSD=1, CRS=2, LEVT=11, PARA=1;
ADD REGSND: ID=1, CMD=0, PARA=1, RSD=1;
ADD CASSIGNAL: SIGNM="R2 Mbit/sFC", ST=R2, LS=L2B, RS=MFC, LSC=1, LCM=1, RSSC=1,
RSCM=1;
ADD CASATTR: ID=1, SIGNM="R2 Mbit/sFC",
SNDLST=DI-1&SI-1&SC-1&ES-0&CC-0&DISC-0&NAC-0,
RCVLST=DI-1&SI-1&SC-1&ES-0&CC-0&DISC-0&NAC-0, RCPS=3, RCCP=2;
ADD TDMIU: BN=0, BT=E32, TIDFV=320, TIDLV=351, VMGWID=0, HOSTID=1, RT=R2,
7.5 Protocol and Specification of Channel Associated

Table 7-5 Protocols and specifications of channel associated signaling adaptation

Channel associated signaling adaptation R2, No.5, and CNo.1

Feature Description 8 TDM Semi-permanent Connections
8 TDM Semi-permanent Connections
About This Chapter
protocols and specifications of time division multiplex (TDM) semi-permanent connections.
8.1 Overview of TDM Semi-permanent Connections

8.2 Availability of TDM Semi-permanent Connections
8.3 Principle and Flow of TDM Semi-permanent Connections
8.4 Data Configuration of TDM Semi-permanent Connections
8.5 Protocol and Specification of TDM Semi-permanent Connections

8 TDM Semi-permanent Connections Feature Description
8.1 Overview of TDM Semi-permanent Connections

Feature Definition
The time division multiplex (TDM) semi-permanent connection is one of the connections in
networking. The signaling, service, and voice can be transparently transmitted, thus enriching
the networking capability of the UMG8900.
l The semi-permanent connection enables the transparent transmission of the signaling

between the TDM devices and the MGC. The semi-permanent connection requires the E1
or SDH connection between the UMG8900 and the MGC to transfer SS7 signaling. Thus,
the networking is more complex. In actual networking applications, the semi-permanent
connection is rarely used.
l For the transparent transmission of services and voices, the transmission media of the semi-
permanent connection is E1 cables. The semi-permanent connection occupies one timeslot
through leased cables. Thus, the semi-permanent connection has high priority and high
service quality, which is applied to dedicated services to transparently transmit services
and voices.
Based on different types of terminations, the UMG8900 supports the semi-permanent connection
of the following types of networking:
l TDM_TDM: two TDM terminations

When the transparent transmission of signaling is configured between the device on the
TDM side and the MGC, the TDM_TDM semi-permanent connection is often used. In
actual networking applications, the semi-permanent connection is rarely used.
l IP_TDM: one IP termination and one TDM termination
l IP_UA: one IP termination and one UAM termination
In the DDN dedicated service, the service quality of the IP network is hard to be guaranteed,
and thus the semi-permanent connection with IP terminations is not used. In the audio
dedicated service, when the semi-permanent connection goes through the IP networking,
IP terminations for the semi-permanent connection must be added.
l UA_UA: two UAM terminations
l TDM_UA: one TDM termination and one UAM termination
Service Benefits
Table 8-1 Service benefits of the TDM semi-permanent connection
TDM semi-permanent This feature improves service quality Not involved

connection and enriches the networking capability.

8.2 Availability of TDM Semi-permanent Connections

Required NEs
Table 8-2 Required NEs for the TDM semi-permanent connection

Feature Required NE
TDM semi-permanent connection MGW, MGC, UAM, and SG
Version Support
Table 8-3 Versions supporting the TDM semi-permanent connection

TDM semi-permanent connection R002 and later
8.3 Principle and Flow of TDM Semi-permanent

Connections
Signaling Transparent Transmission of TDM Semi-permanent Connections

When the TDM connection is available between the UMG8900 and the media gateway controller
(MGC), the signaling system number 7 (SS7) signaling of a timeslot is torn down from the E1
or synchronous digital hierarchy (SDH) trunk by configuring semi-permanent connections. The
signaling is directly transferred to the MGC through the E1 connection between the
UMG8900 and the MGC, and thus the transparent transmission of the SS7 signaling is realized.
After the semi-permanent connection is established between the TDM timeslots that carry the
signaling, the two TDM timeslots are always connected. The SS7 signaling is transparently
transmitted through the semi-permanent connection. Figure 8-1 shows the principle of
transparent transmission of the SS7 signaling through the TDM semi-permanent connection.
NOTE
If the signaling traffic is heavy, the signaling transparent transmission through the TDM semi-permanent
connection is realized by interconnecting the UMG8900 and the signaling transfer device such as the
SG7000. Thus, the timeslots are converged.

Figure 8-1 Signaling transparent transmission of the TDM semi-permanent connection
CAUTION
When configuring the trunk circuit on the MGC side, ensure that the trunk circuit corresponding
to the TDM semi-permanent connection is unavailable. Otherwise, call loss arises when the trunk
circuit is selected.
Transparent Transmission of Services and Voices

The TDM semi-permanent connection is used in services of dedicated lines, including digital
data network (DDN) dedicated services and audio dedicated services.
l The DDN is a digital transmission network that uses digital channels to provide semi-
permanent connection circuits to transmit data signals. The DDN uses the TDM mode and
the circuit switching technology to provide the permanent or semi-permanent digital
dedicated line connection to transparently transmit user data.
l For the audio dedicated service, the ATI is used as a trunk between offices to transmit data.
The ATI is the 2-wire/4-wire E&F interface board of the UMG8900, which providing six
2-wire/4-wire E&F interfaces. At present, the UMG8900 adopts the semi-permanent
connection to connect different ATIs to implement the dedicated connection among 2-wire/
4-wire audio users.
In the DDN dedicated service, the TDM_UA permanent connection and the UA_UA semi-
permanent connection are often used.
Figure 8-2 shows the common networking of semi-permanent connection in the dedicated
service.

Figure 8-2 Common networking of semi-permanent connections in the dedicated service
l SPC(A) and SPC(D): two UAM terminations. Only one UA_UA semi-permanent
connection needs to be configured.
l SPC(B): The type of semi-permanent connection must be distinguished in segments. From
the IP termination to the termination on the ATI, the semi-permanent connection is IP_UA.
From terminations on two ATIs, the semi-permanent connection is UA_UA.
l SPC(C): one UAM termination and one TDM termination. Only one TDM_UA semi-
permanent connection needs to be configured.
8.4 Data Configuration of TDM Semi-permanent

Connections
Overview of Configuration
This section describes the configurations of the TDM semi-permanent connection in the
applications of signaling transparent transmission and voice transparent transmission.
Procedure
l Configuring the signaling transparent transmission
Figure 8-3 shows the networking of the signaling transparent transmission of the TDM
semi-permanent connection.
NOTE
When the signaling volume is large, the UMG8900 and the SG7000 are interconnected, thus
converging the timeslots. Alternatively, the UMG8900 and the MGC can be interconnected, which
is rarely used. In these two interconnection applications, the configurations of the UMG8900 are the
same.

Figure 8-3 SS7 signaling transferring of the semi-permanent connection
– Two E1 circuits between the UMG8900 and the PSTN switch are connected.
– Two E1 circuits between the UMG8900 and the MSC are connected.
NOTE
Configure at least two E1/T1 circuits to one office direction to ensure communication security.
Table 8-4 lists the data planning of the signaling transparent transmission of the semi-
permanent connection.
Table 8-4 Data planning
No. Interworking Parameter Parameter Value
1 TDM interface connecting the E1 interface 0 of E32 2 in slot 10

UMG8900 and the SG7000 E1 interface 0 of E32 3 in slot 11
2 Timeslot number of the bearer link 16

between the UMG8900 and the
SG7000
3 TDM interface connecting the E1 interface 2 of E32 0 in slot 4

UMG8900 and the PSTN switch E1 interface 2 of E32 1 in slot 5
4 Timeslot number of the bearer link 16

between the UMG8900 and the PSTN
switch
To configure the signaling transparent transmission of the TDM semi-permanent

connection, perform the following steps:
1. Configure the timeslots.
ADD TDMIU: BT=E32, BN=0, TIDFV=64, TIDLV=95, VMGWID=0, RT=Extern;

2. Configure the semi-permanent connection to the SG7000. The source TDM timeslots
are the 16th timeslot of interface 2 in slot 4 of frame 2 and the 16th timeslot of interface
2 in slot 5 of frame 2. The destination TDM timeslots are the 16th timeslot of interface
0 in slot 10 of frame 2 and the 16th timeslot of interface 0 in slot 11 of frame 2.
ADD SPC: ID=0, SPCN="To BSC", CT=TDM_TDM, CD=DDIR, STFN=2, STSN=4, SPN=2,
STS=16, DTFN=2, DTSN=10, DPN=0, DTS=16;

ADD SPC: ID=1, SPCN="To BSC", CT=TDM_TDM, CD=DDIR, STFN=2, STSN=5, SPN=2,
STS=16, DTFN=2, DTSN=11, DPN=0, DTS=16;
l Configuring the DDN dedicated line service of the DSL
For the DDN dedicated line service, the following interface boards are used.
– DSL
– HSL
– SDL
Take the DSL as an example. Through the semi-permanent connection, the UMG8900 sets
up the connection of the digital dedicated line between data terminals attached to the
multifunctional terminal adapter (MTA) and between the data terminal attached to the MTA
and the digital data network (DDN) node machine. See Figure 8-4.
NOTE
The MTA is located in the data service unit (DSU) of the user's terminal. The MTA is connected to
the DSL through the 2B1Q interface.
Figure 8-4 DDN dedicated line service
– Two E1 circuits between the UMG8900 and the PBX are set up.
– Reserved timeslots on interface 0 on the DSL are added.
Table 8-5 lists the data planning of the DDN dedicated line service.
1 TDM interface connecting the E1 port 0 of E32 0 in slot 0

UMG8900 and the UA frame

2 Timeslot number of the link directly 2

carried by the UMG8900 and UA
frame
3 TDM interface in the UA frame E1 interface of port 0 in slot 4 of frame

1
To configure the DDN dedicated line service of the TDM semi-permanent connection,
perform the following steps:
1. Configure the DSL.
ADD UABRD: FN=2, SN=7, BT=DSL, LKS=2, BINIFID=16;
2. Configure the MTA for port 0 on the DSL. The first port rate of the MTA is set to 64
kbit/s and the B1 channel is used.
ADD MTA: MIDX=0, FMN=1, SLTN=4, PRTN=0, RATE0=BAUT_RATE_64000,
BCHANNEL0=B1;
3. Add the reserved timeslots for port 0 on the DSL.

ADD PRTTS: FN=2, SN=4, PN=0;
If you attempt to configure the semi-permanent connection for the UA termination,

the timeslot must be reserved for the UA termination. The termination occupies one
internal timeslot.
4. Configure the semi-permanent connection. The semi-permanent connection is
established between the B1 channel of port 0 on the DSL and timeslot 2 of port 0 on
E32 0.
ADD SPC: ID=0, CT=TDM_UA, CD=DDIR, STFN=0, STSN=0, SPN=0, STS=2, DRFN=1,
DRSN=4, DRPN=0;
l Configuring audio dedicated line services

The ATI is the 2/4-wire E&M interface board of the UMG8900. It is compatible with slots
of the ASL/A32 and can provide the six-channel 2/4-wire E&M interface. The ATI is used
as the analog trunk between offices. Only the 2/4-wire audio cable is used to transmit data.
At present, the UMG8900 adopts the semi-permanent connection mode to connect different
ATIs to realize the dedicated connection among 2/4-wire audio users. Figure 8-5 shows
the typical networking.

Figure 8-5 Networking of the audio dedicated line service
– The semi-permanent connection SPC(A) of UA_UA is established in UMG8900 A.

– The semi-permanent connection SPC(B) of IP_UA is established between UMG8900
A and UMG8900 B.
Table 8-6 lists the data planning of the DDN dedicated line service.
1 Work mode of the ATI port Line 4
2 IP termination and port number of 192.168.0.1:8000

semi-permanent connection of
UMG8900 A
3 IP termination and port number of 192.168.0.1:8000

semi-permanent connection of
UMG8900 B
To configure the processing of the dedicated line service of the TDM semi-permanent
connection, perform the following steps:
1. Configure the ATI.

ADD UABRD: FN=0, SN=3, BT=A32;

2. Set the work mode of port 0 on the ATI in slots 3 and 4 of the UMG8900 to line 4.
SET ATIPRT: FN=0, SN=3, PN=0, WORKMODE=LINE4;
3. Add the reserved timeslot for ATI port.

4. Configure the semi-permanent connection SPC (A) between port 0 on the ATI in slot
3 and port 0 on the ATI in slot 4.
ADD SPC: ID=1, CT=UA_UA, CD=DDIR, SRFN=0, SRSN=3, SRPN=0, DRFN=0, DRSN=4,
DRPN=0;
5. Set the attributes of the ATI port of SPC(B). The work mode of port 1 on the ATI in
slot 4 of UMG8900 A is set to line 4 and that in slot 5 of UMG8900 B is also set to
line 4.
6. Add the reserved timeslots of the port on the ATI for SPC (B). The timeslots for port
1 on the ATI in slot 4 of UMG8900 A and that in slot 5 of UMG8900 B are reserved.
7. Add the semi-permanent IP terminations for UMG8900 A and UMG8900 B.

ADD SPCIP: IPDOMAIN=0, LOCALIP="192.168.0.1", LOCALUDP=8000,
REMOTEIP="172.16.0.1", REMOTEUDP=8000, VPUBRD=0, SERVICETYPE=BYPASS,
CODEC=G711A, PTIME=PT20;
ADD SPCIP: IPDOMAIN=0, LOCALIP="172.16.0.1", LOCALUDP=8000,
REMOTEIP="192.168.0.1", REMOTEUDP=8000, VPUBRD=0, SERVICETYPE=BYPASS,
CODEC=G711A, PTIME=PT20;
8. Add the semi-permanent connection between port 1 on the ATI in slot 4 of

UMG8900 A and the semi-permanent IP termination. Add the semi-permanent
connection between port 1 on the ATI in slot 5 of UMG8900 B and the semi-permanent
IP termination.
ADD SPC: ID=2, CT=IP_UA, CD=DDIR, SISA="192.168.0.1", SISP=8000, SIAD=0,
DRFN=0, DRSN=4, DRPN=1;
ADD SPC: ID=3, CT=IP_UA, CD=DDIR, SISA="172.16.0.1", SISP=8000, SIAD=0,
DRFN=1, DRSN=5, DRPN=1;
----End
8.5 Protocol and Specification of TDM Semi-permanent

Connections
Compliance Protocols and Specifications

None

Feature Description 9 Announcement Playing and Digit Collecting
9 Announcement Playing and Digit Collecting
About This Chapter
protocols and specifications of announcement playing and digit collecting.
9.1 Overview of Announcement Playing and Digit Collecting

9.2 Availability of Announcement Playing and Digit Collecting
9.3 Principle and Flow of Announcement Playing and Digit Collecting
9.4 Data Configuration of Announcement Playing and Digit Collecting
9.5 Protocol and Specification of Announcement Playing and Digit Collecting

9 Announcement Playing and Digit Collecting Feature Description
9.1 Overview of Announcement Playing and Digit

Collecting
In the network, during a voice service connection process, announcements are played in the
specific phases regardless of whether the call succeeds or fails. Different prompt tones instruct
users to complete calls or indicate users that the call fails. The standard defines two
announcement playing realization modes: One is that announcement is played by the
independent intelligent peripheral (IP) device, and the other is that the mobile switching center
(MSC) embedded with announcement playing resources provides the announcement playing
function.
The media gateway (MGW) must be loaded with tone files to support announcement playing.
Voice data of each tone to be played is saved in the tone files. The tone files saved in the
UMG8900 adopt the G.711A codec. Each resource board of the UMG8900 can save tone files
that can be played for two hours. The tone files saved on all the resource boards must be the
same.
The UMG8900 acts as a high-capacity universal media gateway and provides the digit collecting
function for collecting the dialing numbers of users. Numbers, such as the called number and
the number and password of the recharge card, sometimes need to be collected during a call.
The UMG8900 can collect these numbers under the control of the media gateway controller
(MGC), and then reports the numbers to the MGC for processing. For example, before a call is
established, the call control device must analyze the dialing number after the user picks up the
phone and dials the number. The MGC completes call control processes. The MGW, controlled
by the MGC, collects and reports the dialing number of the caller to the MGC or other gateway
devices.
Feature Definition of Announcement Playing

Announcement playing refers that announcements are played on the local network for users or
the peer network. Tones include basic tones and intelligent tones. The basic tones refer to signal
tones, and the intelligent tones include basic service tone, fixed intelligent tone, and variable
intelligent tone. Signal tones and basic service tones are controlled by the MSC. Intelligent
announcement playing is based on the common announcement playing and controlled by the IP
device. The service can play announcement to users according to service logic (such as PPS and
MVPN) and service event (such as announcement playing at the last minute, recharging and
balance querying). PPS refers to prepaid service and MVPN refers to mobile virtual private
network. In addition, the service can be adapted to announcement voice types and language types
dynamically.
During a call, the system plays signal tones to users. The signal tones are classified according
to announcement playing conditions and playing modes.
l DN announcement playing and failure announcement playing
The MGC provides dialed number (DN) announcement playing and failure announcement
playing based on whether the connection is complete.

– The DN announcement playing corresponds to calls that are connected successfully.

Carriers can determine whether to play announcement for some special numbers based
on data configuration.
– The failure announcement playing corresponds to calls that are not connected. When a
call fails, the system sends the cause of the failure to the user through record. The system
has a default announcement playing mode that maps announcement playing to the cause.
If carriers consider that default voices are different from the expected ones, they can
modify the default voices through data configuration.
l Synchronous announcement playing and asynchronous announcement playing
The MGC provides two announcement playing modes: synchronous announcement playing
and asynchronous announcement playing.
– The feature of synchronous announcement playing is that announcement is played from
start and stopped after being played for the specific number of times. In this mode, the
call occupies lots of announcement playing channels. Normally, one call occupies one
announcement playing channel independently.
– The feature of asynchronous announcement playing is that users hear voice randomly.
In this mode, the call occupies less announcement playing channels. Multiple calls can
share one asynchronous announcement playing channel.
In theory, each signal tone can be played in synchronous announcement playing mode or
asynchronous announcement playing mode. Some signal tones such as busy tone (450 Hz,
-10+3 dBm0 or -10-3 dBm0, 0.35 s on/0.35 s off), ringback tone (450 Hz, -10+3 dBm0 or
-10-3 dBm0, 1.0 s on/4.0 s off), and congestion tone (450 Hz, -10+3 dBm0 or -10-3 dBm0,
0.7 s on/0.7 s off), however, are played in asynchronous announcement playing mode
fixedly. In general, irregular voices are played in synchronous announcement playing
mode.
The UMG8900 supports the loading of tone files. Tone files can be recorded in independent
recording devices and then the formats of the tone files are converted through the specific
software. After conversion, the tone files are loaded to the back administration module
(BAM) through the local maintenance terminal (LMT) and then loaded to the specific VPU.
Feature Definition of Digit Collecting

In some special applications, the user must finish some interactive operations, such as
recharging, calling the extensions after calling the operators, and calling the customer service
center, through dialing keys. Dual tone multi-frequency (DTMF) is used to meet the requirement.
Number signals are classified into two types: pulse and DTMF. At present, DTMF is commonly
used. DTMF, a signal sent by a terminal device in the network, is an in-band signaling system.
It can be used only in voice services or voice-digital interactive services. The users can generate
DTMF signaling by pressing keys in the terminal devices, such as 0 to 9, A to F, *, # on the
handset.

Service Benefits
Table 9-1 Service benefits of announcement playing and digit collecting

Announcement The simple interaction between users and Users can transact various
playing the network in the basic services is services at home instead of
realized by playing signal tones and basic going to the business halls.
service tones to the users. The These services include
combination of intelligent recharging, inquiring balance,
announcement playing and intelligent modifying password,
digit collecting realizes the real-time reporting loss or canceling loss
interactions between the UMG8900 and report, subscribing for some
the users. That is, users can implement IN services, complaining, and
the related services, such as inquiring inquiring services.
balances, modifying passwords, Being instructed by the
inquiring/customizing/canceling intelligent voice, users can
intelligent network (IN) services, implement voice services such
through terminals. Thus, the number of as IP calls, selecting prompt
business halls is reduced. This saves the language in conference calls,
cost of carriers. and learning the reason of call
Intelligent announcement playing failures and the failures of IN
enables the carriers to remind the users of services in time.
recharging in time, explain the reason of
call disconnection, and advertise the
latest operating policies and activities. In
this way, the carriers can win long-term
customer loyalty, launch the value-added
services as soon as possible, and gain
more profit.
By realizing announcements playing in
different languages through voice
transformations on the same platform,
the carriers could satisfy the customers
who speak different languages more
flexibly.
Digit collecting The carriers can realize multiple basic or Users can easily and
IN services, such as the 1860 service, conveniently access various
automatic recharging, and traffic services, such as recharging
secretary in China, through DTMF. Thus, through the Internet by using
various value-added services can be the recharging card, through
realized without manual interference. the terminal keyboard.
This feature also saves the operating cost,
enhances the service quality, and
strengthens the competitiveness.

Table 9-2 Function restrictions of announcement playing and digit collecting

Announcement To realize announcement playing, the UMG8900 must be loaded with the
playing proper tone files, and the definition of tone files and the ID indexes on the
UMG8900 must be consistent with those on the softswitch.
Digit collecting At present, the UMG8900 supports the pulse and DTMF digit collecting
on the time division multiplex (TDM) side and the G.711 in-band voice or
digit collecting of DTMF signals over RFC2833 on the Internet Protocol
(IP) side.
9.2 Availability of Announcement Playing and Digit

Collecting
Required NEs
Table 9-3 Required NEs for announcement playing and digit collecting
Feature Required NE
Announcement playing MGC, MGW, and intelligent peripheral in

intelligent announcement playing
Digit collecting
Version Support
Table 9-4 Versions supporting announcement playing and digit collecting

Announcement playing R002 and later
Digit collecting

9.3 Principle and Flow of Announcement Playing and Digit

Collecting
9.3.1 DTMF Code Detecting and Sending

frequency (DTMF) code detecting and sending.
9.3.2 Basic Tone Playing
This section describes the implementation principles and service flow of basic tone playing.
9.3.3 Intelligent Tone Playing
This section describes the implementation principles and service flow of intelligent tone playing.
9.3.4 Local Language Adaptation
This section describes the implementation principles and service flow of local language
adaptation.
9.3.5 Dynamic Tone File Loading
This section describes the implementation principles and service flow of dynamic tone file
loading.
9.3.6 Non-Customized Color Ringback Tone
This section describes the implementation principles and service flow of non-customized color
ringback tones.
9.3.1 DTMF Code Detecting and Sending

frequency (DTMF) code detecting and sending.
DTMF is an in-band signaling system originated by terminal devices. The terminal devices must
be able to send the DTMF messages and the networks must support the two-way DTMF
transmission, namely, from the terminal to networks and from the networks to the terminal. The
control flow of the DTMF protocol is as follows:
The media gateway controller (MGC) sends messages that carry DTMF event detection to the
media gateway (MGW) to control the DTMF detection. After detecting DTMF events, the MGW
matches the DTMF events with the DTMF event detection sent by the MGC. The matching
result is sent to the MGC for subsequent processing.
The MGC sends messages that carry DTMF signals to the MGW to control the DTMF sending.
The MGW, following the indication of the MGC, sends DTMF signals to the specific
terminations. These signals are generally used for DTMF digit collecting of the receiving end
or transmitted to the next node through trunks.
9.3.2 Basic Tone Playing

This section describes the implementation principles and service flow of basic tone playing.
Announcement playing resources are built in the UMG8900 for playing basic tones. During a
voice service call, the UMG8900 plays basic tones under the control of the media gateway
controller (MGC).

The UMG8900 can play basic tones such as busy tone, ringing tone, initial ringing tone, dial
tone, two-stage dial tone, special dial tone, howling tone, and call waiting tone. The
UMG8900 supports the configuration of asynchronous tones of some basic tones. Each
asynchronous tone matches a transcoder (TC) channel and can be played continuously and
circularly on the TC channel. The user, under the control of the media gateway controller (MGC),
can connect to this channel after hearing the asynchronous tone. Tones on the asynchronous tone
channel can be played for multiple users. This saves substantive announcement playing
resources. Asynchronous tones can be played only on the TDM side.
The contents of basic tones are generally signal tones.
9.3.3 Intelligent Tone Playing

This section describes the implementation principles and service flow of intelligent tone playing.
Intelligent tone playing refers to that the service control point (SCP) plays service-related tones
to users based on the service logic such as the prepaid service (PPS) and mobile virtual private
network (MVPN) or the service switching point (SSP) plays service-related tones to users based
on service events such as last-minute announcement. The SSP requests the special resource point
(SRP) to play the announcement.
The media gateway controller (MGC) provides the functions of both the mobile switching center
(MSC) server and the SSP. The media gateway (MGW) provides the SRP function. When
receiving the announcement playing request from the SCP or determining that announcement
playing is required based on the service event, the MGC converts the announcement ID into tone
ID of the corresponding tone file, and then sends an announcement playing request to the MGW
through H.248. After receiving the announcement playing request, the MGW plays the tones,
and then reports the result to the MGC.
There are many intelligent tones such as the last-minute prompt tone, intelligent service prompt
tone, failure processing tone, standard tone, and tones for variable intelligent data such as
amount, time, date, number, and digit. These tones are played by interworking of the MGW and
the MGC through a unified message interface. Service control is implemented by the intelligent
devices and the MGC.
Before playing basic tones and intelligent tones, you must process the recorded tone materials
such as the busy tone and ringing tone into tone packets or dynamic tone files and load them to
the VPU of the MGW. The loaded tone packets and dynamic tone files can be invoked by the
application programs. For the processing methods of tone packets or dynamic tone files, see
HUAWEI UMG8900 Universal Media Gateway Operation GuideTone File Management.
9.3.4 Local Language Adaptation

This section describes the implementation principles and service flow of local language
adaptation.
In actual applications, telecommunication networks in different countries need to provide
different languages to better meet the requirements of users. This requires the adaptation on
languages, sequences, and syntax rules. For example, for standard tone playing and customized
announcement playing, different languages may be required in the same area during a service
interaction such as digit collection. The prompt tone is played in a language selected by the user.
For the worldwide application of telecommunication devices, the multi-national voice adaption
is developed to meet the requirements of language differentials. The UMG8900 is loaded with
the customized syntax rule analysis software and tone files to support the localized
announcement playing.

9.3.5 Dynamic Tone File Loading

This section describes the implementation principles and service flow of dynamic tone file
loading.
The UMG8900 supports the dynamic loading of tone files. Different tone files can be loaded to
support different prompt tones, thus meeting the requirements in different applications.
Users can use the Tone File Process Tool to process the recorded tone materials such as busy
tones and ringing tones into tone packets or dynamic tone files, and then load them to the VPU
of the UMG8900. These tone packets and dynamic tone files can be invoked by the application
program.
The tone files saved in the UMG8900 adopt the G.711A codec. Each resource board of the
UMG8900 can save tone files that can be played for two hours. Tone files can be repeated or be
played for multiple calls. The resource boards work in load-sharing mode, and are configured
in N+1 mode to improve the reliability.
9.3.6 Non-Customized Color Ringback Tone

This section describes the implementation principles and service flow of non-customized color
ringback tones.
For the non-customized color ringback tone, the fixed ringback tone is replaced by the color
ringback tone, and the color ringback tone is randomly selected by the system in a specific range
that is decided by the configured color ringback tone sets.
The media gateway controller (MGC) controls the UMG8900 to play the color ringback tone.
Based on the mode of the color ringback tone set, the UMG8900 plays announcement. In
synchronous mode, the CMU sends messages to the VPU, and the VPU randomly selects a color
ringback tone and plays it. In asynchronous tone, the CMU randomly selects an established
asynchronous announcement playing channel and notifies the TNU to connect the calling
termination to play the color ringback tone.
At present, the non-customized color ringback tone is used in the trunk gateway (TG) application.
Both the media gateway (MGW) and the MGC must support the non-customized color ringback
tone.
9.4 Data Configuration of Announcement Playing and Digit

Collecting
Procedure
Step 1 Process tone files including initial ringing tone, basic tone, intelligent tone, and color ringback
tone.
Step 2 Load tone files.

l Load tone packets. Run LOD TOBAM to load tone packets to the back administration
module (BAM). Run LOD TOBP to load the tone packets to the VPU. After the tone packets
are successfully loaded, reset the VPU and then restart it to validate the newly loaded tone
packets.

l Load dynamic tone files. Run LOD TOBAM to load dynamic tone files to the BAM. Run
LOD TONE to load the dynamic tone files to the VPU. Dynamic tone files can be loaded
online. After the dynamic tone files are loaded, they take effect in later calls.
Step 3 Run ADD ATONE to configure asynchronous tones.
Step 4 (Optional) Configure non-customized ringback tone.

1. Load color ringback tone files according to Step 2 and Step 3. The color ringback tone
files can be contained in tone packets or independently processed into dynamic tone files.
2. Run ADD CTONESET to add color ringback tone sets to a specific virtual media gateway
(VMGW).
3. Run ADD CTONE to add color ringback tones to a specific color ringback tone set.
Step 5 (Optional) Detect and send dual tone multi-frequency (DTMF) codes.
1. Run SET MRPARA to modify parameters such as A/MU law, the duration of the digitmap
timer, Match mode, standard parameters for DTMF generation, and DTMF detect.
2. Run SET TCPARA to set the DTMF transparent transmission function.
3. Run SET RFC2833 to set parameters for sending and detecting DTMF signals over
RFC2833.
----End
9.5 Protocol and Specification of Announcement Playing

and Digit Collecting
Table 9-5 Protocols and specifications of announcement playing and digit collecting
Announcement playing and digit collecting H.248

ITU-T Q.24 for DTMF digit detection

Feature Description 10 Syntax Adaptation
10 Syntax Adaptation
About This Chapter
restrictions, and compliance protocols and specifications of syntax adaptation.
10.1 Overview of Syntax Adaptation

This section provides the definition and describes application scenarios, service benefits for
carriers and users, and function restrictions of this feature.
10.2 Availability of Syntax Adaptation
This section describes the required network elements (NEs) and versions of the UMG8900 that
support this feature.
10.3 Loading a Syntax Adaptation Script
This section describes how to load a syntax adaptation script.
10.4 Rolling Back a Syntax Adaptation Script
This section describes how to roll back a syntax adaptation script.
10.5 Checking the Syntax Adaptation Script
This section describes how to check the syntax adaptation script and related dynamic tone files.
10.6 Querying the Syntax Adaptation Script
This section describes how to query a syntax adaptation script.
10.7 Protocol and Specification of Syntax Adaptation
This section describes the compliance protocol and specification of this feature.

10 Syntax Adaptation Feature Description
10.1 Overview of Syntax Adaptation

Feature Definition
Syntax adaptation refers to defining and describing syntax rules through syntax adaptation
scripts. You can determine the syntax analysis capability of the media gateway (MGW) by
loading syntax adaptation scripts. A syntax adaptation script, independent of the host software,
is developed and released separately to reduce the number of patch loading times and prevent
impacts on existing services during a version upgrade. The operations for meeting syntax
requirements through a syntax adaptation script can be performed in the daytime.
At present, variable intelligent data, such as integers, numbers, time, duration, dates, and fee
amounts, can be played in intelligent services through syntax adaptation.
On-site personnel collect office information to obtain the syntax rules of different languages.
Then, the R&D personnel use the specified tool to generate syntax adaptation scripts to meet
different syntax requirements.
The following describes the concepts involved in syntax adaptation:
l Language type
The language type is used to identify a language. Each language type is specific to a
language ID. For example, 1 indicates English and 2 indicates Chinese.
l Variable intelligent data
Variable intelligent data refers to the data that is played for users accessing intelligent
services. This data includes integers, numbers, time, duration, dates, and fee amount. The
values of the data, such as time and account balance, are variable.
l Syntax analysis
Syntax analysis is to analyze the variable intelligent data and convert it into one tone unit
or a sequence of tone units.
Based on syntax requirements, you can obtain basic tone units from the natural language
for playing variable intelligent data. For example, numbers 0 to 99, numeral units hundred,
thousand, million, and billion, the time unit second, duration units hour, minute, and second,
and the conjunction "and". These basic tone units are played in a certain sequence; for
example, the time 12:34:56 is played as twelve thirty-four fifty-six seconds. Syntax analysis
arranges these tone units and converts them into codes based on syntax rules.
l Vowel and combination tone
Vowels are basic tone units for playing variable intelligent data.
A combination tone is a tone sequence composed of zero, one, or more vowels. It is actually
the content of a variable intelligent data.

Application Scenario
Figure 10-1 Networking for syntax adaptation
SCP: service control point MGC: media gateway controller

MGW: media gateway RNC: radio network controller
UTRAN: universal terrestrial radio access network
As shown in Figure 10-1, the MGW receives a request delivered by the MGC for playing
variable intelligent data. Then, the MGW analyzes the syntax of the variable intelligent data and
plays the variable intelligent data after obtaining the sequence of tone units.
A syntax adaptation script is developed through a configuration tool automatically. Each syntax
adaptation script describes the syntax rules about one type of language. The syntax adaptation
script can be loaded to the VPU of the MGW, and be parsed, analyzed, and processed by the
VPU through the syntax rules described in the syntax adaptation script.
Service Benefits
Syntax adaptation Carriers can load only a Not applicable.

syntax adaptation script
rather than the software of a
specified version to
dynamically modify the
syntax analysis capability of
the MGW. Thus, services are
not interrupted.

Syntax adaptation l Syntax rules are complicated and their

development is uncertain. Therefore, the
syntax rules defined in this feature may not
be applicable to all types of syntax.
l Syntax adaptation may not be applicable to
some special or complicated syntax.
l A private protocol is adopted between
Huawei MGC and Huawei MGW for
playing variable intelligent data.
Consequently, this feature may not take
effect on the MGWs interworking with
other MGCs.
10.2 Availability of Syntax Adaptation

Required NEs
Feature Required NE
Syntax adaptation MGW and MGC
Required Product Versions

Feature Version
Syntax adaptation V200R008C01 and later
10.3 Loading a Syntax Adaptation Script

This section describes how to load a syntax adaptation script.

Prerequisite
CAUTION
If the media gateway (MGW) has been put into commercial use, the following operations must
be performed when the traffic is low and the VPU is deactivated.
Background Information
l Online syntax adaptation script loading
The process of online syntax adaptation script loading consists of two procedures:
1. Loading the dynamic tone files related to the syntax adaptation script: The dynamic
tone files must be loaded to the VPU and the hard disk of the OMU. For details, see
Loading Tone Files.
2. Loading the syntax adaptation script: The syntax adaptation script must be loaded to
the VPU and the hard disk of the OMU. After the syntax adaptation script is loaded,
the syntax analysis capability described in the syntax adaptation script takes effect on
the VPU.
NOTE
You must load the tone files related to the syntax adaptation script first, and then load the syntax
adaptation script.
l If a new dynamic tone file, which is irrelevant to the current syntax adaptation script, is loaded
to meet other announcement playing requirements, the usage of the syntax adaptation script is
not affected. Therefore, you do not need to load the syntax adaptation script again.
l If some dynamic tone files required for the syntax adaptation script are not loaded, you do not
need to load the syntax adaptation script again. For details on how to check whether all the
dynamic tone files related to the syntax adaptation script are loaded, see 10.5 Checking the
Syntax Adaptation Script.
l Automatic syntax adaptation script loading
After the syntax adaptation script and the corresponding dynamic tone files are loaded to
the hard disk of the OMU, the script and files are loaded from the hard disk of the OMU
to the VPU automatically after the VPU is restarted.
NOTE
The syntax adaptation script is stored in the memory of the VPU. Therefore, the script is lost when
the VPU is reset. After the VPU is restarted, the syntax adaptation script is loaded automatically to
the VPU from the hard disk of the OMU. If the syntax adaptation script stored on the VPU is different
from the syntax adaptation script on the hard disk of the OMU before the VPU is reset, the syntax
adaptation script on the VPU cannot be restored. This principle for the syntax adaptation script is
similar to the principle for a dynamic tone file.
Procedure
Step 1 Start the File Transfer Protocol (FTP) server.
Start the FTP server on the PC where the syntax adaptation script is to be uploaded. Set User
Name to bam, Password to bam, and Base Directory to c:\bam, that is, the path for uploading
the syntax adaptation script.
Step 2 Back up files.
Back up all the files in c:\bam\bin\tonepatch.

Step 3 Copy the syntax adaptation script.
Copy the syntax adaptation script and the related dynamic tone files (including the new files and
modified files) to c:\bam\bin\tonepatch.
NOTE
l Generally, the dynamic tone files are stored in the basic tone package and are loaded together with the
host files to the hard disk of the OMU. The c:\bam\bin\tonepatch path stores the new and modified
dynamic tone files.
Step 4 Upload the syntax adaptation script or dynamic tone files to the hard disk of the OMU.
Log in to the local maintenance terminal (LMT), and run LOD TOBAM to upload the syntax
adaptation script or dynamic tone files to the hard disk of the OMU.
l Version Type must be set to Dynamic Tone File.

l File Name specifies the name of the syntax adaptation script or dynamic tone file to be loaded.
If File Name is not specified, it indicates that all the syntax adaptation scripts or dynamic
tone files in c:\bam\bin\tonepatch on the FTP server will be loaded.
NOTE
l A syntax adaptation script is named in GA_xx.ini format. xx represents two hexadecimal numbers
specific to the language ID. For example, if the language ID is 1, the corresponding syntax
adaptation script is named GA_01.ini; if the language ID is 254, the corresponding syntax
adaptation script is named GA_FE.ini.
l A syntax adaptation script is generated by a configuration tool. Do not change or modify the file
name or file contents.
l Server IP Address refers to the IP address of the PC where the syntax adaptation script is
to be loaded, User Name refers to the user name specified for the FTP server, and
Password refers to the password specified for the FTP server.
l File Type can be set to Syntax adaptation script, Dynamic tone, or both.
NOTE
If dynamic tone files related to syntax adaptation have not been loaded or need to be updated, you must load
dynamic tone files first or load the dynamic tone files and syntax adaptation script at the same time.
For example, to load all the scripts in c:\bam\bin\tonepatch on the PC whose IP address is
10.110.28.175, run the following command:
LOD TOBAM: VT=DT, SIP="10.110.28.175", UID="bam", PWD="***", MT=GA;
The following information is displayed:

%%LOD TOBAM: VT=DT, SIP="10.110.28.175", UID="bam", PWD="*****", MT=GA;
%%RETCODE = 0 Progress report, accomplished
Download Result
--------
File name Download result Verifications Possible failing reason
GA_01.ini Succeed NULL NULL

GA_FE.ini Succeed NULL NULL
Result Stat
--------
Succeed = 2
Failed = 0
--- END
Step 5 Check whether the files are loaded.

Run LST TONEFILE to check whether any syntax adaptation script or dynamic tone file exists
on the hard disk of the OMU.
You do not need to specify any parameter for this command. You can check whether any syntax
adaptation script or dynamic tone file is loaded successfully by comparing the listed file names,
file size, and creation time with the syntax adaptation script and dynamic tone files in c:\bam
\bin\tonepatch.
For example, run the following command to check the syntax adaptation script and tone files on
the hard disk of the OMU:
LST TONEFILE: MT=BTONE-1&WTONE-1&BTONEPACK-1&WTONEPACK-1&GA-1;

%% LST TONEFILE: MT=BTONE-1&WTONE-1&BTONEPACK-1&WTONEPACK-1&GA-1;%%
RETCODE = 0 accomplished
Tone files list

--------
File name File creating time File size(Bytes) CRC
P001DS0002A00000001.stf 2008-08-08 21:37:16 5152 22699
P001DS0002A00000002.stf 2008-08-08 21:37:16 5152 22699
P001DS0002A00000001.wbv 2008-08-08 21:37:16 5152 22699
P001DS0002A00000002.wbv 2008-08-08 21:37:16 5152 22699
tonefile_wb.arj 2008-06-05 20:20:44 29934455 44432
tonefile.arj 2008-06-05 20:40:24 23315580 51740
GA_01.ini 2008-08-08 18:08:08 64544 40210
GA_FE.ini 2008-08-08 18:08:08 56694 7623
(Number of results = 8)
--- END
l If all the files are loaded successfully, proceed with Step 6.

l If some files are not loaded, perform Step 4 to load these files again.
Step 6 Synchronize the files of the master OMU to the slave OMU.
Run SYC BAMFILE to synchronize the device software and configuration files including the
dynamic tone files and syntax adaptation script on the hard disk of the master OMU to the hard
disk of the slave OMU.
NOTE
To synchronize all the files on the OMU, set Version Type to the default value All Files. You can also
choose Dynamic Tone File or Syntax Adaptation Script to synchronize only the dynamic tone files or
syntax adaptation script. For details, see the help about this command.
Step 7 Deactivate the specified board.
Run DEA BRD to deactivate the board to which the syntax adaptation script is to be loaded.
Then, wait 15 seconds.
NOTE
l This operation is to reduce the call traffic on the board where the syntax adaptation script is to be loaded,
thus minimizing the service risk.
l Deactivating a board may increase the traffic on active boards. Therefore, you can perform this step
only when the traffic is low.
l Run DSP MEDIARES to check whether the resources occupied by calls on the board are released.
Step 8 Load the syntax adaptation script or dynamic tone files to the VPU.
Run LOD TONE to load the syntax adaptation script or dynamic tone files to the VPU.

l Frame No., Slot No., and Board Position specify the position of the board where the files
are to be uploaded.
l Board Type specifies the announcement board where the files are to be loaded.
l File Type specifies the type of the file to be loaded. It can be Syntax adaptation script or
Dynamic tone.
l File Name specifies the name of the syntax adaptation script or dynamic tone file to be loaded.
If File Name is not specified, it indicates that all the syntax adaptation scripts or dynamic
tone files in the hard disk of the OMU will be loaded.
For example, run the following command to load the script GA_01.ini on the hard disk of the
OMU to the VPU in slot 10 of frame 1:
LOD TONE: FN=1, SN=10, BT=VPU, MT=GA, FILE="GA_01.ini";

%%LOD TONE: FN=1, SN=10, BT=VPU, MT=GA, FILE="GA_01.ini
%%RETCODE = 0 accomplished
Load result
--------
FRAME SLOT POSITION SSN FILE NAME RESULT FAIL REASON
1 10 VPU Mother Board GA_01.ini Succeed <Null>

Result Stat
--------
Total load files = 1
Succeeded = 1
Failed = 0
--- END
NOTE
l It is recommended that you load a syntax adaptation script or dynamic tone file when the traffic is low.
Step 9 Check whether the syntax adaptation script is loaded.

Run CHK TONE to check whether the syntax adaptation script is loaded successfully on the
VPU. For details, see 10.5 Checking the Syntax Adaptation Script.
l If the syntax adaptation script is loaded successfully, proceed with Step 10.
l If not, perform Step 8 to load the syntax adaptation script.
Step 10 Check whether all the dynamic tone files are loaded.
Run DSP TONE to check whether all the dynamic tone files related to the syntax adaptation
script are loaded. For details, see 10.5 Checking the Syntax Adaptation Script.
l If all the dynamic tone files are loaded, proceed with Step 11.
l If not, perform Step 8 to reload the dynamic tone files to the VPU.
Step 11 Activate the VPU.
Run ACT BRD to activate the VPU.
Step 12 Repeat Step 7 to Step 11 on other announcement boards, that is, other VPUs, to load the syntax
adaptation script to them.
----End

10.4 Rolling Back a Syntax Adaptation Script

This section describes how to roll back a syntax adaptation script.
Prerequisite
CAUTION
The media gateway (MGW) must be operating normally and the VPU must be deactivated.
Otherwise, errors occur during a syntax adaptation script rollback.
Syntax adaptation script rollback may be required during a version rollback or temporary test.
Syntax adaptation script rollback contains two steps:
1. Deleting a syntax adaptation script and the related dynamic tone files
After the syntax adaptation script is removed from the memory of the VPU, the syntax
analysis capability described in the syntax adaptation script is ineffective for the VPU. You
can remove a syntax adaptation script from a VPU that has started normally. You can also
remove the syntax adaptation script from the hard disk of the OMU at the same time.
2. Reloading the backup syntax adaptation script and the related dynamic tone files
Procedure
Step 1 Deactivate the board.
Run DEA BRD to deactivate the board to which the syntax adaptation script is loaded. Then,
wait 15 seconds.
NOTE
Run DSP MEDIARES to check whether resources occupied by calls on the board are released.
Step 2 Remove the syntax adaptation script.

Run RBK TONE to remove the syntax adaptation script.
l If you do not specify Frame No., all the frames are selected.
l If you do not specify Slot No., all the boards in the specified frame are selected.
l If you do not specify File name, all the dynamic tone files or syntax adaptation scripts on
the specified boards are removed.
l File Type can be set to Syntax adaptation script or Dynamic tone. The default value is
Dynamic tone.
l If you set Delete the tone file on the HD to YES, the corresponding syntax adaptation script
on the hard disk is also removed. If you set Delete the tone file on the HD to NO, files on
the hard disk are not removed.
NOTE
Before a software upgrade, remove the existing scripts that will not be applicable in the new version.
Otherwise, the VPU will obtain these scripts from the file system on the hard disk of the OMU after the
MGW or the VPU restarts, thus affecting the existing services.

For example, to remove the GA_01.ini script on the VPU in slot 10 of frame 1 without removing
the GA_01.ini script on the hard disk, run the following command:
RBK TONE: FN=1, SN=10, FLN="GA_01.ini", DLF=NO, MT=GA;
The execution result is as follows:

%%RBK TONE: FN=1, SN=10, FLN="GA_01.ini", DLF=NO, MT=GA;
%%RETCODE = 0 accomplished
Tone file rollback result

--------------------
Frame No. Slot No. Board type Result
1 10 VPU Success
--- END
Step 3 Check whether the script is removed.

Run CHK TONE to check whether the syntax adaptation script is removed from the VPU and
the file system of the OMU. For details, see 10.5 Checking the Syntax Adaptation Script.
Step 4 Remove the dynamic tone files.
For details on how to remove the dynamic tone files, see Rolling Back Tone Files.
Step 5 Reload the syntax adaptation script and dynamic tone files.
Copy the backup syntax adaptation script and dynamic tone files to c:\bam\bin\tonepatch, and
then reload these files. For details, see 10.3 Loading a Syntax Adaptation Script.
----End
10.5 Checking the Syntax Adaptation Script

This section describes how to check the syntax adaptation script and related dynamic tone files.
Prerequisite
l The media gateway (MGW) operates normally, and the OMU and VPU are normal.
l No loading commands are being executed.
CHK TONE is used to check whether the syntax adaptation script is loaded on the OMU and
the VPU and whether the syntax adaptation scripts on these two boards are the same. If the syntax
adaptation scripts on these two boards match, it indicates that the syntax adaptation script is
loaded successfully.
DSP TONE is used to check whether all the dynamic tone files related to the syntax adaptation
script are loaded on the VPU. If all these dynamic tone files are not loaded, ALM-1630 Not all
tone files are loaded is generated.
Procedure
Step 1 Check the loading status of the syntax adaptation script.
Run CHK TONE to check whether the syntax adaptation script is loaded successfully.

Dynamic tone.
For example, run the following command to check whether the syntax adaptation script exists
on the VPU in slot 10 of frame 1 and the hard disk of the OMU. If yes, check whether they are
the same.
CHK TONE: FN=1, SN=10, MT=GA;

%%CHK TONE: FN=1, SN=10, MT=GA;%%
Tone file check info

----------------
Frame No. Slot No. Board type File name Exist in BAM Exist in board Match
1 1 VPU GA_01.ini Yes Yes Yes

1 1 VPU GA_FE.ini Yes No No
1 1 VPU GA_03.ini Yes Yes No
1 1 VPU GA_04.ini Yes Yes Yes
File number in board = 3

File number in bam = 4
Matched file number = 2
If the syntax adaptation script on the VPU and that on the hard disk of the OMU match, it indicates
that the loading is successful. If not, it indicates that the syntax adaptation script is loaded to
only the hard disk of the OMU but is not loaded to the VPU. In such a case, perform Step 8 in
10.3 Loading a Syntax Adaptation Script to load the syntax adaptation script to the VPU.
Step 2 Check the loading status of dynamic tone files related to the syntax adaptation script.
Run DSP TONE to check the loading status of dynamic tone files related to the syntax adaptation
script.
l Language type refers to the language ID. Each language ID is specific to a syntax adaptation
script.
l Loaded or not specifies the type of tone files to be displayed. You can choose to query the
tone files that are loaded or the tone files that are not loaded to the specified board.
For example, run the following command to check the loading status of the dynamic tone files
in slot 10 of frame 1:
DSP TONE: FN=1, SN=10;

%%DSP TONE: FN=1, SN=10;%%
Loading status of tone files specific to the syntax adaptation script

------------------------------
Frame No. Slot No. Board type Language type Variable intelligent tone ID Loaded or no
1 10 VPU 1(0x01, English) 200(0x000000C8) Yes

1 10 VPU 1(0x01, English) 201(0x000000C9) Yes
1 10 VPU 254(0xFE, German) 4294967293(0xFFFFFFFD) No
1 10 VPU 254(0xFE, German) 4294967294(0xFFFFFFFE) Yes

Tone file information

--------
Number of files to be loaded = 4
Number of tone files loaded = 3
Number of tone files not loaded = 1
The execution result shows whether the dynamic tone files are loaded. If some dynamic tone
files are not loaded, perform Step 8 in 10.3 Loading a Syntax Adaptation Script load these
dynamic tone files to the VPU.
----End
10.6 Querying the Syntax Adaptation Script

This section describes how to query a syntax adaptation script.
Prerequisite
The media gateway (MGW) operates normally, and the OMU and VPU are normal.
LST TONE is used to check the information, such as the file name, time stamp, and file size,
about the syntax adaptation script on a specified board.
Procedure
Step 1 Run LST TONE to query the syntax adaptation script.
l If you do not specify Frame No., the syntax adaptation scripts in all the frames are queried.
l If you do not specify Slot No., syntax adaptation scripts on all the boards in the specified
frame are queried.
Dynamic tone.
l Language type refers to the language ID. Each language ID is specific to a syntax adaptation
script.
----End
Example
Run the following command to query all the syntax adaptation scripts on the VPU in slot 10 of
frame 1.
The configuration script is as follows:
LST TONE: FN=1, SN=10, TTYPE=GA;
An example execution result is as follows:

%%LST TONE: FN=1, SN=10, TTYPE=GA;%%
Load result
--------------------
FRAME SLOT Board position Language type File name Time stamp File size (Byte

1 10 VPU 1(0x01, English) GA_01.ini 2008-08-05 12:04:22 64544
--- END
10.7 Protocol and Specification of Syntax Adaptation

This section describes the compliance protocol and specification of this feature.
Table 10-1 Protocol and specification of syntax adaptation

Syntax adaptation None

Feature Description 11 Multi-Level Overload Control
11 Multi-Level Overload Control
About This Chapter
protocols and specifications of multi-level overload control.
11.1 Overview of Multi-Level Overload Control

11.2 Availability of Multi-Level Overload Control
11.3 Principle and Flow of Multi-Level Overload Control
11.4 Configuring Congestion and Overload Protection for the System
11.5 Protocol and Specification of Multi-Level Overload Control

11 Multi-Level Overload Control Feature Description
11.1 Overview of Multi-Level Overload Control

Feature Definition
Without the overload control, when the call requests from the media gateway controller (MGC)
exceed the processing capability of the CMU, the put-through rate for the new calls becomes
lower, the successful access of important calls cannot be ensured, and the calls with low priority
may not be connected. As a result, the overload control system must be used to manage the
volume of the new calls and protect the UMG8900 system. The multi-level overload control
includes the overload control that the MGC provides for the UMG8900 and the overload
protection provided by the UMG8900 itself.
The MGC processes the overload of the UMG8900 and thus ensures the system security of the
UMG8900. The MGC and the UMG8900 must work together to realize the overload control
function. The overload control of the MGC can be classified into H.248.11-based control and
H.248.10-based control. The H.248.11 protocol is used for overload control, and the H.248.10
protocol is used for congestion control.
l H.248.11 defines the overload control package (OCP), which can notify the MGC when
the call strength of the UMG8900 exceeds the overload threshold of H.248.11.
l H.248.10 defines the congestion handling package, which can ask the MGC to reject some
new calls when the call strength of the UMG8900 exceeds the overload threshold of H.
248.10. The H.248.10 protocol puts forwards the concept of multi-level overload control.
A certain level controls certain center processing unit (CPU) utilization, and rejects the
calls of a certain percentage accordingly. For example:
– Level 1: CPU overload 80%, and 20% of the calls rejected.
The UMG8900 can implement its own overload protection function without interacting with the
MGC. That is, the overload protection can be configured and implemented independently. The
situation where the overload protection function is used can be:
l The MGC does not support the overload protection, and only the overload protection system
of the UMG8900 is used.
l The MGC supports the overload control, which, however, is not successful. When the CPU
utilization of the CMU exceeds the protection threshold, the UMG8900 enables its overload
protection system to reject some calls according to the percentage and the priority.

Service Benefits
Table 11-1 Service benefits of multi-level overload control

Multi-level It avoids the loss of the connection It reduces the

overload control triggered by the overload, and improves the probability of the
customers' satisfaction. connection loss.
11.2 Availability of Multi-Level Overload Control

Required NEs
Table 11-2 Required NEs for multi-level overload control

Feature Required NE
Multi-level overload If MGC performs the overload control for the UMG8900, the MGC
control and the UMG8900 must work together.
The UMG8900 can implement its own overload protection function
without interacting with the MGC. That is, the overload protection can
be configured and implemented independently.
Version Support
Table 11-3 Versions supporting multi-level overload control

Multi-level overload control R005C02 and later
11.3 Principle and Flow of Multi-Level Overload Control

H.248.11 Overload Control

1. The UMG8900 must be pre-configured with overload threshold and disabling threshold.
When the center processing unit (CPU) utilization exceeds the overload threshold, the

11 Multi-Level Overload Control Feature Description
UMG8900 enables the overload control, and reports an overload control packet (OCP)
whenever N ADD commands are received (N refers to an integer that is configurable). The
reporting rate is configurable. When the CPU utilization drops below the disabling
threshold, the UMG8900 disables overload control and stops sending the OCP.
2. The frequency of overload messages received by the MGC exceeds the preset value (usually
a small value), but the overload control is not enabled, and then the MGC enables the leaky
bucket algorithm to control the overload. The leaky bucket algorithm, which is independent
of the UMG8900, is implemented by the MGC.
H.248.10 Congestion Control

1. The overload threshold and the rejected call percentage for multiple levels of overload must
be configured.
2. Based on the overload level, the gateway reports the calls of different percentage to be
rejected. The percentage is carried in CHP; for instance, X=20 indicates the MGC rejects
20% of the calls.
MGW Overload Protection

1. The UMG8900 must be pre-configured with a protection threshold. Set the priority of the
maximum accepted calls during the call control to K, and the initial configured value is an
integer value between the minimum priority and the maximum priority of the system.
Configure the initial rejected percentage.
2. Start a timer that periodically detects the CPU utilization. When the CPU utilization of the
gateway exceeds the protection threshold, enable the overload protection. Accept the calls
whose priority is higher than K, and reject the calls whose priority is lower than K. If the
priority of the calls is equal to K, reject calls according to the initial configured percentage
of the rejected calls.
3. After the overload control is enabled, if the overload still occurs, increase the percentage
of the rejected calls until all the calls (100%) whose priority is not higher than K is rejected.
If the gateway is still overloaded, change the priority K into K+1, until the maximum
priority of the system is reached.
4. After the overload control is enabled, if the CPU overload rate is below the overload
threshold, enable a timer of one second. If the CPU overload rate is still below the overload
threshold, change the priority K into K-1.
5. If the current priority is lower than the minimum priority of the system, enable a timer of
30 minutes (T30). The timer is configurable. After the T30 is timed out, if the current
priority is still lower than the minimum priority of the system, the UMG8900 stops the
overload control.
11.4 Configuring Congestion and Overload Protection for

the System
Procedure
Step 1 Run SET OLCTR to set the MGC-controlled H.248.11 overload control and H.248.10
congestion control.

Step 2 Run SET OLPRO to configure the overload protection of the gateway.
----End
11.5 Protocol and Specification of Multi-Level Overload

Control
Table 11-4 Protocols and specifications of multi-level overload control

Multi-level overload control H.248.11

H.248.10

Feature Description 12 IP Interface Protection
12 IP Interface Protection
About This Chapter
protocols and specifications of Internet Protocol (IP) interface protection.
12.1 Overview of IP Interface Protection

12.2 Availability of IP Interface Protection
12.3 Implementation Principles and Service Flow of IP Interface Protection
12.4 Data Configuration of IP Interface Protection
12.5 Protocol and Specification of IP Interface Protection

12 IP Interface Protection Feature Description
12.1 Overview of IP Interface Protection

Feature Definition
The UMG8900 is a large-capacity device in the core network. To ensure service reliability, the
UMG8900 is generally required to provide the interface protection function.
In the data communication network, various Internet Protocol (IP) packet interfaces, such as the
Fast Ethernet (FE) and Gigabit Ethernet (GE) interfaces, are provided. In actual networking
applications, the UMG8900 may be connected to LAN Switches or routers; therefore, multiple
protection modes must be supported.
The UMG8900 supports the FE and GE interfaces and provides abundant interface protection
functions to meet the requirements of various networking solutions.
In the communication network, independent data communication devices are usually configured
in the packet-switched IP core network. The packet services of the network elements (NEs) can
be accessed through the LAN Switches or through the core network routers that are directly
connected to the NEs.
When services are carried on the FE interface, service convergence is usually implemented
through the LAN Switch. When services are carried on the GE interface, the NEs are directly
connected to the routers or transmission devices.
The UMG8900 supports abundant IP interface backup functions, such as:
l Master/slave and load-sharing protection functions of the FE interface: Bidirectional
forwarding detection (BFD) is usually applied on the master and slave FE interfaces. In
this case, the peer LAN Switch must be configured with the Virtual Router Redundancy
Protocol (VRRP). BFD and route backup are usually applied on the FE interfaces that work
in load-sharing mode.
l IP trunk function of the FE interface
l Master/slave and load-sharing protection functions of the GE interface: BFD is usually
applied on the master and slave GE interfaces. In this case, the peer router must be
configured with the VRRP. BFD and route backup are usually applied on the GE interfaces
that work in load-sharing mode.
Service Benefits
Table 12-1 Service benefits of IP interface protection
IP interface protection This feature supports various Quality of voice services and
IP packet service protection data services are improved.
and backup functions. With
this feature, network
reliability is enhanced and
service quality is improved.

Table 12-2 Function restrictions of IP interface protection
IP interface The routers and LAN Switches interconnected with the UMG8900
protection must support the following:
l BFD (necessary for quick detection of faults)
l VRRP (necessary for non-APS 1+1 backup of the FE and GE
interfaces)
l IP trunk
12.2 Availability of IP Interface Protection

Required NEs
Table 12-3 Required NEs for IP interface protection
Feature Required NE
FE interface protection MGW and router
GE interface protection MGW and router
IP enhanced fault detection BFD MGW and router
Route backup MGW and router
Version Support
Table 12-4 Versions supporting IP interface protection
FE interface protection R005C02 and later
GE interface protection R005C02 and later
IP enhanced fault detection BFD R005C02 and later
Route backup R005C02 and later

12.3 Implementation Principles and Service Flow of IP

Interface Protection
Related concepts are described as follows:
l Protection group
After a protection group is configured, non-APS 1+1 protection can be realized on the IP
interfaces. The non-APS 1+1 protection is described as follows:
Non-APS 1+1 protection is also called master/slave protection. One protection group
consists of a pair of master and slave interfaces, and services are switched based on the Up/
Down status of the interfaces. In the normal state, the master interface is used. If the master
interface is Down, services are switched to the slave interface. Hardware of some interfaces
supports this protection mode automatically without any special configuration. This mode
generally applies to the scenario where the FE or GE interface of the UMG8900
interconnects with a router.
The implementation of master/slave protection varies for the interconnection with different
interfaces and front boards:
– The FE interface in the HRU+FE application automatically supports master/slave
protection. Therefore, protection groups are not needed.
– The FE interface in the HRD+FE application supports load sharing by default.
Therefore, protection groups must be configured for master/slave protection.
– The GE interface in the HRU+GE and HRD+GE applications supports load sharing by
default. Therefore, protection groups must be configured for master/slave protection.
l BFD
The Bidirectional Forwarding Detection (BFD) protocol is a simple Hello protocol. A pair
of systems periodically sends detection packets on the channel for setting up sessions
between them. If a system does not receive the detection packets of the peer system for a
long time, it considers that the bidirectional channel to the peer system is faulty. BFD can
detect faults on channels of any type between systems. These channels can be physical
links, virtual circuits, tunnels, multiprotocol label switching (MPLS) label switched paths
(LSPs), multiple-hop routing paths, and non-direct channels. Meanwhile, BFD can detect
forwarding faults quickly because it is simple and dedicated to fault detection. Therefore,
BFD ensures high quality of the transmission of voice service, video service, and other
demand services. It also ensures high reliability and high applicability of voice over IP
(VoIP) and other real-time services.
l Route backup
The route backup function is to improve the reliability of networks. Carriers can configure
multiple routes to the same destination based on the actual conditions. One of the routes
has the highest priority and serves as the master route; the other routes have lower priorities
and serve as the slave routes. Normally, the router adopts the master route to forward data.
When the line is faulty, the master route becomes inactive and the router selects the route
with the highest priority among the slave routes to forward data. Thus, the switchover from
the master route to the backup route is realized. When the master route recovers, the router

restores the status of the master route to be active and selects a route to send data. The
master route has the highest priority. Therefore, the router selects the master route to send
data. In this manner, the switchover from the backup route to the master route is realized.
l VRRP
The Virtual Router Redundancy Protocol (VRRP) is an error tolerance protocol defined by
RFC2338.
Usually, one default route is configured on all the hosts in one network. The next hop IP
address of the route is set to 10.110.10.1, as shown in Figure 12-1. As a result, packets of
which the destination IP addresses are not in the network segment are sent to router A
through the default route for communication with the external network. Figure 12-1 shows
the networking.
When router A is faulty, the communication between the hosts whose default route is
destined for router A and the external network fails.
Figure 12-1 Networking for the LAN
The VRRP technology targets at the preceding problem. It is designed for the local area
network (LAN), such as the Ethernet, with the multicast or broadcast capability. The VRRP
technology binds a group of routers in the LAN into a virtual router. This group of routers
is called a backup group. The backup group consists of one master router and several backup
routers. Figure 12-2 shows the VRRP diagram.

Figure 12-2 VRRP diagram
The virtual router has its own IP address 10.100.10.1, and the routers in the backup group
have their own IP addresses. For example, the IP address of the master router is 10.100.10.2
and that of a backup router is 10.100.10.3. The hosts in the LAN are aware of only the IP
address 10.100.10.1 of the virtual router, rather than the IP address 10.100.10.2 of the
master router or the IP address 10.100.10.3 of the backup router. The hosts take the IP
address 10.100.10.1 of the virtual router as the next hop address of their default route. Thus,
the hosts in the network can communicate with hosts in other networks through the virtual
router. The master router and backup routers are usually in the same broadcast domain. The
packets sent by the host can be sent to both the master router and a backup router. When
the backup router receives the packets, it discards them; when the master router receives
the packets, it forwards them. Therefore, in networking, the ports on the master router and
backup routers connecting to the ports on the host are grouped in one virtual LAN (VLAN).
In this manner, these ports are in the same broadcast domain.
If the master router in the backup group is faulty, a router is selected from the backup routers
in the group through the voting policy to act as the master router. The new master router
continues to provide routing services for the hosts in the network. Thus, the hosts in the
network can continuously communicate with the external network.
12.3.1 FE Interface Protection
This section describes the implementation principles and service flow of Fast Ethernet (FE)
interface protection.
12.3.2 GE Interface Protection
This section describes the implementation principles and service flow of Gigabit Ethernet (GE)
12.3.3 IP Enhanced Fault Detection BFD
This section describes the implementation principles and service flow of IP enhanced fault
detection BFD.
12.3.4 Route Backup
This section describes the implementation principles and service flow of route backup.

12.3.1 FE Interface Protection

This section describes the implementation principles and service flow of Fast Ethernet (FE)
The FE interface is usually applied in the following scenarios:
l The service capacity of the device is small, or the device is used to transmit signaling
messages only.
l The node where the device is located is not in the same place as the Internet Protocol (IP)
packet backbone routing node.
l Service stream convergence must be realized on Layer 3 LAN Switches, which reduces the
number of transmission interfaces and uplink optical fibers. For example, convergence of
multiple FE links into one Gigabit Ethernet (GE) link.
Figure 12-3 shows the networking of the FE interface.
Figure 12-3 Networking of the FE interface
The UMG8900 provides FE interfaces to connect to two Layer 3 LAN Switches respectively.
The UMG8900 is connected to the IP packet core network through the LAN Switch convergence.
In actual networking, two provider edge (PE) devices can be connected to the Layer 3 LAN
Switches respectively. Through the two PE devices, the UMG8900 is connected to the packet
core network. Configurations of the FE interfaces working in master/slave mode are different
from those of the FE interfaces working in load-sharing mode. The details are described as
follows:
Master/Slave FE Interfaces + VRRP

When HRUs are interconnected with the interface boards providing the FE interfaces, the FE
interfaces work in master/slave mode by default. When HRDs are interconnected with the
interface boards providing the FE interfaces, a protection group can be configured for the FE
interfaces to work in master/slave mode.

The FE interfaces working in master/slave mode are usually directly connected to two Layer 3
LAN Switches. The two LAN Switches implement service convergence and adopt the Virtual
Router Redundancy Protocol (VRRP). Figure 12-4 shows the networking.
Figure 12-4 Networking for FE interface protection
FE interfaces are configured on the UMG8900. A pair of master and slave FE interfaces shares
one IP address IP0 and connect to two LAN Switches respectively. The LAN Switches adopt
VRRP. The IP address of the virtual LAN (VLAN) interface is IP1.
The UMG8900 can detect loss of physical signals. To detect faults quickly, the UMG8900 and
the interconnected LAN Switches must support bidirectional forwarding detection (BFD). When
the master FE interface is faulty or the UMG8900 detects that the master link fails through BFD,
services are switched to the other FE interface. Then, the UMG8900 delivers a new Medium
Access Control (MAC) address through gratuitous Address Resolution Protocol (ARP) packets.
After receiving the ARP packets, the LAN Switches update their local MAC address table and
routing information. During this process, services on the UMG8900 are almost not affected.
NOTE
During the switchover, alarms are generated and packets are lost.
Load-sharing FE Interfaces + Route Backup

When HRDs are interconnected with the interface boards providing the FE interfaces, the FE
interfaces work in load-sharing mode by default. In this mode, route backup is usually applied.
BFD is usually configured to support quick detection of link faults. For the principles of BFD
and route backup, see the related documents.
IP Trunk
The IP trunk technology is an IP address binding mode. In this mode, multiple interfaces are
bound to save IP addresses.
Figure 12-5 shows the IP trunk networking.

Figure 12-5 Networking of IP trunk
Configure a trunk group on the UMG8900 and set the IP address of the trunk group. Multiple
ports are available in one trunk group. When one port is faulty, services on the port are shared
by the other ports in the trunk group, thus realizing service protection.
12.3.2 GE Interface Protection

This section describes the implementation principles and service flow of Gigabit Ethernet (GE)
The GE interface is usually applied when the UMG8900 and the Internet Protocol (IP) packet
backbone node are deployed in the same equipment room, where the interfaces of high-end
routers are available for direct connection. In this case, the UMG8900 is connected to dual
provider edges (PEs) or a single PE.
Figure 12-6 shows the network diagram of the GE interface.
Figure 12-6 Networking of the GE interface
If the UMG8900 has a large capacity or functions as the key device in the network, the dual PE
networking mode is recommended.
The protection mode of the GE interfaces working in master/slave mode is different from that
of the GE interfaces working in load-sharing mode. The details are described as follows:

Master/Slave GE Interfaces + VRRP

The GE interfaces working in master/slave mode are usually connected to a single PE or dual
PEs. In dual PE mode, the two PEs adopt the Virtual Router Redundancy Protocol (VRRP).
Figure 12-7 shows the networking.
Figure 12-7 Networking for GE interface protection
GE interfaces are configured on the UMG8900. A pair of master and slave GE interfaces shares
one IP address IP0 and connect to PE 1 and PE 2 on the IP backbone network node respectively.
The two PEs adopt VRRP and share an IP address IP1.
The UMG8900 can detect loss of physical signals. To detect faults quickly, however, the
UMG8900 and the interconnected PEs must support bidirectional forwarding detection (BFD).
When the master GE interface is faulty or the UMG8900 detects that the master link fails through
BFD, services are switched to the other GE interface. Then, the UMG8900 delivers a new
Medium Access Control (MAC) address through gratuitous Address Resolution Protocol (ARP)
packets. After receiving the ARP packets, the PEs update their local MAC address table and
routing information. During this process, services on the UMG8900 are almost not affected.
NOTE
During the switchover, alarms are generated and packets are lost.
Load-sharing GE Interfaces + Route Backup

By default, the GE interfaces work in load-sharing mode. In this mode, route backup is usually
applied. BFD is usually configured to support quick detection of link faults. For the principles
of BFD and route backup, see 12.3.3 IP Enhanced Fault Detection BFD and 12.3.4 Route
Backup.
12.3.3 IP Enhanced Fault Detection BFD

This section describes the implementation principles and service flow of IP enhanced fault
detection BFD.
Principle of BFD
BFD is short for the bidirectional forwarding detection protocol. The fast protection of failure
in the Internet Protocol (IP) networking depends on two technologies: fast response to failure

and fast protection switchover of failure. The fast protection switchover of failure mainly
includes the fast convergence technology of the route and fast reroute technology (FRR). For
the devices in the core network, they are the fast switchover of the master and slave links and
the fast switchover of the load-sharing links. The precondition of the technology is the fast
response to failure, that is, BFD.
The BFD is proposed by the Internet Engineering Task Force (IETF). By now, the fourth draft
is issued. A request for comments (RFC) is to be formed in the near future. By periodically
sending failure detection data packet based on User Diagram Protocol (UDP), BFD not only
detects and judges the physical disconnection failure of the transmission links, optical interface,
and electrical interface, but also detects and judges failure at the link layer and network layer,
such as the packet loss, error codes, and forwarding errors. BFD makes up for the defect of
detecting failure at only the physical layer.
The BFD detects failure at layer 3; therefore, both ends of the detected link must be configured
with the IP addresses. Theoretically, the detected links can be end-to-end links. In actual
applications, the BFD is usually deployed on link segments. The switchover of the end-to-end
link has strict requirements for the relevant switchover between devices in the entire network,
and severely affects the traffic of the entire network. In addition, in most cases, a suitable end-
to-end link is not available. The protection for link segments can be easily achieved. Through
the clearance of failure in the network segment, the end-to-end link remains connected.
The BFD mechanism enables detection and judgment of failure in 30 milliseconds. It is a perfect
failure detection function for the new generation router. With other failure protection measures,
the BFD lays a solid foundation for a highly reliable IP network.
Combined Application of BFD Detection, Protection Group, and Route Backup

BFD levels, namely, IP level and IF level, can be configured. By default, the IP level is adopted.
The result of IP-level BFD detection influences only the source IP address, and that of the IF-
level BFD detection influences the whole interface. That is, if an interface is configured with
multiple IP addresses and the IF-level BFD detection is adopted, the BFD of the interface
becomes down if that of a configured IP address is down.
The board that supports independent interface backup is the HRU with the GE interface board.
That is, an HRU controls two back IP interface boards, and the IP interfaces on the two IP
interface boards can be separately numbered in applications. The boards that do not support
independent interface backup are the HRU with the FE interface board, the HRU with the POS
interface board, and the MPU/OMU. That is, an HRU controls only one back IP interface board,
and the IP interfaces on the two IP interface boards work in 1+1 backup mode. The board
switchover processes of these two kinds of boards are different. For details, see the following:
1. BFD switchover process of the IP-level BFD detection (combined with route backup)
On condition that the IP-level BFD detection is used jointly route backup, the switchover
processes of boards that support or do not support independent interface backup are the
same after the BFD detection is down. The detailed process is as follows:
l If the slave IP address of the configured IP address is normal (the interface, gateway,
and BFD detection are all up)
– Services are switched to the slave IP address if the master IP interface, gateway, or
BFD detection is down.
– The BFD still processes packets on the original port rather than being switched
together with route backup.

– Services are switched back to the master IP address after the master IP interface is
up, the gateway resolution is successful, and the BFD session is up.
l If no slave IP address is available, or the slave IP address is abnormal (the interface,
gateway, or BFD detection is down), the master IP address becomes down if the master
IP interface, gateway, or BFD detection is down.
2. BFD switchover process of the IF-level BFD detection (combined with protection group
or route backup and BFD is configured on the board supporting independent interface
backup)
On condition that the BFD is configured on the board supporting independent interface
backup and the BFD is used jointly with protection group or route backup, the switchover
process after the IF-level BFD detection is down is as follows:
l If the interface is in the protection group
– Services of the master interface in the protection group are switched to the slave
interface.
– The BFD is switched together with the protection group and always processes
packets in the valid working path.
– Services on the slave interface are switched back to the master interface after the
master IP interface is up, the gateway resolution is successful, and the BFD session
is up.
l If the interface is not in the protection group, check whether route backup is configured
for the IP address of the interface. If yes, services are switched to the slave IP address
if the switchover requirements are met.
3. BFD switchover process of the IF-level BFD detection (BFD is configured on the board
not supporting independent interface backup)
On condition that the BFD is configured on the board not supporting independent interface
backup, the switchover process after the IF-level BFD detection is down is the process of
board switchover. The conclusion is as follows:
l For a board that provides interfaces, such as the HRU providing GE interfaces
– The BFD detection type is the IP address type. Route switchover is triggered when
BFD sessions are Down. Route backup must be configured.
– The BFD detection type is the interface type. If protection groups are configured,
the switchover of protection groups can be triggered; if route backup is configured
on the interface, route switchover can be triggered for the IP address that is
configured with route backup.
l For a board that is configured with protection groups, if the BFD detection type is the
IP address type, the board only reports an alarm when the BFD sessions are Down. The
switchover of protection groups is triggered only when the BFD detection type is
configured as the interface type.
l For a board that does not support independent interfaces, such as the MPU, the
switchover of the boards can be triggered when the BFD detection type is either the IP
address type or the interface type.
12.3.4 Route Backup

This section describes the implementation principles and service flow of route backup.
Overview
The route backup function is to improve the reliability of the network. Users can configure
multiple routes to the same destination based on the actual conditions. One of the routes has the

highest priority and serves as the master route; the other routes have lower priorities and serve
as the slave routes.
Normally, the router adopts the master route to transfer the data. When the line is faulty, the
master route becomes inactive and the router chooses the route with the highest priority in the
slave routes to transfer the data. Thus, the switchover from the master route to the slave route is
realized. When the master route is restored, the router restores the corresponding route and
chooses the route again. The master route has the highest priority, so the router chooses this
route to send the data. In this case, the router performs switchover from the slave route to the
master route.
After the route backup relation is configured on two Internet Protocol (IP) interfaces of the HRB,
when the interface or link with the master IP address is faulty, IP packets (including service
packets and control packets) with the master IP address as the source IP address are sent through
the interface with the slave IP address. Route backup in different networking environments is
respectively depicted as follows.
As shown in Figure 12-8, IP interfaces IP 0 and IP 1 are in different network segments and route
backup is configured on these IP addresses. When the master link is normal, packets with IP 0
as the source IP address are sent by the master interface IP 0, and the master interface IP 0 and
slave interface IP 1 can receive the packets with IP 0 as the destination IP address. When the
master link is faulty, packets with IP 0 as the source IP address are sent by the slave interface,
and those with IP 0 as the destination IP address are received by the slave interface IP 1.
Figure 12-8 Route backup diagram 1
As shown in Figure 12-9, when IP0 and IP1 are in the same network segment, two networking
modes are available. In the two networking modes, normally, packets with IP 0 as the source IP
address are sent by the master interface IP 0; when IP 0 is faulty, the preceding packets are sent
by the slave interface IP 1. When receiving packets, based on the received Address Resolution
Protocol (ARP) response packets, the gateway resolves the media access control (MAC) address
related to the main IP address of the UMG8900, and then decides whether to send the IP packets
with IP 0 as the destination IP address to the master interface or the slave interface. When the
master and slave interfaces are in the same local area network (LAN), only the links between
the UMG8900 and switch can be protected. Thus, the master and slave interfaces are often
configured in different LANs.

Figure 12-9 Route backup diagram 2
12.4 Data Configuration of IP Interface Protection

12.4.1 Data Configuration of BFD

This section describes the data configuration for enabling and maintaining BFD.
12.4.2 Data Configuration of Route Backup
This section describes the data configuration for enabling and maintaining route backup.
12.4.1 Data Configuration of BFD

This section describes the data configuration for enabling and maintaining BFD.
Context
The bidirectional forwarding detection (BFD) can provide the fast fault detection function. Once
a fault is detected, the route can be protected through route backup.
Procedure
Step 1 Run ADD BFD to configure BFD detection.
----End
Example
Network diagram
In this example, the BFD and route backup are configured for the IP bearer. If the master route
is detected to be faulty, the slave route works and takes over the services. Figure 12-10 shows
the network diagram.

Figure 12-10 IP bearer network diagram
The master IP address can be 192.168.1.1 and the slave IP address can be 192.168.1.2. When
the BFD detects failure of the master IP address, the slave IP address can be used.
The master IP address is configured on interface 0 of HRB 0 in the UMG8900, and the gateway
IP address is 192.168.1.254. The slave IP address is configured on interface 1, and the gateway
IP address is 192.168.1.254.
The BFD needs to be configured on the router. The source IP address is set to 192.168.1.254,
and the destination IP address is set to 192.168.1.1.
NOTE
If the LAN Switch interconnected with the UMG8900 is the S3328, Detect Type must be set to Interface.
//Configure the IP address.
ADD IPADDR: BT=HRB, BN=0, IFT=GE, IFN=0, IPADDR="192.168.1.1",
ADD IPADDR: BT=HRB, BN=0, IFT=GE, IFN=1, IPADDR="192.168.1.2",
//Set the bearer bandwidth. The bandwidth of the master IP address in route backup
needs to use the non-bearer bandwidth of the interface that the slave IP address is
configured on after route switchover; therefore, the bearer bandwidth cannot be set
to the line speed.
MOD IPIF: IFT=GE, BT=HRB, BN=0, IFN=0, AUTONEGO=NO, BEARBW=512000;
//Configure the gateway IP address.

TIMEOUT=NoAging;
TIMEOUT=NoAging;
//Configure the route backup.

ADD RTBAK: BT=HRB, BN=0, IFT=ETH, IFN=0, IPADDR="192.168.1.1",
IPADDRBAK="192.168.1.2";
//Configure the BFD.

ADD BFD: BT=HRB, BN=0, IFT=ETH, IFN=0, BFDNM="UMG8900_BFD_1", TYPE=IP,
SRCIP="192.168.1.1", DSTIP="192.168.1.254", DISCLO=1, DISCRE=1;
12.4.2 Data Configuration of Route Backup

This section describes the data configuration for enabling and maintaining route backup.
Procedure
Step 1 Run ADD IPADDR to add an IP address.
Step 2 Run MOD IPIF to configure the bearer bandwidth.

Step 3 Run ADD GWADDR to configure the gateway IP address.
Step 4 Run ADD RTBAK to configure the route backup.
----End
Example
Networking diagram
As shown in Figure 12-11, the UMG8900 is connected to the router through two links. The two
interfaces of the UMG8900 are in the network segments 1.1.1.1/8 and 2.2.2.2/8.
Figure 12-11 Network diagram for route backup
Configure the bidirectional route backup to ensure that the UMG8900 can use the other interface
to receive and send packets in case that one link is faulty.
The gateway IP address of interface 0 on HRB 0 of the UMG8900 is 1.1.1.100. The gateway IP
address of interface 1 is 2.2.2.100.
Configure two static routes on the router.

[Quidway] ip route-static 1.0.0.0 255.0.0.0 gigabitEthernet0/0/1 preference 60
[Quidway] ip route-static 2.0.0.0 255.0.0.0 gigabitEthernet0/0/0 preference 60
//Configure the IP address.
ADD IPADDR: BT=HRB, BN=0, IFT=GE, IFN=0, IPADDR="1.1.1.1", MASK="255.0.0.0",
FLAG=MASTER, INVLAN=NO;
ADD IPADDR: BT=HRB, BN=0, IFT=GE, IFN=1, IPADDR="2.2.2.2", MASK="255.0.0.0",
FLAG=MASTER, INVLAN=NO;
//Configure the bearer bandwidth. The interface where the master IP address of the
route backup is located transfers packets by using the non-bearer bandwidth of the
interface where the slave IP address is located after routes are switched over;
therefore, the bearer bandwidth of the interface where the slave IP address is
located cannot be set to the line speed.
//Configure the gateway IP address.

ADD GWADDR: BT=HRB, BN=0, IPADDR="1.1.1.1", GWIP="1.1.1.100", TIMEOUT=Aging;
ADD GWADDR: BT=HRB, BN=0, IPADDR="2.2.2.2", GWIP="2.2.2.100", TIMEOUT=Aging;
//Configure the route backup.

ADD RTBAK: BT=HRB, BN=0, IFT=GE, IFN=0, IPADDR="1.1.1.1", IPADDRBAK="2.2.2.2";
ADD RTBAK: BT=HRB, BN=0, IFT=GE, IFN=1, IPADDR="2.2.2.2", IPADDRBAK="1.1.1.1";
12.5 Protocol and Specification of IP Interface Protection


Table 12-5 Protocols and specifications of IP interface protection

IP interface protection None

Feature Description 13 SDH/SONET Interface Protection
13 SDH/SONET Interface Protection
About This Chapter
protocols and specifications of synchronous digital hierarchy (SDH)/synchronous optical
network(SONET) interface protection.
13.1 Overview of SDH/SONET Interface Protection

13.2 Availability of SDH/SONET Interface Protection
13.3 Principle and Flow of SDH/SONET Interface Protection
This section describes the implementation principle and service flow of this feature.
13.4 Data Configuration of SDH/SONET Interface Protection
13.5 Protocol and Specification of SDH/SONET Interface Protection

13 SDH/SONET Interface Protection Feature Description
13.1 Overview of SDH/SONET Interface Protection

Feature Definition
Most of the existing telecommunication networks adopt the time division multiplexing (TDM)
transmission mode. Therefore, the UMG8900 need support the TDM transmission mode.
Large-capacity transmission modes, such as the synchronous digital hierarchy/synchronous

optical network (SDH/SONET) mode, usually require the interface protection function to ensure
the reliability of service transmission.
The UMG8900 supports the synchronous transport module 1 (STM-1) SDH/SONET interface.
You can configure the relevant interface protection function to meet the requirements of
networking reliability. The UMG8900 also supports the asynchronous transfer mode (ATM)
interface. The SDH/SONET protocol is applied at the physical layer of the ATM interface.
Therefore, the ATM interface protection function is the same as the SDH/SONET interface
protection function. Thus, only the SDH/SONET interface protection function is described.
The SDH/SONET interface protection adopts the standard Automatic Protection Switching
(APS) protocol and can be connected to the transmission device that supports standard protocols.
Service Benefits
Table 13-1 Service benefits of SDH/SONET interface protection
SDH/SONET interface This feature enhances This function is intangible to

protection transmission reliability of the users.
network, ensures service
provisioning, and improves
quality of services.
13.2 Availability of SDH/SONET Interface Protection

Required NEs
Table 13-2 Required NEs for SDH/SONET interface protection
Feature Required NE
SDH/SONET interface protection MGW, PSTN switch, and PBX

Version Support
Table 13-3 Versions supporting SDH/SONET interface protection
SDH/SONET interface protection R005C02 and later
13.3 Principle and Flow of SDH/SONET Interface Protection

This section describes the implementation principle and service flow of this feature.
Basic Concepts
The basic concepts of synchronous digital hierarchy (SDH) interface protection are defined as
follows:
l APS is short for automatic protection switch. It means that in the SDH network, when the
working entity is faulty, the service data is automatically switched to the protection entity.
APS is classified into linear protection and ring protection. APS can be implemented on
different layers. The UMG8900 supports only the linear multiplex section protection at
present. The UMG8900 also supports 1+1 single-ended, 1+1 dual-ended, and N:1
protection.
l In the case of 1+1 backup protection mode, the unidirectional mode means that the receiving
end can automatically choose to receive information based on the quality of the line. The
bi-directional mode means that the receiving end exchanges the status information between
nodes by using K-byte according to the APS protocol. In this way, the nodes can be switched
to protect the service information. And during the switchover in this protection mode, the
K-byte information between nodes is always transmitted over the optical fiber of the
protection channel.
l 1:N backup protection mode supports only one working mode, that is, the bi-directional
recoverable mode.
The bi-directional recoverable working mode in the 1:N backup protection also uses the
multiplex section protection protocol. During the switchover, the K-byte information
between the nodes is also transmitted over the optical fiber of the protection channel.
l Single end
The working channel switches to the protection channel only on the side where the optical
fiber is faulty. The channel switchover of the peer device is invisible.
l Dual-end
The two ends of the cable start switchover simultaneously after negotiation. The switchover
can be performed either from the working channel to the protection channel or from the
protection channel to the working channel.
l Recoverable

When Signal Fail (SF), Signal Degrade (SD) or other abnormality disappear, the working
channel recovers, and the services are switched from the protection channel to the working
channel.
l Unrecoverable
When the working channel recovers, services are not switched to the working channel
unless the protection channel is faulty.
Protection Principle
Interface protection uses the linear multiplex section protection mode. The working principles
of 1+1 backup and 1:N backup are described as follows.
CAUTION
For APS 1+1 backup protection mode: the switchover between the protection channel and the
working channel is at the board level, rather than the interface level. Thus, if an interface is
switched to the protection channel from the working channel, it can cause the switchover between
the master and slave boards.
Figure 13-1 shows the 1+1 backup protection mode.
Figure 13-1 1+1 backup protection mode
In 1+1 backup protection mode, each working channel has one private protection channel. The
transmitting end sends signals in both channels. The receiving end decides to receive signals in
the working channel or in the protection channel based on the quality of the signals.
In terms of switchover mode, the 1+1 backup protection mode is classified into unidirectional
unrecoverable mode, unidirectional recoverable mode, bi-directional unrecoverable mode, and
bi-directional recoverable mode.
l Unidirectional mode means that the local end performs the switchover based on the quality
of cables without the prior negotiation with the peer end.
l Bi-directional mode means that either end must negotiate with the other end before
switchover. If the negotiation is successful, both the ends perform switchover at the same
time.

l Recoverable mode refers to the protection mode in which the node during switchover is
released and recovers to the normal state after the working channel becomes normal for a
certain period.
l Unrecoverable mode refers to the protection mode in which the node during switchover
remains in the switchover state even if the working channel becomes normal.
In the case of 1+1 backup protection mode, the unidirectional mode means that the receiving
end can automatically choose to receive information based on the quality of the line. The bi-
directional mode means that the receiving end exchanges the state information between nodes
by using K-byte according to the APS protocol. In this way, the nodes can be switched to protect
the service information. During the switchover in this protection mode, the K-byte information
between the nodes is always transmitted over the optical fiber of the protection channel.
Figure 13-2 shows the 1:N backup protection mode.
Figure 13-2 1:N backup working mode
The 1:N backup protection mode differs from the 1+1 backup protection mode in that N working
channels are protected by a private backup channel in 1:N backup protection mode. When the
system works normally, the working channel transfers the primary information. In case that the
transmission on the working channel is interrupted or the performance of the working channel
is greatly degraded, the transmitting end of the primary information performs switchover and
sends the information on the protection channel. Therefore, the receiving end receives
information through the protection channel. In this way, the protection mechanism is enabled.
The 1:N backup protection mode supports only the bi-directional recoverable working mode.
According to the multiplex section protection protocol, the K-byte information between the
nodes is transmitted over the optical fiber of the protection channel during the switchover.
13.4 Data Configuration of SDH/SONET Interface

Protection

Prerequisite
l The hardware data is correctly configured.
l The MGW control data is correctly configured.
l The SDH/SONET interface data is correctly configured.

Figure 13-3 shows the index mapping of the configuration command parameters.
Figure 13-3 Index mapping of main parameters of SDH/SONET interface protection

Context
NOTE
l If the UMG8900 is configured with APS protection, the interconnected radio network controller (RNC)
or transmission device must also be configured with APS protection.
l If the RNC that is connected to the ATM interface of the UMG8900 does not support APS protection,
you can configure 1+1 APS one-end protection on the UMG8900. In this case, the APS protection
process is not implemented inside the UMG8900, but the 1+1 one-end protection function is realized.
l When the S1L, S1E, UG02S2L, and UG02S2E are applied in the SSM-32 frame, they support interface-
level protective switchover. When a fault occurs on an interface, the switchover of the interface does
not cause the switchover of the entire board. In the UMG8900, interfaces on a pair of master and slave
boards in two adjacent slots can be the backup of each other, with one interface as the master interface
and the other interface as the slave interface. When an interface is faulty, this interface is switched.
Therefore, a slave interface may be located on the master board and a master interface may be located
on the slave board. When the interface of the master board fails, the corresponding interface on the
slave board takes over. The faulty interface on the master board changes to the slave interface and is
displayed to be blue on the device panel of the LMT. Meanwhile, the interface of the slave board
changes to the master interface and is displayed to be green on the device panel.
l To set the protection mode of the SDH/SONET interface to 1+1 APS protection, set Backup Type to
1+1Backup when running ADD BRD to add the S1L/S2L. To set the protection mode of the SDH/
SONET interface to 1:N APS protection, set Backup Type to Load Sharing when running ADD
BRD to add the S1L/S2L.
l If the SDH/SONET interface is configured with 1+1 or 1:N APS protection, the timeslot corresponding
to the protection channel must be set to the internal timeslot.
l In 1+1 APS protection mode, it is recommended that the working channel be configured on the board
in the slot with an even slot number and the protection channel be configured on the board in the slot
with an odd slot number.
Procedure
Step 1 Run ADD PG to add a protection group.
Set Protect type to APS1PLUS1 or APS1VSN. If Protect type is set to APS1PLUS1, you
must also set Recover mode (Not recover or Recover) and Operate mode (Unidirectional or
Bidirectional) according to actual requirements.
Step 2 When Recover mode is set to Recover, run SET WRTIME to configure the recover time length.
Step 3 If the signaling degrade (SD) flag is required, run SET SIGDEFECT to set the SD flag. Set
SD flag to SD enable.
Step 4 Run ADD PGIF to configure the protection group to which the optical interface belongs. Before
adding working channels, add the protection channel of the protection group. The protection
channel number in the protection group is always 0.
Step 5 Run SET PG to enable the protection controller.
----End
Example
//Configure four S1L boards in 1:3 backup mode.
ADD PG: PGID=0, IFT=SDH/SONET, TYPE=APS1VSN, CHNNUM=3;
SET WRTIME: PGID=0, WTIME=6;
SET SIGDEFECT: PGID=0, SDFLAG=SD_ENABLE;
ADD PGIF: FN=2, SN=13, IFN=0, PGID=0, CHN=0;


//Start the protection group protocol controller.

SET PG: PGID=0, CMDT=START_CONTROLLER;
13.5 Protocol and Specification of SDH/SONET Interface

Protection
Table 13-4 Protocols and specifications of SDH/SONET interface protection

SDH/SONET interface protection APS protection protocol G.841

Feature Description 14 StandAlone
14 StandAlone
About This Chapter
protocols and specifications of StandAlone.
14.1 Overview of StandAlone

14.2 Availability of StandAlone
14.3 Principle and Flow of StandAlone
14.4 Data Configuration of StandAlone
14.5 Protocol and Specification of StandAlone

14 StandAlone Feature Description
14.1 Overview of StandAlone

Feature Definition
StandAlone is a disaster tolerance scheme provided by the UMG8900. When the media gateway
controller (MGC) is faulty, or when the communication between the UMG8900 and the MGC
is interrupted, the UMG8900 connects basic calls between the analog users of the user access
module (UAM) or between the users that V5 access network device accesses without the control
of the MGC. This is to superimpose parts of the call control function of the MGC to the media
gateway (MGW). Thus, when a disaster occurs, the network can keep working and the reliability
protection of the MGW is enhanced.
After disconnecting from the MGC, the UMG8900 enables the StandAlone function to maintain
the call control on the basic service of analog users. In this way, the original conversation set up
by the MGC proceeds. When the UMG8900 recovers the connection to the MGC, the
StandAlone function is automatically disabled, and the call control is resumed by the MGC.
Service Benefits
Table 14-1 Service benefits of StandAlone

StandAlone StandAlone is a disaster tolerance The function is invisible to

scheme of the UMG8900. user.
StandAlone provides the
UMG8900 with stronger disaster
tolerance capability, which
improves network reliability,
ensures normal running of
services, and improves service
qualities.

Table 14-2 Function restrictions of StandAlone
StandAlone service l StandAlone supports only the calls between the intra-office analog
users. It does not support the outgoing calls.
l StandAlone supports only the basic call control service. It does not
support the supplementary services such as call forwarding.
l StandAlone function supports only the calls between the users of
the same virtual media gateway (VMGW). It does not support the
inter-VMGW calls.
NOTE
The UGC does not support this feature.
14.2 Availability of StandAlone

Required NEs
Table 14-3 Required NEs for StandAlone
Feature Required NE
UAM StandAlone MGW and UAM analog users
V5 StandAlone MGW and V5 access network users
StandAlone bill MGW and iGWB
Version Support
Table 14-4 Versions supporting StandAlone
UAM StandAlone R005C02 and later
V5 StandAlone R005C02 and later
StandAlone bill R005C02 and later

14.3 Principle and Flow of StandAlone

14.3.1 UAM StandAlone

This section describes the implementation principles and service flow of user access module
(UAM) StandAlone.
14.3.2 V5 StandAlone
This section describes the implementation principles and service flow of V5 StandAlone.
14.3.3 StandAlone Bill
This section describes the implementation principles and service flow of StandAlone bill.
14.3.1 UAM StandAlone

This section describes the implementation principles and service flow of user access module
(UAM) StandAlone.
Functions
The StandAlone feature is an enhanced reliability protection function provided by the
UMG8900. When the external signaling/bearer network are faulty, a loss of signaling connection
between the UMG8900 and the softswitch may occur, leading to the service failure. With the
StandAlone feature, however, the UMG8900 may provide the call connection capability for the
basic service without the intervention of softswitches. When the UMG8900 and softswitch
control device recover to the normal state, StandAlone may exit from the service without
interrupting the call. In this way, StandAlone provides the disaster tolerance capability for the
UMG8900.
The StandAlone feature is applied in the following conditions:
1. This feature allows the user to disable, enable, and query this function.
2. When the gateway exits from the service or the connection to the media gateway controller
(MGC) is interrupted, this feature can automatically take over the MGW. The takeover,
however, depends on whether the users enable this function.
3. After this feature takes over the MGW, the manner of processing the session keeps
unchanged. This indicates that, after the disconnection to MGC, the session established by
softswitch proceeds during the "session release interval after MGC failure" and is not
interfered by the new call. If the MGW exits from the service, the session is released through
service exit.)
4. This feature can automatically exit from the takeover when the MGW recovers the
connection to softswitch. The feature also ensures that the conversation set up by
StandAlone is not interfered.
5. The feature supports only remote subscriber processor (RSP) automatic laser shutdown
(ALS) users.
6. The feature supports only the basic call for RSP ALS users. This feature does not support
the supplementary service or the polarity reversed users.

7. This feature supports only the hairpin mode.

8. This feature takes effect on virtual media gateways (VMGWs).
(1) This feature supports only the call connection for the intra-VMGW RSP users. It does
not support the inter-VMGW calls at present.
(2) StandAlone takes over a VMGW; however, the other VMGWs can still handle the
service under the management of the softswitch.
9. This feature supports the number configuration and query for RSP analog subscriber line
(ASL) users. The length can be up to 16 bits.
10. This feature supports the query configured by digitmap.
11. This feature supports the time length configuration of the timer for no-reply, busy tone, and
howling tone.
Networking Applications
Figure 14-1 shows the user access module (UAM) StandAlone services and the networking
applications.
Figure 14-1 UAM StandAlone networking diagram
System Implementation
When the connection between a VMGW and the media gateway controller (MGC) in the
UMG8900 is interrupted, or when the VMGW exits from the service, the basic call of RSP-ASL

users in the VMGW can proceed normally, provided that the StandAlone function is enabled,
and the users has configured a number identical to the MGC. At this time, the VMGW is
controlled by StandAlone. And the onhook and offhook information about the users is reported
to the StandAlone function entity for handling. The swithover is complete automatically.
If other VMGWs still communicate normally with the MGC, the services of these VMGWs are
not affected by the StandAlone function entity.
The previous conversation set up by the MGC on the VMGW proceeds until timeout. Time-out
time is configured by the users in SET VMGW.
When the connection between the VMGW and the MGC recovers, the MGC can control the
VMGW. To maintain the prior conversations set up by StandAlone, the VMGW rejects the
operations of the MGC on the terminations in the conversations.
14.3.2 V5 StandAlone
This section describes the implementation principles and service flow of V5 StandAlone.
Functions
The V5 StandAlone feature is an enhanced function on the basis of remote subscriber processor
(RSP) plain old telephone service (POTS) StandAlone feature provided by the UMG8900. The
V5 StandAlone feature supports RSP users, and it further supports StandAlone of V5 users. In
this way, StandAlone provides the disaster tolerance capability for the UMG8900.
It supports the enhanced V5 StandAlone functions, including:
1. It supports handling the intra-office V5 user call after the H.248 link to the media gateway
controller (MGC) is disconnected.
2. It supports the calls between V5 and POTS StandAlone users.
3. It supports V5.1 and V5.2 interfaces. The V5.2 interface supports protection group 2.
4. It supports V5 interface maintenance and management, configuration of V5 user data, and
V5 call signaling tracing.
5. It supports the importing of V5 user data and provides the tool that helps import layer 3
addresses and telephone numbers of V5 users from the MGC.
NOTE
l It does not supports V5 StandAlone function of the remote switch module (RSM). After RSM is
disconnected from the host exchange, the V5 users that access through the RSM cannot make a call.
l It does not support V5 integrated services digital network (ISDN) users (PRI/BRI), neither the V5 semi-
permanent nor V5 pre-connection call.
Figure 14-2 shows the V5 StandAlone services and networking applications.

Figure 14-2 V5 StandAlone networking diagram
When the connection between a VMGW and a MGC in the UMG8900 is interrupted, or when
the VMGW exits from the service, the basic call service of RSP-ASL users or V5 users in VMGW
can proceed, provided that the StandAlone function is enabled, and the user has configured a
number identical to the MGC. At this time, the VMGW is controlled by StandAlone. And the
onhook and offhook information about the RSP-ASL users is reported to the RSP StandAlone
function entity for handling. All the V5 protocol information about V5 interface is reported to
the V5 StandAlone function entity for handling. The switchover is complete automatically.
If other VMGWs still communicate normally with the MGC, the services of these VMGWs are
not affected by StandAlone function entity.
When the VMGW recovers connection to the MGC, the MGC may control the VMGW. Due to
the limitation of the V5 protocol (V5 interface needs a restart), the ongoing conversations of V5
users are interrupted.
14.3.3 StandAlone Bill

This section describes the implementation principles and service flow of StandAlone bill.
Functions
In the fixed network, the UMG8900, acting as an AG, can work in StandAlone mode. In this
working mode, intra-office V5 user calls can be implemented inside the UMG8900. The bill
information related to the call made under the control of the UMG8900 is required to be reported
to the billing center. To meet this requirement, the bill reporting feature is added. When the
UMG8900 acts as an AG in StandAlone mode in the fixed network after this feature is added,
bills of V5 and POTS users can be output in the simple format to the iGateway Bill (iGWB).
The unsuccessful calls are also calculated.

The Bill module caches the bills generated by the CMU module into the bill pool of the board
where CMU module is located, then transfers the bills to the bill pool where OMU module is
located by the reliable transfer system, and eventually submits the bills to the iGWB by using
IP bearer through the Slide-Window Protocol (SWP).
Figure 14-3 shows the system networking.
Figure 14-3 System networking diagram
The bill is provided by the call processing service module of the CMU. The bill is written to the
CMU bill pool by using the interface provided by the bill module. Then, the bill is transferred
from CMU bill pool to OMU bill pool by using the reliable transfer system between the CMU
and OMU. At last, UMG8900 and iGWB use the slide-window protocol to report the bill to
iGWB.
CMU module may be distributed on the board which may belong to any of the 4 logical board
types: CMU, VPU, OMU, or MPU. The OMU module, however, can only be distributed on the
OMU.
The bill module can run in the host office with the SSM-256 or SSM-32 frame, or in the SSM-4
frame.
In the host office with the SSM-256 or SSM-32 frame, the OMU entity in the diagram can have
only one pair of OMUs in the OMBs and the OMUs, and one UMG8900 can have only one pair
of OMUs. The CMU entity may exist in the board which may belong to 3 logical board types:

CMU and MPU (after the integration the three boards, the physical board types are MPU and
MPB).
In the SSM-4 frame, the OMU entity exists on the OMD and the CMU entity exists on the VPD.
The bill module is comprised of the bill pool sub-module and bill reporting sub-module. In
addition, it includes the entity that helps implement the function. The bill pool sub-module
receives the bill generated by the service module, and caches it to the bill pool. The bill pool
sub-module on the board where the CMU entity is located transfers the bill to the bill pool where
the OMU entity is located. The bill reporting sub-module sets up and maintains a connection to
the iGWB, and reports the bill in the bill pool on the board where the OMU entity is located to
the iGWB.
l Bill pool sub-module
1. Bill caching
The host office with the SSM-256 or SSM-32 frame supports the storage of 800000
bills that are distributed on three pairs of CMUs. The host exchange of small
specification, however, supports the storage of 500,000 bills. The memory of the bill
pool is allocated dynamically. If the bill pool is configured not to export bills, the
memory of the bill pool is released. Bills are stored in the bill pool in a simple format.
When the bill pool is full, bills are covered cyclically. Bill pool gives an alarm and
counts the lost bills due to the cyclic coverage.
2. Bill transferring
By using compression and decompression, the bills in the bill pool on the board where
the CMU entity is located is transferred periodically to the bill pool on the board where
the OMU entity is located. The reliable transfer system is used to ensure that there is
no loss of the bills during the transfer. To make best use of the bill pool on the board
where the CMU entity is located and on the board where the OMU entity is located,
the bill pool sub-module on the board where the OMU entity is located sends a transfer
control message periodically to the bill pool sub-module on the board where the CMU
entity is located.
3. Providing an interface for interacting with the service module
The service module invokes the interface of the bill module to write the bill to the bill
pool. On the VPU/MPC/CMU, all the corresponding virtual media gateways
(VMGWs) are configured to give a notification to the bill pool sub-module when the
bills are not exported. The bill pool sub-module begins to release the memory of the
bill pool when it receives the notification.
l Bill reporting sub-module
1. Setup and maintenance of the bill reporting connection
When the UMG8900 starts, if the user is configured the information about setting up
the connection, the bill reporting sub-module initiates the Transmission Control
Protocol/Internet Protocol (TCP/IP) connection to the iGWB. After the successful
connection, the sub-module registers the MID of the MGW with the iGWB. The sub-
module sends the handshake message to the iGWB and the bill data periodically. The
sub-module receives the response data from the iGWB and maintains the connection
that is set up. The sub-module also supports the integrated transfer of the bill.
2. Bill reporting
The reporting of bills from the bill pool to the iGWB uses the reliable transfer system
of the Slide-Window Protocol (SWP). The bill module maintains the slide-window

protocol that it follows to communicate with iGWB. The bill module reports the bill
periodically if there are bills in the bill pool.
l Other entities
1. In the bill module, the bills in the bill pool are required to be synchronized on the
master/slave boards. In this way, there is little possibility of losing the bills after the
master/slave switchover. The bill module uses the integrated backup system provided
by the distributed object-oriented programmable real-time architecture (DOPRA) to
enable the bill synchronization on the master/slave boards. It also enables the
synchronization of control information and connection configuration information on
the master/slave boards.
2. In the bill pool, it provides the interface that interacts with the command line module,
receives the command given by the users, performs the appropriate operations, and
returns the relevant information.
14.4 Data Configuration of StandAlone

Prerequisite
l The time division multiplexing (TDM) bearer is correctly configured.
l The V5E1 link is correctly configured.
l The LAPV5 link is correctly configured.
Procedure
Step 1 Run ADD V5TGto add the V5 trunk group.
Step 2 Run ADD V5TKC to add the V5 trunk circuit.
Step 3 Run ADD V5I to add the V5 interface. Set Protect Group Type to P2 (Protect Group 2).
Step 4 Run ADD PHONENO to configure the telephone number table.
Step 5 Run SET CCDIGITMAP to configure the StandAlone dialing plan.
Step 6 Run SET IGWBINFO to configure the connection information with the iGateway Bill (iGWB).
CAUTION
After the UMG8900 is successfully connected to the iGWB, the UMG8900 registers the VMGW
MID of the VMGW with the iGWB. The related authentication information about the VMGW
MID need be added to the GatewayIDs.ini file of the iGWB. The UMG8900 sends an
authentication message of the VMGW MID of the VMGW before sending the bill to the iGWB
at a time. After the authentication succeeds, the iGWB can normally receive the correct bill from
the UMG8900.
Step 7 Run SET CCSWT to enable the StandAlone option.
----End

Example
l For V5 users
//Configure the V5 trunk data.
ADD V5TG TKGNO=0, CMUBN=30, VMGWID=0, TKGNAME="V5 StandAlone";
ADD V5TKC: TKGNO=0, L3SE1ID=0, L2SE1ID=0, ANSE1ID=0, STID=0;
//Configure the V5 interface.

ADD V5I: INFNO=0, TKGNO=0, INFID=0, MAINLNK=0, MLNKID=0, PROTTYP=P2,
VICELNK=2, PSTNLNK=4, PSTNID=1, P2S1ID=1, P2S2ID=3, VARNO=0;
//Configure the telephone number table.

ADD PHONENO: PHONETYPE=V5, V5SPHNNO="6540080", V5EPHNNO="6540083", IID=0,
SL3ADDR=0;
//Configure the StandAlone dialing plan.

SET CCDIGITMAP: DIGITMAP="65400xx";
//Configure the connection information with the iGWB.

SET IGWBINFO: SRCIP="10.0.0.1", SRCPORT=1234, DSTIP ="10.1.1.1", DSTPORT
=1234;
CAUTION
The iGWB can normally receive bills from the UMG8900 only when the related
authentication information about the VMGW MID of the VMGW is added to the
GatewayIDs.ini file of the iGWB.
//If VMGW 0 whose ID is 10.1.1.1:3333 needs to send bills to the iGWB, you need
to type the following
10.1.1.1:3333 262
in the GatewayIDs.ini file, where the number 262 is the module number without
any practical meaning. The module number should range from 256 to 511.
//Enable the StandAlone option.

SET CCSWT: VMGWID=0, USERTYPE=ESL-0&V5-1, BILL=YES;
l UA users
//Configure the phone number table.
ADD PHONENO: PHONETYPE=ESL, MODE=BYTID, SPHNNO="6540070", EPHNNO="6540075",
STID=64;
//Configure the StandAlone dialing plan.

SET CCDIGITMAP: DIGITMAP="65400xx";
//Configure the connection information with the iGWB.

SET IGWBINFO: SRCIP="10.0.0.1", SRCPORT=1234, DSTIP ="10.1.1.1", DSTPORT
=1234;
CAUTION
The iGWB can normally receive bills from the UMG8900 only when the related
authentication information about the VMGW MID of the VMGW is added to the
GatewayIDs.ini file of the iGWB.

//If VMGW 0 whose ID is 10.1.1.1:3333 needs to send bills to the iGWB, you need
to type the following
10.1.1.1:3333 262
in the GatewayIDs.ini file, where the number 262 is the module number without
any practical meaning. The module number should range from 256 to 511.
//Enable the StandAlone option.

SET CCSWT: VMGWID=0, USERTYPE=ESL-1&V5-0, BILL=YES;
14.5 Protocol and Specification of StandAlone

Table 14-5 Protocols and specifications of StandAlone

UAM StandAlone Internal protocols of Huawei
V5 StandAlone YDTV51 V20, YDTV52 V20

ITU-T G.964/G.965

Feature Description 15 IP QoS
15 IP QoS
About This Chapter
This chapter describes the definition, required network elements (NEs), function restrictions,
specifications of IP QoS.
15.1 Overview of IP QoS

This section describes the definition, benefits for carriers and users, and function restrictions of
type of service/differentiated services code point (ToS/DSCP) and virtual local area network
(VLAN) priority.
15.2 Availability of IP QoS
15.3 Principle and Flow of IP QoS
15.4 Data Configuration of IP QoS
15.5 Protocol and Specification of IP QoS

15 IP QoS Feature Description
15.1 Overview of IP QoS

This section describes the definition, benefits for carriers and users, and function restrictions of
type of service/differentiated services code point (ToS/DSCP) and virtual local area network
(VLAN) priority.
Feature Definition
The UMG8900 supports the differentiated service (DiffServ) technology, which can specify
different attributes (DSCP/ToS service flag) for each data packet based on the behavior
characteristics of data stream and the service requirements. According to the different priorities
of the data packet, the network processor (NP) and core network router of the virtual processing
unit/high-speed routing board (VPU/HRB) carry out different policies to ensure that the high-
quality service matches the service streams with a high priority. The UMG8900 supports the
Institute of Electrical and Electronics Engineers (IEEE) 802.1P and IEEE 802.1Q (VLAN)
protocols, which set priorities for different layer 2 services. By setting priorities for each VLAN,
the UMG8900 can isolate the OMC, signaling, and voice over IP (VoIP) streams. The LAN
Switch on the bearer network adopts proper QoS policies to various services according to their
respective packet priorities. Thus, the packets of which the VLAN IDs are marked with a higher
priority are forwarded prior to other packets. In addition, a dedicated queue can be used for voice
packets, and voice packets can be set with the absolute priority to prevent the burst packets from
preempting network resources.
Service Benefits
Table 15-1 Service benefits of IP QoS
ToS/DSCP The service quality of the VoIP It ensures that the high quality
network and the customer service matches the data stream
VLAN priority satisfaction are improved. with high priority.
Table 15-2 Function restrictions of IP QoS
ToS/DSCP The IP QoS supported by the UMG8900 is an inherent feature. The

QoS, however, is an end-to-end assessment, therefore, it cannot
VLAN priority reflect the QoS of the entire network.
15.2 Availability of IP QoS


Required NEs
To implement the IP-based quality of service (QoS), the user must configure the QoS policy for
devices on the entire network.
Table 15-3 Required NEs for IP QoS

Feature Required NE
ToS DSCP IP QoS requires the support of data bearer

network device.
VLAN priority
Version Support
Table 15-4 Versions supporting IP QoS

ToS DSCP R005C02 and later
VLAN priority
15.3 Principle and Flow of IP QoS

15.3.1 ToS DSCP
This section describes the implementation principles and service flow of ToS DSCP.
15.3.2 VLAN Priority
This section describes the implementation principles and service flow of virtual local area
network (VLAN) priority.
15.3.1 ToS DSCP

This section describes the implementation principles and service flow of ToS DSCP.
IP TOS and IP DSCP are two protocols of describing the QoS of IP packets on the network layer.
Their label fields are defined in one byte of the IP header in the multiplexing mode. In other
words, only one protocol is valid at a certain time.
Figure 15-1 and Figure 15-2 show the definitions of IP TOS field and DSCP field.
Figure 15-1 Definition of the IP TOS field

Figure 15-2 Definition of the IP DSCP field
In the IP TOS field, the middle 4-bit TOS information is valid, the MBZ bit is set to 0, and
PRECEDENCE is ignored. The four bits of the TOS field represent the minimum delay,
maximum throughput, highest reliability, and minimum cost respectively. Among the four bits,
only one bit can be set. If all the four bits are 0, it indicates a common service.
The 6-bit DS field is defined as the code point, and the router receiving packets processes the
packets based on the 6-bit DS field. The 2-bit CU field (currently unused) is omitted.
The UMG8900 can use the TOS field and the DSCP field of the IP header as the QoS labels.
For example, the signaling and VoIP voice/video share the physical network, based on the
features of the two services, the UMG8900 identifies DSCP in the IP header of the VoIP voice
data as EF, and that of the signaling data as AF. To prevent VoIP data from preempting the
bandwidth of the signaling data, the bandwidth of the EF stream must be limited on the routers
to reserve enough bandwidth for AF. In this way, both the low delay forwarding of voice/video
service and the smooth transmission of data streams of the signaling network are ensured.
15.3.2 VLAN Priority

This section describes the implementation principles and service flow of virtual local area
network (VLAN) priority.
When sending data packets, each host that supports the 802.1Q protocol inserts a 4-byte 802.1Q
frame header between the source address of the Ethernet frame header and the Ethernet length
or type field. This 4-byte 802.1Q tag header contains a 2-byte tag protocol identifier (TPID)
whose value is 0x8100, and 2-byte tag control information (TCI). TPID, a new type defined by
IEEE, indicates that it is a packet with the 802.1Q tag. Figure 15-3 displays the content of 802.1Q
tag header.
Figure 15-3 802.1Q tag header
VLAN Identifier (VLAN ID): It is a 12-bit field, indicating the IDs of the VLANs. Totally 4096
IDs are available. The data packet sent by each host that supports the 802.1Q protocol contains
this field, indicating the VLAN that the data packet belongs to.

Canonical format indicator (CFI): It is used in the frame format when the bus Ethernet exchanges
data with the FDD and token ring networks. The bit can be neglected.
Priority: It occupies three bits and indicates the priority of a frame. There are eight priorities.
The priority determines which data packet must be sent first when the switch is congested. The
UMG8900 sets up calls based on signaling exchange. When the traffic approaches the upper
limit of the processing capability of the UMG8900, the UMG8900 automatically carries out
overload call restriction. Thus, when services are normal, traffic burst and network congestion
rarely occur. The UMG8900 supports the VLAN priorities by adding a proper VLAN priority
field to outgoing IP packets of different types, and therefore, the packets are properly processed
by the switch on the transmission path.
The UMG8900 R005 version sets the VLAN priority for IP packets as follows: When the VLAN
of an interface is configured, the VLAN priorities corresponding to the three types of packets,
that is, signaling, network management, and service packets, that are sent from this interface are
set. Then, IP packets are set with the corresponding priorities and then forwarded.
15.4 Data Configuration of IP QoS

15.4.1 Configuring the DiffServ Function

15.4.2 Configuring the VLAN Priority Function
15.4.1 Configuring the DiffServ Function

Procedure
Step 1 Run SET IPQOS to configure Diff Serv Code Point (DSCP)/type of service (ToS) for the various
types of data. The priority order is video service -> voice service -> control message -> others.
The priority of the internal packets does not need to be configured. Use the default value.
----End
15.4.2 Configuring the VLAN Priority Function

Procedure
Step 1 Run ADD IFVLAN to add the designated Ethernet interface to VLAN, and specify the priority
for different packets.
Step 2 Run ADD IPADDR to configure VLAN ID for the IP address of the specified interface.
----End

15.5 Protocol and Specification of IP QoS

Table 15-5 Protocols and specifications of IP QoS

ToS/DSCP RFC 1349
VLAN priority IEEE802.1Q

Feature Description 16 RTP Multiplexing
16 RTP Multiplexing
About This Chapter
This chapter provides the definition and describes the application scenarios, required network
elements (NEs), function restrictions, implementation principles, and data configuration of RTP
multiplexing.
16.1 Overview of RTP Multiplexing

This section provides the definition and describes service benefits and function restrictions of
this feature.
16.2 Availability of RTP Multiplexing
16.3 Configuring RTP Multiplexing
This section describes the definition, functions, negotiation process, application scenarios, data
planning, configuration steps, and sample tasks of Real-time Transport Protocol (RTP)
multiplexing.
16.4 Protocol and Specification of RTP Multiplexing

16 RTP Multiplexing Feature Description
16.1 Overview of RTP Multiplexing

this feature.
Feature Definition
The Real-time Transport Protocol (RTP) multiplexing technology, defined by the 3rd Generation
Partner Project (3GPP), is applied to the Nb interface. It is an algorithm with which the bandwidth
can be saved and the network utilization can be improved. When more than three packets are
multiplexed, you can use the RTP multiplexing technology to improve bandwidth usage. In this
case, a maximum of around 60% bandwidth can be saved. When the Nb interface is based on
the Internet Protocol (IP), the RTP multiplexing technology can be used to improve the
bandwidth usage. With the RTP multiplexing technology, RTP headers and RTP packets can be
multiplexed.
RTP multiplexing contains compressed RTP multiplexing and non-compressed RTP

multiplexing.
l Non-compressed RTP multiplexing: The RTP packets with the same source IP address and
the same destination IP address are multiplexed as one packet. The IP header and the User
Datagram Protocol (UDP) header are shared by multiple packets. Meanwhile, a multiplex
(MUX) header is added to each RTP packet.
l Compressed RTP multiplexing: After the packets are multiplexed, the RTP header is
compressed. In the RTP header, the fields that are not changed during calls are compressed
but the Sequence Number field and the Timestamp field are not compressed.
In the next generation network (NGN), the MGWs use YY interfaces to implement RTP
multiplexing. Figure 16-1 shows the application scenarios of RTP multiplexing.
Figure 16-1 Application scenarios of RTP multiplexing
MGW: media gateway MGC: media gateway controller

HLR: home location register
Service Benefits
Table 16-1 Service benefits of RTP multiplexing
RTP multiplexing Packets can be multiplexed, None

and thus the bandwidth is
saved effectively.
Table 16-2 Function restrictions of RTP multiplexing
RTP multiplexing l The RTP multiplexing feature is applicable to the HRD

only. Each HRD supports up to 2048 RTP multiplexing
queues.
l The RTP multiplexing technology cannot be applied if the
network address translation (NAT) device is deployed in
the network.
l The packets of the multi-frame calls and the calls between
the virtual media gateways (VMGWs) cannot be
multiplexed.
l The packets of the RFC2833 and 3G data services cannot
be multiplexed.
16.2 Availability of RTP Multiplexing

Required NEs
Table 16-3 Required NEs for RTP multiplexing
Feature Required NE
RTP multiplexing MGW

Table 16-4 Version supporting RTP multiplexing

Feature Version
RTP multiplexing V200R008C01
16.3 Configuring RTP Multiplexing

This section describes the definition, functions, negotiation process, application scenarios, data
planning, configuration steps, and sample tasks of Real-time Transport Protocol (RTP)
multiplexing.
Principle of RTP Multiplexing

RTP multiplexing refers to encapsulating multiple RTP packets between a pair of IP addresses
as one IP packet. Thus, the valid payload of the network is improved. RTP multiplexing can be
classified into compressed RTP multiplexing and non-compressed RTP multiplexing.
Compressed RTP multiplexing packets and non-compressed RTP multiplexing packets are
different in format.
1. Non-compressed RTP multiplexing
Figure 16-2 shows the process of multiplexing non-compressed RTP packets.
Figure 16-2 Process of multiplexing non-compressed RTP packets
The RTP packets with the same source IP address and the same destination IP address are
multiplexed as one packet. The IP header and the User Datagram Protocol (UDP) header
are shared by multiple packets. Meanwhile, a multiplex (MUX) header is added to each
RTP packet.
Figure 16-3 shows the structure of the RTP MUX header.

Figure 16-3 Structure of the RTP MUX header
The filed T (one bit) in the MUX header specifies whether the packet is a compressed
multiplexing packet or a non-compressed multiplexing packet. If the field T is 0, it indicates
that the packet next to the MUX header is a non-compressed multiplexing packet. If the
field is 1, it indicates that the packet next to the MUX header is a compressed multiplexing
packet.
The field R (one bit) in the MUX header is reserved. It must be set to 0 when the multiplexing
packet is transmitted so that this field is not checked when the multiplexing packet is
received. The load length of the multiplexing packet specifies the length of the load next
to the MUX header excluding the MUX header.
l A complete RTP packet header, defined by RFC1889, is encapsulated next to the MUX
header in the non-compressed RTP multiplexing packet, as shown in Figure 16-4.
l A compressed RTP packet header is encapsulated next to the MUX header in the
compressed multiplexing packet. The compressed RTP packet header contains only a
sequence number of one byte and a time stamp of two bytes. Thus, the packet can be
compressed and bandwidth can be saved. Figure 16-7 shows the number of compressed
RTP multiplexing packets. The yellow part shows the compressed RTP packet header.
The length of each RTP packet header is 12 bytes. Figure 16-4 shows the structure of the
RTP packet header.

Figure 16-4 Structure of the RTP packet header
Table 16-5 provides the meanings of the fields in the RTP packet header.
Table 16-5 Meanings of the fields in the RTP packet header

Field Meaning Description
Version Version number See RFC3550. The length is 2 bits. It indicates the RTP
(V) version. The current RTP version is 2.0.
Padding Padding flag See RFC3550. The length is 1 bit. If the value is 1, it
(P) indicates that one or multiple padding fields are
suffixed to the packet.
Extension Extension flag See RFC3550. The length is 1 bit. If the value is 1, it
(X) indicates that an extension packet header is suffixed to
the fixed packet header.
CSRC Number of CSRC See RFC3550. The length is 4 bits. It indicates the
count distinguishers number of CSRC distinguishers suffixed to the fixed
(CC) packet header.
Marker Marking bit See RFC3550. The length is 1 bit. If the M bit is set, it
bit (M) indicates that certain important items, such as the
frame border, are marked in the packet.
Payload Payload type See RFC3550. The length is 7 bits. It indicates the type
type (PT) of the valid payload in the RTP packet.
Sequence Sequence number See RFC3550. The length is 16 bits. The start value of
number the sequence number is random. The sequence number
is increased by one each time an RTP data packet is
transmitted. Based on the sequence number, the
receiving end detects packet loss and reassembles data
packets.

Timestam Time stamp See RFC3550. The length is 32 bits. It indicates the
p sampling time of the first bit in the RTP data packet.
The sampling time precision must meet the
synchronization requirement to facilitate the
synchronization and jitter calculation. The start value
of the time stamp is random. The time stamp value
ascends with the data size.
SSRC SSRC identifier See RFC3550. The length is 32 bits. It is used to

identify the sender of the RTP packet. It is generated
at random. No SSRC identifier is shared by any two
synchronization sources during an RTP session.
CSRC list CSRC identifier See RFC3550. It is an array of 0 to 15 CSRC identifiers

list identifying the contributing sources for the payload
contained in this packet. Each CSRC identifier has 32
bits. The number of CSRC identifiers is given in the
CC field. Up to 15 contributing sources can be
identified. The CSRC identifiers are inserted by
mixers, using the SSRC identifiers of contributing
sources.
Figure 16-5 shows the format of the non-compressed RTP multiplexing packet.

Figure 16-5 Format of the non-compressed RTP multiplexing packet
The source and destination port numbers in the UDP header is negotiated through the Real-
time Transport Control Protocol (RTCP) packets. The fields marked in yellow comprise a
MUX header, which occupies five bytes. The T bit indicates whether the packet is a non-
compressed RTP multiplexing packet or a compressed RTP multiplexing packet. The MUX
ID and source ID are the remainder obtained by dividing the port number in the original
RTP packet by two. The length is the RTP packet length. The R bit is reserved at present.
Table 16-6 provides the meanings of the fields in the RTP multiplexing packet header.

Table 16-6 Meanings of the fields in the RTP multiplexing packet header
T RTP See RFC3550. The length is 1 bit.

multiplexin l 0: Non-compressed RTP multiplexing
g mode
l 1: Compressed RTP multiplexing
Mux ID Destination See RFC3550. The length is 15 bits. The value is obtained
ID of the by dividing the destination port number of the RTP packet
user plane by two.
connection
Length Length of See RFC3550. The length is 8 bits. It equals the sum of the
Indicator the RTP header length and payload length of the RTP multiplexing
multiplexin packet in bytes. The maximum value is 255.
g packet
R Reserved See RFC3550. The length is 1 bit. The value is permanently

0.
Source Source ID of See RFC3550. The length is 15 bits. The value is obtained
ID the user by dividing the source port number of the RTP packet by
plane two.
connection
2. Compressed RTP multiplexing

Table 16-6 shows the process of multiplexing compressed RTP packets.
Figure 16-6 Process of multiplexing compressed RTP packets
The RTP packets with the same source IP address and the same destination IP address are
multiplexed as one packet. The IP header and the UDP header are shared by multiple
packets. Meanwhile, a MUX header is added to each RTP packet. The field sequence
number (SN) and time stamp (TS) are not changed when the RTP packet header is further
compressed. Other unchanged fields are compressed.
Figure 16-7 shows the format of the compressed RTP multiplexing packet.

Figure 16-7 Format of the compressed RTP multiplexing packet

Figure 16-8 Format of the compressed RTP multiplexing packet in the SIP networking
Compared with the RTP packet in the BICC networking, the M and PT byte is added to the
packet header after the compression.
Table 16-7 lists the meanings of the fields in the compressed RTP multiplexing packet
header.

Table 16-7 Meanings of the fields in the compressed RTP multiplexing packet header
Item Meaning Description
Sequence Sequence See RFC3550. The length is 8 bits. The start value
number number of the sequence number is random. The sequence
number is increased by one each time an RTP data
packet is transmitted. Based on the sequence
number, the receiving end detects packet loss and
reassembles data packets.
Timestamp Time stamp See RFC3550. The length is 16 bits. It indicates

the sampling time of the first bit in the RTP data
packet. The sampling time precision must meet
the synchronization requirement to facilitate the
synchronization and jitter calculation. The start
value of the time stamp is random. The time stamp
value ascends with the data size.
M Marking bit See RFC3550. The length is 1 bit. If the M bit is

set, it indicates that certain important items, such
as the frame border, are marked in the packet.
PT Payload type See RFC3550. The length is 7 bits. It indicates the

type of the valid payload in the RTP packet.
Process of Negotiating the RTP Multiplexing

Packet multiplexing negotiation is implemented through the RTCP Address Resolution Protocol
(APP) packets. The receiving state, transmitting capability, and number of the port for receiving
the RTP multiplexing packets must be proclaimed in the APP packets. The receiving states are
non-multiplexing, non-compressed multiplexing, and compressed multiplexing. The
transmitting capabilities are non-multiplexing, non-compressed multiplexing, and compressed
multiplexing. Assume that MGW 1 and MGW 2 support RTP multiplexing and compression
technologies and that the RTP multiplexing function is enabled on MGW 1 and MGW 2. Figure
16-9 shows the negotiation and packet exchange process.

Figure 16-9 RTP multiplexing process
MGW: media gateway
1. A call is set up, and RTP packets are exchanged between the two media gateways (MGWs).
The RTP multiplexing process is not involved in this stage.
2. MGW 1 sends the multiplexing and compression information to MGW 2 through the RTCP
APP packet. Then, MGW 2 sends the multiplexing and compression information to MGW
1 through the RTCP APP packet.
3. After receiving the RTCP APP packet from MGW 2, MGW 1 immediately sends the
multiplexing packet to MGW 2. After receiving the multiplexing packet from MGW 1,
MGW 2 immediately sends the multiplexing packet to MGW 1.
The MGW cannot process the fragmented voice packets. Therefore, voice packets to be
multiplexed cannot be fragmented. The voice packets to be multiplexed will be labeled to
indicate that fragmentation is not allowed. The MGW does not detect the path MTU (PMTU)
initiatively. Instead, it updates the PMTU passively. When a flood of the Internet Control
Message Protocol (ICMP) oversize packets are received, the length of multiplexed IP packet is
adjusted if the RTP multiplexing stream can be found based on the source IP address, destination
IP address, and type of service (ToS).

For details on the application scenarios of RTP multiplexing, see Overview of RTP
Multiplexing.
Bandwidth Calculation
After the packets are multiplexed, the bandwidth is saved effectively. In the following formula,
FP indicates the size of the RTP payload, MUX indicates the size of a MUX header, and n is the
number of multiplexed RTP packets. The value of n is related to the maximum transmission unit
(MTU) of the interface. According to the packet format specified by the RTP multiplexing
specification, the MUX header contains five bytes. Gain (1 - (new bandwidth/original
bandwidth)) can be obtained according to the following formula:
Gain = 1 - [L2Head + IP + UDP + n (MUX + RTP + FP)]/n (L2Head + IP + UDP + RTP + FP)
Here, IP + UDP + n (MUX + RTP + FP) < MTU
The preceding formula is applicable to the cases when the compressed RTP multiplexing
function is not enabled. If the compressed RTP multiplexing is enabled, the following formula
is used to calculate the gain:
Gain = 1 - [L2Head + IP + UDP + n (MUX + 3 + FP)]/n (L2Head + IP + UDP + RTP + FP)
Here, IP + UDP + n (MUX + RTP + FP) < MTU
The formula shows that the bigger the n is, the more the bandwidth is saved.
For example, when the AMR codec is adopted, the packet payload is 35 bytes. For the Ethernet,
the maximum value of MTU is 1500. Therefore, up to 33 packets can be multiplexed as one
packet theoretically. The more the packets are multiplexed, the higher the bandwidth usage is.
When 33 packets are multiplexed, 60% bandwidth is saved.
Figure 16-10 Bandwidth usage of the RTP multiplexing
Data Planning
l Table 16-8 lists the parameter output to this step, and you need to fill in the parameter
values according to the output parameters of the input source.

Table 16-8 Input parameters

Parameter Parameter Value Input Source
Name
Mux port <Mux port> Configuring MGW data
Negotiation <Negotiation times> Configuring MGW data

times
Is delay send <Is delay send negotiation Configuring MGW data

negotiation in in compression mode>
compression
mode
l Table 16-9 lists the data needed in this step. The interconnected device column in the table
indicates whether the parameter needs to negotiate with the interconnected parameter. If
not, "-" is filled in.

Parameter Name UMG8900
No. of the multiplex port <Mux port>
Number of negotiation times <Negotiation times>
Whether a negotiation message is sent in <Is delay send negotiation in compression

delay in compression mode mode>
Procedure
Step 1 Run MOD IPIF to set rtp mux capability to compression.
MOD IPIF: IFT=GE, BT=HRB, BN=0, IFN=0, RTPMUX=COMP;
NOTE
rtp mux capability of the UMG8900 must be set to the same value as rtp mux capability of the peer device.
Otherwise, the packets are transmitted and received according to the configuration of the low RTP multiplexing
capability after the RTP multiplexing is negotiated.
The bandwidth usage lowers with the RTP multiplexing capability in descending order, that is, compressed RTP
multiplexing -> non-compressed RTP multiplexing -> no RTP multiplexing.
Step 2 Run SET RTPMUX to set the RTP multiplexing parameters.

SET RTPMUX: MUXPORT=<Mux port>, NEGNUM=<Negotiation times>,
ISDELAY=<Is delay send negotiation in compression mode>;

NOTE
1. The recommended value for Mux port is 1024. Mux port is unique in the MGW and must be an even
number. Mux port can be used only for multiplexing. Ensure that Mux port does not conflict with port
numbers for the links such as the H.248 links, semi-permanent connections, signaling agents of the HRD of
the MGW.
The multiplexing port numbers of the interconnected device and the MGW can be different.
2. Negotiation times of the MGW must be the same as Negotiation times of the interconnected device.
3. Is delay send negotiation in compression mode of the MGW must be the same as Is delay send negotiation
in compression mode of the interconnected device.
----End
Example
Example script
//Run MOD IPIF to configure the RTP multiplexing capability for the GE interface of
the HRD. Set Interface type to giga ethernet interface, Board type to HRB, Board
No. to 0, Interface No. to 0, and rtp mux capability to compression.
MOD IPIF: IFT=GE, BT=HRB, BN=0, IFN=0, RTPMUX=COMP;
//Run SET RTPMUX to set RTP multiplexing parameters, that is, set Mux port to
1028, Negotiation times to 3, and Is delay send negotiation in compression mode to
YES.
SET RTPMUX: MUXPORT=1028, NEGNUM=3, ISDELAY=YES;
16.4 Protocol and Specification of RTP Multiplexing

Table 16-10 Protocols and specifications of RTP multiplexing

RTP multiplexing 3GPP TS 29.414 V6.0.0

Real-time Transport Control Protocol

Feature Description 17 IVCP
17 IVCP
About This Chapter
restrictions, data configuration, and compliance protocols and specifications of IP voice
compressor plus (IVCP).
17.1 Overview of IVCP

17.2 Availability of IVCP
17.3 Configuring IVCP on the IP over E1 Interface
This section describes how to configure the IP over E1 interface of IP voice compressor plus
(IVCP).
17.4 Protocol and Specification of IVCP

17 IVCP Feature Description
17.1 Overview of IVCP

Feature Definition
The IP voice compressor plus (IVCP) function is applicable to IP over E1 networking where the
synchronous digital hierarchy (SDH) transmission network provides voice over IP (VoIP)
services. The UMG8900 adopts the IVCP technology to improve bandwidth usage and reduce
operation expenditure (OEPX).
In some areas such as the African and South American countries, some carriers lease E1 links
for data transmission because of insufficient transmission resources. To save transmission
resources and reduce OPEX, the carriers often deploy the digital circuit multiplication equipment
(DCME) at the two ends of the leased links. The DCME at one end compresses the packets
before sending them and the DCME at the other end decompresses the packets after receiving
them.
NOTE
The DCME enables some 64-kbit/s pulse code modulation (PCM) streams to be transmitted along fewer
transmission channels.
The DCMEs are connected in back-to-back mode, that is, the DCME must be deployed at each
end of a link, as shown in Figure 17-1.
Figure 17-1 DCME networking

The time division multiplexing (TDM) data between two UMG8900s may be transmitted
through the SDH transmission network, microwaves, or satellite links. The data is compressed
before being transmitted and then decompressed after being received.
The traditional DCME can compress only the TDM data and cannot compress the IP packets
over E1 links. To compress the IP packets effectively and reduce the bandwidth occupied by the
VoIP packets, the UMG8900 adopts the IVCP technology that provides similar compression
capability of dedicated DCME. The IVCP technology can save bandwidths between any
UMG8900s for carriers.
Service Benefits
Table 17-1 Service benefits of IVCP
IVCP The IVCP technology Not involved

improves bandwidth usage
and reduces OPEX.
Table 17-2 Function restrictions of IVCP
IVCP The data must be transmitted by one UMG8900 and then

received by another UMG8900.
NOTE
The UGC does not support this feature.
17.2 Availability of IVCP

Required NEs for IVCP
Table 17-3 Required NEs for IVCP
Feature Required NE
IVCP MGW

Version Support
Table 17-4 Versions supporting IVCP
IVCP V200R008C01 and later
17.3 Configuring IVCP on the IP over E1 Interface

This section describes how to configure the IP over E1 interface of IP voice compressor plus
(IVCP).
Prerequisite
l The hardware data is configured correctly.
l The media gateway (MGW) control data is configured correctly.
IVCP Networking
Figure 17-2 shows the IVCP networking.
Figure 17-2 IVCP networking
The UMG8900s interwork with each other through IP over E1 interfaces. In the IP over E1
networking, a local UMG8900 directly connects to the remote UMG8900 through the
synchronous digital hierarchy (SDH) transmission network.
IVCP
The UMG8900 adopts a private algorithm. When compressing the Real-time Transport Protocol
(RTP) packet headers, the UMG8900 multiplexes multiple RTP packets as one RTP packet.
Then, multiple calls can share one RTP packet header, which reduces the cost of RTP packet
headers and improves bandwidth usage. Table 17-5 lists the compression ratios of different
codecs when the voice activity detection (VAD) factor is 0.55 (Compression ratio = 64 kbit/s/
Rate of the compressed packet).

Table 17-5 Compression ratios of different codecs for IVCP
Codec Type Compression Ratio
G.711 1
G.729 11

Figure 17-3 shows the index mapping of the configuration command parameters when the
UMG8900 supports the IVCP function.
Figure 17-3 Index mapping of the configuration command parameters when the UMG8900
supports the IVCP function
The data must be transmitted by one UMG8900 and then received by another UMG8900.
Data Planning
l Table 17-6 lists the parameter output to this step, and you need to fill in the parameter
values according to the output parameters of the input source.

Table 17-6 Input parameters
Parameter Parameter Value Input Source

Name
Board type <Board type> Configuring Frames and Boards
Board No. <Board No.> Configuring Frames and Boards
Virtual media <Virtual media gateway id> Configuring MGW data

gateway ID
Start TID <Start TID> Configuring the TDM Timeslot
End TID <End TID> Configuring the TDM Timeslot
l Table 17-7 lists the data needed in this step. The interconnected device column in the table
indicates whether the parameter needs to negotiate with the interconnected parameter. If
not, "-" is filled in.
Parameter Name UMG8900
TDM port No. <TDM port No.>
Internal port No. of the IOE <IOE internal TDM port No.>
Start TDM timeslot <Start timeslot>
End TDM timeslot <End timeslot>
Serial interface No. <Serial Interface No.>
Interface No. <Interface No.>
VT interface No. <VT Interface No.>
Bear bandwidth(Kbps) <bear bandwidth(Kbps)>
Interface IP address <Interface IP address>
Interface IP address mask <Interface IP address mask>
Procedure
Step 1 Run ADD TDMIU to add the time division multiplexing (TDM) timeslot on the TDM interface
board and set Relay type to Inside.
ADD TDMIU: BT=<Board type>_1, BN=<Board No.>_1, TIDFV=<Start TID>,

TIDLV=<End TID>, VMGWID=<Virtual media gateway id>, HOSTID=<Board No.>_2,
RT=INSIDE;
Step 2 Run ADD BIND to bind the internal TDM port on the IOE board and the physical TDM port
on the TDM interface board.

ADD BIND: TDMBT=<Board type>_1, TDMBN=<Board No.>_1, TDMPORT=<TDM port

No.>, IOEBN=<Board No.>, IOEPORT=<IOE internal TDM port No.>;
Step 3 Run ADD CHANNEL to bind the timeslots of the internal TDM port on the IOE board to form
a Serial interface, which is an IP interface.
ADD CHANNEL: BN=<Board No.>_3, PORT=<IOE internal TDM port No.>,
STARTTS=<Start timeslot>, ENDTS=<End timeslot>, IFN=<Serial Interface No.>;
Step 4 When multiple Serial interfaces support Multilink PPP (MP) binding, the VT interface comes
into being. In this case, you need to run MOD IPIF to add the Serial interface to the VT interface.
If MP binding is not supported, go to Step 5. Set Interface type to SRL, Board type to HRB,
and MP enable to YES.
MOD IPIF: IFT=SRL, BT=HRB, BN=<Board No.>_3, IFN=<Interface No.>, IFMP=YES,
VT=<VT Interface No.>;
Step 5 Run MOD IPIF to modify the configurations of the IP interface. That is, set Interface type to
SRL or VT, Board type to HRB, and Compress enable to IP Voice Compressor Plus.
MOD IPIF: IFT=VT, BT=HRB, BN=<Board No.>_3, IFN=<Interface No.>,
BEARBW=<bear bandwidth(Kbps)>, COMPRESS=iVCP;
NOTE
After modifying Compress enable, you need to run MOD IPIF to set Interface enable to disable, and
then set Interface enable to enable. Thus, the settings can take effect.
----End
Example
Networking diagram
Figure 17-4 shows the IVCP networking.
Figure 17-4 IVCP networking
//Add TDM timeslots to ports 0 and 1 on E32 board 0 and ports 0 and 1 on E32 board
1.
ADD TDMIU: BT=E32, BN=0, TIDFV=0, TIDLV=63, VMGWID=0, RT=INSIDE;
ADD TDMIU: BT=E32, BN=1, TIDFV=1024, TIDLV=1087, VMGWID=0, RT=INSIDE;
//Bind ports 0 and 1 on E32 board 0 and ports 0 and 1 on E32 board 1 to the four
internal TDM ports on IOE board 0 respectively.
ADD BIND: TDMBT=E32, TDMBN=0, TDMPORT=0, IOEBN=0, IOEPORT=0, DESP="Binding TDM
Port1";
Port2";
Port3";

Port4";
//Bind TDM timeslots of each TDM port. Each Serial interface has 31 timeslots.
ADD CHANNEL: BN=0, PORT=0, STARTTS=1, ENDTS=31, IFN=0;
//Bind the Serial interfaces to the VT interfaces.

MOD IPIF: IFT=SRL, BT=HRB, BN=0, IFN=0, DESP="VT0-0", IFMP=YES, VT=0;
//Configure bearer bandwidths of the VT interfaces.

MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=0, DESP="VT0", BEARBW=3968, COMPRESS=iVCP,
RPTROUTE=YES;
MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=1, DESP="VT1", BEARBW=3968, COMPRESS=iVCP,
RPTROUTE=YES;
NOTE
When configuring the bearer bandwidth, ensure that the maximum bearer bandwidth of a channel is 64
kbit/s. In this example, one VT interface has two Serial interfaces, and one Serial interface has 31 channels.
Then, the maximum bearer bandwidth of one VT interface is 2 x 31 x 64 kbit/s, that is, 3968 kbit/s.
The bearer bandwidth of the interface transmitting signaling packets is set to 0.
If the IVCP function is supported, the UMG8900 compresses the RTP packets to reduce the bandwidth
occupied by the RTP packets, thus improving transmission efficiency. After the IVCP function is enabled,
the route backup function of the interface is unavailable.
//Set Interface enable of the VT interfaces to disable.
MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=0, ENABLE=NO;
MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=1, ENABLE=NO;
//Set Interface enable of the VT interfaces to enable. Then, the setting can take
effect.
MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=0, ENABLE=YES;
MOD IPIF: IFT=VT, BT=HRB, BN=0, IFN=1, ENABLE=YES;
Postrequisite
After configuring IVCP on the IP over E1 interface, set the IP address for the IP over E1 interface.
Configuring the IP Interface Address
17.4 Protocol and Specification of IVCP

None

Feature Description 18 NTP Network Time
18 NTP Network Time
About This Chapter
protocols and specifications of NTP network time.
18.1 Overview of NTP Network Time

This section provides the definition and describes service benefits for carriers and user, and
18.2 Availability of NTP Network Time
18.3 Principle and Flow of NTP Network Time
18.4 Data Configuration of NTP Network Time
18.5 Protocol and Specification of NTP Network Time

18 NTP Network Time Feature Description
18.1 Overview of NTP Network Time

This section provides the definition and describes service benefits for carriers and user, and
Feature Definition
In the telecommunication networks, it is required that the system time of all the network elements
(NEs) to be the same. This facilitates the operation and maintenance, billing, and management
for the networks.
The Network Time Protocol (NTP) is used to ensure that the time of all the NEs is synchronized.
This function is primarily applied to the precision time synchronization of different NEs. When
applied in the fixed network or the wireless network, the UMG8900 uses this function.
The UMG8900 can act only as the NTP client. An NTP entity runs only on the OMU and
synchronizes the time of the OMU with the configured NTP server. The OMU is responsible
for synchronizing the time of other boards.
The UMG8900 uses the NTP function in client mode. The UMG8900 as a client sends the request
for time synchronization to the specified server. The host in client mode sends the packet to the
server periodically, regardless of the layer and the reachability of the server. The host in this
mode is the workstation in the local area network (LAN). It can be synchronized by the server
but does not synchronize the server.
Service Benefits
Table 18-1 Service benefits of NTP network time
NTP network time In centralized network This feature provides time

management mode, adopting correction between the billing
the NTP protocol in the LAN servers of carriers and the
can avoid the clock drift of the online PCs. Thus, the function
host. Thus, the clocks of allows users to avoid the
different billing systems in the troubles caused by the
LAN are synchronized, which difference between the
facilitates the traffic RADIUS bills of the office and
measurement, charge the users' bills recorded by the
settlement, and billing PC billing software.
management. In addition, the
NTP function provides time
correction between the devices
in the office and that at the user
end.

18.2 Availability of NTP Network Time

Required NEs
Table 18-2 Required NEs for NTP network time
Feature Required NE
NTP network time MGW and NTP Server
Version Support
Table 18-3 Versions supporting NTP network time
NTP network time V100R002 and later
18.3 Principle and Flow of NTP Network Time

The time synchronization is better when the number of clock sources is smaller. Because of the
enormous network, all devices cannot be connected to the same time server. Thus, in the Network
Time Protocol (NTP) model, hierarchical structure that is often up to 15 layers is adopted. The
main reference sources that are synchronized with the national standard clock are connected to
the frequently visited resource such as the backbone gateway. The main reference resources run
in the network as main time servers. The NTP nodes form the time trace system in hierarchical
structure. The node on the top layer (first layer) traces the national standard time. The node on
the second layer traces the national standard time through the node on the first layer. Each node
keeps a certain precision time according to its own clock. In addition, the node automatically
sends the request for correcting the time in appropriate correction cycle.
NTP is used to send the time information about the main time servers to other time servers
through the network. In addition, it is used to check the clock of every server periodically to
reduce the error caused by the device or transmission fault. Some NTP hosts or gateways in the
local area network (LAN) run as secondary time servers which send the time information to
other hosts in the LAN through the NTP protocol. Figure 18-1 shows the network structure.

Figure 18-1 NTP networking diagram
NOTE
The servers and clients are relative concepts. The device that provides the time standard is the server, and
the device that receives the time is the client.
The NTP connection can run in any of these modes: active peer mode, passive peer mode, client
mode, server mode, and broadcast mode.
Implementation Principle
The NTP consists of two parts: NTP client and NTP server. The NTP client and NTP server send
the data packets carrying their respective time information to each other. In this way, the NTP
client obtains the time information. Then, the NTP client figures out the best time to correct the
time through the time selection algorithm. Figure 18-2 shows the interaction process and
working principle of clock synchronization.

Figure 18-2 Principle diagram of clock synchronization
1. The NTP client sends an NTP data packet requesting synchronization to the NTP server.
The data packet carries the timestamp of leaving the NTP client. See Figure 18-2. The
timestamp is 10:00:00 am.
2. When the NTP data packet reaches the NTP server, the NTP server adds its timestamp, that
is, 11:00:01 am.
3. The NTP server sends the received data packet to the NTP client. The timestamp (11:00:02
am) of the NTP server is added to this data packet.
4. When the NTP client receives the response data packet from the NTP server, the NTP client
adds a new timestamp, that is, 10:00:03 am.
At present, the NTP client gets sufficient time information to calculate the two important
parameters required for time correction:
l Time delay of a cycle required when the NTP message is sent and received
l Time offset between the NTP client and the NTP server
Therefore, the NTP client can set its own clock based on the two parameters to synchronize the
clock with that of the NTP server.
Figure 18-3 shows how to calculate the time offset and delay in the NTP protocol.

Figure 18-3 Calculating method for time offset and delay
The NTP server sends the response packet to the NTP client. The response packet includes time
t0 at which the NTP client sends the request packet, time t1 at which the NTP server receives
the request packet, and time t2 at which the NTP server sends the response packet. The NTP
client can receive time t3 at which the response packet is received from the NTP server. The
calculating methods for time delay and offset are as follows:
l Delay = (t3 - t0) - (t2 - t1)

l Offset = [(t1 - t0) + (t2 - t3)]/2
Offset indicates the deviation between the node in the computer data network and the NTP server.
In general, the data transmission backbone network is configured with one or more NTP servers.
The nodes in the backbone data transmission network send the time synchronization request to
the NTP server. The clocks of the nodes in the entire network are synchronized through the NTP
time correction function.
The NTP client process of the back administration module (BAM) synchronizes with the NTP
server at a certain interval to ensure the time accuracy of the BAM. The BAM also sends the
data frame of time correction to the host at a certain interval (often every five minutes) to ensure
the consistency of host time with the BAM time. Thus, the time of the host, BAM, and NTP
server is the same.
18.4 Data Configuration of NTP Network Time

Context
The UMG8900 can be configured with up to 10 Network Time Protocol (NTP) servers. After
the configuration, the UMG8900 keeps sending NTP packets to each server and receives the
reply. Based on the timestamp in the NTP packets and the algorithm specified by the protocol,
the UMG8900 selects a best NTP server, calculates the deviation between the local time and the
server time, and then adjusts the local time.
When configuring the NTP servers, the UMG8900 can determine whether authentication is
required. If the authentication is required, the packet interaction between the UMG8900 and the
NTP servers require an authentication key ID. The receiving party of the packets obtains the key
based on the key ID, and then translates the packets.

Procedure
Step 1 Run SET TIMESYC to set the synchronization mode of the local system time to NTP.
Step 2 Run SET TZ to set the time zone and the daylight saving time. Daylight saving time is optional.
If the current time is during the daylight saving time zone and the NTP server is correctly set
and runs normally, the final local time is adjusted and calculated according to Greenwich Mean
Time and setting of the daylight saving time.
For example, Greenwich Mean Time got from the NTP Server is 03:00:00 and Beijing time is
11:00:00. If the current time is during the daylight saving time zone and the daylight saving time
is set to one hour forward, the final local time is 12:00:00.
Step 3 Run ADD NTPSRV to add the NTP server.
----End
Example
//Set the system time. Synchronize the host time with the NTP server.
SET TIMESYC: INFO=NTP;
SET TZ: ZONET=GMT_0800, DST=NO;
ADD NTPSRV: IPADDR="10.1.1.3", AUTH=NO, VER=3, PREFER=NO;
18.5 Protocol and Specification of NTP Network Time

Table 18-4 Protocols and specifications of NTP network time

NTP network time NTP

Feature Description 19 GPS Clock Synchronization
19 GPS Clock Synchronization
About This Chapter
protocols and specifications of global positioning system (GPS) clock synchronization.
19.1 Overview of GPS Clock Synchronization

19.2 Availability of GPS Clock Synchronization
19.3 Principle and Flow of GPS Clock Synchronization
19.4 Data Configuration of GPS Clock Synchronization
19.5 Protocol and Specification of GPS Clock Synchronization

19 GPS Clock Synchronization Feature Description
19.1 Overview of GPS Clock Synchronization

Feature Definition
The navigation star global positioning system (GPS) is the second generation satellite navigation
system developed by the US Department of Defense.
The UMG8900 supports the GPS clock synchronization, keeps track of the satellite system, and
provides Stratum 1 clock.
The performance of the GPS clock synchronization complies with the International
Telecommunication Union - Telecommunication Standardization Sector (ITU-T) G.811 clock
standard.
Service Benefits
Table 19-1 Service benefits of GPS clock synchronization
GPS clock synchronization This feature improves the Not involved

quality of service (QoS).
Table 19-2 Function restrictions of the GPS clock synchronization
GPS clock synchronization The independent CLK with the satellite card is inserted.
19.2 Availability of GPS Clock Synchronization

Required NEs
Table 19-3 Required NEs for GPS clock synchronization
Feature Required NE
GPS clock synchronization MGW

Version Support
Table 19-4 Versions supporting GPS clock synchronization
GPS clock synchronization V100&V200R002 and later
19.3 Principle and Flow of GPS Clock Synchronization

The UMG8900 contains two types of frames, that is, SSM-256 frames and SSM-32 frames. The
clock system of the SSM-256 frame is different from that of the SSM-32 frame.
In SSM-256 self-cascading mode, the clock signals between frames are distributed through the
clock distribution cable. Figure 19-1 shows the architecture of the clock system in SSM-256
self-cascading mode.
Figure 19-1 Architecture of the clock system in SSM-256 self-cascading
Figure 19-2 shows the architecture of the clock system in SSM-32 self-cascading mode.

19 GPS Clock Synchronization Feature Description
Figure 19-2 Architecture of the clock system in SSM-32 self-cascading
The dashed line represents the clock extraction when the independent CLK is used and the real
line represents the clock extraction when the clock subboard is used.
The CLK or clock subboard is always located in the main control frame. The CLK supports the
building integrated timing supply system (BITS), GPS, and 8-kHz line clocks. The clock
subboard supports the BITS and 8-kHz line clocks.
The GPS clock line connects the CLK and the GPS clock device through the SMA plug. The
connector of the GPS clock input cable is inserted into the ANT interface on the CLK to obtain
the GPS clock signals.
19.4 Data Configuration of GPS Clock Synchronization

Procedure
Step 1 Run MOD CLKSRC to set the GPS clock source.
If other clock sources are configured, seeCLK Providing the Clock.
----End
Example
//Configure the clock source and choose the GPS.
MOD CLKSRC: BRDTYPE=CLK, GPSPRI=FIRST, GPSTYPE=GPS;

19.5 Protocol and Specification of GPS Clock

Synchronization
Table 19-5 Protocol and specification of GPS clock synchronization

GPS clock synchronization ITU-T G.811

Feature Description 20 VMGW
20 VMGW
About This Chapter
protocols and specifications of virtual media gateway (VMGW).
20.1 Overview of VMGW

20.2 Availability of VMGW
20.3 Principle and Flow of VMGW
This section describes the implementation principles and service flow of virtual media gateway
(VMGW).
20.4 Data Configuration of VMGW
20.5 Protocol and Specification of VMGW

20 VMGW Feature Description
20.1 Overview of VMGW

Feature Definition
Virtual media gateway (VMGW) means that one physical media gateway (MGW) can be divided
into multiple logically independent MGWs. For example, if two VMGWs are defined for a
physical MGW, these two VMGWs can be connected to two media gateway controllers (MGCs).
Each MGC considers the VMGW controlled by it as an independent MGW.
The H.248 protocol defines that only a master MGC can control the related MGW. By defining
the VMGW, a physical MGW can be controlled by multiple MGCs. Each VMGW is identified
by the VMGW ID, and managed by different softswitches. The bearer resources of the physical
MGW can be allocated to different VMGWs in exclusive or resource-sharing mode so that the
flexibility of the UMG8900 is enhanced. In addition, the VMGW feature can be applied to the
disaster tolerance networking scheme of mobile switching center (MSC) Pool.
Figure 20-1 VMGW
See Figure 20-1. The UMG8900 is a physical device. To meet the networking requirements,
the UMG8900 is divided into three VMGWs: VMGW1 implements the interworking with the
global system for mobile communication/wideband code division multiple access (GSM/
WCDMA) network; VMGW2 implements the interworking with the code division multiple
access (CDMA); VMGW3 implements the interworking with the next generation network
(NGN). Thus, one physical UMG8900 can be logically divided into three MGWs. These
VMGWs are controlled by different softswitches. In addition, one VMGW can belong to two
MGCs (in master/slave mode) to realize the dual-homing function.

Service Benefits
Table 20-1 Service benefits of VMGW

VMGW It reduces the number of offices and the networking Not involved
cost (CAPEX).
It simplifies the network topology and reduces the
spare parts. Due to the integrated maintenance, the
cost can be lowered (OPEX).
It can adjust the percentage of the fixed and mobile
media resources dynamically. And thus the resources
can be effectively used.
The access and trunk gateway (ATG) and the
interception gateway (IGW) are integrated to reduce
the hardware investment.
Table 20-2 Function restrictions

VMGW In the UMG8900 R005/R006 versions, one physical MGW can be divided
into 16 VMGWs. In the R007 version, one physical MGW can be divided
into 32 VMGWs.
UMG8900 R005C02 and the later versions support VMGW feature
The resource allocation and interworking among VMGWs are restricted. For
details, see 20.3 Principle and Flow of VMGW.
In the R005 version, the UMG8900 serves as an IGW, but it does not support
the integration of ATG and IGW. V100R006C02 and the later versions
support the integration of ATG and IGW.
The VMGWs do not support the role-based management. That is, the user
cannot manage only one VMGW.
20.2 Availability of VMGW


Required NEs
Table 20-3 Required NEs for VMGW

Feature Required NE
VMGW UA, MGC, and NMS
Version Support
Table 20-4 Versions supporting VMGW

VMGW R005C02 and later
NOTE
V100R006C02 and later versions support the integration of ATG and IGW.
20.3 Principle and Flow of VMGW

This section describes the implementation principles and service flow of virtual media gateway
(VMGW).
Application Scenarios
l Application scenario 1: One physical MGW is used in multiple networks of a carrier.
Figure 20-2 One physical gateway shared by multiple MGCs

An carrier owns multiple networks such as the UMTS, CDMA, and GSM. When being
connected to networks of other operators, each network requires an independent
UMG8900 in traditional networking applications. Each network uses one VMGW that
serves as an MGW after the UMG8900 is divided into VMGWs. Therefore, one
UMG8900 can realize interworking between different networks, which saves the network
investment.
l Application scenario 2: One physical gateway is shared by multiple MGCs, and the
seamless capacity expansion is realized without any modification to hardware connections.
Figure 20-3 One physical gateway shared by multiple MGCs
Several MGCs can share one MGW local exchange. When one of the MGCs is overloaded,
some services of the base station controllers (BSCs)/user agents (UAs) can be shifted to
another MGC without any modification to hardware connections.
For example, when VMGW 1 accesses BSCs/UAs 1 to 10, VMGW 1 is controlled by MGC
1. If more users access the BSC/UA and MGC 1 is overloaded, MGC 2 can take over some
services of the BSCs/UAs.

Before service switchover, configure the data on MGC 2. Then, modify the data on the
UMG8900 to bind the TDM resources of some BSCs/UAs to VMGW 2. Meanwhile,
modify the data on the BSCs/UAs to connect the BSCs/UAs to MGC 2. You do not need
to modify the hardware connections.
l Application scenario 4: In the next generation network (NGN), the interception gateway
(IGW) is used for interception of the IAD/Ephone/AG. In certain cases, the small terminal
equipment such as IAD, Ephone, and AG does not support sending and copying of
interception contents. The services must be transferred to the IGW and then transparently
transmitted by the IGW. Then, interception to subscribers is performed on the IGW. In the
functional model, the IGW can integrate with the UMG8900 to serve as an AG, a TG, or
a TDM switch. The IGW can export packet interception streams and provide TDM
interfaces.
Figure 20-4 IGW networking in the ATG & IGW integrated architecture
Principle Description
The UMG8900 supports up to 32 VMGWs, and each VMGW supports the configuration of three
master and slave softswitches to ensure immediate switch in the case of failure. The following
figure shows how the VMGW is realized on the UMG8900. Only the master server controls the
MGW at one time.

Figure 20-5 Realization principle of the VMGW
l Allocating resources
– TDM resources
The TDM resources are allocated by being bound to VMGWs. You can allocate the
TDM bearer resources to different VMGWs by using the MML commands. Thus, the
TDM resources can be logically allocated.
In the R007 version, the MGW proxy A-Flex/Iu-Flex solution enables different
VMGWs to share the TDM resources. Thus, the circuit multiplexing efficiency of A
interface is improved. This solution is directed only for the management of the A
interface in TDM mode in MGW proxy A-Flex solution. For details, see the Description
of the MSC Pool Feature.
– Other resources
ATM/IP interfaces and TC/EC resources are dynamically shared by all VMGWs.
Note that the IP over E1 feature enables the IP packets directly to be carried over E1
port. Thus, the E1 port carrying IP packets is different from the E1 resource of traditional
TDM PCM code stream. The E1 port, similar to the VoIP FE/GE port, can be shared
by all VMGWs.
l Managing NEs
At present, the command configuration, system log, performance statistic, and alarm
information about the UMG8900 are not saved based on VMGWs. The configuration of
command lines is considered as an example. You cannot directly delete all the
configurations of a VMGW at a time. You can only delete certain configuration of a
specified VMGW. The VMGWs in N2000 network element (NE) topology are physically

presented as one network manager (NM) identifier rather than multiple logically
independent VMGWs.
l VMGW interworking
In actual networking, the application of VMGW requires the interworking of different
VMGWs. The IP interworking mode and the TDM interworking mode can be selected for
VMGW interworking.
– IP interworking mode
When the signaling interworking between the MGCs is achieved through the Session
Initiation Protocol (SIP), the IP interworking mode must be used for the VMGWs of
the UMG8900.
If the IP is chosen for internal interworking, the VMGW interworking service stream
is not necessarily transmitted to the router for loopback. The IP interface board judges
that the service stream is the interworking connection of the current physical gateway.
Then, the service stream is directly looped back to the GE backplane through the
MHRU. The service stream does not occupy the interconnected port of the router
through the MGW; however, it affects packet forwarding and processing capabilities
of the MHRU. In the TDM networks such as the global system for mobile
communications (GSM), the internal IP interworking requires two more TCs to switch
the service path.
Figure 20-6 Streams carried by the VMGW through the IP interworking mode in the
case of TDM input and TDM output

Figure 20-7 Streams carried by the VMGW through the IP interworking mode in the
case of TDM input and IP output
– TDM interworking mode

When the signaling interworking between the MGCs is achieved through the Integrated
Services Digital Network User Part/ISDN User Part (ISUP), the TDM interworking
mode must be used for the VMGWs of the UMG8900.
If the TDM is chosen for internal interworking, to realize the VMGW interworking, the
TDM service stream must travel to the digital distribution frame (DDF) through the
external E1 port for the loopback of the TDM service stream.
Figure 20-8 Streams carried by the VMGW through the TDM interworking mode in
the case of TDM input and TDM output

The VMGW interworking, similar to the interworking between two independent physical
MGWs, occupies a certain VMGW interworking resources.
20.4 Data Configuration of VMGW

Procedure
Step 1 Configure the virtual media gateway (VMGW).
1. Run SET VMGW to configure the specified VMGW ID.
NOTE
The maximum IP termination number, time division multiplexing (TDM) termination number, and
asynchronous transfer mode (ATM) termination number supported by each VMGW can be
configured with SET VMGW.
2. Run ADD MGC to configure the media gateway controller (MGC) that matches the
specified VMGW. The different VMGWs are controlled by different MGCs.
3. Run SET H248PARA to configure the H.248 protocol parameters of the specified VMGW.
4. Run ADD H248LNK to add the H.248 signaling link from the specified VMGW to the
MGC.
NOTE
The different VMGWs can share an H.248 interface, that is, the local IP addresses of the H.248 link
of the different VMGWs can be the same. But the local port numbers cannot be the same. The H.248
bearer protocol can be different.
5. Run ACT VMGW to activate the specified VMGW.
Step 2 Run ADD TDMIU to configure the TDM resources bound to the specified VMGW, as well as
the interworking of the VMGW.
The VMGWs in fixed and mobile networks are respectively connected to the softswitches in
fixed and mobile networks. At present, Huawei's softswitches in fixed and mobile networks
interwork only through ISUP. Therefore, the VMGWs in fixed and mobile networks can be
connected only through the TDM mode. The TDM interfaces that can interwork between the
VMGWs are directly connected with external loopback cables.
NOTE
The basic TDM interworking method is described here. How the TDM resources are shared by different
VMGWs in the MGW proxy A-Flex/Iu-Flex solution is not given here.
Step 3 Configure the IP interworking between VMGWs (SIP signaling between MGCs).
Different VMGWs can share the IP terminations. All the VMGWs select the IP terminations
according to the same policy. Once an IP termination is selected by a VMGW, this IP termination
belongs to the VMGW before it is released.
The IP interface of the VMGW processes the IP packets in the following ways:
l The VMGW sends the bearer packets to the related MGW based on the source IP address of
the IP bearer packets. Then, the MGW transfers the packets according to the routing table.

l The VMGW sends the signaling packets that come from the MGC to the next-hop router
according to the routing table.
l The IP interface directly loops back the IP packets that interwork between the VMGWs to
the GE bus. These IP packets are not sent out.
The IP interworking between VMGWs is not involved in the transmitting of the bearer packets
and signaling packets. Therefore, the packet processing remains the same. For the IP packets
that interwork between the VMGWs, the UMG8900 can determine to loop back or transfer the
packets without the involvement of the configurations. Therefore, the IP interworking between
VMGWs remains the same.
----End
20.5 Protocol and Specification of VMGW

Table 20-5 Protocols and specifications of VMGW

VMGW ITU-T Recommendation H.248.1

RFC3015

Feature Description 21 MGC Dual Homing
21 MGC Dual Homing
About This Chapter
protocols and specifications of media gateway controller (MGC) dual homing.
21.1 Overview of MGC Dual Homing

21.2 Availability of MGC Dual Homing
21.3 Principle and Flow of MGC Dual Homing
21.4 Data Configuration of MGC Dual Homing
21.5 Protocol and Specification of MGC Dual Homing

21 MGC Dual Homing Feature Description
21.1 Overview of MGC Dual Homing

Feature Definition
Compared with the traditional mobile switching center (MSC), the softswitch architecture based
exchange device in the core network has larger capacity, wider service scope, and more
customers. In case of breakdown due to natural disaster, misoperation and device fault, it is likely
to have service interruption on a larger scale than that of the traditional MSC.
To ensure security and reliability of the network, Huawei softswitch provides a dual homing
solution by adding a backup softswitch.
The UMG8900 is configured with the master and slave softswitches. Generally, the master
softswitch manages the UMG8900 to process signaling and provide telecommunication service.
When the master softswitch is faulty, the slave softswitch can take over all the tasks of the master
softswitch. Thus, the mobile network proceeds.
Dual homing is recommended when the network is important and the service requirements are
high.
Service Benefits
Table 21-1 Service benefits of MGC dual homing
MGC dual homing It provides backup capacity for remote Not involved
disaster tolerance to improve the reliability
of softswitch network.
It provides the secure and reliable service,
ensuring the service quality, improving the
competitiveness.
It does not affect the peripheral network
elements.
Table 21-2 Function restrictions of MGC dual homing
MGC dual homing This feature does not support the cooperation with the softswitch of
other suppliers.

21.2 Availability of MGC Dual Homing

Required NEs
Table 21-3 Required NEs for MGC dual homing
Feature Required NE
MGC dual homing MGW and MGC
Version Support
Table 21-4 Versions supporting MGC dual homing
MGC dual homing V100R002 and later
21.3 Principle and Flow of MGC Dual Homing

Dual-Homing Switchover
l Switchover principles
To implement the disaster tolerance function between different dual-homing softswitches,
the softswitches must support the automatic dual-homing switchover. The general
principles of dual-homing switchover are as follows:
– The service logic is unchanged during dual homing switchover.
For instance, when the service is switched to another softswitch, the inter-exchange
calls between the master and slave softswitches are still inter-exchange calls, and the
inter-exchange switchover between the master and slave softswitches is still inter-
exchange switchover. That is, the switchover is performed on a physical softswitch that
is logically different softswitches.
– The dual-homing switchover is performed on softswitches.
When some media gateways (MGWs) under one softswitch are faulty, the dual-homing
switchover is not triggered. The switchover takes place only when the softswitch is

faulty. In this case, all the services of the MGWs under the faulty softswitch are switched
over to the slave softswitch.
l Dual-homing switchover modes
Two modes of dual-homing switchover are available.
– Automatic mode
The dual homing system checks the master softswitch according to the pre-set
parameters. Once it detects that the master softswitch is abnormal or recovers from the
abnormality, the dual-homing switchover or changeback is triggered automatically.
– Manual mode
Run the related commands to trigger the dual-homing switchover or changeback.
Based on the differences of the switchover and the changeback, the two working modes
can be set flexibly softswitches.
In application, automatic switchover and manual changeback are recommended to
minimize the service interruption time and to avoid the repeated switchover in abnormal
situations.
l Dual-homing switchover/changeback in automatic mode
– Trigger conditions
In automatic mode, the slave softswitch determines the trigger of the dual-homing
switchover and changeback by judging the state of the master softswitch based on the
heartbeat signals.
The UMG8900 judges the state of the softswitch based on the handshake signaling with
the softswitch. If the UMG8900 detects that the master softswitch is faulty, it registers
with the slave softswitch.
– Process of dual-homing switchover
When the master softswitch cannot provide services, the heartbeat connection between
the master and slave softswitches is interrupted, and the master softswitch terminates
the handshake signal with the UMG8900.
When the slave softswitch cannot detect the heartbeat signal of the master softswitch at
a interval, it determines that the master softswitch is faulty, and the dual-homing
switchover is triggered. The slave softswitch activates the virtual softswitch of the local
master softswitch, and waits for the registration of the UMG8900.
If the UMG8900 does not receive the handshake signal from the master softswitch at a
interval, it determines that the master softswitch is faulty. In this case, the UMG8900
registers with the slave softswitch. After the registration of the UMG8900, the slave
softswitch processes the service from the UMG8900.
– Dual-homing changeback
When the master softswitch recovers to the normal condition, the heartbeat connection
with the slave softswitch is recovered.
When the slave softswitch detects the heartbeat signal of the master softswitch, it
determines that the master softswitch becomes normal. Then, the slave softswitch
triggers the dual-homing changeback. The slave softswitch activates the local virtual
softswitch of main offices and terminates the handshake with the UMG8900.
When the master softswitch becomes normal, the UMG8900 registers with the master
softswitch again, and the master softswitch begins to process the service from the
UMG8900.
l Dual-homing switchover/changeback in manual mode

In manual mode, to trigger the dual-homing switchover or changeback, run the appropriate
commands.
To initiate the dual-homing switchover, the user needs to send the switchover command to
the master and slave softswitches. When the master softswitch receives the switchover
command, it terminates the handshake signal with the UMG8900. When the slave
softswitch receives the switchover command, it activates the local virtual softswitch of the
master softswitch. When the UMG8900 determines that the master softswitch is faulty
based on the termination of the handshake signal, it registers with the slave softswitch.
The dual-homing switchover and changeback are the same in manual mode, except that the
service is changed back to the master softswitch from the slave softswitch.
If the dual-homing switchover cannot be triggered in automatic mode, you can trigger it in
manual mode.
l 1+1 mutual-aided dual-homing networking
Figure 21-1 shows the networking of 1+ 1 mutual-aid dual homing.
Figure 21-1 1+1 mutual-aid dual homing networking diagram
In the networking of 1+1 mutual-aid dual homing, the two softswitches can switch their
roles as master and slave, and they maintain a heartbeat connection.
Normally, the UMG8900 1 and the UMG8900 2 belong to the MGC 1, and the
UMG8900 3 belongs to MGC 2.
In Figure 21-1, the continuous line indicates that the connection between the UMG8900
and the master softswitch is in the active state. The dotted line indicates that the connection
between the UMG8900 and the slave softswitch is in the non-active state.
In system configuration in 1+1 mutual-aided networking, the maximum number of users
that may be controlled by the softswitch must be considered, thus ensuring sufficient
capacity and resources for the office. This is to ensure that the slave softswitch can take
over all the services of the master softswitch after dual-homing switchover.

For example, the MGC 1 and MGC 2 are to be configured to support the service of three
UMG8900s.
l 1+1 master/slave dual homing networking
Figure 21-2 shows the networking of 1+1 master/slave dual homing.
Figure 21-2 1+1 master/slave dual homing networking diagram
The 1+1 master/slave dual-homing solution is a special case of the 1+1 mutual-aided dual-
homing solution. In the networking of 1+1 mutual-aided dual-homing, if one softswitch
office is normal and no UMG8900 registers with the softswitch, the networking of 1+1
mutual-aided dual-homing is the same as that of 1+1 master/slave dual homing.
In the networking of 1+1 master/slave dual homing, the two softswitches serve as the master
and slave, and they keep a heartbeat connection. UMG8900 1, UMG8900 2, and
UMG8900 3 take the master MGC as the master softswitch. In the normal case, the link
connection between the UMG8900 and the master softswitch is in the active state. The link
connection between the UMG8900 and the slave softswitch is in the non-active state.
Compared with the 1+1 mutual-aided dual-homing, 1+1 master/slave dual homing requires
a specific slave softswitch in the network. When the master softswitch is normal, the slave
softswitch has no service to process. After the dual-homing switchover, the slave softswitch
takes the place of the master softswitch to process the service.
21.4 Data Configuration of MGC Dual Homing

Configuration Suggestions
In the dual-homing networking, even though the master softswitch is normal, the slave softswitch
may fail to receive the heartbeat message from the master softswitch, and become active due to
the interruption of the IP network or other causes. The simultaneous activeness of the two
softswitches of a UMG8900 is called dual activation.

In case of dual activation, the link connections between the UMG8900 and the two softswitches
are in the active state. Thus, the UMG8900 may allocate the signaling from other network
elements to the two softswitches, causing network confusion.
In dual activation, to ensure that the UMG8900 can send the signaling first to the master
softswitch for processing, the signaling data between the UMG8900 and the softswitch must be
configured with different priorities. The specific configuration has two modes: link priority and
route priority.
l Link priority mode
Figure 21-3 shows the networking diagram of link priority.
Figure 21-3 Networking diagram of link priority
The 1+1 dual-homing networking is composed of two softswitches. The UMG8900 also
serves as the signaling gateway to forward signaling messages between the softswitch and
other network nodes such as the home location register (HLR).
MGC 1 is the master softswitch of UMG8900 1, and MGC 2 is the master softswitch of
UMG8900 2.
Configure the link to MGC 1 on UMG8900 1. Half links with higher priorities in the link
set are connected to the local virtual softswitch of MGC 1. The other half links with lower
priorities in the link set are connected to the remote virtual softswitch of MGC 2.
Normally, the UMG8900 1 sends the signaling to MGC 1 through links with higher priority.
When MGC 1 is faulty, the UMG8900 connects MGC 2, and sends the message to MGC
2 to process.
UMG8900 2 and UMG8900 1 have the same configuration principles.
l Route priority mode
Figure 21-4 shows the networking diagram of route priority.

Figure 21-4 Networking diagram of route priority
The 1+1 dual-homing networking is composed of two softswitches. The UMG8900 also
serves as the signaling gateway to forward signaling messages between the softswitch and
other network nodes such as the HLR.
MGC 1 is the master softswitch of UMG8900 1 and MGC 2 is the master softswitch of
UMG8900 2.
Two routes are configured on UMG8900 1 to MGC 1. One route is a direct route from C
to A, which has a higher priority. The other is an indirect route first connected to MGC 2
and then to MGC 1. This route takes MGC 1 as a signaling transfer point and has a lower
priority.
Normally, UMG8900 1 sends the signaling of MGC 1 to MGC 1 through the direct route
for processing. After the dual-homing switchover, UMG8900 1 sends the signaling of MGC
1 to MGC 2 through the indirect route for processing.
The route configuration of UMG8900 2 is the same as that of UMG8900 1.
The link priority and route priority modes are applicable to the Internet Protocol (IP)
signaling and the time division multiplexing (TDM) signaling. Only half links in link
priority mode are available and alarm exists on the MGW. Thus, the route priority
networking mode is recommended to avoid the disadvantages of link priority mode. The
Route priority mode requires that the gateway or the external network element configure
the signaling route priority. If the route is unavailable, select the link priority mode.
Procedure
Step 1 Run SET VMGW to configure the virtual media gateway (VMGW).
Step 2 Run ADD MGCto add the master media gateway controller (MGC).
Step 3 Run ADD MGCto add the slave MGC.
Step 4 Run ADD H248LNK to configure an H.248 signaling link to the master MGC.
Step 5 Run ADD H248LNK to configure an H.248 signaling link to the slave MGC.

Step 6 Run ACT VMGWto activate the VMGW.
Step 7 Run ADD L2UALKSto add a SIGTRAN link group.
Step 8 Run ADD L2UALNKto configure a SIGTRAN link to the master MGC.
Step 9 Run ADD L2UALNKto configure a SIGTRAN link to the slave MGC.
----End
Example
//Configure the master and slave MGCs.
//Configure VMGW 0
SET VMGW: VMGWID=0, MIDTYPE=IP, MID="211.169.150.41:2945";
//Specify the master MGC for VMGW 0.

ADD MGC VMGWID=0, MGCIDX=0, MIDTYPE=IP, MID="191.169.150.30:2944", MSS=MASTER;
//Specify the slave MGC for VMGW 0.

ADD MGC: VMGWID=0, MGCIDX=1, MIDTYPE=IP, MID="191.169.150.50:2944", MSS=SLAVE;
//Configure the H.248 signaling links to the master and slave MGCs.
//Configure the H.248 signaling link to the master MGC.
LOCALPORT=2945, PEERIP="191.169.150.30", PEERPORT=2944, LINKNAME="To-Master-MGC";
//Configure the H.248 signaling link to the slave MGC.

LOCALPORT=2945, PEERIP="191.169.150.50", PEERPORT=2944, LINKNAME="To-Slave-MGC";
//Activate the VMGW.

ACT VMGW: VMGWID=0;
//Configure the SIGTRAN links to the master and slave MGCs.

//Configure the SIGTRAN link group.
ADD L2UALKS: PROTYPE=IUA, LKS=0, PT=2, NMA=1, TRANSTXTID=NOUSE, TM=LOADSHARE;
//Configure SIGTRAN links 0 and 1 to the master MGC.

ADD L2UALNK: PROTYPE=IUA, BN=1, LNKNO=0, LKS=0, LOCALPN=9900,
LOCALIP1="211.169.150.41", REMOTEPN=9900, REMOTEIP1="191.169.150.30", CS=Server,
PRIO=0, INSTREAM=16, OUTSTREAM=16;
//Configure SIGTRAN links 2 and 3 to the slave MGC.

21.5 Protocol and Specification of MGC Dual Homing

Protocols and Specifications of MGC dual homing

None

Feature Description 22 SCTP Multi-homing
22 SCTP Multi-homing
About This Chapter
protocols and specifications of the Stream Control Transmission Protocol (SCTP) multi-homing.
22.1 Overview of SCTP Multi-homing

22.2 Availability of SCTP Multi-homing
22.3 Principle and Flow of SCTP Multi-homing
22.4 Data Configuration of SCTP Multi-homing
22.5 Protocol and Specification of SCTP Multi-homing

22 SCTP Multi-homing Feature Description
22.1 Overview of SCTP Multi-homing

Feature Definition
The Stream Control Transmission Protocol (SCTP) multi-homing refers to a feature that multiple
IP addresses are supported in one SCTP association. The two ends of the association can own
multiple IP addresses. Therefore, a much more reliable end-to-end multi-path transmission
mechanism is available to users of upper layer protocols.
The SCTP multi-homing provides the following functions:
l The M3UA/L2UA/H.248 links can be configured with two local IP addresses and two peer
IP addresses. The peer IP addresses are of domain name.
l When the upper layer of the SCTP client requires for link establishment, the SCTP client
sends the request carrying the local IP address list to the SCTP server. The peer IP addresses
are first selected in turn, and then the local IP addresses are selected in turn until the link
establishment succeeds.
The SCTP server performs the interception by binding the local IP address list and the ports.
The SCTP server can reject the request for the link establishment from illegal IP addresses.
The SCTP link establishment requires that the number and value of the local IP addresses
of the SCTP client are the same as those of the peer IP addresses of the SCTP server.
l The path management to the SCTP multi-homing is supported.
SCTP manages the paths of the association through heartbeat mechanism. The number of
the paths depends on that of the peer IP addresses. That is, one association can own two
paths if two peer IP addresses are configured. Therefore, the SCTP terminations maintain
the paths from the local primary IP address to the two destination IP addresses. When the
value of path retransmit attempts is greater than the path retransmit threshold, SCTP reports
to the upper layer protocols that the peer IP addresses are not reachable, and then switches
over the path. When the value of path retransmit attempts reaches the association retransmit
threshold, SCTP reports to the upper layer protocols that the association is disconnected.
l The transmitting and receiving of the multi-homing data can be realized.
SCTP sends the packets from the local primary address and receives the packets coming
from the destination primary address and the secondary address.
l The parameters of the SCTP management information base (MIB) and the association
information can be queried.
Application Scenarios
The SCTP multi-homing is applicable to networks with separated architectures. The
UMG8900 supports the two-path and four-path applications, which offers better compatibility.
The details are respectively described as follows:
l Two-path application of the SCTP multi-homing

Figure 22-1 Two-path application scenario of the SCTP multi-homing
See Figure 22-1. The two paths of the SCTP multi-homing are as follows: path from the
local primary IP address to the remote primary IP address; path from the local secondary
IP address to the remote secondary IP address. In this case, the SCTP association owns
only two paths. The path can be switched over in the case of failure.
l Four-path application of SCTP multi-homing
Figure 22-2 Four-path application scenario of the SCTP multi-homing
See Figure 22-2. The four-path application, similar to the two-path application, supports
two local IP addresses and two peer IP addresses.
The four paths of the SCTP multi-homing are as follows: path from the local primary IP
address to the remote primary IP address; path from the local secondary IP address to the
remote secondary IP address; path from the local primary IP address to the remote
secondary IP address; path from the local secondary IP address to the remote primary IP
address. In this case, the SCTP association owns four paths. The path can be switched over
in the case of failure.
l Two-path application and four-path application of SCTP multi-homing
Figure 22-3 Two-path and four-path application scenarios of the SCTP multi-homing

See Figure 22-3. The media gateway (MGW) can support the virtual media gateways
(VMGWs). Therefore, the MGW can be connected to multiple media gateway controllers
(MGCs) at the same time. Some MGCs support only two-path application of the SCTP
multi-homing, while some MGCs support only the four-path application of the SCTP multi-
homing.
Whether the two-path application or the four-path application is adopted depends on the
MGC connected to the UMG8900.
Service Benefits
Table 22-1 Service benefits of the SCTP multi-homing

SCTP multi-homing This feature guarantees stable running of Not involved

the device and avoids link disconnection.
22.2 Availability of SCTP Multi-homing

Required NEs
Table 22-2 Required NEs for SCTP multi-homing

Feature Required NE
SCTP multi-homing MGW and MGC
Version Support
Table 22-3 Versions supporting SCTP multi-homing

SCTP multi-homing R007 and later
22.3 Principle and Flow of SCTP Multi-homing


The Stream Control Transmission Protocol (SCTP) and the Transmission Control Protocol
(TCP)/User Datagram Protocol (UDP) belong to the protocols of transport layer. The SCTP
protocol combines the features of the UDP packet transmission and the TCP reliable sequential
transmission, and thus is suitable for telecommunication. These telecommunication applications
require reliable transmission without packet limitations.
The TCP/UDP protocol identifies an association rather than a connection (the UDP protocol is
connectionless) with a quaternary group including the local address, local port, remote address,
and remote port. The SCTP protocol extends the local address and remote address in the
quaternary group to local address list and remote address list. The addresses in the lists
correspond to different interfaces or different routes.
By default, an address in the list is selected as the primary IP address. In general, the protocol
stack uses the primary IP address as the destination IP address to which the packets are sent.
When the path corresponding to the primary IP address is unavailable, for example, the
corresponding interface is faulty or the network route breaks down, another address in the list
is selected as a new primary IP address. The new primary IP address is the destination IP address
to which the packets are sent.
When the UMG8900 is configured with the SCTP multi-homing, the local end can be configured
with two IP addresses and the remote end can also be configured with two IP addresses or two
domain name addresses. In this case, the SCTP protocol identifies an association with hexahydric
group including the local address list, local port, remote address list, and remote port. The local
address list and the remote address list represent two IP addresses. One is the primary IP address
and the other is the secondary IP address.
Figure 22-4 shows the principle of the SCTP multi-homing.
Figure 22-4 Principle of the SCTP multi-homing
The UMG8900 is configured with the local IP address list and the destination IP address list that
respectively contain at least two IP addresses. The destination IP address can be of domain name.
NOTE
This feature requires two IP addresses. One is the primary IP address and the other is the secondary IP
address.
The UMG8900 requires SCTP to support the following: H.248 protocol and SIGTRAN (M3UA/
L2UA) protocol. These two types of protocols support the SCTP multi-homing. The primary IP
address of the peer device is used when the link is established. When the primary IP address is
unavailable, the secondary IP address is used for link establishment to guarantee the normal state
of the link.

Service Flow
The H.248, L2UA, or M3UA link forwards the messages through the centralized forwarding
interface on the OMB, MPU, MPB, or HRU. Therefore, the SCTP multi-homing requires that
the centralized forwarding boards work in load-sharing mode. That is, the centralized forwarding
modules of the master and slave boards must be capable of realizing centralized forwarding
function. The HRU supports the SCTP multi-homing. The OMB, MPU, and MPB are supposed
to support the SCTP multi-homing. The description to the OMB, MPU, and MPB is as follows
(The board refers to the OMB, MPU, or MPB unless otherwise specified).
The Mc interface on the OMB can be configured to load-sharing mode. The OMC interface is
the interface for system maintenance and can work only in master/slave mode.
Figure 22-5 shows the internal processing of the SCTP multi-homing.
Figure 22-5 Internal processing of the SCTP multi-homing
The centralized forwarding module can work in load-sharing mode. That is, the slave board also
enables the IP module and provides the centralized forwarding function. In addition, the slave
board is compatible with the master/slave features in versions earlier than R007C01. The OMB,
MPU, or MPB determines the master/slave mode or load-sharing mode for the IP module based
on the actual conditions.
Set Slot No. with the command that adds the IP address. Thus, an IP address can be effective
only in one slot. Slot No. is optional. When the boards work in master/slave mode, you do not
need to configure Slot No. When the boards work in load-sharing mode, you must configure
Slot No.
22.4 Data Configuration of SCTP Multi-homing


Configuration Principles
l The centralized forwarding board is configured to load-sharing mode. Then, set the IP
address of the centralized forwarding interface on the slave board and add the link with this
IP address.
l The OMC interface on the OMB in the main control frame supports only the master/slave
mode. The OMC interface on the slave board cannot be configured with the IP address even
if the OMB works in load-sharing mode.
NOTE
If the OMB works in load-sharing mode, only the Mc interface works in load-sharing mode. The
OMC interface is the operation and maintenance interface and works in master/slave mode.
The master/slave mode cannot be switched to the load-sharing mode in the following situations:
l The IP interface on the specified board is configured with the detection IP address. Then,
the detection IP address is deleted.
l The IP interface on the specified board is configured with the voice mobile attenuation code
(VMAC). Then, the VMAC is deleted.
l The IP interface on the specified board is configured with the peer IP address. Then, the
peer IP address is deleted.
l The IP interface on the specified board is configured with the Address Resolution Protocol
(ARP). Then, the ARP is deleted.
l The IP interface on the slave board is disabled.
l The packets of the IP interface on the specified board are forwarded.
The load-sharing mode cannot be switched to the master/slave mode in the following situations:
l The IP interface on the specified slave board is configured with the static route.
l The IP interface on the specified slave board is configured with the IP Security Protocol
(IPSec) crypto map set.
l The IP interface on the specified slave board is configured with the virtual local area
network (VLAN).
l The IP interface on the specified slave board is configured with the centralized forwarding.
l The IP interface on the specified slave board is configured with the bidirectional forwarding
detection (BFD).
l The IP interface on the specified slave board is configured with the IP address.
Procedure
Step 1 Run SET IPWORKMODE to set the IP work mode of the centralized transferring board to
load sharing.
After the board switches to the load-sharing mode, the centralized transferring function is
realized on both the master and slave boards.
The load-sharing mode is valid only for the OMB, MPB, and MPU.
Step 2 Run ADD IPADDR to add the IP address on the master board.
The slot number must be specified in load-sharing mode.
Step 3 Run ADD IPADDR to add the IP address on the slave board.

Step 4 Run ADD ROUTE to add the default route.
Step 5 Run ADD H248LNK to add the H.248 link.
Step 6 Run ADD M3LNK to add the M3UA link.

NOTE
The L2UA link must be configured if the centralized forwarding module forwards the signaling transport
(SIGTRAN) messages through L2UA.
----End
Example
Network diagram
Figure 22-6 shows the typical networking of the SCTP multi-homing.
Figure 22-6 Typical networking of the SCTP multi-homing
Set the IP work mode of the OMB to load sharing and set the IP addresses of the Mc interfaces
on the master and slave boards. Then, add the H.248 link and M3UA link with the configured
IP addresses. The packets of the PPU and SPF can be transferred through the Mc interfaces on
the master and slave OMBs.
Data planning
Before configuring data, negotiate the main interworking parameters between the MGC and the
UMG8900. See Table 22-4.
Table 22-4 Configuration information about the SCTP multi-homing
1 Local IP address 1 and port number 10.110.110.110: 5000

2 Local IP address 2 and port number 10.110.110.111: 6000
3 Peer IP address 1 and port number 192.168.1.10: 5000
4 Peer IP address 2 and port number 192.168.1.11: 6000
IP address of the router connected to the

5 10.110.110.1
UMG8900
Example script
//Set the IP work mode of the centralized transferring board, set the board type to
OMB, board number to 0, and IP work mode to load sharing.
SET IPWORKMODE: BT=OMB, BN=0, WM=LOADSHARE;
//Add the IP address of the Mc interface on the master OMB.

ADD IPADDR: BT=OMU, BN=0, IFT=ETH, IFN=1, IPADDR="10.110.110.110",
MASK="255.255.255.0", FLAG=MASTER, INVLAN=NO, SN=7;
NOTE
The Mc interface on the OMB in the SSM-32 frame can be set only to load-sharing mode. The OMC
interface can be set only to master/slave mode.
//Add the IP address of the Mc interface on the slave OMB.
ADD IPADDR: BT=OMU, BN=0, IFT=ETH, IFN=1, IPADDR="10.110.110.111",
MASK="255.255.255.0", FLAG= SLAVE, INVLAN=NO, SN=8;
//Add the default route and the IP address of the next hop is 10.110.110.1.
ADD ROUTE: BT=OMU, BN=0, DSTIP="0.0.0.0", DSTMASK="0.0.0.0", RTTYPE=NEXTHOP,
NEXTHOP ="10.110.110.1", PREF=60;
//Add the H.248 link. The path mode is set to TWOPATH. In the SCTP multi-homing,
Local Master IP address and Peer Slave address must be specified.
ADD H248LNK: LINKID=1, VMGWID=2, MGCIDX=2, TT=SCTP, LOCALIP="10.110.110.110",
LOCALPORT=5000, PTHMODE=TWOPATH, PEERIP="192.168.1.10", PEERPORT=5000,
SLIP="10.110.110.111", SRIP="192.168.1.11", FN=1, SN=7, BP=FRONT;
//Add the M3UA link. The path mode is set to TWOPATH. In the SCTP multi-homing,
Second IP Address of Local End and Second Address of Remote End must be specified.
ADD M3LNK: LNK=1, BT=SPF, BN=0, LKN="to MGC", LIP1="10.110.110.110",
LIP2="10.110.110.111", LP=6000, RIP1="192.168.1.10", RIP2="192.168.1.11", RP=6000,
LSX=0, ASF=ACTIVE, PTHMODE=TWOPATH;
22.5 Protocol and Specification of SCTP Multi-homing

Table 22-5 Compliance protocols and specifications of SCTP multi-homing
SCTP multi-homing ITU-T Recommendation H.248.4-AnnH (SCTP

transmission)
RFC2960

Feature Description 23 IPSec
23 IPSec
About This Chapter
protocols and specifications of IP Security (IPSec).
23.1 Overview of IPSec

23.2 Availability of IPSec
23.3 Principle and Flow of IPSec
This section describes the implementation principles and service flow of IPSec.
23.4 Configuring IPSec
23.5 Protocol and Specification of IPSec

23 IPSec Feature Description
23.1 Overview of IPSec

Feature Definition
IP Security (IPSec) is a framework security protocol formulated by the Internet Engineering
Task Force (IETF) to ensure security and encryption performance of the data transmitted on the
Internet. The purpose of this protocol is to provide security service for Internet Protocol (IP)
packets. IPSec consists of two security protocols: Authentication Head (AH) and Encapsulating
Security Payload (ESP). AH is the protocol for the packet verification header. AH provides
functions such as data source verification, data integrity verification, and replay protection. ESP
is the protocol for packet security encapsulation. This protocol provides encryption for IP
packets.
IPSec can be used to protect one or more paths between two hosts, between two gateways, or
between a host and a gateway. IPSec provides services such as access control, packet integrity
verification, data identity verification, relay protection, and packet encryption. These services
are provided at the IP layer, and thus upper layer protocols such as Transmission Control Protocol
(TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), and Border
Gateway Protocol (BGP) can use these services.
In the UMG8900, the IPSec function can be used to ensure security of IP packet transfer between
the UMG8900 and the media gateway controller (MGC) and between the UMG8900 and the
network management device.
Service Benefits
Table 23-1 Service benefits of IPSec

IPSec This feature improves network security and This feature improves
ensure security of IP packet transfer between the network security.
UMG8900 and the MGC and between the
UMG8900 and the network management device.
23.2 Availability of IPSec

Required NEs
Table 23-2 Required NEs for IPSec

Feature Required NE
IPSec MGW and MGC

Version Support
Table 23-3 Versions supporting IPSec

IPSec R002 and later
23.3 Principle and Flow of IPSec

This section describes the implementation principles and service flow of IPSec.
l IPSec
The IP Security (IPSec) protocol family is a series of protocols defined by the Internet
Engineering Task Force (IETF). It provides IP data packets with high-quality,
interoperable, and cryptology-based security. Devices encrypt and verify the data source
on the IP layer. Thus, only confidential, complete, and reliable data packets are transmitted
on the network.
– Confidentiality: The user data is encrypted and transmitted in the encrypted text format.
– Data integrity: The received data is verified to check if the packet is changed.
– Data authentication: The data source is verified to ensure that the data is from the
authentic sender.
– Anti-replay: Malicious users are prevented from attacking the network by re-sending
captured data packets. That is, the receiver rejects existing or overlapped data packets.
With the Authentication Header (AH) and Encapsulating Security Payload (ESP) security
protocols, IPSec can solve the security concerns.
– AH is the protocol for packet header verification. It provides functions such as data
source verification, data integrity check, and replay protection. AH, however, does not
encrypt the protected data packets.
– ESP is the protocol for encapsulation security load. In addition to all the functions
provided by AH, except that the IP packet header is not included in the data integrity
check by the ESP protocol, ESP supports encryption of IP packets.
l Security association
The security association (SA) is the basis as well as the essence of IPSec. The SA determines
certain elements between the communication peers, including the protocol (AH, ESP, or
both) that is used to protect the data packet security, protocol conversion mode (transport
mode or tunnel mode), encryption algorithm (DES or 3DES), shared key of the protected
data in the specific flow, and lifetime of the key.
The SA is unidirectional. Bidirectional communication between two peers requires at least
two SAs for security protection on data flows in the two directions. In addition, to use both
AH and ESP to protect the data flows between peers, two SAs are required. One SA is used
for AH, and the other for ESP.

The SA is uniquely identified by a triplet of the following: security parameter index (SPI),
destination IP address, and security protocol ID (AH or ESP). The SPI is a 32-bit value
generated to uniquely identify an SA. The SPI is carried in the AH and ESP headers for
transmission.
The SA has a life cycle. The life cycle is calculated in two modes:
– Limited by time: updated at a specified interval
– Limited by traffic: updated after specified data flows (bytes) are transmitted
l Packet encapsulation mode
There are two packet encapsulation modes in the IPSec protocol: transport mode and tunnel
mode.
– Transport mode: AH or ESP is inserted in the back side of the IP packet header but in
front of all the transmission layer protocols, or in front of all other IPSec protocols.
– Tunnel mode: AH or ESP is inserted in front of the original IP packet header. A new
IP packet header is generated in front of the AH or ESP.
The following takes Transmission Control Protocol (TCP) as an example to illustrate the
data encapsulation format in transport mode and tunnel mode when different security
protocols are used. Figure 23-1 shows the data encapsulation formats in different security
protocols in the two modes.
Figure 23-1 Data encapsulation formats in different security protocols
The transport mode mainly differs from the tunnel mode in networking applications. The
transport mode is normally used for end-to-end IPSec protection. The tunnel mode can be
used for end-to-end protection or protection of certain segment from one end to the other.
The tunnel mode occupies more bandwidth due to an extra IP packet header.
l Authentication algorithm
Both AH and ESP can authenticate the integrity of an IP packet to judge whether the packet
is changed during transmission. The authentication algorithm is carried out through the
hash function. The hash function is an algorithm that does not limit the length of the entered
messages and can output messages of a specific length. The output is called message digest.
The IPSec peers calculate the digest. If both digests are the same, it indicates that the packet
is intact. Two algorithms are used for IPSec authentication:
– MD5: A message of any length is entered and a 128-bit message digest is generated.
– SHA-1: A message of less than 2n(n=64) bits is entered and a 160-bit message digest
is generated.
The SHA-1 digest is longer than the MD5 digest. Thus, the SHA-1 is safer than MD5.

l Encryption algorithm
ESP can encrypt the IP packets to prevent the contents of the packets from being intercepted.
The encryption algorithm is carried out by the symmetrical key system. This system
encrypts and decrypts data with the same key. IPSec uses two types of encryption
algorithms:
– DES: encrypting a 64-bit plain text block by using a 56-bit key
– 3DES: encrypting a plain text by using three 56-bit DES keys (168 bits)
The 3DES is much safer than the DES. The encryption speed of the 3DES, however, is
slower.
l IKE
You can set the SA of IPSec manually. When there are more network nodes, manual
configuration is difficult to implement. It is also difficult to ensure security. In this case,
the Internet Key Exchange (IKE) protocol is required to automatically set up the SA and
exchange the key.
The IKE protocol is built upon the framework that is defined in the Internet Security
Association and Key Management Protocol (ISAKMP). The IKE protocol can provide
automatic negotiation exchange key and establish an SA for the IPSec protocol, simplifying
use and management of the IPSec protocol.
IKE has a set of self-protection mechanism. On unsecured networks it can perform the
following: key distribution, ID authentication, and IPSec SA establishment.
IKE performs key negotiation and sets up SA for IPSec at two stages. At the first stage, a
channel with ID authentication and security protection is set up between the communication
parties. At this stage, an ISAKMP SA (also called the IKE SA) is set up for the exchange.
At the second stage, the security channel set up at the first stage is used to negotiate the
security service for IPSec, that is, to negotiate the specific SA for IPSec and set up the
IPSec SA. The IPSec SA is used for the final secured transmission of the IP data.
The self-protection mechanism of IKE is realized by combining the Diffie-Hellman
exchange algorithm, cookie exchange, and forcible authentication technology.
The Diffie-Hellman exchange is a public key encryption mechanism. The basic rule is to
generate the shared key for the communication parties through algorithm without key
transfer.
In the Diffie-Hellman algorithm, the communication parties must exchange the public
information first. Each party combines the public information about the other party and its
own secret information to calculate a shared secret value. This secret value serves as a
session key or is used to generate a session key.
23.4 Configuring IPSec


Figure 23-2 shows the index mapping of the configuration command parameters of the IP
Security (IPSec) protocol.

Figure 23-2 Index mapping of main parameters in IPSec configuration
Procedure
Step 1 Run ADD EACL to add an extended access control list (ACL) rule.
Step 2 Run ADD ISTM to add an IPSec transform mode.
Step 3 Run ADD ISSP to add an IPSec security policy.
Step 4 Run SET IPIFSPG to set an IPSec security policy group of the interface.
----End
Example
ADD EACL: NUM=100, RULE=PERMIT, PROT=TCP, SIP="192.168.0.0", SRMSK="0.0.0.255",
SOP=EQ, SP1=20, DIP="202.118.0.0", DRMSK="0.0.0.255", LOG=YES, TIME="TILL2003";
ADD ISTM: ISTMN="mode1", PROT=ESP, AM=TRANSPORT, ESPA=SHA1, ESPE=TripleDES;

ADD ISSP: ISSPGN="isspg1", NUM=1, ISTMN="istm1", LIP="1.1.1.1", PIP="2.2.2.2",

ACL=100, TYPE=MANUAL, AIS=256, AIKF=STRING, AISK="KEY", AOS=256, AOKF=HEX,
AOHK="00112233445566778899aabbccddeeff";
SET IPIFSPG: BT=HRB, BN=0, IFT=ETH, IFN=0, ENABLE=YES, ISSPGN="d";
23.5 Protocol and Specification of IPSec

Table 23-4 Compliance protocols and specifications of IPSec

IPSec RFC1321
RFC1828
RFC1829
RFC2104
RFC2401
RFC2402
RFC2403
RFC2404
RFC2406

Feature Description 24 SSH
24 SSH
About This Chapter
protocols and specifications of secure shell (SSH).
24.1 Overview of SSH

24.2 Availability of SSH
24.3 Configuring SSH
This section describes the operation for enabling and maintaining this feature.
24.4 Protocol and Specification of SSH

24 SSH Feature Description
24.1 Overview of SSH

Feature Definition
Secure shell (SSH) is a secure remote login protocol developed based on Telnet. Data
transmission between the local maintenance terminal (LMT) and the network element (NE) is
carried over SSH. This provides a secure transmission mode. At present, the UMG8900 supports
connection with the putty, OpenSSH, and Huawei SSH client. The putty and OpenSSH are two
types of widely-used open SSH clients.
Service Benefits
Table 24-1 Service benefits of SSH

Feature For Carriers For Device Suppliers
Secure shell (SSH) This feature realizes This feature enables the device
secure login and suppliers to provide functions badly
maintenance of the needed by the carriers and users,
UMG8900, enhancing catch up with industrial mainstream
security for device functions, produce new selling
operation and points, and meet the bidding
maintenance. requirements of key operators on
system maintenance security.
Table 24-2 Function restrictions of SSH

SSH This feature supports connection with up to five SSH clients at the
same time.
24.2 Availability of SSH


Required NEs
Table 24-3 Required NEs for SSH

Feature Required NE
SSH MGW and SSH client
Version Support
Table 24-4 Versions supporting SSH

SSH R006 and later
24.3 Configuring SSH

Context
To connect the Huawei I3SAFE SSH client and the UMG8900, perform the following steps:
Procedure
Step 1 Generate the public key file of the RSA authentication client.
1. Start the Huawei I3SAFE SSH client, and then click Key Generation. See the following
figure.
2. A window is displayed.

Click Next.
3. Set the key type to RSA, and the key length to 1024 bits. At present, the secure shell (SSH)
server of the UMG8900 supports only the RSA key of 1024, 2048, and 4096 bits. Click
Next. See the following figure.
4. Enter the passphrase and prompt for protecting the key file. Then, click Next. See the
following figure.

5. Move the cursor in the following window until the process is complete. Then, click Next.
See the following figure.
6. Select a format for the public key file, and then click Save Key Pair. Enter a key pair name,
and then click Save. At present, the UMG8900 SSH server supports the public key files of
the open SSH and putty formats.

Assume that the name of the public key file is id_rsa.pub, and name of the private key file
is id_rsa.pvt.
Step 2 Upload the public key file of the RSA authentication client and set an account for the SSH user.
Through the File Transfer Protocol (FTP), upload the public key file id_rsa.pub to the hard disk
of the OMU on the UMG8900 connected to the client through SSH. The public key file can be
saved in any valid path. Assume that the file is uploaded to c:/bam/.
Configure the SSH user on the UMG8900. Start the local maintenance terminal (LMT), and then
log in to the UMG8900 through the LMT. Run SET SSHOP to configure the admin user or
other valid local users. Set SSH User Link Type to SSH AND SFTP USER, Authentication
Type to RSA or PASSWORD, RSA Authentication Public Key File to c:/bam/id_rsa.pub,
SFTP Login Directory to c:/, and SFTP Right for SSH FTP (SFTP) operations to FULL. See
the following figure.
Step 3 Configure the SSH server of the UMG8900.

Run SET SSHSRV. See the following figure. The parameters can be set based on actual
conditions.

Step 4 Set the SSH connection.

Run SET TEOV to set the timeout interval during which no data is transmitted over the SSH
connection. When the duration during which no data is transmitted over the SSH connection
exceeds the timeout interval, the UMG8900 disconnects the SSH connection. Set the timeout
interval to 30 minutes. See the following figure.
Step 5 Add configuration items.

1. Add configuration items for the UMG8900 to be connected on the I3SAFE SSH client. To
start the I3SAFE SSH client on the PC, click the configuration button on the toolbar. See
the following figure.
2. A window for configuration is displayed. Select the Profile Management tab page. Click
Add Profile. See the following figure.

3. The Add New Profile window is displayed. See the following figure. The IP address of
the target server is the maintenance IP address of the UMG8900 to be connected. Assume
that the IP address is 10.110.49.6, and the user name is the SSH user name set with SET
SSHOP on the UMG8900 to be connected. Here, the user name is admin. Click OK.
4. Set the authentication mode. The authentication mode must match the authentication mode
set with SET SSHOP on the UMG8900. The authentication mode is set to ALL with SET
SSHOP in the preceding step. Thus, you can select either Public Key Authentication or
Password Authentication, or select both parameter values. If both Public Key
Authentication and Password Authentication are selected, the RSA authentication mode
is used by preference. If the RSA authentication fails, the PASSWORD authentication
mode is used. The authentication succeeds when one of these modes succeeds. Select the
RSA authentication mode. See the following figure. Click Properties.

5. The Profile Public Key Authentication dialog box is displayed. Click Browse... to view
the private key file id_rsa.pvt. Enter the password in Pass phrase for protecting the private
key file, and then click OK.
6. Select the LMT Proxy tab page, and then click the Add button. See the following figure.

7. The Add LMT Listener dialog box is displayed. Set the parameters according to the
following figure. Click OK.
8. Select port 6006, and then click Edit. See the following figure.

9. Deselect Text port, and then click OK. See the following figure.
10. Select the Mapping tab page, and then click Add. See the following figure.

11. The Add LMT Mapping dialog box is displayed. Enter the maintenance IP address of the
UMG8900 to be connected and select the related configuration items of the SSH
connection. Click OK. See the following figure.
12. Select the Connection tab page. Set the parameters according to the following figure. Click
OK.

The configuration of the I3SAFE SSH client is complete.
Step 6 Click Connect on the toolbar of the I3SAFE SSH client. See the following figure.
Step 7 The Connect - Server Profile dialog box is displayed. Select the configuration items for the
UMG8900 to be connected, and then click Connect. See the following figure.
Step 8 The UMG8900 is successfully connected to the client. See the following figure.

Step 9 You can run man-machine language (MML) commands. Start the LMT on the PC. Set the
parameters according to the following figure. Click Login. Then, the data of the LMT can be
transmitted through the SSH connection. The IP address of the proxy server is the IP address of
the PC where the I3SAFE SSH client is installed.
----End
24.4 Protocol and Specification of SSH

Table 24-5 Compliance protocols and specifications of SSH

SSH SSH 2.0

Feature Description 25 Operation and Maintenance
25 Operation and Maintenance
About This Chapter
This chapter provides the definition and describes the required network elements (NEs), and
operation of operation and maintenance.
25.1 Overview of Operation and Maintenance

25.2 Availability of Operation and Maintenance
25.3 Operation of Operation and Maintenance
This section describes the operation for using this feature.

25 Operation and Maintenance Feature Description
25.1 Overview of Operation and Maintenance

Feature Definition
As the management center of UMG8900, the operation and maintenance system provides system
management, configuration management, maintenance management, alarm management,
performance management, test management, equipment archive management, trace
management, and return code management.
Service Benefits
Table 25-1 Service benefits of operation and maintenance
Operation and This feature enables control and Not involved

maintenance management on the UMG8900 and
improves operability and maintainability.
25.2 Availability of Operation and Maintenance

Required NEs
Table 25-2 Required NEs for operation and maintenance
Feature Required NE
Operation and maintenance MGW
Version Support
Table 25-3 Versions supporting operation and maintenance
Operation and maintenance V100R002 and later

25.3 Operation of Operation and Maintenance

This section describes the operation for using this feature.
25.3.1 Fault Management

This section describes the operation of fault management.
25.3.2 Configuration Management
This section describes the operation of configuration management.
25.3.3 Performance Management
This section describes the operation of performance management.
25.3.4 Security Management
This section describes the operation of security management.
25.3.5 Device Management
This section describes the operation of device management.
25.3.1 Fault Management

This section describes the operation of fault management.
Context
This section describes the operations of alarm and trace management.
Procedure
l Browse the alarm information.
1. Log in to the local maintenance terminal (LMT). Choose Fault Management >
Browse Alarm, or directly click the icon , to browse alarms. By default, the
Fault and Event browse windows appear. Fault alarms and event alarms are listed in
the two windows.
2. Double-click an alarm. The Alarm Detailed Information dialog box appears. This
dialog box lists the details of the alarm.
3. Click More on the Alarm Detailed Information window to display the online help
of the alarm. The online help includes the detailed explanation of the alarm and
suggestions to clear the alarm.
On the Alarm Detailed Information window, click Previous or Next to go to the

detailed information window of the previous or next alarm.
NOTE
Run LST ALMAF to browse active alarms.

l Query alarm logs.
1. Log in to the LMT, and then choose Fault Management > Query Alarm Log. A
dialog box appears.

2. Specify the query conditions in the related tab of the dialog box.
On the General Option tab, you can set the query conditions based on Alarm Type,
Alarm Severity, Alarm Time or Return Amount. On the Detailed Option tab, you can
set the query conditions based on Event Type, Alarm ID or Alarm Serial Number.
NOTE
l Logical AND relation exists between multiple query conditions.

l The Return Amount in the General Option tab contains the maximum number of alarms
in the query result. If the return amount is set to 80, only the latest 80 alarms out of 100
alarms that meet the conditions are returned.
3. Click OK. Then, alarm logs that meet the query conditions are displayed in the dialog
box. Double-click an alarm. The Alarm Detailed Information dialog box appears.
This dialog box lists the details of the alarm.
Click More on the Alarm Detailed Information window to display the online help
of the alarm. The online help includes the detailed explanation of the alarm and
suggestions to clear the alarm.
On the Alarm Detailed Information window, click Previous or Next to go to the

detailed information window of the previous or next alarm.
NOTE
Run LST ALMLOG to query the alarm logs.

l Create trace tasks.
1. Log in to the LMT. For example, to create an Address Resolution Protocol (ARP)
interface trace task, select the Maintenance tab in the man-machine language (MML)
navigation window. In the tab, choose Service > Trace Management > IP Trace >
ARP interface trace.
2. Double-click the ARP interface trace node. The Create ARP interface trace dialog
box appears.

Click Select in the Create ARP interface trace dialog box. The board that meets
the needs dialog box appears.
In the dialog box, choose the board that meets the conditions of the created trace task.
By choosing the board, you can easily add the board to the trace task. You need not
to fill in the frame number and slot number.
NOTE
You can also create a trace task through the device panel. For example, to create an ARP
interface trace task for the Internet Protocol (IP) interface of the , and then choose Create ARP
interface trace in the shortcut menu.
3. In the Create ARP interface trace dialog box, specify the parameters required for
creating the trace task. Select Set auto file. The system automatically saves the trace
results to the installation directory D:\HWLMT\client\output\main\UMG8900
\UMG8900Vx00R00xCxx\trace with the file name localhost_ARP interface
trace_YYYY-MM-DD-HH-mm-SS.tmf.
4. Click OK to submit the trace task creation request to the BAM. The real-time trace
data display window appears on the right side of the navigation window. By now, a
trace task is successfully created.
5. Choose Set Trace Time in the Create ARP interface trace dialog box. Then, specify
the expected end time of the trace task. For example, set Stop Time to 2006-03-06
15:00. It indicates that the trace task ends at the time, and the system automatically
stops the trace task. Invalid Task appears in the trace task window.
----End
25.3.2 Configuration Management

This section describes the operation of configuration management.
Context
The data in the UMG8900 can be configured through the man-machine language (MML)
commands, device panel, and execution of the data configuration script. These configuration
methods are completed through the local maintenance terminal (LMT). Before configuration,
you need to log in to the back administration module (BAM) through the LMT Client. The
Internet Protocol (IP) address of the BAM is the IP address of the network port of the operation
and maintenance center (OMC).
Procedure
l Using MML commands for data configuration
The MML command is a common configuration method provided by the
telecommunication device suppliers at present. The LMT supports the MML command line
mode. Figure 25-1 shows the MML command input window.

Figure 25-1 MML command input window
Table 25-4 lists the meaning of the four shortcut icons.
Table 25-4 Meaning of shortcut icons in the command input area

Shortcut Icon Meaning
It displays the parameter input interface. You can also press

Enter after entering a command.
It runs a command. You can also press F9.
It selects the next command. You can also press F8.
It selects the previous command. You can also press F7.
When using MML commands for data configuration, pay attention to the following:
– The parameters in red are mandatory for a command. You must set these parameters;
otherwise, execution of a command fails. For example, Frame No., Frame Ver, Frame
Type, Cabinet No., and Location in Cabinet in Figure 25-1 are mandatory.
– The parameters in black are normally optional for a command. You may specify values
for these parameters or leave them unset. They do not affect the execution of a command.
For example, parameters Frame Name and Frame Description in Figure 25-1 are
optional.
– To reduce the workload for data configuration, the system presets some parameters that
are fixed and need no frequent change to the default values. You can decide whether to
change these parameters based on actual conditions.

– If you are not aware of the default value or value range of a parameter, you can point
the arrow of the mouse to the input box of the parameter and in about one second, the
system displays the default value or value range of the parameter in a small pane.
– For functions, notes, parameter description, and examples of MML commands, see the
MML online help.
l Methods of using the device panel
The device panel is mainly used to configure and query the hardware data, such as frames
and boards. It provides the direct view. For example, during configuration of a board, you
can directly view the information such as the boards in the system and board status.
The LMT provides the device panel. For how to use the device panel, see the online help
in the LMT.
l Methods of using data scripts
CAUTION
As the data scripts are complied by the data center under the experimental environment,
they may not be fully suitable for deployment. You may need to change the data based on
the actual needs for the deployment.
The data script files are mainly used for data configuration operations in device deployment,
system capacity expansion, software upgrade, and daily maintenance. The main purpose
of these files is to improve efficiency and reduce data configuration errors.
The data configuration script file is a .txt file consisting of multiple MML commands and
scripts. On the LMT, choose System > Batch Commands. A dialog box appears. Select
the Immediate Batch Command or Timing Batch Command tab. Set the parameters for
batch processing and select an available data script in .txt format. The system executes the
scripts one by one at once or at a specified time point based on the setting.
----End
25.3.3 Performance Management

This section describes the operation of performance management.
Procedure
l Create a measurement task.
1. Log in to the UMG8900 performance management system. Select the Task tab in the
navigation window.
2. Choose Task > Create a Task, or right-click the mouse in the navigation window
and select Create a Task. The Create task dialog box appears.
3. Specify the basic information about the task in the Create task dialog box. Parameters
with the * mark are mandatory.

There are three output modes.

– Output by perf port: After the task is created, only the measurement result is
reported to the network management system (NMS) but not stored.
– Output by perf file: The measurement result is saved to c:\bam\data\prf in the
OMU file system. You can run LST PERFRST to query the measurement result.
If Output by perf file is in the OMU file system with disk D, the measurement
result is saved to d:\bam\data\prf.
– Output by perf file and port: The measurement result is reported to the NMS and
stored in the back administration module (BAM) file system.
NOTE
l If the system does not provide available measurement objects for the selected measurement
unit, the measurement task cannot be created. The system displays a prompt box and
requires you to change the measurement unit.
l You can use the defined task template to simplify the task creation.
4. Select the Item information tab. The Optional items box lists all the measurement
items of the selected measurement unit. Double-click the desired items or click
after selecting them to make them listed in the Selected items box.
NOTE
You can use defined item templates to select measurement items.

5. Select the Object information tab. The Optional objects box lists all the
measurement objects of the selected measurement unit. Double-click the desired
measurement objects or click after selecting them to make them listed in the
Selected objects box.

NOTE
You can use defined object templates to select measurement objects.

6. Select Time information tab, and specify the time information about the task.
The time information about a task includes:
– Task type
In the Task type area, specify the task type, and start and end time. Begin and
End define when a task is started and ended. If the task type is set to Semi-
permanent, the task has only the start time and no end time. If it is set to Limited
period, the task has both the start time and end time. If it is set to Permanent, the
task does not stop until being deleted.
– Time type
Enter the information in Time information pane. Options include Stat every
day, Stat every week, and Stat every month.
For the latter two options, you also need to click Set to specify the days in a week
or month for measurement.

– Measure period
Set the measurement period in the Time information area. The time period
specifies how often the measure result is exported. Period includes six options:
1Minute, 5Minutes, 15Minutes, 30Minutes, 60Minutes, and 1440Minutes.
– Segment
Three segments can be set in the Segment area. Segment decides on which
segments the measurement is carried out.
NOTE
l Segments cannot overlap. The start time of segment 2 must be later than the end time
of segment 1, and the start time of segment 3 must be later than the end time of segment
2.
l You can use defined time templates to specify the measurement time.
7. Select Threshold information tab. Set the thresholds for measurement items that are
selected in the Index information tab at all alarm levels.
To set thresholds for an item, click the item line, and then specify values under Thrd
Low and Thrd Up. You can select an unwanted list item and click Delete to delete
it. You can also select the line, and click Delete. See the following figure.
NOTE
l Only original items rather than custom items can be set with thresholds.
l For a measurement item of percentage type, CPU utilization, for example, its thresholds
must be set within the range from 0 to 100.
8. Click OK to send the task creation request to the BAM. After a measurement task is
successfully created, the task is listed under the task list navigation tree.
l Modify a measurement task.
1. Log in to the UMG8900 performance management system. Select Task tab in the
navigation window.
2. Select the task to be modified in the task list navigation tree. Choose Task > Modify
the Task, or right-click the desired task and then select Modify the Task. The Modify
task dialog box appears.

NOTE
Only the tasks in the suspended state can be modified. If the status of the task is Ready, you
need to suspend it first.
3. Modify the parameters of the task. Click OK to send the task modification request to
the BAM. Query the task (see Querying a Measurement Task) to make sure that its
parameters are modified.
NOTE
After the parameters are modified, activate the suspended task to resume the task.
l Query a measurement task.
navigation window.
2. Double-click the task to be queried in the task list navigation tree to send the task
query request to the BAM. When the command is executed successfully, the details
of the task appear in the task detailed information window. See the following figure.
NOTE
Select the task to be queried in the task list navigation tree. Choose Task > Show Task's
Information, or right-click the desired task and then select Show Task's Information.
----End
Creating a Task for Context Measurement on the CMU

Task description
l Measurement object: virtual media gateway (VMGW) 1
l Measurement items: the number of contexts created, number of contexts successfully
released, duration for contexts, maximum number of contexts, and average number of
contexts
l Measurement time: 2005-02-01 to 2005-08-01. Measurement results are output once every
day.

l Measurement results: The results are output by file and port.

Steps
navigation window. Choose Task > Create a Task. The Create task dialog box appears.
2. Specify the parameters. See the following figure.
3. In the dialog box, select the Item information tab. Double-click the following items in the
optional item list and move them to the Selected items list: Total of Contexts Created
Newly, Total of Successful Contexts Released, Total Duration(s), Peak of the Number
of Context, and Average of the Number of Context.
4. Select the Object information tab. Double-click VMGW ID=1 in the Optional objects
list to move it to the Selected objects list. See the following figure.
5. Select the Time information tab, and then set the task information. See the following
figure.

6. Click OK to send the task creation request to the BAM. If the task is created successfully,
the task named VMGW1 Context management (Ready) appears in the task list
navigation tree. See the following figure.
Creating a Task for CPU Utilization Measurement

Task description
l Measurement object: PPU and OMU with the board group number as 0
l Measurement items: Average occupied rate of CPU(%), Duration of CPU Overload
(s), Number of CPU Overload, Duration of CPU Congestion(s), and Number of CPU
Congestion. If the value of Average occupied rate of CPU(%) is between 85% and 95%,
a major alarm is issued. If it is between 95% and 100%, a critical alarm is issued.
l Measurement time: The task is carried out from 9:00 to 16:00, from Monday to Friday, and
from 2005-02-01 to 2005-08-01. Measurement results are output every hour. The preceding
time information is set into a time template. You can use the time template when you create
a measurement task.
l Measurement results: The results are output by file and port.
Steps
Task description
l Measure object: PPU 0 and OMU 0.

l Measure items: average occupied rate of CPU, duration of CPU overload, number of CPU
overload, duration of CPU congestion and number of CPU congestion. If the average
occupied rate of CPU is between 85% and 95%, a major alarm is issued. If between 95%
and 100%, a critical alarm is issued.

l Measure time: The task is carried out from 9:00 to 16:00, from Monday to Friday, and from
2005-02-01 to 2005-08-01. Measure results are output every hour. The above time
information is set into a time template. You can use the time template when you create a
measure task.
l Measure results: The results are output by file and port.
Steps
1. Log in to the UMG8900 Performance Management System, and then click the Templet
tab in the bottom navigation window. Choose Templet > Create Time Templet, and the
Create time templet dialog box is displayed.
2. Enter parameter information for the time template. See the following figure.
3. Click OK to send the time templet creation request to the BAM. If it is created successfully,
a time template named Time templet for CPU usage is displayed in the template navigation
tree.
4. Click the Task tab in the bottom navigation window. Choose Task Management > Create
a Task or right-click and select Create a Task. The Create Task dialog box is displayed.
5. Specify the parameters. See the following figure.

6. Click the Item Information tab, and double-click the following items in the Optional
Items list to move them to the Selected Items list: Average occupied rate of CPU(%),
Duration of CPU Overload(s), Number of CPU Overload, Duration of CPU congestion
(s), Number of CPU congestion, and Max occupied rate of CPU(%).
7. Click the Object Information tab, and double-click the following objects in the Optional
Objects list to move them to the Selected Objects list: Board frame and slot No. = CMU:
31:0, Board frame and slot No. = CMU:30:0, and Board frame and slot No. = OMU:
0:1.
8. Click the Time Information tab. Then set the time templet to Time templet for CPU
usage. This time template is used to specify the time parameters.

9. Click the Threshold Information tab. Select the line of Average CPU occupied rate and
Critical alarm level, and then enter 95 and 100 under the Threshold Lower and Threshold
Upper lists. In the same means, set thresholds for major alarms to 85 and 95.
10. Click OK to send the task creation request to the BAM. If it is created, a task named CPU
occupation rate measure is displayed in the task navigation tree.
25.3.4 Security Management

This section describes the operation of security management.
Context
The local maintenance terminal (LMT) is a multi-user system. It performs the hierarchical
authority management on the operator (user) to ensure system security.

l The system administrator has the authority to add or delete the account of an ordinary
operator, but cannot delete the admin account.
l The system administrator can modify the operation time limit of an ordinary operator. The
ordinary operator can run commands authorized to them within the operation time limit.
By default, the admin account is not limited by time.
The operator can run LST CMDS to list the commands available.
A local account refers to the operation user account managed by the network element (NE). A
domain user refers to the operation user account managed by the network management system
(NMS). The domain user can log in to the system through the NE.
CAUTION
If an operator logs in to the system using the domain user account, only Change Passwordin
Authority is available.
Procedure
l Account management
1. Add an operator account.
(1) Choose Authority > Account > Add. The Operator Management dialog
box appears.
(2) In the Operator Information area, set the information about the operator.
– Account: the name of the account to be added.
– Description: the description of the account to be added.
– Definition: roles and responsibilities of the operator.
(3) Set the password of the operator.
– New Password: the password (case sensitive) of the account to be added.
– Confirm password: the password (case sensitive) set in New Password.
(4) In the Authority Limit area, select the authority for the account.
(5) Select Modify Time Limit to set the validity period of the account. You can select
Limited Date, Limited Time, or Limited Week. The operator holding the account
can log in to the system only in the validity period.
– Limited Date: The operator can log in to the system only on the specified
day.
– Limited Time: The operator can log in to the system only at the specified
time.
– Limited Week: The operator can log in to the system only in the specified
week.
(6) Specify the start time and end time for Limited Date and Limited Time.
– Start: It specifies the start time when the account takes effect. If the end time
is not specified, the account keeps valid until the administrator cancels the
account.

– End: It specifies the end time when the account becomes invalid. The operator
cannot log in to the system after the end time expires.
(7) Click OK.
CAUTION
You can also run ADD OP to add an account. After adding the account, run MOD
OP to modify the time limit of the account.
2. Delete an operator account.

(1) Choose Authority > Account > Delete. The Delete Operator dialog box
appears.
(2) Select the account to be deleted. Click Delete, or press Delete or Enter on the
keyboard.
(3) The Confirmation dialog box appears, prompting the following:
Are you sure to delete operator xxx?
(4) Click Yes.
CAUTION
l The administrator account, admin, cannot be deleted.
l You can also run RMV OP to delete an account.
3. Modify an operator account.

(1) Choose Authority > Account > Modify. The Modify Operator dialog box
appears.

(2) Select the account to be modified. Click Modify or double-click the account. The
Operator Management dialog box appears.
(3) Modify the password, authority limit, and time limit.
(4) Click OK.
CAUTION
l Accounts with the administrator or operator authority cannot be modified.
l You can also run MOD OP to modify an account.
l Command group management

1. Modify a command group.
(1) Choose Authority > Command Group > Modify Command Group. The
Modify Command Group dialog box appears.
(2) In the Command Group drop-down list, select the command group to be
modified. The system displays all the commands in this command group.
(3) Modify the commands in the command group. That is, clear the selected
commands and select new commands.
(4) You can enter the desired command in Search Command, and click Search or
press Enter on the keyboard to search the command.
NOTE
The command search is not case sensitive. If the command cannot be found, the
Prompt dialog box is displayed to indicate the search failure. The command search
supports cyclic search. That is, if the current command is the last command meeting the
search condition, you can click Search to return to the first command meeting the search
condition.
(5) Click OK.

CAUTION
l You can run ADD CCG to add commands to the command group.
l You can run RMV CCG to delete command groups and LST CCG to list
command groups.
2. Set the command group name.

(1) Choose Authority > Command Group > Set Command Group Name. The
Set Command Group Name dialog box appears.
(2) In the Command Group drop-down list, select the command group whose name
is to be set.
(3) In Command Group Name, enter the name of the command group.
(4) Click Set.
CAUTION
l Only the system administrator can set the command group name. When Command
Group Name is null or a space is entered, it means that the command group name
is deleted or the command group name is set to null.
l The system administrator can also run SET CCGN to set the command group
name.
l Password policy setting

1. Choose Authority > Password Policy Setting. The Password Policy Setting dialog
box appears.
2. Set the minimum length of the password.
3. Select the types of characters for password complexity.
4. Click OK.

CAUTION
l Only admin can set the password policy.
l For certain NEs, Special character can be selected in Password Complexity.
Table 25-5 Parameter description

Parameter Value Range Remark
Minimum password 6~32 The default value is 8. You can set

length the minimum password length
based on the requirement.
Password You can select letters in You can set the complexity of the
complexity the upper or lower case, password, including the character
and digits. types required in the password. For
certain NEs, you can select special
character for this parameter.
l Password changing
The system requires the operator to change the login password in the following cases:
1. When the operator logs in to the system as a domain user for the first time, the system
displays the Change Password dialog box, asking the operator to change the
password.
2. After the password of the domain user is re-set by the administrator, the system asks
the operator to change the password when the domain user logs in to the system for
the first time.
3. If the password of the domain user has reached the preset prompting time during
system login, the system reminds the user to change the password in time.
4. If the password of the domain user reaches the maximum validity period when the
user logs in to the system, the Change Password dialog box is displayed, asking the
user to change the password.
In the preceding cases, the system requires the operator to change the password during
system login.
1. Choose Authority > Change Password. The Change Password dialog box appears.

2. The system displays the operator name by default.

3. Enter the old password, new password, and confirm password.
4. Click OK.
CAUTION
l Ordinary operators (not the system administrator) can change their own passwords only.
If an operator forgets the old password, the operator can contact the system administrator
for a new password.
l After entering the old password and the new password in the Change Passworddialog
box displayed, click OK to validate the new password; otherwise, click Cancel to return
to the User Login dialog box.
l The domain user can modify the account password after system login by choosing
Authority > Change Password.
----End
25.3.5 Device Management

This section describes the operation of device management.
Procedure
l Frame management
Double-click a node of a rack in the navigation tree in the device panel. All the frames in
the cabinet are displayed in the right part of the Device Management window. This part
is a virtual rack, or virtual device panel window. The black number on the left side in each
frame is the number of the frame. The system provides users with functions of frame
management, including adding a frame, removing a frame, modifying a frame, viewing a
frame, opening an emulated frame, and displaying the status of a board in the frame.
Functions of frame management are detailed as follows.
1. Adding a frame
(1) In the virtual panel in the right section of the Device Management window, right-
click a blank space in the frame.
(2) Select Add Frame in the shortcut menu and enter a frame number.

(3) Click OK to add a new frame.
You can also run ADD FRM to add a frame.

2. Removing a frame
(1) In the virtual panel in the right section of the Device Management window,
right-click the pane of an existing frame.
(2) Select Remove Frame in the shortcut menu. A window appears for you to
confirm the operation.
(3) Click OK.
You can also run RMV FRM to remove a frame.
CAUTION
Remove all the boards, except the boards added by default, from a frame before
removing the frame.
3. Modifying a frame
click the pane of an existing frame.
(2) Select Modify Frame in the shortcut menu. A window appears for you to modify
the frame.
(3) Enter the parameters of the frame to be modified. The parameters are listed in
later sections.
(4) Click OK to modify the frame.
You can also run MOD FRM to modify a frame.

4. Viewing a frame
click the pane of an existing frame.
(2) Select List Frame in the shortcut menu. A window appears. This window shows
the attributes of the frame.
You can also run LST FRM to view a frame.

5. Opening an emulated frame
(1) In the virtual panel in the right section of the Device Management window, if
the front of the rack is displayed, double-click the border of a frame to open the
front emulated frame of the frame. If the rear of the rack is displayed, double-
click the border of a frame to open the back emulated frame of the frame.
(2) In the virtual panel in the right section of the Device Management window, if
the front of the rack is displayed, double-click the blank space at the upper part
of a frame to open the back emulated frame of the frame. If the rear of the rack
is displayed, double-click the blank space at the upper part of a frame to open
the front emulated frame of the frame.

NOTE
Before the emulated frame is opened, in all the displayed frames of a rack:
l The black number in the left pane is the frame number.
l The gray part in the frame shows the temperature of the frame.
l Below the board number is the status of the fan in the frame.
6. Displaying the status of a board in the frame
In the virtual panel in the right section of the Device Management window, the status
of all boards is displayed in each frame. Different colors represent different status.
Four colors are introduced here. The meaning of different colors is also described in
the legends at the rightmost part in the Device Management window.
– Green: The board is running normally. If two boards work in master/slave mode,
the green color means that the master board is running normally.
– Light blue: The slave board is running normally.
– Red: The board is faulty.
– Gray: The slot is empty.
Table 25-6 List of frame parameters
Parameter ID Parameter Name Parameter Description
FN Frame No. It indicates the number of a new frame. It

uniquely specifies a frame. This is a
mandatory parameter. Value range: 0-29.
SHF Cabinet No. It specifies the number of a cabinet where

a defined frame is located. This is a
mandatory parameter. Value range: 0-29.
LOC Frame location It specifies the location of a frame in the

cabinet. This is a mandatory parameter.
Value: TOP, MIDDLE, and BOTTOM.
l Board management
In the navigation panel in the left pane, click the Device Panel tab to display all the racks
of the network element (NE). Double-click a node to open the rack and display the running
statuses of all the frames and boards.
The board management contains board configuration and board maintenance.
1. With the board configuration, you can add, remove, and query all types of boards
according to the actual hardware configuration.
2. With the board maintenance, you can view the specific status of a board, board version,
CPU utilization, memory utilization, and other information during operation. When a
board fails, you can reset or switch over the board.
1. Adding a board
(1) Right-click an empty slot in a frame. Select Add Board in the shortcut menu.

(2) In the displayed window, select mandatory parameters such as the board type.
Click OK to add a board in the specified position.
You can also run ADD BRD to add a board.
2. Removing a board
(1) Right-click the board in a slot of the frame.
(2) Select Remove Board in the shortcut menu. A window appears for you to
confirm the action. Click YES to remove the board.
You can also run RMV BRD to remove a board.
3. Querying the version of a board
(2) Select Query Version in the shortcut menu. A window appears. The version
information about the board is displayed, including the PCB version, BIOS level
1 version, software version, and logic version.
You can also run LST BRDVER to remove a board.
4. Querying a board
(2) Select Query Board in the shortcut menu. A window with the query result is
displayed. All the attributes of the board, including the frame number, slot
number, location, board type, module number, and slot number of the mutual-
aid board, are displayed.
You can also run LST BRD to query a board. By using different parameters, you can
view the information about multiple boards.
5. Displaying the status of a board
(2) Select Display Board Status in the shortcut menu. A window with the query
result appears. This window shows the detailed information about this board,
including the board type, board status, available memory, memory utilization,
CPU utilization, status of Ethernet port 1, status of Ethernet port 2, backup status,
physical memory size, flash memory size, time for total backup, and board bar
code.
You can also run DSP BRD to display the board information.
6. Resetting a board
CAUTION
Be cautious in using the Reset Board action.

(2) Select Reset Board in the shortcut menu. A window appears for you to confirm
the action. The window prompts that resetting the board may lead to loss of the
board data. Click OK to reset the board.
You can also run RST BRD to reset a board.

7. Switching over master and slave boards

(2) Select Swap Board in the shortcut menu. This menu item is available for boards
with the master/slave switchover function only.
(3) The system displays a window for you to confirm the action. Click OK to switch
over the master and slave boards.
You can also run SWP BRD to switch over the boards.
NOTE
When you enable this function, the UMG8900 may be affected. Use the function under
instructions of Huawei technical engineers. In addition, the function is available for master/
slave boards only.
8. Displaying CPU and memory utilization
(2) Select Query CPU in the shortcut menu.
(3) The system starts to monitor the modules and the CPU of a board.
You can also run DSP CPUR to display the CPU and memory utilization of a board.
l Port management
Through port management, you can view the status of the port on a specific board. In the
system, there are two types of ports: E1 port, and asynchronous transfer mode (ATM) and
fast Ethernet (FE) port. To manage ports on the Device Management window, open the
emulated frame. For how to open the emulated frame, see the description in Frame
Management.
1. Displaying the port status
(1) Open the emulated frame, and right-click the port on a board.
(2) Select Display Port Status in the shortcut menu. Pay attention to the availability
of the shortcut menu.
(3) A window displaying the port status appears, including the port type, port status,
and port loop type.
l UI panel management
The panel is in the Device Management part of the LMT. The panel includes frames,
boards, and legends. The panel description includes the description of the power, cabinet,
frame, board, and fan. Figure 25-2 shows the overall structure of the cabinet. The following
part describes the operations that can be viewed in the panel. For details, see Frame
Management, Board Management, Port Management, and Board Loading Process.

Figure 25-2 UI panel
1. Cabinet 2. Frame 3. Board 4. Indicator
For details, see online help on the LMT.

l Emulated frame management
The emulated frame includes the frame, board, fan frame, and interface. Double-click or
right-click the blank part of the frame to display the emulated frame. See the following
figure.

For details, see online help on the LMT.

----End

Feature Description 26 Time Localization
26 Time Localization
About This Chapter
restrictions, and operation of time localization.
26.1 Overview of Time Localization

26.2 Availability of Time Localization
26.3 Configuring the Time Localization Function

26 Time Localization Feature Description
26.1 Overview of Time Localization

Feature Definition
To meet the requirement for time localization, the UMG8900 provides the time localization
function. You can set time or daylight saving time (DST) according to the time zone where the
UMG8900 is located.
Time localization can be applied when a user logs in to the UMG8900 through the network
management system (NMS) or local maintenance terminal (LMT). This includes scenarios that
the NMS or LMT sends a man-machine language (MML) command to the UMG8900, creates
a trace task, and displays the status of the UMG8900.
Service Benefits
Table 26-1 Service benefits of time localization
Time localization This feature facilitates This feature is invisible to

management on different users.
NEs across different time
zones through one NMS, thus
reducing the number of
NMSs and maintenance staff
and saving the cost.
Table 26-2 Function restrictions of time localization
Time localization The NMS or LMT must be compatible with

the UMG8900; otherwise, the NMS or LMT
cannot resolve the packets sent by the
UMG8900.
26.2 Availability of Time Localization


Required NEs
Table 26-3 Required NEs for time localization
Feature Required NE
Time localization MGW and N2000
Version Support
Table 26-4 Versions supporting time localization
Time localization R006 and later
26.3 Configuring the Time Localization Function

Figure 26-1 shows the networking application of time localization.
Figure 26-1 Networking application

26 Time Localization Feature Description
Function Flow
Figure 26-2 shows the function flow of time localization at the man-machine language (MML)
interface.
Figure 26-2 Service flow of time localization at the MML interface
Figure 26-3 shows the function flow of time localization at the binary interface.
Figure 26-3 Service flow of time localization at the binary interface

Procedure
Step 1 Run SET TZ to set the time zone and the daylight saving time (DST).
Step 2 Run SET DSTSWT to enable reporting of the DST.
----End
Example
//Set the time zone and DST.
SET TZ: ZONET=GMT+0800, DST=YES, SM=DATE, SMONTH=MAY, SDAY=10, ST=00&00&00,
EM=DATE, EMONTH=SEP, EDAY=1, ET=00&00&00, TO=60;
//Enable the flag of reporting the DST.

SET DSTSWT: DSTSWT=YES;

Feature Description 27 Offline Test
27 Offline Test
About This Chapter
restrictions, and operation of offline test.
27.1 Overview of Offline Test

27.2 Availability of Offline Test
27.3 Operation of Offline Test

27 Offline Test Feature Description
27.1 Overview of Offline Test

Feature Definition
Offline test means to perform tests when the media gateway (MGW) is not in the registration
state.
Service Benefits
Table 27-1 Service benefits of offline test

Offline test The offline test function is used to The offline test function can
detect whether the transcoder (TC) quickly detect whether the
and echo cancellation (EC) chips are internal voice channel can be
normal in the internal simulated established and whether the
dialing test when the MGW is not in functions of the TC and EC
the registration state. Real dialing test chips are normal.
is not performed.
Basically, the offline test does not
affect the ongoing calls.
Table 27-2 Function restrictions of offline test

Offline test There are no special restrictions on the offline test function.
27.2 Availability of Offline Test

Required NEs
Table 27-3 Required NEs for offline test

Feature Required NE
Offline test Not involved

Version Support
Table 27-4 Versions supporting offline test

Offline test R005 and later
27.3 Operation of Offline Test

Context
In the call service of the UMG8900, failure occurs due to transcoder (TC) or echo cancellation
(EC) failure. The offline test of data insertion and rereading must be performed to locate the
faulty chip.
Procedure
Step 1 The time division multiplexing (TDM) terminations used in the test must be pre-configured. If
the terminations are not configured, run ADD TDMIU to add a TDM termination.
Step 2 In a TC test, the resources on the packet side are required. If the Internet Protocol (IP) bearer
resources are not configured, run the man-machine language (MML) command to configure the
IP resources.
Step 3 Run STR OLT to test the specified board or all the boards.
NOTE
l For the TC test, the board type on the packet side must be specified.
l For the test with the specified timeslot, an idle timeslot must be specified at the same time.
l For those parameters without specified values, the test path is selected in turn.

27 Offline Test Feature Description
CAUTION
l Check if the TC and EC subboards are configured. If not, CONNECT_FAULT appears in the
test result.
l For the TC test, make sure that the IP or asynchronous transfer mode (ATM) resources are
available. If no packet resources are available, Err appears in the test result.
l Make sure that the entered TDM termination is idle. If the test is performed on a timeslot
with non-idle termination, The status of timeslot X is not idle appears.
l If you conduct a test on the board of which terminations are not idle, Err appears in the test
result.
----End
Example
Specify an idle timeslot on the E32 to test if all the TCs on a certain VPU are normal. For the
meaning of each field, see the MML online help.
STR OLT: TYPE=TCTSI, CMUBN=30, TDMBTTCTSI=E32, TDMBN=0, TKNO=0, TSINO=0, RSCBT=VPU,
RSCBN=0, PKGBT=HRU, PKGBN=0;
Test if all the ECs on all the VPUs are normal.

STR OLT: TYPE=ECBRD, CMUBN=30;
Forcibly stop ongoing offline tests. This command does not have any parameters.
STP OLT
Display the result of the last offline test. This command does not have any parameters.
DSP OLTRST
The returned result is as follows:

+++ HUAWEI UMG8900
2005-10-29 19:07:57
O&M #43
%%DSP OLTRST:;%%
TEST PATH :
-----------
TestMode TDMBoardType TDMBoardNo RSCBoardType RSCBoardNo
EC E32 0 VPU 1
TEST RESULT:
------------
No. ErrorCode ErrorFrameCounter PathNo
1: OK 0 1
2: OK 0 1
3: OK 0 1
4: OK 255 1
5: CONNECT_FAULT 0 1
it shows that the result of last time outline is successful
--- END

If VOS_OK appears in the test result, it indicates that the test is successful. If the value of
ErrorFrameCounter is 0, it indicates that the EC is normal. If the value is not 0, it indicates
that the EC is faulty.

Feature Description 28 Upgrade Without Service Interruption
28 Upgrade Without Service Interruption
About This Chapter
This chapter provides the definition and describes service benefits for carriers and users, and
28.1 Overview of Upgrade Without Service Interruption

This section provides the definition and describes service benefits for carriers and users of this
feature.
28.2 Availability of Upgrade Without Service Interruption

28 Upgrade Without Service Interruption Feature Description
28.1 Overview of Upgrade Without Service Interruption

This section provides the definition and describes service benefits for carriers and users of this
feature.
Feature Definition
The without service interruption upgrade ensures that the online services are not affected during
upgrades. The period during which new users cannot access services is shorter than 10 seconds.
The main design principle is to partition the system into two independent logical subsystems
(planes) to carry services respectively. Thus, two subsystems can be upgraded separately to
ensure that at least one subsystem carries services all the time.
The without service interruption upgrade is realized through the tool for upgrade without service
interruption.
l The UMG8900 acts as an access gateway (AG).
l The UMG8900 acts as a trunk gateway (TG).
Service Benefits
Table 28-1 Service benefits of upgrade without service interruption
Upgrade without service l It helps enhance customer Not applicable.

interruption satisfaction.
l It helps reduce service loss
during upgrades.
28.2 Availability of Upgrade Without Service Interruption

Required NEs
Table 28-2 Required NEs for upgrade without service interruption
Feature Required NE
Upgrade without service interruption MGW

Feature Description 28 Upgrade Without Service Interruption

Feature Version
Upgrade without service interruption V200R008C01 and later

Feature Description 29 Basic BootROM Online Upgrade
29 Basic BootROM Online Upgrade
About This Chapter
restrictions, and operation of basic BootBOM online upgrade.
29.1 Overview of Basic BootROM Online Upgrade
29.2 Availability of Basic BootROM Online Upgrade
29.3 Operation of Basic BootROM Online Upgrade

29 Basic BootROM Online Upgrade Feature Description
29.1 Overview of Basic BootROM Online Upgrade

Feature Definition
In all the networking applications, the media gateway (MGW) supports the basic BootROM
online upgrade of the boards.
Online upgrade means to upgrade the board when it is running normally. The following protocols
are involved:
l FTP
This protocol is used to transfer the basic BootROM file from the version server to the back
administration module (BAM) of MGW.
l Private loading protocol on the IPC channel in the MGW
This protocol is used to transfer the data of the basic BootROM file from the BAM to the
board RAM.
The basic BootROM software provided by the board support package (BSP) is written to
the operation interface of the read-only memory (ROM) from the memory.
Online upgrade includes local and remote upgrade. It can be performed through the man-machine
language (MML) command. The data is transmitted from the file server to the BAM of the
UMG8900 by the File Transfer Protocol (FTP). Thus, remote upgrade can be achieved.
Online upgrade means to upgrade the board when it is running normally. If the board is not
running normally, the online upgrade cannot be achieved.
The boards that support the basic BootROM online upgrade are as follows: UG01OMB,
UG01HRC, UG01VPD, UG02E32, UG01ESU, UG01OMD, UG01TNC, UG01TNB,
UG03CLK, UG01PIE, UG02ASU, UG01MPB, and UG02HRU. All the listed boards are logical
type names. In actual applications, M or F is added in front of the name, for example,
UG01MOMB or UG01FOMB. Table 29-1 lists the corresponding printed circuit board (PCB)
versions and logical application relations if the boards support the basic BootROM online
upgrade.
Table 29-1 Board PCB versions and corresponding logical application relations
Board Type PCB Version (Applicable to Logical Version (CPLD/

(Logical) the Specific Version and Later EPLD)
Versions)
OMB UG01 PCB-VER.B EPLD-013
TNB UG01 PCB-no restriction EPLD-201
HRC UG01 PCB-VER.B CPLD-104
VPD UG01 PCB-VER.C CPLD-104
OMD UG01 PCB-VER.B (U147)0101

Board Type PCB Version (Applicable to Logical Version (CPLD/

(Logical) the Specific Version and Later EPLD)
Versions)
TNC UG01 PCB-VER.B CPLD-106
E32 UG01 PCB-VER.B EPLD-013
ESU UG01 PCB-VER.C EPLD-103
CLK UG03 PCB-no restriction No restriction
PIE UG01 PCB A 001
ASU UG02 PCB-no restriction No restriction
MPB UG01 PCB-VER.B EPLD-013
HRU UG02 PCB-no restriction No restriction
Service Benefits
Table 29-2 Service benefits of basic BootROM online upgrade
Feature For Carriers Benefits for Users
Basic BootROM online This feature can effectively This function is invisible to
upgrade reduce the maintenance cost. the users.
l The board to be upgraded runs normally.
The abnormal boards do not support any online upgrade including the basic BootROM
upgrade.
l The board to be upgraded supports the basic BootROM online upgrade.
If the board does not support the function, the command execution fails.
Not all the boards of one logical board support the basic BootROM online upgrade. This
function is also related to the physical type and the hardware version of the board.
When the upgrade operation is performed, you do not need to consider whether all the
boards of one type support the basic BootROM online upgrade. The system can
automatically process those boards that do not support this function. The system does not
upgrade them but gives related prompt messages.
l The rules to name the basic BootROM files to be upgraded are as follows:
The commands for the basic BootROM online upgrade inherit those for the former board
software upgrade. The only way in which the system distinguishes the functions is the
specific software name during upgrade. If the name of the basic BootROM file is correct,
the system upgrades the basic BootROM file; otherwise, the system performs upgrade
operations of ordinary software. Thus, make sure that the name of the basic BootROM to
be upgraded in the system is correct before online upgrade.

The naming rules of the basic BootROM file are the same as those of the extended
BootROM. The method to determine the name is as follows: Run DSP SWVER : VT =
SUIT; to obtain the version configuration table; find the type of the board to be upgraded
and check the name of the extended BootROM software named EXBOOTROMCODE; get
the basic BootROM name from the extended BootROM name according to certain rules.
Rules for converting an extended BootROM name to a basic BootROM name: The unified
name of the extended BootROM software is xxxx_eBootRom.bin. xxxx is the physical or
logical name of the board type. The name of the basic BootROM software is
xxxx_bBootRom.bin.
29.2 Availability of Basic BootROM Online Upgrade

Required NEs
Table 29-3 Required NEs for basic BootROM online upgrade

Feature Required NE
Basic BootROM online upgrade MGW
Version Support
Table 29-4 Versions supporting basic BootROM online upgrade

Basic BootROM online upgrade R006 and later
29.3 Operation of Basic BootROM Online Upgrade

Context
As shown in Figure 29-1, the basic BootROM software is uploaded to the back administration
module (BAM) hard disk of the OMU from the version server by the File Transfer Protocol
(FTP) for storage. The BAM hard disk may be the physical hard disk, CF card, or Flash file
system. Then, the basic BootROM software is transmitted to the random-access memory (RAM)
of the board through the internal loading protocol from the OMU hard disk. After that, the basic
BootROM software is written to the read-only memory (ROM) of the board through the interface
of the board support package (BSP) lower layer support system.

Figure 29-1 Loading the BootROM software to the hard disk of the OMU
Procedure
Step 1 Run LOD TOBAM to upload the basic BootROM software from the file server to the BAM
hard disk for storage.
LOD TOBAM: VT =MS, FN ="xxxx_bBootRom.bin", UID ="bam", PWD ="bam";
File Name indicates the name of the basic BootROM file to be uploaded. User Name and
Password indicate the user name and the password to log in to the specified FTP server. The
command is used in the same way as that in the basic upgrade.
Step 2 Run LOD TOBT to complete online upgrade of the basic BootROM.
LOD TOBT: BT =XXXX, FN ="xxxx_bBootRom.bin";
Board Type indicates the type of the board to be upgraded. It can be any of the preceding board
types that support the basic BootROM upgrade. File Name indicates the name of the software
to be upgraded. Enter the name of the basic BootROM file here.
When this feature is used, Enable in LOD TOBT is invalid. The rest parameters remain valid.
Step 3 Run RST SYS to restart the system and validate the uploaded file.
----End
Example
To online upgrade the basic BootROM of the TNC, run the following command:
LOD TOBT: BT=TNU, FN="mtnc_bBootRom.bin", SRC=NET, UID="bam", PWD="***";
Postrequisite
1. Problem description: The software is not written into the ROM during upgrade.
After running the upgrade command, the prompt of loading failure is likely to appear. The
possible errors are as follows: No support for Basic Bootrom loading, Time
out when saving data, Fail to write data in ROM, No file
found, and The file exceeds the standard size.

(1) The errors related to the system support capability and file system, such as No
support for Basic Bootrom loading, No file found, and The
file exceeds the standard size, do not affect the original basic
BootROM software in the ROM of the board. Quit the upgrade or run the upgrade
command again after performing processing according to the prompt message.
(2) For the errors such as Time out when saving data and Fail to write
data in ROM, the original basic BootROM of the board may be damaged. Run the
command to load the basic BootROM software again. If the loading still fails, take
emergency measures for recovery.
2. Problem description: emergency measures for recovery after rewriting ROM.
Procedure: when upgrading failed and BootROM in ROM damaged, load the basic bootrom
by using CANBUS.

Feature Description 30 JTAG Upload Through MML Command
30 JTAG Upload Through MML Command
About This Chapter
restrictions, and operation of joint test action group (JTAG) upload through man-machine
language (MML) commands.
30.1 Overview of JTAG Uploading Through MML Command
30.2 Availability of JTAG Upload Through MML Command
30.3 Operation of JTAG Upload Through MML Command

30 JTAG Upload Through MML Command Feature Description
30.1 Overview of JTAG Uploading Through MML

Command
Feature Definition
The new joint test action group (JTAG) upload feature simplifies and optimizes the loading
process on the basis of the existing JTAG upload feature. Thus, JTAG upload without support
of the JTAG Studio software is achieved. The operations are performed on the local maintenance
terminal (LMT) for convenience. This function supports the following features:
l Supporting direct uploading with MBus data frame files as the source files
l Supporting the loading buffer
l Supporting verification of data results completed by the OMU and judgment of correctness
of the upload process
Service Benefits
Table 30-1 Service benefits of JTAG upload
JTAG upload This feature loads and upgrades the erasable Not involved.
programmable logic device (EPLD) or basic input/
output system (BIOS) of the board, realizing JTAG
upload without support of the JTAG Studio
software and data verification on the OMU.
Table 30-2 Function restrictions of JTAG upload
JTAG upload The JTAG files to be loaded are usable MBus data frame files.
The versatile routing platform (VRP) needs to support the File Transfer
Protocol (FTP).
30.2 Availability of JTAG Upload Through MML Command


Required NEs
Table 30-3 Required NEs for JTAG upload
Feature Required NE
JTAG upload MGW
Version Support
Table 30-4 Versions supporting JTAG upload
JTAG upload R007and later
30.3 Operation of JTAG Upload Through MML Command

Context
The joint test action group (JTAG) upload feature on the media gateway (MGW) supports the
following functions:
l Using MML commands for JTAG uploading

l Adding the slot information for MBus data frames
l Supporting the loading buffer
Procedure
Step 1 Gain usable MBus data frame files.
The maintenance bus (MBus) frame data files are generated during version release. That is, the
files released by the configuration management office (CMO) and used for JTAG upload are
usable MBus data frame files.
Step 2 Run LOD JT to issue the upload command.
The flow of issuing the upload command is as follows:
1. Place the MBus frame data files to the local directory, for example, d:/temp/jtag.
2. Run LOD JT for the first time, and select the File Transfer Protocol (FTP) mode to
download the files to the memory.

30 JTAG Upload Through MML Command Feature Description
3. Wait for the data returned by the MBus. Then, verify the returned data. If the verification
fails, stop uploading the files.
4. If verification succeeds, determine whether the file upload process is complete. If the upload
process is not complete, continue sending the data frame files.
CAUTION
If you run LOD JT to upload the file for the first time, select the FTP mode for uploading. If
the buffer mode is selected for uploading, the physical type of the board to be uploaded must be
the same as that in the buffer.
Timeout processing:
l Set the file sending timer. The time of waiting for the response to each data frame file is five
minutes.
l Set the 30-minute buffer timer. When the file is downloaded to the buffer, a 30-minute timer
is started. Upon timeout, the buffer automatically releases the memory.
Step 3 Verify the data returned by the MBus.
The OMU verifies the data returned by each sent file. If file sending fails, stop JTAG uploading.
Step 4 Limit the loading buffer time to 30 minutes.
After gaining files from the FTP server and loading a certain board, all the loaded files are stored
in the loading buffer for a period. To immediately load files to a board of the same type, set
Source to Load Buffer. Thus, the files in the buffer are directly used during the loading process,
shortening the FTP process and improving efficiency. The buffer mechanism is to reserve the
JTAG files of the latest board type only.
Figure 30-1 Loading buffer
Precautions:

l If you do not run LOD JT within 30 minutes, the buffer is released.

l If you run LOD JT and set Source to Load Buffer within 30 minutes, the system loads the
buffered JTAG files from the memory.
l If you run LOD JT and set Source to Load Buffer after 30 minutes, the system returns a
message, indicating the loading failure due to no buffer.
l If you run LOD JT and set Source to FTP Server within 30 minutes, you need to update
the contents in the loading buffer from the FTP server and store the contents for 30 minutes
after uploading succeeds.
----End
Example
l Load the back board in slot 5 of frame 1 in FTP mode. The loaded file is stored to d:/temp/
jtag of the server of which the IP address is 10.110.28.88.
LOD JT: FN=1, SN=5, BP=BACK, SRC=FTP, DIR="d:/temp/jtag",
SVRIP="10.110.28.88", USERNAME="bam", PASSWORD="bam";
l Load the back board in slot 5 of frame 1 in buffer mode.

LOD JT: FN=1, SN=5, BP=BACK, SRC=BUFFER;

HUAWEI UMG8900 Universal Media Gateway 31 Backup and Restoration of Configuration Files on the
Feature Description LMT
31 Backup and Restoration of

Configuration Files on the LMT
About This Chapter
restrictions, and operation of backup and restoration of configuration files on the local
maintenance terminal (LMT).
31.1 Overview of Backup and Restoration of Configuration Files on the LMT

31.2 Availability of Backup and Restoration of Configuration Files on the LMT
31.3 Operation of Backup and Restoration of Configuration Files on the LMT

31 Backup and Restoration of Configuration Files on the HUAWEI UMG8900 Universal Media Gateway
LMT Feature Description
31.1 Overview of Backup and Restoration of Configuration

Files on the LMT
Feature Definition
The configuration data of the UMG8900 is stored in the OMU file system, including files of
configuration, user information, command groups, alarms, performances, dynamic tones,
debugging, and license. All these files must be managed in an effective and efficient way. The
UMG8900 can back up the configuration data. Thus, the configuration data can be restored when
it is lost or corrupted.
Service Benefits
Table 31-1 Service benefits of backup and restoration of configuration files on the LMT
Backup and restoration of The configuration data of the Not involved

configuration files on the UMG8900 can be stored and restored
LMT when it is lost or corrupted. Thus, the
carriers can reduce the loss.
Table 31-2 Function restrictions of backup and restoration of configuration files on the LMT
Backup and restoration of This function ensures that the LMT can log in to the File Transfer
configuration files on the Protocol (FTP) server that is used to back up the configuration
LMT data.
The FTP server tool such as wftpd32 must be enabled when the
specified server is used to back up the configuration data. In
addition, the user information about the FTP server such as the
user name, password, and user root path must be set and the path
is under full control.
The FTP user that logs in to the UMG8900 must have full control
over the C:\ directory when the configuration data is restored on
the UMG8900.

31.2 Availability of Backup and Restoration of

Configuration Files on the LMT
Required NEs
Table 31-3 Required NEs for backup and restoration of configuration files on the LMT
Feature Required NE
Backup and restoration of configuration files MGW

on the LMT
Version Support
Table 31-4 Versions supporting backup and restoration of configuration files on the LMT
Backup and restoration of configuration files R006 and later

on the LMT
31.3 Operation of Backup and Restoration of Configuration

Files on the LMT
Prerequisite
You can run PING on the local maintenance terminal (LMT) to gain the IP address of the
operation and maintenance center (OMC) interface on the UMG8900. Then, the LMT can log
in to the UMG8900 through the OMC interface. The file transfer protocol (FTP) server state of
the UMG8900 is ON.
Procedure
Step 1 Set the FTP server state to ON on the LMT.
Run DSP FTPSRV on the LMT to query the FTP server state. If it is OFF, run SET
FTPSRV to set the FTP server state to ON.

SET FTPSRV: SRVSTAT=ON;

Step 2 Create an FTP user on the LMT.
Run ADD FTPUSR to add an FTP user. Set the user name and the password to bam. Set the
working directory to the root directory of disk C. Set the authority to FULL. The preceding
password is used only as an example. You must set the password by strictly following the
password configuration policy. The length of the password is recommended to be more than six
characters that are composed of digits and mixed letters.
ADD FTPUSR: USRNAME="bam", PWD="bam", CFM="bam", HOMEDIR="c:\",
RIGHT=FULL;
Step 3 Save or restore the configuration file in a specific server.
To save or restore the configuration file in a specific server, install the FTP tool wftpd32 on the
server that is used to save the data. Then, set and activate the specific user.
1. Double-click the wftpd32.exe file. An interface appears. See Figure 31-1.
Figure 31-1 Interface of the wftpd32 tool
2. Choose Security > Users > rights. The User/Rights Security Dialog window appears.
See Figure 31-2.

Figure 31-2 User setting
3. Click New User. Set the user name in the popup New User window to bam. Then click
OK. See Figure 31-3.
Figure 31-3 Adding a user
4. Set the password in the Change Password window, and then click OK. See Figure
31-4.
Figure 31-4 Setting the password
5. Return to the User/Rights Security Dialog window. Set Home Directory to C:\ as the
default directory. Then, click Done to complete FTP settings. See Figure 31-5.

Figure 31-5 Setting the default directory
Step 4 Log in to the UMG8900 LMT.
Start the LMT on the PC, and then enter the main interface.
Step 5 You can back up the configuration data immediately or regularly.
To... Then...
Back up the configuration data immediately Perform Step 6.
Back up the configuration data regularly Perform Step 7.
Step 6 Back up the configuration data immediately.
To back up the configuration data immediately, perform the following steps:
1. Choose Backup > Backup Configuration Data Immediately. See Figure 31-6.
Figure 31-6 Backing up the configuration data
2. In the Backup Configuration Data Immediately window, you can set the backup mode
and the path. There are two backup modes: local backup and backup on the specified server.

l Backup at the local end

To back up the configuration data at the local end, select Local, and set the backup path
for configuration files to D:$\HW LMT\adaptor\clientadaptor\UMG8900
\UMG8900Vx00R00xCxx\output\ConfigurationData. Usually, the default path is
used. Click OK, and then the system backs up related files to the specified path. See
Figure 31-7.
Figure 31-7 Backing up the configuration data at the local end
l Backup on the specified server
CAUTION
When the configuration data is backed up on the specified server, the saving path must
be the relative path on the server that is used for storing the configuration files.
To back up the configuration data on the specified server, select FTP Server. Set the
user name and the password to bam, which are set on the specified FTP server. Set the
server IP address to 10.110.49.100, and the path to Configuration Data. The path must
be the relative path on the server that is used for saving the configuration files. See
Figure 31-8.

Figure 31-8 Backing up the configuration data on the specified server
Step 7 Back up the configuration data regularly.

To back up the configuration data regularly, perform the following steps:
1. Choose Backup > Backup Configuration Data Regularly. See Figure 31-9.
Figure 31-9 Backing up the configuration data
In the Backup Configuration Data Regularly window, set the backup start time and
period. You can also select the local end or the FTP server to back up the configuration
data. See Figure 31-10. For how to select the local end or specified FTP server for backup,
see the description in Backup Configuration Data Immediately.

Figure 31-10 Backing up the configuration data regularly
Step 8 Restore the configuration data.
To restore the configuration data, perform the following steps:
1. Choose Backup > Restore Configuration Data. See Figure 31-11.
Figure 31-11 Restoring the configuration data
2. In the Restore Configuration Data window, you can set the restoration mode and the
path. You can restore the configuration data at the local end or on a specified FTP server.
l Restoration at the local end
To restore configuration data at the local, set the user name and the password to bam
in the NE FTP Information tab of the Restore Configuration Data window. The user

name and password must be the same as those set when the FTP user is added. Select
Local, and set the path for restoring the configuration data to D:$\HW LMT\adaptor
\clientadaptor\UMG8900\UMG8900Vx00R00xCxx\output\ConfigurationData.
The path must be the same as the saving path selected in configuration data backup. If
the configuration data must be synchronized to the slave OMU, select Synchronize to
OMU standby board. Click OK. See Figure 31-12. The system automatically
synchronizes the configuration data to the hard disk of the slave OMU.
Figure 31-12 Restoring the configuration data at the local
l Restoration on the specified server
CAUTION
l The specified restoration path must be the same as that specified when configuration
data is backed up on the specified server. The path must be the relative path on the
backup server.
l The BAM folder must exist in the folder that is used for saving the configuration
data.
To restore the configuration data on the specified server, set both the user name and the
password to bam in the NE FTP Information tab of the Restore Configuration
Data window. The user name and password must be the same as those set when the
FTP user is added. Select FTP Server, and set the path for restoring the configuration
data to Configuration Data. The path must be the same as the saving path selected in
configuration data backup. If the configuration data must be synchronized to the slave
OMU, select Synchronize to OMU standby board. Click OK. See Figure 31-13.

Figure 31-13 Restoring the configuration data on the specified server
3. The program automatically restores the backup configuration data files to the BAM of the
OMU. To avoid impacts on the normal operation of the UMG8900, make sure that the
configuration files for restoration are correct.
4. Run RST SYS to restart the UMG8900 to validate the restored data files.
----End

Feature Description 32 Password Configuration Policy
32 Password Configuration Policy
About This Chapter
restrictions, and operation of password configuration policy.
32.1 Overview of Password Configuration Policy

32.2 Availability of Password Configuration Policy
32.3 Setting Password Policy
This section describes the operation for enabling and maintaining password policy.

32 Password Configuration Policy Feature Description
32.1 Overview of Password Configuration Policy

Feature Definition
Password configuration policy: To enhance the system security, restrictions and constraints are
adopted on the password attribute in password management. The restrictions and constraints
include length of the configured password (minimum length and maximum length), types of
mandatory characters in the password, validity period of the password, number of password
input errors allowed, and whether to lock users with multiple login attempts.
Service Benefits
Table 32-1 Service benefits of password configuration policy

Password This feature realizes flexible This feature enables the device
configuration policy password management for the suppliers to provide functions
media gateway (MGW), needed by the carriers and users,
improving security and catch up with industrial
availability of system operation mainstream functions, produce
and maintenance, and facilitating new selling points, and meet the
use by users. special requirements of carriers
on system maintenance security.
Table 32-2 Function restrictions of password configuration policy

Password The password configuration policy is used for constraint check on

configuration policy newly set passwords only, rather than old passwords.
32.2 Availability of Password Configuration Policy


Feature Description 32 Password Configuration Policy
Required NEs
Table 32-3 Required NEs for password configuration policy
Feature Required NE
Password configuration policy MGW
Version Support
Table 32-4 Versions supporting password configuration policy
Password configuration policy R006 and later
32.3 Setting Password Policy

This section describes the operation for enabling and maintaining password policy.
Procedure
1. Choose Authority > Password Policy Setting. The Password Policy Setting dialog box
appears.
2. Set the minimum length of the password.
3. Select the types of characters for password complexity.
4. Click OK.
NOTE
l Only admin can set the password policy.
l For certain NEs, Special character can be selected in Password Complexity.
Table 32-5 Parameter description
Minimum password 6~32 The default value is 8. You can set the
length minimum password length based on
the requirement.

32 Password Configuration Policy Feature Description
Password complexity You can select letters in the You can set the complexity of the
upper or lower case, and password, including the character
digits. types required in the password. For
certain NEs, you can select special
character for this parameter.
Example
l Adopt the following password configuration policy: Set the minimum password length to
8, maximum password length to 32, maximum validity period to 90 days, and maximum
error times for entering a password to 3. Lock the user with multiple login attempts. Set
the lock duration to 30 minutes. The password must contain letters in lower case and digits.
SET PWDPOLICY: PWDMINLEN=8, PWDMAXLEN=32, MAXEFFTIME=3,MAXMISSTIME=3,
AUTOLOCKUSER=YES, AUTOLOCKTIME=30,COMPLICACY=Lowercase-1&Digit-1;
l Set a forbidden password. Forbid using abcd1234 as the password.

ADD FRDPWD: FRDPWD="abcd1234";
Postrequisite
Assume that the system is configured in the same way as that in the example. The verification
method is as follows.
Log in to the LMT. Choose Authority > Change Password. Perform the following steps to
modify the new password.
l Set a password with the length shorter than eight bits. The system returns a message,
indicating that setting the password fails.
l Set a password with the length larger than 32 bits. The system returns a message, indicating
that setting the password fails.
l Set a password with capital letters and digits. The system returns a message, indicating that
setting the password fails.
l Set a password with the length between 8 and 32 bits and containing letters in lower case
and digits. The system returns a message, indicating that setting the password succeeds.

Feature Description 33 Transmission Quality Check in the IP Bearer Network
33 Transmission Quality Check in the IP

Bearer Network
About This Chapter
restrictions, operations, and alarms of transmission quality check in the IP bearer network.
33.1 Overview of the Transmission Quality Check in the IP Bearer Network

33.2 Availability of Transmission Quality Check in the IP Bearer Network
33.3 Locating Faults of the IP Bearer Network Through Monitoring IP Addresses

33 Transmission Quality Check in the IP Bearer Network Feature Description
33.1 Overview of the Transmission Quality Check in the IP

Bearer Network
Feature Definition
After the telecommunication network develops to the IP-based network, both the core network
and the bearer network adopt IP for transmission.
l Compared with the traditional time division multiplexing (TDM) network, the IP bearer
network is complex and may run into various IP transmission faults. Therefore, the
probability of faults in the IP bearer network is greater than that in a traditional TDM
network.
l The business field of the IP bearer network is different from that of the core network.
Therefore, locating and analyzing faults in one network are difficult for engineers of another
network.
Locating faults in the IP bearer network is more difficult and fault causes are more complex than
those in the traditional TDM network.
To ensure that faults are cleared quickly by proper engineers, determining where faults occur is
the first and foremost step after services are interrupted. With the aim to locate faults effectively
and shorten service interruption duration, the UMG8900 is enabled to locate faults of the bearer
plane. Faults of the signaling plane are located by the media gateway controller (MGC).
Service Benefits
Transmission quality check This feature helps to locate Not involved

in the IP bearer network faults and clear faults of the
IP bearer network
effectively.

Function Restriction
Transmission quality check in the IP bearer l To enable this function, the peer device
network must support the ping function.
l If firewalls are deployed on the networks,
the firewalls must allow ping packets to
pass through.
l Ping packets between devices in the core
network must be able to pass through the
IP bearer network. Therefore, routers are
required not to discard Internet Control
Message Protocol (ICMP) packets,
irrespective of whether the ICMP packets
are destined for the routers.
33.2 Availability of Transmission Quality Check in the IP

Bearer Network
Required NEs
Table 33-1 Required NEs for transmission quality check in the IP bearer network
Feature Required NE
Transmission quality check in the IP bearer MGW

network
Version Support
Transmission quality check in the IP bearer V200R008C01 and later

network

33.3 Locating Faults of the IP Bearer Network Through

Monitoring IP Addresses
Prerequisite
l The peer device must support the ping function.
l If firewalls are deployed on the networks, the firewalls must allow ping packets to pass
through.
l Ping packets between devices in the core network must be able to pass through the IP bearer
network. Therefore, the router is required not to discard Internet Control Message Protocol
(ICMP) packets whose destination is not the router.
Context
On the UMG8900, configure monitoring IP address pairs, consisting of local IP addresses and
destination IP addresses. To detect the transmission quality of the IP bearer network, interfaces
with the local and destination IP addresses periodically send standard ICMP packets such as
echo request and echo reply packets to each other. According to the response status of ping
packets, the UMG8900 can monitor the running status, such as connection or disconnection,
packet loss, of the IP bearer network. Through ping operations, the transmission quality of the
IP bearer network can be detected in two directions. The measurement values of packet loss ratio
are not accurate; however, they can indicate how the transmission quality of the IP bearer
network changes.
The detection paths are the same as the actual media paths; therefore, the status of the IP bearer
network indicated through ping operations is the actual status of the IP bearer network carrying
end-to-end service flows. Ping operations are independent of services. Therefore, ping
operations can be performed irrespective of the types of services, such as voice and video, carried
on interfaces whose IP addresses are monitoring IP addresses. In addition, ping operations can
be performed even if there is no traffic.
Refer to Figure 33-1. The black arrows between IP 1 and IP 5 identify one detection path, and
the red arrows between IP 3 and IP 6 identify another detection path. The blue arrows identify
routing paths that can be selected according to routing policies and networking conditions.

Figure 33-1 Networking diagram
IP 1: 10.110.1.100 IP 2: 10.110.1.1 IP 5: 10.111.9.90
IP 3: 10.110.2.100 IP 4: 10.110.2.1 IP 6: 10.111.8.80
After a monitoring IP address pair is configured, the UMG8900 reads through the list of
monitoring IP addresses every two seconds.
l The alarm about disconnection of the IP bearer network is generated when 10 ping packets
are lost consecutively, and the alarm is cleared when 30 consecutive ping packets are not
lost.
l The minor fault alarm indicating that the packet loss ratio of the IP bearer network exceeds
the threshold is generated when more than 2 among 100 packets are lost, that is, when the
packet loss ratio is greater than 2%. The alarm is cleared when 300 consecutive packets are
not lost.
NOTE
Here, 100 packets refer to any 100 consecutive packets. The alarm is generated when the number of
ping packets between two lost ping packets is smaller than or equal to 98.
Procedure
Step 1 Run ADD GWADDR to add gateway IP addresses.
ADD GWADDR: BN=0, IPADDR="10.110.1.100", GWIP="10.110.1.1", TIMEOUT=NoAging;
ADD GWADDR: BN=0, IPADDR="10.110.2.100", GWIP="10.110.2.1", TIMEOUT=NoAging;
Step 2 Run ADD MONITORIP to add monitoring IP address pairs. The parameters Monitor IP and
Source IP for Monitor IP must be specified.
ADD MONITORIP: DSTIP="10.111.9.90", LOCALIP="10.110.1.100", FLAG=YES, DESP="To UMG
9";
ADD MONITORIP: DSTIP="10.111.8.80", LOCALIP="10.110.2.100", FLAG=YES, DESP="To UMG
8";

NOTE
l If firewalls are deployed on the networks, the firewalls must allow ping packets between two IP
addresses in a monitoring IP address pair to pass through.
l The added local IP addresses are used to monitor the status of the IP bearer network, and therefore they
must not be test IP addresses configured on the HRB. To ensure that alarms are generated only when
specified conditions are met, the local IP addresses must be configured with gateways whose IP
addresses can be resolved successfully.
l Each frame allows you to configure up to 300 monitoring IP address pairs.
Step 3 Run LST ALMAF to check whether the following alarms are generated.
Serial No. Alarm ID and Name
1 ALM-3266 Gateway resolution failed
2 ALM-3282 IP bearer network is abnormal
3 ALM-3283 The loss packet of IP bear network exceed threshold
l If the alarms are generated, handle them by referring to the UMG8900 Help.
l If the alarms are not generated, it indicates that the IP bearer network is of good quality,
and the monitoring task can be continued.
----End

Feature Description 34 IP CAC
34 IP CAC
About This Chapter
This chapter provides general information, availability, configuration method, and related alarm
of the IP CAC feature.
34.1 Overview of IP CAC

34.2 Availability of IP CAC
This section provides the required network elements (NEs) and versions of the UMG8900 that
34.3 Configuring the IP CAC Function
This section describes data configuration of this feature.

34 IP CAC Feature Description
34.1 Overview of IP CAC

Feature Definition
With the IP CAC feature, the UMG8900 can actively monitor the QoS statuses of the IP address
pairs in use to check whether service congestion, interruption, or block occurs on the bearer
network. This helps to effectively determine whether a network fault is caused by the core
network or IP bearer network. When the bandwidth is insufficient or the QoS level declines, the
UMG8900 can restrict the bandwidth or calls, or adjust the differentiated service code point
(DSCP) flag through the static connection admission control (CAC) optimization, dynamic CAC
optimization, and dynamic adjustment of the DSCP flag functions. Then, the UMG8900 can
change the policies for later services to prevent further deterioration in network quality and loss
in user services.
With the IP CAC feature, the UMG8900 provides the following functions:
l Automatic discovery and detection of faulty IP address pairs
The UMG8900 collects the QoS statistics of the IP address pairs used by ongoing calls and
learns the statuses of the IP address pairs for reference during later service processing. If
the packet loss ratio of an IP address pair is 60% or higher, the UMG8900 considers the IP
address pair as abnormal and pings the IP address pair. After detecting that the IP address
pair has recovered, the UMG8900 deletes the IP address pair from the monitoring list.
l Static CAC optimization
In addition to the existing CAC algorithm based on the outgoing interface, the
UMG8900 can allocate bandwidths based on destination network segment. If the bandwidth
for a specified destination network segment is exhausted, new calls with the same
destination network segment cannot be established and the UMG8900 sends a message to
the media gateway controller (MGC) to inform the abnormality.
l Dynamic CAC optimization
You can configure the call reject ratio for the good, fair, and poor QoS levels on the
UMG8900. If the MGC requires the UMG8900 to detect the QoS of calls, the UMG8900
rejects a certain number of the calls according to the preset call reject ratio.
l Dynamic adjustment of the DSCP flag
The UMG8900 monitors the QoS statistics of the IP address pairs in use in real time. If the
QoS level of an IP address pair changes from excellent to good, fair, or poor, the
UMG8900 degrades the DSCP flag of some users using the IP address pair, thus
guaranteeing voice quality for users with a high QoS level.

Service Benefits
IP CAC This feature can prevent The feature can improve the
network problems at the call completion rate and
maximum limit, reduce voice quality.
network traffic, and
guarantee the voice quality
for users with a high QoS
level.
IP CAC l The feature can be used to detect only the abnormalities between
Huawei core networks or between core networks of Huawei and
another vendor.
l If firewalls are deployed on the networks, the firewalls must
allow ping packets to pass.
l The implementation of the dynamic CAC function requires
Huawei MGC.
l The IOE does not support the feature.
l A license is required for the function of automatic discovery and
detection of faulty IP address pairs, dynamic CAC optimization,
or dynamic adjustment of the DSCP flag.
l In the feature, only the packet loss ratio is considered for
assessing the QoS of an IP address pair.
l Both the IP bearer and TDM bearer must be configured between
two UMG8900s.
34.2 Availability of IP CAC

This section provides the required network elements (NEs) and versions of the UMG8900 that
Required NEs
Function Required NE
IP CAC MGC and MGW


Function Version
IP CAC V200R008C01 and later
Required License
A license is required except static CAC optimization.

34.3.1 Automatic Discovery and Detection of Faulty IP Address Pairs
This section describes how the UMG8900 automatically discovers and detects faulty IP address
pairs.
34.3.2 Static CAC Optimization
This section describes how to configure the static connection admission control (CAC)
optimization function.
34.3.3 Dynamic CAC Optimization
This section describes how to configure the dynamic connection admission control (CAC)
34.3.4 Dynamic Adjustment of the DSCP Flag
This section describes how to configure the function of dynamic adjustment of the differentiated
service code point (DSCP) flag.
34.3.1 Automatic Discovery and Detection of Faulty IP Address

Pairs
This section describes how the UMG8900 automatically discovers and detects faulty IP address
pairs.
Prerequisite
l The HRU and HRD are available.
l If firewalls are deployed on the networks, the firewalls must allow ping packets to pass.
l The license for dynamic connection admission control (CAC) optimization is required.
l The IP quality of service (QoS) function and the local Real-time Transport Control Protocol
(RTCP) function must be enabled to implement the function of automatic discovery and
detection of faulty IP address pairs.
An IP address pair refers to a pair of source IP address and destination IP address that are
occupied by calls.
With the function of automatic discovery and detection of faulty IP address pairs, the
UMG8900 collects the QoS statistics of the IP address pairs used by ongoing calls and learns

the statuses of the IP address pairs for reference during later service processing. If the packet
loss ratio of an IP address pair is 60% or higher, the UMG8900 considers the IP address pair as
abnormal. Then, the UMG8900 pings the IP address pair and generates an alarm. After detecting
that the IP address pair recovers through the ping operation, the UMG8900 deletes the IP address
pair from the monitoring list.
The specifications related to this function are as follows:
l Each HRU and HRD supports the QoS statistics of 4096 IP address pairs.
l The QoS measurement items for IP address pairs contain packet loss ratio (maximum values
in the outbound and inbound directions), delay, and jitter. All measurement items except
the packet loss ratio in the inbound direction require that the remote device should support
RTCP. Currently, only the packet loss ratio is considered for assessing the QoS.
l Each HRU and HRD can automatically detect and add 300 abnormal IP address pairs whose
packet loss ratio is 60% or higher to the monitoring list.
Figure 34-1 shows the messages exchanged for the function of automatic discovery and
detection of faulty IP address pairs.
Figure 34-1 Messages exchanged for the function of automatic discovery and detection of faulty
IP address pairs
1. The UMG8900 collects the QoS statistics of the IP address pairs used by ongoing calls in
real time.

NOTE
l Run DSP IPQOS to view the statistics of the IP address pairs in use.
l If an IP address pair is no longer used, the UMG8900 stops collecting the QoS statistics.
2. The UMG8900 collects the statistics of each IP address pair every five seconds. If the packet
loss ratio of either received or sent packets is 60% or higher, the IP address pair is regarded
as abnormal. The remote device must support RTCP for the UMG8900 to measure the
packet loss ratio in the outbound direction. The measurement of the packet loss ratio in the
inbound direction is not restricted.
3. The UMG8900 adds the abnormal IP address pair to the monitoring list.
4. The UMG8900 monitors abnormal IP address pairs through the existing active detection
function described in 33.3 Locating Faults of the IP Bearer Network Through
Monitoring IP Addresses. According to the monitoring result, "ALM-3282 IP bearer
network is abnormal" is generated for each service board. After detecting that the packet
loss ratio of the IP address pair is lower than 2% through the ping operation, the
UMG8900 deletes the IP address pair from the monitoring list.
Procedure
Step 1 Run SET FUNCSWT to enable the IP QoS function.
SET FUNCSWT: IPQOSSWT=ON;
Step 2 Run SET RTCP to enable the local RTCP function.

SET RTCP: TIMER=5, SENDFLAG=SEND;
Step 3 Run DSP IPQOS to query the QoS statistics of all IP address pairs on a specified board.
%%DSP IPQOS: BN=0;%%
IPQoS Info.
-----------
Local IP Destination IP QoS Level Lost rate
10.110.45.67 10.110.50.187 Excellent 0%

10.110.45.67 10.110.50.186 Good 2%
10.110.45.68 10.110.50.186 Good 3%
--- END
Step 4 Run DSP MONITORIP to query the monitored IP address pairs.

%%DSP MONITORIP: FN=1, SN=5, BP=FRONT;%%
Board No. 1
------------
Open Domain Monitor ip Local IP Frame No. Slot No. Monitor State Add type
No 0 10.110.50.194 10.110.45.67 1 5 Normal Manual

No 0 0.0.0.44 0.0.0.10 1 5 Interrupt Auto
--- END
Step 5 Check whether ALM-3282 IP bearer network is abnormal is generated on the local maintenance
terminal (LMT).

NOTE
You do not need to manually configure the function of automatic discovery and detection of faulty IP
address pairs. You can manually configure IP address pairs as required. For details, see 33.3 Locating
Faults of the IP Bearer Network Through Monitoring IP Addresses.
----End
Postrequisite
If the ping operation fails due to network faults, you can run RMV MONITORIP to delete the
automatically identified IP address pairs from the monitoring list.
34.3.2 Static CAC Optimization

This section describes how to configure the static connection admission control (CAC)
Principle and Networking

CAC determines whether a connection request is accepted or rejected according to network
activities during call establishment.
In addition to the existing CAC algorithm based on the outgoing interface, the UMG8900 can
allocate bandwidths according to destination network segment. If the bandwidth for a specified
destination network segment is exhausted, new calls with the same destination network segment
cannot be established and the UMG8900 sends a message to the media gateway controller
(MGC) to inform the abnormality.
l Figure 34-2 shows the existing CAC algorithm based on the outgoing interface.
This algorithm can effectively control the traffic to the bearer network but cannot prevent
service congestion in certain network segments.
Figure 34-2 CAC algorithm based on the outgoing interface
l Figure 34-3 shows the optimized CAC algorithm that allows bandwidth allocation
according to destination network segment.
If you are aware of traffic distribution on the network, you can specify the traffic destined
for each network segment to prevent congestion in certain network segments. Traffic

distribution, however, is difficult to plan or predict; therefore, the optimized CAC algorithm
can be applied to small-scale networks only. If the UMG8900 cannot reach the preset
forwarding capacity for some destination segments, you can set the bandwidth dedicated
to the network segment to restrict the traffic destined for the network segment. Network
segments with bandwidth limits must not have intersections.
Figure 34-3 Optimized CAC algorithm
In Figure 34-4, the bandwidths for four network segments are specified.
Figure 34-4 Bandwidth calculation by using the optimized static CAC algorithm
The UMG8900 measures the bandwidth of each network segment. The UMG8900 informs the
MGC of the calls that cause the total bandwidth to exceed the preset bandwidth for a network
segment. Then, the MGC selects another route or disconnects the calls according to the preset
policy.

Service Flow
Figure 34-5 shows the service flow.
Figure 34-5 Service flow chart
1. After a peer IP address is assigned to a new call, the UMG8900 checks whether the IP
address belongs to a network segment with a preset bandwidth limit. If yes, the
UMG8900 checks the total bandwidth of the network segment.
NOTE
The HRB reports the bandwidth of each network segment with bandwidth limits to the OMU every
five seconds.
2. The OMU checks whether the total bandwidth of a network segment exceeds the limit. If
yes, the OMU sends a message containing "G/cause = UR" to the MGC. The MGC then
determines whether to disconnect the calls.

NOTE
If the bandwidth exceeds 92% of the preset bandwidth limit, ALM-1064 Access bearer bandwidth
resource insufficient is generated. When the bandwidth usage is lower than 88%, the alarm is cleared.
Configuration Example
Table 34-1 lists the data planning.
The UMG8900 allows you to specify bandwidths for up to 32 network segments. Network
segments with bandwidth limits must not have intersections.
Descripti Site Bandwid Destinati Destinati Destinati Destinati

on index th(Kbps) on on on on
network wildcard network wildcard
segment mask 1 segment mask 2
1 2
MGW- 1 1024 10.111.0.0 255.255.2 10.110.0.0 255.255.2

BEIJING to 52.0 to 52.0
10.111.3.2 10.110.3.2
55 55
Procedure
Step 1 Run ADD SITEINDEX to add a site index with a bandwidth limit.
ADD SITEINDEX: ID=1, BW=1024, DESC="MGW-BEIJING";
Step 2 Run ADD SITEIP to add network segments with bandwidth limits.
ADD SITEIP: DSTIP="10.110.0.0", DSTMASK="255.255.252.0", ID=1;
ADD SITEIP: DSTIP="10.111.0.0", DSTMASK="255.255.252.0", ID=1;
----End
Postrequisite
None
34.3.3 Dynamic CAC Optimization

This section describes how to configure the dynamic connection admission control (CAC)
Prerequisite
This function requires a license. When the license for this function is available, the UMG8900
collects the statistics of the IP address pairs in use at a regular interval.

The UMG8900 collects the statistics of the IP address pairs in use at a regular interval. The
statistics include packet loss ratio, jitter, and delay. Currently, only the packet loss ratio is
considered for assessing the quality of service (QoS).
QoS level Excellent Good Fair Poor
Range of [0,1%] (1%,5%] (5%,10%] (10%,60%)

packet loss
ratio
You can configure the call reject ratio for the good, fair, and poor QoS levels on the
UMG8900. If the media gateway controller (MGC) requires the UMG8900 to detect the QoS
of calls, the UMG8900 rejects a certain number of the calls according to the preset call reject
ratio. When the packet loss ratio of an IP address pair is 60% or higher, the UMG8900
automatically rejects new calls that use this IP address pair.
You can specify a half circle. After the QoS recovers, the UMG8900 gradually restores the traffic
of the IP address pair according to the specified half circle.
After the half circle, the UMG8900 decreases the call reject ratio to half of the initial call reject
ratio. Then, the UMG8900 takes twice the half circle to further decrease the call reject ratio to
zero. The UMG8900 stops decreasing the call reject ratio if it detects that the QoS declines again.
Then, the new call reject ratio when the UMG8900 stops the adjustment is used. The
UMG8900 decreases the call reject ratio every 60 seconds. The default half circle is 10 minutes.
The allowed range for the half circle is from 5 to 20 minutes.
The local IP address with excellent QoS level is automatically selected. If no proper local IP
address is available, calls are rejected according to the call reject ratio.
Service Flow
1. The working parameters for the dynamic CAC optimization function are set by using man-
machine language (MML) commands.
2. If the QoS level of the IP address pair for new calls is good, fair, or poor, and the calls carry
the specific detection event, calls are rejected according to the call reject ratio.
NOTE
If time division multiplexing (TDM) resources are available, the MGC tries to re-establish the calls.
3. The UMG8900 decreases the call reject ratio gradually after the QoS of IP address pairs
recovers.
Configuration Example
Table 34-2 lists the data planning.
QoS Level Call Reject Ratio Half Circle (Minute)
Good 5% 20

QoS Level Call Reject Ratio Half Circle (Minute)
Fair 10% 20
Poor 50% 20
Procedure
Step 1 Run SET CAC to set the working parameters for the dynamic CAC optimization function.
SET CAC: RECYCLE=20, GOODRATE=5, MIDRATE=10, POORRATE=50;
----End
Postrequisite
None
34.3.4 Dynamic Adjustment of the DSCP Flag

This section describes how to configure the function of dynamic adjustment of the differentiated
service code point (DSCP) flag.
Prerequisite
The license for the dynamic connection admission control (CAC) optimization is required to
implement the function of dynamic adjustment of the DSCP flag.
DSCP refers to bit 0 to bit 6 of the DS field in the IP packet header. Routers provide services of
different quality of service (QoS) levels to different service flows according to the DSCP flag.
For details, see 15.3.1 ToS DSCP.
The UMG8900 monitors the QoS statistics of the IP address pairs in use in real time. If the QoS
level of an IP address pair changes from excellent to good, fair, or poor, the UMG8900 degrades
the DSCP flag of some users using the IP address pair, thus guaranteeing voice quality for users
with a high QoS level.
Service Flow
1. Normally, the DSCP value in voice packets is EF, which is of the highest priority.
2. If the QoS level changes from excellent to good, fair, or poor, the UMG8900 degrades the
priority of a certain percentage of voice packets to AF0, which is of the lowest priority.
Then, routers automatically discard packets with low priority, thus guaranteeing the
bandwidth for users with high priority.
NOTE
The priority level ranges from 0 to 15 in ascending order.
You can configure two groups of mappings between priority levels and DSCP values, one for
packets in normal situation and the other for packets when the QoS level changes from excellent
to good, fair, or poor.

If the QoS level of an IP address pair changes from excellent to good, fair, or poor, the
UMG8900 adjusts the DSCP flag to the user specified value for all users that use the IP address
pair in one minute. After the adjustment, the DSCP value in these packets does not change even
if the QoS recovers. For new calls, the mappings for packets in normal situation are still
employed.
Table 34-3 and Table 34-4 list the default mappings between priority levels and DSCP values.
Table 34-3 Default mappings between priority levels and DSCP values in normal situation
Pr 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
io
rit
y
D EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF EF
S
C
P
va
lu
e
Table 34-4 Default mappings between priority levels and DSCP values during dynamic
adjustment
Pr 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
io
rit
y
D A A A A A A A A A A EF EF EF EF EF EF
S F0 F0 F0 F0 F0 F0 F0 F0 F0 F0
C
P
va
lu
e
Procedure
Step 1 Run SET PRITODSCP to set the two groups of mappings between priority levels and DSCP
values.
SET PRITODSCP: PRIORITY=Priority8, DSCP0=***, DSCP1=***;
NOTE
Run RST PRITODSCP to set the DSCP flag to the default value.
Run LST PRITODSCP to query the existing mappings between priority levels and DSCP values.
----End

Data Planning
Table 34-5 Mappings between priority levels and DSCP values in normal situation
Pr 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
io
rit
y
D A A A A A A A A A EF EF EF EF EF EF EF
S F2 F2 F2 F3 F3 F3 F4 F4 F4
C 3 2 1 3 2 1 3 2 1
P
va
lu
e
Table 34-6 Mappings between priority levels and DSCP values during dynamic adjustment
Pr 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
io
rit
y
D A A A A A A A A A A EF EF EF EF EF EF
S F1 F2 F2 F2 F3 F3 F3 F4 F4 F4
C 1 3 2 1 3 2 1 3 2 1
P
va
lu
e
Configuration Script
SET PRITODSCP: PRIORITY=Priority9, DSCP0=EF, DSCP1=AF41;
SET PRITODSCP: PRIORITY=Priority8, DSCP0=AF41, DSCP1=AF42;
Postrequisite
None

Feature Description 35 Characteristic Location Method with Dialing Tests
35 Characteristic Location Method with

Dialing Tests
About This Chapter
This chapter describes the characteristic location method with dialing tests.
35.1 Data Configuration of Dialing Fault Location for a Specified User

restrictions, and operations of dialing fault location for a specified user.
35.2 Dialing Test for the Specified Resource
restrictions, and operation of the dialing test for the specified resource.

35 Characteristic Location Method with Dialing Tests Feature Description
35.1 Data Configuration of Dialing Fault Location for a

Specified User
restrictions, and operations of dialing fault location for a specified user.
35.1.1 Overview of Dialing Fault Location for a Specified User

this feature.
35.1.2 Availability of Dialing Fault Location for a Specified User
35.1.3 Data Configuration of Dialing Fault Location for a Specified User
35.1.1 Overview of Dialing Fault Location for a Specified User

this feature.
Feature Definition
At present, to locate a voice quality fault such as one-way audio, no audio, and noise, you must
check all network elements (NEs) related to the call one by one. Therefore, locating faults is
time-consuming and difficult.
With the feature of dialing fault location for a specified user, the UMG8900 can perform inloops
and outloops for terminations under the control of the mobile switching center (MSC) server.
To locate a voice quality fault, you can initiate loopbacks on the UMG8900 side for terminations
one by one.
To initiate loopbacks on the UMG8900 side, run LOP TID on the local maintenance terminal
(LMT) of the UMG8900. Then, perform loopbacks for terminations one by one to locate a voice
quality fault.
Service Benefits
Dialing fault location for a Voice quality faults such as Not applicable.
specified user one-way audio, no audio, and
noise can be located
efficiently.

Feature Function Restrictions
Dialing fault location l This feature is applicable only to IP terminations.

for a specified user l Loopbacks cannot be performed for an IP termination that is
involved in a multiparty service or is intercepted.
l Loopbacks cannot be performed for an IP termination that is
enabled with the Real-time Transport Protocol (RTP)
multiplexing function.
l Loopbacks for IP terminations can be implemented on only the
HRD.
35.1.2 Availability of Dialing Fault Location for a Specified User

Required NEs
Table 35-1 Required NEs for dialing fault location for a specified user
Feature Required NE
Dialing fault location for a specified user MSC server and MGW
Version Support
Dialing fault location for a specified user V200R008C01 and later
35.1.3 Data Configuration of Dialing Fault Location for a Specified

User
Figure 35-1 shows an inloop and an outloop. The outloop is performed on the termination T1
and the inloop is performed on the termination T2.
The loopback direction refers to the direction towards which the termination of a session is
looped back. For sessions at T1 and T3, the loopback is outward; therefore this loopback is called

outloop. For sessions at T2 and T4, the loopback is inward; therefore this loopback is called
inloop.
Figure 35-1 Inloop and outloop
NOTE
l This feature is applicable only to the mobile switching center (MSC) server and the UMG8900.
l Loopbacks for IP terminations can be implemented on only the HRD.
l Only outloops cannot be performed for asynchronous transfer mode (ATM) terminations.
l You can loop back an ATM or IP termination of a board; however, if the board is switched before the
loopback, the loopback is ineffective.
Dialing process
To locate dialing faults, you can initiate loopbacks on the UMG8900 side.
l Loopback initiated on the UMG8900 side

Figure 35-2 Loopback initiated on the UMG8900 side
1. Create a call tracing task on the local maintenance terminal (LMT) of the MSC server.
2. Create a User call trace task on the LMT of the UMG8900.
3. Set up a call to make the fault recur.
4. Analyze the traced messages to determine the location and index of each termination
in the call path.
5. Run LOP TID to perform a loopback for a specified termination successfully.
6. Hear the voice to locate the terminations where the fault occurs.
7. Locate the fault segment by segment.
Procedure
l Figure 35-3 shows the application scenario of dialing fault location for a specified user.

Figure 35-3 Networking diagram
T1: TDM termination T2: IP termination T3: IP termination T4: IP termination
After a voice quality fault such as one-way audio, no audio, noise, or cross-talking occurs
between MS 1 and MS 2, you can locate the fault by initiating loopbacks on the
UMG8900 side for T1, T2, T3, and T4.
l Locate faults by initiating loopbacks on the UMG8900 side.
1. Connect the MSC server to the PC where the LMT is installed, and then log in to the
MSC server through the LMT.
2. On the LMT of the MSC server, create a task.
NOTE
For details on message tracing through the LMT of the MSC server, see the user manuals of
the MSC server.
3. Connect the UMG8900 to the PC where the LMT is installed, and then log in to the
UMG8900 through the LMT.
4. On the LMT of the UMG8900, create a User call trace task.

Double-click User call trace. The Create User call trace dialog box is displayed.
Specify the parameters, and then click OK.
5. Perform a dialing test by using the number of the traced MS.

6. Determine the context ID of the call.
Determine the context ID of the call through traced user messages on the LMT of the
UMG8900. The context ID of the call specific to the number of the PSTN phone is
shown in hexadecimal digits in the red frame.
7. On the LMT of UMG8900 1, run DSP CTXINFO to query information about T1 and
T2.
Run DSP CTXINFO: CID=*; (* represents the ID of the current call) to query
Index of T1 and T2.
For example, if CID is 2293798, the sample output is as follows:

%%DSP CTXINFO: CID=2293798;%%
Basic information of context:

***********************************************************
Initialization time VMGW index CMU No.
2007-06-26 17:02:18 15 32
***********************************************************
Information of terminations:
***********************************************************
Index TID(High) TID(Low)Type
0 0x00000000 0x20230002 ATM
1 0x00000000 0x3000044D IP
***********************************************************

Information of topology:
***********************************************************
Index(Begin) Index(End) StreamIndex Relation
0 1 0 Bothway
***********************************************************
Information of Stream:
***********************************************************
StreamIndex StreamID 0 0x1
***********************************************************
--- END
NOTE
A termination that starts with 0x20 is an ATM termination; a termination that starts with 0x30
is an IP termination; a termination that starts with 0x40 is a TDM termination.
The rightmost 15 digits in the TID (low) field indicate the session ID of a user.
8. Perform an outloop for T1 on the LMT of UMG8900 1.
(1) Run LOP E1 to perform an outloop for T1.
LOP E1: FN=*, SN=*, LOC=PORT, MODE=OUTLOP, PN=*; Here, FN,
SN, and PN represent the frame number, slot number, and port number of the E1
board, respectively. For details, see the help of the command.
(2) Check whether the voice quality fault is rectified.
– If not, it indicates that the user access (UA) frame causes the fault.
– If the voice quality fault is rectified, cancel the loopback for T1.
(3) Cancel the loopback.
Run LOP E1 to cancel the loopback for T1.LOP E1: FN=*, SN=*,
LOC=PORT, MODE=DELLOP, PN=*; Here, FN, SN, and PN represent the
frame number, slot number, and port number of the E1 board, respectively. For
details, see the help of the command.
9. Perform an inloop for T2 on the LMT of UMG8900 1.
(1) Check TID of the IP termination against the command output in Step 7.
(2) Perform an inloop for T2 by referring to Step 8.
– If not, it indicates that UMG8900 1 causes the fault.
– If yes, cancel the loopback for T2.
10. Determine the indexes of T3 and T4 through the LMT of UMG8900 2.
(1) Run DSP CALLRSC on the LMT of UMG8900 2 and enter a context ID to
check resource statistics specific to the context ID.
Run DSP CALLRSC: QM=CID, CID=*; (* represents the ID of the current
call) to query resource statistics specific to the context ID.
Obtain the indexes of T3 and T4 based on the values of SrcRscID(L) and
DestRscID(L).
Topo. in Context
--------------
StreamID SrcRscID(H) SrcRscID(L) SrcRscType DestRscID(H) DestRscID(L)
DestRscType Topo
1 0x00000000 0x3000055D IP 0x00000000 0x3000066D

P BOTHWAY
(2) Based on Local IP address and Remote IP address of T3 and T4, determine
the locations of the two terminations on UMG8900 2.

Take the IP termination 0x3000055D as an example. Based on Remote IP

address of T3 and T4, and the gateway IP addresses of UMG8900 1 and BSC
2, you can determine the indexes of the two terminations.
IP Resource (0x3000055D) Information
------------------------------
Frame No. = 1
Slot No. = 15
Board No. = 0
Board Type = HRB
Resource Type = TC
ource domain ID = 0
Local IP address = 10.110.50.235
Local Port No. = 132
Remote IP address = 10.110.50.236
Remote Port No. = 4
11. Perform an outloop for T3 on the LMT of UMG8900 2.

(2) Perform an outloop for T3 by referring to Step 8.
– If not, it indicates that the bearer network of the CN causes the fault.
– If yes, cancel the outloop for T3.
12. Perform an inloop for T4 on the LMT of UMG8900 2.
(2) Perform an inloop for T4 by referring to Step 8.
– If not, it indicates that UMG8900 2 causes the fault.
– If yes, it indicates that the bearer of BSC 2/RNC 2 or of the A/Iu interface
causes the fault.
----End
35.2 Dialing Test for the Specified Resource

restrictions, and operation of the dialing test for the specified resource.
35.2.1 Overview of Dialing Test for the Specified Resource

35.2.2 Availability of Dialing Test for the Specified Resource
35.2.3 Dialing Test for the Specified TC/EC Resource
This section describes how to locate a fault through dialing tests for the specified transcoder/
echo cancellation (TC/EC) resource.
35.2.1 Overview of Dialing Test for the Specified Resource


Feature Definition
Currently, you cannot perform dialing tests for the media gateway (MGW) by using the
transcoder/echo cancellation (TC/EC) channels. If noises are present, you cannot determine
whether noises are caused by TC/EC chips on the MGW by checking every TC/EC chip. If the
available fault location information indicates that the fault may be caused by the TC/EC on a
certain VPU, the fault still cannot be located through dialing tests for a specified TC/EC channel.
This feature enables you to determine whether noises are caused by a TC/EC chip by checking
all TC/EC chips on the MGW through dialing tests for TC/EC channels.
l The specified TC resource serves as the announcement playing TC.

The applications in this scenario are as follows:
– Call between two users on the same MGW in 2G networking
– Call between two users on the same MGW in code division multiplex access (CDMA)
networking
– Call between two users on the same MGW in next generation network (NGN)
networking
– Call between two users on the same MGW in universal mobile telecommunications
system (UMTS) networking using transcoder free operation (TrFO)
– Hairpin call between two users on the same MGW serving as an access gateway (AG)
– Call between two users on the same MGW in 2G pool networking (using different
VMGWs on one physical MGW to save TC resources)
– Ringback tone playing by the called local exchange to the caller in 2G, CDMA, or 3G
networking
For these calls, TC is employed only for playing the ringback tone. For the networking
where the MGW acts as the AG, TC is employed for dial tone playing and number receiving.
The TC is released after number receiving and then applied for again for playing the
ringback tone to a caller. Therefore, the specified TC is employed for dial tone playing,
number receiving, and ringback tone playing.

Figure 35-4 GSM 2G networking of the dialing test for calls between users on the same MGW
l The specified TC resource serves as the number receiving TC.

If the media gateway controller (MGC) applies for TC resources for number receiving, the
specified TC must serve as the number receiving TC for dialing tests.
The specified TC serves as the number receiving TC only for the networking where the
MGW acts as the trunk gateway (TG). For the networking where the MGW acts as the AG,
the TC for dial tone playing is assigned and then this TC is employed for number receiving.
Therefore, in AG networking after completing dial tone playing and number receiving, the
specified TC serves as the announcement playing TC for dialing tests.
Figure 35-5 Networking of the dialing test for number receiving TC in TG networking
l The specified TC resource serves as the topology TC.


– Inter-office call or call between users of IP bearer of different NMGWb interfaces of

the same office in 2G, CDMA, or 3G networking
– Non-hairpin call between two users on the same MGW in AG networking
– TG networking
The specified TC serves as the topology TC to associate time division multiplexing (TDM)
terminations with IP terminations.
Figure 35-6 GSM 2G networking of the dialing test for calls between users on different MGWs
l The specified TC serves as one of the double topology TCs.

– Inconsistent codecs of the ATM-based or IP-based Iu interface and the IP-based Nb
interface in 3G networking
– Inconsistent codecs of the GSM or CDMA IP-based A interface and the IP-based Nb
interface
– No consistent codec through the TrFO negotiation
Therefore, double TCs are required for codec conversion on both sides.
Figure 35-7 Networking of the dialing test for inconsistent codecs of the Iu and Nb interfaces
in inter-office calls in 3G networking

l The EC resource is specified.

This scenario involves the networking of global system for mobile communications (GSM)
2G local exchange, CDMA local exchange, AG, gateway exchange between a public
switched telephone network (PSTN) and a public land mobile network (PLMN), and TG
in the fixed network.
Figure 35-8 Networking of the dialing test for the specified EC for two users on the same
MGW in AG networking
Service Benefits
Dialing test for the specified This feature enables you to Not involved
resource determine whether noises in
a call are caused by a TC/EC
fault.

Dialing test for the specified resource l You can perform a dialing test for either
the specified TC or the specified EC on one
board.
l The man-machine language (MML)
commands involved in this feature are
hidden commands. The configuration that
specifies the TC or EC to be checked
cannot be modified.
l You can start only one user number tracing
task at a time on the MGW.
35.2.2 Availability of Dialing Test for the Specified Resource

Required NEs
Feature Required NE
Dialing test for the specified resource MGC and MGW
Version Support
Dialing test for the specified resource V200R008C01 and later
35.2.3 Dialing Test for the Specified TC/EC Resource

This section describes how to locate a fault through dialing tests for the specified transcoder/
echo cancellation (TC/EC) resource.
Context
This feature enables you to determine whether noises in a call are caused by a TC/EC chip by
checking all TC/EC chips on the media gateway (MGW) through dialing tests for TC/EC
channels.

l You can perform a dialing test for either the specified TC or the specified EC. That is, you
cannot perform dialing tests for both TC and EC at the same time.
l The man-machine language (MML) commands involved in this feature are hidden
commands. The configuration that specifies the TC or EC to be checked cannot be modified.
l If the CMU is switched or reset, or the VPU is reset, the configuration is no longer effective.
To perform dialing tests for the specified resource, you must create a user number tracing
task on the media gateway controller (MGC), and start a full flow call tracing task and
specify the resource for tests on the MGW.
Procedure
Step 1 Create a user number tracing task on the local maintenance terminal (LMT) of the MGC.
NOTE
For details on message tracing through the LMT of the MSC server, see the user manuals of the MSC
server.
Step 2 Create a full flow call tracing task on the LMT of the MGW. See Figure 35-9.
Figure 35-9 Parameter settings for creating a full flow call tracing task on the MGW
Set Trace Type to USERID and TCEC to TRUE. See Figure 35-10.

Figure 35-10 Creating a full flow call tracing task
Step 3 Run DSP RSCDESP to query the resources on the board where dialing tests for the specified
resource are performed. The example is as follows:
%%DSP RSCDESP: BT=VPU, BN=109;%%
Display the resource state

------------
Board Type Board No. Resource Type Card No. DSP No. Start channel No. End channel No.
VPU 109 TC 0 0 0 47
VPU 109 TC 0 1 0 47
VPU 109 TC 0 2 0 47
VPU 109 TC 0 3 0 47
VPU 109 TC 0 4 0 47
VPU 109 TC 0 5 0 47
VPU 109 TC 0 6 0 47
VPU 109 TC 0 7 0 47
VPU 109 EC 0 0 0 255
VPU 109 EC 0 1 256 511
VPU 109 EC 0 2 512 767
VPU 109 EC 0 3 768 1023
--- END

Step 4 Specify the resource for dialing tests on the MGW.

Run SET USEDRSC to specify the TC resource for dialing tests. The example is as follows:
//Perform dialing tests for the specified TC resource on channel 20 of
chip 0 on VPU 109. The TC serves as the topology TC.
SET USEDRSC: BT=VPU, RT=TC, RF=TOPO, CHIP=0, CHN=20, BN=109;
Step 5 Run LST USEDRSC to check the resource of dialing tests. The example is as follows:
%%LST USEDRSC:;%%
List the used resource information

------------
Board Type Board No. Resource Type Tc Function DSP No. Channel No.
VPU 109 TC TOPO 0 20
--- END
Step 6 Use a terminal to perform dialing tests.

Step 7 Run DSP USEDRSC to query the usage of the resource of dialing tests.
If the dialing test occupies the specified resource, the example is as follows:
%%DSP USEDRSC:;%%
Display the used resource state

------------
Board Type Board No. Resource Type Tc Function DSP No. Channel No. Used Resource Ocuppy State
VPU 109 TC TOPO 0 20 Success

--- END
If the specified resource for dialing tests is occupied by another call, the example is as follows:
%%DSP USEDRSC:;%%
Display the used resource state

------------
Board Type Board No. Resource Type Tc Function DSP No. Channel No. Used Resource Ocuppy State
VPU 109 TC TOPO 0 20 Channel is ocuppied by other call
--- END
Step 8 If noises are present in the call using the resource, it indicates that the chip is faulty.
----End
Postrequisite
After the call is terminated, if you do not intend to perform another test, set TCEC to FALSE
in the full flow call tracing task.

Feature Description 36 Electronic Label
36 Electronic Label
About This Chapter
restrictions, and operation of electronic label.
36.1 Overview of Electronic Label

36.2 Availability of Electronic Label
36.3 Operation of Electronic Label

36 Electronic Label Feature Description
36.1 Overview of Electronic Label

Feature Definition
This feature enables users to write electronic labels for field replaceable units (FRUs), export
electronic labels of all FRUs governed by the OMU, display electronic label files. At present,
you can export electronic labels for FRUs through the MIMU software.
You can export and display electronic labels by running GET ELABEL and DSP ELABEL.
The electronic label feature is used to export and display the electronic label of an FRU or a
pluggable optical module.
Service Benefits
Table 36-1 Service benefits of electronic label

This feature enables users to export and

Electronic label display electronic labels and to export Not involved
electronic labels into a file.
Table 36-2 Function restrictions of electronic label

Electronic label When setting electronic labels, ensure the specification of electronic
labels files by users and OMU does not check the file format.
36.2 Availability of Electronic Label

Required NEs
Table 36-3 Required NEs for electronic label

Feature Required NE
Electronic label MGW

Feature Description 36 Electronic Label
Version Support
Table 36-4 Versions supporting electronic label

Electronic label R007 and later
36.3 Operation of Electronic Label

Procedure
Step 1 Run GET ELABEL to obtain the electronic label.
Obtain the electronic labels of all field replaceable units (FRUs) in slot 12 of frame 1. Store the
obtained electronic labels to d:/flashinfo_get.fls on the server whose IP address is 10.110.28.88.
GET ELABEL: SRN=1, SN=12, PRTL=FTP, SVRIP="10.110.28.88", USR="bam",
PWD="bam", FPAN="d:/flashinfo_get.fls";
Step 2 Run DSP ELABEL to query the electronic labels.
1. Query the electronic labels of all FRUs in slot 12 of frame 1 on the user interface (UI).
DSP ELABEL: SRN=1, SN=12, BP=FRONT;
2. Query the electronic labels of subboards in front and back slots 12 of frame 1 on the UI.
DSP ELABEL: OT=SB, SRN=1, SN=12;
----End

Feature Description 37 Power Consumption Reduction
37 Power Consumption Reduction
About This Chapter
restrictions, data configuration, and related performance measurement items of power
37.1 Overview of Power Consumption Reduction

37.2 Availability of Power Consumption Reduction
37.4 Related Performance Measurement Items
This section describes the related performance measurement items of this feature.

37 Power Consumption Reduction Feature Description
37.1 Overview of Power Consumption Reduction

Feature Definition
The energy consumption of devices is widely concerned. Besides saving operation expenditure
(OPEX) of carriers, reducing the energy consumption is beneficial to the environment and is the
social responsibility.
This feature refers to that the media gateway (MGW) automatically powers off some VPUs or
ECUs to save electric power when the traffic is low. Automatic power-off of a board indicates
that the MGW decreases the system capacity by powering off some boards when the traffic is
low to reduce energy consumption.
The actual result of power consumption reduction is related to the average resource usage of
total resources (average number of occupied resources/total number of system resources) and
average resource usage of in-service boards (average resource usage/total number resources
occupied by in-service boards) after the power consumption reduction function is enabled. If
the average resource usage is 30%, the average resource usage on the in-service boards after the
power consumption reduction function is enabled is 50%. The number of boards required for
processing services can be calculated by dividing 30% by 50%. Therefore, 60% of boards can
support the current services. Thus, 40% of the power consumption is saved.
The related concepts are described as follows:
l Grouping boards: To avoid that users cannot access a type of services because the board is
powered off automatically, ensure that boards with the same resource type are in the same
group.
l Power-off operation: Before the average resource usage on in-service boards is lower than
the power-off threshold in five minutes, some in-service boards need to be powered off to
increase the average resource usage to a proper value, that is, the power-off recovery
threshold.
l Power-on operation: Before the average resource usage on in-service boards exceeds the
power-on threshold in five minutes, some boards need to be powered on to decrease the
average resource usage to a proper value, that is, the power-on recovery threshold.
l TC or EC resource migration: Before powering off the VPU or ECU, deactivate the board
and forbid any access to services. Services on the VPU or ECU are released. If the resources
are not released in five minutes, migrate TC or EC resources on the VPUs or ECUs to the
boards that are not deactivated to avoid service interruption.
Figure 37-1 shows the relation between the average resource usage and each threshold, that is,
power-on threshold, power-off threshold, power-on recovery threshold, and power-off recovery
threshold.

Feature Description 37 Power Consumption Reduction
Figure 37-1 Relation between the resource usage and each threshold
Service Benefits
Power consumption This feature saves electric Not applicable.

reduction power and cost for carriers.
Feature Function Restrictions
Power consumption reduction l Before the upgrade, disable the automatic

power-off function.
l The VPU whose services cannot be
migrated, for example, the VPU that is
configured with asynchronous tones,
cannot be powered off for power
37.2 Availability of Power Consumption Reduction


37 Power Consumption Reduction Feature Description
Required NEs
Feature Required NE
Power consumption reduction MGW

Feature Version
Power consumption reduction V200R008C01 and later

37.4 Related Performance Measurement Items

This section describes the related performance measurement items of this feature.
Statistics of Power off
l Number of Power-off Times
l Total Number of Power-off Times
l Power-off Duration
l Total Power-off Duration

Feature Description A Glossary
A Glossary
Numerics
3GPP See 3rd generation partnership project
3rd generation Founded in 1998, a project which aims to expedite the development of open, globally
partnership project accepted technical specifications for the Universal Mobile Telecommunications System
(UMTS), including the WCDMA and TD-SCDMA specifications. The WCDMA
specifications developed by the 3GPP include 3GPP R99, R4, R5, R6, and R7.
A
A interface An interface between the BSS and MSC. It is a 2G interface. Its physical link adopts the
2.048 Mbit/s PCM digital transmission link to transmit the information related to call
processing, mobility management and BSS management. It adopts the BSSAP protocol.
AAL See ATM adaptation layer
access A link between the customer and the telecommunication network. Many technologies,
such as the copper wire, optical fiber, mobile, microwave and satellite, are used for
access.
access control list A series of sequential rules consisting of permit | deny statements. In firewall, after ACL
is applied to an interface on the router, the router decides which packet can be forwarded
and which packet should be denied. In QoS, ACL is used to classify traffic.
access network A local part of a telecommunication network. It is closest to the subscriber's home or
enterprise and opposite to the core network.
ACL See access control list
add/drop multiplexer A digital multiplexing device that offers interfaces between different signals in a
network.
address A number that identifies the location of a device in a network or the location on the hard
disk or the memory, such as the IPv4 address or IPv6 address of a network entity.
address resolution A protocol used in the IP network to map an IP address to a MAC address and thus enable
protocol the transmission of IP datagram across a LAN.
Issue 01 (2010-01-12) Huawei Proprietary and Confidential A-1

A Glossary Feature Description
adjacency A portion of the local routing information which pertains to the reachability of a single
neighboring ES or IS over a single circuit. Adjacencies are used as input to the Decision
Process for forming paths through the routing domain. A separate adjacency is created
for each neighbor on a circuit, and for each level of routing (i.e. level 1 and level 2) on
a broadcast circuit.
ADM See add/drop multiplexer
AGC See automatic gain control
AH See authentication header
american national The American National Standards Institute is a voluntary membership organization (run
standards institute with private funding) that develops national consensus standards for a wide variety of
devices and procedures.
AN See access network
analog signal A signal sent by an analog system without restriction specified on transmitted data.
ANSI See american national standards institute
application service A business that provides computer-based services to customers over a network.
provider
APS See automatic protection switching
APS 1+1 Indicates that the protective group uses the master/slave interfaces mode. The APS
protective mode is supported. One protection group has one work channel and one
protection channel. The switchover is performed based on the APS protocol. In the
normal state, the work channel is working. If an APS switchover event is detected by
the work channel, the services are switched to the protection channel.
APS 1:N Indicates that the protective group uses one protective channel and N pieces of working
channels. The APS protective mode is supported. One protection group has N work
channels and one protection channel. The switchover is performed based on the APS
protocol. In the normal state, N work channels are working. If an APS switchover event
is detected by one work channel, the services are switched to the protection channel. The
APS protection requires the interconnected device to support the APS protocol.
area A routing subdomain that maintains the detailed routing information about its own
internal composition and the routing information enabling it to reach the other routing
subdomains. In IS-IS and OSPF, it is a set of adjacent networks and hosts that have been
administratively grouped together within an autonomous system. In IS-IS, an area
corresponds to a Level 1 subdomain.
ARP See address resolution protocol
ASP See application service provider
association Logical association or channels that are established between two SCTP terminations
according to the four-handshake system of the SCTP protocol.
asynchronous A digital announcement not always played by the MGW from beginning when receiving
announcement 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.
A-2 Huawei Proprietary and Confidential Issue 01 (2010-01-12)

asynchronous transfer A data transfer technology based on cell, in which packets allocation relies on channel
mode demand. It supports fast packet switching so that the network resources can be used
efficiently. The size of a cell is fixed, 53 bytes in total. Here, 48 bytes form the payload
and the other five bytes form the header.
ATM See asynchronous transfer mode
ATM adaptation layer A collection of protocols that enable the voice, data, image, and video traffic to run over
an ATM network.
ATM switch A switch to transmit cells through an ATM network. It receives the incoming cell from
an ATM endpoint or another ATM switch, analyzes and updates the cell header
information, and then switches the cell to an output interface towards the destination.
authentication header It is a type of IPv6 extension headers, and is also a kind of IPsec. It ensures data integrity,
authenticates original identities, and provides some optional and limited anti-replay
services for IP.
auto negotiation A procedure defined in Fast Ethernet in which a device accords with another device on
a transmission mode before transmitting data. The mode can be 100 Mbit/s or 10 Mbit/
s and full or half duplex.
automatic gain control A process or means by which gain is automatically adjusted in a specified manner as a
function of a specified parameter, such as received signal level.
automatic protection Automatic Protection Switching (APS) is the capability of a transmission system to
switching detect a failure on a working facility and to switch to a standby facility to recover the
traffic.
available user capacity A capacity that specifies the number of new access users that the MSC server can
accommodate. For example, if the initial capacity of the MSC server is 2000000, the
available user capacity is 1500000 on condition that 500000 users are currently on line.
B
backup flag It specifies whether the CN node is centralized backup MSC. The information about all
the registered mobile phones in the pool is backed up to the centralized backup MSC.
bandwidth A range of transmission frequencies that a transmission line or channel can carry in a
network. In fact, it is the difference between the highest and lowest frequencies the
transmission line or channel. The greater the bandwidth, the faster the data transfer rate.
base station A fixed radio transmitter/receiver that relays signals from and to the mobile terminals or
handsets electronically within a specified range. It accommodates the devices that are
necessary to set up and complete calls on handsets, such as the antenna and computer.
base station controller A logical entity that connects the BTS with the MSC in a GSM network. It interworks
with the BTS through the Abis interface, the MSC through the A interface. It provides
the following functions: Radio resource management, Base station management, Power
control, Handover control, and Traffic measurement. One BSC controls and manages
one or more BTSs in an actual network.
base station subsystem A physical device that gives radio coverage to a specific geographical zone called a cell.
It consists of the BTS and BSC.

base station subsystem The protocol employed across the A interface in the GSM system. It is used to transport
application part MM (Mobility Management) and CM (Connection Management) information to and
from the MSC (Mobile Switching Centre). The BSS Application Part (BSSAP) is split
into two sub application parts, these are: the BSS Management Application Part
(BSSMAP) and the Direct Transfer Application Part (DTAP).
base station subsystem This protocol is also used to convey general BSS (Base Station System) control
management information between the MSC (Mobile Switching Centre) and the BSS. An example is
application part the allocation of traffic channels between the MSC and the BSS.
BFD See bidirectional forwarding detection
bidirectional A simple hello mechanism to detect failures in a network and work with the routing
forwarding detection protocols to expedite failure detection.
bit The smallest unit of information that can be used by a computer. It is a binary digit that
can be 0 or 1.
BITS See building integrated timing supply system
bits per second A rate at which the individual bits are transmitted through a communication link or
circuit. Its unit can be bit/s, kbit/s, and Mbit/s.
BPS See bits per second
broadband A term that indicates the capacity with enough bandwidth to transmit voice, data and
video signals. It supports transmission of large amount of information.
broadcast An operation of sending electromagnetic signals to many receivers through the air or the
public service network so that the information or programs can be transmitted at the same
time. It also refers to the telecommunication mode that information sent by a terminal
can be received by multiple receiving terminals in the computer network at the same
time.
BSC See base station controller
BSS See base station subsystem
BSSAP See base station subsystem application part
BSSMAP See base station subsystem management application part
BTS See base station
building integrated In the situation of multiple synchronous nodes or communication devices, one can use
timing supply system a device to set up a clock system on the hinge of the telecom network to connect the
synchronous network as a whole, and provide satisfactory synchronous base signals to
the building integrated device.
burst A process of forming data into a block of the proper size, uninterruptedly sending the
block in a fast operation, waiting for a long time, and preparing for the next fast sending.
busy tone A tone indicating that the called party is busy.
byte A unit of computer information equal to eight bits.
C
call loss A process during which a call cannot be set up or released owing to an error or failure.
CAS See channel associated signaling

CAS multiframe A multiframe set up based on timeslot 16. Each CAS multiframe contains 16 E1 PCM
frames. Among the eight bits of timeslot 16 in the first of the 16 frames, the first four
bits are used for multiframe synchronization. The multiframe alignment signal (MFAS)
for synchronization is 0000. The last four bits are used as the not multiframe alignment
signal (NMFAS). The NMFAS is XYXX. For the other 15 frames, timeslot 16 is used
to transmit the exchange and multiplexing (E&M) signaling corresponding to each
timeslot.
CBR See constant bit rate
CCS See common channel signaling
CDMA See code division multiple access
CDMA2000 A 3G technology developed by Qualcomm of the US. Technology competitive with
WCDMA, upgraded form CDMA1, and developed by the GSM community as a
worldwide standard for 3G mobile.
cell A geographic area in a cellular mobile telephone system where a cell site controls all
cellular transmission.
centralized backup An MSC server in the MSC pool. This MSC server backs up the user data of each MSC
MSC server server/VLR in the MSC pool. In addition, the MSC server backs up the call services for
single MSC servers in the MSC pool when they are faulty and restores the call services
for the faulty MSC servers after they are recovered. Different from other MSC servers,
no NRI is available for the centralized backup MSC server, and the uplink SCCP CR
messages are not distributed to the centralized backup MSC server.
centralized forwarding Forwarding of OMC packets, H.248 packets and SIGTRAN packets through one IP
interface. It can save IP address resources and avoid a complex network.
challenge handshake A method of authentication that you can use when connecting to an ISP that allows you
authentication protocol to log on automatically.
channel A telecommunication path of a specific capacity and/or at a specific speed between two
or more locations in a network. The channel can be established through wire, radio
(microwave), fiber or a combination of the three.
channel A channel refers to the CDR processing mode and storage directories that match a sorting
condition. A channel corresponds to a CDR storage path.
channel associated A signaling system in which the signaling information is transmitted within the voice
signaling channel. China Signaling System No. 1 is a kind of CAS signaling.
CHAP See challenge handshake authentication protocol
circuit pool A group of trunk circuits that are identical in bearer capability.
CNG See comfort noise generation
code division multiple CDMA is a form of wireless multiplexing, in which data can be sent over multiple
access frequencies simultaneously, optimizing the use of available bandwidth. In a CDMA
system, data is broken into packets, each of which are given a unique identifier, so that
they can be sent out over multiple frequencies and then re-built in the correct order by
the receiver.
comfort noise The CNG is the algorithm that is used to generate comfort noise. The CNG expands the
generation lower rate noise modeling data into a standard frame of G.729 data by filling in some of
the less significant parameters. It then performs G.729 synthesis to generate the comfort
noise.

common channel A signaling system used in telephone networks that separates signaling information from
signaling user data. A specified channel is exclusively designated to carry signaling information
for all other channels in the system. China Signaling System No. 7 is a kind of CCS
signaling.
congestion An extra intra-network or inter-network traffic resulting in decreasing network service
efficiency.
constant bit rate An ATM service category supporting applications like voice and video that require a
constant bit rate.
CRC-4 multiframe A multiframe is recommended by ITU-T G.704 and set up based on the first bit of timeslot
0. The CRC-4 multiframe is totally different from the CAS multiframe in principle and
implementation. Each CRC-4 multiframe contains 16 PCM frames. Each CRC-4
multiframe consists of two CRC-4 sub-multiframes. Each CRC-4 sub-multiframe is a
CRC-4 check block that contains 256 x 8 = 2048 bits. Bits C1 to C4 of a check block
can check the previous check block.
D
differentiated services Values for a 6-bit field defined for the IPv4 and IPv6 packet headers that enhance class
code point of service (CoS) distinctions in routers.
digital network A telecommunication network where information is first converted into distinct
electronic pulses and then transmitted to a digital bit stream.
DNS See domain name service/server
domain name service/ An Internet protocol to relate the service names or URLs to an IP address and conversely.
server
double wrapping A coding mode. In binary codec, parameters of the OCTET STRING type are coded with
the standard BER grammar, and then H.248 binary coding is performed. It is stipulated
in the H.248V2 protocol. For details, see the H.248V2 protocol.
DSCP See differentiated services code point
DTMF See dual tone multi-frequency
dual homing A solution in which signaling transfer points are configured in pairs, that is, each
signaling point connects two signaling transfer points. Dual homing solutions can be 1
+1 master/slave backup, 1+1 mutual aid, N+1 backup, and N+1 mutual aid. The dual
homing solution is a network security solution put forward by Huawei first. This solution
is used to ensure the security of MSC servers. Nowadays, the dual homing solution is
applied in multiple commercial networks.
dual tone multi- It is an analogue inband access signaling system.
frequency
DW See double wrapping
E
E-LABEL See electronic label
E1 A European standard for high-speed data transmission at 2.048 Mbit/s. It provides 32 x
64 kbit/s channels.
EC See echo cancellation

echo In the traditional PSTN network, an echo is caused by the 2/4 wire conversion. In a
common session, the end-to-end delay is small, an echo can be rapidly transmitted to the
ears of speakers, and thus it is not easily felt. In long-distance calls or international long-
distance calls, however, the end-to-end delay is big, and the echo canceller must be used
to control echoes.
echo cancellation Echo cancellation indicates the configuration of an echo canceller (usually called EC)
in the communication network with the echo problem to reduce or eliminate echoes.
EFR See enhanced full rate
electronic label The label that stores the codes for identifying objects in the format of electronic data.
With features such as large capacity, high confidentiality, read-write capability, and
working in hard conditions, it is much better than other electronic labels.
element management An element management system (EMS) manages one or more of a specific type of
system network elements (NEs). An EMS allows the user to manage all the features of each NE
individually, but not the communication between NEs - this is done by the network
management system (NMS).
EMS See element management system
encapsulating security Encapsulating Security Payload is used in transmission mode and tunnel mode. It adopts
payload the encryption and authentication mechanism and provides services such as data source
authentication, data completeness, anti-replay, and secret security.
encapsulation A procedure of packetizing a protocol data unit in a group of protocol header and tail.
encryption A method used to guarantee the security and authenticity of data in end-to-end
transmission. Encryption can be implemented through technologies such as data pseudo-
random alteration and data substitution.
end system A network entity that sends and receives packets in IS-IS.
enhanced full rate A technology that improves the quality of calls made on a digital mobile network. It is
achieved through more efficient use of bandwidth.
equipment serial It is a number assigned to the equipment by the manufacture for identification and
number tracking.
error correction Technique for restoring integrity in data that is corrupted during transmission. It requires
additional information to be sent with the original data and allows the data to be
reconstructed from this information if the original data is corrupted.
ESN See equipment serial number
ESP See encapsulating security payload
ethernet A local technology based on CSMA/CD. The speed of the Ethernet can be 10 Mbit/s,
100 Mbit/s, 1000 Mbit/ s or 10000 Mbit/s. It is easily maintained and of high reliability.
extend superframe The multiframe format of T1. Each multiframe comprises of 24 single frames.
F
file transfer protocol FTP is a commonly used application. It is the Internet standard for file transfer. The file
transfer provided by FTP copies a complete file from one system to another system. To
use FTP, we need an account to log in to the server, or we need to use it with a server
that allows anonymous FTP.

firewall A security gateway that is positioned between two different networks, usually between
a trusted network and the Internet.
flow Data amount through a piece of equipment within a unit of time.
flow control A method used to control the data packets that traverse a device so that the device is not
overloaded because of heavy traffic.
FR AMR codec A full rate AMR codec algorithm that can be used only in GSM networks. The bit rate
algorithm can be 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, or 12.2 kbit/s. The AMR algorithm is an adaptive rate-based codec algorithm, which
adopts the algebraic code excitation linear prediction (ACELP) mechanism.
frame Logical grouping of information sent as a data link layer unit over a transmission
medium. Often refers to the header and the trailer, used for synchronization and error
control, that surround the user data contained in the unit. The terms cell, datagram,
message, packet, and segment also are used to describe logical information groupings at
various layers of the OSI reference model and in various technology circles.
frequency The number of completing tasks per unit of time with Hz as its unit. 1 Hz = 1 cycle per
second.
frequency shift keying FSK is used in low speed modems to modulate data that uses two frequencies, one of
which is used to represent a binary one and the other a binary zero. In full-duplex
transmission, two different frequencies are used in each direction, which leads to four
different frequencies being used.
FSK See frequency shift keying
FTP See file transfer protocol
full duplex It is a mode to transmit signals along a bearer channel or carrier in both directions at the
same time.
full rate A rate for transmitting data services. The service bandwidth can be 9.6 kbit/s, 4.8 kbit/
s, or 2.4 kbit/s.
G
gateway A device that implements protocol conversion between different devices or networks.
gateway GPRS support It is short for gateway GPRS support node. In the IMS, a UE can find the entry point of
node the IMS through the GPRS process. That is, it can obtain the IP address of the P-CSCF
through the GGSN.
gCause An event type stipulated in the H.248 protocol.
global system for Abbreviated GSM. The second-generation mobile networking standard defined by ETSI.
mobile
communications
GSM See global system for mobile communications

GSM EFR codec The GSM enhanced full rate (EFR) algorithm, a compressed mixed codec algorithm
algorithm based on the GSM network. It adopts the code excited linear prediction (CELP)
technology, and the compressed bit rate is 12.2 kbit/s. Fully considering the spectrum
transition characteristic of the voice, this codec mode improves the codec algorithm of
the voice source to make the voice quality clear and sufficient, thus improving the voice
quality greatly. When the bandwidth used in the EFR algorithm is the same as that in the
FR algorithm, the EFR algorithm can improve the call quality under the condition of
weak signals through a more advanced algorithm. This codec mode is used in GSM
networks.
GSM FR codec The GSM full rate (FR) algorithm, a compressed mixed codec algorithm. It adopts the
algorithm regular-pulse excitation-long term prediction (RPE-LTP) codec technology, and the
compressed bit rate is 13 kbit/s. The outstanding characteristic of this codec mode is its
stability, namely, it has relative stable voice quality under different mobile noise
backgrounds and unstable wireless transmission condition (different error modes). This
codec mode is used in GSM networks.
half rate A variant of GSM, Half-Rate doubles system capacity by more efficient speech coding.
The conversion of the voice to digital packets can be done 3 ways, using Half Rate coding
(HR), Full Rate coding (FR) or Enhanced Full Rate coding.
HR See half rate
HR AMR codec A half rate AMR codec algorithm that can be used only in GSM networks. The bit rate
algorithm can be 4.75 kbit/s, 5.15 kbit/s, 5.90 kbit/s, 6.70 kbit/s, 7.40 kbit/s, or 7.95 kbit/s. The
AMR algorithm is an adaptive rate-based codec algorithm, which adopts the algebraic
code excitation linear prediction (ACELP) mechanism.
HR codec algorithm A half rate GSM voice encoding algorithm.
ICMP See internet control message protocol

IETF See internet engineering task force
IKE See internet key exchange
integrated services Integrated Services Digital Network (ISDN) is comprised of digital telephony and data-
digital network transport services offered by regional telephone carriers. ISDN involves the digitization
of the telephone network, which permits voice, data, text, graphics, music, video, and
other source material to be transmitted over existing telephone wires.
intermediate system-to- Intermediate System-to-Intermediate System. OSI link-state hierarchical routing
intermediate system protocol based on DECnet Phase V routing whereby ISs (routers) exchange routing
information based on a single metric to determine network topology.
international standards A United Nations agency, based in Geneva, Switzerland, responsible for worldwide
organization standards, including many networking standards. The OSI reference model, published
as ISO standard 7498, was jointly developed by the ISO and the ITU.
international A United Nations agency, one of the most important and influential recommendation
telecommunication bodies, responsible for recommending standards for telecommunication (ITU-T) and
union radio networks (ITU-R).

international An organization that establishes recommendations and coordinates the development of

telecommunication telecommunication standards for the entire world.
union
telecommunication
standardization
internet A global network that uses IP to link various physical networks into a single network.
internet control An extension to the Internet Protocol. It allows for the generation of error messages, test
message protocol packets and informational messages related to IP.
internet engineering An international community of network designers, operators, vendors, and researchers.
task force IETF focuses on the evolution of the Internet architecture and the smooth operation of
the Internet.
internet key exchange An optional function of the IPSec that provides ways for encryption. It is used to provide
the function of sharing the internet key through negotiating whether the AH Header and
the ESP Header of the IPSec packet are consistent.
internet protocol A protocol that enables data to be sent from one point to another on the Internet.
internet security A protocol that allows the message receiver to get a public key and use digital certificates
association and key to authenticate the sender's identity.
management protocol
IP See internet protocol
IP address An exclusive address on the Internet for each interface, which is 32 bits long. An IP
address indicates a connection to a network, not a host.
IP security protocol A general designation of a set of open protocols. With the IPSec, the encryption and data
source verification between specific communication parties can ensure the
confidentiality, intactness, and authenticity of data packets when they are transmitted
over the Internet.
IPSec See IP security protocol
IS-IS See intermediate system-to-intermediate system
ISAKMP See internet security association and key management protocol
ISDN See integrated services digital network
ISO See international standards organization
ITU See international telecommunication union
ITU-T See international telecommunication union telecommunication standardization
J
jitter The variation in the time taken for packets to be delivered to an endpoint or network
entity.
K
KDC See key distribution center
key distribution center A COMSEC facility that generates and distributes key in electrical form.

L
LAN See local area network
LAPV5 signaling link A layer-2 link on the V5 interface. The V5 interface is the interface between the access
network and switches, and it is a service node interface (SNI).
link It is the physical or logical connection for two pieces of equipment to communicate with
each other.
local area network A network intended to serve a small geographic area, (few square kilometers or less), a
single office or building, or a small defined group of users. It features high speed and
few errors. Ethernet, FDDI and Token Ring are three technologies implemented in LAN.
loopback Loopbacks function to perform hardware/software self-loops for certain transmission
devices or channels.
M
M3UA destination An M3UA logical entity that equals the MTP3 destination signaling point.
entity
MAC See media access control
maximum transmission The MTU (Maximum Transmission Unit) is the size of the largest datagram that can be
unit sent over a network.
MD5 See message digest 5
media access control Media Access Control is the lower of the two sublayers of the Data Link Layer. In general
terms, MAC handles access to a shared medium, and can be found within many different
technologies. For example, MAC methodologies are employed within Ethernet, GPRS,
and UMTS etc.
media gateway A logical entity that converts the format of the media of a network to meet the format
requirement of another network. It can process audio services, video services and data
services, and convert the media format in full duplex mode. In addition, it can play certain
audio and video signals, and provide the IVR function and media conference.
media gateway The Media Gateway Controller (MGC), also known as Call Agents or Soft Switches,
controller handles registration, management, and control functionality of resources in the Media
Gateway (MG).
message digest 5 One-way hashing algorithm that generates a 128-bit hash for producing message
authentication signatures.
message transfer part A part of the Signaling System 7 (SS7) used for communication in Public Switched
Telephone Networks. MTP Level 3 provides routing functionality to transport signaling
messages through the SS7 network to the requested endpoint.
message transfer part Message Transfer Part level 3 broadband provides message routing, discrimination and
level 3(broadband) distribution (for point to point link only). It also provides signaling link management,
load sharing and changeover between links within one link-set. The protocol is a
broadband ISDN based protocol used typically in ATM (Asynchronous Transfer Mode).
message type A descriptor that identifies the function of a message. Stimulus call control has one
message type (information). The functional call control has several message types
concerning call connection, call disconnection, and call status.
MGC See media gateway controller

MGW See media gateway

MIN See mobile identification number
mobile identification A number that identifies a mobile unit in wireless carrier's networks, and dials from other
number networks or fixed lines. In addition, it can be electronically checked to help prevent fraud.
mobile station A mobile device, such as cellular phones or mobile personal digital assistants (PDAs).
mobile switching center A logical entity that provides interfaces for interworking with the function entities in a
GSM/WCDMA system and the public network. It plays a core role for switch in the
GSM/WCDMA system. It provides mobile management and switch to mobile
subscribers and sets up communications between mobile subscribers, or between a
mobile subscriber and a fixed line subscriber.
modem A device that enables data to be exchanged by interpreting and converting both analogue
signals and digital signals.
MPLS See multiprotocol label switching
MS See mobile station
MSC See mobile switching center
MSC pool A pool formed by multiple MSC servers that serve a pool area. A device in the access
network interconnects with multiple MSC servers in the pool.
MTP See message transfer part
MTP3b See message transfer part level 3(broadband)
MTU See maximum transmission unit
multiplexer Equipment which combines a number of tributary channels onto a fewer number of
aggregate bearer channels, the relation between the tributary and aggregate channels
being fixed.
multiprotocol label A technology that uses short tags of fixed length to encapsulate packets in different link
switching layers, and provides connection-oriented switching for the network layer on the basis of
IP routing and control protocols. It improves the cost performance and expandability of
networks, and is beneficial to routing.
MUX See multiplexer
N
narrowband A term used to depict the communication services that transmit over TDM timeslot. The
PSTN is normally a narrowband network. A communication channel whose transmission
rate is lower than 2 Mbit/s is usually considered to be narrowband.
network In communications, a system of interconnected communication facilities.
network resource An identifier that is used to distinguish a separate core network (CN) node, namely,
identifier server in the pool, from all the CN nodes that serve the pool. The NRI occupies bits 23
to n of the TMSI, where n ≥ 14. An NRI occupies up to 10 bits. An NRI starts from bit
23 of a TMSI and is 1 to 10 bits in length.
network service access A connection to a network that is identified by a network address.
point

network time protocol The Network Time Protocol was developed to maintain a common sense of "time" among
Internet hosts around the world. Many systems on the Internet run NTP, and have the
same time (relative to Greenwich Mean Time), with a maximum difference of about one
second.
non APS 1+1 Indicates that the protective group uses the master/slave interfaces mode. The APS
protective mode is not supported.One protection group has two interfaces, one master
and the other slave. Services are switched based on the UP/DOWN status of the
interfaces. In the normal state, the master interface is working. If the master interface
becomes DOWN, services on it are switched to the slave interface. This mode can be
automatically supported by hardware for some interfaces, and is not required to be
configured.
non APS 1:N Indicates that the protective group uses one protective channel and N pieces of working
channels. The APS protective mode is not supported. One protection group has N+1
interfaces, and services are switched based on the UP/DOWN status of the interface. In
the normal state, N interfaces are working. When one interface becomes DOWN, services
on it are switched to the slave interface.
NRI See network resource identifier
NSAP See network service access point
NTP See network time protocol
null-network resource A special NRI that is coded with normal NRIs in a uniform way. The null-NRI is used
identifier to instruct the RAN to select another serving MSC server for the MS during handover
among MSC servers in the pool. A null-NRI is unique in a pool.
null-NRI See null-network resource identifier
number of ATM The point in an ATM network where an ATM connection is initiated or terminated. ATM
endpoints endpoints include ATM-attached workstations, ATM-attached servers, ATM-to-LAN
switches, and ATM routers.
number of IP The number of concurrently available IP terminations on a gateway.
terminations
P
packet Data packets and local packets. Logical grouping of information that includes a header
containing control information and (usually) user data. Packets are most often used to
refer to network layer units of data.
packet forwarding When a router receives a datagram, and it is found that the destination IP address of the
datagram does not match the IP address of the router, then the router queries the route
list and forwards the datagram to another router or the destination host.
packet fragmentation The MTUs in the networks are different, and thus data packets must be fragmented and
reassembled when routers are used for interworking.
packet loss A technology of compensating packets according to an appropriate algorithm if packets
compensation are lost in the transmission.
packet over SDH Packets transmitted over SDH.
PAP See password authentication protocol

parity A method for character level error detection. An extra bit added to a string of bits, usually
a 7-bit ASCII character, so that the total number of bits 1 is odd or even (odd or even
parity). Both ends of a data transmission must use the same parity. When the transmitting
device frames a character, it counts the numbers of 1s in the frame and attaches the
appropriate parity bit. The recipient counts the 1s and, if there is parity error, may ask
for the data to be retransmitted.
password A method for verifying the identity of a user attempting to log on to a Point-to-Point
authentication protocol Protocol (PPP) server. PAP is used if a more rigorous method, such as the Challenge
Handshake Authentication Protocol (CHAP), is not available or if the user name and
password that the user submitted to PAP must be sent to another program without
encryption.
path maximum When a node sends a flood of data to another node, the data is transmitted after being
transmission unit fragmented. When the data fragment reaches the MTU from the source to the destination,
it is considered to be optimal. The fragment length is called PMTU.
PBX See private branch exchange
PCM See pulse code modulation
PCM See pulse code modulation
PCR See peak cell rate
PDH See plesiochronous digital hierarchy
peak A time period when calls are the busiest in terms of service traffic.
peak cell rate The maximum rate at which an ATM connection can accept cells.
pending transaction A transaction type stipulated in the H.248 protocol. For details, see the H.248 protocol.
When a transaction lasts for a long time and the gateway processes the transaction, the
gateway sends a Pending transaction to the MGC to inform the MGC of the processing
to avoid retransmission.
performance One of five categories of network management defined by ISO to manage the OSI
management networks. Performance management subsystems are in charge of analyzing and
controlling network performance, including network throughput and error rates.
ping A method of testing whether a device in the IP network is reachable according to the
sent ICMP Echo messages and received response messages.
PLC See packet loss compensation
plesiochronous digital A technology used in telecommunications networks to transport large quantities of data
hierarchy over digital transport equipment such as fiber optic and microwave radio systems.
Plesiochronous Digital Hierarchy is the first multiplexing hierarchy used in digital
transmission systems. The base frequency was 64kbit/s, multiplexed up to 2048, 8448,
34,368 and 139,264Mbit/s. Previously, there was more than one standard system and it
varied between Europe, the US and Japan.
PM See performance management
PMTU See path maximum transmission unit
point-to-point protocol A widely used WAN protocol designed to provide router to router and host to network
connections over synchronous and asynchronous circuits. In addition, PPP has a built-
in security mechanism.

pool A concept raised in 3GPP TS 23.236. It means that multiple serving CN nodes in the
network form a pool area. Within this area, an MS can roam at will without changing
the serving CN node.
port A physical or logical communication interface.
POS See packet over SDH
PPP See point-to-point protocol
private branch A telephone switch for use inside a corporation.
exchange
profile negotiation A parameter for interconnection between the MGW and the peer MGC. Each profile can
be considered as a subset of the H.248 standard. ETSI_GateControl/1 defines the
ServiceChange message in a more detailed manner. For details, see ETSI TS 102 333
V1.1.2. ETSI_Tgw/1 defines partial subsystems in the NGN. For details, see ETSI ES
283 024 V1.1.1. FT_Tgw/1 defines and expands partial subsystems in the NGN. For
details, see ETSI ES 283 024 V<1.0.14>.
protocol On the Internet "protocol" usually refers to a set of rules that define an exact format for
communication between systems.
PSTN See public switched telephone network
public switched Network by which household and business phones are connected, typically by
telephone network conventional fixed cables. It is the infrastructure providing a country's telephone system
and it is the original analog telephone network.
pulse A variation above or below a normal level and a given duration in electrical energy.
pulse code modulation A method of converting an analog voice signal to digital. It samples the signal 8,000
times per second and encodes the signal amplitude as an 8 bit value. The produced digital
transmission rate is 64 kbit/s.
pulse code modulation A method of converting an analog voice signal to digital. It samples the signal 8,000
times per second and encodes the signal amplitude as an 8 bit value. The produced digital
transmission rate is 64 kbit/s.
Q
Q.921 signaling link An ISDN data link. The corresponding protocol is ITU-T Q.921.
QoS See quality of service
quality of service Short for Quality of Service, QoS refers to service capacity assessment of IP network
packets. Typically, the capability of supporting service requirements such as delay, delay
jitter, and packet loss is considered as the core assessment object. Certain support
technologies are required to meet the core requirements.
R
radio network An entity that manages the radio part of the network in UMTS.
controller
real time Pertaining to the processing of data by a computer in connection with another process
outside the computer according to time requirements imposed by the outside process.

real time variable bit A rate that is intended for real-time applications. The rt-VBR services are connection-
rate oriented with variable bit rates. The bandwidth used by a termination varies with the
information sending rate of the termination. The ATM network guarantees the
sustainable cell rate (SCR) for communication terminations, and requires that the
terminations adopt rates equal to or lower than the peck cell rate (PCR) to send
information. rt-VBR is typically used in the services that require much on time sensitivity
such as image services.
real-time control The statuses of sessions in the connection are contained in the packets to guarantee QoS
protocol of RTP.
real-Time transport A host-to-host protocol that is used in real-time multimedia services such as Voice over
protocol IP (VoIP) and video.
RNC See radio network controller
route A route is a set of all sub-routes from local office to a destination office. A route contains
multiple sub-routes and different routes may contain the same sub-routes.
router It is a piece of equipment that can forward the data, which should not be routed to it. In
other words, a router can receive packets and forwards them to the right destination,
because a router connects to more than one physical network.
rt-VBR See real time variable bit rate
RTCP See real-time control protocol
RTP See real-Time transport protocol
S
SCCP See signaling connection control part
SCTP association An association is the logic relation, or channel, established between two SCTP endpoints
for data transmission, through the four-way handshake mechanism prescribed in SCTP.
SCTP dual-homing A networking of 3GPP R4 or later in which one MGW belongs to two MSC Servers.
networking mode
SDH See synchronous digital hierarchy
security domain A set of elements, a security policy, a security authority and a set of security relevant
activities in which the set of elements are subject to the security policy, administered by
the security authority, for the specified activities. The Security Domain focuses on the
identification of industry standards related to cybersecurity and the creation of policies
to promote a more secure environment.
security parameter A numeric identifier in IPsec, used with the destination address and security protocol to
index identify a security association (SA).
segmentation A term used to set limits to collision domains, which allows Ethernet networks to achieve
higher performance. It is also called network segmentation.
sequence number An identifying number used to designate a block of data, an operation, or part of an
operation.
server A network device that provides services to network users by managing shared resources,
often used in the context of a client-server architecture for a LAN.
serving GPRS support A device in the mobile network that requests PDP contexts with a GGSN.
node

session initiation An application layer protocol used for creating, modifying, and terminating a multimedia
protocol session in IP networks. It is part of the multimedia protocol system that IETF standardizes
constantly. The SIP protocol is used to initiate the interactive user sessions containing
the multimedia elements of video, voice, chatting, game, and virtual reality.
SGSN See serving GPRS support node
signaling The instructions and the signals that are transmitted among different levels of exchanges
to enable the network to run normally as an entire entity and thus implement call
connections. The instructions control connections, and the signals indicate the execution
results and running status.
signaling connection A protocol used by the SoftX3000 to establish circuit-independent signaling connections
control part with the VLR, HLR, EIR, MSC, SMC, GMLC, and SCP through the SS7 signaling
network.
signaling point A node that sends or receives signaling messages in a signaling network.
signaling system 7 A protocol used in telecommunication for delivering calls and services. SS7 typically
employs a dedicated 64 kilobit data circuit to carry packetized machine language
messages about each call connected between and among machines of a network to
achieve connection control.
signaling transfer point A node that transfers messages received from a signaling link to another. Element of an
SS7-based Intelligent Network that performs routing of the SS7 signaling.
SIP See session initiation protocol
SN See sequence number
softswitch A term that refers to a softswitch device in a narrow sense. A softswitch provides call
control and connection control for real-time services. As the control core of the NGN,
softswitches separate the services from the call control and the call control from the
bearer, and adopt the application program interface (API) and standard protocols. This
makes it easy for network carriers to develop new services and realize new features.
SONET See synchronous optical network
SP See signaling point
SPI See security parameter index
SS7 See signaling system 7
standard SG A networking mode relative to the MSC Pool networking. In standard SG networking
networking mode, the UMG8900 serves only as an SG in signaling processing. The signaling
messages are processed only to the MTP3 layer. The UMG8900 does not resolve the
MTP3 user contents; instead, the UMG8900 forwards them according to the destination
point codes in the messages.
static route A route that cannot adapt to the change of network topology. Operators must configure
it manually. When a network topology is simple, the network can work in the normal
state if only the static route is configured. It can improve network performance and ensure
bandwidth for important applications. Its disadvantage is that when a network is faulty
or the topology changes, the static route does not change automatically. It must be
changed by operators.
STM See synchronous transport module
STP See signaling transfer point

stream index An index that is used to uniquely identify a media stream. It is stipulated in the H.248
protocol. For details, see the H.248 protocol.
stream mode A mode that identifies the direction of the media stream on a termination. It is stipulated
in the H.248 protocol. For details, see the H.248 protocol.
subboard A type of board used in the separated architecture for the UMG8900. The board with the
separated architecture consists of the baseboard and the subboard that work jointly to
implement certain functions. Take the SPF as an example. The SPF subboard mainly
processes layer-2 narrowband signaling such as signaling on the MTP2 links, Q.921
links, and LAPV5 links. The SPF baseboard typically processes layer-3 signaling.
subnet mask The technique used by the IP protocol to determine which network segment packets are
destined for. The subnet mask is a binary pattern that is stored in the client machine,
server or router and is matched with the IP address.
SX See softswitch
synchronous digital The European counterpart to SONET. SONET is an intelligent system that provides
hierarchy advanced network management and a standard optical interface. Specified in the
Broadband ISDN (B-ISDN) standard, SONET backbones are widely used to aggregate
T1 and T3 lines. The European counterpart to SONET is the Synchronous Digital
Hierarchy, and the term "SONET/SDH" is widely used when referring to SONET.
synchronous optical A North American standard for Synchronous Data Transfer over Optical Networks.
network
synchronous transport An information structure supporting section layer connections.
module
T
T1 A basic physical layer protocol that is used by the digital signal level 1 (DS1)
multiplexing method in North America.
TCP See transmission control protocol
temporary mobile A temporary mobile station identification assigned by the MSC. The TMSI is stored in
subscriber identity the VLR and the SIM card and used by the MS to originate and receive calls. One TMSI
maps to only one IMSI in a VLR area. The TMSI is used to conceal the international
mobile subscriber identity (IMSI) for sake of security.
time stamp The time of day recorded in a transaction. The current time is maintained by the computer
in minute fractions of a second and is used for a variety of synchronization purposes
including determining transaction order in the event of a system failure.
time to live A period of time starting when resources such as sessions and terminations are allocated
and ended when the resources are released.
TMSI See temporary mobile subscriber identity
topology The topology of a network describes the way computers are connected together.
Topology is a major design consideration for cost and reliability.
ToS See type of service
traffic The average number of calls made and received by call sources in a seizure duration.
transit Connection to and use of a telecommunication path that is provided by a vendor.

transmission control A connection oriented packet switching protocol that provides reliable data transmission
protocol service for applications on the Internet.
transmit mode The mode employed for transmission.
transparent Transmission of signals over the network without any change of structures and data. For
transmission signals, the network is transparent.
tunnel One of the NAT traversal solutions. Configure the tunnel client in the private network
and the tunnel server on the proxy device. The client transmits packets to the server
through the UDP tunnel or HTTP tunnel.
tunnel mode An IPSec mode of operation in which the entire IP packet, including the header, is
encrypted and authenticated and a new VPN header is added, which protects the entire
original packet.
type of service A field in an IP packet (IP datagram) that is used for quality of service (QoS). The TOS
field is 8 bits, broken into five subfields.
U
UBR See unspecified bit rate
UDP See user datagram protocol
UMTS See universal mobile telecommunication system
UMTS terrestrial radio A WCDMA radio network in UMTS.
access network
universal mobile A system that is applied in the third-generation (3G) wireless networks. It transmits text,
telecommunication digitized voice and multimedia based on packets. The transmission rate of data can be
system up to 2 Mbit/s.
unspecified bit rate A transmission service that does not guarantee a fixed transmission capacity. Any
application that can tolerate delays is ideally satisfied by an UBR.
user datagram protocol A connectionless transport layer protocol, in TCP/IP, that exchanges datagram without
acknowledgments or guaranteed delivery.
UTRAN See UMTS terrestrial radio access network
V
VAD See voice activity detection
VAD See voice activity detection
variable bit rate QoS class defined by the ATM Forum for ATM networks. VBR is subdivided into a real
time (RT) class and non-real time (NRT) class. VBR (RT) is used for connections in
which there is a fixed timing relation between samples.
VBR See variable bit rate
VCI See virtual circuit identifier

video gateway When the MGW serves as a VIG, audio, video and H.245 (multimedia communication
control protocol) data is multiplexed in H.223 frames. The MGW needs to demultiplex
H.223 frames and then transmits H.223 control protocol data transparently to the MGC.
Thus, H.245 signaling links need to be set up between the MGW and the MGC. This
configuration is unnecessary in other networking applications.
VIG See video gateway
virtual channel A term that enables queuing, packet scheduling, and accounting rules to be applied to
one or more logical interfaces.
virtual circuit identifier A 16-bit field in the header of an ATM cell. The VCI, together with the VPI, identifies
the next destination of a cell as it passes through a series of ATM switches on its way to
its destination.
virtual local area A LAN is divided into several logical LANs to suppress broadcast packets. Each virtual
network LAN is a broadcast area. Hosts in the same VLAN can directly communicate but hosts
in different VLANs cannot. Thus, broadcast packets are restricted in a VLAN.
virtual path identifier 8-bit field in the header of an ATM cell. The VPI, together with the VCI, identifies the
next destination of a cell as it passes through a series of ATM switches on its way to its
destination.
VLAN See virtual local area network
voice activity detection Voice activity detection or voice activity detector is an algorithm used in speech
processing wherein, the presence or absence of human speech is detected from the audio
samples. The main uses of VAD are in speech coding and speech recognition. A VAD
may not just indicate the presence or absence of speech, but also whether the speech is
voiced or unvoiced, sustained or early, etc.
voice activity detection Voice activity detection or voice activity detector is an algorithm used in speech
processing wherein, the presence or absence of human speech is detected from the audio
samples. The main uses of VAD are in speech coding and speech recognition. A VAD
may not just indicate the presence or absence of speech, but also whether the speech is
voiced or unvoiced, sustained or early, etc.
VPI See virtual path identifier
W
W-CDMA See wideband code division multiple access
WB-AMR See wide band AMR
wide band AMR Full rate of broadband AMR codec algorithm, which is also called G.722.2 algorithm.
Generally, it refers to a codec type.
wideband code division A radio interface technology used in most of the third-generation (3G) wireless systems.
multiple access It is the third generation standard developed and supported by GSM proponents.


Feature Description - (V200R008C02 01, NGN)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Feature Description - (V200R008C02 01, NGN)

Uploaded by

Copyright:

Available Formats

HUAWEI UMG8900 Universal Media Gateway

Huawei Proprietary and Confidential

Huawei Technologies Co., Ltd.

Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.

Trademarks and Permissions

Huawei Proprietary and Confidential

About This Document.....................................................................................................................1

2 UAM-Accessed Narrowband User Service...........................................................................2-1

Issue 01 (2010-01-12) Huawei Proprietary and Confidential i

5 Voice Quality Enhancement.................................................................................................... 5-1

6 Narrowband Common Channel Signaling Adaptation......................................................6-1

7 Channel Associated Signaling Adaptation...........................................................................7-1

8 TDM Semi-permanent Connections...................................................................................... 8-1

ii Huawei Proprietary and Confidential Issue 01 (2010-01-12)

8.4 Data Configuration of TDM Semi-permanent Connections...........................................................................8-5

9 Announcement Playing and Digit Collecting......................................................................9-1

11 Multi-Level Overload Control.............................................................................................11-1

13 SDH/SONET Interface Protection......................................................................................13-1

Issue 01 (2010-01-12) Huawei Proprietary and Confidential iii

13.1 Overview of SDH/SONET Interface Protection.........................................................................................13-2

18 NTP Network Time................................................................................................................18-1

iv Huawei Proprietary and Confidential Issue 01 (2010-01-12)

19 GPS Clock Synchronization.................................................................................................19-1

21 MGC Dual Homing...............................................................................................................21-1

25 Operation and Maintenance................................................................................................25-1

Issue 01 (2010-01-12) Huawei Proprietary and Confidential v

25.3.2 Configuration Management................................................................................................................25-5

28 Upgrade Without Service Interruption..............................................................................28-1

29 Basic BootROM Online Upgrade........................................................................................29-1

30 JTAG Upload Through MML Command..........................................................................30-1

31 Backup and Restoration of Configuration Files on the LMT........................................31-1

32 Password Configuration Policy...........................................................................................32-1

33 Transmission Quality Check in the IP Bearer Network.................................................33-1

vi Huawei Proprietary and Confidential Issue 01 (2010-01-12)

34.3.1 Automatic Discovery and Detection of Faulty IP Address Pairs.......................................................34-4

35 Characteristic Location Method with Dialing Tests.......................................................35-1

37 Power Consumption Reduction..........................................................................................37-1

Issue 01 (2010-01-12) Huawei Proprietary and Confidential vii

Figure 1-1 AG networking...................................................................................................................................1-4

Issue 01 (2010-01-12) Huawei Proprietary and Confidential ix

x Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Figure 16-5 Format of the non-compressed RTP multiplexing packet..............................................................16-8

Issue 01 (2010-01-12) Huawei Proprietary and Confidential xi

xii Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Table 1-1 Required NEs for basic services..........................................................................................................1-2

Issue 01 (2010-01-12) Huawei Proprietary and Confidential xiii

Table 7-4 Versions supporting channel associated signaling adaptation ............................................................7-3

xiv Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Issue 01 (2010-01-12) Huawei Proprietary and Confidential xv

Table 24-4 Versions supporting SSH ................................................................................................................24-3

xvi Huawei Proprietary and Confidential Issue 01 (2010-01-12)

Issue 01 (2010-01-12) Huawei Proprietary and Confidential xvii

About This Document

Product Name Version

HUAWEI UMG8900 V200R008C02

Issue 01 (2010-01-12) Huawei Proprietary and Confidential 1

2 UAM-Accessed Narrowband User Service

5 Voice Quality Enhancement

6 Narrowband Common Channel Signaling Adaptation

7 Channel Associated Signaling Adaptation

8 TDM Semi-permanent Connections

9 Announcement Playing and Digit Collecting

11 Multi-Level Overload Control