IP NETWORK

Guide to Local Exchange Cutovers on an IP Bearer Network

Issue 1.0

Date 2010-03-31

INTERNAL

HUAWEI TECHNOLOGIES CO., LTD.

Guide to Local Exchange Cutovers on an IP Bearer Network v1.0 INTERNAL

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. Please feel free to contact our local office or company headquarters.

Huawei Technologies Co., Ltd.

Address: Administration Building, Huawei Technologies Co., Ltd.,

Bantian, Longgang District, Shenzhen, 518129, People’s Republic of China

Website: http://www.huawei.com

Email: [email protected]

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 trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice

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.

2023-4-8 Huawei Confidential Page 2 of 26

mailto:[email protected]

http://www.huawei.com/


Contents

1 Background...................................................................................4

2 Overview.......................................................................................5

3 Analysis of Types of Networking and Local Exchange Cutovers on an IP Bearer Network............................................................................6

3.1 Common Networking Types of the Local Exchanges on a Bearer Network.....................................................6

3.1.1 Network Type 1........................................................................................................................................6

3.1.2 Network Type 2........................................................................................................................................7

3.1.3 Network Type 3........................................................................................................................................8

3.1.4 Network Type 4........................................................................................................................................8

3.2 Cutover Type Analysis.......................................................................................................................................9

4 Cutover Tests...............................................................................164.1 Pre-Cutover Tests.............................................................................................................................................16

4.2 Post-Cutover Service Tests..............................................................................................................................17

5 Characteristics of the Implementation of Softswitch Services........18

6 Precautions for a Cutover.............................................................216.1 Hardware Preparations and Reviews...............................................................................................................21

6.2 Script Check.....................................................................................................................................................21

6.3 Detailed Cutover Steps....................................................................................................................................22

6.4 Cutover-Related Documents............................................................................................................................22

7 Example of Cutover Steps..............................................................................23



1 Background

Nowadays, major telecommunications operators build their own large-scale IP bearer networks to meet the ever-increasing service demands. Thus, more and more cutovers on large IP bearer networks are involved in the process of helping operators build their IP bearer networks phase by phase. If engineers are unfamiliar with the local exchange cutovers on IP bearer networks and the voice service implementation on the softswitch, and inexperienced in cutovers on IP bearer networks, problems may occur during the cutover. To prevent such problems and improve the cutover efficiency and cutover success ratio, this document lists the precautions for a cutover based on the typical networking of the local exchanges on the existing IP bearer networks and the characteristics of service implementation on the softswitch. Engineers can refer to this document when making cutover schemes and break the scheme down to operation procedures.



2 Overview

For a cutover on a large network, some tasks need to be completed and some precautions taken. Experienced engineers work out proper and detailed cutover schemes and cutover steps to ensure that the cutover is performed smoothly. In addition, the engineers must also consider the characteristics of various networks. The diversity in networking and service traffic requires a local exchange cutover on an IP bearer network. This requires the engineers to learn the local exchange networking modes on different bearer networks, be familiar with the service implementation mode, know the impacts of the cutover operations on the services, make proper plans, and determine operation procedures. The following chapters describe several types of cutovers on an IP bearer network, characteristics of service implementation, and impacts of cutovers on services.



3 Analysis of Types of Networking

and Local Exchange Cutovers on an IP Bearer Network

3.1 Common Networking Types of the Local Exchanges on a Bearer Network

3.1.1 Network Type 1GE

S3526EFEUMG8900

S2016B

R2631E

FEFE

FE

FE

GE

UMG8900

S2016B

S3526E

S3526E

S3526E

NE80E

NE80

SoftX3000

SoftX3000

S3526E

Connected to the NMS

Maintenance terminal


A softswitch, namely, the SoftX3000, and UMG8900 exist in the exchange. The SoftX3000 is connected to an access router (AR) (NE80) on the bearer network through a switch (S3500 series). The SoftX3000 transmits signaling services across provincial exchanges through this link. The UMG8900 is also connected to the switch to register with the SoftX3000 of the exchange and the SoftX3000 implements call control on the UMG8900. In addition, the UMG8900 is connected to an NE80E on the bearer network through another link. Media service traffic is forwarded to the bearer network through this link for interworking with other exchanges.



Alternatively, the SoftX3000 and UMG8900 can be connected to the AR on the bearer network through a router (R2631E shown in the preceding figure) so that the bearer network is connected to the network management system (NMS).


S3526EFEUMG8900

E1/STM -1

Maintenance terminal S2016B

R2631E

CE1

FEFE

FE

FE

GE

UMG8900

S2016B

S3526E

S3526E

S3526E

NE80E

NE80E

Connected to the NMS

Only the UMG8900 exists in the exchange. The UMG8900 registers with a remote SoftX3000 (generally a regional node).

The UMG8900 is connected to an AR on the bearer network through a switch (S3500 series). The UMG8900 registers with the remote SoftX3000 through the bearer network so that the SoftX3000 implements call control locally. In addition, the UMG8900 is connected to the AR on the bearer network through another link. This link is used to direct the media service traffic between provincial exchanges.

The UMG8900 is connected to the AR on the bearer network through a router (R2631E shown in the preceding figure) so that the bearer network is connected to the bearer network.

In network type 2, only the UMG8900 rather than the SoftX3000 is deployed in the local exchange. The UMG8900 is connected to the ARs in two exchanges in dual-home mode, and the two ARs are enabled with the Virtual Router Redundancy Protocol (VRRP).




S3526EFEUMG8900


S2016B

FEFE

FEFE

GE

UMG8900

S2016B

S3526E

S3526E

S3526E

NE80E

NE80

SoftX3000

SoftX3000


Firewall

Firewall

Firewall

FE

R2631E connected

FEFirewall

to the NMS

The SoftX3000 and UMG8900 exist in the exchange. This is the same as the case of network type 1.

The SoftX3000 is connected to the AR on the bearer network through a switch (S3500 series) and a firewall is deployed between the switch and the AR. The UMG8900 is also connected to the switch (to register with the SoftX3000 of the local exchange so that the SoftX3000 implements call control). In addition, the UMG8900 is connected to the AR on the bearer network through another link that is used to forward the media service traffic to the bearer network for interworking with other exchanges.

The SoftX3000 and UMG8900 are connected to the AR on the bearer network through a router (R2631E shown in the preceding figure) so that the bearer network is connected to the bearer network.

3.1.4 Network Type 4Network types 1 and 3 are similar. The difference between them is that in network type 3, a firewall is deployed between the switch and the AR. Network type 3 is a networking scheme that meets the security requirements of diversified services on the bearer network and therefore is commonly used in next generation network (NGN) bearer networks. Because the cutover schemes for these two network types are basically the same, the following describes only one cutover type (for network type 1).

The main difference between network types 1 and 2 is that in network type 2, no SoftX3000 exists in the local exchange, that the signaling service of the UMG8900 is connected to the AR on the bearer network through a switch (S3500 series), and that the UMG8900 registers with a remote SoftX3000 (generally a regional node) through the bearer network.

For the deployment principles and network configurations for the network types, refer to the documents relevant to mobile IP Metropolitan Area Network (MAN)/NGN bearer networks of the operator.



3.2 Cutover Type AnalysisDepending on the bearer device used and the links to be adjusted in the local exchange cutovers on bearer networks, cutovers fall into the following types:

Cutover Type 1

The original network adopts network type 1. The AR on the new bearer network is a newly added device. During the cutover, the device on the original network is not upgraded and the softswitch service on the AR on the original network is migrated to the AR on the new network.

The following figure shows the network topology before a cutover:

Core of the original network

CR1

CR2

CR2

CR1

Core of the new network

AR1 on the original network


AR2 on the new network


Device on the target network

SoftX3000S3526E

R2631

UMG1

UMG1

SoftX3000

R2631

S3526E

Device on the existing

network

Connection between the original and new network

2 × 2.5 G2 × GE



The following figure shows the network topology after the cutover:

Core of the original

network

CR1

CR2

CR2

CR1

Core of the new network





GBIC

GBIC

SFP

Device on the existing

network


S3526E

R2631

UMG1

UMG1

SoftX3000

R2631

S3526E

2 × 2.5 G2 × GE

GBIC

Connection between the original and

new networks

The cutover procedure is as follows:

Perform cutovers on each group of UMG8900 and SoftX3000 on an exchange in two phases.

In the first phase of the cutover, cut over the softswitch service under AR1 on the original network.

Perform the following steps:

1. Perform pre-cutover service tests and check again the software and hardware environments of the cutover (Complete this step one hour before the cutover);

2. When the cutover begins, Datacom engineers directly disconnect the AR from the two S3526E switches to switch over the softswitch service (for details about the switchover, refer to the characteristics of the implementation of the softswitch service);

3. Interconnect the S3526E-1 and AR1 and configure the switch. Ensure that the link is connected and the route is reachable;


5. Interconnect the UMG8900 and AR1 on the new network. Ensure that the link is connected;

6. Interconnect the R2631 and AR1 on the new network. Ensure that the link is connected and the route is reachable;

7. On the R2631, configure a static default route and set its next hop to the IP address of the network management VPN interface of the AR;

8. From AR1 on the new network, test service reachability on the softswitch in the local exchange (for details, refer to the sections describing tests);

9. If interworking traffic exists between the original network and the new network during the cutover, ensure that the configuration of the interworking between the original network and the new network relevant to the service in the local exchange are complete;

10. On AR1 on the new network, configure the advertisement of the VPN service network segments (media/network management should be advertised before the signaling).



After the media routes are advertised, perform media route test verification on some exchanges (these tests are not considered as post-cutover tests). Configure the advertisement of the signaling routes if the verification result is normal.

In the second part of the cutover, perform service tests and verification.

11. On AR, check whether the public and private network routing tables contain the default VPN route and the detailed routes for the completed part of the cutover.

12. Verify services according to the service verification checklist. The order of the service verifications is the media VPN, signaling VPN, and NM VPN (Verification tests are performed on data monitor VPN and SS7 VPN if these two VPNs exist). For details about the test methods, refer to the sections describing tests.

Multiple service tests can be performed separately at the same time. The tests must be performed completely according to the test checklist.

13. If the service verification fails within the specified time period, perform rollback according to the upgrade guide. During the device rollback, the link status is restored.

14. If the routing test verification succeeds, instruct softswitch engineers to perform dialing tests.

15. Make observations on the exchange.

In the second phase of the cutover, cut over the softswitch under AR2 on the original network to the new network.

The main procedure of the second phase of the cutover is basically the same as that of the first phase of the cutover.

Cutover Type 2

The UMG8900 cuts over the services on the softswitch before the cutover to the AR on the new network. Two ARs on the network are currently used on the original network and need to be cut over to the CR device on the new network.

Analysis: In network type 2, the UMG8900 is connected to the AR on the new network. Therefore, during the cutover, mainly adjust the new AR to the CR link on the new network and there is no need to adjust the links of softswitch end exchanges. If a device on the new network needs to be upgraded, the device needs to be reconfigured after the upgrade. Pay special attention to the route advertisement on the ARs.

Precautions: The prerequisites to service route advertisement are as follows. The ARs are connected to the devices (UMG8900, S3526, and R2631) on the softswitch side. The service routes are reachable (Before route advertisement, check the service connectivity on ARs. Ping the IP addresses of the media, signaling, and softswitch network management of the local exchange from the ARs. If the service is provided within a VPN, you need to ping the VPN instance).



CR1

CR2

CR2

CR1

CR1

Device on the existing network


Link between the original and new networks

2 × GE

2 × 2.5 G

Device that is used before cutover and needs to be cut over to the new network

S3526E

R2631

UMG8900 1

UMG8900 1

SoftX3000

SoftX3000

R2631

S3526E

Before cutoverAR1-NE40 on the current node on the existing network

AR1-NE80 E on the existing node on the

new network

Core of the existing network on the regional node .

AR2-NE80 E on the existing node on the

new network

AR2- NE 40 of regional

node on the existing network

Core of the new network on the regional node .

Core of the new network on the regional center node.

AR2- NE80 E of regional node on the new network

AR1-NE40 on the current node on the existing network

CR1

CR2

AR2-NE40 on the existing network on the regional node

CR1

Core of the new network on the regional node

CR1



Device that is used before cutover and needs to be cut

over to the new network

S3526E

R2631

R2631

S3526E

After cutover

UMG8900 1

Core of the existing network on the regional

node


Link between the original and new networks 2 × GE

2 × 2.5 G

UMG8900 1

SoftX3000

SoftX3000

CR2AR2-NE80E on the new

network on the regional node

AR2-NE80E on the new network on the

existing node

AR1-NE80E on the new network on the existing node

The main tasks involved in cutover type 2 are as follows (in the order of serial operations):

1. Perform pre-cutover service tests and second confirmation of the software and hardware environments of the cutover (Complete this step one hour before the cutover).

2. Upgrade the ARs that need to be upgraded (load the version package before the cutover).

3. If interworking traffic exists between the original and new networks during the cutover, determine the corresponding exchanges and complete the configuration of the interconnection between the original and new networks.

4. Cut over the link between AR-NE80E and regional node CR.

5. When the upgrade is complete, update the data configuration (except service route advertisement) of the NE80E.

6. Check the connectivity of the link between the UMG8900/SoftX3000 and the ARs and deploy service routes.



7. Check the connectivity of the link between the softswitch NM devices and ARs and deploy service routes.

8. Ensure that the links and service routes between the ARs and the UMG8900, SoftX3000, and softswitch NM devices are normal.

9. Configure the advertisement of the service network routes (in the order of media/NM and signaling). Note: After the media advertisement, test the advertised signaling.

10. Perform service verifications.

Cutover Type 3

The main characteristics of cutover type 3 are as follows. There is only one UMG8900. Before the cutover, the UMG8900 (signaling service) is connected via the uplink to two switches connected to an AR. The media services are directly connected to the AR. After the cutover, the UMG8900 (signaling services) is connected via the uplink to two switches respectively connected to two new ARs. In addition, the UMG8900 (media services) is directly connected through the uplink to two new ARs enabled with VRRP and heartbeat messages are exchanged between the ARs.

Analysis: After the cutover, the UMG8900 is connected via the uplink to two ARs and the network topology changes. You can first complete the cutover on one side from the UMG8900 to an AR on the new network (as the UMG8900 is connected via the uplink to two ARs, you can choose to perform a cutover on the easier side) to increase the cutover success rate.

CR1

CR2

CR2

CR1

AR1 on the existing node

AR2 on the existing node

New AR2 on the regional node

CR2

New AR2 on the existing node

CE1


S3526E-1

S3526E-2

CR1

CR2

CE1

--

-

CR1

CR2

CE1

--

-


CR1

CR2


UMG8900 1


CE1



--

-

2 × GE2 × 2.5 G

Before cutover



Core of the existing network on the regional node

CR1

CR2

CR2

CR1

UMG8900 1

AR2 on the new network on the regional node


CR2


S3526E-1

S3526E-2

AR2 on the existing network on the regional node

-1-1




AR1 on the existing node on the existing

network

AR2 on the existing node on the new network

-1

2 × GE

2 × 2.5 G

After cutover

Perform the following steps:

1. Perform pre-cutover service tests and second confirmation of the software and hardware environments of the cutover (Complete this step one hour before the cutover).

2. When the cutover begins, Datacom engineers should directly disconnect the AR from the two S3526E switches to implement a switchover of the softswitch service (for details about the switchover, refer to the characteristics of the implementation of the softswitch service).

3. Interconnect the S3526E-1 and AR1 and configure the switch. Ensure that the link is connected and the routes are reachable;




7. Interconnect the R2631 and AR1 on the new network, and perform relevant configuration. Ensure that the link is connected and the route is reachable;

8. From AR1 on the new network, perform service reachability tests on the softswitch in the local exchange (for details, refer to the sections describing tests);

9. If the original network and the new network interwork with each other during the cutover, ensure that the configuration of the interworking between the original network and the new network relevant to the service in the local exchange are complete;

10. On the AR1 on the network, configure the advertisement of the VPN service network segments (media/network management should be advertised before the signaling).

After the media routes are advertised, perform media route test verification on some exchanges (these tests are not considered as post-cutover tests). Configure the advertisement of the signaling routes if the verification result is normal.



In the second phase of the cutover, verify the service tests.

11. Check whether the routing tables of the public and private networks on AR contain the default VPN route and the detailed routes for the completed part of the cutover.

12. Verify services according to the service verification checklist. The order of the service verifications is media VPN, signaling VPN, and NM VPN (Verification tests are performed on data monitor VPN and SS7 VPN if these two VPNs exist). For details about the test methods, refer to the sections describing tests.

Multiple service tests can be performed separately at the same time. The tests must be performed completely according to the test checklist.

13. If the service verification fails within the specified time period, perform rollback according to the upgrade guide. During the device rollback, the link status is restored.

14. If the routing test verification succeeds, instruct softswitch engineers to perform dialing tests.




4 Cutover Tests

As an important part of a cutover, softswitch cutover tests indicate whether the services before and after the cutover are normal. When the cutover is complete, the test contents and relevant operation records must be recorded and submitted to the project team.

4.1 Pre-Cutover TestsPre-cutover tests are the basis for verifying services after a cutover. The service tests before a bearer network cutover must be comprehensive, covering every relevant test point. If no comprehensive pre-cutover testes are performed and only the test documents before the cutover are used, no basis can be provided for accurately determining whether any problem occurs in the cutover and whether the cutover succeeds in the case that the cutover results are different from the test results of the test scheme. An example is as follows:

Before the local exchange cutover on a bearer network, the engineers do not perform comprehensive tests on the services (media, signaling, and network management) on the bearer network (As the number of exchanges is large and the service tests take quite a long time, the engineers do not attach importance to pre-cutover tests or make proper arrangements. Thus, the tests are not sufficiently performed). The services of the exchanges in some tests fail before the cutover. This, however, is not specified in the test scheme (A test scheme is usually completed by the local exchange supervisor, who is not very clear about the services of other exchanges in the whole project). When the test after the cutover shows that the test fails, it is considered that the cutover process has gone wrong. After time-consuming fault location, however, it is found that the failure of the exchange under test is normal. The time for the cutover of a large project is usually short. Therefore, time wastes and even cutover failures due to insufficient pre-cutover tests must be avoided.

Test example

The following section uses the preceding bearer network local exchange networking/cutover type 1 as an example, assuming that the services belong to their VPNs on the bearer network.

Run vpn instance name Media to test the media service.

On the AR, run ping -vpn Media remote media service address x.x.x.x.

Test the signaling service (vpn instance name SG).

On the S3526, run ping -a Signaling service address Remote signaling address.



Test the softswitch NM service (vpn instance name NMS).

On the R2631, ping the remote NM service address.

4.2 Post-Cutover Service TestsAs a necessary step to check whether the cutover succeeds after the cutover, post-cutover tests include the routing tests on the bearer network side and dialing tests on the softswitch side. Completing service routing tests is the main task of Datacom engineers. Similar to pre-cutover tests, post-cutover tests must be performed comprehensively and carefully. For the softswitch local exchange cutover on the bearer network, softswitch engineers can perform dialing tests only after the service address can be pinged successfully after the cutover on the bearer network side to verify that the bearer network side is normal.

The procedure for post-cutover tests is basically the same as that for pre-cutover tests. An example is as follows:

The following section uses the preceding bearer network local exchange networking/cutover type 1 as an example, assuming that the services belong to their VPNs on the bearer network.

Test the media services (vpn instance name Media).

On the AR, run ping –vpn Media Remote media service address x.x.x.x.

Test the signaling service (vpn instance name SG).

On the S3526, run ping –a Signaling service address Remote signaling address.

Test the softswitch NM service (vpn instance name NMS).

On the R2631, ping the remote NM service address.



5 Characteristics of the

Implementation of Softswitch Services

Before a cutover, fully communicate with the engineers on the softswitch side about the impacts on the services on the softswitch side during the cutover, characteristics of the local softswitch implementation, and the influences on the softswitch services during the local exchange cutover:

1. Check whether the UMG8900 and the SoftX3000 of the local exchange are in the same equipment room, that is, whether any SoftX3000 exists locally. This affects the number of service interruptions during the cutover. For details, see the section describing the characteristics of the softswitch service implementation.

2. Check whether the UMG8900 is configured with automatic switchover. That is, check whether the services are automatically switched to the circuit-switching side (exchange A) after the signaling on the bearer network side is down.

Understanding the influences that a local exchange cutover has on the bearer network helps engineers make proper cutover schemes and cutover steps and allows Datacom engineers to better grasp the overall cutover on the exchange.

Before a cutover, communicate with the engineers responsible for the softswitch side about the characteristics of the local softswitch implementation, including the following:

Check whether the UMG8900 and the SoftX3000 of the local exchange are in the same equipment room, that is, whether any SoftX3000 exists locally. This influences the number of service interruptions during the cutover. The detailed analysis is as follows:

Check whether the UMG8900 is configured with automatic switchover. That is, check whether the services are automatically switched to the circuit-switching side (exchange A) after the signaling on the bearer network side is down or whether manual operations are required.

The media service traffic of the softswitch on the bearer network side is mainly the cross-provincial call traffic between provincial exchanges. The arrival of the media traffic at the bearer network depends on the reachability of the media service routes on the bearer network and the reachability of the signaling services between provincial exchanges on the bearer network. Note: If the media routes are reachable but the signaling services are not, no media traffic arrives on the bearer network. Media traffic arrives on the bearer network only if the signaling services are reachable and media routes are normal.



Based on the equipment deployment on the softswitch side and the impacts brought by the cutover on the bearer network, the softswitch side can be classified into the following types:

Type 1

This type of nodes is equipped with two pairs of the UMG8900 and SoftX3000. The UMG8900 and the homing SS are in the same equipment room. On the softswitch side, the configuration of the UMG8900 and SS does not need to be changed. During the cutover of the UMG8900 and SS to the new bearer network of the local node, the communication between the local node SS, UMG8900, and other node SSs and UMG8900s is interrupted. The UMG8900, however, is still registered on the local node SS. The calls from other SSs to the local province (service area) are forwarded to the mutual-aid SS (the second SoftX3000 of the local node). The UMG8900 under the mutual-aid SS sends the calls to the local exchange. The local exchange still sends the calls to the cutover node SS and the calls are routed out of the exchange through the bridge circuit to exchange A. During the cutover, no dual-homing switchover occurs on the UMG8900.

Summary: In a cutover of type 1, intra-provincial call services are not interrupted, but a cross-provincial call is interrupted once during the cutover (after this, the services are led to the circuit switching side) before being routed back to the bearer network when the cutover on the bearer network is complete and normal.

Type 2

This type of nodes mainly appears on the regional node. Working as the SSs of the regional center, these nodes manage the UMG8900s of multiple provinces or multiple UMG8900s of a province. The configuration of the UMG8900s and SSs does not need to be changed. Based on the cutover time arrangement, dual-homing switchovers occur in the following cases:

1. The regional center SS and the homing UMG8900 are cut over on different days. When the SS is cut over, dual-homing switchover occurs on the UMG8900 but not in the same equipment room under the SS. For example, assume that UMG8900 1 in Shijiazhuang is registered under SS2 in Beijing. When the services on AR2 in Beijing are cut over, UMG8900 1 in Shijiazhuang is not cut over. Thus, UMG8900 1 in Shijiazhuang is switched to SS1 in Beijing. When the cutover on AR2 in Beijing is complete, UMG8900 1 in Shijiazhuang is switched back to SS2 in Beijing.

2. The regional center SS and the homing UMG8900 are cut over on the same day. When the bearer network cutover on the node on which the UMG8900 resides is completed ahead of the schedule and the network is restored, and the UMG8900 and SS are in different equipment rooms, a dual-homing switchover occurs on the UMG8900. For example, UMG8900 1 in Hohhot is registered under SS2 in Beijing. The two nodes are cut over on AR2 on the same day. If the network in Hohhot recovers ahead of schedule, UMG8900 1 in Hohhot is registered under SS1 in Beijing. When the SS2 network in Beijing recovers, UMG8900 1 in Hohhot is again registered under SS2 in Beijing.

3. The SS not on the same node is disconnected from the bearer network earlier than the homing UMG8900. In this case, the UMG8900 performs a switchover to the mutual-aid SS.

Depending on the time arrangement of the bearer network cutover, some regional center SSs and homing UMG8900s are not cut over at the same time. Thus, the UMG8900 and the SS need to be disconnected from each other twice.



Type 3

This is a special type. Only the UMG8900 rather than the SoftX3000 is deployed in the local exchange. The UMG8900 signaling is connected to an AR through an S3500 switch to register with the remote SoftX3000. There is only one AR1 router on the original bearer network. Thus, no device redundancy can be provided at either the level of the softswitch or the level of ARs on the bearer network. During the construction phase, AR2 is added to such provincial exchanges on the bearer network. AR2 and AR1 are in different equipment rooms. After the cutover, the signaling plane of the UMG8900 is connected to AR1, while the bearer plane of the UMG8900 is connected to AR2. On the signaling plane, connect an S3526E the AR2 instead of AR1. On the bearer plane, connect one of the GIO ports corresponding to the HRUs with the same board number to AR1 and the other to AR2. Enable VRRP between each group of GE interfaces on AR1 and AR2 to provide redundant backup for the HRUs.

Analysis: The third type is special and used by a few exchanges. When the signaling between the UMG8900 and SoftX3000 is interrupted, the service is directly affected. The backup mechanism on the softswitch side, however, switches the services to the circuit switching side. On the softswitch NMS side, the call service is transiently damaged.



6 Precautions for a Cutover

6.1 Hardware Preparations and ReviewsBefore a cutover, hardware preparations and reviews must be ready (Hardware preparations must be made seriously. Otherwise, a problem that occurs in the cutover is irreversible and directly causes the cutover failure).

Get ready the spare boards and spare parts before a cutover. Configure 1:1 backup for important spare parts (the proportions of spare parts to be prepared are to be determined by the project team).

Before the cutover, the devices, links (physical cables), and ports to be adjusted in the cutover must be confirmed by the project supervisor on the exchange.

Upgrade spare boards to the target version in advance.

6.2 Script CheckBefore a cutover, examine the scripts carefully (by referring to the planning information uniformly distributed by the project team). For the configuration, focus on the following:

Port parameter configuration, port address configuration, clock, and negotiation mode

RD/RT name of a VPN

Routing configuration – fast convergence; area/hierarchy; routing network segment/mask (key check item); configuration of protocol features

For QoS configuration, check the simple traffic classification, traffic behavior, policy, queue, and bandwidth allocation.

Check the versions and device command lines.



6.3 Detailed Cutover StepsCutover steps are detailed in documents. Convert into scripts the configuration to be used on the night when the cutover is performed. In addition, the scripts must contain all the needed operations and commands. If operations that require more than one operator are involved in the cutover, some simple device login operations and login commands must also be recorded in the cutover step document.

6.4 Cutover-Related DocumentsThe documents needed in the cutover preparation phase are as follows:

Device Configuration Panel, IP Address Planning, Checklist of Service Test Addresses, and Device Upgrade Guide.

Exchange Keeping Checklist or Device Observation Guide

Cutover output – Cutover Scheme, Upgrade Plan, Cutover Operation Records, Records of the Results Before and After the Cutover, and Exchange Keeping Records.



7 Example of Cutover Steps

The following contents are used for reference only rather than as standards.

Make the following preparations before a cutover:

1. Back up the system: Complete the system backup at least two hours before the cutover.

Implemented by (XX):

(1) To back up the configuration file, run display cur, and back up vrpcfg.zip to a PC.

(2) To obtain the port status information that needs to be backed up, run the following commands:

display interface

display ip interface brief

display cfcard:/

(3) To obtain the routing information that needs to be backed up, run the following commands:

display ip routing-table

display ip routing-table vpn-instance ***

display ip routing-table vpn-instance *** statistics

(4) To display the configuration file of the S3526 switch to be backed up, run the following command:

display current-configuration

2. Test the network connectivity and record the interface addresses that can be pinged successfully.

Implemented by: XXX

Ping -vpn ChinaMobile_NGN_Media x.x.x.x

Ping -vpn ChinaMobile_NGN_Media x.x.x.x

Ping -vpn ChinaMobile_NGN_SG x.x.x.x

Ping -vpn ChinaMobile_NGN_NMS x.x.x.x

Ping -c 100 –S 8100 x.x.x.x

Ping -c 100 –S 8100 x.x.x.x

Ping -c 100 –S 8100 x.x.x.x

Check the newly deployed jumpers.



Implemented by: XXX

(1) Check the connection between the UMG8900 and AR1 on the new network.

UMG Port Address AR1 Port Address

2/4/0 x.x.x.x 3/0/0 x.x.x.x

2/5/0 x.x.x.x 4/0/0 x.x.x.x

(2) Check the connections between the two S3526E switches and AR1 on the new network.

Port Address AR1 Port Address

S3526E-1 0/4(vlan10) x.x.x.x 1/0/0 x.x.x.x

S3526E-2 0/4(vlan10) x.x.x.x 2/0/0 x.x.x.x

Make necessary markings on the original jumpers to facilitate system restoration.

3. Draw the configuration panel of the devices on the existing network. The device configuration panel must be drawn according to the configuration panel of the target network.

4. Make sure that the following cutover tools are available.

Software tools: FTP/TFTP program, script comparison program, TCL

Hardware tools: portable computer, console cable, network cable, mobile phone, label paper, and screwdriver.

5. Make sure that the spare parts and tail fiber resources are available.

[Attach the spare part application form]

The cutover procedure is as follows:

Record and document all the operation steps.

Before the cutover (one day before the cutover and on the night when the cutover is performed), the exchange supervisor must verify the lines to be adjusted. Before the cutover, the service addresses must be tested one by one according to the Checklist of Service Test Addresses and recorded. The test records before and after the cutover must be collected and submitted.

Tasks in the first phase of the cutover: Complete the network topology according to the target network starting from 0:00 a.m.

Implemented by: XXX

1. At 0:00 a.m., deactivate the UMG8900 1 and SoftX3000 connected to AR1 on the new network.

Operation procedure: Disconnect the two S3526E switches from the NE40. After confirming the disconnection, connect the NE80E to the S3526E switches.

2. Interconnect S3526E-1 and AR1.


S3526E-1 0/4(vlan10) x.x.x.x 1/0/0 x.x.x.x

3. Interconnect S3526E-2 and AR1.


S3526E-2 0/4(vlan10) x.x.x.x 2/0/0 x.x.x.x

4. Interconnect the UMG8900 and AR1.

UMG Port Address AR1 Port Address



2/4/0 x.x.x.x 3/0/0 x.x.x.x

2/5/0 x.x.x.x 4/0/0 x.x.x.x

5. Interconnect the R2631 and AR1.

R2631E Port Address AR1 Port Address

1/2 x.x.x.x 1/0/1 x.x.x.x

6. When the preceding tasks are performed, another pair of cutover team members can change the configuration of the S3526E and R2631E.

(1) Change the configuration of the R2631E.

(2) Change the configuration of the S3526E.

7. Perform corresponding tests after the preceding configuration.

(1) Run display ip interface brief to display port status information. Check whether all the connected ports are Up according to the device panel.

Ping all the directly connected IP addresses of the devices. Check whether any IP address of the devices in configured incorrectly according to the IP address planning.

Run display isis peer to check whether an IS-IS neighbor relationship is established.

Run display bgp peer to check whether a BGP neighbor relationship is established.

(2) display bgp route

display ip route 0.0.0.0

Run display ldp peer to check whether an LDP session is established.

(3) display mpls ldp session

(4) display mpls lsp

-----------------------On AR-NE80E, run ping –vpn XXX service address (instead of directly connected address) on the network segments on S3526 switch and R2631 before advertising the network segment.

8. On the AR, advertise the corresponding service network segment (mask lengths for media, signaling, network management service failures)addresses and the loopback addresses of the S3526E and configure a static route to null 0:

Media:

bgp xxxxx

ipv4-family vpn-instance xxxx

network x.x.x.x x.x.x.x

ip route-static vpn-instance xxxx x.x.x.x x.x.x.x NULL0 pr 200 ----------sys in global mode

Signaling:

bgp xxxxx



ip route-static vpn-instance xxxx x.x.x.x x.x.x.x NULL0 pr 200 ----------sys in global mode

NMS:

bgp xxxxx





ip route-static vpn-instance xxxx x.x.x.x x.x.x.x NULL0 pr 200 ----------Global mode sys

The service verification tasks and the time of the verification tasks in the second phase of the cutover are as follows:

Implemented by: XXX

1. Check whether the routing tables of the public and private networks on AR2 contain the default VPN route and the detailed routes for the completed part of the cutover.

2. Verify services according to the service verification checklist. The order of the VPN routing tests is media VPN, signaling VPN, and NM VPN.

3. If the service verification fails within the specified time period, perform rollback according to the upgrade guide. During the device rollback, restore the original link to the original status.

4. If the routing tests succeed, activate the UMG8900 and perform dialing tests.


Rollback1. If the fault still cannot be located or solved at 4.30 a.m. after the cutover failure, the

device is reset and the configuration file before the cutover is specified as the data configuration to be read after the device is started.

Run commands to:

Specify the device startup version as the version before the cutover.

Specify the device startup file as the backup file.

Restart the device:

2. During the device startup, restore the link connections according to the networking before the cutover.

3. After the device starts normally, test and verify the services according to the checklist. Compare the test and verification results with the routing information, interface status information, board status information, and configuration file recorded during cutover preparations.
