Ericsson AXE 810 Service Manual

Introduction

In the next few years, networks will evolve
toward today’s vision of an “all-IP” network.
We can see two possible scenarios: one for
traditional networks, and one for “next­generation” networks. For traditional net­works, the scenario describes what will hap­pen in multiservice networks and in second-

generation mobile networks, such as GSM.
The next-generation network scenario de­scribes the development of mobile Internet
and fast Internet access in fixed networks.

In traditional networks, evolution is dri­ven by never-ending growth in the need for
processing capacity; in mobile networks, by
growth in the number of subscribers and
usage levels per subscriber. The wireline
network is also experiencing a sharp increase
in traffic because of Internet “surfing.”

In next-generation networks, traditional
telephone and data networks will converge
to become general networks designed for
many different services and modes of access.
The convergence of data and telecommuni­cations makes it possible to combine the best
of two worlds. Some requirements, such as
the need for heightened performance, are
fulfilled more easily when development is
based on data communications products.
Also, the variety of access modes—via
second- and third-generation mobile net­works, the multiservice networks, and
broadband—will necessitate the coexis­tence of different transmission formats.
Thus, gateways will be required at network
interconnection points.

1

10

Ericsson Review No. 1, 2001

Thanks primarily to an architecture that was developed to support
change, the AXE exchange continues to evolve. Its architecture and mod­ularity have benefited customers—AXE has served as local exchanges
and international exchanges, and even in mobile networks to provide
mobile switching centers (MSC), home location registers (HLR), and other
functions. This has resulted in a total number of about 13,000 exchanges
and an all-time-high growth rate.

The modularity of AXE makes it possible to add new functionality in a
cost-effective way, but hardware and software R&D must also make the
most of new technologies.

This article describes recent adaptations of hardware and software that
will prepare AXE for the next generation of networks. The authors focus
on a system architecture that will serve as the basis for migration toward
a server-gateway architecture for third-generation mobile networks and
the next generation of multiservice networks. Adaptations will also enable
improvements in existing networks where traffic is growing quickly.

AAL ATM adaptation layer
ACS Adjunct computer subsystem
ALI ATM link interface
AM Application module
AP Adjunct processor
APC AM protocol carrier
APIO AXE central processor IO
APSI Application program service

interface

ASIC Application-specific integrated

circuit
ATM Asynchronous transfer mode
BICC Bearer-independent call control
BIST Built-in self-test
BSC Base station controller
C7 CCITT (now ITU-T) no. 7, a com-

mon-channel signaling system
CAS Channel-associated signaling
CP Central processor
cPCI Compact peripheral component

interconnect
CPP Cello packet platform
DL Digital link
DLEB Digital link multiplexer board in the

GEM
DSA Dynamic size alteration
DTI Data tranmission interworking
ECP Echo canceller in pool
ET Exchange terminal
ETSI European Telecommunications

Standards Institute
FTP File transfer protocol

GCP Gateway control protocol
GDDM Generic datacom device magazine

(subrack)
GDM Generic device magazine (subrack)
GEM Generic Ericsson magazine (subrack)
GS Group switch
GSM Global system for mobile

communication
GSS Group switch subsystem
HDLC High-level data-link control
HSB Hot standby
IO Input-output
IOG Input-output group
IP Internet protocol
IPN Interplatform network
ISDN Integrated services digital network
ISP Internet service provider
IWU Interworking unit
MGW Media gateway
MIPS Million instructions per second
MSC Mobile switching center
MSCS Microsoft cluster server
MSP Multiplex section protection
MTP Message transfer part
MUP Multiple position (timeslot)
NGS Next-generation switch
OSS Operations support system
PCM Pulse code modulation
PDH Plesiochronous digital hierarchy
PLMN Public land mobile network
PSTN Public switched telephone network
PVC Permanent virtual circuit

RAID Redundant array of independent

disks
RAM Random access memory
RISC Reduced instruction set computer
RLSES Resource layer service specification
RM Resource module
RMP Resource module platform
RP Regional processor
RPC Remote procedure call
RPP Regional processor with PCI interface
SCB-RP Support and connection board - RP
SDH Synchronous digital hierarchy
SES Service specification
SONET Synchronous optical network
SS7 Signaling system no. 7
STM Synchronous transfer mode
STOC Signaling terminal open communi-

cation
TCP Transmission control protocol
TDMA Time-division multiple access
TRA Transcoder
TRC Transceiver controller
TSP The server platform
TU 11, 12 Typical urban 11 (12) km/hr
UMTS Universal mobile telecommunica-

tions system
VCI Virtual channel identifier
VPI Virtual path identifier
XDB Switch distributed board
XSS Existing source system
WCDMA Wideband code-division multiple

access

BOX A, TERMS AND ABBREVIATIONS

AXE 810—The evolution continues

Magnus Enderin, David LeCorney, Mikael Lindberg and Tomas Lundqvist

Ericsson Review No. 1, 2001

11

Typical of next-generation network ar­chitecture is the separation of connectivity
and communication or control services. This
new new architecture will appear first in
GSM and WCDMA/UMTS core networks,
where AXE exchanges will continue to serve
as MSCs. For multiservice networks, tele­phony servers will become hybrid nodes
which consist of an AXE exchange that uses
an AXD 301 to handle packet-switched
data.

Based on the traditional and next­generation scenarios, network evolution
will demand increased processing capacity,
greater switching capacity, and conversion
to packet-switched technology. In addition,
new ways of doing business will emerge as
virtual operators pay for the right to use tele­com equipment owned by other operators.
Similarly, more operators are expected to
enter the market, putting additional de­mands on charging and accounting func­tions.

To succeed in today’s telecommunica­tions market, operators must be able to pro­vide their users with new functionality in
networks and complete coverage by mobile
systems at the same or a lower cost as time
progresses. Operators put demands on the
return on investment, cost of ownership,
footprint (multiple nodes per site), plug­and-play functionality (short lead times in
the field), and quality of software packages
(quality of service).

This article describes the latest develop­ments made in the AXE platform to meet
these requirements, and what new products
will be launched. For example, to shorten
the software development cycle, a layered ar­chitecture was introduced in the early
1990s, resulting in application modules
(AM). Current work on application modules
focuses on the server-gateway split. AXE
hardware is also undergoing a major archi­tectural transformation to further reduce the
footprint, power consumption, and number
of board types.

Ericsson’s goal is to cut the time to cus­tomer for AXE by targeting improvements
in production, transportation, and installa­tion. Far-reaching rationalization has been
achieved through the introduction of the
generic Ericsson magazine (GEM), an open,
flexible, scalable, high-capacity magazine
(subrack). A new distributed, non-blocking
group switch (GS890) has also been intro­duced, as have new devices, such as the ATM
link interface (ALI) and ET155-1, which en­able AXE to serve as a gateway to an ATM

network. Also, a new input-output (IO) sys­tem, called the APG40, has been developed
using products from mainstream data com­munications vendors.

The application platform

The traffic-handling part of AXE has a two­layer architecture: the application platform,
which consists of hardware and software; and
the traffic applications, which solely consist
of software. The application platform can be
seen in terms of hardware and software,
which present different but complementary
views of the architecture.

The software view

The AXE application software has contin­ued to evolve since it was first layered and
modularized in the early 1990s. Market de­mand for shorter lead-times was the main
force driving the change to layers and mod­ularization.

Application modules

Traffic applications are encapsulated in ap­plication modules that use the application­platform software—called the resource
module platform (RMP). There is no direct
communication between application mod­ules. All communication between them
takes place via protocols, where the proto­col carriers are implemented in the resource
module platform (Figure 1).

APZ

XSS

AM

CONŁRMCOMŁRMOMŁ

RM

APSI

NAP

RM

RMP

Other

RMs

AM AM AM

CHA

RM

C7

RM

Figure 1
AXE 810 application software architecture.

The interface of the resource module plat­form with the application modules, called
the application platform service interface
(APSI), is a formalized client-server inter­face. Subsets of the APSI, or individual in­terfaces, are called service specifications
(SES). Each service specification provides a
service for the application modules, some of
the most important services being:

• connection service—for setting up a phys-

ical connection;

• communication service—for communi-

cation between application modules;

• object manager—for operation and main-

tenance;

• AM protocol carrier (APC);

• charging service; and

• services for signaling no. 7 (SS7), such as

the message transfer part service.
The total concept, which consists of the

RMP, APSI, the AMs, and the inter-AM
protocols, is known as the application mod­ularity concept. It is largely thanks to this
concept that the system lifetime of AXE
consistently exceeds expectations—the
AXE system is 30 years old, yet we see no
end to its potential evolution.

Resource modules

When the RMP was first introduced, it was
small in comparison to the large volume of
existing software, called existing source sys­tem (XSS). Following several RMP devel­opment projects, the migration from the
earlier architecture to the AM architecture
is now virtually complete. The resource
module platform, in turn, has become large
and complex, leading to a refinement of the
AM concept and the division of the RMP
into several resource modules (RM). The in­terfaces provided by the resource modules
are formalized as resource-layer service spec­ifications (RLSES).

A priority in the development of RMs and
AMs (known collectively as system mod­ules) is to specify the interfaces (SES and
RLSES) early in the development process.
When the interfaces are “frozen”, the sepa­rate system modules can be designed inde­pendently of one another, often at different
geographical locations, as is common in the
Ericsson organization.

The second major advantage for develop­ment of applications is that application­platform hardware is now associated with
specific resource modules and controlled by
them. Application modules simply request
services via the APSI. Hardware is “owned”
by the software in the respective resource
modules.

Hardware

The hardware (Figure 2) revolves around
the GS890 group switch, which has 512 K
multiple positions, each with a bit rate of
64 kbit/s.

The biggest change in the hardware ar­chitecture is the addition of a new exchange
interface (the DL34) to existing DL3 and
DL2 interfaces. The DL34 interface sup­ports from 128 to 2,688 timeslots to each
device board, in steps of 128, via a backplane
interface in the generic Ericsson magazine
running at 222 Mbit/s. This interface made
it possible to improve the devices connect­ed to the group switch, further reducing
input power, cabling, the number of board
types, footprints, installation time, and
other parameters. The high-speed DL34 in-

12

Ericsson Review No. 1, 2001

SCB-RP

ET155

ET155

XDB DLEB

DLHB

TRA

ECP

CGB

CGB

SCB-RP

RPHS

CP

HD

RPHS

APG

RP4

IRB

IRB

LRB

ETC5

ETC-T1

ETC-J32

RPP

RPG3

PDSPL2

J7X21-2

DL2IO

DL2 (cable)

VGA display

External alarm

Remote Ethernet (TCP/IP)

RPB-S

RPB-SEthernet

RPB-S
Ethernet (IPN)
Ethernet (IPN)

Local Ethernet (TCP/IP)

Keyboard

Alarm panel

External
sync

ETC
sync

SONET

Ethernet

RPB-S

GEM GDM

EMBUS

RPB-S

DL34

DL34

DL3

DL2

SDH

SDH

PDH

PDH

PDH

ALI

M-AST

S7V35

S7DS0A

Figure 2
Hardware architectural overview.

• Connection RM (CONRM)

• Communication RM (COMRM)

• Operation and maintenance RM (OMRM)

• Network access products RM (NAPRM)

• Pooled devices RM (PDRM)

• Common channel signaling RM (C7RM)

• Charging support RM (CHARM)

BOX B, CURRENT RESOURCE
MODULES

Ericsson Review No. 1, 2001

13

terface has also facilitated a more efficient
version of the group switch itself, also lo­cated in the GEM.

Another architectural change (Figure 2)
is the interplatform network (IPN). In the
first phase, the IPN will be used to speed up
communication between the central proces­sor (CP) and adjunct processors (AP). The
interface is based on fast Ethernet. In a sec­ond phase, it will be upgraded to Gigabit
speed.

All devices that support the DL34 inter­face can be mixed in the GEM more or less
without limit. The maximum capacity of
each GEM is 16 K multiple-position time­slots (MUP), which corresponds to eight
STM-1 ET boards, for example. Physically,
there is space for 22 device boards in one
GEM.

If a switch is needed that is larger than
16 K MUPs, or when the number of devices
exceeds 22, additional GEMs must be
added. These can be configured without in­terruption while the system is processing
traffic. An exchange based on the GEM is
linearly expandable. The maximum switch
size is 512 K MUPs at normal rate (64
kbit/s) or 128 K MUPs at a subordinate rate
(n x 8 kbit/s).

By inserting a pair of digital link multi­plexer boards (DLEB) in the GEM, we can
convert the DL34 backplane interface into
four DL3 cable interfaces. This allows all of
today’s devices in the generic device maga­zine (GDM), generic datacom device mag­azine (GDDM), and other formats to be used
with the new switch core.

Software evolution

The original AXE concept has enabled on­going evolution and modernization. Legacy
software can be reused or modified, sub­systems and system modules can be mod­ernized or completely replaced, interfaces
can be left unchanged or redesigned to meet
new needs, and new architectures can be in­troduced. Yet AXE remains fundamentally
AXE.

Several software development programs
are under way in parallel. The APZ proces­sor is being adapted to serve as a multi­processor CP to multiply call-handling ca­pacity. Cost of ownership is being reduced.
Ericsson is improving its internal manage­ment of software to reduce time-to-market
and time-to-customer. These activities are
in addition to the four programs described
below.

Software migration

The network architecture is changing. In
particular, we see two new types of node: the
server (or media-gateway controller) and the
media gateway itself, resulting in what is
known as the “server-gateway split.” In
order to meet the demands of the new ar­chitecture, the software in the application
platform is being migrated from a tradi­tional telecom environment—which is
STM-based, mainly for voice traffic—to-

XSS

AM

RMP Server module

STM AAL2/AAL5

SS7SS7
GCP

GCP

SS7 STM

1999 2001 2001/2002

STM AAL2/AAL5

Gateway module

Server module

Media gateway

AM AM AM AM AM

Figure 3
Software evolution toward the server-gateway split.

ET

TRA

or DTI

TRA

or DTI

ALI

ATM/AAL2

network

STM network

GSS

AXE media gateway

Switched 64 kbit/s connections for PCM coded voice
Switched 64 kbit/s connections for HDLC framed voice or data packets

Figure 4
System architecture, ATM interworking function.

ward a packet-based environment, initially
for ATM, and subsequently for IP.

In this new architecture, the server con­trols the call or session, whereas the media
gateway provides the bearer service, trans­mitting information over the connectivity
layer. An advantage of separating call con­trol from bearer control is that bearer tech­nology can be upgraded from STM via ATM
to IP without affecting the call control.

The original AM architecture has proved
itself to be future-proof and is well suited to
accommodate the server-gateway split. The
split has been implemented in system mod­ules (new and modified AMs and RMs)
without any fundamental changes to the
software architecture. For example, new
RMs for bearer-access service and for TDM
access are currently being developed for the
WCDMA/UMTS program.

Two separate migration tracks are
currently being followed. For the
WCDMA/UMTS program, AXE is the nat­ural choice of technology for the server,
thanks to its high capacity and high level of
functionality. AXE is also available as a com­bined server/media-gateway node, where the
server part controls its own gateway part. By
contrast, the Cello packet platform (CPP) is
the preferred choice of technology for ATM­based media gateways. In such a network,
the server nodes communicate using bearer­independent call control (BICC). The server
controls the gateway using the gateway con­trol protocol (GCP). ATM-based gateways
communicate using Q.AAL2.

The second migration track is for the next­generation switch (NGS) program for the
multiservice network. The server node is a
hybrid node made up of co-located AXE and
AXD 301 systems. The gateway node con­sists of an ATM switch (also an
AXD 301) for AAL1 connections, and is
controlled by the server using the gateway
control protocol.

In-service performance

Robustness, or in-service performance, has
long been a priority in AXE development,
and considerable improvements have been
and are still being made. No software is
100% reliable, but robust systems can be
achieved by means of recovery mechanisms
that minimize the effects of software mal­functions or program exceptions.

One of the most powerful robustness
mechanisms is known as forlopp, which is a
recovery mechanism at the transaction level.
(Forlopp is an anglicization of the Swedish

word förlopp, roughly the “sequence of
events.”) The forlopp mechanism is a low­level recovery mechanism by which only the
transaction affected by the software mal­function is released. This minimizes the dis­turbance to the overall system. The forlopp
mechanism, which has been refined in sev­eral stages and is now applied to all traffic
handling in AXE and to many operation and
maintenance functions, has significantly re­duced the number of recoveries at the sys­tem level.

System restart is used as a recovery mech­anism for certain faults and for system up­grades. The restart mechanism itself has
been optimized in several ways, so that in
the few cases that still require restart, its du­ration is as short as possible.

Activities for restarting software in the re­gional processor (RP) have been especially
improved. For example, regional processors
are restarted through minimal restart by de­fault—that is, with the suppression of un­necessary actions. Complete restarts are per­formed on regional processors only when
necessary. Regional processors are restarted
asynchronously, which means that no re­gional processor has to wait for any other re­gional processor to become ready for a restart
phase. These improvements have signifi­cantly reduced the time consumed when
restarting application hardware.

If necessary, AXE can, via the IPN, be re­loaded from the backup copy of the system
on the APG40 file system. This approach is
ten times faster than the design that applied
before the APG40 and IPN were intro­duced. Also, the time it takes to make a
backup copy of the system on APG40 is one­fifth of what it was before.

The restart duration for a system that is
upgrading to new software has also been re­duced. The most recent improvements in­volve RP software, which is now preloaded
prior to an upgrade, instead of during the
upgrade, thus saving restart time.

Major improvements have been made to
the function-change mechanism used for
system upgrades. Inside the central proces­sor, the time needed for data transfer prior
to a changeover to new software has been cut
from hours to typically ten minutes. (The
data transfer does not disturb traffic han­dling, but exchange data cannot be changed
during data transfer.)

Another improvement applies to the
retrofit of new CPs that replace old ones. The
bandwidth of the connection between the
processors has been expanded by using re-

14

Ericsson Review No. 1, 2001

1999

System downtime

Complete exchange failure
Software upgrade
Restart with reload
Large restart
Small restart

2000 2001 2002

Figure 5
Reduction in system downtime.