Reducing complexity for converged voice/data networks and services architecture

Bell Labs Technical Journal ◆ April–June 2000 55Copyright 2000. Lucent Technologies Inc. All rights reserved.

IntroductionTelecommunications service providers have

deployed packet-based data networks separately from

traditional circuit-based voice telephony networks;

consequently, services, equipment, and management

of these networks are disjoint. There is currently a

movement to bring these capabilities together on

packet networks. Service providers are also requiring

support for third-party programmability of services.

One driver for convergence is a reduction in complex-

ity that will eventually result in greater service inte-

gration as well as management and equipment

savings. Even the word convergence carries the promise

of simplification. However, the reality is that the new

capabilities to converge are being added to an

extremely large, existing, complex system. Even as

converged voice/data networks reduce significant

aspects of complexity inherent in deploying and man-

aging separate networks, they introduce new areas of

potential complexity by providing greater sophistica-

tion, including support for equipment from multiple

vendors and third-party programmability. The internal

components of the hardware and software elements

may need to increase significantly in sophistication

and complexity to reduce the external complexity visi-

ble to service providers and service users.

This paper examines the move toward converged

voice/data networks and services architecture and pre-

sents principles for reducing complexity while manag-

ing the increased sophistication of the architecture

components. The scope of the paper includes the

aspects of the 7R/E† Packet Solutions that address

complexity by framing the target solutions’ architec-

ture space as well as the component-based service

architecture for the 7R/E programmable feature server

(PFS), which is at the heart of converged voice/data

services.

♦ Reducing Complexity for ConvergedVoice/Data Networks and Services ArchitectureJanet R. Dianda, Bin-Wen Ho, and Kristin F. Kocan

The telecommunications industry today is facing an increasing degree of complexitydue to the proliferation of available technologies and separate implementations ofvoice and data networks and services. Recent trends in the industry toward a conver-gence of telephony/computer technologies, networks, and services create an oppor-tunity for reducing complexity in the converged voice/data network. The convergedtelecommunications network will be packet based, providing integratedvoice/data/video services with third-party programmability to any subscriber, any-where, over any access media. This paper describes an architectural approach tomeet these challenges. A set of guiding principles is formulated and used for devel-oping the converged network and service architectures. These principles, which pro-vide an overall framework for partitioning network and service functions intocomponents, are illustrated using the planned 7R/E† Packet Solutions system andservice architectures to build component-based converged voice and data serviceswith interfaces to operations, administration, maintenance, and provisioning(OAM&P) frameworks for industry-grade reliability, availability, and security.

56 Bell Labs Technical Journal ◆ April–June 2000

Convergence Trends in the Telecommunications IndustryThe dominant trends in the telecommunications

industry today are convergence in the areas of tech-

nologies, transport and access networks, and services.

They provide an opportunity to enable new networks

and services that would be very complex to provide in

today’s systems, but they also bring along their own

complexities, which must be addressed.

Technologies convergence. There is an acceler-

ated pace in the convergence of telephony and com-

puter/Internet technologies. Packet switching

technology, originally designed for computer commu-

nications, has emerged as the dominant technology for

telephony networks. Recent software technology

advances such as object-oriented programming, dis-

tributed client/server computing models, middleware,

and open application programming interfaces (APIs)

for custom programmability have become standard

practices. In the area of hardware, standard PC/work-

station boards are increasingly used as platforms for

switching applications.

Voice and data networks convergence. With the

convergence described above, it has become feasible

for a common, packet-based core network to provide

Panel 1. Abbreviations, Acronyms, and Terms

AAL1—ATM adaptation layer type 1AAL2—ATM adaptation layer type 2ADSL—asymmetric DSLAPI—application programming interfaceASR—automatic speech recognitionATM—asynchronous transfer modeBICC—bearer-independent call controlBRA—basic rate accessBRI—basic rate interfaceCAG—cable access gatewayCCS7—Common Channel Signaling System 7CFS—call feature serverCOPS—common open policy serviceCPU—central processing unitDPE—distributed processing environmentDSL—digital subscriber lineH.323—ITU standard for multimedia (real-time

voice, data, video communication) across IP-based networks

H.248/Megaco—ITU standard for media gatewaycontrol

IETF—Internet Engineering Task ForceIN—intelligent networkIP—Internet protocolIPDC—IP device controlISC—International Softswitch ConsortiumISDN—integrated services digital networkITU-T—International Telecommunication Union,

Telecommunication Standardization SectorIVR—interactive voice responseIWG—interworking gatewayJAIN*—Java* APIs for integrated networksLAG—line access gatewayLDAP—lightweight directory access protocolMCU—multimedia conferencing unit

MMRS—multimedia resource serverMSF—Multiservice Switching ForumNCS—network-based call signalingOAM&P—operations, administration, maintenance,

and provisioningOSS—operations support systemPAG—packet access gatewayParlay—an open API specified by the Parlay Group

to enable secure, public access to core capabili-ties of telecommunication and data networks

PC—personal computerPFS—programmable feature serverPOTS—“plain old telephone service”PRA—primary rate accessPRI—primary rate interfacePSTN—public switched telephone networkQoS—quality of serviceSDSL—symmetric DSLSG—signaling gatewaySIP—session initiation protocolSNMP—simple network management protocolSS7—Signaling System 7TAG—trunk access gatewayTCAP—transaction capabilities application partTINA-C—Telecommunications Information

Networking Architecture ConsortiumURL—uniform resource locatorVPN—virtual private networkWAG—wireless access gatewayW-CDMA—wideband code division multiple

accessW-TDMA—wideband time division multiple

accessxDSL—any of various DSL technologiesXML—Extensible Markup Language

Bell Labs Technical Journal ◆ April–June 2000 57

transport for any type of information via any type of

media access—wireline or wireless, narrowband or

broadband. In fact, “voice” has become just one type

of data. Today’s separate transport networks for voice,

data, and video will converge into a single, unified,

packet-based network, as described in the section, “An

Approach to Reducing Complexity: The 7R/E Target

Architecture.”

Access networks convergence. The rising

demand for data services and the rapid growth of

Internet services are the primary drivers for access net-

works convergence. Considering access as “the last

mile,” converged broadband voice/data/video access

types are becoming increasingly real. In the wireline

arena, access types such as asymmetric digital sub-

scriber line (ADSL), symmetric digital subscriber line

(SDSL), and cable modem are already planned or

being deployed. In the wireless arena, next-generation

wideband code division multiple access (W-CDMA)

and wideband time division multiple access (W-TDMA)

networks are becoming reality. The challenge is to pro-

vide a common packet node with a core set of services

across all the access types without redeveloping the

services for each one. Graceful interworking of services

between endpoints with different access types is also

required.

Service convergence. With the convergence of

technologies and networks, any value-added services

on the converged network can be made available to

any end user, anywhere in the world, over any access

media. Furthermore, the marriage of telephony and

Internet technologies opens the possibility for user

customization of services over a Web-based interface

in real time. Open APIs for rapid service creation and

deployment—using object-oriented-based technology

in a distributed processing environment (DPE)—may

become a standard feature for any service platform.

The section entitled “A Component-Based Service

Architecture for the 7R/E PFS” explains how the PFS

supports service convergence.

Guiding Principles for Reducing Complexity of theConverged Voice/Data Networks Architecture

These convergence trends create an excellent

opportunity for introducing new paradigms, concepts,

technologies, and design principles for emerging, con-

verged voice/data networks and services. To reduce

the complexity in providing these networks, we have

identified the following guiding principles:

• Decomposing network functions into components with

well-defined interfaces. A decomposition scheme that

clearly separates network functions into compo-

nents results in a component-based network archi-

tecture in which a network can be described as

consisting of components interconnected through

a common signaling/transport interconnect core.

Using industry open interfaces between these

functional components reduces the complexity of

supporting mix-and-match interworking, enabling

a flexible architecture that can be configured for

various applications.

• Separating services from transport components. The

functional decomposition uses a layered approach

that separates services from network transport

components. This principle allows independent,

separate evolution paths for service and transport

components, enabling common services to be

applied seamlessly across various transport and

access types.

• Providing a fully distributed architecture and processing

environment with component location transparency. The

solution must take advantage of the distributed

client/server technology for location transparency,

enabling flexible packaging of logical functional

components into physical elements. It also extends

the concept of a switching “node,” in which a node

can be geographically dispersed yet logically man-

aged and administered as a single entity.

• Developing mix-and-match components to support flexi-

ble configurations and technology upgrades. The com-

ponents must be able to work with each other in a

mix-and-match manner so that a subset of these

components can be selected and configured to pro-

vide a specific application. Individual components

can be replaced or upgraded to follow technology

curves without affecting other components.

• Supporting updates of network and service components

with advanced service programmability. The compo-

nents must be capable of accommodating updates

to their software and hardware without disrupting

existing user services. This capability is important


for supporting fast service creation and deploy-

ment, especially the incremental changes required

for third-party programmability.

• Providing interworking functions in the new networks to

interact gracefully with the legacy systems. To protect

existing legacy investments, it is essential that a

graceful evolution path, enabling legacy systems

and components to interwork with new-generation

network and service components, be identified.

This approach will provide services transparency to

legacy end users.

• Integrating operations, administration, maintenance,

and provisioning (OAM&P) management. With the

“flattening” of telecommunications networks into

components and interconnections, the manage-

ment of components becomes more unified. A

node may be defined logically as a grouping of

components managed together by an integrated

OAM&P management system, regardless of the

geographical locations of these components. This

approach could reduce complexity by simplifying

the management of the overall network, resulting

in substantial management savings.

Counteracting Aspects of Complexity for Service ProvidersThree major aspects of complexity for service

providers, their causes, and potential approaches to

counteract the causes are discussed in this section.

Service complexity. Service-related capabilities are

controlled by multiple vendors of complex equipment.

Both voice and data services have a strong coupling to

the particular vendors involved; providing a new ser-

vice may involve several vendors and multiple steps.

New service capabilities are developed and tested for

consistency and interoperability with other services,

and the necessary systems are upgraded or deployed.

The intelligent network (IN) is a countermeasure to

this problem and will remain so, since it provides a cen-

tralized point for modification through software

updates. However, some services are not amenable to

IN triggering. Data services are not typically call-

processing based, but they are management related and

rely on policies deployed to data transport equipment.

Traditional switching networks have great difficulty in

providing the desired level of flexibility and program-

mability now required by service providers.

A more comprehensive approach to counteract

this aspect of complexity is to apply the guiding princi-

ples of functional partitioning of systems in the net-

work into components with well-defined

interfaces—specifically, decoupling the services layer

from the transport layer. This partitioning, combined

with the principles of developing mix-and-match com-

ponents for a DPE, enables the use of off-the-shelf

equipment and software from multiple vendors. The

partitioning is described in the section entitled “An

Approach to Reducing Complexity: The 7R/E Target

Architecture.” In addition to high-level decoupling of

components, service layer components benefit from

being decoupled to the extent that independent devel-

opment and deployment is practical. The service com-

ponents should provide open APIs at the call

processing/service switching point level, in addition to

providing IN triggers for programming applications at

higher levels. Policies to govern data services must also

be programmable. These steps are critical to reducing

complexity in deploying third-party services and are

described in detail in the “Reducing Complexity in the

Converged Voice/Data Services Platform” section.

The deployment of converged voice/data packet

networks will create a whole new area of complexity

for service providers—interworking services and calls

on packet-based networks with those on circuit-

switched networks. The guiding principle of providing

interworking functions on converged voice/data net-

works to interact gracefully with legacy systems

addresses this issue.

Equipment maintenance and upgrade complexity.

Maintaining and adding capabilities to network equip-

ment takes too long and costs too much. An enormous

variety of equipment is deployed in the network,

sometimes with overlapping functionality. Just storing

the needed spare parts can be quite costly for service

providers. Even within a given vendor’s product line,

consistency is rare, especially with the number of

acquisitions taking place.

One approach to counteract this aspect of com-

plexity is to move toward platforms and multiuse

components, leveraging the guiding principle of

decomposing network functions into mix-and-match

components with well-defined interfaces. This


approach takes advantage of the similarity of prevalent

equipment and goes a step further to actually use the

same frame, backplane, or circuit packs. From a soft-

ware vantage, it includes using the same middleware,

functional packages, platforms, and frameworks where

appropriate.

System management complexity. Network man-

agement is too complex. Variety in operations support

systems (OSSs) and alternative management systems

continues to be the norm. Data equipment does not

have the same management paradigm as traditional

voice switches and may use hybrid element managers

and network managers to get a network view of

deployed equipment.

One approach to counteract this aspect of com-

plexity is to apply the guiding principle of integrated

OAM&P management—to unify system operations

with a single system that handles multiple types of

equipment, representing elements with a common

object model and providing a unified user interface.

The 7R/E OneLink Manager† provides these capabili-

ties for 7R/E Packet Solutions.

An Approach to Reducing Complexity: The 7R/ETarget Architecture

The guiding principles described above are applied

to a high-level architecture model—the 7R/E target

architecture model—to manage the overall complexity

of 7R/E architecture for the 7R/E Packet Solutions

family of products. The purpose of target architecture

is to provide a high-level framework for current and

future 7R/E components, enable mix-and-match

interworking of various components for intended

applications, allow independent evolution paths for

these components, and ensure the overall integrity of

7R/E Packet Solutions.

7R/E Architecture PrinciplesUsing the general guiding principles, a set of 7R/E

architecture design principles is identified as follows:

• 7R/E functions are decomposed into three

planes—services/control, interconnect, and media

access/resources, as shown in Figure 1.

• A 7R/E component belongs to one of these func-

tional planes and supports reference interfaces to

other components.

• Industry open interfaces are used between compo-

nents where applicable.

• Voice/data/video multimedia integration is

provided.

• Mix-and-match interworking of components is

supported to provide seamless services for wireline

local, tandem, and wireless applications in con-

verged voice/data networks.

• Components in all planes can be either geographi-

cally centralized or remote.

• Boundaries of a 7R/E node are determined by the

OneLink Manager, which may administer geo-

graphically distributed elements.

• A graceful evolution path is provided for convert-

ing 5ESS® legacy investments to the 7R/E system.

• New development environments and techniques

are used to improve time to market and support

more flexible configurations and updates.

• The 7R/E system is configurable to support

requirements for reliability, capacity, and cost.

The 7R/E Target Reference ArchitectureAs described in the architecture principles above,

the 7R/E components are grouped into three planes:

services/control, interconnect, and media access/

resources. Control and signaling messages between the

components are communicated via open APIs and

protocols, whenever applicable, through the inter-

connect plane. Many standards bodies and industry

forums, such as the International Telecommunication

Union (ITU), the Internet Engineering Task Force

(IETF), the Multiservice Switching Forum (MSF),1 and

the International Softswitch Consortium (ISC)2 are

addressing these new open interface issues. Figure 1

illustrates the 7R/E target reference architecture,

including the functional planes and the major

architectural component groups in each of the planes:

• In the services/control plane, three component

groups are proposed:

– The feature server group, which is responsible for

call control functions and services associated

with a call or a multimedia session. It also con-

trols media gateways and media resource

servers in the media plane.

– The management server group, which provides a

unified OAM&P interface to the external OSS


and handles the element management func-

tions of components belonging to the switching

complex.

– The application server group, which includes

applications for specific telephony and data

applications—for example, Web servers, mobility

servers (such as user authentication, registration,

and location), policy servers, broker servers,

directory servers, e-commerce servers, messaging

servers, and content servers. These servers

become a part of the switching complex when

they are managed by the management server.

• The interconnect plane provides connectivity for

control/signaling messages between the compo-

nents as well as switching/routing media traffic

between the media components in the media

access/resources plane. The interconnect fabric group

provides connectivity between 7R/E components

as well as interfaces to the core packet network,

which may be Internet protocol (IP), IP/asynchro-

nous transfer mode (ATM), native ATM, or IP over

fiber. The interconnect fabric group will be config-

ured to provide the security, performance, and

reliability needed to meet the applications require-

ments.

• The media access/resources plane deals with access

to external media interfaces, signaling transport

associated with these interfaces, and media conver-

sions/processing. It includes:

– The media gateway group, which converts

external media formats to the desired media

format for the core network. It also handles

signaling gateway functions for facility associ-

ated signaling interfaces and provides in-band

tone detection/generation capability for in-call

service invocations.

– The signaling gateway group, which may be

required for interfaces with non-facility associ-

Media access/resources

Interconnect

Services/control

IPATM

Featureservers

Applicationservers

Managementservers

Open APIs, interfaces, and protocols OSSs

Interconnect fabricsCore packet

network

Signalinggateways

Mediagateways

Media resourceservers

Nativeaccess

SS7 Lines, xDSL, modems,trunks, DLC, cable,wireless

API – Application programming interfaceATM – Asynchronous transfer modeDLC – Digital loop carrierIP – Internet protocol

OSS – Operations support systemSS7 – Signaling System 7xDSL – Any of various digital subscriber line technologies

Figure 1.7R/E† target reference architecture model.


ated signaling interfaces such as Signaling

System 7 (SS7) links from signaling transfer

points in the carrier network. The signaling

gateway may relay, tunnel, translate, termi-

nate, or screen the call and bearer signaling and

deliver this information to the appropriate fea-

ture server.

– The native access group, which provides access to

media interfaces native to the interconnect fab-

ric. It may include firewall functions for secu-

rity purposes.

– The media resource server group, which provides

shared resources for media services, including

tones, announcements, interactive voice

response (IVR), and multimedia conferencing.

7R/E Realization ExampleA possible realization of 7R/E Packet Solutions is

shown in Figure 2, which illustrates how the refer-

ence architecture model is used to guide the design of

7R/E components. The actual realizations of the 7R/E

product family are, of course, dependent on customer

needs and economic realities. In this example, the ref-

erence component groups in the services/control plane

are realized by the following components:

Call featureservers

Programmablefeature servers

Applicationservers

OneLinkManager™

Signalinggateways

Trunkaccess

gateways

Lineaccess

gateways

Cableaccess

gateways

Wirelessaccess

gateways

Multimediaresourceservers

Packetaccess

gateways

ATM/IP control and bearer switches

Service creation APIs Directory interfaces OSSs

SS7 PSTNTrunksPRI/PRA

POTSBRI/BRAADSL

Cable Wireless IPATM

Corepacket

backbone

ADSL – Asymmetric digital subscriber lineAPI – Application programming interfaceATM – Asynchronous transfer modeBRA – Basic rate accessBRI – Basic rate interfaceIP – Internet protocol

OSS – Operations support systemPOTS – “Plain old telephone service”PRA – Primary rate accessPRI – Primary rate interfacePSTN – Public switched telephone networkSS7 – Signaling System 7

Figure 2.7R/E† Packet Solutions realization example.


• Call feature servers (CFSs), which provide traditional

5ESS switch voice services over packet for end

users subscribing to these services;

• PFSs, which provide advanced multimedia services,

using third-party programmability, for end users

subscribing to these services;

• The OneLink Manager, which provides the manage-

ment servers function described in the reference

model; and

• Application servers, which include Web servers for

service access session function and mobility servers

for wireless services.

The interconnect fabric in this example is realized

by ATM/IP control and bearer switches, which provide

signaling/control connectivity between 7R/E compo-

nents as well as user/bearer connectivity between

media/resources components and the packet core

backbone network.

The media access/resources plane is realized by:

• Trunk access gateways (TAGs), which provide media

gateway functions for public switched telephone

network (PSTN) trunks, including Common

Channel Signaling System 7 (CCS7), primary

rate interface (PRI)/primary rate access (PRA),

and in-band;

• Line access gateways (LAGs), which provide media

gateway functions for “plain old telephone service”

(POTS), basic rate interface (BRI)/basic rate access

(BRA), and xDSL interfaces;

• Cable access gateways (CAGs), which provide media

gateway functions for cable modem interfaces;

• Wireless access gateways (WAGs), which provide media

gateway functions for wireless access networks;

• Packet access gateways (PAGs), which provide packet

access to media interfaces, including ATM adapta-

tion layer type 1 (AAL1), ATM adaptation layer

type 2 (AAL2), and IP;

• Signaling gateways (SGs), which provide signaling

processing and distribution functions for SS7 links;

and

• Multimedia resource servers (MMRSs), which pro-

vide shared resources for media services, includ-

ing tones, announcements, IVR, multimedia

conferencing unit (MCU), and automatic speech

recognition (ASR).

The components described above support standard

open interfaces. For example, the interfaces between

the feature servers and the media gateways support

standard H.323,3 H.248/Megaco,4,5 IP device control

(IPDC),6 and network-based call signaling (NCS)7 pro-

tocols. The interface between the CFS and the PFS

currently supports bearer-independent call control

(BICC)8 and will evolve with the standards. Simple

network management protocol (SNMP)9 is used for

element management interfaces. Transaction capabili-

ties application part (TCAP),10,11 lightweight directory

access protocol (LDAP),12 and common open policy

service (COPS)13 protocols are used whenever appro-

priate. The PFS open APIs are available for third-party

services programmability. Since all platforms support

compatible interfaces, the 7R/E system may be config-

ured for local, toll/tandem, wireline, wireless, or a

combination of these applications. Additional compo-

nents may also be added to provide more data ser-

vices—for example, virtual private networks (VPNs)

and e-commerce.

5ESS Legacy to 7R/E EvolutionFor service providers who operate legacy 5ESS

switching systems, a graceful evolution path has been

identified for migrating legacy lines and trunks to sup-

port 7R/E services, as shown in Figure 3. The 5ESS

system evolution approach reuses the same 7R/E com-

ponents introduced earlier to convert existing legacy

switches for next-generation use.

As shown in Figure 3, 7R/E components are

added to an existing 5ESS switch to migrate traffic

from the 5ESS circuit-switched world to the 7R/E

packet-switched world. An interworking gateway

(IWG), similar to the TAG function described earlier, is

used to convert media and signaling from circuit

switched to packet switched. The 7R/E feature servers

provide services for traffic migrated from the 5ESS

world to take advantage of new services available in

the packet world. The 7R/E OneLink Manager, which

has an OAM&P interface to the 5ESS system, provides

a unified interface to external OSSs. The service

provider, depending on demand, may control the rate

of migration from the legacy circuit-switched world to

the new world of packet networks.


A Component-Based Service Architecture for the7R/E PFS

The 7R/E PFS service architecture addresses the

complexities inherent in providing converged

voice/data services by leveraging the guiding princi-

ples. The service architecture is component based; its

piece parts consist of service components, which plug

into the service framework and the OAM&P frame-

works. New services may be added by plugging new

components into the frameworks.

Complexity in Services PlatformsThe complexity of development and deployment of

services in a telecommunications network contributes

to the cost and the time-to-market delays of introducing

new services. Developing services for a converged

voice/data network faces increased complexity on sev-

eral fronts. Traditional approaches to service develop-

ment and deployment may have difficulty keeping up

with the fast-paced world of packet technology. The PFS

component-based service architecture embraces the

new technology trends to reduce the complexities of

providing converged voice/data services.

Sources of complexity in the traditional services

platform. A traditional switching system is a closed

system provided by an equipment provider. A pre-

Packet domain

Callprocessing

(SMP)

Administrationmodule

Fabric (CM and SM)

Line/trunkunits (SM)

5ESS® legacy

LinesTrunks

OneLinkManager™

OSSs

Corepacket

backbone

Inter-workinggateways

Signalinggateways

Mediagateways

Multimediaresourceservers

Packetaccess

gateways

SS7 Lines, trunks,cable, ADSL

IPATM

Programmablefeature servers

Call featureservers

ATM/IP control and bearer switches

Servicecreation APIs

ADSL – Asymmetric digital subscriber lineAPI – Application programming interfaceATM – Asynchronous transfer modeCM – Communications moduleIP – Internet protocol

OSS – Operations support systemSM – Switching moduleSMP – Switching module processorSS7 – Signaling System 7

Figure 3.7R/E™ Packet Solutions with 5ESS® evolution.


defined set of IN triggers to IN service control points is

the only door of opportunity for the service provider

to develop new services. The equipment provider must

go through a relatively long and complex develop-

ment cycle to provide new services on the switch. The

software elements are typically tightly coupled, sharing

global data structures, with an inadequate degree of

separation between functional entities such as services,

transport, and access. There are often multiple call

models deployed on the switch—one for each access

type, such as analog lines, integrated services digital

network (ISDN) lines, analog trunks, and ISDN trunks.

The services and the interfaces to access and transport

may be embedded inside each call model. Adding a

new service may require separate development and

testing on multiple call models. Changes to a data

structure may require coordination across multiple

software modules and global recompilations to ensure

a consistent software image. Some side effects of tradi-

tional approaches include being locked into a single

solution for a given switch, making it difficult to follow

new technology curves. Continuing along the tradi-

tional path for services development in the face of the

explosions of access types, transports, and standard

protocols may become increasingly difficult.

Sources of complexity in the new converged

voice/data services platform. The new packet-based

telecommunications nodes and networks provide an

opportunity to develop a converged voice/data services

platform. The new platform must handle a growing list

of access types, including cable, xDSL, and wireless, in

addition to analog and ISDN. The new multimedia pro-

tocols, such as H.323 and session initiation protocol

(SIP),14 support intelligent endpoints, which may have

multiple simultaneous packet streams for voice, data,

and video. Protocol standards for the telecommunica-

tions industry have mushroomed. There are new stan-

dards for the interface between separate services

processors (feature servers) and transport processors

(LAGs and TAGs). The new packet networks must

interwork with the legacy PSTN, its protocols, and its

IN servers. Added to these complexities is the desire to

support third-party programmability on feature servers.

There is also much uncertainty regarding what the

new services will be, how they will manifest them-

selves on the new packet-based nodes and networks,

and what the future capabilities of intelligent end-

points will be. Designing the packet-based services net-

work in the face of such complexity and uncertainty is

daunting. A vision of these future services includes

“anywhere, any media services.” Subscribers will be

able to access their personal services anywhere in the

world and adjust to the media capabilities (voice, data,

or video) of their endpoints (PC, FAX, wireless, analog,

or ISDN). They will expect “Follow me” services that

locate them and business services (closed user group,

VPN, or CENTREX) when they are working from

home or on the road. Service providers are requesting

a service architecture that supports multimedia ser-

vices and third-party programmability to allow flexible

configuration and technology upgrades. They want

programmable OAM&P characteristics, including pol-

icy management, and a unified data view of sub-

scribers and services.

Reducing Complexity in the Converged Voice/DataServices Platform

The service architecture will reduce complexity in

providing converged voice/data services, enabling

third-party programmability, and interworking with

legacy services by using software technologies and

techniques recommended in the earlier section on

guiding principles.

Leveraging service architecture concepts from

the telecommunications industry. Standards bodies

and consortia within the telecommunications industry

have defined functional entities and standard protocols

between the functional entities for next-generation,

multimedia, packet networks. The functional entities

are designed as components, which may be developed,

deployed, and evolved independently to counteract the

complexity of traditional, tightly coupled software

elements.

The ITU-T has recommended a unified functional

model,15 which separates services signaling from

transport signaling. H.248/Megaco has been recom-

mended as the protocol between services and trans-

port. This separation has been reflected in the SS7

ISDN user part evolution to BICC. The H.323 suite of

protocols has been recommended to support multi-

media telecommunications. The IETF has developed


SIP to address multimedia telecommunications across

IP networks. It is anticipated that both H.323 and SIP

clients will proliferate on intelligent endpoints.

The separation of services from transport is directly

reflected in the components of the service architecture,

with feature servers to provide services and media gate-

ways to provide transport. Several protocols are cur-

rently being standardized, and the ability to access

services using multiple protocols is essential. On the

one hand, standard protocols reduce complexity in

building interworking piece parts. On the other, the

industry has not settled on a single standard; two or

three protocols are likely to be popular. The complexity

of interworking between clients of different protocols,

such as H.323 and SIP, must be addressed. To contain

the impact of this complexity, the components are

designed to seamlessly support several protocols with-

out requiring rewrites of the core service logic.

The Telecommunications Information Networking

Architecture Consortium (TINA-C)16 defines entities

and interfaces for a next-generation converged

voice/data service architecture. Its functional decom-

position for high-level components reduces complexity

for supporting services for intelligent endpoints among

multiple telecommunications business players. As

shown in Figure 4, the entities include:

• The access session, which provides the interface

between the subscribers and the retailer. The tradi-

tional interface for analog phones is dial tone. For

intelligent endpoints with multimedia capabilities,

a more human-friendly interface is desirable. The

access session may provide a Web browser inter-

face to the endpoint. The PC client may select ser-

vices offered by a particular service provider

Programmable feature server

Intelligentendpoint

Application server

*Access session

Webbrowser for

service access

Application server Directories

ServiceYellow Pages

Location services

*Broker

*Servicesession

Core service logic

*Connectioncontrol

Media gatewaysPacket network

TINA-C – Telecommunications Information Networking Architecture Consortium

*TINA-C entities

Figure 4.TINA-C entities in the service architecture.


(optionally through a broker) by clicking on a

screen. The access session then starts up the appro-

priate service session application.

• The broker, which allows subscribers to learn about

and locate desired services, including price and

quality of service (QoS). Government regulations

may allow subscribers to access services from mul-

tiple service providers, which increases complexity.

The broker addresses this complexity by providing

a uniform and general way for any service

provider’s services to be offered to the subscribers.

• The service session, which runs the service chosen

by the subscriber. It reduces the complexity of

modeling the components involved in a call,

which may involve multimedia, multiple parties,

and multiple access types. It requests connections

through connection control. It knows about the

participating parties in the session and the

resources in use for the session (for example,

video conferencing bridge).

Note that the access session Web-browser inter-

face reduces complexity for the subscriber who wants

to invoke a service. Rather than relying on dial tone

and memorized dialed digits to communicate with the

telecommunications service provider, the exact service

and special parameters (such as cost and QoS) may be

chosen by reading about the service in a human lan-

guage, on screen, then clicking on the corresponding

buttons. It may also be more straightforward to offer

new services by adding them to a browser interface,

instead of specifying and provisioning new dialed

codes in every switch in the network. Routing to a

person may consist of choosing his/her name from the

directory with a click instead of memorizing his/her

phone numbers (home, work, and cell phone). The

“Follow me” services will take care of alerting the per-

son, wherever he or she happens to be.

Reducing the complexity of providing service

components across DPEs. The converged voice/data

7R/E service architecture will achieve reliability, scal-

ing, and load balancing by distributing components

across processors on the packet network. To reduce

the complexity of a DPE and enable a piece-part, mix-

and-match services component architecture, the fol-

lowing techniques will be used:

• The component distribution middleware will support

location transparency for computational objects,

providing an interface between objects of multiple

languages (such as C, C++, or Java*) and enabling

seamless deployment of service components

across PFS and application server processors.

Location transparency reduces the complexity of

developing service components for a DPE. The

components may reference each other symboli-

cally and do not need to know if the referenced

component is local or remote.

• The global namespace (a symbolic naming scheme

for components) may be represented by a tree

structure, such as a hierarchical file system, in

which distributed components appear as file

names. Just as Web pages are addressed using uni-

form resource locators (URLs), the namespace

addresses objects by relative path names. This is a

powerful and flexible model, which establishes

relationships based on location in the file system.

New service components may be added on the fly

to the global namespace, thus becoming instantly

available for use. The component distribution and

global namespace middleware provides a great

advantage to simplifying service development,

since the distribution of objects is handled invisi-

bly. The service logic does not need explicit point-

ers to invoke methods on objects; it can refer to an

object in a generic, symbolic fashion. The middle-

ware, not the service logic, takes care of the details.

• The component distribution middleware uses

generic data marshaling for messages between com-

ponents. This contrasts with explicit remote

method invocation to access objects, used on a

conventional platform, which requires ad hoc

implementation of interfaces and implementation-

dependent data marshaling of arguments, which

must be synchronized manually. Generic data

marshaling passes messages to components with

keyword/value pairs for the data parameters.

These keyword/value pairs allow the addition of

new parameters for new services to existing mes-

sages in an upwardly compatible fashion. Making

upwardly compatible changes means adding new

methods or data parameters to existing methods


but not deleting existing data parameters or meth-

ods. Unchanged code will continue to operate as

before. Each component specifies the keywords it

is looking for, and the rest are ignored. Generic

data marshaling even works between objects writ-

ten in different programming languages. This capa-

bility, combined with full distribution of objects

across the network and location transparency of

objects, allows objects that were developed inde-

pendently to interwork by invoking each other’s

API. This technique reduces the complexity of

third parties independently deploying useful ser-

vices by reducing the need to synchronize code

changes and retest existing services.

Techniques for independent development and

deployment of service components. One of the most

powerful techniques for reducing complexity in the

service architecture and supporting third-party pro-

grammability is utilizing technologies that enable inde-

pendent development and deployment of service

components. In addition to the DPE middleware, the

PFS service architecture is designed for software update

capabilities. New services can be added to the live sys-

tem, and existing services can even be modified on the

live system, provided that the changes are imple-

mented in an upwardly compatible fashion. Service

components can plug into the services and OAM&P

frameworks. The service deployment can occur with-

out blocking new arriving calls or disrupting existing

calls. Some new services may be registered with the

broker, where they are immediately available for use.

The following techniques reduce the complexity of ser-

vice component development and deployment.

The first technique for reducing complexity is writ-

ing components in object-oriented programming languages.

Object-oriented languages support the encapsulation

of data inside objects, reducing the need for global

data. The public methods of the object provide APIs

that can be invoked by other objects. The object-

oriented paradigm provides a level of support for loose

coupling of objects through the publicly declared inter-

faces and the private implementations within objects.

It is a powerful tool for skillful programmers to

develop independent functional entities with clean

separation between services, transport, and access.

Using objects can take the place of hand-mixing logic

and embedding decision-making in switch statements

with multiple cases. Instead, invocation of logic is

external and automatic, based on the typing of the

objects themselves.

Object-oriented programming languages may use

static binding or dynamic binding. The 7R/E service

architecture, which provides language interworking

through its component distribution middleware,

allows programmability and service development

using both kinds of languages.

Languages with static binding, such as C++, are

used for real-time sensitive code, which must be exe-

cuted as quickly as possible to allow efficient through-

put for message handling. Static binding means that the

language has a virtual memory address paradigm of

pointers and offsets inside its object descriptions,

which are computed at compile time. The disadvan-

tage of static binding is that deploying new service

components used in a given process requires recompil-

ing the process image, taking the process off line,

relinking, and reloading the updated process. This

update procedure must be carefully orchestrated to

avoid affecting calls in progress or new call requests

coming in to the system.

Languages with dynamic binding, such as Java,

are used for flexible, run-time customizable services.

Java has been very popular for developing and deploy-

ing Web-based Internet applications. Dynamic lan-

guages support incremental compiling and dynamic

loading of new and changed objects, which reduces

the complexity of programming new services even

more. Dynamic software update capabilities and incre-

mental evolution of service components and APIs

empower run-time, third-party programmability of

components. Dynamic binding of objects greatly

reduces the complexity involved in evolving services

by eliminating the need for global recompilations and

generic retrofits.

The PFS DPE middleware and open APIs support

programmability with both static and dynamic object-

oriented languages. The PFS allows service provider

programmability of extensions to the C++ code for

high real-time sensitivity. It allows third-party pro-

grammability of high-value service components writ-


ten in either static or dynamic languages deployed

across the open APIs.

API extensibility, a second complexity-reducing

technique, supports third-party programmability and

independent service logic development. API extensibil-

ity between components is achieved in an upwardly

compatible fashion. In traditional switching nodes, the

service provider must request an API change (for mes-

sages based on IN triggers, for example), then wait for

the equipment provider to go through a development

cycle to produce the new API. Extensible APIs

empower the service provider to extend them at will.

The call model is designed to reduce complexity as

well. It is canonical, access neutral, and transport neu-

tral. External signaling protocols (such as H.323, SIP,

and BICC) are converted into the canonical messages

of the call model’s internal protocol by the protocol-

interoperability components. Internally, the canonical

call model forwards every event to the service logic to

take appropriate actions. The canonical call model

seamlessly supports handling calls between endpoints

that use different protocols, such as calls between

H.323 clients and SIP clients. The core service logic is

unaware of the different protocols; it receives events

and requests actions. The protocol-interoperability

components translate generic requests into protocol-

specific ones for outgoing connection-control messages

from the call model to a gateway or resource server

(such as a TAG, LAG, or MMRS).

Service logic components provide yet another means

of reducing complexity. The PFS service logic reduces

complexity by providing multimedia services through

a service framework, which utilizes core service logic

components to support any user, anywhere, with any

access media. The core service logic is access and trans-

port neutral; it interacts with the canonical call model,

which shields service logic from external protocol

details. Third parties may program service components

and link them into the service framework. Service

logic is modeled as loosely coupled components. A ser-

vice logic component consists of a service class that

inherits middleware capabilities through base classes,

which enable a class to plug into the underlying ser-

vice framework and interact in a generic fashion with

the OAM&P frameworks.

Polymorphism is an object-oriented technique that

can be leveraged in writing access- and transport-

neutral service components, which can evolve in an

upwardly compatible fashion. With polymorphism,

components make requests of a general class, and the

specific subclass of the component invoked customizes

its behavior transparently. The core service logic

receives events from the canonical call model through

the service session. It responds with a generic request

such as “Alert subscriber.” Customization based on

user preferences and endpoint capabilities is then

applied to the result using polymorphism. For an ana-

log phone, “Alert subscriber” may become “Ring

phone” or “Apply call waiting tone.” For a PC soft-

phone, the result may become “Pop up window,” and

the user may accept the call by a mouse click. The con-

nection control layer formats the appropriate mes-

sages, using the appropriate protocol, to make

connection requests of the media gateway. If new

endpoint types are developed, they do not affect the

core service logic. Figure 5 shows the relationships

between components of the service architecture.

Finally, OAM&P programmability for service compo-

nents reduces complexity. The OneLink Manager pro-

vides seamless integration of all the feature servers in

the network. “Smart provisioning” through the

OneLink Manager hides feature-server-specific details

from the administrator. Billing and measurements

between the feature servers are integrated to provide a

single system view. OAM&P frameworks allow the

service components to generically plug into OneLink

Manager policy, maintenance, provisioning, and

billing. The need to write custom OAM&P code for a

new service is greatly reduced. If a new service is

developed for the 7R/E system, it inherits from base

classes, which automatically plugs it into the service

and OAM&P frameworks. A subscriber may self-

subscribe to the new service through a Web-based

interface or choose the service on a per-use basis

through the broker. The OAM&P agents include:

• Policy agents, which allow service logic to interact

with the policy server; they grant, deny, or cus-

tomize treatment for a given request. The policy

agents also provide protection for third-party ser-

vices. They can control component behavior and


specify privileges and restrictions for central pro-

cessing unit (CPU) utilization, resource usage, and

MMRS access. The service provider may deploy a

policy agent to govern the behavior of a new third-

party service.

• Maintenance agents, which allow service compo-

nents to send and receive events to and from the

maintenance manager to ensure systems integrity

and fault management.

• Provisioning agents, which allow service compo-

nents to interact with the directory coordinator to

retrieve data from databases. When a new service

is developed, a small program is written to teach

the directory coordinator from which databases to

retrieve the data and how to retrieve it. The data-

base details, including their locations and access

methods, are then hidden from the applications.

• Billing agents, which allow service components to

report events to the billing manager. The extensi-

ble billing manager allows new data and new

billing record types to be specified by third-party

developers.

Interworking with legacy systems and applica-

tion servers. The basic strategy for interworking with

legacy systems and components is to largely leave the

legacy systems as they are and perform the interwork-

ing on the converged voice/data packet nodes. These

nodes will interface to the PSTN through media gate-

ways for both incoming and outgoing calls. The

canonical call model in the PFS will interwork SS7 sig-

naling endpoints with non-SS7 signaling endpoints.

The PFS will use SS7 TCAP messages to interface with

existing services running on the IN service control

points. As the IN service control points evolve to sup-

port new open APIs such as Java APIs for integrated

networks (JAIN*),17 Parlay,18 and Extensible Markup

Language (XML),19 the PFS will interface to them with

the newer, more powerful protocols.

The PFS will also interface to new application

servers using next-generation protocols such as SIP,

Policy Directorycoordinator

Billing

Maintenance

Core servicelogic

Servicesession

BICC protocolinteroperability

H.323 protocolinteroperability

SIP protocolinteroperability

Endpointagent

BICC – Bearer-independent call controlOAM&P – Operations, administration, maintenance, and provisioningSIP – Session initiation protocol

OAM&PService componentsCall controlGateway interfaces

Canonicalcall model

Figure 5.Components of the service architecture.


JAIN, Parlay, and XML. The extensibility of XML lends

itself well to developing third-party applications.

Application servers may include Web servers, SIP

servers, and specialized MMRS servers.

The CFS (based on 5ESS call control) separates

signaling from transport for 5ESS services over packet.

The CFS and the PFS may hand off calls to each other

through BICC signaling. The hand-off model creates a

clean, although limited, mechanism for involving both

feature servers in a single call. Endpoints that desire

traditional voice services over IP will be homed on the

CFS. Endpoints that are multimedia enabled will be

homed on the PFS.

In the future, the PFS may interface to other fea-

ture servers through a “wrapper,” which provides an

interworking function between the servers at a finer

level of granularity than the hand-off model. It may be

useful for leveraging existing CFS services for new

endpoints, such as SIP clients, and for interworking

those services with multimedia capabilities on the PFS.

ConclusionThree major aspects of complexity visible to the

service provider—service introduction complexity,

equipment maintenance and upgrade complexity, and

system management complexity—have been system-

atically addressed in the 7R/E target architecture and

service architecture. The guiding principles for reduc-

ing complexity presented in this paper have been

translated into actionable principles that guided these

architectures and are being realized in various 7R/E

Packet Solutions. In summary:

• Complexity is reduced in the 7R/E architecture by

converging services for voice and data onto the

same network, managed by the integrated

OneLink Manager.

• The complexity of mixing and matching compo-

nents is reduced in the 7R/E Packet Solutions by

separating service, control, signaling, and transport

functions into separate architecture components

linked by standard protocols or open APIs.

• Multiple vendors may contribute services software

through open APIs, service frameworks, and

OAM&P frameworks, which provide the 7R/E sys-

tem with a level of flexibility and programmability

not available in traditional switching systems.

• Protocol-interoperability modules, a canonical call

model, and access-neutral core service logic reduce

the complexity of interworking calls among diverse

endpoints and support subscriber access to services

across any media.

• Interactions with legacy systems across well-

defined interfaces contain the complexity of com-

munications between the packet networks and the

circuit-switched networks.

The result is an enabling of voice/data convergence in

the 7R/E Packet Solutions with advanced service

capabilities.

*TrademarksJAIN and Java are trademarks of Sun Microsystems,

Inc.

References1. Multiservice Switching Forum, “Multiservice

Switching Forum System Architecture Implemen-tation Agreement,” MSF-ARCH-001.00-STRAW,Dec. 1999, <http://www.msforum.org/>.

2. International Softswitch Consortium, FAQs,<http://www.softswitch.org/FAQs/index.html>.

3. International Telecommunication Union,“Packet-Based Multimedia CommunicationsSystems,” ITU-T Rec. H.323, Feb. 1998,<http://www.itu.int/>.

4. International Telecommunication Union,“H.248/Megaco Protocol,” ITU-T Draft Rec.H.248, V. 16, Feb. 2000, <http://www.itu.int/>.

5. F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Rayhan, B. Rosen, and J. Segers, “MegacoProtocol,” IETF Internet-Draft, Feb. 2000,<http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-07.txt>.

6. E. Zimmerer, “Internet Protocol Device Control,”Revision 0.15, Level3 Communications, Jan. 29,1999.

7. Cable Television Laboratories, Inc., “PacketCable†Network-Based Call Signaling (NCS) ProtocolSpecification,” CableLabs Interim SpecificationPKT-SP-EC-MGCP-102-991201, Dec. 1999,<http://www.packetcable.com/specs/pkt-sp-ec-mgcp-I02-991201.pdf>.

8. International Telecommunication Union,“Bearer-Independent Call Control (BICC)Protocol,” ITU-T Draft Rec. Q.BICC, Feb. 2000,<http://www.itu.int/>.

9. J. Case, M. Fedor, M. Schoffstall, and J. Davin,“Simple Network Management Protocol(SNMP),” IETF RFC1157, May 1990,


<http://www.ietf.org/rfc/rfc1157.txt>.10. International Telecommunication Union, “Func-

tional Description of Transaction Capabilities,”ITU-T Rec. Q.771, June 1997, <http://www.itu.int/>.

11. International Telecommunication Union, “Guide-lines for Using Transaction Capabilities,” ITU-TRec. Q.775, June 1997, <http://www.itu.int/>.

12. W. Yeong, T. Howes, and S. Kille, “LightweightDirectory Access Protocol (LDAP),” IETF RFC1777,Mar. 1995, <http://www.ietf.org/rfc/rfc1777.txt>.

13. D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry, “The COPS (CommonOpen Policy Service) Protocol,” IETF RFC 2748,Jan. 2000, <http://www.ietf.org/rfc/rfc2748.txt>.

14. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: Session Initiation Protocol,”IETF RFC2543, Mar. 1999, <http://www.ietf.org/rfc/rfc2543.txt>.

15. International Telecommunication Union, “GeneralAspects for the Development of Unified SignalingRequirements,” ITU-T Technical Report TRQ.2001,Mar. 1999, <http://www.itu.int/itudoc/itu-t/rec/q/q1000up/qsup7.html>.

16. Telecommunications Information NetworkingArchitecture Consortium, “Service Architecture,”V. 5.0, June 18, 1997, <http://www.tinac.com/specifications/specifications.htm>.

17. Sun Microsystems, Inc., “JAIN† APIs forIntegrated Networks,” <http://java.sun.com/products/jain/index.html>.

18. The PARLAY Group, Specifications,<http://www.parlay.org/products.htm>.

19. World Wide Web Consortium, “ExtensibleMarkup Language (XML),” V. 1.0, W3C Rec.10, Feb. 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.

(Manuscript approved May 2000)

JANET R. DIANDA, a member of technical staff in theSwitching Architecture, Performance, andSystems Engineering Department ofLucent’s Switching Solutions Group inNaperville, Illinois, holds an M.S. degree incomputer science from the Illinois Institute

of Technology in Chicago. Ms. Dianda is currentlyworking on the 7R/E† programmable feature serverand converged voice/data networks architecture.

BIN-WEN HO is a distinguished member of technicalstaff in the Switching Architecture, Perfor-mance, and Systems Engineering Depart-ment of Lucent’s Switching Solutions Groupin Naperville, Illinois. He received a B.S. fromCheng-Kung University in Taiwan and an

M.S. from Stanford University in Palo Alto, California,both in electrical engineering, as well as a Ph.D. in elec-trical and computer engineering from the University ofWisconsin in Madison. Dr. Ho currently works on defin-ing architectural directions for future telecommunica-tions systems and networks, and for next-generationswitching products.

KRISTIN F. KOCAN is a technical manager in the SwitchingArchitecture, Performance, and SystemsEngineering Department of Lucent’s Switch-ing Solutions Group in Naperville, Illinois.She holds a B.S. in engineering and an M.S.in information engineering from the

University of Illinois in Chicago as well as a Ph.D. in systems engineering from Southern Illinois University inCarbondale. Dr. Kocan leads the Switching ArchitectureEvolution Planning Team and is responsible for switch-ing system architecture evolution. ◆

Documents

Reducing complexity for converged voice/data networks and services architecture