United States Patent [191
`La Porta et al.
`
`|||||| llllllll m llllllllll N510 1|! slglllottylllnluuun|||||||N|||
`
`Patent Number:
`[111
`[45] Date of Patent:
`
`5,509,010
`Apr. 16, 1996
`
`[54] COMlVIUNICATIONS SIGNALING
`PROTOCOLS
`
`[75] Inventors: Thomas F. La Porta, Thornwood,
`N.Y.; Malathi Veeraraghavan, Atlantic
`Highlands, NJ.
`
`[73] Assignee: AT&T Corp., Murray Hill, NJ.
`
`[21] Appl. No.: 82,654
`[22] Filed:
`Jun. 25, 1993
`
`[51] Int. Cl.6 .............................. .. H04L 12/12; H04J 3/12
`[52] U.S. Cl. ...................................... .. 370/681; 370/110.1
`[58] Field of Search ......................... .. 370/60, 60.1, 94.1,
`370/1101, 58.1, 58.2, 58.3, 68.1; 379/220,
`229, 230, 240, 165, 350, 352; 395/20002,
`200.03, 600, 700
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,512,016 4/1985 Fulcorner et al. ................. .. 370/110.l
`
`. . . . .. 379/230
`8/1989 Thom et a1. . . . . . .
`4,853,955
`370/1101
`2/1993 Sahni ......... ..
`5,184,345
`..... .. 370/1101
`5,305,318 4/1994 Ozeki et al. .
`5,313,463
`5/1994 Gore et a1. ......................... .. 370/1101
`
`OTHER PUBLICATIONS
`
`C. Woodworth, M. I. Karol, R. D. Gitlin, “A Flexible
`Broadband Packet Switch for a Multimedia Integrated Net
`work”, Proceedings International Conference on Communi
`
`cations, Jun. 23—26, 1991, Denver.
`I. Faynberg, L. R. Gabuzda, M. P. Kaplan, M. V. Kolipakum,
`W. J. Rowe, A. L. Waxman, “The Support of Network
`Interworking and Distributed Context Switching in the IN
`Service Data Function Model”, 2nd International Confer
`ence on Intelligence in Networks, France, Mar., 1992.
`S. Minzer, “A Signaling Protocol for Complex Multimedia
`Services”, IEEE Journal on Selected Areas in Communica
`tions, vol. 9, No. 9, Dec., 1991.
`M. Fukazawa, M. Wakarnoto and M. W. Kim, “Intelligent
`Network Call Model for Broadband ISDN”, ICC 1991, pp.
`964-968.
`
`Primary Examiner-Wellington Chin
`Assistant Examiner—Chau T. Nguyen
`Atzomey, Agent, or Firm—J0hn A. Caccuro
`
`[57]
`
`ABSTRACT
`
`A modular suite of peer~to-peer protocols that are indepen
`dent of communications network architecture supported, and
`the type of switching systems (packet~switched or circuit
`switched), is used for a broadband and/or narrowband com
`munications network. The protocols are comprised of client
`server-oriented signaling messages that are restricted to
`include information and parameters associated with only one
`particular function of traditional call processing.
`
`9 Claims, 5 Drawing Sheets
`
`203
`/
`
`201
`
`cc2,cc4,cc7,cc8
`
`06,08,016
`20s
`v1,v2
`
`—:vc1 TR. TABLE ENTRY
`207
`Nsims
`204
`;
`N5,N7,N1,N4
`r
`CHANNEL
`CONNECTION )
`1
`
`L2,L4,L5
`P7,P9,P10
`L1,L3,L5
`
`Nam,
`N3,Nt1,N12
`
`“m5
`
`P3,P5
`
`206
`
`‘[
`
`cctccs
`
`P1,P2,P4
`
`f
`
`CALL
`
`coNNtcnoN
`P8,P11
`
`MAPPING
`
`205
`
`Bright House Networks - Ex. 1040, Page 1
`
`

`
`US. Patent
`
`Apr. 16, 1996
`
`Sheet 1 of 5
`
`5,509,010
`
`* ‘
`
`CEO 2%
`555 ,8 02mm ,5
`@EE 52%: 5% 222525
`
`
`
`M222: ; 1 355 :2 i 5 E o:
`
`
`
`:0 H 658 m?zmm
`
`R R
`
`:0 E
`
`_ _
`
`E > E
`
`+ f
`
`
`
`1 \ .25 m2 :5
`
`2 n, 2: N2 $2
`
`
`
`\ 225228
`A was:
`
`Bright House Networks - Ex. 1040, Page 2
`
`

`
`U.S. Patent
`
`Apr. 16, 1996
`
`Sheet 2 of 5
`
`5,509,010
`
`L/\ 5.20.20.20.38
`
`II . . . . . . F :3 2: N; s 3 s 5 5
`
`8050.30.80
`
`zesmzzot \
`
`588 E
`
`. . 2.; x
`
`EN EN
`
`2262
`
`19%: 5% .E 55
`
`:22233532
`
`N 65%
`
`H35
`
`226E200
`
`25%:
`
`Bright House Networks - Ex. 1040, Page 3
`
`

`
`Bright House Networks - Ex. 1040, Page 4
`
`

`
`US. Patent
`
`FIG. 4
`
`Apr. 16, 1996
`
`Sheet'4 of 5
`
`5,509,010
`
`OPERATION
`SETUP-CALL
`MODIFY -CALL-OR—REOUEST—
`INFORMATION
`RELEASE-CALL
`PERFORM-NEGOTIATION
`INTERACT-WITH-CONNECTION-
`SERVER
`CONVEY-USER-SERVER-
`INFORMATION
`PERFORM-SERVICE-INVOCATION-
`COORDINATION
`
`CLASS EVENTS
`C
`U1,C4,C15
`C
`U3,C4,C15
`
`C
`C
`C
`
`U
`
`U
`
`U4,C1 2
`S1 ,C3
`S2,C9,C14
`
`54
`
`C1
`
`OPERATION
`SETUP-CONNECTIONS
`RELEASE-CONNECTIONS
`MODIFY-EXISTING-CONNECTIONS
`FIND-PATH
`CUT-THRU-CONNECTION
`ADD-CHANNEL-TO-CONNECTION
`DELETE-CHANNEL-FROM-
`CONNECTION
`MODIEY-OOS-Qr-BW
`
`CLASS
`C
`C
`C
`C
`C
`C
`C
`
`EVENTS
`C6,CC4,CC2,
`C8,CC7
`C7,P1 1,P8
`CC1,P1,P2
`CC3,N11,N12
`P7,N8,N2
`P9,N8,N2
`
`C
`
`P10,N8,P8
`
`OPERATION
`RESERVE-CHANNEL
`COMMIT-CHANNEL
`MODIFY-CHANNEL
`DROP—CHANNEL
`FREE-RESERVED-CHANNELS
`SETUP-VCI-TRANSLATION-TABLE—ENTRY
`DROP-VCI-TRANSLATION-TABLE-ENTRY
`INFORM-NODE-OF~RECEIVE—CHANNEL
`
`CLASS EVENTS
`C
`PS,L1,L3
`C
`N5,L2
`C
`N1,L4
`C
`N7,L5
`C
`P5,|_5
`C
`N6,V1
`C
`N13,V2
`u
`N4
`
`‘FIG. 5
`
`FIG. 6
`
`Bright House Networks - Ex. 1040, Page 5
`
`

`
`US. Patent
`
`Apr. 16, 1996
`
`Sheet 5 of 5
`
`5,509,010
`
`u 65%
`
`d.
`
`@E
`
`
`
`m2 zcmTz ozcwcm
`
`
`
`185m 5650
`
`zamTz,
`
`ozmwuuowz :5
`
`8“ 125m 22
`
`zQwTm
`
`025505 :5
`
`NR
`
`
`
`518 SE28 55mm
`
`E 52
`
`
`
`.uzmmmoo? .35.. 235
`
`
`
`5:28 @888”: .6528 55am
`
`
`
`
`
`
`
`2%: 1255
`
`I
`
`) 2K
`
`
`
`.Y 025302; .33 £672
`
`
`
`
`
`
`
`12% gas}:
`
`Bright House Networks - Ex. 1040, Page 6
`
`

`
`5,509,010
`
`2
`vices using, for example, Asynchronous Transfer Mode
`(ATM) switches, it is apparent that the existing signaling
`protocols are inadequate to support those new services.
`Extension of the existing ISDN signaling protocols to sup
`port the B-ISDN services presents certain drawbacks. Those
`drawbacks include a) perpetuating the distinction between
`user-network interfaces and network-to-node interfaces,
`which is likely to be dysfunctional in an environment where
`the roles of, and the relationship between, switches, cus
`tomer premises equipment and other processors in a network
`can be rede?ned for a particular service; b) perpetuating the
`bundling of certain functions, such as call control, connec
`tion control, and channel control in the NNI and UNI
`protocol suites; and c) di?iculty in managing connections, in
`general, and meeting quality-of-service parameter checking
`requirements for certain connections, in particular.
`Consideration has also been given to derive new message
`syntax and message ?ow procedures for B-ISDN networks.
`However, that approach precludes the reuse of existing
`protocol-related software. Thus, no prior art signaling pro
`tocol architecture is able to provide a feasible, modular and
`?exible approach to allow widespread implementation of the
`emerging B-ISDN services while accommodating tradi
`tional and N-ISDN telephony services.
`
`l0
`
`15
`
`25
`
`1
`COMMUNICATIONS SIGNALING
`PROTOCOLS
`
`TECHNICAL FIELD
`
`This invention relates to communication systems. More
`speci?cally, this invention relates to signaling protocols for
`communications networks.
`
`BACKGROUND
`
`Historically, communications switches were designed to
`manage and perform most, if not all, the functions associated
`with the completion of a telephone call. These functions
`include switching, routing, signaling, call control and ser
`vice control. The development of digital, software-driven
`switches, allowed the signaling function to be decoupled
`from the other functions performed by a switch. Accord
`ingly, protocols governing the format and the type of sig
`naling information, were developed to a) allow communi
`cations between switches and b) manage the interface
`between a switch and a signaling node handling some of the
`signaling functions. Thus, these interfaces were limited to
`strictly network-speci?c functions and accordingly they
`became known in the art as “Network Node Interfaces”
`(NNI). The set of standardized protocols associated with the
`NNI type of interfaces is the Signaling System No. 7 (SS7).
`As customer premises equipment, such as Private Branch
`Exchanges (PBX) and telephone sets, started to use digital
`signals, as opposed to analog signals, to communicate with
`switches, protocols were also needed to manage the com
`munications interfaces between users’ equipments and
`switches. Accordingly, protocols were also developed to
`standardize user-network access procedures or, more spe
`ci?cally, the interfaces between the customer premises
`equipment and the switches of a telephone network. Those
`interfaces became to be known in the art as “User-Network
`Interfaces” (UNI). Associated with the UNI interfaces is a
`standardized set of protocols known as “Digital Subscriber
`Signaling System No. 1” (DSSl).
`With the introduction of Narrowband Integrated Services
`Digital Network (N-ISDN) and the Open Systems Intercon
`nection (081) model which de?ned user-network access and
`network-to-network (or switch~to-switch) standards for
`voice and data communications, UNI and NNI were adapted
`to conform to these new standards. NNI protocols were
`further extended to standardize communications procedures
`between switches and service-speci?c database systems that
`provide, for example, call related information look~up func
`tions for services, such as Freephone, known in the United
`States as 800 Service. The subset of the NNI protocol suite
`related to communications between switching nodes and
`service-speci?c processors in a network is known as Trans
`actions Capability Application Part or TCAP for short.
`Unfortunately, the dichotomy between user-network access
`procedures and switch-to-switch communications proce~
`dures remained. A consequence of that dichotomy is mani
`fested in the need for multiple protocol conversions to take
`place (from UNI format to NNI format and back to UNI
`format) in order to relay, for example, caller-id information
`to the called party. More importantly, ISUP messages still
`include information and related parameters associated with
`different call processing functions, thereby unduly compli
`cating execution of call processing functions.
`With the development of Broadband Integrated Services
`Digital Network (B-ISDN) standards and their anticipated
`widespread implementation to offer a wide variety of ser
`
`SUMMARY
`
`One example of the present invention is directed to a
`modular suite of peer-to~peer protocols that are a) indepen
`dent of communications network architecture, and the type
`of switching systems (for example, ATM or circuit-switched
`systems) used in the architecture b) comprised of client
`server-oriented signaling messages that are restricted to
`include information and parameters associated with only one
`particular type of traditional call processing.
`In a preferred embodiment of the invention, object-ori
`ented analytical tools are used to de?ne a set of application
`processes or functions associated with traditional call pro
`cessing. The set of application processes or functions may
`include, for example, call control, connection control, chan
`nel control, and service control. Associated with each appli
`cation process is an Application Service Element (ASE)
`which de?nes the operations (and related parameters)
`needed to be performed for an application process to com
`municate with another application processes. Thus, a sepa
`rate set of operations is de?ned for each identi?ed applica
`tion process. When each application process is executed in
`a separate physical or logically partitioned server, the num
`ber of entities that require change to introduce a new service
`is greatly reduced.
`Advantageously, a suite of protocols conforming to the
`principles of the invention may coexist with other protocols,
`such as ISUP. For example, the suite of protocols of the
`invention may be implemented for NNI interfaces only or
`for broadband communications exclusively, while DSSl
`signaling messages are used for UNI interfaces and DSSl/
`SS7 protocols are used for narrowband communications.
`
`35
`
`45
`
`55
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`FIG. 1 is a block diagram of an exemplary distributed
`processing architecture for a broadband communications
`network.
`FIG. 2 is a representation of part of an Object Commu
`nications Model designed to illustrate the nature and type of
`inter-entity communications supported by the protocols of
`the invention.
`
`65
`
`Bright House Networks - Ex. 1040, Page 7
`
`

`
`5,509,010
`
`3
`FIG. 3 shows the structure of the protocol stacks for
`servers implementing particular call processing functions in
`a broadband communications network environment.
`FIG. 4, 5, and 6 are tables that list the type of operations
`that need to be supported in a broadband communications
`network environment.
`FIG. 7 is a networking arrangement that illustrates the
`potential coexistence of the signaling protocols of the inven
`tion with existing protocols.
`DETAIL DESCRIPTION
`
`FIG. 1 is a block diagram of an exemplary distributed
`processing architecture for a broadband communications
`network. Because of the unique requirements of broadband
`communications services, such as the need to support a)
`multiple connections in a call, b) common path/diverse path
`routing in a connection, 0) modi?cation of active connec
`tions, and d) end-to-end quality of service determination,
`certain call processing functions have been extended to
`manage communications over a broadband network. Those
`functions include call control, route control, connection
`control, and channel control. The identi?cation of these
`functions is predicated on a formal analysis technique called
`Object Oriented Analysis (OOA) described in further detail
`below. Due to the complexity of call processing in a broad
`band environment, it is desirable to implement those func
`tions in separate physical or logically partitioned servers to
`allow the operations of each server to be independent from
`the operations of another server, thereby, effectively sepa
`rating service control from call control, channel control, and
`connection control. Thus, in FIG. 1, the call control function
`is shown as the call control application process 103 in call
`server 102. The call server is responsible for a) service
`coordination and invocation when multiple services are
`requested in a call, b) user-to-user and user-to-server nego
`tiation of resources, 0) recognition of needs for special
`resources, such as protocol converters and multimedia
`bridges, d) maintenance of call state and con?guration
`information and e) management of ownership and permis
`srons.
`Similarly, the connection control application process 105
`is implemented in connection server 104. The latter is
`responsible primarily for establishing, releasing and modi
`fying connections within a call, and for computing end-to
`end Quality-of-Service (QOS) measurements. Likewise, the
`channel control application processes 107 and 112 that are
`associated with Switching O?’ices (S0) 108 and 110, respec
`tively, are executed in channel servers 106 and 111, respec
`tively. Switching o?ices 108 and 110 house ATM switches
`arranged to cross-connect, multiplex and switch voice, data
`and video tra?ic. Channel servers 106 and 111 allocate
`resources on a link-by-link basis, and maintain Virtual
`Channel Identi?er translation table entries (described below)
`to interconnect channels that are part of a connection.
`Also shown in FIG. 1 are service-speci?c servers 118,
`120, 122, and 124 that provide particular broadband-based
`services for a call associating users such as Customer
`Premises Equipment CPE 101, 113 and 114 and those
`servers. Further details regarding the distributed architecture
`of FIG. 1 can be found in the commonly assigned co
`pending US patent application, Ser. No. 08/055,487.
`FIG. 2 shows illustrative entities of a broadband commu
`nications network and the type of signaling messages needed
`to establish communications between these entities.
`FIG. 2 is derived from the use of a four model structure
`advocated in a methodology called “Object Oriented Analy
`
`l0
`
`15
`
`20
`
`25
`
`30
`
`35
`
`45
`
`55
`
`60
`
`65
`
`4
`sis” (00A). 00A is used in this example to identify the
`signaling requirements of a broadband communications net
`work. The four types of models in the OOA methodology
`are: Information Model (IM), State Models (SM), Object
`Communication Model (OCM), and Process Models (PM).
`The IM identi?es networking entities and the characteristics
`of, and the relationship between, those entities that are called
`“objects”. An object identi?es all the data associated with
`the application domain of each entity being analyzed.
`Objects shown in FIG. 2 include: user object 201, call object
`202, server object 203, connection object 204, call connec
`tion mapping object 205, route object 206, channel object
`207 and Virtual Channel Identi?er (VCI) Translation Table
`Entry 208.
`The call object 202 de?nes an association between the
`user object 201 and the server 203. It is identi?ed in a
`broadband network by a call reference value. Other
`attributes associated with a call object are the user objects
`and the server objects in the call. These attributes may be
`referenced by identi?ers. The route object 206 is a path
`through the network that connects multiple end-points (users
`and/or servers) through switches. The route object 206 may
`terminate on users or servers, and may be point-to-point or
`multipoint. The route object 206 is referenced by a route
`number and entity identi?ers (user, server,switches) for
`communications with other objects. Associated with the
`route object 206 are: a) performance attributes, bandwidth,
`and switches identi?ers in the route. In the broadband model
`of FIG. 2, connection object 204 is a virtual channel con
`nection (VCC). It is a communication path between users
`and servers through switches. The connection object 204
`may identify a point-to-point or multipoint connection that
`extends between points where the ATM adaptation layer
`(AAL) is terminated. Attributes of connection object 104 are
`performance metrics, adaptation layer attributes, direction
`ality, symmetry, virtual channel connection identi?ers
`(VCCI), end user identi?ers, and switches in the connection.
`Because a single connection may be active on many calls,
`or a single call may have many active connections, the call
`object 202 and the connection object 204 have a many-many
`relationship. For this reason, the associative object called
`call-connection mapping object 205 is de?ned to map con
`nections into calls. It is an associative object which is
`indicative of the many-many relationship between a call
`object and a communication object.
`The channel object 207 de?nes anAsynchronous Transfer
`Mode (ATM) virtual channel link. It is a link in an ATM
`interface. The channel object 207 connects either two
`switches or a switch and a user/server. The channel object
`207 is referenced by its Virtual Path Connection Identi?er
`(VPCI), VCI, end entity identi?ers and port numbers. VCI
`translation table entry 208 is an associative object that
`de?nes interconnection between channels that are pan of a
`connection.
`In an SM (one per object identi?ed in the IM), diiferent
`states of an object instance are shown. When an object
`instance enters a state, it performs certain actions. As part of
`these actions, it generates events. Events generated 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. 'Ihose events are called in the
`art “cross~object events”. They are represented in FTG. 2 by
`the labels C1 to C18, CC1 to CC8, L1 to L5, N1 to N12, P1
`to P10, S1 to S6, U1 to U14, and V1 to V2. A partial list of
`these events with their associated data are shown. In the
`
`Bright House Networks - Ex. 1040, Page 8
`
`

`
`5,509,010
`
`5
`labeling scheme, the letter “C” is used for events generated
`in the call object 202 and two other related objects user
`call-interaction and server-call-interaction objects (not
`shown). The letters “CC” denote events associated with the
`call-connection-mapping object 205. Similarly, the letter
`“L” is used for events generated by channel object 207, the
`letter “N” is used for events generated by the connection
`object 204, while the “P” is used for events generated by the
`route (path) object 206. The letter “S” is used for server
`events and the letter “U” points to user events generated by
`user 201.
`As an illustration of the relationship between objects and
`events, the flow of events for a successful call establishment
`scenario is described immediately below. The event U1
`(Setup-call), is generated by the user object 201 in response
`to that user initiating a call requesting service provided by
`server 203. That event causes a state transition in the call
`object 202. As a result, events C1 (Invoke-server), are
`generated by the call object 202 which communicates events
`C1 to the server object instances involved in the call. The
`server object 203 may generate, for example, event S1
`(Perform-negotiation), if needed. This causes event C2,
`Negotiation-with-user, to be generated from the call object
`202 to the user object. The user object replies with event U2,
`Reply-to-negotiation~request. The call object 202 sends this
`response back to the requesting server object via event C3
`(Retum-negotiation‘information-to-server). The server
`object 203 is then assumed, in this example, to generate
`event S2 (Server-request-or-response), to the call object 202.
`This object instance then generates event C6, (Setup-con
`nections), to the call-connection mapping object 205. For the
`sake of simplicity, communications between the call-con
`nection mapping object 205, the route object 206 and the
`connection object 204 are not discussed in this example.
`Assuming a predetermined route instance already exists, the
`connection object 204 generates events N5 (Commit-chan—
`nel), and N6, (Setup—VCI-translation-table-entry) to the
`instances of channel object 207 and the VCI translation table
`entry object 208, respectively. Assuming success, i.e., events
`L2 (Channel-committed), and V 1, (VCI-translation-setup),
`are received by the connection object 204, the call-connec
`tion mapping object 205 generates event CC4 (Mandatory
`connections-in-call-established) that is communicated to the
`call object 202/The latter then generates events, C4 (Notify
`user-call-success) to user object instances in the call and
`events C9 (Notify-server-connection-success) and C5
`(Notify-user-server-call-status-information) to server object
`instances in the call.
`Similar event communication paths can be traced through
`FIG. 2 for call release and call modi?cation procedures.
`Based on the OCM model described in FIG. 2, the
`multiserver-based communications network architecture of
`FIG. 1 is derived. The architecture 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 functionality in charmel servers 106 and 111, con
`nection control functions in connection server 104, call
`control functions in the call server 202 and service control
`functions in the service-speci?c servers 118, 120, 122 and
`124. Assignment of particular tasks or operations to a
`particular server re?ects the close relationship between
`objects related to particular functions, as indicated by the
`number of cross-object events associated with those tasks or
`operations. For example, the call-connection mapping object
`205, the connection object 204 and the route object 206 are
`managed in the connection server 104 of FIG. 1.
`
`20
`
`25
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`FIG. 3 shows the structure of the protocol stacks for
`servers implementing particular call processing functions in
`a broadband communications network environment.
`Depicted in FIG. 3 are user 302 and servers comprising the
`Virtual Private Network (VPN) Server 301, the Call Server
`303, the Connection Server 304, the VMR Server 305, and
`the Channel Server 306. Resident in each server/user is an
`associated application process 307, 308, 321, 322, 323, and
`324. These application processes de?ne the tasks to be
`performed by the user or server. For example, the Call
`Server 303 has an application process 308 to perform Call
`Control. Similarly, the Application Process 323 performs
`channel control functions for the channel server 306.
`Also resident in each server are Application Service
`Elements (ASEs) which define the interfaces for communi
`cations between one or more users/servers to carry-out the
`task identi?ed in the Application Process. In this example,
`ASEs that are de?ned include a) Broadband Call Service
`Element (BCSE) shown as BCSE 309 in user 307, BCSE
`314 in the VPN server 301, BCSE 310 in call server 303,
`BCSE 380 in connection server 304 and BCSE 315 in VMR
`server 305 b) Broadband Bearer Service Element (BBSE)
`shown as BBSE 318 in the connection server 304 and BBSE
`317 in the call server 303 0) Broadband Channel Service
`Element (BCHSE) shown as BCHSE 319 in connection
`server 304 and BCHSE 320 in channel server 306. The
`BCSE represents the communication functions (operations
`and parameters) needed to communicate with the call con
`trol application process, BBSE, the communication func
`tions needed to reach the connection control application
`process, and BCHSE, the communication functions needed
`to reach the channel control application process.
`For example, if the user 302 wishes to establish a call, it
`will send a request to the Call Server 303 using its BCSE
`309. This request is received by the BCSE 310 in the Call
`Server 303, and the operation(s) and related data are for
`warded to the application process performing Call Control
`308 in the Call Server. If any services have been requested
`by the User, the Call Server will use its Service ASEs 311 to
`communicate with the service-speci?c servers. For example,
`the Call Server may send a request to the VPN Server 301
`via its VPN ASE (a speci?c ASE in the set of Service ASEs
`311, or it may send a request to the VMR Server 305 through
`the VMR service ASE (one of the 311 ASEs). The applica
`tions running in these servers 321,322 receive the requests
`and process them. If the Call Server requests a connec
`tion(s), it uses the BBSE 317 to access the Connection
`Control application 324 resident in the Connection Server
`304 via its BBSE 318. Likewise, if the Connection Server
`Application 324 must communicate with the Channel Server
`Application 323 resident in the Channel Server 306, it uses
`its BCHSE 319 to invoke operations via the BCHSE 320 in
`the channel server 306.
`In each server of FIG. 3 are depicted the lower layer
`protocols that are used for communications between servers.
`The. nature of these protocols depends on the con?guration
`of the servers in a networking environment. For example,
`servers may be colocated with switches, or may be con
`nected with switches via signaling links. Thus, inter-server
`communication schemes may vary from shared memory
`writes to wide area protocols. Based on the network archi
`tecture, different means of involving and transporting
`remote operations can be used. If call control, connection
`control, channel control, and service control functions are
`implemented as different UNIX processes, standard IPC
`(InterProcess Communication) mechanisms can be used to
`support remote operation invocations. If the different appli
`
`Bright House Networks - Ex. 1040, Page 9
`
`

`
`5,509,010
`
`10
`
`15
`
`20
`
`25
`
`7
`cation processes are distributed on servers that are physi
`cally separated, a pre-existing ASE called ROSE (Remote
`Operations Service Element) can be used to support remote
`invocations of the operations speci?ed in the ASEs. In the
`UNI protocol, ROSE is used in the Q.932 Facility Informa
`tion Element and in the NNI protocol, the Component
`Sub-Layer (CSL) of TCAP (Transaction Capabilities Appli
`cation) uses ROSE. Thus, embedded bases of these proto
`cols can be reused for transporting information related to the
`ASEs.
`FIGS. 4, 5 and 6 provide for each ASE de?ned in FIG. 3,
`the names of operations, the classes and the corresponding
`cross-object events. In these ?gures, if an operation is
`con?rmed (class C), a reply is expected from the other
`entities receiving the message. With Uncon?rmed (class U)
`operations, no reply is expected from the entity receiving the
`message.
`FIG. 4 shows the list of operations needed for BCSE 310,
`314, 315 and 340 in FIG. 3 to support the communication
`needs of the call control server in FIG. 3. The ?rst three
`operations in FIG. 4 correspond to events U1, U3 and U4,
`generated by the instance of the user object 201 in FIG. 2.
`These operations are invoked to reach the call control
`functions of establishing modifying, and releasing calls,
`respectively. Since Setup-call, Modify-call-or-request-infor
`mation, and Release-call operations are of type Class C,
`events C4, (Notify-user-call-success), C15 (Notify-user
`call-failure) and C12, (Call-released), indicate that success
`and failure responses are expected from the entity setting up
`the call.
`Operation “Perform-negotiation”, corresponds to the
`user-to-user and user-to-server negotiation, compatibility
`and status checking functions of the call control application
`process. In this operation, the call server (where the call
`control application resides) also performs its function of
`recognizing the need for specialized servers, such as con
`verters. This operation corresponds to event S1 (Perform
`negotiation) and event C3, (Retum-negotiation-information
`to-server) indicative of the fact that a response is required.
`The next operation, Interact-with-connection-control, corre
`sponds to event S2, Server-request-or-response. Events C9,
`Notify-server-connection-success, and C14, Notify-server
`connection-failure, correspond to success and failure
`responses, respectively.
`One of the functions of call control is to act as a liaison
`between users and servers. The Convey-user-server-infor
`mation operation in the BCSE ASE provides the communi
`cation needs of this function. The Perform-service-invoca
`tion operation may be invoked by another call server if it
`needs to reach servers that are connected to the remote call
`server.
`To interact with the connection 304 of FIG. 3, the call I
`control application process 324 in the call server 303 uses
`the operations of the BBSE 317 and 318 in the call server
`and connection server, respectively. FIG. 5 lists these opera
`tions and associated events. The operation Setup-connec
`tions is used to reach the function of connection control
`related to establishing connections. Operation success is
`reported in event CC4, (Mandatory~connection-in-call-es
`tablished) and failure in event CC2 (Mandatory-connec
`tions-unavailable). Operation Release-connections is an
`operation whose invocation corresponds to event C8, while
`event CC7, (Connection-in-call-dropped) reports success.
`The operation Modify-existing-connections is invoked to
`change one ore more connections by either adding a party,
`dropping a party or changing QoS or bandwidth of a
`connection.
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`The operations, Find-path, and Cut-thru-connections, are
`used to support communication between peer connection
`control processes distributed among several connection
`servers. To support end-to-end-QoS computation, one con
`nection server (per one or more connections in a call) may
`need to ?rst accumulate QoS characteristics that can be
`offered for diiferent parts of a connection, before it decides
`whether or not to cut-through the connections. In this case,
`the operation Find-path, is ?rst invoked and reports of
`success or failure, events P1 and P2, collected. The connec
`tion server performs the end-to-end QoS computation and
`then invokes Cut-thru-connection in connection servers
`responsible for different segments of the connection if
`end-to-end QoS can be met. A similar rationale exists for
`operations Add-channel-to-connection, Delete-channel
`from-connection and Modify-QoS-or-BW operations of
`BBSE.
`Operations to support the communication needs of chan
`nel control BCHSE 320 are shown in FIG. 6. The Reserve
`charmel operation corresponds to event P3 with the same
`name. If a route object instance corresponding to the needs
`of a connection setup request does not exist, then channel
`object instances are ?rst reserved. The connection control
`function determines whether the attributes of the requested
`connection can be met before committing these channels
`with invocations of the Commit-channel operation. If a
`predetermined route exists, the connection control function
`directly invokes the Commit-channel operation of channel
`control applications. Operations, Modify-channel and Drop
`channel, are invoked to reach the channel control application
`process to change characterist