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
58 Bell Labs Technical Journal ◆ April–June 2000
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
Bell Labs Technical Journal ◆ April–June 2000 59
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
60 Bell Labs Technical Journal ◆ April–June 2000
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.
Bell Labs Technical Journal ◆ April–June 2000 61
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.
62 Bell Labs Technical Journal ◆ April–June 2000
• 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.
Bell Labs Technical Journal ◆ April–June 2000 63
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.
64 Bell Labs Technical Journal ◆ April–June 2000
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
Bell Labs Technical Journal ◆ April–June 2000 65
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.
66 Bell Labs Technical Journal ◆ April–June 2000
(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
Bell Labs Technical Journal ◆ April–June 2000 67
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-
68 Bell Labs Technical Journal ◆ April–June 2000
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
Bell Labs Technical Journal ◆ April–June 2000 69
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.
70 Bell Labs Technical Journal ◆ April–June 2000
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,
Bell Labs Technical Journal ◆ April–June 2000 71
<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. ◆