RBS Software Configuration

Chapter 3
This chapter is designed to provide the student with knowledge of the software architecture for RBS, first for it being a cello node and also because of its radio functionality.

OBJECTIVES:
Upon completion of this chapter the student will be able to Recognize the SW blocks and functionalitys. Recognize the relation between these SW blocks and the HW. Understand the file architecture in the RBS. Understand the relation of these files. Manage these files. Upgrade processing. Start and reload process.

RBS 3000 Troubleshooting

Intentionally Blank

EN/LZT 1237167 REV A

3 RBS Software Configuration

3 RBS Software Configuration

Table of Contents
Topic Page

CELLO SW STRUCTURE .....................................................................1

CELLO PROCESSOR TOPOLOGY...............................................................................1

SYSTEM SW CONFIGURATION STRUCTURE....................................4

SYSTEM CONFIGURATION FILES...............................................................................4

SYSTEM UPGRADE..............................................................................9
UPDATING THE CONFIGURATION..............................................................................9 START AND RELOAD PROCESSES ..........................................................................11

EN/LZT 123 7167 REV A

RBS 3000 Troubleshooting

Intentionally Blank

ii

EN/LZT 123 7167 REV A

RBS Software Configuration

CELLO SW STRUCTURE
CELLO PROCESSOR TOPOLOGY
Cello offers the applications an execution platform comprising A number of processors and communications between them. A distributed real-time OS, supporting robust application design. O&M support for applications. A fault-tolerant real-time database. A robust fault-tolerant system. A space SWitch.

The Cello platform provides an execution platform including Main Processors (MPs) equipped with a hard disk and Board Processors (BPs). The MPs in the node will cooperate and form a Main Processor Cluster (MPC) where the main part of the control software will execute. The processors in the MPC are equal with respect to control, that is, there are no master slave relations. However, from the application point of view, the MPs may have different roles. The execution platform have a logical topology according to Figure 3.1 where the MPC is the center in a star topology with BPs on its end points. A BP is physically located on a device board mounted in a Cello based subrack and the BP controls the application specific hardware on each device board. The generic term for the application specific hardware is Device Processor (DP) which may contain a mix of DSP(s), FPGA(s) and ASIC(s).
EP
Auxiliary Unit

ECP

NPU

DP XP

BP

BP

DP

Device Board

Auxiliary Unit

ECP
MP

HD

XP
Auxiliary Unit

DP ECP

BP

IC P
MP
P IC

IC

Device Board

P IC
I CP

ICP
HD

ICP

BP

DP

Device Board

MP

MPC

HD

Device Board

P IC

NPU NPU

DP

BP

IC

BP

DP

Device Board

Device Board

Figure 3. 1 RBS processor topology (principle) EN/LZT 123 7167 REV A 1

RBS 3000 Troubleshooting

All BPs communicate with the MPC via the Internal Control Paths, (ICPs) but not with each other. The ICPs are also used within the MPC where each processor has communication with all others. The possible configurations are not dependent on how processor boards are located in sub-racks of the node. Hence, the MPC may have processors mounted in all sub-racks and a sub-rack does not need to have an MP mounted in it. In the case of the RBS only one MP is used. The ICP transport from one processor to another uses link handlers for secure data transfer and AAL5 channels through the ATM SWitch which are setup by the Cello platform at startup.
S A I A S C I Device Board D P B P S P IC GPB S P IC C P U S A I

DBM
SC B A S C C B ackp lane S P IC IS L I

BB Subrack
S A I Device Board A S C I

ASCI ASCC BP CPU GPB ISLI SAI SCB SPIC

ATM Switch Core Interface ATM Switch Core Circuit Board Processor Central Processing Unit General Purpose Processor Board Inter Switch Module Interface Switch Access Interface Switch Core Board Space Switch Interface Circuit

D P B P

S P IC

DBM
SCB B ackp lan e A S C C S P IC

RF Subrack

Figure 3. 2 ATM SWitch interfaces

Plug in units not connected to the ATM SWitch, that is, Auxiliary Units, use a different protocol for control signalling, the ECPs. Instead of ATM/AAL5, which is used for the ICPs, an HDLC protocol on RS-485 is used. As depicted in Figure 3.3, some device boards are equipped with a DME (Device Module Extension) including necessary hardware to provide communication to auxiliary units. The auxiliary units themselves may be equipped with an AUM, Auxiliary Unit Module, which includes a processor running as an XP and interface circuitry for connection to the DME. In the macro RBS, the AIU boards, RFIF boards and the SCBs are working as a primary station for the HDLC link. Redundancy for the communication is possible and two boards holding a DME may be connected to the same HDLC link as shown in Figure 3.3. That is, both RFIFBs are connected to the same AUs. However, only one at a time will be active and in
2 EN/LZT 123 7167 REV A

RBS Software Configuration

case of a failure, the control shall be SWitched to the other board.

FAN

A U M A NT E NN A CU M CP A FA N

A U M XA L M

A U M M CP A e x t.

R ET M o to r S e n so r

A U M

A U M E C P( R S 4 8 5 ) A S C

S CB A TF SC B D M E D M E

R FIF B A TF RF IFB D M E D M E A U M

F e e d e rA

M P M P

A IUB M E A TF D E C P(R S 4 8 5 ) B iasT I C P C o m m . +D C D C

Figure 3. 3 External control paths, physical view

Both the DME and AUM are design solutions provided by the BCP subsystem. In case no full XP support is needed, it is possible to use a non AUM based HW platform. This type of processor will be treated as an External Processor (EP) which doesnt include all the features that are part of an XP. Nevertheless, still the general interface rules and standard must be complied with. In the RBS the CU, ASC, FAN, XALM, MCPA and MCPA fan are equipped with the AUM. Only the RETU is using a proprietary implementation (see Figure 3.3). Furthermore, BCP gives the necessary functionality for management of the AU connections in the ATF (Auxiliary Unit Transport Function) which will be in operation on all device boards equipped with a DME. The last type of unit is the Non Processor Unit (NPU). The NPU is a "non intelligent" unit, for example, a backplane, which can only store an HW fault log1 and provide product information

HW fault log is not part of phase 1.

Data to the system. The NPU can either be connected to a device board or an auxiliary unit.
EN/LZT 123 7167 REV A 3

F e e d e rB

RBS 3000 Troubleshooting

SYSTEM SW CONFIGURATION STRUCTURE

SYSTEM CONFIGURATION FILES
The configuration of the system is described in several files in Cello. The complete system configuration is defined in the database backup, the db.dat file. The distribution of Software (SW) running on the MPs, BPs, and Special purpose Processors (SPs) is also described in the ARMAMENT file and the LLP.LMID (LOAD_SERVER_LM) file. The LLP.LMID, ARMAMENT, db.dat, ok, and attribute files, described in this chapter, are located in the /d/configuration/cv/<cv-name>/ directory of the loader MP hard or flash disk, where <cv-name> is the name of a subdirectory to a Configuration Version (CV). Note that many CV directories may exist in /d/configuration/cv/, each containing the files needed for its CV. The cv.ptr contains the name of the CV (<cv-name>), which will be used when the Cello node starts. When a user runs the system, adds and removes boards, replaces Load Modules (LMs), and so on, the configuration will gradually distance itself from the original configuration. Therefore it is important to be able to control changes using the files and database described here.

The LLP.LMID File

The LLP.LMID file controls the start of the LOADER_SERVER_LM on the MP. The LLP.LMID file is located in the /d/configuration/cv/<cv-name>/ directory of the loader MP hard or flash disk and it is the second position in the ARMAMENT file. The LOAD_SERVER_LM belongs to the Control System and provides the application LM satellites with local capabilities to be loaded from a local file system. When created as a text file, it appears as one line for example,. CXC1320785_RXXX, which is the software product number and revision of the LOAD_SERVER_LM.

EN/LZT 123 7167 REV A

RBS Software Configuration

The ARMAMENT File

The ARMAMENT file contains information about all Cello Core LMs that need to be running on the loader and BPs before the db.dat information can be used, and the order in which the LMs will be started. It also contains information of which Cello processors that will become MP and BPs, respectively. Note that only the LOADER_SERVER_LM load module reads the ARMAMENT file. The file is located in the /d/configuration/cv/<cv-name> directory of the loader MP hard disk. Once the database is started (data_base_lm), the loader server will start fetching the configuration data from the database instead of from the ARMAMENT file (db.dat file). An update of the ARMAMENT file is needed when the Cello Core LMs are changed. The ARMAMENT file is updated when adding new boards. Other LMs are modified in the database. The structure of the ARMAMENT file is shown below: SMN APN Hardware PID ABC number SWitch Module Number ASCC port number Board ABCnumber Rev. Board revision state 1=MP 0=BP 1 n LMID for load module 1 LMID for load module n MP/BP Load Phase LMID

Figure 3. 4 Structure of Armament file

When created as a text file the ARMAMENT file has the following appearance: The delimiter between the fields is comma (,). No blanks are allowed in fields (this caused that the SW is not identified), only numbers (0 - 9), uppercase characters (A - Z), underscore (_), slash (/), and percent sign (%). Line delimiter is line feed, that is, new line, "\n", and "0x0A". Each LM is treated as a product having an identity, consisting of an ABC-number and an R-state. This applies to LMs executed by GPBs and DBMs. When addressing a specific LM, its LMID is used. The LMID is a concatenation of the ABC-number
EN/LZT 123 7167 REV A 5

RBS 3000 Troubleshooting

(capitals and no blanks) and R-state, using underscore ("_") as a separator, for example, CXC1234567_RXXXX. The underscore is only allowed just before the R-state (_R1A01). Since a slash (/) cannot be used in a file name, a solution is to use the per cent sign (%), for example, CXC1234567%1_R1A01.

$ cat ARMAMENT # Updated for RBS INC7.10 SWTP IOV5 2001-09-12 0,20,ROJ1192106/2,R4,1,1,CXC1321447_R4E02,10 0,20,ROJ1192106/2,R4,1,2,CXC1320785_R7C01,100 0,20,ROJ1192106/2,R4,1,3,CXC1320781_R6C03,200 0,20,ROJ1192106/2,R4,1,4,CXC1321315_R3E01,200 0,20,ROJ1192106/2,R4,1,5,CXC1320782_R6D02,200 0,20,ROJ1192106/2,R4,1,6,CXC1320787_R7C01,200 0,20,ROJ1192106/2,R4,1,7,CXC1321341_R4C02,200 0,20,ROJ1192106/2,R4,1,8,CXC1321314_R3C01,200 0,20,ROJ1192106/2,R4,1,9,CXC1321317_R3B01,200 0,20,ROJ1192106/2,R4,1,10,CXC1321316_R3C01,200 0,20,ROJ1192106/2,R4,1,11,CXC1320784_R6B02,300 0,20,ROJ1192106/2,R4,1,12,CXC1321408_R3G02,200 0,20,ROJ1192106/2,R4,1,13,CXC1320783_R5B01,200 $

Figure 3. 5 Armament File for CV empty

Note: In the product.attributes file, the slash must be used, for example, CXC1234567/1_R1A01. Immediately to the right of the percent sign, the following figures may be used: 1 = The LM is of target type mp750 (as in the above example). 2 = The LM is of target type bp403. 11 = The LM must be loaded on an MP in a Radio Base Station (RBS) configuration. 12 = The LM must be loaded on a Dynamic Connection Handling (DCH) MP or on a central MP in a Radio Network Controller (RNC) configuration. 13 = The LM must be loaded on a Signaling Connection Control Protocol (SCCP) MP in an RNC configuration. 21 = The LM must be loaded on a BP in a generic network node (like RNC). 22 = The LM must be loaded on a BP in an RBS. Heap and pool configuration from the armament file should be used for configuration of core load modules when needed.

EN/LZT 123 7167 REV A

RBS Software Configuration

In the case of the first row: 0,20,ROJ1192106/2,R4,1,1,CXC1321447_R4E02,10 reading from left to right, the 0 indicates the Subrack Module Number (SMN), the 20 indicates the ASCC Port Number (APN) and the next field indicates the Hardware Product ID, followed by the Board Revision State. The next field then indicates if it is a Main Processor (=1) or a Board Processor (=0) followed by the load phase. The final piece of information is the Load Module ID. The pglist command gives you the load modules that are loaded in the ARMAMENT.

The db.dat File

The database backup file contains initial configuration data for Plug-In Units (PIUs) and LM Resource Objects (ROs). It is important that the database backup contents correspond with the ARMAMENT file and the LLP.LMID file. The ARMAMENT and LLP.LMID files are regenerated from the db.dat file by using the cv mk shell command when a working database exists. Besides information also included in the ARMAMENT file, the db.dat file contains a description of the preconfigured connections that will be set up when the system is started. The db.dat file is located in the /d/configuration/cv/<cv_name>/directories of the MP hard disk. To read the information from the db.dat we have to use the SQL commands and read the tables. There are different tables defined. Go to SQL Commands in chapter 4.

The ok File
The ok file is mandatory and used as a flag by the Configuration Version SW, indicating a successful creation of a certain Configuration Version. The file is empty when it is used for the first time.

EN/LZT 123 7167 REV A

RBS 3000 Troubleshooting

The attribute File

The attribute file is mandatory and contains the attributes, for example, operator, operators comment, Upgrade Package (UP) reference, and Configuration Version identifier, for a certain Configuration Version. The file is empty when it is used for the first time.

EN/LZT 123 7167 REV A

RBS Software Configuration

SYSTEM UPGRADE
UPDATING THE CONFIGURATION
When the user of a Cello system adds new LMs or boards, the configuration will be changed. Consequently, the configuration files must be changed. Only changes pertaining to the Cello Core LMs will require an update of the ARMAMENT file. All other changes must be made in the database, using ObjectExplorer, EMAS, SQL commands, or shell commands. The text that follows describes how to create and activate a new CV, and how to restart the system.

Creating New Configuration Version

A ConfigurationVersion MO is automatically created at start-up. See Reference for more details. When creating a new CV, a directory with the following contents will be created: A database backup from the current Random Access Memory (RAM) CV. File db.dat The ARMAMENT file The LLP.LMID file

Create new CV.

cv mk <cv-name>

Instead of using the cv mk command, a new CV can be created using the "create" action (in ObjectExplorer) on an MO of type ConfigurationVersion (recommended). In EMAS, a new CV is created as follows: EMAS Main Window -> Maintenance -> Software -> Backup.

EN/LZT 123 7167 REV A

RBS 3000 Troubleshooting

Activating Configuration Version

In order for the created CV to be used at node restarts, the CV must be activated and the file cv.ptr already changed, pointing to this CV.

Activate CV.
cv set <cv-name> ok

Instead of using the cv setcommand, a CV can be activated using the "setStartable" action (in ObjectExplorer) on the ConfigurationVersion MO (recommended). In EMAS, the actions performed by giving the cv set command and reload is replaced by the following: EMAS Main Window -> Maintenance -> Software -> Restore.

Restarting System
If a configuration of the system is performed using SQL commands or shell commands, the system needs to be restarted in order for new the configuration data to take effect. At restart, the database is recreated from the database backup file (remember to save the new configuration in the database backup copy before restarting the system). A restart is performed using the "restart" action (in ObjectExplorer) on the ManagedElement MO (recommended) or by giving the following commands: reload, or restartObj me from the command line. Note that, after each restart or reload, EMAS has to be restarted, which takes a couple of minutes. For more information about the commands go to the Command Line Interface, in chapter 3.

10

EN/LZT 123 7167 REV A

RBS Software Configuration

START AND RELOAD PROCESSES

This chapter describes the process when the system is started or restarted, for example, after a reload or when the RBS is powered on.

Choosing the RBS state

1. The first file to be read by the system is the GPB_BOOT_LM, which is the file for booting the GPB. Other processors have their own boot files. 2. One of the next files to be loaded is the OSSELECT_LM, which decides if the RBS is going to be in the back up or the basic mode. The reasons for being in the back up and not in the basic mode can be: No CV available Faulty CV Upgrading process (reload --)

Back up mode
The OSSELECT_LM decides to work in the back up mode and loads the GPB_BACKUP_LM with the simplest RBS configuration. Other processors also load their back up load modules.

Basic mode
1. The OSSELECT_LM looks for the configuration version to be used so it consults the cv.ptr file. 2. In the cv.ptr is the CV programmed to be the CV used in the RBS. This is configured by the command: cv set <cvname>. 3. In the CV the first file to read is the LLP.LMID, which contains the LOAD SERVER. 4. The LOAD_SERVER_LM contains the sequence of files to be loaded in the RBS. If everything is correct, (LOAD_SERVER_LM and file ok) the GPB_BASIC_LM is loaded and the RBS starts to load in the basic mode. 5. The first file in the list of the Load Server is the GPB_BASIC_LM, which is one of the first in the ARMAMENT file. (Cello_Core_LMs) of this CV. The Load

EN/LZT 123 7167 REV A

11

RBS 3000 Troubleshooting

Server starts to read the files contained in the ARMAMENT file. 6. The first two LMs from the ARMAMENT have already been loaded because they are the GPS_BASIC_LM and the LOAD_SERVER_LM, so the load continues from the third one in the ARMAMENT. The LMs in the ARMAMENT are the Cello_ Core_LMs, and they are updated, while new LMs are defined in the scripts. 7. After the ARMAMENT comes the configuration included in the db.dat. The db.dat file contains the rest of the LMs, which are not included in the ARMAMENT. The definitions that do not belong to the Cell Core are in this file. For reading this information we need the SQL commands, so it is a database indeed.

12

EN/LZT 123 7167 REV A