BusinessPhone Communication Platform 4.0
System Description ASB 150 02

## Software

### General

The program (software) system is divided into a number of regional and central program blocks. A program block administers a well-defined part of the system, certain hardware, a certain type of device, a certain function or a certain type of data.

A program block is usually divided into a number of program units, where each unit has its fixed function within the block.

Program blocks communicate with one another by sending/receiving messages. Program units within a block communicate with one another by sending/receiving messages or via local function calls.

Data is administered mainly within a block. When data from a block is needed in another program block, it is requested with the help of messages between the blocks.

A signal input is the place in a program unit where messages (signals) are received.

A complete program for a processor consists of a number of interworking program blocks.

The operating system in the central software has the task of linking all the parts in the entire system by functioning as distributor of the messages. The operating system in the regional software provides the corresponding features locally on a board. All operating systems have queues for messages waiting to be executed. Each operating system also offers support for local functions on the relevant boards.

Within the system each device board position, each individual device on a board and each signal input in the system has a number to be able to address messages.

These numbers are used primarily for messages but are also used as reference for the storage of data and as identity in fault logs.

Examples of program blocks are:

- Operating system (OS)
- Database, nonvolatile data (E2)
- Extension block (EX): Central administration of extensions
- Trunk block (TR): Central administration of external lines for connection to other telephone exchanges
- Digital line interface, extensions (ELD): Regional administration of digital telephone lines
- Analogue line interface, extensions (ELA). Regional administration of analogue telephone lines
- Telephone directory (DI): Central facility (lacks own devices) that stores names together with telephone numbers and, when requested by other blocks, helps to translate telephone numbers into name strings and vice versa.

Example of program units within the central extension block (EX):

- Traffic unit (EXINP): Administers telephony traffic for all telephones

Examples of messages:

- HOOKOFF and HOOKON: Sent from an extension board when a telephone handset goes off hook or on hook

Example of signal inputs:

- ST.EXINP is the name of the signal input in the program unit (EXINP) in the extension block (EX) where telephony traffic is administered.

Example of signal paths between program units:

### Regional software

The regional software on all device boards administers the hardware and line interfaces.

The main task is to read out and verify hardware signals, e.g. key depressions, go off hook or receive incoming ring signals. Furthermore, orders from the central software shall be executed, e.g. flashing LED, start ring signals, generate a tone signal or connect the device's voice channel to the PCM-bus.

It is a system principle (for off-loading the central processor) that all details in the line interfaces shall be administered locally by the regional software. Only functional signals type "call", "digits" or "disconnection" are sent onwards to the central software.

All time-critical monitoring is administered by the RP (that is time measurements from milliseconds and upwards).

The program language is assembler or C. The program code is stored in EPROM.

Data for selection of different settings is stored by the central software and is sent to RP on system start or in conjunction with reprogramming.

### Central software

The central software (on CPU-D_) has master control of all telephony and operation & maintenance functions.

The program flow is controlled by a simple, central operating system, that primarily queues and distributes messages in the entire system. This operating system also supports the central software with functions for memory allocation, time monitoring (1 second to 11 minutes), realtime clock and certain fault logging processes.

The task of the central software is to receive messages (from RP) concerning verified events, analyse them with regard to the status the device possesses (idle, digit transmission, speech state etc.) and to take appropriate measures as a consequence (interconnect devices, start ringing, etc.).

The program language is assembler. The program code is stored in EPROM. Programmable data is stored in E2PROMs or BBRAMs depending on the CPU-D_ used.

### Addressing

For communications between different units in a system a special form of addressing is required. In this system addressing is structured in the following manner:

#### Identity code (ID-CODE)

Identifies a signal input in a program (a program unit), a program-process and/or an individual device within the entire system.

Complete ID-CODE consists of four parameters

- ST: Signal type (signal input)
- SN: Signal number (process number)
- CARD: Board position
- IND: Individual number on a board

and is used for addressing messages between different program units.

Short ID-CODE comprises two parameters, ST, SN or CARD, IND and is used as identifier of programmable data in E2 - or battery backed-up memory.

Identifier with one parameter, ST or CARD is used in conjunction with fault logging to identify from which signal input in the central software, or from which board a certain fault originates.

#### Central software

"Software identifier", is called for "Job signal" and comprises two parameters, signal type (ST) and signal number (SN).

ST (value 64 - 251) is used by the operating G18 system to identify a signal input in a program unit in the central software.

SN is used locally by the program unit, normally in order to be able to differentiate between several concurrent processes (calls) for a specific individual.

#### Regional software

"Hardware position", is called for "individual address" and comprises the two parameters, board position (CARD) and individual number (IND).

CARD (value 0-63) is the number of the board position at which a certain device board is inserted. The number is permanently encoded in the back plane of the cabinet and is read by the board's RP.

IND is the number of a specific individual on a board. The individual telephone line or another unit on a device board.

### Directory numbers

#### Principles

The directory number is the number that represents an individual telephone in the system, i.e. the number to be dialled for calling a certain extension.

In ASB 150 02 a directory number is used not only as a logical identifier for telephones but also for routes, individual external lines, facilities that shall be accessed with individual numbers or with number intervals. Also functions that normally are considered as extension procedures (type programming *00#) have been assigned a directory number (*00#) in this system.

This extensive use of directory numbers is necessary because the program system offers much support for the interconnection of units/functions with the help of these numbers.

Directory numbers comprise 1 - 4 digits. Normal directory numbers that can be dialled from a telephone, consist of digits 0 - 9, * and #. Special directory numbers (cannot be dialled) that are used internally within the system by certain facilities contain the letters C,D and E.

The system can administer arbitrary combinations of one, two, three or four digit numbers simultaneously, as long as these do not conflict with one another, e.g. if a telephone has number 100 and another telephone has number 1000 there will be a conflict. As it will then be impossible to call number 1000, the caller will be connected to number 100 instead.

#### Number plans

On cold start of a PBX, all installed devices and facilities are assigned a directory number. These numbers are stored in the non volatile memory together with CARD, IND (board position and individual number) or ST, SN for facilities.

Assignment commences upon start-up at the installed boards, placed on the board position with the lowest number.

- Extensions have numbers 200, 201,... assigned
- External lines have numbers 700, 701,... assigned
- All external lines are placed in one route with number 0 For programming number *00#, etc. is assigned.

Most of these directory numbers can later be altered to the numbers desired.

### Program execution

#### Processes

"Regional process" denotes a program in a regional processor for a certain type of device that operates on an individual line.

"Central process" denotes a program in the central processor that administers a certain type of device or facility and which operates on a data area where all details concerning the state of an individual device or a function are stored.

These data areas can be permanently assigned a certain device or function but one or more data areas can also be "borrowed" on a temporary basis from a common area where a certain task is executed.

A central and a regional process for an individual device communicate directly with one another using messages with the help of regional and central support functions.

Example showing two analogue extensions that are not active in any call.

#### Status, events

A central process for a function or a device has a certain status, e.g. "IDLE".

Example with an extension that is in idle state:

The regional process for a device detects an event, e.g. a telephone handset has gone off-hook, and sends a message ("HOOKOFF") to "its" central process.

Example with an extension that is in off hook state:

The central process then receives an incoming message which indicates that an event has occurred. This event is analysed with regard to existing status. In the example this event will cause the process to change status to "TRAFFIC" and a new, temporary process is created to keep track of this call. The new process is given the status "DIGIT ANALYSIS" and all subsequent events (digits, handset on hook, etc.) are analysed with regard to this/these new status(es).

Example with an extension that dials digits:

#### Divided call control

"Divided call control" is applied. This means that the extension process in the example below only administers one half of a call. When a sufficient number of digits has been received and analysed the extension process, with the help of certain support functions, will be interconnected with the program unit that administers the device/function that is represented by the dialled number.

Example with an extension that has dialled an external number:

With divided call control each program unit needs only be expert for its own devices and a limited number of statuses that are applicable for these tasks. Each process needs only keep track of its half of a call, that is its own hardware and connected party. All exchange of information between the two call halves takes place via a standardised message interface, irrespective of whether an extension has dialled an external number, connected itself to a facility or dialled an internal number (calls another extension).

It is possible to have several calls going on at the same time from one telephone. For example one or more parked external calls, an inquiry call and one or more incoming calls (camped on). In this case a new, temporary process is created for each of these new calls.

Example with an extension that has a parked external call and an internal inquiry call:

Each process attends to its own tasks, that is deals with incoming messages from its own device and from the other call half on the basis of the status possessed by the process.

On disconnection the other call half is informed, the connection between the two halves is removed, and each half clears down.

Example, when involved parties have disconnected:

Divided call control is also applied when several parties are included in a call, e.g. conference. The process for each participant is aware only of itself (own device) and is connected to one other process.

The actual conference process is of another kind and can keep track of several connected parties plus its own hardware (MPU), in the central switch).

Example with a three-party conference:

### Administration of data

Certain data must not be lost in conjunction with system restarts and loss of power. This applies for example to all programmable data, extensions' absence information and fault logs.

This data, i.e. semipermanent data, is stored in E2-memory (E2PROM) and in battery backed-up memory on CPU-D_. Back-up copies of the programmable data can also be made using an external computer (PC) for operation & maintenance of the system (RASC).

In the battery backed-up memory, it is mainly metering information (costs and number of pulses), data for the realtime clock and certain restart information that is stored.

In the E2-memory all other semipermanent data (directory numbers, categories, transmission data, etc.) is stored.

Locations of the various data bases:

For new installation (cold start) of a PBX, default values are assigned automatically for all programmable data on the basis of the PBX's actual configuration. This data can later be altered via programming. Certain data can be altered from a system telephone with display, but to be capable of making complete alterations an external computer with operation & maintenance program (RASC) for the PBX is necessary.

In the RASC-computer it is also possible to maintain a separate set of all programmable data for the PBX. In this database alterations can be made locally (off line) for transfer to the PBX's database later on.

With RASC it is also possible to make backup copies of the PBX's data and to reload this data when required.

As a general principle the programmable data is administered whereby the program units in the PBX fetch copies from the database when traffic is started at an individual extension. This means that one can alter parameters for an individual device during ongoing traffic without disturbing the call. New programmable data is not put to use before all calls for a certain device have been ended. This is in order to avoid conflicts that will otherwise arise when data is altered during a call.

The programmable data that affects the regional program units (line signalling characteristics, transmission data, etc.) is sent from the central data base with the help of the relevant central program unit on system start and when data has been altered. The same principle, that is the parameters are not utilised until the respective device has been disconnected, also applies for the regional units.

The validity of the values of the programmable parameters can be verified in most cases during programming by the data operator. Certain regionally employed data, however, would constitute an exception. This regional data, which has been programmed locally in RASC, is transferred to the PBX's data base. If the data does not agree with the characteristics of the installed devices, the latter will generate some kind of alarm when the central program units send the data to the regional units. The central database will be updated in accordance with the database in RASC, but the regional units that cannot accept the data will utilise previously received data or the existing default data (if any).

The PSTN of the local markets have certain requirements to transmission, cadence and time out etc. settings. Sessions for several markets are available and can be loaded for easy updating of these parameters.

Revision: K © Ericsson Enterprise 2003