United States Patent [19]
`La Porta et al.
`
`llllllllllllllllllllllIlllllllllllllllllllIllllllllllllllllllllllllllllllll
`USOO5434852A
`[11] Patent Number:
`5,434,852
`[45] Date of Patent:
`Jul. 18, 1995
`
`[54] DISTRIBUTED PROCESSING
`ARCHITECHTURE FOR CONTROL OF
`BROADBAND AND NARROWBAND
`COMMUNICATIONS NETWORKS
`[75] Inventors:
`Thomas F. La Porta, Thornwood,
`N.Y.; Malathi Veeraraghavan,
`Atlantic Heights, NJ.
`AT&T Corp., Murray Hill, NJ.
`298,287
`Aug. 31, 1994
`
`Assignee:
`Appl. NO.:
`Filed:
`
`[73]
`[21]
`[22]
`
`[63]
`
`Related US. Application Data
`Continuation of Ser. No. 82,656, Jun. 25, 1993, aban
`cloned.
`
`Int. Cl.6 ....................... .. H04J 3/12; H04L 12/16
`US. Cl. ................................... .. 370/582; 370/62;
`370/681; 370/1101; 379/157; 379/165
`Field of Search .................. .. 370/581, 58.2, 58.3,
`370/60, 60.1, 62, 68.1, 110.1; 379/94, 157, 158,
`165, 202
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`L531
`
`[56]
`
`4,896,319 l/ 1990 Lidinsky et a1. .................... .. 370/60
`5,036,318 7/1991 Bachhuber et a1
`.. 370/851 X
`
`5,218,602 6/1993 Grant et a1. . . . . . . . . . .
`. . . . .. 370/582
`5,291,479 3/1994 Vaziri et a1. ..................... .. 370/582
`
`OTHER PUBLICATIONS
`C. Woodworth, M. J. Karol, R. D. Gitlin, “A Flexible
`Broadband Packet Switch for a Multimedia INtegrated
`Network”, Proceedings International Conference on
`
`1991, Denver, pp.
`
`Communications, Jun. 23-26,
`32.1-32.8.
`I. Faynberg, L. R. Gabuzda, M. P. Kaplan, M. V.
`Kolipakum, W. J. Rowe, A. L. Waxrnan, “The Support
`of Network Interworking and Distributed Context
`Switching in the IN Service Data Function Model”,
`2nd International Conference on Intelligence in Net
`works, France, Mar., 1992, pp. 11-16.
`S. Minzer, “A Signaling Protocol for Complex Multi
`media Services”, IEEE Journal on Selected Areas in
`Communications, vol. 9, No. 9, Dec. 1991. Pp.
`1383-1394.
`M. Fukazawa, M. Wakamoto and M. W. Kim, “Intelli
`gent Network Call Model for Broadband ISDN”, ICC
`1991, pp. 964-—968.
`PrimaryY Examiner-Melvin Marcelo
`Attorney, Agent, or Firm-John A. Caccuro
`[57]
`ABSTRACT
`A distributed, server-based communications network
`architecture delivers broadband and narrowband com
`munications services. In the architecture, various tradi
`tional call processing functions, such as switching fabric
`or channel control, call control, and connection control
`are separated into distinct application processes with
`clearly de?ned interfaces for communications between
`these application processes. Those distinct application
`processes may be implemented in separate physical or
`logically partitioned nodes. The well-de?ned interfaces
`allow communications among: a) physical or logically
`partitioned nodes within a network and b) physical or
`logically partitioned nodes of other networks.
`
`12 Claims, 5 Drawing Sheets
`
`520
`‘ DATA RETRIEVAL
`me VIRTUAL PRIVATE
`INFORMATION SERVER
`519
`NETWORK SERVER
`52L
`~ SERVICE CONTROL
`- SERVICE CONTROL
`i______.
`
`521
`
`522
`“
`TELESERVER
`SERVlC
`ONTRO
`_____i
`1
`
`SERVICES
`DATABASE
`
`517
`
`516
`
`CALL
`SERVERS
`
`5“
`
`CALL
`CONTROL
`
`sriz
`
`504
`
`CONNECTION
`SERVERS 505
`
`CONNECTION
`CONTROL
`
`see
`1
`
`507
`
`an
`1
`
`5m
`\
`
`CHANNEL
`SERVER
`
`CHANNEL
`CONTROL
`
`CHANNEL
`SERVER
`
`532 \
`CHANNEL
`CONTROL
`
`law
`
`510
`
`l
`509
`
`524
`“ FREEPHONE
`SERVERS
`SERVICE
`ONTRO
`
`525~
`
`CPE
`
`l
`513
`
`514
`,\
`
`CPE
`
`Bright House Networks - Ex. 1016, Page 1
`
`

`
`US. Patent
`
`July 18, 1995
`
`Sheet 1 of 5
`
`5,434,852
`
`FIG. 1
`
`OBJECT
`
`IDENTIFYING ATTRIDuTEs
`
`NON-IDENTIFYING ATIRIDuTEs
`
`cALL
`
`CONNECTION
`
`CHANNEL
`
`ROUTE
`
`CALL CONNECTION MAPPING
`
`CRV
`VCCI
`VCI TRANSLATION TABLE ENTRY CHANNEL IDENTIFIER
`cNANNEL IDENTIFIER
`CRV
`USER IDENTIFIER
`(SERVER IDENTIFIER)
`
`usER-cALL-INTERAcTIoN
`(3ERVER_CAU__INTERACHQN)
`
`CALL REFERENCE vALuE SERVER IDENTIFIERs(R)
`USER IDENTIFIERs(R)
`coNNEcTIoN PERFoRNANcE AITRIDuTEs
`VIRTUAL CHANNEL
`CONNECTION IDENTIFIER AAL PROTOCOL TYPE(BEARER cAPABILITY)
`DIREcTIDNALTIY AND SYMMETRY
`usER IDENTIFIERs(R)
`SWITCH IDENTIFIERs(R
`CHANNEL IDENTIFIERs R)
`ATN LAYER BEARER CAPABILITY
`CHANNEL PERFORMANCE AITRIBUTES
`
`USER IDENTIFIER
`swITcN IDENTIFIER
`Two PORT NUMBERS
`VPCI/VCI
`ROUTE NUMBER
`
`PERFORMANCE ATTRIBUTES
`BANDNIDTH
`DIREcTIoNALIIY AND sYNNETRY
`USER IDENTIFIERs(R)
`swITcN IDENTIFIERs(R)
`CHANNEL IDENTIFIERS(R)
`
`VCCI(R)
`
`VCCIs
`CONNECTION ATTRIBUTES
`SERVICE IDENTIFIERS
`SERVICE-SPECIFIC PARAMETERS
`USER IDENTIFIERS
`USER-SPECIFIC PARAMETERS
`DIVERGENCE FLAG
`SYNCHRONIZATION FLAG
`NEGOTIATION OPTIONS
`MODIFICATION MANDATORY 0R OPTIONAL
`ADD USER FLAG
`DELETE USER FLAG
`CHANGE 003 OR BW FLAG
`SUCCESS FLAG
`FAILURE FLAG
`
`Bright House Networks - Ex. 1016, Page 2
`
`

`
`US. Patent
`
`July 18, 1995
`
`Sheet 2 of 5
`
`5,434,852
`
`FIG. 2
`CALL
`5U
`
`‘SERVERS __
`1
`21 1
`
`CHANNEL
`
`CHANNEL
`
`Ci“
`
`l
`CALL
`CHANNEL
`206
`
`209
`1
`
`SW
`(gm )
`USER --L'-' " "L- "- "
`
`'0' "
`
`¢
`
`_
`
`‘
`
`ZQROUTE
`“ ~
`
`‘
`I
`201
`
`/
`/
`202 V 203
`207
`
`208
`
`USER _.._
`
`Bright House Networks - Ex. 1016, Page 3
`
`

`
`US. Patent
`
`July 18, 1995
`
`Sheet 3 of 5
`
`5,434,852
`
`3054mm) (connecnou T306
`1(2) x p
`1(2) x 'p
`
`307
`
`30a
`
`CALLCONN NAP
`CONNECTION
`ROUTE
`
`>
`
`CONNECTION SERVER
`
`Bright House Networks - Ex. 1016, Page 4
`
`

`
`US. Patent
`
`July 18, 1995
`
`Sheet 4 of 5
`
`5,434,852
`
`13m , an @
`22% gag: §§ 255% g? as;
`
`
`MZOEE , 22E; , 25E: :2 , E25 :2; i J 552:; ) 1 5
`
`in NS own m. .QFW
`
`2m 26
`
`/ an , 4
`
`SE28
`
`
`
`an $55
`
`zoEmzzoQ
`225528
`
`f
`
`
`$2M , E g 525 @255 é
`
`,, gum
`
`
`:0 “ ‘flu/wig] v 5
`
`mom in mom
`
`
`
`:m an gm
`
`:
`
`\ w
`
`Bright House Networks - Ex. 1016, Page 5
`
`

`
`US. Patent
`
`July 18, 1995
`
`Sheet 5 of 5
`
`5,434,852
`
`88
`
`_ _
`
`u. 226M228
`d 55%
`
`82 cm
`
`u z
`
`
`r] :6
`_ 5.5%
`5.2 *
`
`—
`
`Ezmm
`
`228M228
`
`M.
`
`2;
`ss\ m : vEoEuz
`
`saw 55%
`
`a? , :6,
`
`E? __ a;
`
`I
`
`205F228
`
`2G
`
`226M228
`diam
`is
`
`Bright House Networks - Ex. 1016, Page 6
`
`

`
`1
`
`5,434,852
`
`DISTRIBUTED PROCESSING ARCHITECHTURE
`FOR CONTROL OF BROADBAND AND
`NARROWBAND COMIVIUNICATIONS
`NETWORKS
`
`This application is a continuation of Ser. No.
`08/082,696, ?led on Jun. 25, 1993, abandoned.
`
`TECHNICAL FIELD
`This invention relates to communication systems.
`More speci?cally, this invention relates to communica
`tions systems supporting broadband and narrowband
`voice, data and video communication services.
`
`l0
`
`15
`
`25
`
`30
`
`BACKGROUND
`Over the years, advances in communications net
`works architecture have allowed new telecommunica
`tions services to be offered by communications carriers.
`For example, the introduction of a separate signaling
`subnetwork within a communications network paved
`the way for the introduction of services, such as soft
`ware-de?ned network and freephone services. Like
`wise, communications architectures have changed in
`response to needs of the marketplace for particular
`telecommunications services. For example, persistent
`requests for customized services from subscribers were
`the driving force behind the creation of a service
`independent capabilities-based architecture called “In
`telligent Network” (IN) architecture. The IN architec
`ture represents an evolutionary step from the traditional
`communications architecture. More speci?cally,
`changes were introduced in the traditional architecture
`to meet the requirements of the IN-based services. Of
`particular importance in the IN-architecture is the sepa
`35
`ration of the service control functions from the trans
`port control functions. However, one of the drawbacks
`of the IN architecture is that all network nodes must be
`capable of, and may be required to perform, loosely
`coupled functions aimed at different objectives i.e.,
`there is a bundling of distinct control functions, such as
`call control, connection control and channel control.
`As a result, introduction of new services associated with
`one of these functions require changes to software that
`effects all of these functions and that is loaded in these
`network nodes.
`With the impending standardization of Broadband
`Integrated Services Digital Network (B-ISDN), an
`emerging class of new services is anticipated to be of
`fered by carriers and third party vendors. Those ser
`vices include high bandwidth multimedia, multipoint
`applications, interactive video services, bulk data re
`trieval and archiving, messaging and distributional ser
`vices. Associated with these new services are switching,
`connection, and signaling requirements whose complex
`ities are unparalleled in today’s communications net
`works. Requirements that have been identi?ed include
`user/server negotiation requirements, dynamic modi?
`cation of active connections, recognition of need for
`special resources (such as protocol converters and brid
`ges), to name a few.
`From the foregoing, it is clear that today’s communi
`cations network architectures are ill-suited for those
`emerging requirements. Thus, a new communications
`architecture is needed to allow communications net~
`works to support the emerging B-ISDN services while
`at the same time accommodating traditional and IN
`based telephony services. Unlike the evolutionary adap
`
`40
`
`45
`
`55
`
`60
`
`65
`
`2
`tation of the traditional communications architecture to
`meet the requirements of IN-based services, the com
`plexity of call and connection controls in a B-ISDN
`environment requires a paradigm shift in communica
`tions network architectures to meet the performance
`demanding requirements of B-ISDN services.
`
`SUMMARY
`The present invention is directed to a distributed,
`server-based communications network architecture in
`which various traditional call processing functions,
`such as switching fabric or channel control, call con
`trol, connection control are separated into distinct ap
`plication processes with clearly de?ned interfaces for
`communications between these application processes.
`Those distinct application processes may be imple
`mented in separate physical or logically partitioned
`nodes. The well-defined interfaces allow communica
`tions among physical or logically partitioned nodes
`within a network, physical or logically partitioned
`nodes of compatible networks, and customer premises
`equipment connected to a compatible network.
`In a preferred embodiment of the invention, object
`oriented analytical tools are used to derive four types of
`models to identify the functions associated with call
`processing in a B-ISDN, N-ISDN and traditional com
`munications networks. These models are: an Informa
`tion Model (IM), State Models (SM), an Object Com
`munications Model (OCM), and Process Models (PM).
`An Information Model (IM) is similar to an “Entity
`Relationship” diagram in which, all data associated
`with a physical or logical entity are grouped into “ob
`jects”. Included in the data for physical objects, such as
`CPE (also called “users”), switches, and adjunct pro
`cessors (also called “servers”), are the respective attri
`butes of these objects, such as, identi?ers and object
`speci?c parameters. For intercommunications between
`the physical objects, the model also identi?es communi
`cations objects, such as call, connection and channel,
`with their respective attributes and relationships to the
`physical objects and other communications objects
`(one-to-many, many-to-many).
`In the State Models (SM), different states of an object
`instance are de?ned. When an object instance enters a
`state (the call object in the “call being set up” state, for
`example), it performs certain actions (digit translation in
`a server, for example). In the course of performing
`those actions, the object generates events that may im
`pact its own state model and cause state transitions in
`other object instances, called “cross-object events”.
`The cross-object events for all objects in the IM are
`identi?ed in the Object Communication Model (OCM).
`The details of data flow in an Action Process are pro
`vided in the Process Models (PMs).
`Based on the four models, a multiserver-based com
`munications network architecture is derived. The archi
`tecture is characterized by a functional separation of the
`operations to be performed by the servers. For example,
`existing call processing functions may be allocated to
`individual servers as follows: fabric control functional
`ity in one or more channel servers, connection control
`functions in one or more connection servers, feature
`management capabilities in one or more call servers and
`service control functions in service-speci?c servers,
`each one of these service-speci?c servers being associ
`ated with a particular type of communications service.
`Assignment of particular tasks or operations to a partic
`ular server reflects the close relationship between ob
`
`Bright House Networks - Ex. 1016, Page 7
`
`

`
`5,434,852
`
`3
`jects related to particular sub-functions, as indicated by
`the number of cross-object events associated with those
`tasks or operations. For example, the call-connection
`mapping, the route and the connection objects are man
`aged in one server. Details of a suite of protocols de
`?ned to enable communications between these applica
`tion processes are provided in the commonly assigned
`co-pending United States patent application Ser. No.
`08/082,654 entitled “Communications Signaling Proto
`cols”.
`
`BRIEF DESCRIPTION OF THE DRAWING
`FIG. 1 is a table that lists objects and their associated
`attributes for B-ISDN communications;
`FIG. 2 depicts instances of the call, channel, connec
`tion and route objects for an illustrative multipoint,
`multiconnection call in a B-ISDN networking environ
`ment;
`FIG. 3 shows some of the objects of FIG. 2 and the
`number of cross-object events needed between these
`objects to perform certain traditional call processing
`functions in a broadband communications network to
`establish communications between users;
`FIG. 4 shows an illustrative arrangement of servers in
`which multiple objects are grouped together in certain
`servers to limit the number of signaling communications
`messages.
`FIG. 5 shows a block diagram of a distributed pro
`cessing architecture for a broadband and narrowband
`communications network; and
`FIG. 6 is an illustrative block diagram of a multiple
`network con?guration for the distributed architecture
`of FIG. 5.
`
`30
`
`4
`slation-Table-entry and the user-call-interaction are
`associative objects.
`In the middle column of the table of FIG. 1 are listed
`the identifying attributes of the objects. All of these
`attributes are either self-explanatory or are described in
`further detail below.
`Listed in the ?rst column on the right hand side are
`the non-identifying attributes of the objects. Those attri
`butes identify particular characteristics associated with
`an object. For example, non-identifying attributes of a
`call object include Server Identi?ers and User Identi
`?ers to particularly point-out the servers and users in
`volved in the call. Similarly, non-identifying attributes
`of a switch include Capacity of the Switch, Number of
`Priorities Offered, Maximum Switching Rates.
`FIG. 2 depicts the instances of the call, channel, con
`nection and route objects for an illustrative multipoint,
`multiconnection call in a B-ISDN simpli?ed network
`ing environment. The objects shown in FIG. 2 are a) the
`users 201, 209 and 210; b) the connections 202 and 203;
`c) the switches 207 and 208; d) the server 211, the route
`212, the channels 204, 205, 206 and the call 214. The
`characteristics, attributes, and the operations and func
`tions associated with each object are discussed below.
`In FIG. 2, a user 201 is shown connected to a switch
`207 via a channel 204. The user 201 may be, for exam
`ple, a digital Communications Premises Equipment
`(CPE), such as a PBX, a data terminal or data communi
`cations equipment, arranged to transmit and receive
`data at ?xed or variable rate. Connections 202 and 203
`represent communications paths between users 201,209
`and 210 through switches 207 and 208. In B-ISDN
`terminology, a connection, such as connection 202 or
`203 is called a “Virtual Channel Connection” (V CC).
`Although connections 202 and 203 are shown as multi
`point communications paths terminated on users 209
`and 210, connections may be con?gured as point-to
`point communications paths terminated on users as well
`as servers. An important characteristic of connections
`202 and 203 is that they extend between points (such as,
`users 201, 209 and 210) where the ATM adaptation
`layer protocol (AAL) which manages end-to-end com
`munications, is terminated. Connections 202 and 203 are
`in effect, a “slice” of the route 212, utilizing a portion of
`the resources of that route over which they run. For
`communications in the broadband network of FIG. 2,
`connections 202 and 203 are referenced by a) their
`unique connection identi?er called a Virtual Channel
`Connection Identi?er (V CCI) and b) the end entity
`identi?ers (users or servers). Of particular importance
`are the attributes of connections 202 and 203. These
`attributes include performance metrics, adaptation layer
`parameters, directionality, symmetry and the identi?ers
`of switches in these connections.
`Functions associated with the control of connections
`202 and 203 comprise a) connection establishment in
`cluding end-to-end Quality-of-Service (QOS) computa
`tion, b) connection release, 0) connection modi?cation,
`and d) connection status and con?guration information
`management. In the broadband networking environ
`ment of FIG. 2, since a single connection may be active
`on many calls, or a single call (such as call 214) may
`have many active connections (such as, connections 202
`and 203), the relationship between the objects are many
`many. For this reason, an associative object called the
`call-connection mapping is de?ned to map connections
`into calls.
`
`35
`
`45
`
`DETAILED DESCRIPTION
`FIG. 1 is a table that lists objects and their associated
`attributes for B-ISDN communications. The table of
`FIG. 1 is derived from the use of an analytical tool
`known in the an as “Object Oriented Analysis” (00A).
`00A advocates the building of four types of models:
`Information Model (IM), State Models (SM), Object
`Communication Model (OCM), and Process Models
`(PM), to ascertain the characteristics of entities and the
`relationship between those entities that are called “ob
`jects”. An object identi?es all the data associated with
`the application domain of each entity being analyzed. In
`an SM (one per object identi?ed in the IM), different
`states of an object instance are shown. When an object
`instance enters a state, it performs certain Actions. As
`50
`pan of these actions, it generates Events. Events gener
`ated in the state model of an object may cause state
`transitions in another object or cause transitions in its
`own state model. Data may be associated with an event.
`The OCM shows only those events generated in an
`object that cause transitions in another object’s state
`model. An Events dictionary lists all the events in the
`different state models. A PM is used to provide details
`of data ?ow with an Action Process (combined list of
`actions) in each State of each Object.
`FIG. 1 is a representation of a part of an Information
`Model (IM) for a broadband network. In FIG. 1, an
`exemplary list of identi?ed objects is provided in the
`?rst column on the left hand side. Relationships be
`tween objects can be one-to-one, one-to-many, or
`many-to-many. Associative objects and relational attri
`butes are used to represent many-to-many relationships.
`In FIG. 1, the call-connection-mapping, the VCI-Tran
`
`55
`
`65
`
`Bright House Networks - Ex. 1016, Page 8
`
`

`
`5,434,852
`5
`Included among the physical objects of FIG. 2 are
`switches 207 and 208. Those switches are preferably
`Asynchronous Transfer Mode (ATM) switches that are
`arranged to format, multiplex, cross-connect and switch
`information in 53-byte packets called “cells” to support
`voice, data and video services (in an integrated fashion
`or individually) at a wide variety of interface speeds.
`Because of the variety of services supported by a broad
`band network in general and switches 207 and 208, in
`particular, a call, such as call 214 needs to be controlled.
`Call control functions include a) service coordination to
`identify service requests and reconcile con?icts (when
`present) among those services, b) end-to-end negotia
`tion to match (for the call) requested services and re
`sources to available services and resources in the net
`work, c) management of information regarding status,
`con?guration, ownership and permissions information
`for calls, d) interaction with connection servers e) user
`to-user, user-to-server negotiations and t) the establish
`ment and release of calls.
`20
`Also shown in FIG. 2 is a route 212 which consists of
`a network communications path that connects users
`201, 209, 210 through switches 207 and 208. Although
`in FIG. 2, route 212 is depicted as a multipoint path, it
`would be appreciated that a route may be point-to-point
`or multipoint. Associated with route 212 are particular
`attributes, such as performance metrics, bandwidth,
`directionality, symmetry and identi?ers of switches in
`the route. Route control deals primarily with the avail
`ability of routes and resources on each route.
`In FIG. 2, a channel 204 is a logical link between the
`user 201 and the switch 207. Similarly, the channel 205
`connects ATM switches 207 and 208, while the chan
`nels 206 and 214 provide links between ATM switch
`208 and users 209 and 210, respectively. In the broad
`band networking environment of FIG. 2, a channel is
`referenced by the Virtual Path Connection Identi?er
`(VPCI), and end entity identi?ers and port numbers.
`Associated with channels 204, 205, 206 and 213 are
`ATM layer and performance attributes. Functions re
`lated to channel control include a) management of re
`sources such as, VPCIs and VCIs, on a link by link
`basis, and b) entries and updates of VCI translation table
`data that are needed to interconnect channels that are
`part of a connection.
`FIG. 3 shows some of the objects of FIG. 2 and the
`number of cross-object events needed between these
`objects to perform certain traditional call processing
`functions in a broadband communications network to
`establish communications between users. The objects in
`FIG. 3 communicate in a manner that is consistent with
`the OCM. In FIG. 3, a labeling scheme has been
`adopted to identify the number of transactions and
`cross-object events required for communications be
`tween users and servers. The digit in parentheses indi
`cates the number of cross-object events needed to carry
`out communication between two objects, while the
`digit to the left of the one in parentheses points out the
`number of transactions needed for the same communi
`cation. For example, one transaction and two cross
`object events are needed for communications between
`the user object 301 and the call server object 302. As
`shown in FIG. 3, a similar number of transactions is
`needed for communications between the call object 302
`and the server object 303.
`Because of the potential high number of routes, con
`nections and channels that may be needed to set up and
`maintain a call in a broadband communications net
`
`6
`work, the number of transactions and events between
`objects needed for that call may be signi?cant. For
`example, the number of transactions and cross-object
`events needed for communications between the route
`object and the call-connection-mapping object is a func
`tion of n, where n represents the number of routes ac
`tive in the call. Similarly, the number of transactions
`and cross-object events needed for communications
`between the route object and the call-connection-map
`ping object is a function of m, where m represents the
`number of connections. Likewise, communications be
`tween the connection object and the channel objects
`require p transactions and 2p cross-object events, where
`p represents the number of channels.
`FIG. 4 shows an illustrative arrangement of servers in
`which multiple objects are grouped together in certain
`servers to limit the the number of signaling communica
`tions messages. FIG. 4 shows a client represented by
`user 401 connected to a call server 402. The latter is also
`connected to a communications services server 403 and
`to a connection server 404 which is itself linked to a
`channel server 405. FIG. 4 is derived from the IM and
`OCM models of the Object-Oriented Analysis method
`ology. More speci?cally, objects that use a signi?cant
`number of transactions and cross-object events to per
`form an operation associated with a call processing
`function, are simply placed in the same server. For
`example, the connection server 404 manages the call
`connection-mapping object 304, the connection object
`306 and the route object 305 of FIG. 3. Similarly, the
`channel server 405 manages the channel object 307 and
`the VPI/NCI object 308 of FIG. 3. By grouping these
`objects in the same server, the number of transactions
`and signaling messages needed for communications
`between the servers is greatly reduced. For example,
`only one transaction and two si'gnaling messages are
`needed for communications between the servers of
`FIG. 4 or between the user/client 401 and the call
`server 402.
`FIG. 5 shows a representation of a distributed pro
`cessing architecture for a broadband and narrowband
`communications network. The distributed processing
`architecture of FIG. 5 is based on the client/server
`distribution structure of FIG. 4. In FIG. 5, user/clients
`and their instances are represented by CPE 501, 513 and
`514. The servers in the distributed architecture of FIG.
`5 include channel servers 506 and 511, connection
`server 504, call server 502 and service-speci?c servers
`519, 521, 523 and 525, which are representative of the
`types of communications services that can be provided
`in a broadband communications network. It is to be
`understood that other types of service-speci?c servers
`could also be included in the distributed architecture.
`Connected to the call server 502 are a users database
`516 and a service database 517, which store subscriber
`pro?le and service-speci?c information that may be
`shared by the service-speci?c servers. Also shown in
`FIG. 5 are Switching Of?ces (S0) 508 and 510. The
`latter are Asynchronous Transfer Mode (ATM)
`switches arranged to cross-connect, switch and multi
`plex integrated, voice, data and video traf?c.
`In FIG. 5, each server executes an application pro
`cess or call processing subfunction that is shown within
`an ellipse in that server. For example, since the call
`object is placed in the call server 502, it follows that the
`associated call control application process 503 should
`be located in the same server. Each server in the archi
`tecture is designed to operate in a modular fashion, i.e.,
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`Bright House Networks - Ex. 1016, Page 9
`
`

`
`1O
`
`25
`
`30
`
`45
`
`5,434,852
`7
`independently of the operations of the other servers.
`The call server 502 has knowledge of the operations of
`the service-specific servers 518, 520, 522 and 524 and
`connection server 504 only to the extent necessary for
`communications with those servers and to to manage
`feature interaction within a call. The servers of FIG. 5
`are shown as physically separated from each other. It
`would be appreciated that those servers can be logically
`partitioned without being physically separated from one
`another.
`Channel servers 507 and 512 are associated with
`switches 508 and 510. Those servers maintain all in
`stances of the channel object associated with the ports
`of their associated switch. They also maintain instances
`of the VCI Translation Table Entry object for connec
`tions that traverse the switch (508 or 510) with which
`the particular channel object (506 or 512) is associated.
`The connection server 504 provides bearer services
`with capabilities to add, drop or modify a connection
`through switches 504 and 510. In addition, the connec
`20
`tion server 504 provides common/diverse routing of
`connections and end-to-end Quality-of-Service (QOS)
`computation for connections. Connection servers 504
`also maintain connection, state and con?guration infor
`mation.
`At the heart of the distributed architecture of FIG. 5
`is call server 502, which is arranged to provide the
`functions such as: facilitate user-to-user and user-to-net
`work negotiation of options and check for user/server
`status and compatibility; provide service invocation and
`coordination functions; recognize any need for special
`resources (e.g. converters); maintain call state, con?gu
`ration information; and manage call reference values
`and user account information; interact with connection
`servers; and establish, modify and release calls. To pro
`vide these functions, call server 502 is physically linked
`to the CPE 501, 513 and 514 and the service-speci?c
`servers 519, 521, 523 and 525. In addition, call server
`502 has also a physical link to connection server 504 for
`connection and route control functions.
`To illustrate how call processing functions are per
`formed for the establishment of a two-party call, let us
`take the example of a user who initiates such a call and
`desires certain services with certain attributes to be
`provided in that call. The request message and the un
`derlying parameters for the desired services associated
`with that call are sent by the user as a service invocation
`to the call server 502. The latter processes the request
`and forwards the associated parameters to the appropri
`ate service-speci?c servers to invoke operations as nec
`essary in those service-speci?c servers. The latter serv
`ers may interact with like servers (even in other net
`works) to perform the operations indicated by the call
`server 502. At the completion of these operations, the
`service-speci?c servers report the results of their opera
`tion(s) to the call server 502. The latter performs user
`to-user and user-to-server negotiations based on the
`results of the operations performed by the service
`speci?c servers. Subsequently, the call server 502 in
`vokes the services of connection server 504 to request
`that connections with certain performance and routing
`characteristics be established. As part of its route con
`trol functions, connection server 504 may retrieve rele
`vant information from other connection servers or may
`query channel servers 506 and 511 for appropriate infor
`65
`mation. When the connection server 504 has selected
`the routes for the connections, it invokes the services of
`the channel servers 506 and 511 to establish the virtual
`
`8
`charmel links. At the end of their operations, the chan
`nel servers 506 and 511 report the result of these opera
`tions. If the channel operations were successful and the
`requested channels have been allocated, the connection
`server 504 returns a positive result message to the call
`server 502 indicating that the requested connections
`have been established. At that time, the call server 502
`returns a positive result message to the users involved in
`the call indicating that the call has been established.
`While the operations indicated in the example above
`are described sequentially for clarity purposes, it would
`be appreciated by persons skilled in the art that some of
`these operations may be performed concurrently with
`other operations.
`FIG. 6 is a block diagram of a multiple network con
`?guration for the distributed architecture of FIG. 5.
`Shown in FIG. 6 are four networks 600, 610, 620 and
`630 designed in accordance with the client/server dis
`tributed architecture depicted in FIG. 5. Each of these
`networks comprises a call server (6007 for Network I,
`6107 for Network II, 6207 for Network III and 6307 for
`Network IV) that is connected to the other servers in
`each network. As described above, one of the functions
`of these call servers is to forward parameters associated
`with a requested service to the appropriate service
`speci?c servers and to request establishment of connec
`tions and channels from their respective attached con
`nections servers.
`Also connected to call servers 6007, 6107, 6207 and
`6307 are Signal Transfer Points (STP) 6008, 6108, 6208
`and 6308, respectively. Those STPs act as gateways for
`signaling communications messages to be exchanged
`among the networks 600, 610, 620 and 630. Thus, when
`one of these networks wants to request a particular .
`service from another network as pan of the call setup
`process, service request signaling mess