Background
Telecommunications networks have long been provided with a single service to subscribers by a single service provider. However, in the last 20 years telecommunications networks have changed greatly and will continue to evolve, so that there are currently multiple providers offering a variety of different levels of service. For example, data transmission methods and protocols include Internet Protocol (IP), Asynchronous Transfer Mode (ATM), frame relay, and digital telephony. Similarly, a wide variety of transmission means are used by a wide variety of service providers in the long distance voice telephony market, including analog, digital and digital compression methods, including cable, wireless, fiber optic and satellite transmission means. The networks of these service providers are interconnected to form a larger heterogeneous network.
Determining the best way to communicate between two points on such a communication network is a complex task requiring consideration of price, quality and available services according to communication requirements. There is no system available to determine the best way to communicate. Attempts have been made to provide solutions for ATM and IP networks, but for reasons which will be described later, it has been shown that these attempts are fundamentally wrong.
It would also be desirable to have a system that optimizes in a dynamic way according to the different needs of the users and the network service providers. This is particularly important for limited bandwidth communication links, such as wireless communications. Of course, such a system is not available.
A telecommunications network is a physically distributed collection of nodes interconnected by links. An example of an end node is a user interface, such as a telephone or a personal computer that generates and consumes data. Examples of intermediate nodes are switches, routers or gateways that forward data from an input link to an output link, some of which may process or store data to provide video conferencing or voicemail services.
Previously, voice and computer data were transmitted over different networks, although both are currently typically transmitted digitally. Since the demands for voice and data transmission are so different that it is difficult to provide both services simultaneously on a common network. For example, voice communications produce a steady stream of data at a relatively low rate, where speed is more important than accuracy. In contrast, data applications such as browsing the world wide web typically produce bursts of data to be transmitted accurately, and delays of one to two seconds are considered acceptable.
Other services may have different requirements for accuracy, delay, and data rate, which are referred to in communications as quality of service (QOS). Ideally, a telecommunication service provider should provide both communication services optimized for a user-specific application, and at the same time provide services to other users on its own network in an optimal manner. Using conventional techniques, this would require the service provider to provide a different quality of service for each new data application communication it develops. No telecommunications system is currently available that can provide different quality of service requirements for different users and applications.
It is desirable to provide a single communication network that simultaneously transmits data and voice over a common physical channel. This reduces the cost and enables resource sharing. This requires that new applications must be able to use these integrated networks, so that they can be developed without creating special telecommunication networks for them.
It is also desirable that the process of developing new applications be as open as possible, rather than confined to a small group of developers who have special knowledge or access to policy-based resource allocation, so that new applications can be quickly merged.
Since service providers lack knowledge of what applications users implement, it is difficult for them to provide products suitable for these applications. It is also clear that it is not possible for a service provider to predict the requirements of an application to be developed. Similarly, service providers are generally insensitive to the computing power (e.g., processor speed, memory capacity, software and operator expertise, etc.) of a given user. Thus, service providers typically offer products that meet only the most common markets, as well as one or two major niche markets. Currently, the user must find the product of the service provider that best suits his needs, if it is really present. A user with multiple needs must list a list of service providers.
Conventional telephone networks provide fixed quality voice services, referred to as charging quality, the price of which is pre-specified. Long distance distributors use digital voice compression to provide low cost long distance services at a lower price, but as such, the services are of fixed quality, with the price being pre-specified. Because competitors offer different voice qualities, prices, and call success rates, end users may choose more expensive and promising service providers to achieve better quality. This approach becomes clumsy when new services are present, and the end-user must select a service provider for each of their applications separately and can only determine their reputation from their verbal representation.
When contention for network resources occurs, conventional telephone systems employ a "first-come-first-served" approach that denies service to callers if insufficient resources are available. This process is called call admission. It is clear that some users may prefer to accept a lower quality communication service and also prefer not to be denied communication. Current telecommunications networks do not provide this option.
The conventional internet provides a "best effort" service, never attempting to prioritize traffic. However, since each service provider may choose different network capacities and connections to other service providers, the end user has some freedom to choose different service providers, indirectly trading off quality and price. However, this is not a flexible or accurate solution.
Packet switching systems, such as the internet, can give different priority to different packets, so that when congestion occurs, high priority packets have an advantage over low priority packets. But the difficulty is how to properly prioritize in large systems with many conflicting requirements.
Packet priority is not usually simply given priority when implemented, since a high-priority stream of large capacity will completely exclude even a smaller capacity stream of low priority. Thus, fairness principles are used to determine the effect of priority, and a particular algorithm called weighted fairness queuing is implemented in internet routers. It takes turns accessing the network links of the priority queue, the priority queue with less capacity gets priority rather than absolutely excluding its access. However, this method still does not determine how to set the packet priority.
Recent Internet protocol extensions allow users to specify that their data be sent with minimal cost or minimal delay by setting specific bytes of the packet header. However, this mechanism is rarely used because there is no mechanism that guarantees parsimonious use of the mechanism. The user can for no reason require that any data is in any case sent with minimum cost and minimum delay, so that the request becomes meaningless. The mechanism is also relatively coarse in that it only allows the user to set two cost levels and it does not allow the user to specify the rate at which data is desired to be generated.
The ATM standard provides a more detailed mechanism to express quality of service parameters. It allows the specification and reporting of the average delay and the maximum delay, allowing the specification of the maximum and minimum data rates. These mechanisms are also rarely used because the user still has no reason to reduce their demand. ATM quality of service mechanisms are therefore suitable for closed telecommunication systems, where parameters affecting the user traffic are set by the service provider.
Policy-based routing is a system that allows a network administrator to define priorities based on various variables, such as source and destination, or protocols used, etc. For example, web browser traffic using the hypertext transfer protocol (HTTP) may be given priority over email traffic using the Simple Mail Transfer Protocol (SMTP).
Internet communications typically result in packets passing through multiple different networks. Typically, each network is managed by a different entity, using mutually different and mutually incompatible policies. Thus, each of the internet policies described above do not provide a practical solution because the packets will inevitably pass through the bottlenecks presented by these mutually incompatible policies.
Even if these policies are coordinated with each other or transmitted through a single service provider, the user is still unable to negotiate how to handle the user data accepted in the network.
Existing systems are unable to provide diverse services for specific performance requirements. For example, telemedicine, where a surgeon performs a surgical procedure using a teleinstrument, cannot be implemented in existing systems. This application requires extremely strict accuracy, timeliness and very high video bandwidth. The consequences of this network are very serious if it cannot be operated as required.
Another example is an internet game, where many players exchange small packets of information to update their movements with each other. Typical implementations of these games require low latency for their applications, but low bandwidth requirements, allowing for a certain rate of packet loss, which these gaming applications are usually designed to tolerate.
When a conflict occurs, it is apparent that the priority of the telemedicine application should be greater than the priority of the internet game. Therefore, there is a need for a systematic way to determine interactivity between various applications.
Therefore, there is a need for a flexible system to resolve contention for resources of a telecommunications network that ameliorates the above-mentioned problems.
Detailed description of the preferred embodiments of the invention
A system that meets the above objectives is represented in the block diagram of fig. 1. Physically, the telecommunications system 10 comprises a first user interface 12 and a second user interface 14, which are interconnected by a telecommunications network 16. The first user interface 12 and the second user interface 14 may be a telephone, a cellular telephone, a personal digital assistant, a personal computer, or a server that generate and consume data. The telecommunications network 16 has at least one transmission method and protocol, which will be described in detail below.
At the software level, the first user interface 12 has a first user agent 18 that represents the benefit of the first user interface 12 in the negotiation of communications between the first user interface 12 and the second user interface 14. Similarly, the telecommunications network 16 has a telecommunications network proxy 20 that represents the benefit of the telecommunications network 16 at the time of the communication negotiation.
The negotiation of the terms of communication is implemented by a software agent called a negotiation manager 22. Physically, negotiation manager 22 may reside anywhere in system 10, and in a simple implementation, it resides somewhere in telecommunications network 16 provided by the first user's service provider.
The functions of negotiation manager 22 are:
1. identifying a participant of the negotiation;
2. implementing a negotiation specification that allows each participant to think about the contract and can accept or modify the contract;
3. in response to a successful negotiation due to execution of the contract.
Broadly speaking, the system 10 provides a flexible telecommunications system that addresses network resource contention issues.
The flexibility of the system 10 is manifested in that new services and new features developed by other departments can be implemented in the negotiation. In current telecommunication systems, all services are provided and controlled by the telecommunication system provider, which limits the number of services available and prevents the emergence of new services. In system 10, end users, such as negotiation managers or other network entities that may benefit relationships in the negotiation, may obtain new negotiation specifications or software agents developed by themselves or third party partners and implemented in the negotiation. Details of this option will be described in more detail later.
The system 10 of the present invention may more generally allow multiple parties to participate in a negotiation for a given communication. The need for this functionality is apparent as the communication process involves two, three or more telecommunications providers spanning a wide geographical range. It is the best way to guarantee the interests of the parties that all network entities participating in the communication are involved in the negotiation.
The system also allows communication between multiple end users, such as conference calls, where all end users and their associated service providers participate in the negotiation.
The system 10 of the present invention encourages service providers to offer more diverse and flexible services and correspondingly improve the effectiveness of their networks. In turn, the increased diversity and flexibility allows users to negotiate the services they need rather than being forced to choose among the limited services offered by the service provider or having to seek a new service provider that provides the desired services.
The system 10 resolves contention among users, provides a wide variety of data and voice communication services suitable for a variety of different applications, and provides incentives such as reduced prices to use available resources rather than insisting on using the highest quality. By providing real-time negotiation of services, participants will be able to reach mutually accepted results.
As described above, the present invention allows the above improvements to be achieved by providing a software agent within the interested parties to negotiate on their behalf. A lesser problem is that this requires the establishment of a negotiation contract that all software agents can understand, although the nature and parameters of the contract are not limitations of the present invention.
An overview of the software layers of the present invention is shown in FIG. 2. All negotiation stakeholders in this figure are labeled with participant 24. In the simple example corresponding to fig. 1, the participants 24 comprise a first user agent 18 and a telecommunication network agent 20. This example is consistent with conventional voice communication modes where the initiating caller is charged a service fee.
However, setting up a proxy in the second user involved in the negotiation will cause the second user to incur some or all of the communication charges. More importantly, this allows the negotiated communication to take into account the benefits of the second user interface 14. For example, if the second user interface 14 does not have a high speed modem as the first user interface 12, there is no benefit in negotiating a high speed connection between the first user interface 12 and the telecommunications network 16.
Similarly, if the telecommunications network 16 includes a plurality of ATM, long distance or frame relay providers, it may be beneficial to include a software agent in each of the negotiation related telecommunications providers. Thus, any network entity of the telecommunication system 10 that has a beneficial relationship to the negotiation result may be a participant 24 of the negotiation.
Participants 24 communicate with negotiation manager 22 using standard default communication protocols to transmit contracts 26 back and forth. Generally, the negotiation involves a single contract 26 that each participant 24 is free to examine and modify using certain specifications, and the contract 26 also includes a portion of the communication contention. The use of a single contract 26 avoids the additional need for coordination and time taken with the use of multiple contracts.
Because the contract 26 is a relatively small data packet, little time is consumed in passing it from one participant 24 to another. The user may also control the size of the contract 26 to some extent by selecting negotiation strategies and parameters. The contention for contract 26 is described in detail below.
Negotiation manager 22 employs negotiation specification 28 in accordance with a set of specification parameters 30. The present invention will be described herein in connection with a particular negotiation specification 28, but is independent of the actual negotiation specification 28 employed.
As described above, the present invention is not limited to negotiating the physical location of manager 22. Typically, it is desirable that negotiation manager 22 be "trusted" by the parties involved, or reside in a secure location, but the negotiation manager's location is not necessarily so if participants 24 would like to be protected by themselves in the negotiation. For example, participant 24 may wish that the offer of contract 26 be cancelable, allowing him to see the last glance before starting to execute the negotiated contract 26. Examples of using other security methods, including cryptographic signatures or authentication lists, are well known in the art.
Since the location of negotiation manager 22 is not limited, it may be provided by a network service provider, the user himself, or a third party. This flexibility is one of the advantages of the present invention as it makes the present invention an open system. A third party may create a negotiation manager 22 or negotiation specification 28 and make it available to all users and network entities of telecommunications system 10.
This openness allows the system 10 of the present invention to mature very quickly, adding new negotiation managers 22 and negotiation specifications 28 with new features. Conventional telecommunication systems limited to a single service provider can only provide services that the single service provider has.
Figure 3 shows a simple operational flow for negotiation manager 22. Negotiation manager 22 identifies participants 24 at negotiation step 32, implements the negotiation specification at step 34, and if the negotiation is successful, executes the negotiated contract terms 26 at step 36.
The identification of the participant in step 32 may be accomplished in a variety of ways. In a simple implementation with two participants 24, namely the first user agent 18 and the telecommunication network proxy 20, the participants 24 are identified by an initial contract 26 created by the first user agent 18, at which time the first user agent 18 initiates a communication request with the second user interface 14. At this point, the initial contract 26 identifies the first user interface 12 as the source and calling parties of the contract 26, the second user interface 14 as the called party, and the telecommunications network 16 as the service provider.
In a more general case, the initial contract 26 still identifies the first user interface 12 as the source and calling parties of the contract 26, and the second user interface 14 as the called party, but leaves the identification task of the participants 24 at the level of the telecommunications network 16 to the negotiation manager 22. Negotiation manager 22, identifying a service provider from the database, will give the service provider an incentive to find negotiation manager 22 because negotiation manager 22 will not have the service provider participate in the negotiation at all if the service provider is not present in the database of negotiation manager 22. Methods of creating, accessing and maintaining databases about service providers are well known in the art.
The implementation of the negotiation profile 28 at step 34 will be described in detail in connection with the example of the loop profile in fig. 7. For purposes of fig. 3, the negotiation specification 28 is intended to contain a policy that allows each participant 24 to be satisfied with the agreement 26. In the simple case of fig. 1, in the negotiation specification 28, the negotiation manager 22 only has to be responsible for passing the contract 26 back and forth between the first user agent 18 and the telecommunications network proxy 20 without any intervention. At this point, the first user agent 18 times out to terminate the negotiation if the contract 26 is not successfully negotiated within a given period of time.
If the initial contract 26 proposed by the first user agent 18 is acceptable to the telecommunications network broker 20, the telecommunications network broker 20 agrees that the contract 26 is returned to the negotiation manager 22 unmodified. Details of how the telecommunications network broker 20 analyzes and responds to the contract 26 are described below in conjunction with fig. 4 and 8.
At step 36, negotiation manager 22 determines whether contract 26 negotiates successfully, and if so, allows the contract 26 to be executed. The successfully negotiated contract 26 may be marked by setting a flag bit in the contract 26.
The flow chart of fig. 4 describes the operation of the telecommunications network proxy 20. As described above, the goal of the telecommunication network broker 20 is to represent the benefits of the telecommunication network 16 in the negotiation of communications between the first user interface 12 and the second user interface 14. Since the telecommunications network 16 has at least one telecommunications mode and protocol, it may be desirable to optimize the efficiency of using resources.
The operation of the telecommunications network proxy 20 is straightforward. At step 38, telecommunications network proxy 20 receives contract 26 from negotiation manager 22. In a first recursion of the simple example depicted in FIG. 1, the contract 26 contains information provided by the first user agent 18, as described above. At step 40, the telecommunications network broker 20 examines the contents of the contract 26 and determines whether to accept.
If the terms of contract 26 are unacceptable, telecommunications network proxy 20 modifies the terms of contract 26 to an acceptable point and returns contract 26 to negotiation manager 22 at step 44. In the simple case where the telecommunications network 16 has only a very limited set of resources, the telecommunications network broker 20 may comprise a simple algorithm to generate new contract terms 26 with reference to a database of resources and standard rates.
In a more complex implementation, the telecommunications network broker 20 comprises a rule-based broker to optimize the use of the resource closure set. For example, if the telecommunications network 16 has access to ATM services, Continuous Bit Rate (CBR) transmission from 10Kb/s to 10Mb/s can be provided in a complete continuum with rates that are linear with traffic class. In such a case, the telecommunications network proxy 20 considers existing traffic capacity, load, expected traffic volume and cost to determine counters for optimal use of resources. The resource management method is implemented by the ability of those skilled in the art.
If at step 40 it is determined that contract terms 26 are acceptable, then telecommunication network proxy 20 marks at step 46 that contract 26 is acceptable and returns at step 44 contract 26 to negotiation manager 22. As mentioned above, there are many ways to flag the acceptance of a contract 26, including setting a flag bit in the contract 26.
The flow chart of fig. 5 describes the operation of the first user agent 20. The software agent described in the flowchart has only the function of receiving communications, but a software agent having only the function of initiating communications or having the function of initiating and receiving communications may also be implemented.
Broadly speaking, the first user agent 18 operates very similar to the telecommunications network agent 20. As described above, the first user agent 18 is targeted to represent the benefits of the first user interface 12 in the negotiation of communications between the first user interface 12 and the second user interface 14. Since the computing and communication resources and limitations of the first user interface 12 are known only to itself, it may wish to negotiate with communication means and protocols to best use the resources in accordance with the characteristics of the application being implemented. These resources and limitations include, for example, processor speed, memory capacity, and modem speed.
Operation of the first user agent 18 begins at step 48 when the first user agent 18 receives a contract 26 from the negotiation manager 22. In a broad implementation, the first user agent 18 may not have the capability to initiate a communication negotiation. However, this function will be described in connection with the preferred embodiment of the invention of fig. 9. In the case where the first user agent 18 does not have the ability to generate the initial contract 26, the initial contract may be generated by another party attempting to communicate with the first user interface 12, or by the telecommunications network broker 20 as a standard order, when the first user interface 12 logs into the telecommunications service provided by the telecommunications network 16. Other similar situations will be apparent to those skilled in the art.
At step 50, the first user agent 18 examines the contents of the contract 26 to determine whether it can be accepted. If the terms of contract 26 cannot be accepted, first user agent 18 modifies the terms of contract 26 to be accepted at step 52 and returns contract 26 to negotiation manager 22 at step 54. In a simple case, the first user agent 18 has a predefined limit that the first user interface 12 does not want to override. For example, no incoming call charges are accepted, the transmission rate of the modem of the first user interface 12 is not exceeded, and voice communications below the quality of the charges are not accepted. If the parameters of the incoming contract 26 exceed any of these limits, which can be identified by simple logic testing, then a new contract 26 is generated that modifies these parameters to fall within expected boundaries. The first user agent 18 may contain a simple algorithm that references a resource and parameter settings database.
In a more complex implementation, the first user agent 18 comprises a rule-based software agent that optimizes the use of the resource continuum in a manner consistent with that described above for the telecommunications network agent 20. For example, the first user agent 18 may consider the particular application, as well as the computing and communication parameters of the first user interface 12, in communication negotiations. These parameter settings correspond to end-to-end telecommunication parameters such as Peak Cell Rate (PCR), tolerable cell delay variation (CVDT), Cell Transmission Delay (CTD), Cell Loss Rate (CLR) and peak-to-peak delay variation (CDV). These parameters are typically used by ATMs to specify the quality of service (QOS) provided by a telecommunications service. It is obvious that the invention can be applied to various parameters, or different parameters such as Mean Opinion Score (MOS), which are well known in the art. Other metric methods may also include mapping.
If it is determined at step 50 that the terms of contract 26 are acceptable, first user agent 18 marks contract 26 as acceptable at step 56 and returns contract 26 to negotiation manager 22 at step 54. As mentioned above, there are many ways to flag the acceptance of a contract 26, including setting a flag bit in the contract 26.
A preferred example of implementing the invention will now be described.
Figure 6 shows the preferred operation of negotiation manager 22 in response to a communication from a user request. At step 58, negotiation manager 22 is initialized. As is well known in the art, computer software programming requires the initialization of variables, arrays, and functions at the beginning of a program. At step 60, the communication participant 24 is identified. If the negotiation is initiated by the first user, initial contract 26 received by negotiation manager 22 will identify first user interface 12 and second user interface 14, and negotiation manager 22 must identify the various entities in telecommunications network 16 that wish to join participant 24 in order to complete the communication.
Negotiation manager 22 authenticates participant 24 at step 62. As described above, negotiation manager 22 is a software agent that may reside anywhere on the network. Thus, there need not be a secure connection between all participants 24 participating in the negotiation. In a preferred example, the authentication method of participant 24 includes the use of cryptographic signatures, which are well known in the art.
Once participant 24 is authenticated, negotiation manager 22 establishes the context of specification 28 at step 64.
Participant 24 is informed that negotiation is about to begin at step 66. This step provides participant 24 with a feedback on the negotiation status, but also serves to alert participant 24 that subsequent offers are not cancelable. That is, once the user expresses an intent, it cannot undo its intent. Preferably, the unavailability will time out after a brief time, such as one minute.
The negotiation specification 28 is then implemented at step 68 and details regarding the operation of the negotiation specification 28 are given with reference to figure 7.
The participants are then informed at step 70 whether the negotiation was successful or failed. If the negotiation is marked as successful at step 72, then the contract 26 is executed at step 74. If it fails, the contract 26 is discarded at step 76.
An example of a negotiation profile 28 in step 68 of fig. 6 is seen in fig. 7. This negotiation specification 28 is referred to as a "round robin" specification in that each participant 24 has the opportunity to view the contract 26 one after the other and choose to accept or modify it. This process can be repeated for numerous rounds. Once all participants 24 accept the contract 26, it is executed.
The contract 26 passes each participant's 24 hands in each round, which may be predetermined. If the contracts 26 accepted by the parties are not negotiated within the predetermined number of rounds, the negotiation fails.
The "round-robin" negotiation begins at step 78, where negotiation manager 22 receives the list of participants 24 and the initial round number, and the initial contract 26 is created by first user agent 18. In accordance with the open view of the present invention, the negotiation specification 28 routine need not reside within negotiation manager 22. This allows any negotiating entity to provide the negotiation specification 28 or to obtain the negotiation specification 28 from a third party.
The next participant 24 to negotiate is identified at step 80 and the contract 26 is transmitted to the next participant 24 at step 82. The participant 24 processes the contract 26 in the manner described in relation to fig. 6 through 9 and returns the contract 26 to the negotiation manager 22 at step 84.
If the negotiation is not successful, a determination is made at step 86 as to whether all participants 24 have been polled in a given round. If not, control returns to step 80 to identify and query the next participant 24 in the round. Since contracts 26 identify each participant 24 in the negotiation, it is possible to visually flag or identify whether a particular participant 24 viewed the current contract 26 and whether the participant 24 accepted a given contract 26. Such identification methods are well known to those skilled in the art.
At step 88, a determination is made as to whether the contract 26 was successfully negotiated. As described above, each participant identifies whether the contract is accepted by setting a flag bit in the contract 26, or by adding a cryptographic signature and then returning the contract 26 to the negotiation manager 22. This requires that each participant 24 has already viewed and agreed to the current contract 26.
Contract 26 may also be accepted without review by participant 24, provided that the contract is more favorable than an approved contract that participant 24 has been irrevocable. For example, if the contract approved by the first user agent 18 requires 5 minutes of transmission at a regular bit rate of 10Kb/s, a cost of 5 cents per minute, the contract has been in an irrevocable 1 minute period, and the later negotiated contract 26 at a regular bit rate of 10Kb/s for 5 minutes has become charged 4 cents per minute, then the participant 24 is considered to have approved the more favorable contract 26 because it was negotiated during the 1 minute irrevocable period.
If the contract 26 negotiation is successful, the completed contract 26 is returned to negotiation manager 22 for execution at step 90.
If the agreement 26 is not successful, then a determination is made at step 92 as to whether a new round of agreement regarding the agreement 26 is to be performed. If a new negotiation round is necessary, control returns to step 80. If all of the predetermined rounds were performed but a successful contract 26 was not identified at step 88, the negotiation is deemed to have failed and the incomplete contract 26 is returned to negotiation manager 22 at step 94 with the failure identification.
The operation of the telecommunications network agent 20 and the first user agent 18 in the preferred example will now be described with reference to figures 8 and 9 respectively. Before describing the functionality of these agents, a preferred implementation mode common to both agents is described.
First, the telecommunications network agent 20 and the first user agent 18 are implemented as software "agents" that are customized to the respective user, rather than as general software algorithms. Of course, the broad invention can be implemented in general software rather than as an agent, but it suffers from a corresponding loss of functionality and flexibility.
Second, although the sequential steps are described in connection with a flowchart, it is to be understood that the software agents typically reside in memory of the computer or telephone device, in an idle state. This allows the agent to detect arriving communication requests.
Third, in the preferred embodiment, the telecommunications network agent 20 and the first user agent 18 are implemented in a java or C + + based programming language. The benefits of using java will be clear to those skilled in the art, such as the wide range of uses currently available, direct association with browsers or other internet-based applications, a wide range of universal standards, and the benefits of using "sandbox" security. It will be apparent that the invention is not limited to the use of such programming languages.
Using the "sandbox" security method, applets (applets) are only allowed to operate within certain boundaries (sandboxes). This limited real-time environment prevents the applet from accessing or modifying unauthorized areas or performing other harmful operations. In Java applications, a special class called the "applet security manager" performs this enhancement. For example, the "security manager" prevents the applet from reading or writing files to the client's hard drive, or establishing other network connections than to the server from which the applet originates.
As described above, fig. 8 describes the operation of the telecommunication network proxy 20 corresponding to the preferred example of the present invention. The functions performed by steps 38, 40, 42, 44 and 46 are consistent with the broad example scenario described in fig. 4.
In a preferred embodiment, telecommunications network broker 20 monitors the status of network available resources and predicts expected usage so that it can make appropriate decisions to determine the acceptability of incoming contracts 26 and the generation of outgoing contracts 26.
In the preferred embodiment, the telecommunications network proxy 20 determines at step 96 whether the status data of the network is new enough to make a correct decision, or whether the data needs to be updated. If it is determined that new data is needed, then the new data is obtained in step 89.
Network data includes at least two types: internal data and external data. Internal data typically includes resources maintained by the current load, such as a Central Processing Unit (CPU) and memory, and known obligations to provide telecommunication services. These data are very easy to detect since all access and management is under the control of the service provider. Typically, these data need to be updated continuously or in real time.
Extrinsic data is more difficult to obtain and predict. As these resources are outside the control of the service provider. Since the management of these services is beyond the scope of the telecommunication network agents 20, it is necessary to query their availability and quality periodically, for example according to a period determined by time or traffic. For example, network data may need to be updated every minute or more, or every ten calls.
In a preferred embodiment of the invention, the internal data is detected on a continuous basis, recording the current load and subsequent obligations. The external data is updated when a new call comes in and a predetermined time period has elapsed.
There are many ways to update the external data. For example, the sampled packets are transmitted directly to the destination telecommunications network or entity and their performance is checked. In a preferred embodiment, the request is transmitted to the service provider for return of the operational data. The service provider has the responsibility to forward the data correctly in order to retain an acceptable provider as a proxy 20 for the telecommunications network.
Since the telecommunications network broker 20 and the first user agent 18 can monitor their performance during the course of communications, the service provider must be faithfully performing its services, otherwise the customer or other service provider will refuse to use its services.
In the preferred embodiment, the telecommunications network proxy 20 provides standard Asynchronous Transfer Mode (ATM) service selection to describe the requirements of known applications:
1. the design intent of the Constant Bit Rate (CBR) is to accommodate the standard voice telephony mode, but it wastes bandwidth. CBR sets the bandwidth using a given Peak Cell Rate (PCR), which is straightforward in definition. The user also defines a tolerable cell delay variation (CVDT) that is desired to smooth the buffer at the destination. Cell delivery delay (CTD), Cell Loss Rate (CLR) and peak-to-peak delay variation (CDV) are specified by the network as its quality of service (QoS). The user is charged per minute.
2. The real time variable bit rate (rt-VBR) allows burst to peak cell rate and Maximum Burst Size (MBS) and guarantees Cell Transmission Delay (CTD) and tolerable variation (CDVT) at a certain Sustained Cell Rate (SCR). This is a mode suitable for modem telephony. The user pays a fee per second.
3. The non-real-time variable bit rate (nrt-VBR) does not guarantee CTD and is more suitable for web browser applications. The user is charged a minute, but may be discounted for slower packets.
4. The Uncertain Bit Rate (UBR) is basically of the "best effort" type, which is modeled on the current internet service. UBR does in fact specify the peak cell rate, but cannot provide a sustained cell rate. The user may wish to pay in megabytes.
5. The Available Bit Rate (ABR) specifies the Minimum Cell Rate (MCR) and the peak cell rate, and the network uses the backward pressure to control the traffic. The network sends a "resource management" information element to the source to allow it to adapt to the available capacity. The user may wish to pay per minute for the minimum cell rate, pay an additional fee when the rate is higher, or generally pay a higher fee or be discounted once the rate is forced to decrease to the minimum rate. The mechanism makes the best use of the network, and it also optimizes for video conferencing when the user has a complex rate adaptive encoder.
As mentioned above, FIG. 9 depicts the operation of the first user agent 18 in a preferred embodiment of the present invention. The functions performed by steps 48,50,52,54 and 56 are consistent with the broad example scenario described in fig. 5.
Although the functionality of the first user agent 18 and the telecommunications network agent 20 are similarly broadly implemented, the focus of attention in the preferred example is quite different. The focus of the telecommunications network broker 20 is on the status and predictability of the telecommunications network 16 resources, while the first user broker 18 focuses on the requirements of the first user interface 12. The first user agent 18 identifies the resources available to the first user interface 12 and determines the needs of the user in a real-time environment before it can effectively negotiate on behalf of the first user interface 12.
For telephony and web surfing applications, the first user agent 18 preferably communicates with the user through a Graphical User Interface (GUI) in a windowed environment. Preferably, the GUI is provided to the user as a web page that can be edited by a standard browser. Techniques for developing functionality consistent with the present invention are well known in the art. Other applications, such as telemedicine, may require the first user to be embedded or "hardwired" into the first user's application program.
At step 100 of FIG. 9, the first user agent 18 obtains information regarding hardware resources and parameter settings of the first user interface 12. Information regarding the hardware resources may be obtained manually, with the user entering relevant data in response to the prompt from the first user agent 18, but is preferably collected by the first user agent 18 from the operating system upon power-up of the first user interface 12. This information includes data such as microprocessor speed, memory capacity and access times, operating system environment, modem software and hardware, etc. Methods of performing these tasks are well known in the art.
User parameter settings are typically entered manually, preferably through a graphical user interface, and stored on a local computer. The user agent software may provide default values for parameters such as delay and speed. Details of these parameter settings are given below.
At step 102, the first user agent 18 remains in an idle state waiting for a request to accept an incoming call or for a request from a local user to generate an outgoing request. If a request to accept the incoming call arrives, control passes to step 50, which is performed as described in connection with FIG. 5.
If a request is received from the user or user program to initiate negotiation of a new communication, control passes to step 104 where the necessary data is collected to create the initial contract 26. Generally, the initial contract 26 is created by the first user agent 18 by querying the following user information:
1. the destination, or called party, such as the second user interface 14 of fig. 1.
2. Applications such as video conferencing, voice communication, web browsing or email.
The first user agent 18 has default parameters for most applications,
as briefly described above with respect to ATM mode, including minimum acceptable
Subject to cost, delay and speed. These default values may be modified or created by the user
And (5) establishing a new mode. If the first user agent does not know a particular application, that
The first user agent asks the user for default values and stores these parameters for use
For future reference. For example, a user may wish to have more than one deficit in voice communications
A provincial mode: quality of charge for commercial use and comparison of personal or peak usage
Low quality speech. The skilled person is able to implement the softwares that perform these functions
And (3) a component.
3. Acceptance of the contract 26 negotiated by the first user agent 18 is confirmed manually or automatically.
4. And (5) cost negotiation. For example, the cost payment may be to the calling or called party (reverse charge, or 1-800 to party payment service), or to share a fee, or to pay a fee per use (e.g., 1-976 telephone service).
5. Parameter settings for contracts 26 that are not allowed to be irrevocable.
6. Parameter settings regarding the specific service provider to be contacted and negotiated.
7. Parameter settings for negotiation manager 22 or negotiation specification 28 and URL addresses or locations on local hard disk where they can be found.
Based on the queried information, in conjunction with the knowledge of the user interface 12 collected at step 100, the first user agent 18 creates an initial contract 26 at step 104, which is communicated to the preferred service provider at step 106. First user agent 18 then waits for a return of contract 26 from negotiation manager 20 at step 48.
The manner in which this routine is executed is consistent with that described in fig. 5 up to step 108. At step 108, the user may exit the routine or return to step 102 to continue monitoring for new communication requests or to receive new contracts.
The present invention can be applied within a wide range of optional functions, as will be apparent to those skilled in the art in light of the present teachings. One option is the flexibility to terminate and renegotiate terms in the communication. This allows, for example, the service provider to reclaim the fastest communication lines offered at a lower price if it is desired to obtain them by a consumer willing to pay a higher price. This must approve of such interruptions in the initial negotiation, but this allows all participants to gain additional flexibility not provided by existing systems.
Another option is to handle recursive negotiations using the software agent itself rather than the negotiation manager 20. Rather than allowing the negotiation manager 20 to publish the contract 26 to its defined network entities, local network entities, such as other service providers that wish to participate in the negotiation, are identified by the first user agent 18. This allows the first user agent 18 to mask a set of participants from each other. Similarly, network proxies may also have network sub-entities that wish to participate in the negotiation, but in the negotiation they wish to mask other entities from each other. In both cases, the participant can receive the contract 26, send it to the sub-participant and receive the sub-participant's response. The participant wishes to modify the contract 26 by adding or removing information and then sending to the sub-participant, and modify the sub-participant's response and then sending to the negotiation manager 20.
In addition to the "round robin" negotiation specification 28 described above, there may be many other negotiation specifications 28 available to the negotiation manager 20 or a third party. This includes:
1. bid and ask: at any time, each entity is allowed to provide the services accepted by the other entities. This is a less structural specification than the circular specification, as entities may introduce bids at any time.
2. And (3) cheating: only certain parameters are negotiated, otherwise kept secret. This allows entities to lie on their needs or resources in an attempt to negotiate better terms. For example, service providers are reluctant to expose unused resources because users may wish to hold it at a lower price.
3. The person who is probing: service providers allow a large number of users to bid on services simultaneously, providing services only to users who reach a certain level in the negotiation. For example, a service provider has 10 identical communication units that begin negotiating with 20 users bidding for different numbers of units. As the price rises, some users will exit the negotiation and the service provider will adjust to users bidding on 10 or fewer than 10 units. The negotiation specification is more useful in selling commodity services, such as where communication lines are allocated on a predefined time period rather than on a per call basis.
4. Reverse auction: the service provider initiates negotiations with multiple users, initially at a higher price and then reducing the price until the users accept it. The specification is also for commodity service sales.
Although specific examples of the invention have been described, it will be appreciated that modifications or changes may be made to these examples without departing from the true scope and spirit of the invention.
Although the operations are described in detail in connection with method steps, it should be understood that the present invention may be implemented as a combination of software and hardware. The method steps may be performed by a computer processor or similar suitably programmed device, or by an electronic system, which is provided with a means for performing the steps. Similarly, electronic storage means such as computer disks, CD-ROMs, Random Access Memories (RAMs) and Read Only Memories (ROMs) may be written to perform the method steps. In addition, electronic signals representing the steps of the methods may also be transmitted over communication networks.
The set of executable machine code representing the method steps of the present invention may be stored in a variety of formats, such as object code or source code. Such code is generally referred to herein as program code, or simply a computer program. The executable code may also be transmitted as electronic signals over a communication link. In addition, the executable machine code may be integrated with other program code implemented as subroutines, called by an external program, or using other techniques known in the art.
It is to be appreciated that as communication networks become more flexible and powerful, the definition of traditional servers, routers, computers, telephones and other hardware components becomes less and less clear. These terms are used herein to simplify the discussion and are not intended to limit the present invention by the previous definition of such hardware. For example, a cellular telephone with internet access capability may implement the present invention by providing a software agent in read only memory. Such a phone obviously does not have the traditional limitation of the term "phone".
Similarly, existing telephone providers may modify their routing equipment to more broadly apply the present invention, including adding new operability as a stand-alone device, or modifying existing equipment accordingly. In both cases, the actual implementation cannot be read explicitly in the methods described above, but the application realized by the person skilled in the art is derived from the description of the invention herein.
Additionally, the order and details of the method steps may be conveniently modified while still achieving the advantages of the present invention. Such modifications will be apparent to those skilled in the art. The examples set forth herein are intended to be illustrative, not limiting.