The Lucent Technologies Softswitch-Realizing the promise ... · ♦ The Lucent Technologies...

174 Bell Labs Technical Journal ◆ April–June 1999

Introduction and BackgroundThe demand for communications services contin-

ues to explode and grow at an unprecedented rate. It

is widely accepted that in just the next 15 to 20 years

we will see the level of growth in communications

that was seen in the entire last 100 years. Today voice

and data networks coexist, with approximately equal

amounts of traffic; however, data traffic rates are

growing 10 to 15 times faster than voice, driven by an

explosion in the use of the Internet. In 1999, one-

third of all homes in the United States will be on line.

The International Data Corporation predicts that the

level of electronic commerce will increase to $400 bil-

lion in the year 2000, up from $12.5 billion in 1997.

Add to these indicators the fact that less than one out

of four people in the world have ever made a phone

call and also that all the countries of the globe are rac-

ing to develop the communications infrastructures

that fuel their economies as they prepare to meet the

next millennium.

Global deregulation, privatization, and drastic

restructuring of the communications services industry

are fueling this demand further. The U.S. Telecom-

munications Act of 1996 led a worldwide sea change

in telecom deregulation. As a consequence of the act,

there was an explosion in the emergence of new com-

petitive service providers launching new communica-

tion service enterprises, based either on reselling

unbundled elements of the incumbent carriers’ infra-

structures or on building facilities of their own. While

the earlier competitive carriers focused on the resale

model, the current landscape is dominated by the

acquisition and construction of competitive network

♦ The Lucent Technologies Softswitch—Realizing the Promise of ConvergenceRamnath A. Lakshmi-Ratan

The Lucent Technologies Softswitch was created as a result of Project Saras, whichwas initiated by two Bell Labs researchers. The purpose of Project Saras was todevelop a software system that solves several major problems that providers of tele-phony services now face. Today’s public switched communications infrastructure con-sists of a variety of different networks, technologies and systems, most of which arestill based on the wireline circuit-switched structure. The technology, however, isevolving to packet-based networks, and service providers need the ability to inter-connect their customers with these flexible and cost-effective networks without losing the reliability, convenience, and functionality of the public switched tele-phone network. The Lucent Softswitch, formerly known as the PacketStar†IP Services Platform, resulted from a focus on these needs. This Softswitch was initially marketed as a signaling-interoperability and services-creation platformunder the umbrella brand name PacketStar for Lucent data networking products. Itwas renamed in light of the recognition that it represented an emerging concept inthe industry called a “softswitch,” referring to a software-based distributed switching-and-control platform. This paper provides a high-level description of the LucentSoftswitch and its application to building next-generation converged networks.

Bright House Networks - Ex. 1048,

Bell Labs Technical Journal ◆ April–June 1999 175

facilities, driven by a huge influx of investment capital.

The post–U.S. Telecom Act landscape of the com-

munications service-provider marketplace is going

through significant restructuring. Technology

advances in software, transport, and interconnection

are rapidly making it feasible for service providers to

bundle and create so-called converged service offer-

ings. These are little more than the packaging of dis-

parate services such as local, cellular, and long distance

telephony with paging and Internet-access services

into one billing and customer-service bundle.

Alternatively, some carriers are attempting to build

Panel 1. Abbreviations, Acronyms, and Terms

AAL—ATM adaptation layerAIN—advanced intelligent networkA-link—physical termination for SS7

interconnectivityAPI—application programming interfaceATM—asynchronous transfer modeCAS—channel-associated signalingCCS—common channel signalingCLEC—competitive local exchange carrierDS0—Digital signal level 0; transmission rate of

64 kb/s (1 channel) in time division multiplexhierarchy

DS1—Digital signal level 1; transmission rate of1.544 Mb/s (24 64-kb/s channels) in TDM hierarchy

DS3—Digital signal level 3; transmission rate of44.736 Mb/s (672 64-kb/s channels) in TDMhierarchy

DSL—digital subscriber linee&m—“ear” and “mouth” leads from customer

to central officeIMT—intermachine trunkIN—intelligent networkINAP—intelligent network application protocolIP—Internet protocolIPDC—Internet protocol device controlISDN—integrated services digital networkISP—Internet service providerISUP—ISDN user partISV—independent software vendorITU-T—International Telecommunication

Union—Telecommunication StandardizationSector

JVM—Java* virtual machine (Sun Microsystems)LCDS—Lucent Communication Directory ServerLDAP—lightweight directory access protocolMantra—Lucent proprietary canonical multi-

party call modelMGCP—media gateway control protocolMTP—message transfer part

OA&M—operations, administration, and maintenance

OC-3—optical carrier digital signal rate of155 Mb/s in a SONET system

PBX—private branch exchangePDL—policy description languagePEP—policy enforcement pointPIP—packet intelligent peripheralPOTS—“plain old telephone service”PRI—primary rate interface (ISDN)PSTN—public switched telephone networkRADIUS—remote authentication dial-in user

serviceRAS—remote access server/serviceRDBMS—relational database management systemRTP—real-time transport protocolSapphire—Lucent gateway control protocolSCCP—signaling section and control partSCP—service control pointSDK—software development kitSIP—session-initiation protocolSNMP—simple network-management protocolSPS—service provider servletSS7—Signaling System 7SSP—service switching pointSTP—signal transfer pointT1—terrestrial facility (North America) to

transport primary rate of 1.544 Mb/s (24 64-kb/s channels)

TCAP—transaction capabilities applications part(SS7 protocol)

TCP—transmission control protocolTDM—time division multiplexedUDP—user datagram protocolUFA—user feature appletUNI—user network interfaceVTOA—voice and telephony over ATMVoIP—voice over IPVPN—virtual private network



truly converged infrastructures that provide voice,

data, and multimedia services over the same network

using packet-based technologies in backbone net-

works. This convergence of network infrastructure

technologies is being accompanied by a divergence of

business models, with specialized carriers emerging in

many different niches (Figure 1). On the one hand,

some of the major carriers are still building fully verti-

cally integrated service businesses. On the other hand,

there is an emergence of three new types of business

models: (1) the infrastructure provider model, which

leverages of rights of way and investment capital for

construction; (2) the service applications provider

model, which leverages speed in creating new service

applications, together with the modern data-based

infrastructures to deliver them; and (3) the service

retailer and marketer model, which leverages brand

image, marketing, and customer franchises.

The Lucent Technologies Softswitch is particularly

useful to the business model involving infrastructure

providers. The next section of this paper “The

Evolution of Public Communications Networks,” char-

acterizes the public switched telecommunications

infrastructure, its movement toward packet-based

technology, and the challenges network service

providers face as it moves in that direction. The following

section, “Lucent Technologies Softswitch Technology,”

presents Lucent’s Softswitch as an approach to meet-

ing these challenges. That section discusses the tech-

nology design philosophy, the network architectures,

and the systems architectures of the Lucent Softswitch.

The Evolution of Public Communications NetworksToday’s public switched telecommunications

infrastructure consists of a variety of different net-

works, technologies, and systems. Most of this is still

the wireline circuit-switched infrastructure, repre-

sented in Figure 2. Analog local loops, usually after

being aggregated by a subscriber loop carrier, are con-

nected to a local (Class 5) switch where the connec-

tion carries both media and control signaling for all of

the aggregated loops. The local switch is connected

through two separate networks to other toll/tandem

and local switches. One network of intermachine

trunks (IMTs) carries the media in the form of 64-kb/s

time division multiplexed (TDM) streams. All of the

associated control information is carried on a separate

Wir

elin

e

Wir

eles

s

Dat

a

Cab

le

Business layer

Service layer

Network layer

Element layer

Regulated monopolies andoligopolies (circa 1996)

Packet data

Wir

elin

e

Wir

eles

s

Cab

le

Convergence of technologies

Network accessand bandwidth

Applicationscreation, delivery

Service bundlingand retail

Divergence of business models

Integrated service providers

BusinessService

NetworkElements

Right-of-way, capacity,reliability, capital

Applications talent,software/servers, speed

Branding, bundling,marketing, sales

CompetitionDepreciationLabor unionsRegulation

Business models Business drivers

Figure 1.Telecommunications industry structure evolution.



packet-based signaling-and-control network (typically

using ITU-T Signaling System 7 [SS7]1,2 or Common

Channel Signaling System 7 [CCS7]).

The SS7 network basically consists of three kinds

of signaling points—service switching points (SSPs),

signal transfer points (STPs), and service control points

(SCPs). Each signaling point is identified by a unique

numeric point code, analogous to an Internet protocol

(IP) address in an IP network.

SSPs are switches that originate, terminate, or tan-

dem calls. STPs are packet switches that interconnect

and route traffic in the SS7 network. An STP’s role is

similar to that of an IP router but it has significant dif-

ferences. SCPs are centralized database servers for such

functions as 800-number translation and personalized

information.

PRI trunks refer usually to DS1 lines or, more pop-

ularly, T1 lines that have one channel reserved for pri-

mary rate interface (PRI) signaling. Prominent variants

include fractional T1s and non-facility associated

signaling trunks. Channel-associated signaling trunks, or

CAS trunks, refer to in-band signaling variants that can

run on DS1 or T1 trunks.

Much of the logic needed for establishment of

connections and routes for the media through the net-

work are resident in the switches. Additional logic and

POTSphone

SCP

Localswitch IMTs

(TDM-G.711)

SS7 network

(ISUP/MTP)

SCP

Toll/tandemswitch

EnterprisePBX

POTSphone

PBX featurephone

Toll/tandemswitch

Toll/tandemswitch

SCP

Network

IMTs(TDM-G.711)

SS7 network

(ISUP/MTP)

POTSphone

SCP

Localswitch

ISDN PRI/CAS(TDM-G.711)

CAS – Channel-associated signalingG.711 – ITU-T Recommendation G.711IMT – Intermachine trunkISDN – Integrated services digital networkISUP – ISDN User PartITU-T – International Telecommunication Union— Telecommunication Standardization Sector

MTP – Message transfer partPBX – Private branch exchangePOTS – “Plain old telephone service”PRI – Primary rate interfaceSCP – Service control pointSS7 – Signaling System 7TDM – Time division multiplexed

Customer premises

Figure 2.Today’s public switched telephone network (PSTN).



information for enhanced services (such as

800/900/700 national/personal number services) are

drawn from SCPs, which are connected through the

SS7 network to the switches. In some cases other

adjuncts called intelligent peripherals provide media

resources such as dual-tone multiple-frequency digit

recognition, spoken announcements, speech recogni-

tion, and synthesized (text-to-speech) announcements

as part of these enhanced services. In general, a circuit

intelligent peripheral refers to an external media-

processing engine capable of terminating TDM audio

streams and performing some processing on those

streams.

Next-Generation NetworksThe direction that the industry is taking in con-

ceiving and building next-generation networks and in

evolving the current public switched telephone net-

work (PSTN) is largely premised on replacing much of

the TDM-based circuit-switched infrastructure with an

Internet-protocol (IP)–based or asynchronous-

transfer-mode (ATM)–based packet-switched infra-

structure. Figure 3 describes the replacement of the

toll/tandem or long distance part of the PSTN with a

packet backbone. The packet backbone is essentially

thought of as carrying the media traffic. The signaling-

and-control traffic can be carried, as before, on a sepa-

rate packet-based network, or else can be carried in

secure and protected bandwidth flows within the

packet backbone network.

Drivers of Packet-Based TechnologyAs carriers attempt to marshal investment capital

to fund network construction, their business cases are

strongly influenced by the time value of investments,

which in turn are driven by the rate of innovation and

economic learning effects in the core technologies cho-

sen for the networks. These learning-curve effects are

best characterized by the length of the period observed

in which the performance/price ratio doubles

(Table I). The period for commercial computing is the

shortest at about 18 months. It is driven by the learn-

ing curve for semiconductors (often referred to as

Moore’s Law, named after Intel co-founder Gordon

Moore). The performance-doubling period for TDM

circuit-switching technology is the longest of those

shown, at about 60 to 80 months. Packet-based IP and

ATM technologies have displayed intervals of 20 and

40 months, respectively.

In addition to their more rapid rate of develop-

ment, it is estimated that the simpler topologies of

packet-based networks would lead to significant

reduction in operations and administration costs. It is

no wonder that there is an increasing focus on IP and

ATM technologies by network operators. However,

severe challenges face operators building out new net-

works or extending/replacing existing circuit-switched

networks with packet-based infrastructures.

Challenges of Network Service ProvidersCarriers looking to create new service businesses

or to evolve existing ones face the immediate problem

that they must, at a minimum, provide services over

their new/evolved networks with the same composi-

tion, convenience, and quality as the PSTN services to

which the markets are accustomed. This implies that

they must build new IP-based or ATM-based packet

networks that interconnect with the existing wired or

wireless PSTN, as well as other networks such as cable

networks, in order to provide ubiquitous interconnec-

tivity and seamless services.

To begin with, there are many different protocols

used in the packet-circuit gateways that interconnect

circuit and packet networks and in the devices and

client appliances used on those networks. These

include, for example, H.323 and its subsidiary protocols

(an ITU-T packet-telephony protocol suite),3-9 Internet-

protocol device control (IPDC), session-initiation proto-

col (SIP),10 Microsoft’s NetMeeting*, and media-

gateway–control protocol (MGCP).11 Even if the protocol

choices were made, there are many vendors of the gate-

ways and devices, and one vendor’s implementation of

a protocol is not guaranteed to interwork with

another’s. Any implementation must, of course, trans-

parently handle both PSTN and IP clients and must

Table I. Technology innovation periods.

Networking technology Performance/price ratioplatforms doubling period

Commercial computing 18 months

IP technology 20 months

ATM technology 40 months

TDM-circuit switching 60–80 months



utilize multiple existing directories and databases, such

as the SCP and relational database management system

(RDBMS) in the PSTN, and lightweight-directory-access

protocol (LDAP), remote-access service (RAS), and

remote-authentication dial-in user service (RADIUS) in

the packet world.

Service providers must recoup their investments

in legacy networks by reusing existing services, such as

intelligent network (IN) services, while being able to

innovate and offer new Internet services. While doing

all this, they have to systematically grow their business

by being able to manage and scale these converged

networks. Additionally, there is the problem of

adapting/integrating new services. With the telephony

marketplace becoming more competitive, next-

generation networks must provide the ability to inte-

grate new services from any source—local or remote—

to meet the market demands of the ever changing

workplace. These networks must also provide a method

of differentiating one service provider from another.

Project SarasTo solve these challenges, Lucent Technologies

has developed the Lucent Softswitch in an effort called

Project Saras.12 The basic approach is premised on the

unbundling of the core functionality of a conventional

circuit switch and the distribution of this functionality

EnterprisePBX

POTSphone

PBX featurephone/POTS

phone

VolP/VTOA(RTP/UDP/IP orAAL1/AAL2)

POTSphone

SCP

Localswitch IMTs

(TDM-G.711)

SS7 network

(ISUP/MTP)

SCP

EnterprisePBX

POTSphone

PBX featurephone

NetworkCustomer premises

IMTs(TDM-G.711)

SS7 network

(ISUP/MTP)

POTSphone

SCP

Localswitch

ISDN PRI/CAS(TDM-G.711)

AAL – ATM adaptation layerATM – Asynchronous transfer modeCAS – Channel-associated signalingG.711 – ITU-T Recommendation G.711IMT – Intermachine trunkIP – Internet protocolISDN – Integrated services digital networkISUP – ISDN User PartITU-T – International Telecommunication Union— Telecommunication Standardization SectorLD – Long distance

MTP – Message transfer partPBX – Private branch exchangePOTS – “Plain old telephone service”PRI – Primary rate interfaceRTP – Real time transport protocolSCP – Service control pointSS7 – Signaling System 7TDM – Time division multiplexedUDP – User datagram protocolVoIP – Voice over IPVTOA – Voice and telephony over ATM

VolP/VTOA-based LD packet backbone network

Figure 3.Next-generation packet-based long distance networks.



across the backbone of a packet network in the form

of software components that run on commercial stan-

dard computers. This unbundled and distributed archi-

tecture must be open and programmable, both for the

service provider and for any third-party feature devel-

oper, to create and provide new services. All this has

to be capable of providing the scalability and reliability

that the market demands.

Lucent Technologies Softswitch TechnologyFigure 4 describes how the functionality of the

circuit switch, represented by the model on the left,

is unbundled and distributed across the packet back-

bone using the Lucent Softswitch model on the right.

The media interfaces in the circuit switch (line/trunk

cards) are replaced by media gateways that convert

TDM flows to IP or ATM packet flows. The time slot

interchange, or switch matrix, is replaced by the high

performance packet backbone itself. The switch con-

troller that switches timeslots across the switch

matrix is replaced by the Lucent Softswitch, which

controls the switching and routing of media packets

between media gateways across the packet backbone.

In both cases, the switch controller implements

service logic—as in the case of intelligent network

application protocol (INAP) triggers in advanced

intelligent network (AIN) 0.1. In addition, other

services are brought into the communications flows it

controls—for example, through its interconnection

with the SS7 network in the case of PSTN IN services,

or through other databases, logic or feature servers,

and media servers.

Trunking devices or trunking gateways are devices

that terminate trunks associated with SS7 control

links. These TDM trunks carry media from an adjacent

switch in the traditional circuit-switched network. The

adjacent switch usually belongs to a different service

SCP

ATM – Asynchronous transfer modeIP – Internet protocolITU-T – International Telecommunication Union— Telecommunication Standardization Sector

SCP – Service control pointSS7 – Signaling System 7TDM – Time division multiplexed

Gateway controlprotocol

TDM

Access/trunkingmedia gateway

Controller

SS7network

Time slotinterchange

Linecard

TrunkcardTDM TDM

Traditional circuitswitch model Softswitch model

Managementsystem

Newservices

SS7network

Billingsystem

LucentTechnologiesSoftswitch

Gateway controlprotocol

TDMIP

ATM

IP/ATMbackbone

Access/trunkingmedia gateway

IP

ATM

Figure 4.Unbundling services and control from media transport.



provider. Depending on the agreement between the

service providers, these trunks are also called co-carrier

trunks or feature group D trunks.

Access devices or access gateways are devices that ter-

minate PSTN signaling and media. Traditional cus-

tomer premises equipment or a Class 5 switch would

be an appropriate example. More specifically a Lucent

Ascend MAX family member is an example where

DS1s or DS3s supporting in-band signaling variants or

PRI are terminated.

Trunking and access devices and gateways are gen-

erally referred to as media devices and media gateways.

Thus, the Lucent Softswitch begins by providing

the same functionality as a circuit switch, but it does so

in packet-based networks designed to be intercon-

nected with PSTNs. The distinguishing characteristics

of the Lucent Softswitch are:

• It is a programmable call-processing system

supporting a variety of PSTN, ATM, and IP

protocols.

• It runs on commercial computers and operat-

ing systems.

• It controls external trunking gateways, access

gateways, and remote access servers (RASs).

For example,

– A Lucent Softswitch plus a trunking gate-

way is a replacement for a toll/tandem

switch (Class 4 switch) with voice over IP

(VoIP) or voice and telephony over ATM

(VTOA) in the backbone;

– A Lucent Softswitch plus an access gateway

is a voice virtual-private-network (VPN)/

private-branch-exchange (PBX) tie-line

replacement with VoIP in the backbone;

– A Lucent Softswitch plus a RAS offers a

managed modem service using co-carrier

trunks (that is, modem calls signaled

through SS7 ISDN user part [ISUP]);

– A Lucent Softswitch plus a trunking gate-

way and a local feature server is a replace-

ment for a local switch (Class 5 switch) with

VoIP/VTOA in the backbone.

• It reuses IN services through an open and flexi-

ble directory interface. For example, it provides

a directory-enabled architecture with access to

RDBMS, LDAP, and transaction-capabilities

applications part (TCAP) directories.

• It provides open application programming

interfaces (APIs) for third-party developers to

create next-generation services.

• It has programmable back-office features, such as

– Programmable event-detail recording, and

– Call-detail events written to a service

provider’s event-collection mechanism.

• It has advanced policy-server–based manage-

ment of all software components, including

– Simple network management protocol

(SNMP) 2.0 interfaces exposed by all com-

ponents, and

– Policy description language and a system for

writing and enforcing custom policies.

Lucent Softswitch Technology Design PhilosophyThe essential design philosophy behind the Lucent

Softswitch is based on creating a scalable, distributed

software system that is independent of a specific

underlying hardware/operating system and is capable

of handling a variety of synchronous communication

protocols—putting the infrastructure in an ideal posi-

tion to track Moore’s curve. Such a distributed system

can be termed a programmable synchronous communica-

tion control network and should be capable of supporting

the following basic requirements:

• Protocol- and device-independent develop-

ment of call-processing and/or synchronous-

session-management applications;

• Safe execution of multiple third-party applica-

tions in the Lucent Softswitch network with-

out any adverse effects caused by malicious or

wrong behavior of applications;

• The capability for third-party hardware vendors

to add support to new devices and protocols;

• The ability for service providers and application

providers to add support for global system-

wide policies without compromising perfor-

mance and security;

• The capability for the evolving synchronous

communication control network to support

diverse back-office systems including billing,

network management, and other operation

support systems;



• Support of run-time binding or dynamic topol-

ogy of the synchronous communication con-

trol network that aids organic evolution;

• Scalability from very small networks to very

large networks (on the order of the current

PSTN and more); and

• Support for fault resilience from the ground up.

These requirements enable the next-generation

service provider to deploy a Lucent Softswitch-based

network as the backbone for synchronous communi-

cation control that allows rapid development and

deployment of advanced synchronous multimedia

applications.

Signaling and Communications Protocol AgnosticismA basic aspect of the Lucent Softswitch design phi-

losophy as mentioned above is the abstraction of sig-

naling and synchronous communications protocols

and their implementation details through a canonical

model that hides these details from the core call/ses-

sion processing and control. This canonical model

(internally referred to as Mantra) is a generalized

multi-party call/session model of zero or more parties.

Existing call models, such as the Q.93113 model,

become a special case of this model. The special case of

a zero-party call represents pure third-party call con-

trol. This allows for the development and evolution of

the system in a way that is agnostic to the emergence

and adoption of specific protocols or their varied

implementations by different vendors.

As in Figure 5, synchronous communication pro-

tocols can generally be classified into two basic types.

The first set deals with the representation, processing,

and transmission of media content such as audio and

ISUP – ISDN user partITU-T – International Telecommunication Union— Telecommunication Standardization SectorMGCP – Media gateway control protocolPOTS – “Plain old telephone service”Q.2931 – ITU-T Recommendation Q.2931Q.931– ITU-T Recommendation Q.931RTP – Real time transport protocolRTSP – Real time streaming protocolSIP – Session-initiation protocolT/R – Tip/ring

AAL – ATM adaptation layerATM – Asynchronous transfer modeBISUP – Broadband ISDN user partCAS – Channel-associated signalingGR-1129 – Generic Requirement 1129 (Telcordia)H.323 – ITU-T Recommendation H.323; packet telephony protocol suiteH.GCP – ITU-T proposal under study for gateway control protocolIPDC – Internet protocol device controlISDN – Integrated services digital network

Peer to peer

Master/slave

Streaming

Synchronouscommunications

protocols

Control andsignaling

Media

Interactive

RTP, H.323 media content sections or AAL-1/AAL-2, for example

RTSP, for exampleH.323, SIP, ISUP,BISUP, Q.931,

Q.2931, or CAS,for example

IPDC, MGCP,H.GCP, GR-1129,

or POTS T/R,for example

Figure 5.Synchronous communications protocols.



video. The second set deals with control and associated

signaling between parties, devices, and infrastructure

systems that exchange, process, or transmit this content.

The Lucent Softswitch supports various control

and signaling protocols including master/slave control

protocols as well as peer-to-peer protocols spanning

the entire gamut from circuit telephony to packet tele-

phony. Examples of the narrowband circuit-telephony

protocols currently supported by the Lucent Softswitch

include SS7 ISUP (including country variants), Q.931,

and various CAS variants (with equivalent mapping

done to Q.931 by a media gateway). Examples of

packet-telephony VoIP protocols that are supported

include H.323 v1/v2, SIP, IPDC, and MGCP.

Examples of packet-telephony VTOA protocols sup-

ported include IPDC, Sapphire (a Lucent ATM gate-

way control protocol), and user-network interface

(UNI) versions.

The Lucent Softswitch supports Layer 3 (call con-

trol signaling) for the various circuit and packet tele-

phony protocols. Layer 2 and Layer 1 aspects of the

signaling protocols are terminated by:

• Hardware elements running in the same gen-

eral purpose computer as the individual Lucent

Softswitch components; or

• Hardware elements external to the Lucent

Softswitch, such as external signaling gateways

and STPs with TCP/IP support.

In the latter case, Layer 3 signaling is tunneled by the

external hardware element using TCP/IP.

Lucent Softswitch-Based Network ArchitecturesThe Lucent Softswitch is designed as a distributed

software system that provides seamless interoperability

between networks based on diverse technologies, pro-

tocols, and devices. Figure 6 illustrates an instance of

a Lucent Softswitch-based network architecture for

VoIP whose functionality is similar to the current circuit-

switched inter-exchange–carrier/long-distance

network. In this figure, a Class 4 switch is replaced by

a Lucent Softswitch and a set of trunking gateways.

The Lucent Softswitch terminates ISUP signaling from

the STPs, either by directly terminating A-links

(shown as ISUP/MTP in the figure) or by accepting

ISUP signaling over TCP/IP. The trunks (which are

signaled through ISUP) from a local switch (or other

circuit switches) are terminated in the trunking gate-

way, which is capable of converting the G.71114

TDM signal into real-time-transport-protocol

(RTP)15-16/user-datagram-protocol (UDP)/IP packets of

various sizes using various coding schemes (such as

G.711 or G.72917). The circuit switches view the

Lucent Softswitch like yet another circuit switch or

SSP. The trunking gateway itself is controlled by the

Lucent Softswitch using a master/slave protocol such

as IPDC or MGCP to associate a specific time slot

(bay/module/line/channel or circuit identification

code) from the circuit switch with specific

source/destination RTP/UDP/IP streams. The Lucent

Softswitch, as part of its call processing, identifies

the best possible egress gateway to be used for ter-

minating the call and uses this information to com-

mand the trunking gateways to perform specific

functions. For example, the Lucent Softswitch can

choose to complete most of the calls through a

least-cost routing logic that chooses the egress gate-

way closest to the destination phone—in which

case, voice is typically carried mostly in the IP back-

bone. Alternatively, the Lucent Softswitch can

decide to use the TDM switching capabilities of the

trunking gateway, and thus complete the call

through just the circuit-switched network. The service

logic that runs as part of the Lucent Softswitch and

that makes these basic routing decisions is itself

completely programmable.

Figure 6 also illustrates the ability of the Lucent

Softswitch to handle access gateways that terminate

either integrated services digital network (ISDN) PRI

or CAS signaling from enterprise PBXs (either on dedi-

cated access lines or on an IP-based access line. Such

access gateways can be controlled by the Lucent

Softswitch in multiple ways based on the packet tele-

phony protocol actually supported by the access gate-

way. The Lucent Softswitch can act like an H.323

gatekeeper for H.323-based gateways that use the

gatekeeper-routed model, and it can act like the desti-

nation gateway for a static/destination-routed model.

The Lucent Softswitch can also control the access gate-

way using a master/slave protocol such as IPDC or

MGCP in a much finer way (at an individual DS0

level) if the access gateway tunnels the Q.931 (PRI) or



CAS signaling back to the Lucent Softswitch.

Application logic running as part of the Lucent

Softswitch can enable various applications, including

voice VPN, tie-line service, and Centrex services.

The Lucent Softswitch can support enterprise IP

PBXs and IP phones by controlling or communicating

through the appropriate protocol. In Figure 6 this is

shown by the support of IP phones on a cable network

from the Lucent Softswitch through SIP.

Figure 6 also illustrates the ability of the Lucent

Softswitch to reuse all the assets of the current PSTN

by providing access to SCPs, either by accessing the

SCP through TCAP/IP or by accessing it through

standard SS7 links (TCAP over signaling-section-and-

control part [SCCP], TCAP/SCCP). SS7 links refer to

physical links that connect an SS7 device server to

the SS7 network. These links are of six types and

labeled from A through F. Of these, the relevant

Lucent Technologies Softswitch

Trunkinggateway

MGCP/IPDC

Trunkinggateway

Accessgateway

H.323v1/v2 or

TunneledPRI with

IPDC

MGCP/IPDC

Packet intelligentperipheral

PBXISDN PRI or T1

(wink, e&m, for example),TDM G.711

Localswitch

SS7network

POTSphone

ISUP/MTP

ISUP/IP

TCAP/SCCP

SCP

TCAP/IPDirectories

Back officesystems

Cablenetwork

SIP

IP phone

Localswitch

SS7network

POTSphone

POTSphone

SLCTDMG.711

e&m – “Ear” and “mouth” leads from customer to central officeG.711 – ITU-T Recommendation G.711H.323 v1/v2 – ITU-T Recommendation H.323 v1/v2IP – Internet protocolIPDC – Internet protocol device controlISDN – Integrated services digital networkISUP – ISDN user partITU-T – International Telecommunication Union— Telecommunication Standardization SectorMGCP – Media gateway control protocolMTP – Message transfer partPBX – Private branch exchangePOTS – “Plain old telephone service”

PRI – Primary rate interfaceRTP – Real time transport protocolSCCP – Signaling section and control partSCP – Service control pointSIP – Session-initiation protocolSLC – Subscriber loop carrierSS7 – Signaling System 7T1 – Terrestrial facility (North America) to transport primary rate of 1.544 Mb/s (24 64-kb/s channels)TCAP – Transaction capabilities applications partTDM – Time division multiplexedUDP – User datagram protocolwink – Single supervisory pulse

RTP/UDP/IP

Figure 6.Lucent Softswitch-based VoIP network architecture.



links here are the A links that connect the SS7

device server to an STP and the F links that connect

the SS7 device server to an adjacent switch.

The SCPs also view the Lucent Softswitch as a

standard circuit SSP, causing no change to the SCPs.

Services such as toll-free numbers (for example, 800

and 888), local number portability, advanced VPN

services, prepaid/collect/credit-card services, and other

suites of AIN services provided by the SCP are avail-

able using the Lucent Softswitch. Calls from any

devices (using any protocol) can gain access to the cur-

rent assets of the entire PSTN because of the seamless

interworking made possible by the Lucent Softswitch.

Figure 7 illustrates the use of the Lucent

Softswitch in a core ATM network for controlling

VTOA trunking gateways. The primary difference

between Figures 6 and 7 is that the underlying media

gateways exchange voice through different transport

GR-303access

gateway


Trunkinggateway

MGCP/IPDC/

Sapphire

AAL-1/AAL-2/AAL

Trunkinggateway

Accessgateway PBX

ISDN PRI or T1(wink, e&m, for example),

TDM G.711

Localswitch

SS7network

POTSphone

ISUP/MTP

ISUP/IP

TCAP/SCCP

SCP

TCAP/IP

Back officesystems

Localswitch

SS7network

POTSphone

POTSphone

GR-303

MGCP/IPDC/

Sapphire

MGCP/IPDC/

Sapphire

TDMG.711

AAL – ATM adaptation layerATM – Asynchronous transfer modee&m – “Ear” and “mouth” leads from customer to central officeG.711 – ITU-T Recommendation G.711GR-303 – Generic Requirement 303 (Telcordia)IP – Internet protocolIPDC – Internet protocol device controlISDN – Integrated services digital networkISUP – ISDN user partITU-T – International Telecommunication Union— Telecommunication Standardization SectorMGCP – Media gateway control protocolMTP – Message transfer part

PBX – Private branch exchangePOTS – “Plain old telephone service”PRI – Primary rate interfaceSapphire – Lucent ATM gateway control protocolSCCP – Signaling section and control partSCP – Service control pointSLC – Subscriber loop carrierSS7 – Signaling system number 7T1 – Terrestrial facility (North America) to transport primary rate of 1.544 Mb/s (24 64-kb/s channels)TCAP – Transaction capabilities applications partTDM – Time division multiplexedwink – Single supervisory pulse

Directories

SLC

Figure 7.Lucent Softswitch-based VTOA network architecture.



mechanisms. In the VTOA world, voice is carried as

ATM adaptation layer (AAL) packets, such as AAL-1 or

AAL-2. Furthermore, it is possible to use permanent

virtual circuits or even to use existing signaling mecha-

nisms such as Q.293118 (UNI 3.119 or UNI 4.0) to

support switched virtual circuits at a specified quality-

of-service metric. All the applications are totally

shielded from the media difference; hence, all the sig-

naling services and applications that are possible in the

VoIP-based Lucent Softswitch architecture are also pos-

sible in the VTOA-based architecture without any extra

work by the service logics themselves. This trans-

parency is made possible by the ability of the Lucent

Softswitch to introduce new protocols and devices into

the system without compromising the existing set of

applications supported by the Softswitch. The trans-

parency is true for service logic that resides in an exist-

ing asset, such as an SCP, or a new application

developed in the Lucent Softswitch system.

Figure 8 describes how the Lucent Softswitch is

used to control RASs to provide current data services,

such as Internet call diversion. The Lucent Softswitch

either controls the RAS devices through IPDC or

Q.931 over IP. In combination with elements in the

VoIP architecture—such as the packet intelligent

peripheral (PIP), or media resource server—the Lucent

Softswitch-controlled RAS-based network provides the

basis for next-generation services that integrate data

and voice. An example would be Internet call waiting

coupled to buddy lists with text-to-speech or speech

recognition.

Figures 9 and 10 show how the Lucent

Softswitch platform can be used to provide next-

generation network control in access networks. In

Figure 9, a GR-30320 access gateway terminates digital

multiplexed traffic consisting of both G.711 media and

signaling. The control messages are tunneled up to the

Lucent Softswitch over IPDC, providing for call-

processing control as in all the previous cases.

Additional control provided by the MGCP gram-

mar, especially using a PIP, can be used to provide

fine-grained control of the analog POTS telephone at

the end user. This could include traditional dial tone,

on-hook/off-hook detection, and entirely new forms

of dial tone. One example could be an announcement

such as “Welcome to New World Telephones! Where

would you like to go today?” and an enabling of

speech-recognition–based voice prompts such as “Take

me to Mother’s house.” The IP backbone infrastruc-

ture would then provide access to evolving electronic

commerce capabilities, opening a vast array of new

service possibilities.

For enhanced PSTN service features, the Lucent

Softswitch is shown connected to the SS7 network, as

before. A specific feature server, such as the Lucent

Call Feature Server, could be used to provide complete

compatibility with a traditional circuit-switched access

infrastructure.

Figure 10 shows how the basic concepts above are

extended to digital-subscriber-line (DSL) and cable-

based access networks. In all cases, the only necessary

condition is that the signaling-and-control information

about the end-user terminal and intervening devices

(such as cable modems, home network controllers,

and gateways) is passed up to the Lucent Softswitch.

Lucent Softswitch System ArchitectureThe Lucent Softswitch system can be viewed as

consisting of a set of software components, including

call coordinators, device servers, and directory coordi-

nators. All of these components can be distributed

across a set of one or more geographically separated

hardware platforms. Full connectivity is assumed

within a Lucent Softswitch. While no geographic con-

straints are placed, it is common for service providers

to associate a single geographically contiguous area as

a softswitch. As an open system, Lucent Softswitch

components communicate across the network using

standard protocols. The schematic architecture of the

Lucent Softswitch is shown in Figure 11, and each

type of component is described in sections below.

Device servers. The Lucent Softswitch abstracts

and normalizes all sources and sinks of signaling infor-

mation using device servers. A device server is a model

for bringing an endpoint that is foreign to the system

into the call. Device servers are best thought of as

either supporting “physical” devices like gateways, or

“virtual” devices like voice mail, unified messaging, and

auto-attendants. Device servers do not maintain call

state, and they are capable of multiplexing interactions.

A device server is the Lucent Softswitch entity that



translates telephony protocols to Mantra. Protocol

translation also involves translating the Mantra

semantics to protocol-specific behavior. A concrete

example would be the rendering of an announcement

as an in-band voice message to PSTN endpoints, while

a device server for an IP-based phone service might

render the announcement as a message box. Device

servers are usually qualified by the protocol or the

product with which they interface.

Examples of device servers include protocol han-

dlers, such as network interfaces (for instance, SS7

ISUP, POTS loop start/tip and ring, T1 wink start and

TCAP/SCCP

Localswitch

SS7network

SCP

PC withmodem

ISUP(specificcountryvariant)

IP/PPP/modem IMT

ISDN PRI or T1(wink, e&m, for example)

IP/PPP/modem

Remoteaccessserver

IPDC orQ931/IP

SS7 device server

LucentTechnologiesSoftswitchMantra

Serviceproviderservlet

PRI device server

Userfeatureapplet

Call coordinator

Directory coordinator

SCPaccess

LDAPdirectory

Oracle*RDBMS

RADIUSserver

Remoteaccessserver

IPDC (PRItunneling)

RADIUS

IP networkIP

RADIUS

e&m – “Ear” and “mouth” leads from customer to central officeIMT – Intermachine trunkIP – Internet protocolIPDC – Internet protocol device controlISDN – Integrated services digital networkISUP – ISDN user partITU-T – International Telecommunication Union— Telecommunication Standardization SectorLDAP – Lightweight directory access protocolMantra – Lucent proprietary canonical multi-party call modelPC – Personal computer

PPP – Point-to-point protocolPRI – Primary rate interfaceQ.931– ITU-T Recommendation Q.931RADIUS – Remote authentication dial-in user serviceRDBMS – Relational database management systemSCCP – Signaling section and control partSCP – Service control pointSS7 – Signaling System 7T1 – Terrestrial facility (North America) to transport primary rate of 1.544 Mb/s (24 64-kb/s channels)TCAP – Transaction capabilities applications partwink – Single supervisory pulse

*Registered trademark of Oracle Corporation.

Figure 8.Lucent Softswitch-based network architecture for managed modem services.



e&m, Q.931, H.323, and Q.2931). They also include

transparent network signaling mechanisms (such as

CAS and CCS). Other kinds of device servers are end-

point handlers. These include control surface and ren-

dering engine for the user model of the physical/logical

device that is an endpoint in the call (for example,

POTS handset, ISDN phone, or PC soft phone).

Currently device servers are implemented for access

gateways (H.323 v1/v2), trunking gateways

(IPDC 0.12, MGCP, and Sapphire), SS7 signaling

interfaces, and SIP devices.

Call coordinator. The Lucent Softswitch entity in

charge of call processing is the call coordinator. This entity

processes all signaling information and arranges media

paths between device servers and gateways. Call pro-

cessing is initiated by call-request events sent by device

servers. The call coordinator manages individual calls or

sessions, maintains call state, and is the entity that

coordinates multiple device servers for accomplishing

communication. The device servers can be geographi-

cally distributed away from the call coordinator.

A single call coordinator is connected to all the

Analogloop

Subscriberloop carrier

To SS7network

G.711 audio

Trunks totoll/tandem

switches

GR-303 aggregateddigital TS interface GR-303 aggregated

digital TS interface

(Signaling + G.711 audio)

Local digitalcircuit switch Lucent

TechnologiesSoftswitch

GR-303access

gatewayRTP/

UDP/IP

IPDCtunnelled

MGCP

IP

MGCP MGCP

RTP/UDP/IP

Trunkinggateway

PIP

Trunks tocircuit switches

G.711 audio

Media processing

G.711 – ITU-T Recommendation G.711GR-303 – Generic Requirement 303 (Telcordia)IP – Internet protocolIPDC – Internet protocol device controlITU-T – International Telecommunication Union— Telecommunication Standardization Sector

MGCP – Media gateway control protocolPIP – Packet intelligent peripheralRTP – Real time transport protocolSS7 – Signaling System 7TS – Time slotUDP – User datagram protocol

To SS7network

Figure 9.Next-generation access services controlled by a Lucent Softswitch.



device servers in its own Lucent Softswitch site. It can,

and for most meaningful services should, be connected

to other Lucent Softswitch sites. This inter-softswitch

connectivity is between call coordinators and is

arranged using a merge device.

Merge device. This is a dummy device server or a

link that connects one Lucent Softswitch site to

another. It is not a bidirectional link in the sense that,

of two Lucent Softswitches interconnected, the merge

device is only used for calls originating in one

Softswitch site and terminating in the other. One

Lucent Softswitch need not be interconnected to all

other Softswitch sites with a single link. In other

words, a Lucent Softswitch site A can have connectiv-

ity to Lucent Softswitch site C using a Lucent

Softswitch site B. Additionally, due to the nature of

the merge device, the Lucent Softswitch site C in the

prior example can be connected to Lucent Softswitch

site A using a direct link.

Service provider servlet. In any call, service-

provider–specific features are accomplished through a

service provider servlet (SPS) and user-specific features are

accomplished through user feature applets (UFAs), as

described below. The SPS is the active piece of code

that controls the basic call model (Mantra) that is

embedded in the call coordinator. The call coordinator

is instantiated by the SPS and there is exactly one

instance of the SPS per call coordinator. The SPS is

pluggable code developed for or by the service provider

and underlines the flexibility of the Lucent Softswitch.

GR-303 aggregateddigital TS interface

(Signaling + G.711 audio)

EnterpriseIP network

Lucent TechnologiesSoftswitch

Analogloop

termination

Subscriberloop carrier

Phoneadapter

DSL/cableaccess network

GR-303access

gateway

IPbackbone

To SS7 network

PIPTrunkinggateway

IP phonesIP phones

G.711 audio

MGCP

DSL – Digital subscriber lineG.711 – ITU-T Recommendation G.711GR-303 – Generic Requirement 303 (Telcordia)IP – Internet protocolITU-T – International Telecommunication Union— Telecommunication Standardization Sector

MGCP – Media gateway control protocolPIP – Packet intelligent peripheralSS7 – Signaling System 7TS – Time slot

Figure 10.Lucent Softswitch control of DSL and cable access.



User feature applets. The SPS can be pro-

grammed to contain a variety of trigger points that

invite the loading of applets. These applets provide

customization for user features and hence are called

user feature applets (UFAs). A UFA is the active piece of

code that controls one or more conceptual legs of a

call. The UFA represents a user in the call who, for

example, can model a subscriber. The SPS can be con-

sidered as a giant UFA that represents all users in the

system. In fact, the Lucent Softswitch model is to allow

UFAs to be embedded in the SPS that may result in

efficiencies of scale and operation.

To illustrate the customization of user features,

UFAs may be loaded based on calling-party num-

ber or called-party number, or for any attribute of

the caller or called party for that matter. Call pro-

cessing is passed to the UFA that is configured for

the calling party, and then to the UFA that is con-

figured for the called party. These UFAs can lever-

age a wide variety of sophisticated call-processing

features, such as advanced “find me” services.

Like all aspects of the call coordinator, the UFAs

are written in Java* language. A variety of loading poli-

cies can be defined that specify whether the applet is to

be loaded from the same Java virtual machine (JVM)

as the SPS, or from another JVM but on the same host

machine, or from a JVM on an entirely different host

machine. Security and protection policies are associated

with the different loading policies. The association

between users and UFAs is maintained in the directory.

For additional details, refer to the section on third-

party service creation.

Policy server: next generation OA&M for the

Lucent Softswitch. The operations, administration,

and maintenance (OA&M) of the Lucent Softswitch

components is based on a notion of programmable

policies. A policy is a specification that relates three

entities: the state of the Lucent Softswitch compo-

nents, the context under which these components

operate, and a set of actions that can be undertaken to

Policyserver

User featureapplet

SS7 deviceserver

H.323 deviceserver

Tunneled PRIdevice server

Directorycoordinator

Service providerservlet

Call coordinatorSIP

device server

Mantra (on TCP orDIAMETER/UDP)


DIAMETER – Lucent internal protocolH.323 – ITU-T Recommendation H.323ITU-T – International Telecommunication Union— Telecommunication Standardization SectorMantra – Lucent proprietary canonical multi-party call model

PRI – Primary rate interfaceSIP – Session-initiation protocolSS7 – Signaling System 7TCP – Transmission control protocolUDP – User datagram protocol

Figure 11.Lucent Softswitch system architecture.



change the behavior of the components. The state of a

component is represented by events that it generates;

for example, a burst of incoming traffic at a device

server may generate an event signaling congestion at

that element. The failure of an element to respond to a

signal could generate an event. Events generated by

elements are said to be primitive. Primitive elements

can be temporally aggregated to define composite

events. For example, congestion at an element fol-

lowed by a failure to respond to certain stimuli may be

defined as a complex event. Conjunction, alternation,

and negation over primitive events can be used to

define complex event expressions.

Events are associated with a context, which is a set

of attributes. For example, congestion may be an event

with attribute “device server,” which may have a value

“SS7.” Contexts are used to distinguish between events

that originate from various sources or from the same

source. For example, two events generated by the same

element but temporally separated would have different

contexts. Finally, actions are external procedures that

are executed when prescribed events occur in given

contexts. An action may consist of a single procedure

or it may consist of a workflow that ties several proce-

dures into a more complex arrangement.

Policies are stated in a policy description language (PDL)

that has the following basic construct, called a rule:

Event causes Action if Condition.

A set of rules describes one or more policies. A

program in PDL consists of some number of policies.

The OA&M prescription for the Lucent Softswitch

consists of a set of policies written in PDL and imple-

mented by a system called the policy server. The policy

server consists of three main architectural compo-

nents. One component is the policy enforcement point

(PEP), which receives primitive events from Lucent

Softswitch components and exposes those events to an

event aggregator. The event aggregator correlates

events from multiple PEPs and exposes them to the

policy engine. The policy engine consists of rules; a

rule is fired if the event expressions in that rule evalu-

ate to true and the context given by the conditions C

of that rule holds true. The firing of a rule may result

in the execution of one or more actions; since an

action is represented by a procedure, the firing of an

action may result in a command being sent to the PEP.

In addition to acting as event filters, PEPs also affect

actions on components. Examples of typical actions

carried out by PEPs are re-starting a component, trig-

gering a component with a particular stimulus, and

changing some data structure in an interface exposed

by the component (for example, a routing table entry).

The diagram in Figure 12 shows the main architec-

tural components of the policy server. The policy

server uses an internal protocol, Styx® , to communi-

cate information between its various components. The

device aggregator also exposes an SNMP interface,

enabling existing SNMP-based management systems

to use the Lucent Softswitch OA&M system.

The policy server monitors all management events

in the Lucent Softswitch system and maintains control

over all elements. In particular, the policy server mon-

itors the health of all Lucent Softswitch components,

maintains configuration information for all Lucent

Softswitch components, and collects the traps from all

Lucent Softswitch components. The policy server also

presents the management portal for administrators

into the Lucent Softswitch system. As such, the policy

server can be scripted to filter/correlate various traps,

notify other processes about registered events, and

support custom fail-over policies. The policy server

provides centralized administration of a number of dif-

ferent kinds of OA&M policies including alarm filter-

ing, fail-over, device configuration and provisioning,

service class configuration, and congestion control.

The Lucent Communication Directory Server (LCDS) is a

directory coordinator that is a meta-directory providing

uniform access to multiple types of directories transpar-

ently. LCDS exposes an LDAP interface that can be

used by clients to access data resident in various under-

lying data sources. It thus offers data storage trans-

parency. LCDS also offers schema transparency, in the

sense that various components of a schema may refer

to different underlying storage systems. Finally, LCDS

offers access-protocol transparency in that the underly-

ing storage systems may be accessed by a variety of

protocols, such as LDAP, RDBMS, SIP, and TCAP.

Lucent Softswitch RoutingCall processing begins in the SPS, which performs

basic address resolution and selects the device server



or servers that should participate in the call. The SPS

also enforces mandatory policy controls, such as least-

cost routing, and verifies that applicable restrictions are

met. For further details, refer to the section “Third-

Party Service Creation.”

All call-coordinator instances in a single Lucent

Softswitch site share the same routing database, which

can be independently provisioned in a high-performance

relational database such as an Oracle* database. Call-

coordinator instances cache the routing table during

startup for high performance. Refresh triggers are nec-

essary for call-coordinator instances to read the new

routing table. On refresh, new calls are routed using

the new table while existing calls are unaffected.

How Enhanced PSTN Services Are ProvidedThe Lucent Softswitch provides three different

avenues for offering services. In traditional PSTN, the

SCP contains service logic that is accessed from the SSP

through a protocol called the TCAP protocol. For exam-

ple, services requiring number translations usually

invoke TCAP queries to the SCP from the SSP. For

such service offerings, the Lucent Softswitch provides

interworking with the SCP via the TCAP protocol, thus

allowing reuse of the rich set of PSTN services already

implemented in SCPs. The Lucent Softswitch basically

acts like an SSP to an existing SCP. Protocols between

the Lucent Softswitch and an SCP are TCAP/SCCP,

INAP/TCAP/SCCP and TCAP/IP. The INAP 0.1

(AIN 0.1) call model is embedded in the service

provider servlet of the Lucent Softswitch. The two-

party model of INAP is a subset of the multi-party call

model (Mantra) intrinsic to the Lucent Softswitch. AIN

trigger-detection points and event-detection points are

mapped to the SPS primitives. Current developments

are under way to support European Telecom-

munication Standards Institute INAP CS1 and CS2

as well.

Many service logic packs in the SCP make use of

media services. Typical examples of such services are

pre-paid calls and credit-card–based calls, in which

various announcements are played to the subscribers

and tones generated by the subscribers are collected

Pi – Policy iPEM – Policy event managerPEP – Policy enforcement pointSNMP – Simple network management protocol

Policy viewservice

Services views/managers

Event manager

Data coordinator

Directories Devices

Lucent CommunicationDirectory Server (LCDS)

Styx

Deviceaggregator

SNMP

HPOpenView*

Policy execution engine

P0 P1 P2

Device server

PEP PEM

Device interface

Networkelement

Styx

Device server

Device interface

Networkelement

Styx®

Databases

*Trademark of Hewlett-Packard Company.

PEP PEM

Figure 12.Policy server architecture.



and analyzed. These functions in the PSTN are typi-

cally carried out by devices called circuit adjuncts or

intelligent peripherals. An intelligent peripheral offers

TDM interfaces that terminate media and allow tone

detection, speech recognition, and other such media

services. Usually, the SSP controls and instructs the

intelligent peripheral (at the behest of the service logic

in the SCP) using a protocol called Telcordia

GR-1129,21 which is a variant of ISDN PRI. The Lucent

Softswitch also supports this mode of interaction by

providing a GR-1129 interface.

A variation on this model is possible with a new

kind of device called the PIP, mentioned above (see

Figures 6, 9, and 10). The PIP is an external media

processing engine capable of terminating RTP/UDP/IP

or AAL-1/AAL-2 audio streams and performing some

processing on those streams. The PIP provides the

same set of functionality as an intelligent peripheral

except that it has no physical interfaces to terminate

TDM traffic.

The PIP expects RTP/UDP/IP media streams that it

processes for the usual intelligent-peripheral func-

tions—namely, tone detection, announcement record-

ing and playing, and speech services. The PIP is an

adjunct to the Lucent Softswitch and is of interest to

those service providers who are interested in offering

IP-based devices in their networks. The PIP performs

all media processing on RTP/UDP/IP streams (as

opposed to TDM streams in a conventional circuit

intelligent peripheral). There are open research

problems in processing RTP/UDP/IP streams in a

scalable fashion on a PIP device; we intend to

cover these issues in a future paper.

The third avenue that the Lucent Softswitch pro-

vides to service providers for offering new services is to

develop new UFAs. As stated earlier, a UFA is dynami-

cally loaded by the service provider servlet; this loading

can be triggered by any number of events programmed

in the SPS. Software development kits (SDKs) are avail-

able for developers of UFAs.

How New Data Services Are ProvidedSS7 co-carrier trunks, or IMTs, offer a way to divert

modem traffic from the core circuit network. In addition,

regulatory tariff benefits (also known as reciprocal payment)

act as an incentive for a data competitive local exchange

carrier (CLEC) to terminate modems through this

arrangement instead of through ISDN PRI. A cost-

effective large-scale aggregation of modem termina-

tions would allow a data CLEC to offer managed

modem services to smaller Internet service providers

(ISPs) as well as to enterprises where the smaller ISPs

and enterprises do not have to own and manage

remote access servers. For example, an aggregated

DS1/DS3/OC-3 connection running IP between the

data CLEC and the ISP or enterprise could be used to

provide private network routing (for security and

guaranteed performance) or to provide public Internet

routing. In addition, the data CLEC could use the ISP’s

or enterprise’s RADIUS server to authenticate users.

The Lucent Softswitch architecture controls VoIP

as well as modem calls in a consistent and unified fash-

ion. IPDC protocol control is used between the Lucent

Softswitch and the RAS. The Lucent Softswitch can

control an existing ISDN PRI-based RAS in a unified

fashion by tunneling Q.931 signaling from the RAS.

New applications that integrate voice and IP ser-

vices are possible in this infrastructure using the SPS

and UFA.

Third-Party Service CreationAs carriers build new network infrastructures

with increasing bandwidth, they are looking to drive

the rate of innovation in new services to utilize that

bandwidth. In addition, they are looking for a larger

base of suppliers of new services and features than

just the network technology providers for the con-

ventional networks. A key emerging requirement for

next-generation networks is open programmability

that allows third-party independent software vendors

(ISVs) to be able to create new services and features

for public carriers’ networks. However, the service

providers need assurances that ISV-developed services

will not corrupt their network, will not degrade per-

formance or compromise security, and will be free of

feature interactions.

The Lucent Softswitch provides just such an envi-

ronment. By developing UFAs using the SDK, a ser-

vice provider can offer a variety of new services in a

network controlled by a Lucent Softswitch. Moreover,

these applets can be developed by ISVs. As stated earlier,

feature applets can be loaded according to a variety of



policies. In particular, a feature applet may be loaded

from a host in an ISV-controlled premises. The danger

in this loading policy is that the loaded applet can

engage in malicious behavior and corrupt the net-

work. Such loaded applets are governed by security

and protection policies that prevent applets from

opening connections to certain network resources and

components and by controlling the amount of traffic

that such applets can generate. That is, the applets are

governed by rate and connection control policies. A

UFA may use network resources or undertake interac-

tions with external entities. Examples of such third-

party services include both media-based services and

event-detail–based services.

ConclusionIn this very brief and high-level presentation,

we have attempted to cover the basic motivations

that led to the Lucent Softswitch project. Packet-

switching technology and the deregulation of

telecommunication markets are powerful forces that

are shaping the landscape of next-generation com-

munication networks. Simultaneously, computing

power and resources are becoming more powerful

and cheaper by the day. These various forces have

led to certain axioms in the design of the Lucent

Softswitch. Most notably, the Lucent Softswitch

adheres fundamentally to a policy of being agnostic

to hardware that it controls and to the platforms that

the software system runs on. It does not prefer any

one set of signaling protocols, relying rather on protocol

interworking. The Lucent Softswitch offers oppor-

tunities to reuse service assets by interworking with

existing service control points and other legacy

devices. This Softswitch allows new services to be

created by programming the basic switch at various

levels of detail and abstraction. The Lucent

Softswitch is inherently and intrinsically program-

mable in the sense that the most basic switching fab-

ric, the service provider servlet, can itself be

programmed by the service provider through an

open API. This fundamental programming philosophy

allows new services to be developed by independent

software vendors.

AcknowledgmentsThe Lucent Technologies Softswitch resulted from

Project Saras, which was initiated by Bell Labs

researchers Murali Aravamudan and Shamin Naqvi,

departments heads of Communication Software

Research and Network Computing Research, respec-

tively. The Lucent Softswitch team consists of many

developers, prominent among them being Prakash Iyer,

Jana Kadirkamanthan, and Kumar Vishwanathan.

I am privileged to articulate their creativity and accom-

plishments. Any errors, factual or perceptual, remain

solely mine.

*TrademarksJava and Sun are trademarks of Sun Microsystems, Inc.

NetMeeting is a registered trademark of MicrosoftCorporation.

Oracle is a registered trademark of Oracle Corporation.

References1. Standards Committee T1 Telecommunications,

“Telecommunications - Signalling System No. 7(SS7) – General Information,” T1.110, ANSI,1992, http://www.ansi.org

2. Travis Russell, Signaling System #7, McGraw-Hill(New York, New York), 1998.

3. International Telecommunication Union,“Packet-based multimedia communications systems,” ITU-T Rec. H.323, Version 2/1998,http://www.itu.int/ITU-T/index.html

4. International Telecommunication Union, “Callsignalling protocols and media stream packeti-zation for packet-based multimedia communi-cation systems,” ITU-T Rec. H.225.0, Version2/1998, http://www.itu.int/ITU-T/index.html

5. International Telecommunication Union,“Security and encryption for H-Series (H.323and other H.245 based) multimedia terminals,”ITU-T Rec. H.235, Version 2/1998, http://www.itu.int/ITU-T/index.html

6. International Telecommunication Union,“Control protocol for multimedia communication,”ITU-T Rec. H.245, Version 9/1998, http://www.itu.int/ITU-T/index.html

7. International Telecommunication Union,“Generic functional protocol for the support ofsupplementary services in H.323,” ITU-TRec. H.450.1, Version 2/1998,http://www.itu.int/ITU-T/index.html

8. International Telecommunication Union, “Call transfer supplementary service for H.323,”ITU-T Rec. H.450.2, Version 2/1998, http://www.itu.int/ITU-T/index.html



9. International Telecommunication Union, “Call diversion supplementary service forH.323,” ITU-T Rec. H.450.3, Version 2/1998,http://www.itu.int/ITU-T/index.html

10. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: Session Initiation Protocol,”RFC 2543, IETF, March 1999, http://www.ietf.org/rfc/rfc2543.txt

11. Internet Engineering Task Force “MediaGateway Control (megaco) Protocol,” IETFDrafts, April–July 1999, http://www.ietf.org/ids.by.wg/megaco.html

12. Saras is an arbitrary contraction of Sarasvati,the name of the Hindu goddess of intelligence,knowledge, and fine arts. The name was chosento represent the qualities that the LucentSoftswitch technology was intended to impartto networks.

13. International Telecommunication Union, “ISDNuser-network interface layer 3 specification forbasic call control,” ITU-T Rec. Q.931, Version5/1998, http://www.itu.int/ITU-T/index.html

14. International Telecommunication Union, “Pulse code modulation (PCM) of voice fre-quencies,” ITU-T Rec. G.711, Version 11/1988,http://www.itu.int/ITU-T/index.html

15. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobsen, “RTP: A Transport Protocol forReal-Time Applications,” RFC 1889, IETF,Jan. 1996, http://www.ietf.org/rfc/rfc1889.txt

16. H. Schulzrinne, “RTP Profile for Audio andVideo Conferences with Minimal Control,”RFC 1890, IETF, Jan. 1996, http://www.ietf.org/rfc/rfc1890.txt

17. International Telecommunication Union,“Coding of speech at 8 kbit/s using Conjugate-Structure Algebra Code-Excited Linear-Prediction (CS-ACELP),” ITU-T Rec. G.729,Version 3/1996, http://www.itu.int/ITU-T/index.html

18. International Telecommunication Union,“Digital Subscriber Signalling System No. 2 –User-Network Interface (UNI) layer 3 specifica-tion for basic call/connection control,” ITU-TRec. Q.2931, Version 2/1995, http://www.itu.int/ITU-T/index.html

19. ATM Forum, ATM User Network Interface(UNI) Specification Version 3.1, Prentice Hall(Upper Saddle River, New Jersey), 1995.

20. Telcordia Technologies (formerly Bellcore),“Integrated Digital Loop Carrier System GenericRequirements, Objectives, and Interface,”GR-303, Issue 1, Sept. 1995 and all revisionsand supplements.

21. Telcordia Technologies (formerly Bellcore),

“AINGR: Switch – Intelligent PeripheralInterface (IPI),” GR-1129-CORE, Issue 3, Sept. 1997.

(Manuscript approved August 1999)

RAMNATH A. LAKSHMI-RATAN is the director ofProduct Management and Marketing forthe Lucent Softswitch in the ConvergedNetwork Solutions Unit of LucentTechnologies’ Communications SoftwareGroup in Murray Hill, New Jersey. He holds

a B.Sc. in mathematics, physics, and chemistry from theUniversity of Poona in India, an M.M.S. in operationsresearch and marketing from the Bajaj Institute at theUniversity of Bombay, also in India, and a Ph.D. inoperations research and marketing from the Universityof Pittsburgh in Pennsylvania. Dr. Ratan was formerlythe director of Strategy and New Business Develop-ment for Lucent’s Communications Software Group. He also was co-founder and architect of the ConsumerLaboratory at AT&T Bell Laboratories and the recipientof an AT&T Patent Award for creating a network plat-form for personal telecommunications features. Priorto his recent assignments in industrial research anddevelopment, Dr. Ratan held faculty positions at theUniversity of Wisconsin in Madison, the University ofPittsburgh in Pennsylvania, and Rutgers University inNewark, New Jersey. He also worked as an independentmarketing consultant. ◆


The Lucent Technologies Softswitch-Realizing the promise ... · ♦ The Lucent Technologies...

Documents

Transcript of The Lucent Technologies Softswitch-Realizing the promise ... · ♦ The Lucent Technologies...