TITLE : METHOD FOR PROVIDING END-TO-END QUALITY OF SERVICE IN A SOFTSWITCH-BASED NETWORK FOR VOICE AND OTHER REAL TIME APPLICATIONS SPECIFICATION BACKGROUND Cross Reference to Related Application This application is related to, incorporates by reference, and claims priority to the filing date of the following applications:"SYSTEM AND METHOD FOR CALL CONTROL AND ROUTING filed on February 24,2000 and having a serial number of 60/184,796 ;"SYSTEM AND METHOD FOR CALL CONTROL AND ROUTING" filed on April 11,2000 and having a serial number of 60/196,447; METHOD AND APPARATUS FOR CALL CONTROL AND ROUTING filed on August 8,2000 and having a serial number of 09/633,321; and APPARATUS AND METHODOLOGY FOR PROVIDING END- TO-END QUALITY OF SERVICE IN A SOFTSWITCH-BASED NETWORK FOR VOICE AND OTHER REAL TIME APPLICATIONS, filed 7/26/00 having a serial number of 60/220,711.

1. Technical Field The present invention is related to telecommunication and packet and Internet Protocol (IP) based networks and, more particularly, to call setup and routing for voice and real time applications on packet or IP networks.

2. Related Art Developments in the telecommunication industry has significantly improved the ability for people to communicate, exchange data, perform research, and, more generally, the ability to access information resources that were unavailable even in recent history to the common person. The new communication networks are altering the business landscape and are altering the very way individuals work, shop, and keep in touch with each other. Not only, for example, can one use cellular phone service or e-mail to communicate with others, one can also now obtain large documents, graphic images, databases, and other types of information having significant memory footprints through wireless and wireline networks.

The manner in which the communication networks are evolving creates a need for more capable information access tools (computers and transceivers, for example). The new tools, in turn, create a need for new networks having increased data throughput capacity and reliability. New networks and information exchange capabilities that were unimaginable even in recent times are being developed and implemented in a way that impacts businesses and individuals in a significant way. For example, standalone computers may now be integrated with wireless radiotelephones to allow the transmission of information from the computer to a destination by way of a wireless communication network and then by way of the Internet.

The recent explosion of the Internet is creating the capability and desire for networks of all types to be integrated and coupled to exchange data signals carrying the varying types of information. In many cases, the same data also will also be transported through a local area network (LAN) and/or through a telecommunications network prior to being delivered to the Internet. Thus, by way of example, a digitized signal can be transported from a desktop computer through a telephone network to an Internet service provider and through the Internet to a final destination.

New international standards and protocols are being approved to make communication devices created by companies throughout the world compatible with each other. These protocols and standards are used to guide the design of the communication devices, and more specifically, to guide the design of the operating logic and software within the devices. While communication devices that are designed in view of these standards do not always follow the suggested models exactly, they are usually compatible with the protocol-defined interfaces (physical and logical). In order to appreciate the construction and operation of many devices, it is important to generally understand the concepts of some of the significant protocol standards and models.

One important model that currently guides development efforts is the International Standards Organization (ISO) Open Systems Interconnection (OSI) model. ISO/OSI provides a network framework or model that allows equipment from

different vendors to communicate with each other. The OSI model organizes the communication process into seven different categories or layers and places these layers in a sequence based on their relation to the user. Layers 1 through 3 provide actual network access and control. Layers 4 through 7 relate to the point-to-point communications between the message source and destination.

More specifically, the seven layers in the OSI model work together to transfer communication signals through a network. Layer 1 includes the physical layer meaning the actual hardware that transmits currents having a voltage representing a bit of information. Layer 1 also provides for the functional and procedural characteristics of the hardware to activate, maintain, and deactivate physical data links that transparently pass the bit stream for communication between data link entities. Layer 2 is the data link layer or the technology specific transfer layer that effectuates and controls the actual transmissions between network entities.

For example, layer 2 provides for activation, maintenance, and deactivation of data link connections, character and frame synchronization, grouping of bits into characters and frames, error control, media access control and flow control.

Layer 3 is the network layer at which routing, switching and delaying decisions are made to create a path through a network. Such decisions are made in view of the network as a whole and of the available communication paths through the network. For example, decisions as to which nodes should be

used to create a signal path are decided at layer 3. As may be seen, layers 1,2, and 3 control the physical aspects of data transmission.

While the first three layers control the physical aspects of data transmission, the remaining layers relate more to communication functionality. To illustrate, layer 4 is the transport layer that defines the rules for information exchange and manages the point to point delivery of information within and between networks including providing error recovery and flow control. Layer 5 is the session layer that controls the basic communications that occur at layer 4. Layer 6 is the presentation layer that serves as a gateway (a type of"software"interface) between protocols and syntax of dissimilar systems. Layer 7 is the application layer that includes higher-level functions for particular application services. Examples of layer 7 functions include file transfer, creation of virtual terminals, and remote file access.

Each of the above defined layers, as previously mentioned, are as defined by the OSI model. While specific implementations often vary from what is defined above, the general principles are followed so that dissimilar devices may communicate with each other.

As new technologies emerge for transporting voice and data, the Internet is increasingly being used as a backbone to couple these various networks. Accordingly, a user having a terminal coupled to a local area network might seek to

establish a connection with a wireless terminal that is communicatively coupled to a wireless network that is installed a great distance away. As the Internet is a natural choice for bridging the LAN to the wireless network, systems must be developed that have compatible technological approaches. Accordingly, the structured and layered techniques described above facilitate the integration of the various networks to create a desired communication link.

Traditionally, wireline and wireless communication networks that create the call routing and call set up to establish a communication link include the use of large, monolithic circuit switches that are used for call routing.

While such switches work well in an advanced intelligent network for the public switched telephone network (PSTN), they are not interoperable with Internet Protocol (IP) networks. Stated differently, such switches must transmit signals into a gateway device for conversion to an Internet Protocol for transmission through a separate network (the Internet or IP network). Thus, the circuit switch is not able to provide the call set up and control for the entire communication link, as is its traditional function, if the communication link includes the Internet. The circuit switch is only able to provide control for the portion of the communication link that includes the PSTN.

Current circuit switch technology reliably routes calls from telephone to telephone through a communications network.

A typical monolithic circuit switch is formed to have the

capacity for routing and connecting large number of calls.

With today's rapidly expanding telecommunication industry, with the convergence of circuit switched and packet switched networks (exemplified by the Internet), and the requirements to support plurality of access technologies such as PSTN, wireless, DSL, cable modem etc., current circuit switching systems are not adequately flexible to reliably create communication links according to the needs of the user.

As these many different types of networks and technologies develop, an ever increasing need is to not only create gateway systems that allow communication signals to be transported across the networks, but also to provide multi- network signal transportation with certain QoS requirements..

For example, voice and other real time applications can only tolerate a minimal amount of delay without making the signal quality at the destination point unacceptable. One issue, however, is that the different network domains are owned and operated by different entities. Thus, it is difficult for an operator of any one network to have the control necessary to guarantee a bandwidth that is required for a given set of communication signals. Given that the Internet is becoming a backbone of communication networks to interface other networks to create multi-network communication networks, a need exists for a method and apparatus that provides Internet based call setup and control while also maintaining compatibility and interoperability with the conventional monolithic circuit switches. Moreover, a need exists for

Internet based call setup and control that satisfy end to end (ETE) QoS requirements for specified communication signals.

As the Internet becomes a backbone of multi-network communication networks, it is envisioned that congestion will be experienced on occasion thereby limiting the QoS of the voice and other real time applications. There is, therefore, a need realized by the present inventors to implement a quality of service scheme to assist the network provider in assigning priority among the various users and applications competing for the scarce communication network resources.

One problem, however, is that the present packet or IP networks do not contain provisioning for quality of service schemes that can be used across the multiple networks.

Accordingly, while there is a need to establish an ETE quality of service mechanism under that is system wide. It is desirable, if possible, to implement a QoS system that meets the ETE delay, jitter, and packet loss requirements for a given set of communication signals across the multiple networks.

SUMMARY OF THE INVENTION The present invention provides for a method and apparatus that provide end-to-end (ETE) quality of service (QoS) in a Softswitch-based network for voice and other real time applications. More specifically, in a packet or Internet Protocol (IP) network that consists of a Softswitch or call agent to set up and route the voice and other real time applications. A universal QoS manager (UQM) is formed to work with the call agent, gateways and routers to provision, control, and guarantee the ETE delay, jitter, and packet loss of voice and other real time applications.

The UQM consists of the following five components: Bandwidth Manager, Policy Engine, Real Time Performance Monitor, Admission Controller, and Bandwidth Broker. In order to guarantee QoS requirements for a given signal, the UQM first statically allocates bandwidth to different classes of applications to provision the QoS. The UQM monitors the performance of the packet or IP network in real time and performs call admission control to control the QoS.

Additionally, the UQM dynamically allocates bandwidth to certain applications to guarantee the QoS for those applications.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a functional block diagram of an SS7 telecommunication network that coupled through a SS7 gateway to communicate over the Internet or an IP network with a Softswitch (call agent) formed according to one embodiment of the present invention.

Figure 2 is a system diagram illustrating a UQM with a Softswitch (call agent) constructed and operating according to the present invention.

Figure 3 is a functional block diagram of a portion of a communication network including a call agent according to one embodiment of the present invention.

Figure 4 is a functional block diagram illustrating a typical wireless network coupled to communicate with a plurality of wireless terminals as well as with other devices by way of the IP network.

Figure 5 is a functional block diagram of a UQM according to one embodiment of the present invention.

Figure 6 is a functional block diagram of a universal QoS manager formed according to one embodiment of the present invention.

Figure 7 is a functional block diagram of multiple networks coupled to transport a signal having a specified ETE QoS requirement.

Figure 8 is a flow chart that illustrates a method for establishing a voice call over the Internet according to one embodiment of the present invention.

Figure 9 is a flow chart that illustrates a method for establishing a communication link for voice or other real time applications over the Internet according to one embodiment of the present invention.

Figure 10 is a flow chart illustrating a method performed in a UQM of allocating resources for improving ETE performance in a communication network.

Figure 11 is a functional block diagram that illustrates a network in which call admission control is performed based upon estimated ETE transmission time with respect to specified delay budgets.

DETAILED DESCRIPTION OF THE DRAWINGS Figure 1 is a functional block diagram of an SS7 telecommunication network that coupled to communicate over the Internet or an IP network with a Softswitch (call agent) and a universal quality of service manager (UQM) formed according to one embodiment of the present invention.

Referring now to Figure 1, a telephone 10 is coupled to a Signaling Point (SP) 100 that is for creating a trunk (voice/data communication link) with a destination SP. For exemplary purposes, the destination SP is SP 104. The destination SP 104, in turn, connects the call to called party phone 20. SP 100 and SP 104 are coupled directly by a trunk 108. Trunk 108 is a line that physically couples and carries conversations and data from SP to SP. It should be understood, of course, that a communication link might comprise three or more SPs wherein a plurality of trunks would be used to create a communication link from calling party phone 10 to called party phone 20.

SP 100 is also coupled to a Service Switching Point (SSP) 112 and to a Signal Transfer Point (STP) 116 by way of the IP network 130 and a signaling gateway 134. STP 116, in turn, is coupled to STP 120 as well as STPs 124 and 128. In the prior art systems, STP 116 is coupled to a Service

Control Point (SCP 132). An STP is a SP that runs SS7 Transaction Capabilities Application Part (TCAP). It is capable of supporting service control point (SCP) database operations, halting call progress and other operations. It can run in end offices, tandems, or access tandems. The STP runs the SS7's Message Transfer Part (MTP) and the Signaling Connection Control Part (SCCP). The STP only interfaces with SS7 links and does not interface with voice or data links.

The SCP is also a SP that provides data base support operations to another SCP or SSP. In the described embodiment of the invention, a call agent 140 and a service controller 150 provide routing and feature information traditionally provided by STP 116 and SCP 132. Signaling gateway 134 is for transmitting signaling messages to the call agent in an IP packet format. UQM 160 evaluates the call setup signaling that is received for a call being set up. UQM 160 evaluates network conditions, the class of service for the call and the call's quality of service requirement. Based upon these determinations, UQM 160 determines whether to accept the call and what route and network resources should be assigned to the call.

Thereafter, UQM 160 provides the results of its analysis to call agent 140. Call agent 140 sets up the call in a manner that is responsive to the determinations made by UQM 160.

In operation, when calling party 10 dials the digits to place a call to called party 20, the SP 100 communicates with STP 116 which in turn communicates with call agent 140, via a signaling gateway, instead of SCP 132 to obtain routing information for the call. Call agent 140 then returns the specific control and routing information to SP 100, via a signaling gateway to direct it to establish a trunk 108 with SP 104. Without the query to the call agent 140, SP 100 does not know that called party is connected to SP 104. Thus, the query is necessary to determine what trunk line should be selected for routing the call.

The signaling messages that are routed and performed by STP 116 are, therefore, a critically important part of setting up a call. Accordingly, as may be seen, STP 116 also is coupled to STPs 124,128, and 120. The network of STPs enables ultimate signal message routing in the event of a failure of a communication link. Accordingly, SP 100 is able to obtain the information that it needs to set up the call even if a signaling link failure occurs along the path between SP 100 and call agent 140.

With respect to STP 116, the examples herein illustrate the process steps for setting up a call in an SS7 network that is coupled to call agent 140. Because telecommunication service providers have and are continuing to invest

significantly in the above described equipment to create a reliable telecommunication infra-structure, any new systems that are formed to route calls and establish communication links must be formed to be compatible with such existing systems even if the new systems are capable of performing all setup and routing tasks without the assistance of current systems.

Accordingly, as may be seen, call agent 140 that is formed to set up communication links through any of the known types of communication networks is coupled to STP 116 to operate in tandem with the present call control and set up technologies. In the future, however, the STP-to-STP link 108 may be wholly replaced by a plurality of call agents 140 and signaling gateways coupled to communicate over the Internet.

Call agent 140 is capable of receiving a communication signal transmitted in a format defined by a first protocol through IPST Adapter 142 (e. g., SS7 signaling) and to transmit the data within the received signal in a format defined by a second protocol (e. g., an voice over IP protocol such as H. 323, MGCP, SIP, etc.). Additionally, call agent 140 is formed to also determine call routing. Thus, call agent 140 is capable of transmitting and receiving signals through any known network type.

While Figure 1 illustrates call agent 140 being coupled to the SS7 network through a gateway adapter 142, it also has a plurality of gateway devices that enable it to communicate with a plurality of different systems or networks. For example, call agent 140 of Figure 1 includes gateway adapters 144,146 and 148. It is understood of course, that any number of gateways devices may be formed within call agent 140 and that the invention is not limited to just four gateway adapters. As will be explained in greater detail below, call agent 140 is operable to receive communication signals (data packets) from any one gateway device and to output the communication signals (data packets) on any other gateway device. Thus, call agent 140 is able to translate from any protocol used to receive a communication signal to an appropriate protocol for transmitting the communication signal.

Moreover, as will be explained in greater detail below,. call agent 140 also is formed to communicate with UQM 160 and to provision, control, and guarantee the QoS of the voice call and other real time applications. As a part of determining call routing, call agent 140 decides which output port should be used for a communication link that is being set up. Accordingly, call agent 140 operates as a central call control device or router for a large number of networks.

Additionally, call agent 140 includes communication modules for translating between the various communication protocols for all known types of communication networks and systems.

Figure 2 is a system diagram illustrating a UQM constructed on an IP network with a call agent and operating according to the present invention. A call agent 202 coupled to the IP network 204 and converses with all other devices using one or more packet switched protocols supported by the IP network 204. A telephone network 206 (which may be the public switched telephone network"PSTN") or another telephone network couples to the IP network 204 via a gateway 208. Further, a wireless network 210 couples to the IP network 204 via a gateway 212. The manner in which the IP network 204 (or other packet switched networks) couples to the telephone network 206 and to the wireless network 210 is generally known. Thus, the interaction between the IP network 204 and the other networks 206 and 210 will be described only as it relates to the present invention. The structure illustrated in Figure 2 is an exemplary structure.

Other structures may be constructed and operate according to the present invention to support time keeping and expense tracking operations.

Computers 214 and 216 couple to the IP network 204 and may interact with the call agent 202 through this connection.

While computer 214 has a direct connection to the IP network 204, computer 216 must access the IP network via an Internet Service Provider (ISP) 218. Many users currently access the IP network via an ISP, as illustrated with the connection for computer 216. However, some computers currently access the IP network via an Intranet or other coupling network. In this construction, an ISP may not be required. Further direct connections to the Internet are already possible such as shown with computer 214. Thus, simply stated, the structure illustrated in Figure 2 provides a platform of operation for the present invention but must not be constructed to limit the teachings of the present invention.

Traditional PSTN telephones 224 and 226 couple to the telephone network 206. The telephone network 206, as was previously described, may be the public switched telephone network, which transmits data in a pulse code modulation (PCM) format. In another embodiment, the telephone network 206 may be a packet switched network that supports packet- based communications. The teachings of the present invention, therefore, apply equally well to current or future telephone network technology.

Wireless multimedia terminals 220 and 222 and wireless phone 221 wirelessly connect to the wireless network 210.

The wireless network 210 may be cellular based, satellite

based or otherwise structured to provide wireless communication service within a service area. Wireless multimedia terminal 222 is a portable computer that services communications over a wireless link to the wireless network 210. Wireless devices 220 and 221 are personal voice and data devices that wirelessly communicate with the wireless network 210. The wireless network 210 communicates with the IP network 204 via the gateway 212.

A local area network/wide area network (LAN/WAN) 228 couples to the IP network204 via a firewall 230. At least one computer terminal, e. g., computer 232, couples to the LAN/WAN and may communicate with the call agent 202 via the LAN/WAN 228 and the IP network 204. A company, a service provider, or another organization may support the LAN/WAN.

According to the present invention, pluralities of users access the call agent 202 via differing communication paths and using differing terminal devices in order to set up a voice call or other real time application. Because the call agent 202 is accessible from any location having IP network 204 access, the call agent 202 provides ubiquitous service worldwide. Additionally, as described in the text of Figure 2, call agent 202 includes gateways 242,244,246, and 248 for coupling the call agent 202 to the IP network and to other systems and networks. Finally, as may be seen, call

agent 202 communicates through a port 249 with a service controller 250 (or various systems in a service control plane 250).

Continuing to refer to the multiple networks of Figure 2, each network has its own propagation, queuing, processing delays, jitter conditions and packet losses for calls being transported through the wireless network 210as well as when they are transported through the IP network. UQM 260 is operable to transmit signals and measure response delays, jitter conditions, and packet losses to determine what the current total delays are from the network conditions.

Additionally, if by way of example, the communication signals are being transmitted through IP network 204 to firewall 230 and then through local area network/wide area network 228 to terminal 232, UQM 260 further is operable to determine the total delays, jitter conditions, and packet losses from IP network 204 to terminal 232. Thus, by summing the approximate delays, jitter conditions, and packet losses through the networks outside of IP network 204 and by evaluating the end to end requirements for the communication signals being transmitted there between, UQM 260 may provision, control, and allocate and guarantee the amount of resources (bandwidth) needed for the voice call or other real time applications to be transmitted through IP network 204,

and more particularly, from gateway 212 to firewall 230 in the present example.

The various delays, jitter conditions, and packet losses vary not only according to network conditions, but also according to the type of terminal being used. For example, PDA 221 may not be able to exchange signals with the wireless network as fast as wireless terminal 222. Thus, UQM 260 evaluates in one embodiment, the actual delays, jitter conditions, and packet losses for the terminals for which the communication link is being established.

Figure 3 is a functional block diagram of a portion of a communication network including a call agent according to one embodiment of the present invention. Referring now to Figure 3, a network 300 includes a call agent 314 is coupled to communicate with a plurality of gateways from a plurality of different network types. Call agent 314 further includes a universal quality of service manager 308 that assists in provisioning, controlling, and allocating network resources to guarantee the required QoS for voice and other real time applications.

Many different types of gateway systems may be coupled to the call agent 314. Each of these gateways may use different communication protocols for setting up voice calls or other real time applications over the IP network.. For

example, in the network portion of Figure 3, call agent 300 is communicatively coupled with an H. 323 gateway 302, a Media Gateway Control Protocol (MGCP) gateway 304, a Network Call Signaling (NCS) gateway-306, an Internet Protocol Device Control (IPDC) gateway 308, an Internet Protocol Signaling Transport (IPST) gateway 310, a Session Initiation Protocol (SIP) gateway 312, a MEGACO gateway, and an ATM signaling gateway. In general, each of these gateways is IP based and is for controlling either call signaling, call trunking (trunk device control) or both. As may be seen, an Internet 336 and a public switched telephone network 340 including SS7 and other intelligent networks are coupled to communicate with call agent 300.

While call agent 300 suggests that UQM 316 is formed within there within, it should be understood that UQM 316 may be formed external to the call agent and may, itself, communicate with call agent 300 by way of the IP network or another network. In operation, UQM 316 is operable to evaluate, provision, and control all calls for which call set up signals are received to determine whether the required quality of service can be provided for the voice call or other real time application requests. Additionally, UQM 316 may allocate bandwidth (resource) along the route of the IP network to achieve the required quality of service for the

voice call or other real time applications. Additionally, if the call must also be routed through another network, such as wireless network 210 of Figure 2, then UQM 316 estimates the delay budget within the wireless network as a part of determine whether the call's quality of service requirement may be satisfied, and then do the call admission control based on the delay budget estimation and current IP network performance monitoring. As a part of determine whether the call's QoS requirements may be satisfied, UQM 316 determines the path routing using the QoS based routing through the IP network that provides a leg that enables the QoS requirements to be met.

The process of determining whether a QoS requirement can be satisfied includes evaluating current network performance, QoS required for the call, contractual arrangements between the calling parties and the service provider (s), and the type of data being transmitted. For example, voice, data are less tolerant of propagation delays and jitter than file data.

The present invention thus facilitates the development of Voice over IP by creating a quality of service management scheme that is executed by UQM 316 in conjunction with call agent 314.

As may be seen, call agent 300 is formed to have an architecture that can be easily adapted to communicate with

future devices using currently unknown or undeveloped protocols. Thus, to render call agent 300 capable of communicating with a new protocol, its architecture is designed to allow the addition of modules than can translate the new protocol to an internal protocol that is used by the call agent to perform its call setup/teardown and routing functions. These gateways also are formed to control Voice over IP.

As was described before, the UQM 316 is operable to provision, control, and guarantee the QoS within the IP network through which a call is to be connected, and to guarantee the ETE QoS by using the delay budget estimation for the other networks that the call is to be connected ETE and to do the call admission control.

Figure 4 is a functional block diagram illustrating a typical wireless network coupled to communicate with a plurality of wireless terminals as well as with other devices by way of the IP network. One purpose of Figure 4 is to illustrate a typical wireless access network so as to identify some of the QoS parameters that may be expected therein.

For example, a communication signal being transmitted by wireless terminal 402 would experience delays as it is transmitted from 402 to a tower 404. The signals are then

received by tower 404 and transmitted to base station subsystem 406 where they are processed and forwarded to radio access network (RAN) 408. From RAN 408, the signal may be transmitted to an IP router 410 within the IP network 412.

While not explicitly shown, the communication signals may be transmitted to and through a gateway device prior to being transmitted to the IP network. The gateway device would then convert the communication signals from the wireless network into an appropriate data packet format with header for transmission through the IP network. Thus, transmission delays through the gateways will also be experienced. Call agent 414 and UQM 416 are also coupled to IP network 412 to provide call routing based upon-network conditions are defined QoS requirements for the call or real time application that is to be transmitted by way of IP network 412.

Figure 5 is a functional block diagram of a UQM according to one embodiment of the present invention.

Referring now to Figure 5, a UQM 500 includes a processing unit 504, a memory 508 and temporary memory 510. Each is connected to an internal bus 512. Internal bus 512 further is connected to a bus controller 516 that controls the timing, synchronization, and more generally, the bus communications on bus 512.

Memory 508 includes computer instructions that define the operational logic of UQM 500 as well as logic for determine path routing and call acceptance based upon network conditions, allocate bandwidth, reserve network resources, etc.

Memory 510 includes temporary memory buffers for storing operational data created or received during processing.

Processing unit 504, therefore, communicates with memory 508 by way of bus 512 to receive the computer instructions and memory 510 for obtaining temporary data stored therein.

Processing unit 504 then executes the computer instructions within memory 508 and operates upon the data stored within memory 510 to effectuate the operational logic defined by the computer instructions stored within memory 508.

Bus controller 516 further is coupled to a plurality of network interface ports 520,524 and 528 for communicating with external devices. By way of example, network interface port 520 may be for communicating with a gateway device, while network interface port 524 may be for communicating with a call agent. Port 528, on the other hand, may be for communicating with a router. Moreover, as is understood, any one port may be used for communicating with any external device at any given instant. While Figure 5 illustrates only three network ports, it is understood that the UQM of Figure

5 is not limited to three ports and may be a great number of ports for supporting the topology shown in Figure 1.

Continuing to refer to Figure 5, memory 508 includes computer instructions that define operational logic that create a bandwidth manager function, a bandwidth broker function, a real time performance monitor function, a policy engine and an admission controller function. Each of these logical functions operate with each other to define the operation of the UQM 500.

The bandwidth manager defines network bandwidth (resource) to be allocated to different classes of service (CoS), so that the delay sensitive traffic such as voice is given higher priority in processing and routing. One benefit of such functionality is that it can provision the network traffic and lead to more predictable overall network performance and to guarantee the QoS for voice call and other real time applications.

The policy engine creates a database directory to store service level agreements for use by the bandwidth manager to statically allocate bandwidth for different classes of service. The policy engine further defines rules that define the criteria for establishing routes, whether to accept a call, and if so, rules regarding what resources are to be assigned to the call being setup. These rules further define

policy for use by the admission controller function to determine whether to accept a call. For example, the computer instructions may define logic to prompt the admission controller to determine from the policy engine to not admit a call whenever one of the required communication links experienced eighty percent utilization in a last time period having a defined length.

The real time performance monitor function monitors real-time QoS related performance parameters over the entire IP network (e. g., Internet). More specifically, the real time performance monitoring function monitors the network load, link utilization, packet loss ratio, ETE delay, and jitter. Additionally, it monitors performance of networks that are upstream and downstream relative to the Internet in the communication path for the communication signals being transmitted across the multi-networks for the call that is being set up.

The admission controller function communicates with the real time performance monitor to receive network performance data or ratings to enable it to make decisions on whether to accept a call, whether to reroute the call through another network or through a portion of the IP network that is under the control of another call agent, and other similar

decisions. These decisions are made for the next defined period of time.

The bandwidth broker function executes inter-domain service level agreements (and/or peering contracts) to lease or obtain network resources so as to guarantee the ETE QoS for voice call and other real time applications.

Each of the above five listed functions are defined by computer instructions stored in memory 508 of UQM 500. The operational logic defined by these computer instructions are described in further in the discussion of the method and process steps described herein this application that relate to the present invention. In general, however, processing unit 504 executes the computer instructions within memory 508 to provision, control, and guarantee the QoS for a voice call or other real time application being set up.

Figure 6 is a functional block diagram of a universal QoS manager formed according to one embodiment of the present invention. While Figure 5 illustrates a UQM whose functionality is defined by computer instructions executed by a processor, the UQM of Figure 6, is formed in hardware. It is understood, of course, that the UQM may also be formed to comprise a combination of hardware defined logic as well as software-defined logic that is to be executed by a processor.

Figure 6 also better illustrates the interaction among the various components of the system.

As may be seen from examining Figure 6, UQM 600 includes a real time performance monitor 604 that is coupled to communicate with gateways 606 and IP routers 608 to determine network performance in real time. Real time performance monitor 604 further is coupled to admission controller 612 to transmit performance ratings/observations thereto for its call admission determinations.

Bandwidth manager 620 is coupled to communicate with policy engine 624 to statically allocate bandwidth to different classes of traffic. As may be seen, real time performance monitor 604 also is coupled to gateways 606 and IP routers 608 to evaluate network conditions. In addition to being coupled to bandwidth manager 620, policy engine 624 also is coupled to admission controller 612 to provide admission policies thereto based upon specified network conditions. Thus, admission controller 612 is also coupled to call agent 628 to provide call determinations thereto.

Bandwidth broker 616 is coupled to receive performance data from the real time performance monitor and is formed to dynamically allocate bandwidth and to make admission control determinations. Based upon the performance and allocations, bandwidth broker 616 is able to determine whether to secure

or lease network resources in a manner to strive to maximize efficiency while satisfying ETE QoS requirements of the voice call or other real time applications. Further details of the operation of UQM 500 and UQM 600 are provided by a description of the inventive methods and system operation provided in the subsequent description of the figures.

Figure 7 is a functional block diagram of multiple networks coupled to transport a signal having a specified ETE QoS requirement. For exemplary purposes, a call is originated in a first network, namely a wireless network, and is transported through a second network, namely, an IP network or Internet, and then is terminated within a third network, namely, a public switched telephone network. A mobile station 704 is coupled to communicate with wireless network 708 through antenna 712. Wireless networks 708 is coupled to gateway 716 that forms an interface between the first and second networks. Gateway 716 then is coupled to a router 720 that, in turn, is coupled to routers 724,728 and 732. Router 728 also is coupled to gateway 736 that forms an interface between the second and third networks.

Gateway 736 also is coupled to a public switched telephone network 740 that is for routing calls to and from telephone 744. Thus, an end-to-end communication link may be established between mobile station 704 and telephone 744 by

way of the first, second and third networks of Figure 7. The ETE QoS requirement for the call, therefore, is provisioned and controlled by a UQM 748 as part of deciding whether call agent 752 should accept the call and what route through the second network should be assigned to the call based upon current network conditions. Further, UQM 748 guarantees the ETE QoS of the call as it allocates required bandwidth (resources) in the IP network between gateways 716 and 736 to the call being set up.

In operation, gateway 716 generates call setup signals that are received by call agent 752 and UQM 748. UQM 748 evaluates current network conditions and the ETE QoS requirements for the call that is being set up to determine if the network resources are available for the call's QoS requirements to be satisfied.

In one embodiment of the present invention, UQM 748 examines network loading for each leg of the second network in relation to the amount of time that is needed for the transportation of the signals through the second network to determine whether the call should be admitted for the next defined time period.

For example, if the available routers and links for a given QoS requirement is as shown in the second network of Figure 7, then the UQM 748 will evaluate which routes may be

used to meet the ETE QoS requirements given detected levels of congestion. For example, if the policy engine dictates that a link exceeding 80% loading may not be used for a call having an ETE delay or packet loss requirement of a specified value, then a set of routes are defined that do not include links that, in a most recent time period, exceed the 80% loading condition.

For example, if link 5 experienced an 83% loading condition and all the other links have less than 80% loading condition, then the available route paths include a path formed of links 1,3 and 7 and of links 1, 4,6 and 7. If, on the other hand, link 7 experienced the 83% loading factor, then the call is rejected for the next time period. In one embodiment, a typical time period for these types of evaluations is 100 milliseconds. It is understood, of course, that differing time periods may be used.

Additionally, whether a call may be setup is a function of the current network condition and the call's QoS requirements. As explained elsewhere, bandwidth or network resource is reserved for differing classes of service. Thus, a call may be rejected even when the total resources are available but the resources for the particular class of service are not available.

If UQM 748 determines that network resource is available that satisfies the ETE QoS requirements for the call, it advises the call agent 752 that the call may be accepted. It also transmits the available path route information.

Additionally, it transmits, in one embodiment, signals to the gateway 736 between the second and third networks to prompt it to begin setting up the call through the third network to the destination telephone 744.

Figure 8 is a flow chart that illustrates a method for establishing a voice call over the Internet according to one embodiment of the present invention. Initially, prior to a UQM receiving a call set up signal requesting resources for a call, the UQM examines a list of routes that are available in a portion of the Internet over which it has control (step 804). A UQM typically is allocated a group of IP routers and their communication links. Alternatively, however, a UQM may also be formed to control all communications over a particular data packet network or Internet.

After determining what routes and routers are within its control, the UQM groups available routes and resources into a plurality of classes of service (step 808). The method of allocating throughput resources is defined logically either in the UQM hardware or by computer instructions stored within the UQM. Alternatively, the computer instructions, in one

embodiment, define an interactive process to receive and store allocations that are defined by an operator. The operator-defined allocations may be entered either in real time or put into a computer readable file that is downloaded into UQM memory. It is understood, of course, that even a UQM whose operational logic is defined in hardware, such as that shown in Figure 6, includes memory for storing data and operational parameters although such memory is not explicitly shown in the figure.

Thereafter, the UQM is able to receive call set up signals and to set up calls over the data packet network within its control. Accordingly, the UQM receives a call setup signal for processing (step 812). Upon receiving a call setup signal, the UQM analyzes the class of service for the call (step 816). Based upon the call's class of service rating, the UQM determines what routes are available for the call (step 820). Once the UQM has determined a route that may be used for the call, it sends routing information to a call agent to advise it to accept the call and what the corresponding route should be for the call (step 824).

Figure 9 is a flow chart that illustrates a method for establishing a communication link for voice or other real time applications over the Internet according to one embodiment of the present invention. Initially, prior to a

UQM receiving a call set up signal requesting resources for a call, the UQM examines a list of routes that are available in a portion of the Internet over which it has control (step 904). A UQM typically is allocated a group of IP routers and their communication links. Alternatively, however, a UQM may also be formed to control all communications over a particular data packet network or Internet.

After determining what routes and routers are within its control, the UQM groups available routes and resources into a plurality of classes of service (step 908). The method of allocating throughput resources is defined logically either in the UQM hardware or by computer instructions stored within the UQM. Alternatively, the computer instructions, in one embodiment, define an interactive process to receive and store allocations that are defined by an operator. The operator-defined allocations may be entered either in real time or put into a computer readable file that is downloaded into UQM memory. It is understood, of course, that even a UQM whose operational logic is defined in hardware, such as that shown in Figure 6, includes memory for storing data and operational parameters although such memory is not explicitly shown in the figure.

Thereafter, the UQM is able to'receive call set up signals and to set up calls over the data packet network

within its control. Accordingly, the UQM receives a call setup signal for processing (step 912). Upon receiving a call setup signal, the UQM analyzes the class of service for the call (step 916). As mentioned previously, resources (routes) are reserved for the various classes of service.

Once the UQM receives a call setup signal and determines the calls CoS, it then begins evaluating network performance (step 920). More specifically, the UQM evaluates the link utilization of the routes that are available for the call (step 924). In one embodiment, the link utilization is evaluated with respect to the CoS of the call. Additionally, in one embodiment of the invention, the UQM evaluates the network loading as a part of step 924. Additionally, it evaluates the loss ratio and the transmission quality (step 928) and, finally, the ETE propagation delays (step 932).

An analysis of and response to detected link utilization may be may varied according to network operator design requirements. In the described embodiment, each UQM builds a centralized VoIP routing table for each gateway pair and defines a plurality of routes between the pair of gateways.

Then, as a part of measuring link utilization and responding thereto, the UQM determines call admission/routing based upon the measured link utilization value. In the described embodiment, if the link utilization for a select route is

less than a certain threshold for a call that is to be setup, the call is allowed to be setup for the select route.

In the described embodiment of the invention, each of the network performance metrics described above is monitored on a periodic basis, namely, once every 100 milli-seconds.

In another embodiment, the monitoring for each of the metrics occurs once every second. In yet another embodiment, some metrics are measured more frequently than others. For example, in one embodiment, overall network loading is measured only once per second while transmission quality is measure every 100 milli-seconds. Each of the metrics described above are the metrics of the described embodiment of the invention. Only some of the above metrics may be used either alone or in combination with metrics not listed above as a part of the present invention.

Each of the examined performance metrics is then compared against policy rules as a part of determining whether to route, re-route or reject the call for the next defined period of time (step 936). In the described embodiment of the invention, a policy engine is used to store policy rules for use in relation to the measured network metrics.

Based upon the call's class of service rating and the corresponding policy rules that define resource allocation

based upon the measure network metrics, the UQM determines what routes are available for the call (step 940). Once the UQM has determined a route that may be used for the call, it sends routing information to a call agent to advise it to accept the call and what the corresponding route should be for the call (step 944). Generally, the UQM sends routing information to the call agent only if the required QoS can be satisfied for the call being setup given the network conditions and the comparison thereof to the specified policies of the policy engine. If the QoS requirements cannot be satisfied, the call is rejected for that instant.

At a next increment of time, the UQM re-evaluates whether the call can be accepted and routed while satisfying QoS requirements for the call.

Figure 10 is a flow chart illustrating a method performed in a UQM of allocating resources for improving ETE performance in a communication network. The initial step is to evaluate network performance, not only for the last defined period of time, but also a network performance history over a larger defined period of time (step 1004).

For example, the UQM may evaluate network performance in one- hour increments over a period of a week to determine if there are periods during the week in which resources are underutilized or whether there are period in which additional

resources need to be obtained. More specifically, this analysis is performed for each class of service and its defined resources (step 1008). If possible, the UQM reallocates CoS reservations to adjust throughput resources for the various CoS ratings to improve network efficiency (step 1012).

If the UQM cannot adequately modify its allocated resources to meet desired levels of efficiency as well as ETE traffic demands, the UQM generates communication signals with other network providers to borrow/lease bandwidth (step 1016). If resources are leased to or from other providers, the UQM then redefines is CoS reservations to reflect the changes (step 1020).

Figure 11 is a functional block diagram that illustrates a network in which call admission control is performed based upon estimated ETE transmission time with respect to specified delay budgets. In general, if the source of a transmission must connect the destination via n ISPs as shown in Figure 11 and each of the ISPi has a delay budget di, and the Source Access Network and the Destination Access Network have delay budget dsource and dudest respectively (dsource+ dl+ d2+... +dn+ ddest = ETE Delay Budget). Then, each of the Admission Control processing for ISPi must accept/reject a call setup request by following algorithm:

1) If dsource can be guaranteed in the Source Access Network, then GW 1 (Gateway 1) will pass a message to Admission Control 1 to do ISP 1 domain admission control; Admission Control 1 will do the following: if d can be guaranteed, then Admission Control 1 will let GW 2 to inform Admission Control 2 to do ISP 2 domain admission control; if d can not be guaranteed, then Admission Control 1 will let GW 1 to inform the Source Access Network to reject the call setup request 2) Admission Control i will do the following: if d can be guaranteed, then Admission Control i will let GWi+1 to inform Admission Control i+1 to do ISPi+1 domain admission control ; if di can not be guaranteed, then Admission Control i will let GWi inform the Admission Control i-1 to reject the call setup request, which will then send the reject message all the way to the Source Access Network 3) If dudest can be guaranteed in the Destination Access Network, then GWn+1 (Gateway n+1) will pass the acceptance message through Admission Control n, GWn,..., Admission Control 1, GW1, Source Access Network, and each Call Agent will also do the call, setup in its ISP domain, so that an ETE call setup can be established; If dudest can not be guaranteed in the Destination Access

Network, then GWn+1 (Gateway n+1) will pass the reject message all the way back to the Source Access Network.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and detailed description. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the claims. The operation of Figures 1 and 2, for example, may be viewed in tandem with the operations and functions of the call agent as explained in Figures 3 through 10.

As may be seen, the described embodiments may be modified in many different ways without departing from the scope or teachings of the invention. For example, a call agent may be formed to include some of the service control features that present are formed within distinct and separate platforms. Additionally, a different internal protocol may be used from the one chosen by the inventors herein.

Moreover, one creating a call agent or system implementing the call agent may chose to have a different combination of protocol conversion modules.