03-software description.doc

7/30/2019 03-Software Description.doc

1/71

Technical ManualM900/M1800 Base Station Controller Chapter 3 Software Description

3-1

Chapter 3 Software Description

3.1 Structure

The BSC software consists of three major parts: GMPU software (also called Host

software), board software and OMC software. Figure 3-1 is a schematic diagram of

BSC software distribution.

GMPU

OMC

Software

Software Running Entity

GMPU

SoftwareBoard

Software

WS

WS

Software

BAM

BAM

Software



LPN7 Other BoardsBIE

. . .

OMC Server

OMC ServerSoftware

Figure 3-1Relations between BSC software and running entities

Note:Only BAM software is a part of BSC software while the WS software and OMC Server software are part of

the operations & maintenance software. For the sake of integrity, the WS software and OMC Server

software are also included in the BSC software.

3.1.1 GMPU Software

The GMPU software refers to the software that runs on the GMPU of the BM. It

implements such functions as BSC hardware resources control, signaling processing,

radio resources management and interface management.


2/71


3-2

3.1.2 Board Software

The board software refers to the software that runs on FTC, BIE, MSM, LPN7, GLAP,

etc. It implements the interface functions and protocol processing between the data link

layer and the network layer.

The GMPU software communicates and exchanges information with the board

software through the Inter-Procedure Communication (IPC) protocol using the mailbox

mode and memory mapping technology. They cooperate with an appropriate division of

workload to guarantee high reliability and high processing capability of the system.

3.1.3 OMC Software

The OMC software provides such functions as maintenance, data configuration, traffic

statistics and alarm management of the BSC.

As per its physical distribution, the OMC software falls into the parts as follows:

I. BAM Software

The BAM software carries out two functions: one is to send the operation &

maintenance command from the OMC system to the BSC and directs the response of

the BSC system to the OMC terminal, acting as a bridge between OMC and the BSC

system, the other is to serve as a server in the Client/Server network model. BAM can

be used as a maintenance server for near-end maintenance of BSC.

Besides managing the database as well as test tasks and traffic statistic tasks, BAM

stores and forwards alarm messages, traffic statistic data, etc. It can store all the vital

data on the hard disk and dump them to CDs or OMC server if necessary.

II. OMC Server Software

The OMC Server runs on SUN Solaris. The number of OMC servers depends on the

capacity of the system.

The OMC network configuration data and user data are stored in the OMC server.

Other data like alarm data, traffic statistic report data is also stored in the OMC server.

Sybase is used as database platform.

The OMC Server and application consoles are the Server terminal and Client terminalend respectively in the Client/Server model.

III. WS Software

The OMC WS is a direct interface where maintenance and management of GSM NEs

is conducted. It is a simple PC running on the Windows operating system. The software


3/71


3-3

that runs in it consists of OMC Shell and client programs of various application

consoles:

OMC Shell serves to browse and view the configuration state and node information on

the OMC network and monitors OMC network. The operating environment for the OMC

Shell is WINDOWS 9.x or WINDOWS NT.

The application console is a classified set of some service functions, including data

management, maintenance, test, alarms, performance measurement, etc. A user can

perform all the operations available in the OMC system on the application consoles.

All the maintenance & management operations can be performed on one WS or

separately on multiple WSs. The number of WSs depends on the capacity of the

system.

The OMC WS sends the operation & maintenance command to a specific maintenancemodule in the BSC via the OMC Server and BAM, requesting the current running state

from the BSC or requesting the BSC to perform some operation for the real-time

monitoring and control. On receiving the operation & maintenance command, the

operations & maintenance module in the BSC acquires the current running states of the

BSC and sends them to the OMC WS.

BSC organizes all the data required for the operation of the management system using

the distributed relational database to guarantee flexibility, consistency and scalability.

This eliminates the bottleneck resulting from the centralized database and ensures

high-efficiency operation of the system.

3.2 Features

The software system of the BSC is modularly designed, having distributed control

structure and centralized database. It performs channel management, handover

decision and power control functions by using dynamic control algorithm.

OMC software runs on a Client/Server architecture. There are two Client/Server

Models in the OMC part. BAM serves as a server for near-end maintenance of BSC

while OMC Server as a server for application consoles.

The BSC software system has excellent expandability. Handover decision and power

control functions are performed by GLAP. Software optimization helps to enhance the

processing capability of the GMPU, which ensures a reliable functioning ofmulti-module BSC.

The software system of the BSC has strong protections against errors. Functions like

carrier frequency mutual assistance are developed and implemented to enhance the

error tolerance of the BSC system software. Fully backup protection, flow control, and

resource check ensure the system reliability.


4/71


3-4

The software system of BSC provides rich O&M functions, which are enabled via the

interaction between the OMC and the BSC system software. The system also provides

visual graphic interfaces through OMC, which helps to monitor the network and in case

of any abnormality, take spontaneous actions. It provides dynamic data configuration

through which maintenance staff can block a device without affecting current

subscribers calls.

The GMPU software can be loaded from the BAM into the memory of the GMPU

boards and backup software can be stored in the Flash Memory of GMPU. The board

software is stationed in the CPUs of boards. During system upgrading, the related

software can be loaded through OMC without affecting the normal operations of other

parts. This ensures rapid and easy upgrading of software version.

The essential parts like GNET, BIE, etc., operate in a board-level hot backup mode and

the corresponding software supports hot backup and immediate switchover to ensuresystem reliability and service quality.

3.3 GMPU Software and Board Software

The GMPU software and board software manage jointly the hardware resources of

BSC and deliver such functions as signaling processing, radio resources management

and interface management.

The overall structure of the BSC GMPU software and board software is shown in

Figure 3-2.

RR

Call management

Channel management

A interface

BTSM

Abis interface

DBMS

SCCP

MTP

LAPD

RR: Radio Resources Management BTSM: Base Transceiver Stat ion Management

OS: Operating System

LAPD: Link Access Protocol on D channel

SCCP: Signaling Connection Control Part

DBMS: Data Base Management System

MTP: Message Transfer Part

OS

Pb interface

Handover decision

Power control

Figure 3-2BSC software architecture


5/71


3-5

3.3.1 BSC Operating System

The BSC operating system consists mainly of five parts: task management, message

management, memory management, time limit management and initial booting and

recovery.

I. Task Management

A task is the program unit that can be dispatched by the operating system and executed

by the CPU. A task is also called a process. Task management is designed on the basis

of tasks' dynamic, concurrent and asynchronous correlative nature. This definition can

be used to clearly describe the logic of relative programs corresponding to the functions

of BSC.

The system software tasks of BSC can be classified as communication tasks,resources management tasks, call handling tasks, database management tasks and

maintenance tasks. These tasks are running under the coordination and management

of the BSC operating system.

1) Task state

As an "executable program unit", each task has its dynamic states. There are four

states for tasks in the BSC, which are executing, ready, suspended and dormant.

Executing a task means that resources of the CPU are currently occupied and its

program logic is being executed. The CPU can execute only one task at a time, i.e. only

one task can be in the executing state.

When the task for execution is well prepared, it is in the "ready" state.

When a task is waiting for the dispatch by the system i.e. in queue (before the

occurrence of an event), it is in the suspended state.

Dormant tasks refer to those that are not initialized or have been deleted by the system.

The state transition of the task in the BSC is shown in Figure 3-3.

Executing

Ready

Dormant Suspended

Dele

te

Create

Delete

Delete

Eve

ntoc

curs

Dispatch

Timeslice

Waitinsuspension

Figure 3-3Task state transition in the BSC operating system


6/71


3-6

2) Task dispatch

Task dispatch strategy used in the BSC operating system is "seizure dispatch" and is

based on the priority levels of tasks and events. Ready tasks of higher priority levels

seize the resources of the CPU first, and tasks of the same priority levels are

dispatched according to the sequence of their readiness. In the BSC system, when a

task is generated, it is provided with a priority value in the range of 0 -255. The smaller

priority value shows higher priority level, i.e., 0 represents the highest priority level of

the system.

When a task T1 of higher priority is suspended due to its waiting for resource and the

resource is being occupied and not released by task T2 of lower priority, a priority

inversion occurs, which means that a task of higher priority is delayed by a lower

priority task. In a system that is driven by the priority dispatch strategy, T1 can only wait

for the slow dispatch and executions of T2 (slow due to its low priority) and can not be

activated until the occupied resource is released. In this case, execution time of the

higher-priority T1 can not be guaranteed. To solve this problem, the BSC operating

system adopts the priority inheritance technology. Once a task of higher priority is

blocked by a task with lower priority, the task of lower priority can be upgraded to a

proper higher level so that it can be quickly executed and hence release the resources

urgently needed by the task of higher priority.

When a task of lower priority is executed and a task of higher priority is ready due to the

occurrence of an event, the task of higher priority in the ready state can interrupt and

suspend the task of lower priority and therefore seize the control over CPU.

3) Task structure and execution process

In the BSC software system, when a task is created, it is identified with a unique ID,

which is called the task ID and this task ID is used to recognize this task.

Each task comprises two parts: the first is the "initialization" part, and the second is the

"message process" part, as shown in Figure 3-4.

Initialization of task

Message process

Figure 3-4Task structure

All tasks in the BSC system are structured as shown in the above figure. The shadowed

part indicates the special implementation details of a task.

Formatted: Bullets and Numbering



7/71


3-7

According to the structure, the execution process of a task can be described as follows

(source code is in C language):

{

Initialization ( ); /*initialization*/

While (TRUE)

{

Suspended ( ); /*suspended, CPU resources not occupied*/

MessageProcess ( ); /*executing, CPU resources occupied*/

}

}

After being created, a task first executes the internal initialization and then is

suspended for the occurrence of events. When an event occurs, the operating system

sets the task as ready and puts it into the executing state for the processing of the event.

After the processing is finished, the task is suspended again to wait for the occurrence

of next event. This process is repeated in a cyclic way.

Events in the BSC system mainly include message events, timing events and

interruption events.

4) Mutual exclusion and synchronization of tasks

In the BSC operating system, some tasks are dispatched simultaneously and executed

asynchronously. These tasks are not wholly isolated from one another. Due to such

limitation of common resources (e.g. message queue), the operating system must

manage the task conditions and restrictions so that the whole system operate in a

coordinated way.

In the BSC system, the relation among tasks is of two types: resource mutual exclusion

and logic synchronization. The first type means that tasks share some resources while

the resources can only be occupied by one task at a moment. Logic synchronization

means that there is a certain sequential relation among the tasks and therefore only

when a task is executed up to a certain level then other tasks can continue.

In the BSC system, semaphore or the on/off interruption mode can be used t o

coordinate the mutual exclusion of tasks. Synchronization is guaranteed with the eventdriving method. When a task is executed up to a certain level, messages shall be sent

to activate the execution of other tasks.

Interruption Service Routines (ISR) mainly includes:

Clock interruption, which provides the system with real-time clock and timer

services.



8/71


3-8

Interruption of communication interfaces to receive frames or other contact signals

from interfaces.

Abnormal interruption for the execution of abnormal process in the system. All the

ISRs can send messages or sets semaphore to other tasks.

II. Message Management

Apart from timing events and interruption events, communication among tasks in the

BSC are mainly driven and executed by message events. Each message is used

To activate other tasks into the ready or executing states, and

To transfer data between tasks.

1) Description of messages

The message mechanism is to transmit a message of a BM to another task of another

BM. Messages can also be transmitted between two tasks in the same BM or even in

the same module. The BSC operating system provides application programs with three

types of system packets related to message management:

Application packet

Transmission packet

Release packet

The contents of messages in the BSC can be more deeply understood if combined with

the descriptions of flows of the above three types of messages and message bodies.

When task T1 applies for message block M and fills in contents, it sends the contents to

task T2. This indicates that packet event M is going to occur, i.e. task T2 will move from

the suspended state to the ready state. On the other hand, it also means that T1 has

sent data (included in the data domain of M, or M data) to T2.2) Management of message queues

In the BSC, message blocks are managed in the queue mode. There are three types of

queues: idle queue, application queue and ready queue. Each queue is enabled in the

relation mode, which is shown in Figure 3-5.

Tail pointer of idle queuel

Head pointer of idle queue

Tail pointer of ready queue.

.

.

......

......Queue control block

Head pointer of

application queue

Head pointer of ready queue

Tail pointer of

application queue

Figure 3-5Message queues



9/71


3-9

In the whole system, there is one idle queue and one application queue. For ready

queues, however, each task corresponds to a ready queue and ready queues

corresponding to one task are organized according to priority levels and the sequence

of Send_Message_Block. Messages of the same priority level are handled according to

the sequence of the sending time.

To save space and improve efficiency, the BSC provides a common buffer area for all

messages. Queue operation only results in the change of queue pointers while the

contents of the message block need not to be copied or moved. The process of the

change is shown in Figure 3-6.

Idle queue

Applicationqueue

Ready queue of

correspondingtasks

Free message block

Alloc Message block

Send message

Organized according to

receiver ID in the message

Free message block

Figure 3-6Message queue management

III. Memory Management

Memory management is an important content of the operating system, includes

memory allocation and recovery, sharing and protection of memory messages, address

conversion, and memory expansion.

1) Memory organization

A feature of the BSC is the embedded application, i.e. there will not be frequent

memory application/recovery activities. Link mode is used to organize memory blocks

and the "Best_Fit" algorithm is used to allocate memory.

2) Memory check and memory protection

The software system of the BSC adopts the plane mode. All data and program codes

are stored in a section of memory area. Therefore, memory protection is required to

prevent the overriding of memory. In the memory control block there is a "memory block

flag" (domain flag), which contains 2 bytes. Two special characters, for example 'M' and



10/71


3-10

'Z' are stored to indicate that the memory block is normal (undamaged). If the contents

in the flag of the memory control block are not 'M' and 'Z', the contents of the

corresponding memory are damaged.

The BSC operating system periodically checks the validity of each memory control

block on the memory link, including the check of the contents in the flag to see if they

are 'M' and 'Z' or whether contents in the other domains are within the valid range or not.

Once a fault is found, the fault recovery mode shall be used for processing. It is also

possible that the task containing the damaged memory shall be interrupted and a new

task shall be generated.

3) Conversion of memory address

Address conversion is a process of address reallocation. In programming,

programmers use logic addresses independent of the equipment. The address space

composed is called the logic address space, which corresponds to the physicaladdress of the memory and the physical address space. Once a program written with

logic address is stored into memory, and its address and the physical address of the

memory set up a relation. To run it correctly, address conversion should be executed

according to the relation, that is, to map the program address onto the physical address

of the memory.

4) Memory capacity expansion

Memory capacity expansion, also called virtual storage, means that the programmer is

not limited in programming by the structure and capacity of a memory that the program

can directly access. The system creates a storage space for the user, which is much

bigger in capacity than the memory. This requirement-oriented storage space is called

the virtual memory or memory expansion. The expansion of memory is implemented inthe following two ways:

Division of program address space and memory physical address space.

Relocation of program address to physical address, the model is as shown in

Figure 3-7.

a'

Mapping table

aProcessor Memory

Address conversion part

a'

a: program address a': memory address

Figure 3-7Relocation of program address




11/71


3-11

When the memory address of 'a' can not be found via the mapping relation, some

information in the program space must be on the external memory. Therefore, the

external contents must be first introduced into the memory, and then the address

mapping relation is to be modified before the address conversion is continued. The

expansion of memory is in fact enabled by occupying CPU time for the switching of

internal and external memories and by occupying the external space.

IV. Time Limit Management

The BSC executes time limit management according to the real-time processing

requirements.

Cyclic dispatch: This refers to the clock-level tasks. Clock-level tasks in the BSC

operating system are of three types: 10ms cycle tasks, 1s cycle tasks and 1m cycle

tasks.

Timeout dispatch: When the time designated by the user is due, timeout messages will

be sent to the user to activate the task of timeout processing. Timeout dispatch services

provided by the BSC operating system include absolute time limit and relative time limit.

Absolute time limit requires the operating system to process tasks at an absolute

moment defined beforehand. Timeout messages will be transmitted at this absolute

moment. The absolute time has two cases:

Without cyclic repetition: The system is required to monitor a future moment.

When the task is over at due time, the procedure will be ended, i.e., it will not be

repeated again.

With cyclic repetition: A user can set certain time after which a function/procedure

can be repeated so that regular results can be obtained.

For example in call charging there is need for call bills (call data). A process can be set

on 02:00 with the cycle of 24 hours so after every 24 hours the call bill process will start

at 02:00 and will provide the required data.

Relative time limit means that timeout processing shall be executed some time after the

user puts forward the timeout requirement.

The BSC operating system provides the following system invocations related to timer

services:

start_devtimer: start relative time limit services with the basic unit as second.

start_100ms_devtimer: start relative time limit services with the basic unit as 100ms.

stop_devtimer: stop relative time limit services.

register_sys_timer: register unrepeatable absolute time limit services.

register_day_timer: register repeatable absolute time limit services with the cycle of

24 hours.


12/71


3-12

cancel_sys_timer: cancel absolute time limit services.

V. Initialization and System Recovery

To improve the system reliability and self-recovery, the BSC system provides two

important system recovery levels: restart and booting loading.

Restart mainly executes initialization operations and then decides whether to start

booting loading according to the restart level. In this way the control and state variables

of the system can be recovered as defined initially.

Booting loading is the recovery of a higher level. Programs and data will be

reconfigured in the memory through OMC.

1) Restart

The BSC system provides four levels of restart in accordance to different operationalenvironments and terminal maintenance facilities. Detailed functions and system

restart effects are given below.

Restart of Level-1:

Ongoing call proceeding will be affected.

Connected calls will not be affected.

Data and programs will not be loaded.

Restart of Level-2:

Control and state variables of all modules are initialized.

Ongoing call proceeding will be affected.

Connected calls will be affected.

Data and programs will not be loaded

Restart of Level-3: Reinitialize the whole system. Data is loaded through BAM/OMC.

No program is to be loaded.

Restart of Level-4: Reinitialize the whole system. Both data and programs are loaded

through BAM/OMC.

2) Booting and loading

The system booting program and the system loading program of the BSC are 64

Kbytes in total. The basic input and output system (BIOS) occupies 512 bytes, and the

rest is the loading program.

After powered on, the system first enters ROM BIOS and executes the initialization of

GMPU memory, clock and interruption.

After this, the system will start the loading program.

The loading process is as follows:



13/71


3-13

Initialization of the global address table, interruption descriptor table and partial

descriptor table to enter the protection mode.

Initialization of timer interruption mode.

Reading the setting of hardware switches to decide whether reload from the BAM

or from the Flash Memory. To load from the BAM, either data only, or program only,

or both data and program can be loaded. The parts that are not loaded from the

BAM are loaded from the Flash Memory. The sizes of program and data Flash

memories can be set by jumper setting to meet different operational requirements.

When re-loading from the Flash Memory, the loading program shall check the

programs and data in the Flash Memory. If errors are found, the loading program

will request to load from the BAM.

Selection of the loading path. Different loading paths shall be used for different

configuration requirements of modules.

If program or data is to be loaded from the BAM, set up connection with BAM.

Otherwise omit this step.

Load the GMPU program or data to the designated directories.

Check after loading. If the loading is not correct, re-load the data or program.

If the program is loaded correctly, read the switch state of the hardware to decide

whether to back up once again the program that has been loaded into Flash

Memory.

Switch to GMPU software program execution. The dumping of the GMPU data to

the Flash Memory is done by the GMPU. The loading program is responsible for

the verification task only.

3.3.2 Database Management System (DBMS)

Functions of the BSC are executed by program control while the introduction and

deletion of these functions are enabled in a coordinated manner by data in the BSC. In

general, the data is stored and managed in a centralized mode, and the collection of

the data is called database. The management of database is executed by the DBMS

module in the GMPU software of the BSC.

I. Data Structure

According to its organization, the DBMS can be classified into hierarchical, meshed

and relational databases. According to the data storage mode, DBMS can be classified

into distributed and centralized databases.

Data in the BSC is distributed in multiple modules, but logically belongs to the same

database. For single-module BSC, module number is 1 and all data of DBMS are

distributed in a single module. The relation of data is described in a bivariate table,

which is called relational table. One dimension of the table is called tuple, and the other

is called domain or field. Tuple composes one logic record, while domain defines the


14/71


3-14

relevant data item of the relational table. The number of domains reflects the

complexity of relational table.

1) Data dictionary

Data definitions in DBMS are described by the data dictionary. Two types of description

tables, relational description tables and domain description tables are generated. The

former type describes the structures of relational tables and the latter describes the

domains in tables.

2) Data type

Data used in the database of BSC is basically of the following types:

Unsigned character integers within the range of 0 255.

Unsigned integer within the range of 0 65535.

Unsigned long integer within the range of 0 4294967295.

BCD character string, the valid values of characters are within 0

9.

ASCII character string, valid ASCII characters.

3) Table types and retrieval methods

Descriptions of table types are in the relation description table of the data dictionary.

Database of BSC uses the following three types of relational tables.

Direct index table: The tables are directly accessed by using tuple numbers. The tuple

number is not a part of the relation, and the insertion and deletion of the tuple shall not

affect the sorting of the table.

Sequential search table: All tuples in the table are stored according to the sequence.

The search starts from the first tuple and continues in sequence. The newly added

tuples are put at the end of the table.

Sorting table: Tuples in the relation are sorted according to values of key words. Two

tuples can not be stored in one table if values in their sorting fields (key domain) are the

same. In case there are multiple key domains, each key domain can be assigned with

the sorting mode (ascending sequence or descending sequence) and sorting serial

number. The domain with the smallest serial number is in the first priority. The retrieval

of the sequencing table is enabled through dichotomy. The insertion and deletion of a

tuple will cause the movement of the subsequent tuples.

II. Database Structure

The database of the BSC has the distributed structure. Data is distributed in multiplemodules. Each module is responsible for maintaining the local database on the module

and hence is relatively independent. At the same time, each local database is a part of

the global database. Multiple local databases cooperate together to provide the

functions of the global database.




15/71


3-15

The structure of the database on each module is shown in Figure 3-8. Note that there is

only one BM in single-module BSC, hence AM/CM is not required.

AM/CMBSC database

API API

DBMS

Application programinterface

DB

DBMS DBMS

Database Database

BMBM

DBDB

Figure 3-8Module database structure

1) Database

A database, composed of multiple relational tables, is loaded into the memory of GMPU

through BAM from OMC. The access of DBMS to the database is made in RAM and no

disk file operations are needed, hence high speed retrieving is achieved.

Via the control of the GMPU DIP switches, data can be stored in the Flash Memory, and

the modification of data can be duplicated onto the Flash Memory of GMPU, which will

not be lost in case of power failure. On system restart, GMPU can read the originally

stored data from Flash Memory and store it to the memory of GMPU, so it is not

necessary to load it again.

2) Functions of database management system (DBMS)

Functions of the DBMS in the BSC include:

Data definition (defining the structures of relations, field types, distribution places

of data, access modes, etc.)

Provision of application programs with interfaces for retrieving, storing and

modifying data.

Ensuring the consistency and safety of data.

Data backup.

3)Application Program Interface (API)

The API of the database is the interface between the database module of the BSC and

other modules. It makes use of functions provided by the DBMS and provides database

access interfaces for such modules as radio resources management, base station

management, operation and maintenance, performance management, alarm

management and BAM.




16/71


3-16

Functions of API are given below:

Radio resource data management provides data configuration of the following

functions: call procedure, system information, channel management, power

control, handover decision, short message, timer management, frequency

hopping (FH) management and flow control.

The BTS data management provides the BTS configuration data for the base

station management module.

SS7 signaling data management provides the configuration & management of

MTP and SCCP.

Circuit data management executes management of A-interface and Abis interface

circuits according to the configuration of circuit data so as to guarantee that the

assigned circuits in the call process are configured and valid.

Data support for operations and maintenance provides hardware configuration

data for the operation and maintenance module.

Data support for alarms provides alarm configuration data to alarm modules.

Data maintenance cooperates with BAM to enable maintenance of the database,

including the storage, dumping of the database and the addition, deletion and

modification of tuples in the relational table.

III. Features of BSC Database

1) Distributed database

Data is distributed in multiple modules. Each module stores its own data. All data

requests are sent to the local database, and the user does not need to care about the

storage places of the data. Due to this distribution of data, a fault within a module will

not affect the working of other modules. As for single-module BSC, all data is stored ina single module. All queries are done locally, this helps to improve query efficiency.

2) Flexible and reliable expansion

The structure of the relational table and definitions of fields are wholly based on

descriptions of the data dictionary. Modification of the table structure or the introduction

of relations will not cause the change of program code. Therefore, DBMS features fine

expandability.

3) Flexible data setting

BSC must satisfy multiple networking modes and requirements for multiple services. Its

flexible designing makes it free from restrictions.

3.3.3 Software and Data Maintenance

I. System Software and Data Protection

The system software and data of the BSC are stored as files in multiple storage media.

The BAM in the BSC has two 1GB hard disks mirrored to each other, carrying the




17/71


3-17

software and data of BSC. The software and data can also be duplicated on optical

disks or tapes for backup.

GMPU board on each BM of the BSC has one 4 MB (for program) and one 3.5 MB (for

data) Flash Memories. It also has 32 MB RAM, in which the program and data in actual

operations are stored. The intelligent boards also have flash memories of different

capacities to store the software and static data of local modules or boards. Flash

Memory provides such functions as power-failure protection, high access speed, and

repeated erasing and writing. The relation of the BAM hard disk, Flash Memory and the

software and data of memory is as follows.

The hard disk of BAM has a loading description file, which describes the file names and

directories to be loaded on different modules and intelligent boards of different types.

When there is a request for loading from GMPU or intelligent boards, BAM shall send

the needed software and data to assigned GMPU or boards via corresponding loadingchannels according to the descriptions in the loading description file. At the same time,

BAM shall decide whether to write the software and data to be loaded into the

corresponding Flash Memory according to the loading switches on GMPU and boards

(program available, program writable, data available, data writable, etc.). According to

the GMPU or board switch settings, when the system or boards restart, either the

software or data from the Flash Memory should be used or software and data shall be

loaded from the hard disk of BAM. Data modified dynamically in the memory (such as

the online settings of data in some tables made by the maintenance staff) shall be

written periodically into the Flash Memory and the hard disk of BAM so as to ensure

that the modified data is valid during system restart.

Each module has two GMPU boards in active & standby configuration. These boardsare mutually updated through GEMA to ensure the smooth transition of system during

dual-system switchover without any disturbance to the subscriber services.

In general, the system software is a kind of data itself, which is recorded, stored and

used in the form of file for the purpose of centralized management. So the management

of software and data is just management of data in the final analysis.

II. Data and Database

1) Data

Service and functions of the BSC are implemented by programs, and the description,

import, addition, deletion and control of the application range and environment are

enabled by specific data. Programs and data are separate. Programs respond to

events according to the settings of data and implement the services and functions of

the BSC. With data driving, system flexibility has been enhanced and the planning,

optimization and adjustment of the system is facilitated by making data modifications.


18/71


3-18

In the traditional file system, each program defines its data files, "redundancy" and

"inconsistency" is always caused. "Redundancy" is caused as the same data is used by

different programs and, it is dumped for many times. "Inconsistency" always occurs

when a program modifies its own data files while not modifying the same data obtained

in the data files of other programs. As most data must be used and owned by multiple

software modules, the issue of data sharing must be solved.

Various data are usually stored in a centralized way. And the set of the data is called

database, which is managed by DBMS. If the user needs some data, he or she can

make request to DBMS, which will provide the user with the data needed.

To make full use of the system structure of BSC, which is the multi-module distributed

group control structure, Distributed Relational Database Management System

(DRDBMS) can be used to organize, manage, describe and access the data of BSC.

In addition, another advantage of adopting DBMS is the safety, i.e. the protected data

can not be accessed or modified by unauthorized users and can not be damaged by

disastrous events.

The database in the BSC is described in the distributed relational data mode. It is

distributed because each BM stores part of the data, including global data, global link

table data and private data. Data on one module is stored according to the relation

mode and is managed by the relation database sub-system in a unified mode. Relation

database sub-systems on different modules are independent of and consistent with

one another. Therefore, the relation database sub-systems of switching modules are

physically separated and compose a part of the whole database system. Logically

these relation database sub-systems are an organic integrity and compose the

distributed relational DBMS.

In the relational database of the BSC, the data is made up by two-dimensional tables,

which are called relational tables and are a set of relative data, as shown in Figure 3-9.

} Tuple

Key domain

Figure 3-9An example of relation

A row in the relation is called a tuple (or record) and a column is called a domain (field).

Each tuple constitutes a logic record. For example, in a relation that describes

equipment, the amount of tuples is determined by the amount of equipment, and the


19/71


3-19

amount of domains is decided by the degree of complexity of the logic. The use of this

relation facilitates programming and application

Data in the relations of BSC includes unsigned integers with 1 - 4 bytes, BCD codes,

tuple numbers of 2 bytes and block types with uncertain bytes.

Data in BSC is of the following types:

System data: Intrinsic data of the software, such as software parameters, timer and

event descriptions.

Configuration data: Data of the BSC cabinet, frame configuration, slot configuration,

mailbox, transmission HW configuration, clock configuration, etc.

Local office data: This data describes the network parameters of the local BSC and

represents some information such as signaling point information of BSC, phases of the

interfaces, mobile country code, mobile network number, basic data for subordinate

cells, configuration data for carrier frequency, TRAU configuration data, radio channel

configuration data, BIE configuration data for BSC side and site side, LAPD

configuration data, signaling channel configuration data, traffic channel configuration

data, etc.

Site data: It describes the configuration data of subordinate sites of the BSC, including

site slot position data, board software configuration data, and configuration data for

frequency points of the cell carrier frequency.

Cell data: It describes the properties (data) of the subordinate cells of the BSC,

including system information data of the cell, cell frequency allocation data, frequency

points of adjacent cells, switches and parameter data for intra-cell call control, other

properties of the cell, etc.

Handover data: It describes the parameter and switching data required for handover

control.

Power control data: It includes parameters and switching data needed by the BSC in

power control, including power control selection data, cell power control data, the BTS

power control data and MS power control data.

Channel management data: It describes data required by BSC during the management

and allocation of radio channels, including radio channel management and control data

and bad channel management and control data.

Trunk data: It describes circuit data of A-interface and Pb-interface, and data of their

signaling coordination as well as Abis-interface circuit data.

SS7 data: It describes data of MTP and SCCP of SS7.

Alarm data: It describes the alarm parameter data of BSC and BTS.

2) Database Formatted: Bullets and Numbering


20/71


3-20

The BSC organizes data by using the relation mode, which describes the relation

between entity set properties and entity sets via the two-dimensional tables that enable

relational algebraic operations. The relation mode induces the logic structure of data to

a two-dimensional table that satisfies certain conditions, and the table is called a

"Relational Table". The major characteristic of relational table is that not only data, but

also the relation between data is represented.

The BSC database is a set of data relations, made up by various two-dimensional

tables. One dimension is called tuple (row), and the other is called domain (column).

Each tuple is equivalent to a logic record, and each domain corresponds to a certain

property and is equivalent to a data item in logic records. Hence the amount of domains

is determined by the logic complexity of the relation. In a relational table, key domain

instead of pointer is used to query data. And a key domain can include one or multiple

domains. Each search domain also includes one or several domains and is used to

store a certain tuple in the record.

To obtain the data of some tuples, a user program must inform DBMS of the relational

table and also the tuple in the table to be stored. This can be done by defining the

search domain.

In the database of BSC, relations are of two types:

Real relation

Virtual relation

Real relations refer to the relations that are defined by software, stored in the database

and found in the GMPU memory.

Virtual relations, on the other hand, are not stored in the database and memory, butcreated by reconstructing the real relation so as to speed up the search for data and

meet different requirements of users. Virtual relations mainly include redefined relation,

multi-target relation and procedure relation.

A redefined relation is actually a sub-set of the real relation. That is, the existing real

relation is re-defined. Some domains in the real relation are extracted and the sub-sets

are given a redefined relation, as shown in Figure 3-10.

Name and address Personal file

(Redefined relation) (Real relation)

Cell name Cell number Cell name Cell number Cell type Cell CGI ...

A 0 A 0 GSM900 4600027000001 ...

Figure 3-10Example of a redefined relation with same key domains

It can be seen from Figure 3-10 that the name and address list is actually created by

reconstructing two domains extracted from the personal file list. Therefore this list is not


21/71


3-21

stored in the memory and database. For a redefined relation, the key domain should be

the same as that in the real relation. In the operations of BSC, if a user (or the software

that uses data) needs to use the data of a tuple in the redefined relation, a request

should be put forward to DBMS, which will extract the domains related with program

operations from the relative real relation and construct them into a newly defined tuple

to send to the software requesting. The structure of the redefined relation, obviously, is

not same as that of the real relation it is based on. And no modification is allowed on the

redefined relation.

Multitarget means that it is composed by domains extracted from at least 2 real

relations by using the designated link algorithm, as shown in Figure 3-11.

Name and ID table (real relation) ID and address (real relation)

Cell name Cell number Cell number Cell CGI

A 0 0 4600027000001

Key domain |________________________| key domain

Link domain

Name and address list (virtual relation)

Cell name Cell CGI

A 4600027000001

Key domain Key domain

Figure 3-11Example of a multi-target relation

It can be seen in Figure 3-11 that in constructing the "Name and address list" of the

multi-target relation, one of the two real relations shall provide the base point for

constructing the virtual relation. Therefore, the key domain in the multi-target relation

should be the key domain of the real relation. In addition, the link domain plays a vital

role in constructing the multi-target relation, because the data in the next real relation

can only be found by using the link domain. Hence the value of the link key domain in

the first real relation should be the same as that in the key domain of the second real

relation in the multi-target relation. This induction shall go on until all domains involved

in multi-target relations are completely linked.

The application program of the BSC does not care whether a multi-target relation exists

in the memory, but it cares how to obtain the required data in program operations

quickly and conveniently from the multi-target relation.

The procedure relation is a type of virtual relation. It is reconstructed by one or multiplereal relations. A procedure relation is a section of small program (called "procedure"),

which dispatches the data in the corresponding real relationship according to the

process for specific functions execution and follow a certain sequence or algorithm. In

the procedure relation, some domains are dispatching entrance parameters. Some

other domains use algorithm to execute the calculation results or output parameters. If

the procedure relation can not find the real relation needed from the local GMPU


22/71


3-22

memory, the real relation will either in the memory of other modules or stored in the

system disk.

The BSC system adopts the modular distributed control technique. Each module is

equipped with data according to the required functions. Hence the database of the BSC

system is actually a sum of the data in all modules. Its physical arrangement in the

database must be determined by actual needs. For single-module BSC, there is no

distribution of data in multiple modules.

A common relation can be found in a certain module, and its tuples are not distributed in

other modules. In some cases, a module needs only part of the data in a relation while

other modules shall need the other data of the relation. To avoid repetition, the relation

can be divided into different blocks. Each block shall only store the tuples for access. In

this case, a relation is thereby distributed into different modules.

Another case is that a group of modules need the same data of a same relation. If there

is only one relation for such data, it will take a long time to access the relation as all data

requests will be sent to the module that contains the relation. To avoid such an event,

data copies of the relation should be kept in all modules that shall use the relation. That

is, the relation shall be copied into different modules. For the repeated use of a relation,

the key point is to keep the data copies consistent with one another.

In a word, a module can contain an independent data relation or a related data relation,

that is, distributed relation and replicated relation.

1

2

3

4

5

DBMS

Module 1

6

7

8

9

10

DBMS

11

12

13

14

15

DBMS

Module 2 Module 3

Relation A Relation A

Relation BRelation BRelation B

Relation AUsersoftware

Figure 3-12A distributed relation

It can be seen from Figure 3-12 that the data distributed into three modules belong to

the same relation A, whose 15 tuples are distributed to different modules. Module 1

contains tuples 1-5 of the relation, module 2 contains tuples 6-10 of the relation, and

module 3 contains tuples 11-15 of the relation. If the user software of module 1 needs to

access the data in tuples 1-5, it can find the data in the local module.


23/71


3-23

1

2

3

4

5

DBMS

Module 1

1

2

3

4

5

DBMS

1

2

3

4

5

DBMS

Relation A Relation A Relation A

Relation B Relation B Relation B

Usersoftware

Module 2 Module 3

Figure 3-13A replicated relation

It can be seen from Figure 3-13 that data in the three modules of relation B is the same

and contains all tuples (1-5) of the relation. In the event that a module needs the data of

the relation, it need not search in other modules. But when the data in the relation is to

be modified, data in all these three modules must be modified. It can be retrieved from

the data dictionary as for which modules contain copies of the replicated relation.

Some relations in the database of the BSC can either be separated or replicated, or

both.

The database system of BSC can be divided into two layers. The bottom layer is the

relation management layer used to provide such functions as:

Storage, query, modification and duplication of expansion relation-based data

modes.

Control of the integrity, processing-based safety and consistency of data.

Backup of database.

The upper layer comprises service level interface modules and the data maintenance

modules. Service level interface modules support the query and search of database in

service modules. And the data maintenance and the terminal data management

console enable the modification and query of online data as well as other maintenance

management operations in the database.

There are three ways of retrievals in the of BSC database, which can be found by

checking the data dictionary.

Sequential retrieval: All tuples are stored according to the sequence. And each access

shall start from the first tuple, then goes on with the second until the needed tuple is

found. The newly added tuple is put at the end of the relational table and the constantly

read tuples are put at the beginning.

Index access: This means the access to a relational table via the index domain of an

index list. Index access is applicable to direct index lists. The index domain is


24/71


3-24

implicated and not a part of the tuple to be accessed. In general, the values of the key

domain compose the index according to the sequence. If the contents for index are too

many, they can be divided into blocks and set into the indices of multiple levels.

Dichotomy retrieval: The dichotomy retrieval starts from the middle of the relational

table. If the value of the limited condition (composed by multiple key domains) is

greater than that of the entered value, it will compare with the mean value at the bottom

half (key domains are arranged from small to big into the dictionary sequence), and

continue the binary comparisons until the required tuple is founded.

Dichotomy is a quick search algorithm. Its shortcoming is that the addition or deletion of

a tuple is very complicated by reorganizing and rearranging the relation.

III. Data Maintenance and Operation Terminal System

The data maintenance and operation terminal system follows the client/server structure.

The data management server is an object-oriented server set up on the

description-based database system. It not only enables the data access request of the

client terminal, but also provides data storage and access capability for other

application sub-systems. The client terminal of data management provides a

convenient and friendly man-machine interface and provides functions for the BSC as

addition, deletion and modification of both single-piece and batch data as well as

sequencing, querying, setting, printing and backup of data. To ensure the safety of data,

three levels of operation authorities are set for operational staff: operation authority,

setting authority and management authority. The operation authority has the lowest

level, setting authority has higher level and management authority has the highest level

of authority.

1) Data management

The distributions of data arise from requirements of specific application systems. For

large-scale database management systems, distributed management can improve

system performance and reliability and reduce system costs. For BSC, the introduction

of the distribution concept increases the flexibility in system configuration and curtails

cost.

The configuration structure of the single-module BSC is shown in Figure 3-14.


25/71


3-25

BM

BAM

Client Client

Database

DatabaseForeground

Background

M900/M1800 BSC

Figure 3-14Structure of a single-module BSC

The configuration structure of a multi-module BSC is shown in Figure 3-15.

BM

BAM

Client Client

Database

Database

Foreground

Background

AM/CM Database

BM Database

M900/M1800 BSC

Figure 3-15Structure of a multi-module BSC

Data is first distributed on the BAM server. Then it is sent to and stored in the BM and

the database of AM/CM after conversion and loading. BMs and AM/CM only need to

access the data in the local module when reading data instead of paying remote access

via inter-module links, which improves the system performance. Data of each BM is


26/71


3-26

different from that of AM/CM. Only related data of each module is stored in it so that

distributed data management is realized.

The BSC can be configured with multiple terminal systems. Each maintenance system

can maintain the data of the BSC. Via the management of user authorities, illegal

access or operations can be controlled.

2) Data conversion

According to the features of data operations, the foreground database adopts the

self-designed special database system, whose data management mode based on the

specific characteristics of the BSC, is different from normal database systems in

storage format, relation mode and index mode. The database of the background

maintenance terminal system adopts the standard database mode to enable the

storage format, relation mode and index mode. Hence the difference between the data

formats of the background and the foreground comes into being. The backgroundmaintenance terminal system adopts the format conversion mode to keep the

consistency of foreground and background data as well as validity of data. The

conversion process converts the data required by different modules into different files

according to the configurations of modules. In the loading process, relative data files

shall then be loaded into relative modules.

3) Data management server in the client/server structure

The client/server structure is a very popular database management system. DBMS is

designed on the bases of ORACLE and SYBASE. The advantage of the structure is

that according to the division of functions, data operations and data usage are

separated. Functions are shared and the performance of the system is greatly

improved. The security of the database system is further guaranteed and providesmultiple and flexible operation methods and modes for large-scale data applications.

The service access mechanism under the client/server structure is shown in

Figure 3-16.




27/71


3-27

Message processing

Background message processing

Datamanagementsystem

processing

Foreground message processing

Testsystemp

rocessing

Trafficstatisticssystem

processing

Load

MMLprocessing

Alarmm

anagementsystem

processing

Load

systemp

rocessing

Maintenancemanagement

systemp

rocessing

Dataonlinesetting/query

Figure 3-16Service access mechanism

4) Contents of data maintenance

Data management of the BSC includes configuration data management, local office

data management, site data management, cell data management, handover data

management, transmitted power data management, channel data management, trunk

data management, SS7 data management, alarm data management and data

operation management.

Configuration data management: Configuration data describes the hardware

configuration of the BSC, common parameters and data in the AM. Hardwareconfiguration includes frame description, slot description, board description, NOD

description and module description. Common parameters include module parameter,

maximum common tuple number and semi-permanent connections. AM data includes

AM frame description, AM board position description, AM board active/standby group,

AM module description, AM clock description and AM alarm switch description.

Local office data management: Local office data includes local office parameter data,

mobile country code table, mobile network number conversion table, BSC cell table,

frequency hopping data table, TRX configuration table, radio channel configuration

table, LAPD semi-permanent connection table, LAPD signaling connection table,

TRAU configuration table, BSC BIE board description table, the BSC BIE board

active/standby group description table, the site BIE trunk mode description table, thesite BIE configuration table, signaling channel connection table, SS7 timeslot table, the

corresponding relation between MSM and FTC, GMEM board configuration table.

Site data management: Site data includes site description table, TRX configuration

table, frame description table, slot description table, software configuration description

table, BS environment alarm configuration data table and TRX handover control table.



28/71


3-28

Cell data management: Cell data mainly includes system information data, cell

configuration data, cell frequency point data, BCCH data of adjacent cell, SACCH data

of adjacent cell, cell attributes data, cell alarm threshold data, cell call control data, and

cell call handling parameter data.

Handover data management: Handover data includes handover control data, cell

description data for handover, external cell description data, cell adjacent relation data,

filter data, penalty data, emergency handover data, load handover data, normal

handover data, fast-moving handover data and intra-cell handover control data.

Power control data management: Power control data mainly includes power control

selection data, ordinary cell power control data, BTS power control data, MS power

control data, and HWII power control data.

Channel data management: Channel data mainly includes radio channel

management control data and damaged channel management control data.

Trunk data management: Trunk data includes office direction data, trunk group data,

trunk group SS7 data, A-interface trunk circuit data, and Pb interface trunk circuit data.

SS7 data management: The BSC supports SS7 mode which is 14/24-digit compatible.

The 14-digit mode is used in BSC. SS7 data management includes the management of

DPC data, SS7 link set data, SS7 route data, SS7 link data, CIC data, PCIC data,

SCCP destination signaling point data, SCCP sub-system data, GT code conversion

data and new GT code conversion data.

Alarm data management: Alarm data mainly includes such data in the BSC and BTS

as alarm parameter configuration data, alarm environment variable configuration data,

alarm information parameter data and alarm information detailed explanation data.

Miscellaneous : In addition to the above-described data, there are still many system

parameter data such as software parameters and clock parameters.

3.3.4 Radio Resource Management

A critical difference between PLMN and PSTN lies in their resource management. For

PSTN, communication medium can be applied to use whenever a call needs to be

established. While for wireless cellular system like GSM, the dedicated channels of the

radio interface is allocated to the MS (a requirement of the network). When MS drops

the call the radio channels will be released and wait for another call request.

Specifications of the GSM signaling part comprise three functional parts, which are

Radio Resource Management (RR), Mobility Management (MM) and Communication

Management (CM).


29/71


3-29

The key contents of radio resources management is to manage the transmission route

of the radio interface, and responsible for the establishment, maintaining and release of

radio resources.

RR connection is used to connect two peer entities and provide support to the

exchange of information in the upper level, and as a result, point to point conversation

between MS and network can be implemented. Additionally, RR management is

responsible for receiving information from BCCH (PBCCH) and CCCH (PCCCH)

channels.

Radio resources management is distributed in four entities in the GSM system

architecture, which are MS, BTS, BSC and MSC. MS and BSC are responsible for most

of the work.

Mobility management is responsible for the MS location/route data and its updating.

This function is mainly accomplished by MSC (SGSN).

Connection management is responsible for controlling the interworking between the

GSM network and other networks and for the setup and release of the end-end

transmission path to support communications between users. Connection

management depends on the functions for handling the user's mobility and security in

mobility management

I. Call Procedure

During the radio channel management, various messages are exchanged between

different equipment of the network and MS.

The BSC accomplishes signaling processing of various interfaces in a call process and

consequently implements radio resources management.

The whole call process starts from access. Access can be triggered either by MS (e.g.

MS activation request or location update information), or by network (e.g. paging for

GSM subscribers). The access of mobile station is made through the random access

channel (RACH) or packet random access channel (PRACH). In MS access request

only an information of 8 bits is provided, which can not give the specific identification of

the MS. This may result in mistaken access requests due to frequent interference. In

addition, RACH (PRACH) transmission is irregular. It is possible when two mobile

stations initiate request for access at the same time, it will result in the failure. In the

BSC system, the threshold values can be set for BTS to effectively prevent mistakenreports and to distinguish random access collisions.

GSM phase2+ supports two kind of services i.e. data services and speech service. The

procedure of circuit and packet calls is described below.

1) Circuit-based call


30/71


3-30

In this procedure, BSC initiated a dedicated channel allocation procedure after

receiving an access request from MS. The BTS decodes the request correctly and

indicates the BSC to allocate a dedicated channel and activates it in BTS via channel

request information. Then the BTS informs the MS to accept the dedicated channel via

AGCH (access grant channel).

In special cases, if the network facilities response so late to the access request that the

MS re-sends access request, multiple channels may be activated in the BTS. Only one

will be used effectively (the information carried on the 8-bit access requests is not

sufficient for distinguishing mobile stations), as a result, the limited radio resources will

be seriously wasted. In the BSC, a mechanism is designed to prevent such cases.

Thanks to this mechanism, dedicated channels can be established quickly even in big

traffic situation, which consequently accelerates the process of signaling connection

and shortens the signaling connection time.

In the specially established channel, signaling interaction is executed between the

mobile station and the network facilities. After the interaction, the network obtains the

necessary information and allocates a terrestrial link for calls from the MS. Then it

informs MS via radio interface to access and begin the communication process.

Channel release procedure begins after the communication is finished, where radio

links and terrestrial links will be released successively.

2) Packet-based call

When no PCCCH is configured in the serving cell, the channel request message from

the MS is transferred to the BTS via RACH and then reported to the BSC. The BSC

forwards this message to PCU and receives the packet immediate assignment

message from PCU and then sends it to the MS. The BSC will not handle the packet

channel request, but sends it directly to the PCU.

If an MS accesses the packet services for Paging Response, the BSC can not

determine the service type of the access, it then allocates DCCHs first and enters

dedicated mode. After EST_IND of RR_INITIALITION_REQ of layer 3 is received, it

transfers the message to PCU and then enters packet call.

If the MS access packet service via the PCCCH of the cell, then the packet call

procedure is transparent to the BSC.

II. System Information

System information is information about network technical attributes broadcast

incessantly in the BCCH (broadcast control channel) and SACCH (slow associated

control channel). It includes frequency configuration of cells, configuration of common

channels, whether or not to allow emergency calls, whether or not to allow call

re-establishment, etc.



31/71


3-31

MS in idle mode constantly receives system information to keep contact with the

network facilities. In addition, many parameters in system information control the

activities of the MS, including by what means the MS selects cells, by what means the

MS starts access applications, whether the MS adopts the VAD transmission

technology, etc.

At present, M900/M1800 BSC system provides 12 types of system information

demanded in GSM Phase 2+. The system can support the coding of 1024 frequency

channels and the free usage of dual-band mobile stations in the networks of GSM 900

and GSM 1800. In the coding of frequency channels, the limited resource of system

can be most effectively used by selecting automatic coding formats according to the

range of the input frequency channel. Frequency point coding formats currently

supported by the system are Bit map 0 format, Range 1024 format, Range 512 format,

Range 256 format, Range 128 format, and Variable bit map format. Besides, frequency

point coding of the above formats are also enabled in the descriptions of adjacent cells

in system information, and as a result, the handover of dual-band mobile stations

between GSM 900 and GSM 1800 networks can be implemented.

In system information, some data shall be defined by service provider. The BSC system

provides friendly interfaces, which makes information upgrading easy.

In addition, system information in the BSC system also supports GSM 1800 Class-3

MS, and provides necessary parameters for GSM 1800 Class-3 MS to enable the

functions of power control, handover and cell selection.

The 12 system information supported by the BSC system includes

SI1/2/2bis/2ter/3/4/7/13 and SI5/5bis/5ter/6. 5/5bis/5ter/6 is transmitted on the SACCH

and the other 8 messages are transmitted on the BCCH. Only in case of packet service

support, will the cell transmit the system information 13 (SI13). Whether the

transmission of 2bis/2ter/5bis/5ter is permitted is up to the BCCH frequency point

configuration of its adjacent cell. For detail information, please consult GSM 04.08

protocol. The PCU is responsible for the packet system information transmitted on the

PBCCH.

III. Channel Management

Channel management includes two aspects. The channel set for each cell must be

determined, and certain equipment should be configured. This is a "long-term" cell

channel configuration management. On the other hand, channels shall be

allocated/released periodically according to the communication requirements of MS.

This "short-term" management is called the dedicated channel allocation management.

Channel configuration management and channel allocation are all handled by the BSC.

The MSC only indicates the types of channels for each specified communication while

the BTS executes relevant tasks controlled by BSC. Both types of management


32/71


3-32

activities have great effects on the signaling handling processes on radio and Abis

interfaces.

The BSC is not responsible for the allocation of the PDCH (packet data channel). It only

records the state of the packet data channel. When there is change to the state of the

PDCH at the BSC side, the BSC needs to notify the latest state of the PDCH of the

PCU.

IV. Channel Configuration

Channel management in the BSC system provides friendly user operation interfaces

for the channel configuration management of cells. Data of broadcast channels,

dedicated channels, traffic channels and radio frequency points can be conveniently

configured and modified.

1) Allocation of dedicated channels

Dedicated channel allocation management of the BSC system follows the combined

strategies of VEA (very early allocation) and EA (early allocation). The VEA strategy is

used for some special calls while EA is for ordinary calls. The combined modes can

effectively improve the usage of channels. Besides, if the local cell has no idle channel

to assign, the system will initiate the directed retry mechanism, and requests radio

channels from its adjacent cells to establish that call so the success ratio of calls is

improved.

Channel management in BSC system divides the idle channels into different groups

according to interference conditions and traffic is allocated accordingly.

The packet channel resources ensure the reasonable load-sharing between channels,

based on a specially designed algorithm of Huawei. In addition, channel management

in the BSC system supports the allocation of access applications of different priorities

and the queuing of access applications.

The allocation of dedicated channels can be executed according to the preset priority

levels. In some cases, access requests of higher priority can forcibly occupy the

channels being used by lower priority users. When the channels are busy, access

requests can be queued. Under the protection of the preset timer, dedicated channels

can be allocated for new access requests within a period acceptable to the users.

2) Dynamic allocation of SDCCH

In many cases it is difficult to predict and calculate the demand of a cell for SDCCH.The SDCCH dynamic allocation mechanism employed by BSC system enables the

channel configuration to be consistent with the current actual traffic model (features) so

as to reduce call loss and maximize the system capacity.

Its key idea is, if SDCCHs are insufficient in a certain cell, TCHs will act as SDCCHs; if

SDCCHs become idle later, the TCHs will be restored.



33/71


3-33

3) Timeslot frequency hopping

The BSC supports frequency hopping at timeslot level of the radio channel. The

frequency hopping parameters of all the timeslots are configured and maintained at the

GMPU of the BSC, including MAIO, HSN, TSC, and MA table.

Frequency hopping parameters of different timeslots can vary when they meet certain

restrictions, that is to say, timeslot hopping parameters are of diversity.

During the procedures of BTS initialization, BTS configuration under normal running

state, cell call and handover, BSC will control frequency hopping by sending the

channel frequency hopping parameters contained in the message to the BTS

according to relevant protocols.

Frequency hopping can be divided into radio frequency hopping and baseband

frequency hopping. Frequency hopping improves usage efficiency of radio frequencies

and enhances the anti-interference capability of the radio channel, which is of great

importance in cell planning.

4) Issuing configurations to the PCU

To ensure the consistency between the BSC data and PCU data, the data shared by

the two entities is configured from the data management console at the BSC side. The

configurations are issued to PCU via the BSC during the process of running.

These data mainly include two parts: cell attributes and channel attributes. Cell

attributes include cell state, CA list, cell features and attributes, which are closely

related to the system information. Channel attributes include channel state and

frequency hopping attributes, etc. And the BSC issues configuration with the cell as the

unit.

The processes of configuration issuing between the cells can happen in parallel, but

the processes inside the cell are in series.

5) Dynamic PDCH control

It is difficult to predict the packet traffic of the cell. To improve the usage of channels,

dynamic PDCH is introduced. Dynamic PDCH is initialized as a TCH and controlled by

BSC. When the static PDCHs are not sufficient, the PCU will apply for dynamic PDCHs

from the BSC. When the PCU is granted with the control authority, dynamic PDCHs are

used for packet service. On the contrary, if TCHs are insufficient, the BSC can request

dynamic PDCHs from the PCU. When the BSC is in control, the dynamic PDCHs serve

as TCHs. It is not the BSC but the PCU that is responsible for packet data channelallocation.

V. Short Message

Short message service does not require an end-to-end path. The short message

communication is limited to one message only. In other words, the transmission of one





34/71


3-34

message makes one communication. The short message service is transmitted

transparently to BSC.

VI. Timer Management

There are different timers, which play important roles during the whole call procedure.

These timers control the progress of the calling. Beyond that, the sampling of some

timers will affect the performace of the equipment of different manufacturers in time of

inter-connection. The timers in the BSC software system operate in dynamic

management mode. When calls are made, the timers almost take up no processing

time of the main processing unit in the course of processing so that the GMPU of the

BSC software can handle more calls. Besides, the timers in the BSC system adopt a

flexible management mode. The equipment of varying manufacturers can be

interconnected easily and effectively by setting the call timers dynamically from the

OMC data management console and resorting to the testing tools available in the BSC

system. This creates a huge free space for service providers.

3.3.5 Handover Decision & Power Control

The MS may keep on moving during communication, which causes a continuos change

in its relative location. To ensure the channel quality during communication, the MS

incessantly measures the quality of the radio channels of its surrounding cells, and

reports the measurement results (MR) to the BSC via the BTS in the serving cell. The

BSC performs radio link control according to such messages as level intensity and

quality level of the serving cell and its adjacent cells contained in the MR, to guarantee

the channel quality during the whole communications process. When the MS moves

from one cell to another, then for better voice quality, MS should be connected to the

new cell.

To meet the increasing requirement for capacity and functionality in the GSM system,

the BSC improved its GMPU capability by introducing the idea of distributed processing,

that is, MR preprocessing, handover decision, and power control functions are

distributed in GLAP boards and BTS system.

The structure of handover decision and power control in the BSC system are shown in

Figure 3-17.


35/71


3-35

GMPUOMC

LAPD

LAPD bottom-layer drive

LAPD hardware

LAPD

Timed

management

MR

Mail-box/receive

send

Power control handover

Decision measurementreport pre-processing

Boardmanagement

Figure 3-17Power control flow

The handover decision and power control of the BSC system provides the following

features:

1) Distributed processing system. Radio link control functions such as handover

decision and power control are distributed to LAPD boards and BTS, which not only

results in more efficient use of the power processing capabilities of the subsystems butalso improves the system security.

2) Reduced workload of the GMPU. In case of full traffic load, the CPU occupancy ratio

of GMPU remains at 20% or below. This ensures the reliability of the system and

reserves sufficient processing capability for future function and capacity expansion.

3) Supporting dynamic configuration of parameters.

4) Handover decision functions, including:

Basic cell sorting.

Rescue handover (under conditions of TA, bad quality, rapid drop of power level,

or interference, etc.).

Border handover.

Layered and hierarchical handover.

Fast-moving handover.

Traffic load handover (including LOAD INDICATION).

Directed retry.

Forced handover.


36/71


3-36

Handover candidate cell query.

IUO cell handover

5) Power control functions, including:

MS (uplink) power control, and BTS (downlink) power control.

Initial power control.

Dynamic power control.

Power and handover controls are discussed in detail in the following text.

Power control means that BSC adjusts the output power of the MS or BTS (or both)

within a certain range.

The purpose of power control is to improve the usage of frequency spectrum and to

extend the life of MS batteries.

For calls which have been established between MS and BTS, if the received signal

quality is high i.e. high transmission power, the output power of the transmitting end can

be decreased without any affect on the quality of the established call. This reduces the

interference caused by high power signals. The BSC system implements dynamic

po

03-software description.doc

Documents