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.
Transcript
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/VLR Menu
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 View Menu
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 Commands Menu
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/VLR Name
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 International ISDN No
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 Connected BSCs/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.
[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 31-CAA 250 216. [5] Displaying the Attributes of an MSC/VLR, OPERATION DIRECTIONS, 2/154 31-CAA 250 216. [6] Modifying the ISDN Number of an MSC/VLR, OPERATION DIRECTIONS, 4/154 31-CAA 250 216. [7] Operation and Maintenance Description, DESCRIPTION, 2/1551-AXB 250 04. [8] Radio Network Controllers (RNCs) DESCRIPTION, 1/1550-CNA 403 993.
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 Introduction
2 Prerequisites 2.1 User Prerequisites
3 Flowcharts
4 Backup Procedure 4.1 Prepare the Node for Backup 4.2 Back Up the Node 4.3 Test load Backup Files
5 Restore Procedure 5.1 Restore a Backup 5.2 Verify Restoration
6 Appendix 1
7 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 User Prerequisites
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.
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 Back Up 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 Testload Backup Files
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 errors-that 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 Restore a 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:
Having restored, the node reloads with the same status it had as when the backup was taken.
5.2 Verify Restoration
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.
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.
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.
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 Mandatory Command Variables
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
Description
CLEAN Removes all files from the pack-partition /var/gsn/pack
DEL Deletes backup from the directory specified by the variable Directory
IN 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.
INFO Lists all backup for a node.
INSPlease note that labels longer than 40 characters are not allowed.
Deletes third Moves second to third
Moves first to second
New backup into first
MAP Displays node information.
OUT 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.
ROT Moves third to first
Moves second to third
Moves first to second
SWAP Switches first and third
TOR Moves third to second
Moves second to first
Moves first to third
VER 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 Optional Operands
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 DeviceName
The variable DeviceName specifies the backup device, 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
