1 Introduction

The Mobile Services Switching Centre/Visitor Location Register (MSC/VLR) switches the circuit-switched traffic for an attached mobile station within the MSC/VLR service area. The MSC/VLR has a similar function in a circuit-switched network as the Serving GPRS Support Node (SGSN) has in a packet-switched network. The MSC/VLR needs to be registered in the Network Element in order to configure the Gs interface between the SGSN and the MSC/VLR. The Gs interface is used to coordinate the location information of the mobile stations, it is attached to both the packet-switched and the circuit switched networks. The attributes to be specified in this Packet Exchange Manager (PXM) form is the name and the international Integrated Services Digital Network (ISDN) number of the MSC/VLR. If the MSC/VLR has connected Base Station Controllers (BSCs) or Radio Network Controllers (RNCs), this is indicated by an enabled check box.

1.1 Functions
The following functions are supported in the MSC/VLRs PXM form: Creating a new MSC/VLR. See Reference [2]. Displaying the Attributes of All MSC/VLRs. See Reference [4]. Displaying the Attributes of an MSC/VLR. See Reference [5]. Modifying the Attributes of an MSC/VLR. See Reference [6]. Deleting an MSC/VLR. See Reference [3].

1.2 Prerequisites
The person performing configuration and planning should have a solid knowledge of and training in the following areas: Working in the Packet Exchange Manager (PXM) Knowledge in packet-switching communication Operation of the packet-switching node

1.3 Scope
This document describes the menus and elements within the MSC/VLRs PXM form. Note:

All PXM forms can be found in alphabetical order in the Index folder. For a complete description of the PXM Graphical User interface, see Reference [7].

2 MSC/VLRs PXM Form

2.1 MSC/VLRMenu
2.1.1 New

Choose this command to create a new MSC/VLR. In the dialog box that appears, enter the name of the new MSC/VLR. 2.1.2 Select

Choose this command to select an existing MSC/VLR in order to view its current attributes. In the dialog box that appears, enter the name of the MSC/VLR in the box or click List and select an existing MSC/VLR from the list. 2.1.3 Copy Selected

This command is only applicable after having selected an MSC/VLR. Choose Copy selected to create a new MSC/VLR where the attribute of the currently displayed MSC/VLR, the International Integrated Services Digital Network (ISDN) number, is copied to the new MSC/VLR. 2.1.4 Delete

This command is only applicable after having selected an MSC/VLR. Choose Copy selected to delete the currently displayed MSC/VLR. In the dialog box that appears, confirm the deletion. 2.1.5 Rename

Not applicable.

2.2 ViewMenu
2.2.1 Details

Choose this command to bring up a browser window displaying detailed information about the selected MSC/VLR. Browser Window: Details The information displayed in the browser is the name of the specified MSC/VLR, the international ISDN number and the names of the connected BSCs or RNCs. Note: It is not possible to navigate to other web pages from this window. It is possible to print out the contents of the browser window.

2.2.2

List all

Choose this command to bring up a browser window displaying information about all existing MSC/VLRs. The information displayed in the browser are the names of the MSC/VLRs and their respective international ISDN numbers. Note: It is not possible to navigate to other web pages from this window. It is possible to print out the contents of the browser window.

2.2.3

Refresh

Choose this command to display the attributes that are currently active in the SGSN.

2.3 CommandsMenu
Not applicable.

2.4 Help Menu

2.4.1 Help

Choose this command to display the table of contents of this Graphical User Interface (GUI) description. This document includes information about the menus and elements within the MSC/VLRs PXM form.

2.5 MSC/VLRName
This box specifies the name of the MSC/VLR. Data to enter: The name of the MSC/VLR must be unique and consist of any combination of the following characters: a-z, A-Z, 0-9, _, -, $, and #. Note: The name of an existing MSC/VLR cannot be changed.

2.6 InternationalISDNNo
This box specifies the international ISDN number of the MSC/VLR. It is used for Base Station System Application Part+ (BSSAP+) signaling between the SGSN and the MSC/VLR. Data to enter: The international ISDN number must be unique and consist of digits, within the range of 2-15 digits, where the first digit cannot be a zero.

2.7 ConnectedBSCs/RNCs
If the MSC/VLR has connected BSCs or RNCs, this read-only check box is enabled. Use the BSCs or RNCs PXM form to connect or disconnect BSCs or RNCs to the MSC/VLR. See Reference [1] or Reference [8]. Note: The label of this check box will be slightly changed depending on which attributes the SGSN has. BSCs are only applicable for Global System for Mobile Communication (GSM) SGSN, while RNCs are only applicable for Universal Mobile Telecommunications System (UMTS) SGSN nodes.

2.8 List
Click this button to display a dialog box, which lists the names of all existing MSC/VLRs. Select an MSC/VLR to display its attributes or to delete it.

2.9 Apply

Click this button to register the displayed attributes in the Serving GPRS Support Node (SGSN).

2.10 Cancel
This button is available only during the creation of an MSC/VLR. Click it to cancel the creation of a new MSC/VLR.

3 Reference List

[1] BSCs, DESCRIPTION, 3/1550-CAA 250 215. [2] Creating an MSC/VLR, OPERATION DIRECTIONS, 1/154 31-CAA 250 216. [3] Deleting an MSC/VLR, OPERATION DIRECTIONS, 5/154 31-CAA 250 216. [4] Displaying the Attributes of All MSC/VLRs, OPERATION DIRECTIONS, 3/154 31CAA 250 216. [5] Displaying the Attributes of an MSC/VLR, OPERATION DIRECTIONS, 2/154 31CAA 250 216. [6] Modifying the ISDN Number of an MSC/VLR, OPERATION DIRECTIONS, 4/154 31CAA 250 216. [7] Operation and Maintenance Description , DESCRIPTION, 2/1551-AXB 250 04. [8] Radio Network Controllers (RNCs) DESCRIPTION, 1/1550-CNA 403 993.

Backup and Restore of a GSN using GBS

Copyright Ericsson AB 2001 - 2004 - All Rights Reserved. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any errors or damage of any kind resulting from the use of this document.

Contents
1 2 2.1 3 4 4.1 4.2 4.3 5 5.1 5.2 6 7 Introduction Prerequisites User Prerequisites Flowcharts Backup Procedure Prepare the Node for Backup Back Up the Node Test load Backup Files Restore Procedure Restore a Backup Verify Restoration Appendix 1 Reference List

1 Introduction
This document describes how to back up and restore a GPRS Support Node (GSN). Storing a backup outside the GSN allows it to recover from major faults like hardware failure, fire, or unsuccessful updates or upgrades. Restoring a faulty GSN is most advantageous if a backup is taken after every essential change, or on a regular basis. The procedures employ the GSN Backup System (GBS) tool, a collection of scripts that handles the backup of software in a GSN. The tool runs on a GSN Installation and Support (GIS) server connected to the node. For more information on the GBS

scripts used during the backup and restore, see the reference chapter last in the document. All backup files are stored on the GIS server. Consequently, the number of backups that can be stored depends on their size.

2 Prerequisites
GBS must be installed on the GIS server, see Reference [7]. The GIS server must be configured according to the GIS 2.0 solution, see Reference [1]. This backup method requires that a remote shell is free from any printout text, such as a welcome text. Check that the GIS server does not add any messages when running rsh: rlogin <NCB IP> su rsh <GIS server IP> date The output should be of the following format: Mon Jan 15 10:52:27 MET 2001 Backups should be taken during low traffic hours. When a backup should be restored depends on its size and type. The available backup types are currently tar-archive and ufsdump files, both with compression.

2.1 UserPrerequisites
The person performing backup should have a solid knowledge of and training in the following areas: Basic UNIX commands.

The person performing backup should have access to the following: The nickname of the node as registrered in GBS and entered with the command gbs_new_node. Use the command gbs_adm for printing node name information. The root and coreUser passwords for both the node and the GIS server. While making backups and restores, the user should have console access to the node via the terminal server, to make sure that nobody else performs backups or restores of the node simultaneously and to be able to handle error messages.

3 Flowcharts

This chapter gives an overview of the activities to perform when backing up and restoring a GSN.

Figure 1

Backup Procedure

Figure 2

Restore Procedure

4 Backup Procedure
4.1 Preparethe Nodefor Backup
Note that the size of the backup can grow dramatically as patch packages are added and checkpoints are made. In order to keep the size of the backup as small as possible, only a few checkpoints should be kept. Note: These preparations are required the first time the node is backed up, or if the node type has changed. 1. Log on to the GIS server as coreUser. 2. Insert the node into GBS by running the following command: gbs_new_node NCBIPAdress netmask NodeIdentity For a node that supports ncb failover, the NCB IP Adress is the IP adress of the active NCB before an ncb failover has occured.

3. Verify with the command gbs_adm INFO. 4.2 BackUp the Node
A backup is taken from the active NCB and one other GPB by running the gbs_node_backup script.

Note: It is recommended to perform a checkpoint before this procedure, see Reference [9] (GSN 3.0/4.0) or Reference [10](GSN 2.1/2.2).

4. Log on to the GIS server as coreUser.

5. Back up the node by running the following command: gbs_node_backup NodeIdentity The backup procedure does not execute unless sufficient space is available. To manually halt the backup and remove any partial backup files, press Ctrl+C. For verbose mode, use the following command: gbs_node_backup -v NodeIdentity The backup script performs a dump of the root and core partitions on the NCBs and GPBs. This results in root_NCB.tar.Z, core_NCB.tar.Z, root_GPB.tar.Z, and core_GPB.tar.Z, that are placed in the directory /gsn/backups/<NodeIdentity>/<timestamp>[<tag> ]. This takes approximately one hour. Depending on the disk performance and size of the dump, however, it can take up to several hours. No prompt is given while the backup is performed. Wait for the printout Backup Performed on NodeIdentity!

4.3 TestloadBackupFiles
This procedure is used to testload the dump files. The /gsn/backups/<NodeIdentity>/tmp partition is used for storage. Each dump is unpacked and checked for errorsthat is, a restore procedure is simulated locally on the GIS server. No check of the content of the dumps is made. 6. Testload the backup by running the command: gbs_backup_testload NodeIdentity This takes approximately one hour. Depending on the disk performance and size of the dump, however, it can take up to several hours.

5 Restore Procedure
5.1 Restorea Backup
1. Inform the Network Management Center (NMC) operator that the node will be temporarily removed from service. 2. Check that the Dynamic Host Configuration Protocol (DHCP) server on the installation server is active. ps -ef|grep dhcp If this command shows nothing, start the DHCP server. /etc/init.d/dhcp start 3. Check that the installation server does not add any messages when running rsh. rlogin <NCB IP> su password: Enter the root password rsh <installation server IP> date The output should be on the following format: Mon Jan 15 10:52:27 MET 2001 The following procedure will restore the software present in the /gsn/backups/<NodeIdentity>/<timestamp>[<tag>] directory on the GIS server for the node with the identifier <NodeIdentity>. 4. During restore, the node will be out of service for any traffic for approximately 25 minutes. The restore is made in one of two ways, depending on whether all GPBs in the node are running normally or if they are inaccessible through rsh from the GIS server. The first method uses the gbs_restore_node script, the second is a manual method. a. Begin by checking that all GPBs are accessible from the installation server (for example, by pinging

them) and that they are not rebooting. If all is OK, then run the following command: gbs_node_restore NodeIdentity The gbs_node_restore CLI command will ask the user to confirm that a restore is desired: Restoring a node will destroy all data on it that has not been saved. Once the restore starts, it can not be cancelled. Are you sure you wish to restore NodeIdentity? yes/[no]: However, to simplify automatic operation, the option (-y) can be used. If specified (that is, gbs_node_restore -y NodeIdentity), the confirmation prompt will be skipped, and the restore will start immediately. b. If the GPBs are inaccessible through rsh from the GIS server, perform the following procedure for all GPBs and NCBs on the node: Log on as root. Run the following UNIX commands: eeprom boot-device=net:dhcp 'watchdogenable?=false' init 6 Having restored, the node reloads with the same status it had as when the backup was taken.

5.2 VerifyRestoration
Optionally, verify the following activities after restoration: Attach PDP context activation Payload MO SMS and MT SMS over GPRS network PDP context deactivation, explicit, mobile initiated

Charging: PDP activation, payload, PDP deactivation GPRS detach (without switch off)

6 Appendix 1
This is a technical description of the GBS restore process. It is only applicable for the GBS release R1C and onwards. When powering up, the GPB enters the Open Boot Prom (OBP). This is software that resides in flash memory on the GPB. Having entered this state, the ok prompt appears on the console and it is possible to enter commands, for example, changing boot parameters for boot device, the watchdog, and so on. To initiate a GBS restore manually on a GPB, run the following commands in OBP: ok setenv watchdog-enable? false ok setenv boot-device disk:h ok reset-all The GPB boots from partition 7 (disk:h), on which a Solaris minimal OS is installed. The purpose of this OS is to fetch a boot script and execute it. When the Solaris boots on partition 7, it executes /etc/rc2.d/S99COREinstall. This script will query DHCP for a host from which to fetch the boot script and the path to the script. Then it will try through either ftp or tftp to fetch the boot script from the host, which is the GIS server in our case. The fetched boot script, gbs_boot, is GBS-specific. This script uses DHCP to query the location of the boot.def file and then fetches this file from the GIS server. The boot.def file contains information necessary to set up partitions on the disk. After partitioning, gbs_boot creates empty file systems for root and /Core. Then it restores the backup dumps, either ufsdumps or .tar files (.tar files are recommended), to these file systems. Finally, it reboots the GPB from partition 0, which is the root file system. The restore is then finished for that GPB. Once all GPBs have been restored, the node will start in a normal state.

Replace an NCB and Restore Backup

Copyright Ericsson AB 2002, 2003 - All Rights Reserved

Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any errors or damage of any kind resulting from the use of this document.

Contents
1 2 3 4 4.1 4.2 5 Introduction Prerequisities Flowchart Installation Procedure Preparations Replacement Reference List

1 Introduction
This document describes the procedure for replacing a General Processing Board (GPB) acting as Node Controller Board (NCB). This document is valid for nodes with one NCB. For nodes with two NCBs (one active and one passive), use the procedure described in Reference [5]. After the hardware is replaced, the node is restored from a backup stored on the GSN Installation and Support (GIS) server and restarted.

2 Prerequisities
Ensure that the following tools and equipment are available before beginning the procedures: A replacement GPB The GSN Backup System (GBS) installed on a GIS server configured according to the GIS 2.0 solution. For information on the GIS solution, see Reference [2] . A valid backup of the node in the /var/gsn/node_backup/<nodeIdentity>/first directory on the GIS server. Use the command gbs_adm INFO nodeIdentity to print the content of the backup directories. For more information, see Reference [3].

3 Flowchart

This chapter gives an overview of the activities to perform when replacing an NCB and restoring backup.

Figure 1

Replace an NCB and Restore Backup

4 Installation Procedure
This procedure is to be used when replacing a faulty GPB acting as an NCB.

4.1 Preparations
Inform the Network Management Center (NMC) operator that the node will be temporarily removed from service.

4.2 Replacement

Caution!
The Repair Request button is not implemented in the GSN application. The button must not be used in GSN, since unexpected behavior may occur. To replace the board, just

remove it. 1. Put on an antistatic wrist strap. Note: Always wear an antistatic wrist strap when touching any Printed Circuit Board (PCB). 2. Locate the faulty GPB. 3. Remove the screws with a Torx 8 screwdriver and fold out the handles, see Figure 2.

Figure 2

Removing the GPB

4. Pull the GPB straight out of the slot. Note: If the GPB is in operation, the node will reload when the GPB is removed. If the GPB is out of operation (due to hardware failure), the node will not reload.

5. Place the GPB in a container secure from electrostatic discharge, such as the bag that the new board was shipped in. 6. Examine the connectors on the replacement GPB for damage during shipping and handling. If the connectors are out of line, they may damage the cabinet backplane. 7. Insert the replacement GPB. Make sure it slides correctly into the guides in the slot and that the handles are positioned correctly, see Figure 3.

Figure 3

Correct Position of Handles before Inserting the GPB

8. Fold down the handles to lock and push the unit into place, see Figure 4.

Figure 4

Correct Position of Handle after Inserting the GPB

9. Tighten the screws with a Torx 8 screwdriver.

10. Return the faulty GPB to Ericsson for repair. Attach the Repair Delivery Note

to the PEB with a clear description of the fault. For more information on how to fill in the Repair Delivery Note, see Reference [1].

11. Restore the node from backup, see Reference [4]. Note: A backup restore cannot be performed automatically until all the GPBs in the node are running normally.

gbs_adm
Copyright Ericsson AB 2001-2004 - All Rights Reserved Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Ericsson shall have no liability for any errors or damage of any kind resulting from the use of this document.

Contents
1 2 3 4 5 5.1 5.2 6 7 8 9 Description Applicability Prerequisites Syntax Operands and Variables Mandatory Command Variables Optional Operands Environment Examples Related CLI Commands Reference List

1 Description
gbs_adm Job [-b Directory] [-d DeviceName] NodeIdentity [-l Label]

The gbs_adm CLI command administers the backup dumps on the GSN Installation and Support (GIS) server and moves backups between directories. The GIS server can store backups in the directories first, second, third, and tmp.

2 Applicability
The gbs_adm CLI command is only available from the GIS server and can only be used for dumps made with the gbs_node_backup CLI command.

3 Prerequisites
GSN Backup System (GBS) must be installed on a GIS server configured according to the GIS 2.0 solution. Consequently, the server need not be of the same type as that used in the GIS 2.0 solution (SunBlade100), but the partitions must be similar. For further information on how to partition the disks, see Reference [1].

4 Syntax
gbs_adm Job [-b Directory] [-d DeviceName] NodeIdentity [-l Label] [ ] The operands and variables enclosed by brackets are not mandatory to enter.

5 Operands and Variables

This chapter describes the command variables and the operands included in the syntax.

5.1 MandatoryCommandVariables
The following command variables are mandatory: Job The variable Job determines the administration job. The following jobs are defined: CLEAN, DEL, IN, INFO, INS, MAP, OUT, ROT, TOR, SWAP, and VER. See Table 1 for further information. Note: When using the job MAP or VER the otherwise mandatory command variable NodeIdentity is not required.

Note:

A help text accompanies any other job type than those in the table below.
Table 1 Job types

Job type CLEAN DEL IN

Description

Removes all files from the pack-partition /var/gsn/pack Deletes backup from the directory specified by the variable Directory Moves a backup stored on an offline backup device to tmp. The offline backup device is specified by the variable DeviceName.The default backup device is /dev/rmt/0, which is a tape device. Lists all backup for a node. Please note that labels longer than 40 characters are not allowed.

INFO INS

MAP OUT

Deletes third Moves second to third Moves first to second New backup into first

Displays node information. Sends a backup stored in first to an offline backup device. The offline backup device is specified by the variable DeviceName.The default backup device is /dev/rmt/0, which is a tape device. Moves third to first Moves second to third Moves first to second

ROT SWAP TOR VER Moves second to first Moves first to third

Switches first and third Moves third to second

Displays GBS version.

NodeIdentity The variable NodeIdentity is the identity of the node. The identity must be in one of the following formats: a.b.c.d, a.b, a_b, or tag, where a,b,c, and d illustrate segments of the Internet Protocol (IP) address of the Node

Controller Board (NCB). Note: When using the job MAP or VER this command variable is not required.

5.2 OptionalOperands
The following operands are optional: -b Directory The variable Directory specifies the directory to be deleted, when the job type is DEL. The directory is either first, second, third, or tmp. -d The variable DeviceName specifies the backup device, DeviceName when the job type is either IN or OUT. The default backup device is /dev/rmt/0, which is a tape device. -l Label The variable Label is the name of the backup. The label consists of any combination of the following characters: a-z, A-Z, 0-9, _, and -. If no label is given, the default value is NONE.

6 Environment
GIS server.

7 Examples
The following examples describe the use of the gbs_adm CLI command. Example 1 Removes All Files from the Pack-Partition /var/gsn/pack

gbs_adm CLEAN
Example 2 Deletes Backup from the Directory first

gbs_adm DEL -b first node31

Example 3 Moves a Backup Stored on /dev/cdrom to tmp

gbs_adm IN -d /dev/cdrom node31

Example 4 Lists all backups for a node

gbs_adm INFO
Example 5 Rotates the Backup Labeled thursday_backup

gbs_adm INS node31 -l thursday_backup

Example 6 Displays node information

gbs_adm MAP
Example 7 Sends a Backup Stored in the Directory first to /dev/rmt/0

gbs_adm OUT node31

Example 8 Rotates the Backup Using the Job Type ROT

gbs_adm ROT node31

Example 9 Rotates the Backup Using the Job Type TOR

gbs_adm TOR node31

Example 10 Switches the first and the third Directory

gbs_adm SWAP node31

Example 11 Displays GBS version

gbs_adm VER

8 Related CLI Commands

gbs_backup_testload. See Reference [2]. gbs_help. See Reference [5]. gbs_mkdhcp. See Reference [6]. gbs_new_node. See Reference [7]. gbs_node_backup. See Reference [3]. gbs_node_restore. See Reference [4].