U.S. patent application number 10/537785 was filed with the patent office on 2006-07-27 for dynamic resource allocation platform and method for time related resources.
Invention is credited to Yaron Yakov.
Application Number | 20060167703 10/537785 |
Document ID | / |
Family ID | 33131461 |
Filed Date | 2006-07-27 |
United States Patent
Application |
20060167703 |
Kind Code |
A1 |
Yakov; Yaron |
July 27, 2006 |
Dynamic resource allocation platform and method for time related
resources
Abstract
A resource allocation platform for allocating resources between
a provider and a plurality of users at a certain price
differentiated for different users, the resources being time
dependent resources such as communication data capacity, the
platform comprising: an agent-based interaction mechanism for
allowing said provider and said plurality of users to indicate
their requirements and to translate the requirements into offers
and bids, and a pricing engine for ascertaining a resource
allocation price for the offers and bids. The pricing engine uses a
learning mechanism for learning demand behavior of individual users
so that it can translate their requirements into a price which is
fair to them and fair to the provider. Thus, the time-consuming,
and in the case of time-dependent products, product destroying,
bargaining stage of resource allocation is avoided. Optionally, a
"reverse auction" format may be provided, in which a variable
amount of a resource is provided for a fixed price.
Inventors: |
Yakov; Yaron; (Lapid,
IL) |
Correspondence
Address: |
Martin Moynihan;Anthony Castorina
Suite 207
2001 Jefferson Davis Highway
Arlington
VA
22202
US
|
Family ID: |
33131461 |
Appl. No.: |
10/537785 |
Filed: |
December 9, 2003 |
PCT Filed: |
December 9, 2003 |
PCT NO: |
PCT/IL03/01044 |
371 Date: |
March 1, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10414198 |
Apr 16, 2003 |
6805277 |
|
|
10537785 |
Mar 1, 2006 |
|
|
|
Current U.S.
Class: |
705/26.1 ;
705/37 |
Current CPC
Class: |
H05K 3/3421 20130101;
Y02P 70/613 20151101; G06Q 40/04 20130101; B23K 2101/38 20180801;
B23K 1/0016 20130101; H05K 2201/10568 20130101; G06Q 30/0601
20130101; H05K 3/303 20130101; Y02P 70/50 20151101; H01R 43/0256
20130101; H05K 2201/2036 20130101; H05K 2201/10189 20130101 |
Class at
Publication: |
705/001 ;
705/037 |
International
Class: |
G06Q 99/00 20060101
G06Q099/00; G06Q 40/00 20060101 G06Q040/00 |
Claims
1. A resource allocation platform for allocating resources between
a provider and a plurality of users for a resource allocation
price, the resources being duration dependent resources, the
platform comprising: an agent-based interaction mechanism for
allowing said provider and said plurality of users to indicate
required and surplus resources, and a pricing engine, associated
with said interaction mechanism, for ascertaining a resource
allocation price.
2. The platform of claim 1, wherein the pricing engine comprises a
learning mechanism for learning demand behavior of individual
users, therefrom to provide said price.
3. The platform of claim 2, wherein said demand behavior is an
observed demand price curve for a respective user.
4. The platform of claim 1, wherein said pricing engine further
comprises a differentiation mechanism for altering said price by
applying a user based differentiation policy to said price.
5. The platform of claim 2, wherein said learning mechanism is a
per-user neural network.
6. The platform of claim 2, wherein said learning mechanism is a
neural network assigned per a cluster of users.
7. The platform of claim 2, wherein said demand behavior is an
observed demand price behavior for a respective user, said
resources comprise a plurality of different products and wherein
said observed demand price behavior comprises a curve per product,
said learning mechanism being operable to prepare a separate
price-demand curve for each product.
8. The platform of claim 1, wherein said resources are data
communication capacity resources.
9. The platform of claim 8, wherein said resources are one of a
group comprising bandwidth, duration, rate access, CPU access,
trunk access, cache memory, quality of service, and combinations
thereof.
10. The platform of claim 8, wherein said resources comprise a
plurality of different products, each one of said products being
defined by a respective duration and at least one of bandwidth,
rate access, CPU access, trunk access, cache memory, and quality of
service.
11. The platform of claim 1, further comprising an allocation
engine associated with said pricing engine, said allocation engine
being operable to allocate available resources using rules,
according to availability and according to respective resource cost
outputs of said pricing engine.
12. The platform of claim 11, wherein said allocation engine is
operable to allocate resources into an allocation space.
13. The platform of claim 1, wherein said allocation engine is
operable to allocate capacity by maximizing an overall utility
along a time continuum, wherein utility components for future
points along said time continuum are calculated by including terms
for probabilities of bids occurring at respective ones of said
future points.
14. The platform of claim 11, wherein said allocation engine is
further operable to allocate said available resources in such a way
as to maximize a predetermined utility function.
15. The platform of claim 14, wherein said allocation engine is
further operable to use feedback information of achieved utilities
to enhance maximization of said predetermined utility function.
16. The platform of claim 14, wherein said allocation engine is
operable to carry out optimization of a mix within a group of
products.
17. The platform of claim 16, wherein said optimization comprises
measuring changes in utility over changes in allocation between
said products, and to allocate capacity from products showing lower
changes in utility to products showing higher changes in
utility.
18. The platform of claim 1, wherein said agent-based interaction
mechanism comprises a broker agent per user and a broker agent per
provider.
19. The platform of claim 18, wherein said agent based interaction
mechanism further comprises an inter-provider broker agent.
20. The platform of claim 1, wherein said agent-based interaction
mechanism comprises broker agents for translating requests from
respective users and providers into offers and bids, therewith to
interact with other broker agents.
21. The platform of claim 1, wherein said resources are
apportionable into products being portions of a total amount of
said resources and wherein said price engine is operable to build
in a risk cost factor to respective products, such that said cost
factor is inversely related to a size of a respective portion.
22. The platform of claim 1, wherein said duration-based resources
are apportionable into products having different time durations and
wherein said price engine is operable to build in a risk cost
factor to respective products such that said cost factor is
inversely related to a size of a respective time duration.
23. The platform of claim 1, wherein said duration-based resources
are apportionable into products having different bandwidths and
wherein said price engine is operable to build in a risk cost
factor to respective products such that said cost factor is
inversely related to a size of a respective bandwidth.
24. The platform of claim 22, wherein said duration-based resources
are apportionable into products having different bandwidths and
wherein said price engine is operable to build in a risk cost
factor to respective products such that said cost factor is
inversely related to a size of a respective bandwidth.
25. A method of managing a time-dependent resource between at least
one provider and a plurality of users, said method comprising:
assigning a broker agent to each provider and each user to
translate requests concerning said resource into offers and bids,
using learned demand behavior of each user to assign a price to
offers and bids concerning said user, and allocating resources
according to a predetermined utility function based at least partly
on said assigned prices.
26. The method of claim 25, further comprising using further
differential information of each user together with a provider
pricing policy to arrive at said price.
27. The method of claim 25, wherein said allocating resources is
also determined according to a request for a minimum amount of the
time-dependent resource.
28. An interface, for interfacing between resource allocation
platforms, said resource allocation platforms being for allocating
resources between a provider and a plurality of users for a
resource allocation price, the resources being duration dependent
resources, at least one of the platforms comprising: an agent-based
interaction mechanism for allowing said provider and said plurality
of users to indicate required and surplus resources, and a pricing
engine, associated with said interaction mechanism, for
ascertaining a resource allocation price, the platforms interfacing
with each other over junctions, the interface comprising: an agent
for each platform at each junction, said agent being a part of a
respective agent-based interaction mechanism, and further
comprising an inter-platform protocol for exchanging resource
allocation data with a corresponding agent of a respective
interfacing platform, thereby to support inter-platform resource
allocation across said junction.
29. The interface of claim 28, wherein said inter-platform protocol
comprises a loop avoidance mechanism for preventing resource
allocation data from looping between platforms.
30. The interface of claim 29, wherein said loop avoidance
mechanism comprises assigning identification data to an instance of
resource allocation data and wherein said protocol comprises making
passing on said resource allocation data dependent upon a test of
said identification data.
31. The interface of claim 30, wherein said identification data is
a randomly generated number.
32. The interface of claim 31, wherein said randomly generated
number is a relatively large number, thereby to reduce to
negligible proportions the probability of two instances being
assigned an identical number.
33. A resource allocation platform for allocating resources between
a provider and a plurality of users according to a fixed price, the
resources being duration dependent resources, the platform
comprising: an agent-based interaction mechanism for allowing said
provider and said plurality of users to indicate required and
surplus resources, and an availability engine, associated with said
interaction mechanism, for ascertaining a an amount of a resource
to be allocated according to the fixed price.
34. The platform of claim 33, wherein said availability engine also
ascertains said amount of said resource to be allocated according
to a quality parameter.
35. The platform of claim 34, wherein said quality parameter
comprises a minimum amount of said resource.
36. The platform of claim 34, wherein said quality parameter
comprises quality of service.
37. The platform of claim 33, wherein said availability engine
ascertains said amount of said resource to be allocated also
according to requesting said resource in advance of use.
38. The platform of claim 33, wherein said availability engine
ascertains said amount of said resource to be allocated also
according to requesting said resource at a non-peak time of
use.
39. The platform of claim 33, wherein said resource comprises
bandwidth on a network.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to a dynamic resource
allocation platform and method for allocation of time related
resources and more particularly but not exclusively to a platform
for supporting dynamic allocation of data communication
capacity.
BACKGROUND OF THE INVENTION
[0002] Data networks supply enormous amounts of data capacity to
large numbers of users. The usage patterns on the network tend to
change very rapidly and dynamic allocation of the network capacity
is a huge computational problem.
[0003] A commonly used method of managing such a network is to
provide certain users with guaranteed bandwidth levels, at a
certain cost, and to leave the remaining capacity to be shared
between smaller users without any guarantee of availability.
However, such a method avoids entering into the complexity of the
problem. Individual users rarely use all of their capacity all of
the time, but rather tend to fall into certain usage patterns
having peak usage times and minimal usage times.
[0004] Furthermore if a new service is developed at a given
location, the sudden appearance of the new service may upset
existing network resource allocations, and one of the key issues
associated with a managed data network is that the traffic
distribution of a new service is initially an unknown variable
which dynamically changes as a function of usage patterns and
service growth. Therefore, commercial launches of new services
require smart mechanisms that enable cost-efficient dynamic
resource trade and allocation. Without such a mechanism, there is a
risk of undermining the commercial viability of the service
deployment.
[0005] Today, different technologies, such as traffic shapers,
policy-based management and dynamic provisioning attempt to
engineer and smooth the network traffic. These technologies however
focus on network management and therefore obscure the underlying
commercial aspect of the problem.
[0006] Reference is now made to FIG. 1, which illustrates the
current situation. A provider 10 (i.e. carrier, service provider,
etc.) is the entity that provides the network services to its
customers. The provider may sell its own services, or other
providers' services.
[0007] The customer is the entity that receives services from the
provider. A customer may be a subscriber, business organization,
SOHO, or another service provider that buys/leases communication
services from the provider. Two customers, 12 and 14, are shown in
FIG. 1.
[0008] As shown in FIG. 1, the provider 10 runs a provider network
16. The service networks 18 and which represent service allocations
over the provider network 16 to the individual users, for example
as a WAN for a very large multi-location user or a VPN. The service
networks 18 and 20 are set up as sub-domains within the provider's
network 16 that may be allocated to the individual customer.
Different 'service networks' can each be assigned to a different
customer, although all are carried by the provider network.
[0009] Nowadays the business/commercial relationships are handled
manually, which means that it can take days to weeks to set up an
individual service network to the satisfaction of both parties. The
current slow commercial process leads to static allocation and
therefore to inefficiency and consequent loss of potential
additional revenue. The system is unable to respond to situations
such as the sudden popularity of a given server due to the presence
of a new website.
[0010] Reference is made to the following documents, the contents
of which are hereby incorporated within by reference:
[0011] J. Collins, C. Bilot, M. Gini, B. Mobasher "Mixed-Initiative
Decision Support in Agent-Based Automated Contracting"; In Proc. Of
the Fourth Int'l Conf. On Autonomous Agents, pages 247-254, June
2000,
[0012] J. Collins, R. Sundareswara, M. Tsvetovat, M. Gini, B.
Mobasher "Search Strategies for Bid Selection in Multi-Agent
Contracting";
[0013] J. Collins, C. Bilot, M. Gini, B. Mobasher "Mixed-Initiative
Decision Support in Agent-Based Automated Contracting", and
[0014] F. Stzidarovszky, M. E. Gershon, L. Duckstein "Techniques
for Multi-Objective Decision Making in System Management"; Elsevier
Science Publishers, B.V. 1998.
[0015] Nemo Semert, Raymond R. -F. Liao, Andrew T. Campbell, Aurel
A. lazar "Pricing, provisioning and peering: Dynamic Markets for
differentiated internet Services and Implications for network
Interconnections", Colombia University and InvisibleHand Inc.
SUMMARY OF THE INVENTION
[0016] The background art does not teach or suggest an automated
mechanism for resource allocation. The background art also does not
teach or suggest such an automated mechanism for allocating
bandwidth on a communications network.
[0017] The present invention overcomes these deficiencies of the
background art, by providing (according to a first aspect of the
present invention) a resource allocation platform for allocating
resources between a provider and a plurality of users for a
resource allocation price, the resources being duration dependent
resources, the platform comprising:
[0018] an agent-based interaction mechanism for allowing the
provider and the plurality of users to indicate required and
surplus resources, and
[0019] a pricing engine, associated with the interaction mechanism,
for ascertaining a resource allocation price.
[0020] Preferably, the pricing engine comprises a learning
mechanism for learning demand behavior of individual users,
therefrom to provide the price.
[0021] Preferably, the demand behavior is an observed demand price
curve for a respective user.
[0022] Preferably, the pricing engine further comprises a
differentiation mechanism for altering the price by applying a user
based differentiation policy to the price.
[0023] Preferably, the learning mechanism is a per-user neural
network.
[0024] Preferably, the learning mechanism is a neural network
assigned per a cluster of users.
[0025] Preferably, the demand behavior is an observed demand price
behavior for a respective user, the resources comprise a plurality
of different products and wherein the observed demand price
behavior comprises a curve per product, the learning mechanism
being operable to prepare a separate price-demand curve for each
product.
[0026] Preferably, the resources are data communication capacity
resources.
[0027] Preferably, the resources are one of a group comprising
bandwidth, duration, rate access, CPU access, trunk access, cache
memory, quality of service, and combinations thereof.
[0028] Preferably, the resources comprise a plurality of different
products, each one of the products being defined by a respective
duration and at least one of bandwidth, rate access, CPU access,
trunk access, cache memory, and quality of service.
[0029] The platform preferably comprises an allocation engine
associated with the pricing engine, the allocation engine being
operable to allocate available resources using rules, according to
availability and according to respective resource cost outputs of
the pricing engine.
[0030] Preferably, the allocation engine is further operable to
allocate the available resources in such a way as to maximize a
predetermined utility function.
[0031] Preferably, the allocation engine is operable to allocate
capacity by maximizing an overall utility along a time continuum,
wherein utility components for future points along the time
continuum are calculated by including terms for probabilities of
bids occurring at respective ones of the future points.
[0032] Preferably, the allocation engine is operable to carry out
optimization of a mix within a group of products.
[0033] Preferably, the optimization comprises measuring changes in
utility over changes in allocation between the products, and to
allocate capacity from products showing lower changes in utility to
products showing higher changes in utility.
[0034] Preferably, the agent-based interaction mechanism comprises
a broker agent per user and a broker agent per provider.
[0035] Preferably, the agent based interaction mechanism further
comprises an inter-provider broker agent.
[0036] Preferably, the agent-based interaction mechanism comprises
broker agents for translating requests from respective users and
providers into offers and bids, therewith to interact with other
broker agents.
[0037] Preferably, the resources are apportionable into products
being portions of a total amount of the resources and wherein the
price engine is operable to build in a risk cost factor to
respective products, such that the cost factor is inversely related
to a size of a respective portion.
[0038] Preferably, the duration-based resources are apportionable
into products having different time durations and wherein the price
engine is operable to build in a risk cost factor to respective
products such that the cost factor is inversely related to a size
of a respective time duration.
[0039] Preferably, the duration-based resources are apportionable
into products having different bandwidths and wherein the price
engine is operable to build in a risk cost factor to respective
products such that the cost factor is inversely related to a size
of a respective bandwidth.
[0040] Preferably, the duration-based resources are apportionable
into products having different bandwidths and wherein the price
engine is operable to build in a risk cost factor to respective
products such that the cost factor is inversely related to a size
of a respective bandwidth.
[0041] According to a second aspect of the present invention there
is provided a method of managing a time-dependent resource between
at least one provider and a plurality of users, the method
comprising:
[0042] assigning a broker agent to each provider and each user to
translate requests concerning the resource into offers and
bids,
[0043] using learned demand behavior of each user to assign a price
to offers and bids concerning the user, and
[0044] allocating resources according to a predetermined utility
function based at least partly on the assigned prices.
[0045] The method may further comprise using further differential
information of each user together with a provider pricing policy to
arrive at the price.
[0046] According to a third aspect of the present invention there
is provided an interface, for interfacing between resource
allocation platforms, the resource allocation platforms being for
allocating resources between a provider and a plurality of users
for a resource allocation price, the resources being duration
dependent resources, at least one of the platforms comprising:
[0047] an agent-based interaction mechanism for allowing the
provider and the plurality of users to indicate required and
surplus resources, and
[0048] a pricing engine, associated with the interaction mechanism,
for ascertaining a resource allocation price,
[0049] the platforms interfacing with each other over
junctions,
[0050] the interface comprising: [0051] an agent for each platform
at each junction, the agent being a part of a respective
agent-based interaction mechanism, and further comprising an
inter-platform protocol for exchanging resource allocation data
with a corresponding agent of a respective interfacing platform,
thereby to support inter-platform resource allocation across the
junction.
[0052] Preferably, the inter-platform protocol comprises a loop
avoidance mechanism for preventing resource allocation data from
looping between platforms.
[0053] Preferably, the loop avoidance mechanism comprises assigning
identification data to an instance of resource allocation data and
wherein the protocol comprises making passing on the resource
allocation data dependent upon a test of the identification
data.
[0054] Preferably, the identification data is a randomly generated
number.
[0055] Preferably, the randomly generated number is a relatively
large number, thereby to reduce to negligible proportions the
probability of two instances being assigned an identical
number.
[0056] According to still another embodiment of the present
invention, there is provided a resource allocation platform for
allocating resources between a provider and a plurality of users
according to a fixed price, the resources being duration dependent
resources, the platform comprising: an agent-based interaction
mechanism for allowing the provider and the plurality of users to
indicate required and surplus resources, and an availability
engine, associated with the interaction mechanism, for ascertaining
a an amount of a resource to be allocated according to the fixed
price.
[0057] Preferably, the availability engine also ascertains the
amount of the resource to be allocated according to a quality
parameter. More preferably, the quality parameter comprises a
minimum amount of the resource. Most preferably, the quality
parameter comprises quality of service.
[0058] Optionally and preferably, the availability engine
ascertains the amount of the resource to be allocated also
according to requesting the resource in advance of use.
[0059] Also optionally and preferably, the availability engine
ascertains the amount of the resource to be allocated also
according to requesting the resource at a non-peak time of use.
[0060] Preferably, the resource comprises bandwidth on a
network.
BRIEF DESCRIPTION OF THE DRAWINGS
[0061] For a better understanding of the invention and to show how
the same may be carried into effect, reference will now be made,
purely by way of example, to the accompanying drawings.
[0062] With specific reference now to the drawings in detail, it is
stressed that the particulars shown are by way of example and for
purposes of illustrative discussion of the preferred embodiments of
the present invention only, and are presented in the cause of
providing what is believed to be the most useful and readily
understood description of the principles and conceptual aspects of
the invention. In this regard, no attempt is made to show
structural details of the invention in more detail than is
necessary for a fundamental understanding of the invention, the
description taken with the drawings making apparent to those
skilled in the art how the several forms of the invention may be
embodied in practice. In the accompanying drawings:
[0063] FIG. 1 is a simplified diagram showing the current situation
vis a vis network resource allocation and commercial
relationships,
[0064] FIG. 2A is a simplified schematic diagram showing how
providers and customers are linked by brokers and a virtual trading
floor according to a first embodiment of the present invention,
[0065] FIG. 2B is a simplified schematic diagram showing a resource
negotiating platform according to a further preferred embodiment of
the present invention,
[0066] FIG. 3 is a simplified diagram showing relationships between
different providers superimposed on relationships between a
provider and his customers, according to a further preferred
embodiment of the present invention,
[0067] FIG. 4 is a circular flow chart showing interactions
relating to the virtual trading floors of FIGS. 2 and 3,
[0068] FIGS. 5-7B are simplified sequence diagrams for different
kinds of requests made over a virtual trading floor according to
the present invention,
[0069] FIG. 8 is a simplified flow chart showing a pre-trading
procedure for a request to buy from a customer over a trading floor
according to a preferred embodiment of the present invention,
[0070] FIG. 9A is a simplified flow chart showing a pre-trading
procedure for a request to sell from a customer over a trading
floor according to a preferred embodiment of the present
invention,
[0071] FIG. 9B is a graph showing points of operation for use by a
price engine of the present invention,
[0072] FIG. 10 is a typical demand price curve for use by a price
engine of the present invention,
[0073] FIG. 11 is a simplified schematic diagram showing an
allocation engine according to a preferred embodiment of the
present invention,
[0074] FIG. 12 is a simplified flow chart showing a procedure for
allocating capacity over a virtual trading floor according to a
preferred embodiment of the present invention,
[0075] FIG. 13 is a simplified schematic diagram showing
interrelationships between users over a network, and
[0076] FIG. 14 is a simplified diagram showing a series of
platforms interfacing via brokers over junctions, in accordance
with a farther preferred embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0077] The present embodiments disclose a resource allocation
platform for allocating resources between a provider and a
plurality of users at a certain price differentiated for different
users, the resources being time, that is to say duration, dependent
resources such as communication data capacity. The platform
comprises: an agent-based interaction mechanism for allowing the
provider and the users to indicate their requirements and to
translate the requirements into offers and bids, and a pricing
engine for ascertaining a resource allocation price for the offers
and bids. The pricing engine uses a learning mechanism for learning
demand behavior of individual users so that it can translate their
requirements into a price, which is fair to them and fair to the
provider. Thus, the time-consuming, and in the case of
duration-dependent products, product destroying, bargaining stage
of resource allocation is avoided.
[0078] The platform preferably allows for parceling of the
resources into products of given time duration and quality of
service and a risk factor may be introduced into the price of the
product according to the duration. Trading of resources may be on
demand but future and option trading of the resources are also
supported.
[0079] Before explaining at least one embodiment of the invention
in detail, it is to be understood that the invention is not limited
in its application to the details of construction and the
arrangement of the components set forth in the following
description or illustrated in the drawings. The invention is
applicable to other embodiments or of being practiced or carried
out in various ways. Also, it is to be understood that the
phraseology and terminology employed herein is for the purpose of
description and should not be regarded as limiting.
[0080] Reference is now made to FIG. 1, which is a simplified
diagram showing the current situation vis a vis network resource
allocation and indicating commercial relationships between parties
concerned. As discussed in the background above, a resource
provider 10 operates a network 16 which contains service networks
per customer. The allocation may be rigid in that particular
customers may be given a fixed guaranteed bandwidth, or the
allocation may be dynamic in that bandwidth on demand is provided
to the customer, the customer paying only for bandwidth used. In
the latter case, bandwidth is generally provided on a first come
first served basis, or on a normal distribution basis and there is
very little attempt to apply underlying commercial concerns to the
dynamic distribution of bandwidth.
[0081] Reference is now made to FIG. 2A, which is a simplified
schematic diagram showing how network resources are made available
using a first embodiment of the present invention. In FIG. 2A,
parts that are the same as those in previous figures are given the
same reference numerals and are not referred to again except as
necessary for an understanding of the present embodiment. A
provider 10 offers and bids for products via a broker 22 over a
virtual trading floor 24. The broker 22 is preferably a software
module. Customers 12 and 14 also offer and bid for products over
the virtual trading floor, each via his own respective broker 26
and 28. A product is typically the availability of a given amount
of bandwidth with a given quality of service for a given amount of
time. Preferably, a separate virtual trading floor is defined for
each product, so that there is one trading floor for 10 Mb for 10
minutes and a separate virtual trading floor for 5 Mb for an
hour.
[0082] As the trading floor and the broker agents are virtual, each
customer is preferably connected thereto via a client program
30.
[0083] Preferably each broker agent is controlled by the provider
10. Each customer manages his trade activities via a single broker
agent and the broker agents conduct auctioning amongst themselves
over the trading floor 24. Customers can perform two actions, ask
and bid, and both asking and bidding may relate to buying or
selling of resources, as will be explained in greater detail below.
The provider is preferably able to differentiate the auction,
meaning differentiate between different participants.
[0084] Reference is now made to FIG. 2B which is a simplified
diagram showing a platform 50 according to a preferred embodiment
of the present invention. The platform comprises a broker based
interaction mechanism, which comprises virtual agents called
brokers who are assigned, as shown in the previous figure, to
respective providers and users. The brokers manage the requests of
the users and providers regarding the resources and translate them
into bids and offers that can be exchanged with other brokers over
the trading floor.
[0085] A price engine 54 attaches prices to the bids and offers
based on learned information of the users. As will be explained
below it preferably learns a demand price curve for each user for
each product and uses that curve together with the quantity of the
resource indicated in a respective request to arrive at a price.
Other factors may be used such as provider trading policies and the
like. An allocation engine then allocates the resource based on
current availability and a predetermined utility function, which
may take into account prices included, by the price engine, in the
respective offers and bids.
[0086] Reference is now made to FIG. 3, which is a simplified
diagram showing how the platform of the preferred embodiments may
be used when the principle provider 10 requires resources from
another provider. Parts that are the same as those in previous
figures are given the same reference numerals and are not referred
to again except as necessary for an understanding of the present
embodiment. In FIG. 3, DSB represents Distributed Service Broker,
and CC represents Customer Client. In FIG. 3, client 30 of a
customer is connected to the provider domain 32 via a broker agent
as discussed above. However, due to lack of availability at the
provider domain, capacity needs to be obtained from a different
provider having his own provider domain 34. To this end there is
provided an inter-domain broker agent 36, which communicates with
broker agents of another domain, such as inter-domain broker agent
38 of provider domain 34. The two inter domain broker agents
preferably negotiate for resources in the same way as intra-domain
brokers. As will be discussed in greater detail below, there is
preferably provided a protocol for communication between inter
domain brokers. Preferably the protocol addresses security and
privacy issues and additionally addresses the issue of loop
avoidance. Loop avoidance is provided in order to overcome the
problem of offers or bids reaching a given destination several
times from different paths, and is explained in greater detail
below. Preferably, each broker serves one customer. Each
intra-domain broker operates one to many against other brokers and
each inter-domain broker operates one-to-one against another
inter-domain broker. Reference is now made to FIG. 4, which is a
simplified circular flow diagram showing high-level aspects of
operation of a platform according to a preferred embodiment of the
present invention. In a first stage S1, resources available for
allocation are defined--these are the products that are to be
traded within the provider domain. The following stage, S2, allows
the resources to be set up over the network infrastructure, which
is to say time dependent bandwidth units for allocation. In a stage
S3, the trading environment, which is to say the provider brokers,
issue offers and receive requests for trading. In a stage S4, the
customers bid on offers and issue their own requests.
[0087] In a stage S5, the trading environment receives requests and
allocates and or frees resources, which is to say it implements
allocation of the virtual products amongst the customers
accordingly. It is noted that the flow of resources is not simply
from provider to customer. The customer, who may have obtained
resources on a long term basis, can allocate them back to the
provider on a short term basis when the customer is not using the
resources. In general, if the provider is short of resources, it is
more efficient to buy back from customers unused resources than it
is build more capacity or not to supply the demand, and thus the
platform includes the possibility of allowing customers to sell
back unused resources to the provider.
[0088] In a stage S6, the transactions are logged, typically for
the purpose of billing. In a stage S7, the trading environment,
which is to say the platform, collects customer usage statistics.
Patterns obtained from the customer usage statistics may later be
used to assist with smooth running of resource allocation. In a
stage S8, the platform provides a recommendation as to improve the
product mixture and have a better resources allocation that
increases the provider pre-defined utility. That is to say it
decides what kind of available bandwidth parcels to offer the
customer. The procedure then continues with stage S1 or, if there
are no changes, then with stage S3.
[0089] In the following four figures, FIGS. 5-7B, four different
allocation cases are considered. FIG. 5 illustrates a
product-requesting case in which customers wish to buy (or to sell)
products, starting at the moment of making a request, or in a
future specific moment. FIG. 6 illustrates a product-offering case
in which the provider, who has learned and analyzed his customers'
behavior, would like to offer them products to buy (or to sell).
FIG. 7A illustrates a first level options trade, particularly
useful for risk management, in which the provider and the customers
buy or sell an option to buy/sell (e.g. put/call option) a product
at a specific date for a specific price. Fourthly there is the
second level options trade, which creates a derivatives market, in
which the provider and the customers wish to continually trade
(e.g. buy and sell) with options, for their values up to their
expiration dates.
[0090] Reference is now made to FIG. 5, which is a simplified
sequence diagram illustrating the product-requesting case. The
sequence is initiated when the customer issues a request to to his
local (provider supplied) broker. The request can be a buying or
selling request as explained above. The provider's broker
broadcasts the request to all other brokers in the network, which
is to say the trade floor. The brokers reply with BID offers and
the broker serving the initiating customer collects the BIDs,
selects the best BID and uses that best BID as the basis for an
offer to the customer. Provider trade rules may be used to modify
the offer so that the offer does not exactly correspond to the
BID.
[0091] The following examples are possible scenarios:
[0092] 1. The provider issues sell-requests for selected products.
The sell request defines the capacity involved and sets a minimum
price. The sell requests are broadcast to all brokers and each
customer may BID, with the quota and the price.
[0093] 2. A customer issues a buy-request for products to a certain
capacity level. The buy request preferably defines the maximum
price or the required quota. The requests are broadcast to all
brokers and each party (the provider and the customers) may BID,
using the defined quota and the price.
[0094] Reference is now made to FIG. 6, which is a simplified
sequence diagram illustrating the product-offering case. In the
product offering case the provider's broker has learnt the typical
usage patterns of his served customer. Based on the learned
information the broker broadcast requests to buy or to sell to all
other brokers. The brokers respond with bid offers from which the
best is selected and an offer is made to the customer. The customer
then answers with a yes or a no.
[0095] The following example is a possible scenario:
[0096] Suppose one customer generally requests certain products or
product types each working day between 10:00 and 13:00. The broker
learns this pattern and then broadcasts requests to set up an
inventory for the customer. As he does so, the broker offers the
products to the customer at an acceptable price, the acceptable
price being determined from the demand curve. The result is that
the provider can buy the products for the customer in advance and
obtain a better deal than if it were done on-demand. Similarly the
customer receives a quicker response.
[0097] Reference is now made to FIG. 7A, which is a simplified
sequence diagram illustrating the first level option trading case.
The sequence is initiated when the customer issues a request to buy
or to sell an option (put or call) to the provider's broker
operating with him. The broker broadcasts the request to all other
brokers in the network and the brokers reply with BIDs offering to
buy or sell options as appropriate. The broker that serves the
customer collects the option BIDs and selects the best to be
presented to the customer. At the expiration date, the
twin-broker/customer client issues a BID (yes/no) to exercise the
10 option and buy (sell) the product.
[0098] Reference is now made to FIG. 7B, which is a simplified
sequence diagram illustrating the second level option trading case.
The sequence is an extension of the previous sequence. However in
this sequence the option owner can receive a request and sell his
option, or provide an option request (to sell). This may be carried
out at any time up to the expiration date, while the last option
holder, at the expiration date, issues a BID - yes or no for
exercise of the option and allocation of the product according to
the terms of the option.
[0099] Reference is now made to FIG. 8, which is a simplified flow
diagram illustrating the sequence of activities when a customer
issues a request to obtain data carrying capacity, referred to
herein as the pre-trade process. The customer firstly issues a
request, generally via the broker who serves him. The request is
passed on to other brokers who supply bids for providing capacity
currently available from suppliers. The best bid is selected. The
best bid is a bid that maximizes a pre-determined utility function,
that can be developed from a combination of parameters such as--the
customer ID, the profit, the supplier ID and so fourth, together
with respective importance weightings. Thus: U=U(w.sub.1customerID,
w.sub.2Profit, w.sub.3supplierID, . . . )
[0100] wherein U is the utility score, and the w's represent
weighting coefficients allocated to the respective suppliers,
providers and customers.
[0101] Pricing is then calculated using a pricing engine, which
will be discussed in greater detail below, and finally the capacity
is allocated. It is noted that when the market is long, that is to
say supply exceeds demand, prices are set in such a way as to
maximize revenue. Furthermore, the full request of the customer is
fulfilled and then the customer may be presented with additional
offers of spare capacity based on his usage patterns. On the other
hand, when the market is short, then prices tend to rise anyway. In
both cases allocation is preferably made to maximize utility.
[0102] In the case of short supply there is no possibility of
offering spare capacity. The customer places an ask request to buy
needed capacity. His request is broadcast to all relevant brokers
in the usual way. At this point the brokers bid using their own
pricing mechanisms. Now it is likely that some of the brokers place
bids that accord with the customers' pricing. The engine decides
which bidder has won and rewards him with his bidding price. In
addition the customer that placed the initial request preferably
gets the product subject of the offer, but with a price that
differs from that of the seller's offer. If the seller is the
provider then the price paid by the customer may be that set by the
provider however.
[0103] Reference is now made to FIG. 9A, which is an equivalent
flow chart to that of FIG. 8, except that it applies to the case in
which the customer wishes to sell unused capacity back to the
supplier. The basic procedure is the same but in certain respects
is the mirror image of the previous case. In the following only the
differences are highlighted. In FIG. 9A, once again the best offer
is defined as the offer that maximizes a predetermined utility
function. Likewise, pricing is carried out using the price engine,
but is made at the side of the party offering to take the resource.
Allocation is once more made to maximize utility.
[0104] In general, the same product can be offered for different
time durations. If the price is directly proportional to the time
then it is in any user's interest to buy only the current demand
for the minimum duration possible. It is therefore advisable to
provide a mechanism that introduces a factor into the pricing
mechanism to encourage purchase of longer time units.
[0105] In the following, a product is defined as a bandwidth quota
for a specific duration D =(ts-te); (Where ts--is start time and
te--is end time). The duration D may be defined by the provider or
by the customer, as one of the product's attributes. The duration
parameter is the major difference between trade with bandwidth and
trade with products.
[0106] Each product has different supply & demand behavior,
thus for Np products we define Np trade floors. For example there
may be trade floors to trade quotas for durations of a day, a
month, a week, an hour, 20 min, 1 min etc.
[0107] Let [D] be a group of predefined durations D=(d1, d2, . . .
); for example d1=1 min, d2=20 min, d3=1 hour, . . .
[0108] Then, to avoid revenue cannibalization, products with the
same capacities, for the same starting point but with different
durations are preferably P i - 1 = P i d i - 1 d i risk_cost ; d i
> d i - 1 , risk_cost > 1 ##EQU1##
[0109] Risk_cost symbolizes the additional amount that the market
agrees to pay for buying capacity of shorter duration. If, for
example, it is possible to buy capacity for one day and for one
hour, then the `one hour` product price is preferably set at 24
times less then the `one day` price, multiplied by the risk_cost
factor. Thus, factoring in for risk of non-utilization inherent in
buying over the longer term, the longer term products are
cheaper.
[0110] It is possible to expand the use of such a mechanism,
referred to herein as an anti price cannibalization mechanism, by
specifying similar risk cost factors for different types of
fragmentation, for example bandwidth fragmentation. Thus a risk
cost factor may be defined to reward those who buy larger bandwidth
products.
[0111] Having considered how the underlying price is altered to
reflect different products, a pricing engine is now discussed to
explain how an asking price is obtained in individual cases.
[0112] The pricing engine preferably provides a mechanism that
enables the provider to ask using the right offering price, meaning
an offering price that is likely to be accepted.
[0113] A first issue is that of differentiation. In a pure auction,
prices are fully defined by the market, in that all participants
are invited to bid. Then, based on the bid prices received a spot
price is calculated. Various mechanisms may be used to arrive at
the spot price from the bids, for example a first price mechanism,
a second price mechanism etc. The end result is a fully transparent
liquid market which is often not favored by carriers.
[0114] The preferred embodiments use what is known as a
differentiated trading floor, in which the mechanism in use looks
at a level definition assigned to individual participants. The
mechanism may be transparent but is not necessarily so.
[0115] An additional issue is duration dependence. Unlike discrete
products, such as gold and oil, telecom resources are
duration-dependent products. Duration-dependent means that one of
the product's attributes is its supplying time. In other words, it
means that every passing moment is a potential product that can be
sold. Duration dependence is to be contrasted with time dependence,
a term which means that the value of the product changes with time.
The latter applies to most products. With communication connected
products, time dependence of the product includes cyclical time
dependence, in that bandwidth may be more expensive at certain
times of the day and on certain days of the week.
[0116] In conventional dynamic auctions players can place bids
continuously, until the auction is closed; however the product has
a solid definition and the seller loses nothing as a result of the
duration of the auction.
[0117] By contrast, in auctioning of time-dependent products,
during the auction period the seller has a dilemma between on the
one hand closing the deal and rewarding the winner with the current
last offer which may be particularly to the winner's advantage, and
on the other hand continuing to look for a better offer and losing
the revenue that could be generated had the product been sold
now.
[0118] In time-dependant product auctions there is thus a need for
a prediction mechanism that knows right at the start what to offer,
when to offer it and at what price, and in the present embodiments
this may be achieved by learning each and every customer's behavior
individually.
[0119] Such learning may be achieved as follows:
[0120] For every customer:
[0121] For every product (capacity, duration, ts, te):
[0122] Learn the demand curve, that is demand as a function of
price D(P).
[0123] Using the demand curve find the best price to deliver the
maximum revenue, while the prices themselves are limited within the
boundaries defined to avoid cannibalization. D i l j .function. ( P
) + P .differential. D i l j .function. ( P ) .differential. P = 0
##EQU2##
[0124] Since demand is an individual function, it can be
differentiated; which means that the provider can set different
risk_cost factors (for different fragmentations--duration,
bandwidth etc. as explained above) and different minimum wholesale
prices (for buying for the maximum duration, a year for example, or
the maximum bandwidth).
[0125] Trade policies may be set as follows:
[0126] define a minimum price, being the price for buying the
longest duration product, and
[0127] define risk cost factors to apply to different durations of
product. Note that the minimum price and the risk_cost may provide
differentiation factors. That is to say they may be defined for
each customer individually, thereby providing the platform with the
ability to differentiate between customers.
[0128] Reference is now made to FIG. 9B which is a graph providing
a summary of the function of the Pricing Engine. As explained, the
pricing engine's task is to provide any issued ASKs with a best
suitable price. When providing an offer to buyers, its goal is to
maximize income, and therefore the best price will be P*. However,
if the total balance of capacity, of all BIDs and ASKs at a
specific calculated moment is Q2, which means that the minimum
price should be P2 according to the availability of the resource,
then P2 may be set as the ASK price. If, on the other hand, the
balance is Q1, indicating P1, then the ASK price may be P*. In any
case, to avoid price cannibalization as discussed above, the
offered price must not be lower then P.sub.low, which is the lower
boundary.
[0129] Since there are many demand curves, one per customer per
product and per time of allocation, it is almost impossible to
handle a multi-product-multi-customer trade floor using
conventional means. However it is possible to set up a neural
network for each customer or for each identifiable cluster of
customers, since customer behavior in a communication network often
easily clusters, and the neural network can then be trained to
provide the best price for the specific product being requested.
That is to say, preferably, the neural network learns the right
price per product having a defined capacity, duration, and ts.
[0130] Using the neural network as described above is sufficient
for normal, that is steady state or nearly steady state situations.
However, in reality there is burst behavior as well. Burst behavior
can be due to an event. Events may be internal, for example a
network problem. Alternatively the events may be external, for
example the launch at a particular location of an attractive new
web site. In order to deal with such burst behavior it is possible
to define a class of customers that has a similar response to an
event occurrence. If all customers behave normally, that is
according to their demand curves and then suddenly a few responses
are received with aggressive bids, meaning they are willing to pay
more then usual, that means that capacity is short and greater
supply is needed. Being able to recognize such events makes the
system smarter, and each individual customer's behavior at a given
event is preferably stored so that at the next event the platform
is able to make a better guess as to the customer's likely
behavior.
[0131] To find the right opportunity (to sell or to buy) the broker
uses the following procedure:
[0132] The broker learns the player's usage behavior. As he does
so, the broker builds up a usage profile, which preferably means it
finds a set of fuzzy groups that describe the behavior of chosen
measured parameter distributions as a function of time-of-day,
day-on-week and specific dates.
[0133] Then the broker classifies its specific player's profile
into one or more profile classes. A profile class is a fuzzy group
that defines a usage behavior pattern. In the profile class, each
member (a player's usage profile) is assigned its own level of
membership, preferably according to fuzzy logic rules.
[0134] As explained above the broker recognizes exceptions to
normal behavior, and preferably treats such exceptions as new
opportunities that need to be examined. The current behavior is
compared to both the usage profile and the profile class. If an
exception is found to the behavior so defined it implies an
opportunity related to the specific customer, as well as to other
customers having a membership in the profile class group that the
specific customer belong too (up to the membership function). To
explain the identification and subsequent exploitation of such an
opportunity we consider three examples of exceptions that may
signal such an opportunity:
[0135] a. Suppose that one customer's service network is generally
35% utilized at 10 AM on a workday morning, and then one day he
requires 75% of the resource.
[0136] b. Suppose that one customer's usage profile belongs to a
given profile class A that specifies Internet surfing from 10 PM
for two hours, however, one day the player surfs at 11 AM.
[0137] c. Suppose that one customer usage profile strongly belongs
(say more then 0.95) to a profile class A. One day an outside event
(unknown to the system) occurs, causing 30-40% of the members in
the group to change their usage behavior. This means that our
specific customer stands a high chance of changing his behavior as
well.
[0138] Finally the broker prioritizes the new opportunities, that
is to say it prices these opportunities, and may select an
opportunity for direct use in interesting, or making some kind of
offer to the players. The prioritizing mechanism is based on
expected utility theory, wherein the provider predefines weighting
rules and the system then ranks the opportunities based on their
outcome utilities.
[0139] It is noted that fuzzy logic may create situations of
recognizing more then one opportunity, and sometimes the different
opportunities recognized can be in conflict. For example, one
exception may be translated into a sell opportunity, for players
belonging to group A, but the same event is interpreted as a buy
opportunity for all members of group B. As group A and group B are
not necessarily orthogonal there is a finite probability that a
certain player may belong to both groups and is thus simultaneously
subject to the mutually contradictory offers. In such a case the
platform preferably distinguishes between the two opportunities,
prices them and then decides which opportunity suits the given
player better.
[0140] If, at any given time, the provider has spare capacity, that
means that he is able to provide all the capacity he anticipates
that the customers wish to purchase. In such a case, the price may
be evaluated as above and the quota that is estimated is taken
straight from the individual customers' demand curves D(P). The
provider can thereby estimate how much capacity is going to be sold
and how much will be left as spare at every moment.
[0141] However, if capacity is short, or if the provider does not
place enough capacity for sale, that is to say the product on offer
from the provider is small compared with the product demanded by
customers, then there is preferably provided a mechanism that
adjusts the prices accordingly. In this context, reference is made
to FIG. 10 which shows an example of a function that takes the
current usage and provides an adjusted price level.
[0142] The provider preferably controls the prices of its resources
through his broker. The provider broker preferably controls the
products and knows their utilization patterns. When a new request
for a product is received, the broker preferably looks at his
inventory to determine the availability of the product i.e. how
many items are available at the requested starting time for the
requested duration based product.
[0143] The provider defines the pricing curve as a function of
usage--P(usage) as shown in FIG. 10. The curve of FIG. 10 applies
to a market in short supply, however, if the market is long then it
is up to the provider to offer for sale fewer products and thereby
bring about a price rise. Now, if the provider is a monopoly that
the above described activity can be a way to increase the prices.
However, if the provider is subject to competition, then it may
need to find a new product mix. The new product mix may result in a
pseudo-monopoly giving a certain amount of price control, or the
prices may have to be adjusted based on supply and demand of the
market as a whole.
[0144] For every traded product the broker manages accounts that
summarize usage at specific moments.
[0145] The broker then calculates the price to be offered.
[0146] The provider's broker defines the provider's product prices
as they are sold from the inventory. The defined price becomes the
base product price. Then every broker that asks for the product
subsequently updates the product price and all the prices of
products having shorter duration.
[0147] If the provider wishes to reduce or increase the price, all
he needs to do is to redefine the available capacity for trading,
and the usage percentages may be automatically changed and thus the
prices.
[0148] Reference is now made to FIG. 1, which is a simplified
diagram of an allocation engine for use with the present
embodiments. Allocation engine 40 allocates the available capacity
firstly into different product types and then as offers and then to
the individual customers.
[0149] The allocation engine has three main parts as follows:
[0150] 1. a product allocator 42 which finds the optimal product
mixture,
[0151] 2. an offering allocator 44, which allocates capacity for
offering, as part of the ASK procedure,
[0152] 3. a request allocator 46, which allocates capacity to
requests, as part of the BID procedure.
Optimal Products' Mixture
[0153] Firstly, the operation of the product allocator 42 is
considered. It is noted that a product is defined by:
[0154] 1. media--bandwidth (ATM-VP, or MPLS LSP), CPU resource
usage, cache memory, . . .
[0155] 2. capacity--bandwidth: Source, destination and Bit rate,
CPU: Hz, cache memory: place, memory
[0156] 3. QoS--
[0157] 4. Duration
[0158] 5. Start time
[0159] 6. Repetition rate--every day, every week, . . .
[0160] 7. others--any other attributes the provider wishes to add
to differentiate its products.
[0161] The mission of the allocation engine is to define the best
product mixture in terms of how much capacity to allocate to each
product. For example, given 10 Mb free link and two services that
are provided, one 500K and one 250K, the question is how much of
the link to make available as units of the 500K product and how
much of the 250K product? Another allocation example may be product
bundling for different destinations. Given a 600M pipe and ten
different destinations, how much of the pipe should be allocated to
each destination? Is there a destination that needs more then any
of the others?
[0162] Reference is now made to FIG. 12, which is a simplified flow
chart showing a procedure for dynamically determining an optimal
product mix, which procedure is suitable for use by the product
allocator 42. To find the best product mix according to the present
embodiments, the procedure:
[0163] S11. defines the products,
[0164] S12. allocates capacity (# of units) using an initial
guess,
[0165] S13. defines a utility function in terms of:
[0166] revenue,
[0167] traffic,
[0168] other measured parameter or combination of parameters
regarding specific customer(s) and/or route(s) [0169] the utility
function preferably supports
[0170] meaning that utility is increasing with capacity but the
rate of increase is falling.
[0171] Following steps s11-s13, a loop is now entered comprising
steps s14-s17 below:
[0172] S14. Let the trade start and measure the utility generated
from each product,
[0173] S15. Increase the capacity assigned to certain products and
measure the change in their contribution to the utility,
[0174] S16. place the products in order according to levels of
utility change, and
[0175] S17. free capacity allocated to products that have the
smallest utility change and give it to products that have the
greatest changes in their utility.
[0176] Allocate Capacity for Offering (ASK Procedure)
[0177] Returning now to FIG. 11, and the offering allocator 44 is
now considered in greater detail. In making offering allocations
there are two possibilities for the ask mode--ASK the customer to
buy capacity and ASK the customer to sell capacity.
[0178] The price to buy is calculated as explained above in respect
of the pricing engine. For such a price the platform may anticipate
the customer bidding for capacity equal to D(P). In offering to
buy, there is thus no specific role for an allocator.
[0179] However, in the case of making an offering for sale to the
provider, the trade floor preferably operates a reverse
auction--that is to say the trade floor finds the best available
offer, meaning who is offering the highest quota at the lowest
price. Such a sell-back-to-the-provider mechanism is attractive and
can be an advantage in competitive markets, since if customers know
that there is a potential of being paid back for capacity they
don't need, they are encouraged to buy the capacity from the
provider who gives them such an opportunity. Furthermore they are
encouraged to buy larger capacity quotas over longer periods,
knowing that there is a reduced risk of losing out over short term
periods of lower utilization.
[0180] Use of the offering allocator to buy back capacity from
customers is useful when the provider is short of capacity. The
provider may also wish to create a virtual short supply to create a
price increase, and the allocation engine is able to facilitate
such a wish by not allocating available capacity.
[0181] In the case of the customer buying the provider offers a
price and asks the customer how much he wants, whilst having made
an a priori allocation based on the customer's demand curve. In the
case of the customer selling, the provider indicates the capacity
he needs and asks the customer to set a price, the provider then
taking up the capacity according to the price offered. The provider
thereby becomes the customer of his customer. An alternative case
of a customer selling is as follows: A broker agent may determine
that it needs to buy capacity, and, as discussed above, this may be
due to its customer issuing purchase commands, or it may be based
on learned behavior of the customer. The customer's broker
therefore issues a corresponding request for capacity. All the
other brokers on the trading floor receive the requests and,
subject to any given provider policy, 30 they may issue requests to
their own customers to sell the required capacity.
[0182] Allocation of Capacity to Request (BIDs Procedure)
[0183] The function of the request allocator 46 is now considered.
There are two types of request that the provider is asked to
provide BIDs for, these being a request to buy and a request to
sell.
[0184] If a customer issues a request to sell, then the request is
broadcast to all brokers. Some of the brokers determine that the
offer may interest their customer. In such a case the offer is
preferably approached as follows:
[0185] Firstly they check the product price for the customer,
[0186] Secondly they investigate relevant paramters such as any
currently applicable selling policy, the current logic condition of
the price-cost margin, the customer ID, the seller ID, available
capacity in the provider inventory, and other parameters.
[0187] If the above investigations prove satisfactory, then the
brokers allocate the offer to any customer having an identical
quota to that being offered.
[0188] If the customer issues a request to buy and if there is no
resource limitation on the trading floor, then the price is
preferably evaluated using the pricing engine. As mentioned above,
the pricing engine operates, using the respective customer-product
demand-price curve, to offer the price that attains maximum
revenue.
[0189] If the customer issues a request to buy and if the market is
in short (or virtual short) supply of capacity then the BID price
will rise, again according to the dictates of the pricing engine
and the respective customer-product demand-price curve, and the
allocation may be smaller then requested. The allocation will be
according to policy, which may typically be as follows:
[0190] The maximum price gets a full allocation, then the second
highest, and so forth, or in proportional to a price/revenue
balance, thereby to maximize the utility. Utility is typically a
function of different parameters with their weight of importance,
which its first derivative is positive and second derivative is
negative.
[0191] In the following five parts, the dynamic differentiated
auction is considered from a more mathematical perspective.
1: Terminology
[0192] Part 1 defines basic terminology that is relevant for use in
the following chapters. This part provides conceptual descriptions
followed by mathematical notations, while the following issues are
covered: [0193] The resources and the services markets. [0194]
BIDs, and ASKs. [0195] The Future markets. [0196] The Outcry
Auctioneer's game. [0197] The Virtual Trade Floor game.
[0198] In the telecommunication industry it has became common to
talk about two complementary markets--resources and services.
Bandwidth (as well as frequencies, cache memory and CPU time) are
items that may be traded in the resources market. Voice minutes,
SMS messages, video streaming and so fourth are type of services
that may be traded in a services market.
[0199] Let us define the set of all participants, hereinafter
players, including buyers and sellers, by I={1, . . . ,I}. A
player's identity i.epsilon.I as subscript indicates that the
player is a buyer, and as a superscript indicates that the player
is a seller.
[0200] In the resources market, a network owner sells bandwidth,
meaning he sells links between his POPs (points of presence, i.e.
his network's edges). When a buyer purchases a specific link, the
seller is supposed to allocate him the relevant capacity and the
buyer is supposed to pay for the link.
[0201] In the services market, a service operator sells to the
network owner the rights to deliver his service traffic. Although
the service operator may pay the network owner, the service
operator is considered a seller because in such a market the
network operators are competing to get the services' traffic.
[0202] Such markets are considered as complementary markets with
respect to one another since a bottleneck in one market may lead to
overload in the other and v.v. Furthermore, too much bandwidth over
a specific route means there is a lack of traffic, and too much
traffic implies a lack of resources.
[0203] Nowadays the bandwidth resources market is measured in
bandwidth units (i.e. bit-rate) and the services market is measured
in minute units (mainly phone calls minutes). The mapping function
between these markets is dependent on services definitions and
mixtures of different services, as shown in the following
example:
[0204] Taking for example an E1 (2 Mb/sec) link that can handle 30
uncompressed calls, each call requires 64 Kb/sec. Thus 6 Mb/sec
(i.e. three E1s) sold for one hour are theoretically equivalent to
5400 call minutes. We say theoretically because it is possible that
the buyer will not have enough traffic to fill the whole resource,
and in addition, technically he has to leave a certain number of
slots free as a buffer, to take new calls. Generally the size of
the buffer is calculated based on an average call duration, the
ratio between answered and seizure calls--ASR, and the post dial
delay--PDD.
[0205] Now, let us furthermore assume we have video service,
defined with a bit rate of 500 Kb/sec, so that those 6 Mb/sec could
deliver 12 video channels simultaneously. Beside the technical
limitations of buffer requirements, the services mixture is an
important parameter that defines the equivalent function between
the two markets products.
[0206] Let CoS={CoS.sub.1. . . CoS.sub.Ncs} be a set of N.sub.cs
classes of potential services that a service operator can chose to
deliver, while SM i = { ( CoS 1 , a ser .times. .times. 1 ) ,
.times. , ( CoS i Ncs , a i ser ) } ##EQU3## is a subset of CoS
that defines the services' mixture chosen by service operator i to
be sold in the services market. The services' mixture is a set of
pairs, each defining the class of service and the service amount
allocated by the service operator--a.sub.ser (for example number of
call minutes, or number of video channels).
[0207] A CoS defines attributes that are relevant to specific
services. In the following we relate to two parameters: QoS (delay,
packet loss, jitter, etc') and BR (bit-rate), Other attributes may
be handled in a similar way to that in which the QoS is handled
herein.
[0208] We may define traded product capacity (bought by player i
from playerj) c.sub.i.sup.j=c.sub.i.sup.j(in,e,BR,QoS), which in
the resources market defines a link between the ingress (in) and
egress (e) points and in the services market defines the amount of
service traffic between source and destination (ingress and egress
points). The two products are equivalent up to the point of
technical tolerance (a(a.ltoreq.1) ) to compensate buffering
requirements:
c.sub.i.sup.j|.sub.service=ac.sub.j.sup.i|.sub.resource (1)
[0209] For example, if the service operator tolerance is 70%
utilization, then 2 Mb/sec voice quality link sold by player i to
player j for 3 hours in the resources market is equivalent to
0.7*2M=1.4M (which are 3780 call minutes) sold by playerj to player
i in the services market.
[0210] However, while dealing with services it is also common to
buy minutes' capacity to be deployed over the long term (say a week
or a month). For example, a carrier may buy/sell 3000 calls'
minutes per month; meaning that on average he receives or sends 100
minutes every day, distributed over the day. In such a case we need
to expand the above relation (1) to deal with a more comprehensive
function such as
c.sub.i.sup.j|.sub.service=c.sub.j.sup.i|.sub.resource(a,t,i,j,service),
which means that it is time, buyer, seller, service and tolerance
dependent. We further assume we can define such a function and
adjust its parameters, based on historical traffic monitoring.
Thus, from that point of view we further use the term capacity
c.sub.i.sup.j for both markets, since they are complementary.
[0211] Now, in the real world, both players look for trades that
may contain more than one resource or service. Therefore, we may
expand our capacity definition as follows:
[0212] We assume a sellerj trades with resources/services capacity
components defined in the vector C _ j = ( c 1 j , .times. .times.
c L j ) ##EQU4## with L capacity components, each identified by its
attributes c l j = c l j .function. ( i .times. .times. n , e , BR
, QoS ) , ##EQU5## where l.epsilon.L. We may define that the
capacity component c l j ##EQU6## defines the entire pipe or total
communication capacity between the ingress and the egress points.
We also assume that there is no overlapping, which means that for
every l and k there is no c l j .di-elect cons. c k j .
##EQU7##
[0213] In a case of resource capacity it is the seller's
responsibility to define the trade granularity between every two
routers or between two edges of its cloud. The same applies in the
case of service capacity, in which case it is the seller's
responsibility to define the service granularity--that is the
number of minutes taken as the underlying unit on the basis of
which are defined the specific services or packages of services. It
is noted that no overlapping means that if the capacity traded is
packages then trade with specific services is not allowed.
[0214] In both markets, products change hands after setting a
mutual agreement between the buyer and the seller. These agreements
define the payments one party has to give the other. The Dynamic
Differentiated auction supports three types of compensation, which
may be pre-defined between the parties as a general trade
agreement. We may assume player i buys from player j and they issue
a payment agreement between them p.sub.i.sup.j=p.sub.i.sup.j(cost,
risk, fee), while: [0215] cost--is a currency based payment the
buyer requires to pay the seller for the goods, [0216] risk--is
agreed compensation one party pays to the other, in case the
agreement is not fulfilled. The risk value is assumed to cover the
other party's loss from being unable to complete the trade, [0217]
fee--is an additional cost being paid to the contract issuer.
Usually it is the maximum between a minimal payment and some
percentage of the cost.
[0218] The DD auction algorithm provides two mechanisms that enable
handling of the trade. If the buyer initiates the trade then he
places a bid, and if the seller initiates the trade then he places
an ask.
[0219] Suppose player i is buying from player j. Then he places a
bid b.sub.i.sup.j=(q.sub.i.sup.j,p.sub.i.sup.j), meaning he would
like to buy from j a quantity q.sub.i.sup.j (of capacity
c.sub.i.sup.j) and is willing to pay (or being paid) a unit price
p.sub.i.sup.j.
[0220] Since carriers build their selling strategy by
differentiating among their buyers, the inter-carrier market is
found not to be pure liquid. On this point the reader is referred
to R. Jacob "Does communication become commodity?" QSDG magazine;
September 2001, the contents of which are herein incorporated by
reference. Therefore, unlike the classic auction, we define that a
seller j places an ask s.sub.i.sup.j=(q.sub.i.sup.j,p.sub.i.sup.j),
meaning he is offering a player i a quantity q.sub.i.sup.j (of
capacity c.sub.i.sup.j) with a `floor` differentiated price of
p.sub.i.sup.j per unit.
[0221] The future market is a well-known financial tool that is
used to manage investment risk since in some respects it enables
reliable forecasting and allows investigation of future trends. The
DD auction supports two types of contracts--the futures contract
and options. There is also the possibility of developing a
secondary market, where these contracts may be traded. The
implications of such a development may have direct influence on the
first markets (the services and the resources), and therefore we
discuss these possible influences in the Pricing Engine
chapter.
[0222] The Future Contract
[0223] Suppose player i wishes to buy a future contract starting at
t.sub.s>0 and finishing at t.sub.E from player j of a resource
or a service l, then he places a bid b i l j = ( .times. q i l j ,
p i l j .times. ) , ##EQU8## where q i l j = ( .times. c i l j , t
s , t E .times. ) . ##EQU9##
[0224] Note that if t.sub.s=0 this is a SPOT market while
t.sub.s>0 defines a future market.
[0225] At t.sub.s we have three situations: 1) the buyer takes all
his requested capacity and the seller allocates him all the
requested capacity, 2) the buyer takes part of his requested
capacity (or even nothing) and the seller allocates him all that he
takes--i.e. the buyer breaks the contract, and 3) the buyer takes
all his requested capacity and the seller allocates him part (or
nothing)--i.e. the seller breaks the contract. The second and the
third cases may be agreed between the parties to involve a certain
amount of penalty payment, referred to herein as risk. It is also
possible to consider behavior of ATM networks, where the players
may trade with UBR or VBR (unsigned bit rate or variable bit rate)
capacity. In such a case it may typically be agreed by the players
that the capacity is flexible and no party is committed--thus the
risk is zero.
[0226] There is a certain probability of occurrence for each case
and, based on a bid's history and the usage profile, the DD
algorithm considers these probabilities.
[0227] We use the same terminology to define the ask procedure for
a future contract, s i l j = ( .times. q i l j , p i l j .times. )
, ##EQU10## however the ask procedure for a future contract is in
practice a tool for the seller to offer different packages to his
customers. If no buyer signals with a bid, then there is no
contract and there is no obligation from the seller side to supply
the capacity.
[0228] The Option
[0229] An option to buy--referred to as a call ( .times. q i l j ,
p i l j , E l .times. x .times. .times. D .times. ) ##EQU11##
--means that a seller j issues a buyer i an option to buy capacity
q i l j ##EQU12## of resource or service l at a specific price p i
l j ##EQU13## at a specific date E l .times. x .times. .times. d ,
##EQU14## which is the expiration date, and the seller of the
option is obligated to this contract. It being an option the buyer
however is under no obligation to use the option. If the expiration
date is past and the buyer has not realized his option, then the
opportunity is lost, and the option has no value.
[0230] An option to sell--put ( .times. q i l j , p i l j , E l
.times. x .times. .times. D .times. ) ##EQU15## --means that the
buyer issues the seller an obligation to buy capacity q i l j
##EQU16## of resource or service l at a specific price p i l j
##EQU17## at a specific date, and the seller has the option to
realize the contract, until the expiration date Exd.sup.t. Once
again, if the seller does not take up his option by the expiry date
then the option expires without value.
[0231] In the same way as with the differentiated ask definition,
we may define the option value as a differentiated value. The
option issuer may write a different option of the same
resource/service quantity to different customers, and so the option
takes a different value.
[0232] We use a Black and Scholes model to evaluate the current
option value. It is noted that this model is just an example and
there are many other models that can be used to value options. C 0
= S 0 .times. N .function. ( ln .function. ( S 0 / X + r f .times.
T ) .sigma. .times. ( .times. T .times. ) + .sigma. .times. (
.times. T .times. ) 2 ) - Xe - r f .times. T .times. N .function. (
ln .function. ( S 0 / X + r f .times. T ) .sigma. .times. ( .times.
T .times. ) - .sigma. .times. ( .times. T .times. ) 2 ) ( 2 )
##EQU18## Where:
[0233] C.sub.0--is the current option value.
[0234] S.sub.0--is the current differentiated SPOT price of the
capacity, which is the p i l j ##EQU19## of the current ask.
[0235] X--is the option realization price, which is the p i l j
##EQU20## defined in the option.
[0236] r.sub.f--is the current labor debit value.
[0237] T--is the expiration date, Exd l ##EQU21##
[0238] N--is the normal distribution function
[0239] .sigma.--is the normal deviation of the current
differentiated SPOT price S.sub.0.
[0240] Thus, the seller may use his history information to evaluate
the future price of the product, and then to place a call option.
Since all prices are differentiated, the option value likewise has
a differentiated value. The decision regarding the quota is
discussed hereinbelow in the part Allocation Engine.
[0241] In a general auction the outcry auctioneer presents the
seller objectives and he has two roles: 1) to place asks and, 2)
after the bidding to allocate the capacity. In other words we can
say that in the allocation process the auctioneer is required to
allocate service or resources capacity to current bidding buyers
and to future bidding buyers (i.e. to place asks).
[0242] We may assume that at any specific moment the auctioneer
deals with N.sub.B bids, with requests for capacity quantity
defined by a matrix Q.sup.j having N.sub.B columns and L rows,
wherein each component q i j l .function. ( n ) = ( c i j l , t s ,
t E ) .times. | n .di-elect cons. N B ##EQU22## defines a capacity
quantity c i j l ##EQU23## requested by i from j in the n-th bid
(i.e. how much capacity c j l ##EQU24## to buy) which is required
at t.sub.s until t.sub.E. Please note that N.sub.B is
instantaneous, since every moment the seller and the buyers can
places different number of asks and bids respectively.
[0243] For a component l, the relationship between c j l ##EQU25##
and the sum of Q.sup.j row Q j l = n = 1 N B .times. q i j
.function. ( n ) l ##EQU26## defines its economy of sale; if we
take out the asks placed by the seller then if c j l < Q j l
.times. | N B .di-elect cons. Buyers ##EQU27## the product is
traded short; if c j l < Q j l .times. | N B .di-elect cons.
Buyers ##EQU28## the product is traded long, and if they are equal
then we have equilibrium between supply and demand.
[0244] We may define that when buyer i places a bid n with
t.sub.s=0, it means he would like to buy the whole capacity q i j l
.function. ( n ) ##EQU29## of resource or service l, which he is
bidding for. Thus, seller j may allocate him a i j l c j l
##EQU30## such that a i j l c j l .ltoreq. q i j l .function. ( n )
##EQU31## and the buyer will not be disappointed (i.e. the buyer
takes all the capacity allocated for him).
[0245] However, in future market trading, it is possible that some
asks will not be achieved, as well as some future contracts and
options. There are different penalties (risk) for these
non-achievements, of which some will be paid to the seller and some
will be paid by the seller.
[0246] Option expiration dates and forward contracts' realization
dates are the link between present and future market trading. Thus,
the seller process should consider both markets, while placing asks
and allocating capacity.
[0247] Thus, the auctioneer game consists of three questions: 1)
how much capacity to allocate for new asks, 2) what should be the
new asks' prices and 3) how to allocate service or resource
capacity among the current bids. This is a classic multi-objective
decision making (MODM) game, which is discussed in the
multi-objective decision part below and is used to formulate the
auctioneer's game:
[0248] Let C j = ( c j 1 , .times. .times. c j L ) .times.
##EQU32## be the resource/service capacity vector of seller j and
let Q.sup.j be the resource/service capacity requests matrix, where
each component q i j l .function. ( n ) ##EQU33## defines a
specific n-th bid (or ask) allocation request of resource l to
buyer i. Then for every l the auctioneer needs to: Maximize .times.
: .times. E .function. ( U ) = k = 1 K .times. U .function. ( W k )
.times. p k .times. .times. Subject .times. .times. to .times.
.times. a _ j l .di-elect cons. A l .times. l j ( 3 ) ##EQU34##
[0249] wherein E(U) is the expected utility,
[0250] p.sub.k is the probability of outcome k, and
[0251] W.sub.k is the resulting wealth of the decision-maker, if
outcome k is realized. A l .times. l j ##EQU35## are seller j's
alternative allocations for resource/service l and a _ j l
##EQU36## is the allocation vector of the resource/service, which
support .A-inverted.i,j: n = 1 N .beta. .times. a j l .function. (
n ) .ltoreq. n = 1 N .beta. .times. q i j l .function. ( n ) c j l
( 4 ) ##EQU37##
[0252] In simple words, the seller needs to decide what percentage
ratio of capacity component to allocate a specific bid (or ask) to
a buyer, that maximizes his expected utility, while some of the
asks can be placed by over-booking.
[0253] We define the `extra` ratio for capacity component: Ext j l
= n = 1 N .beta. .times. q i j l .function. ( n ) c j l ( 5 )
##EQU38##
[0254] As described above this ratio presents the economy of the
trade. If Ext j l > 1 ##EQU39## than we have a short, or
artificial short situation, where the bids and asks quotes more
capacity than available. If Ext j l < 1 ##EQU40## than the
market has extra capacity, which means that the seller has to place
asks in order to sell these extras. Accordingly, it is possible to
rewrite (3) as follows: n = 1 N B .times. a j l .function. ( n )
.ltoreq. Ext j l ( 6 ) ##EQU41##
[0255] which means that the total sum of the allocation percentages
should at least equal the extra ratio. If all bids receive their
complete quota, than the sum is equal to the extra ratio, however
since it is possible that some buyers will be allocated less quota
then they bid for, it is then that the extra ratio may be bigger
than the total sum.
[0256] A special case applies when n = 1 N B .times. a j l
.function. ( n ) = Ext j l = 1 , ( 7 ) ##EQU42##
[0257] in which the market is in balance and there is equilibrium
between supply and demand. We call this point an equilibrium point
and the pricing strategy is developed hereinbelow around this
point.
[0258] Theorem 1: In present market trading, if all bids are placed
with t.sub.s=0, if the extra ratio is Ext j l < 1 , ##EQU43##
then p.sub.k=1.
[0259] Proof: If all bids are placed with t.sub.s=0, it means that
there is no traded option and as defined above the buyer takes all
resources allocated to him. If the extra ratio is less than one,
then it means that there is enough capacity for all bidders, thus
the probability for all bids to be realized is one.
[0260] Remark: In future market trading, even if Ext j l < 1 ,
##EQU44## we have p.sub.k.ltoreq.1, since it is possible that some
future bids, for example of the options type, may chose not to buy
the entire requested capacity.
[0261] In a further example the seller takes into account not just
the currently available bids but also likely bidding behavior over
a relevant future timescale. Thus if at a current time a provider
has bids to fulfill at a low price but he knows that within a
number of minutes or hours the price is likely to rise then he may
choose not to fulfill current bids but rather retain the capacity
for greater overall profit in the near future. A future likelihood
of a sale may be considered in terms of overall utility containing
a term for the probability of the bid occurring.
[0262] The Auction Procedure
[0263] We define the auction as an on-going procedure that repeats
every .DELTA.T.sub.cycle. In every cycle (say at time t.sub.cycle)
the `outcry` needs to deal with different type of bids and
asks:
[0264] 1. Existing and running bids--all bids that the Auctioneer
had allocated capacity to at t<t.sub.cycle.
[0265] 2. New received bids for current allocation--all bids that
have been received as a response to asks placed in the previous
cycle (i.e. at t=t=T.sub.cycle-.DELTA.T.sub.cycle) their starting
time being within the cycle time (i.e.
t.sub.cycle.ltoreq.t.sub.s<t.sub.cycle+.DELTA.T.sub.cycle).
[0266] 3. New received bids for future allocation--all bids that
have been received during the current cycle as a response to asks
for future contracts or options, whose starting time is after the
cycle time (i.e. t.sub.s>t.sub.cycle+.DELTA.T.sub.cycle).
[0267] 4. Existing bids for future allocation--all bids that have
been received before the current cycle (i.e. at t<t.sub.cycle)
as a response to asks for future contracts or options, whose
starting time is after the cycle time (i.e.
t.sub.s>t.sub.cycle+.DELTA.T.sub.cycle).
[0268] 5. Future bids that reach their expiration date or starting
time during the current cycle (i.e.
t.sub.cycle.ltoreq.t.sub.s,ExD<t.sub.cycle+.DELTA.T.sub.cycle).
[0269] 6. New asks for current market--new asks that the buyer can
bid for in the next cycle.
[0270] 7. Old asks for the current market--those asks that were
placed prior to the current cycle. These asks may be replaced by
new ones, with a new price and new capacity.
[0271] 8. New asks for future products--new asks for future
contracts of options.
[0272] 9. Old asks for future products--old asks for future
contracts of options.
[0273] In short the auctioneer procedure is as follows: the
auctioneer may summarize all current required capacity and offer
capacity. Based on the Extra value the auctioneer should determine
the total capacity for new asks, and using the pricing engine
should determine a price for every new ask.
[0274] It is assumed that the probabilities required to determine
pricing and allocation can be evaluated from the bid history and
the customer database. We also assume we can construct a utility
function U(W), which maps the players' objectives from a measured
wealth W to a level of utility. Such wealth parameters could be:
bid pricing, bid quota, the difference between the bid pricing and
the SPOT, the importance of the customer, or any other measured
interest or logical rule. Based on the expected utility theory we
may construct the decision-maker's utility curve U(W) to support
two axioms:
[0275] 1) the first derivative of U with respect to W is positive,
i.e. the decision-maker always prefers more wealth to less wealth,
and
[0276] 2) the second derivative of U with respect to W is negative,
i.e. each successive increment in wealth yields less additional
(but still positive) utility.
[0277] The Auctioneer game presented above is a decision maker
problem--the decision maker in question typically being the seller.
In the telecommunication market all players act as sellers and
buyers and if we expand the game presented above to deal with
multi-players (i.e. multi-decision makers) then it is a virtual
trade floor game.
[0278] Let assume there are I non-cooperative players, and the
decision variable controlled by the i-th player is denoted by
x.sub.i. Then x.sub.i is called the strategy of the player i. Let
the objective function of player i be denoted by f.sub.i, then
f.sub.i is called the pay-off function of player i. The set X of
all possible decision vectors, x=(x.sub.l . . . x.sub.1), is now
called the set of simultaneous strategy. (In a particular case,
when for all x.epsilon.X, f.sub.1+. . . f.sub.1=0 the game is
called zero sum).
[0279] The solution of such multi-players game is a vector
(x.sub.1*, . . . x.sub.1*).epsilon.X called the equilibrium point
of the game, if for all i and x.sub.i f.sub.i(x.sub.1*, . . .
x.sub.1*).gtoreq.f.sub.i(x.sub.1*, . . . x.sub.i-1*,x.sub.i+1, . .
. x.sub.1*) (i=1, . . . I)
[0280] The vector x*=(x.sub.1*, . . . x.sub.I*) .epsilon.X is an
equilibrium point of the game if and only if it is a fixed point of
the mapping M, that is x* .epsilon.M(x*), while M .function. ( x _
) = { y _ .times. .times. y _ .di-elect cons. X , max y .di-elect
cons. X .times. i = 1 l .times. f i .function. ( x 1 .times.
.times. .times. x i - 1 , y i , x i + 1 , .times. .times. x l ) } .
( 8 ) ##EQU45##
[0281] In other words, the equilibrium point is a point at which no
players change their strategy, because if they do so, their
objectives will be less well fulfilled.
[0282] A simple way to look at the problem is to allow the players
to play, each using his own decision making process to achieve the
best choice (i.e. x*.epsilon. X) for himself, given his objectives.
The players' objectives (i.e. f.sub.i(x) ) may be measurable
parameters such as profit and loss, or subjective parameters, such
as risks and preferences.
[0283] However, in multi-players game every player has a large
number of alternative routes, with different combinations of
bidding/asking timing, directions, quality of service etc'. Here a
preferred embodiment of the differential auction algorithm serves
to determine the best player's strategy, considering cooperative
and competitive relationships/strategies.
Part 2: The Economy of Sell's Strategies
[0284] The core idea of implementing the differential auction in
telecommunication network is to increase the trade dynamic. By
doing so the auction increases the response flexibility and as a
result the network efficiency increases. The outcome is that buyers
enjoy new opportunities without the need to buy resources for the
long term. In other words the unit price may be reduced in time,
however the total income for the seller increases since resources
are more effectively utilized. In order to ensure an overall
revenue increase we need to set the price based on a sound economic
calculation.
[0285] In general we see two market situations:
[0286] 1) where resources are traded short and
[0287] 2) where resources are traded long.
[0288] First we look at a scenario of the short situation
separating present and future trading. Then we look at the long
situation for present and future trading. This part provides
qualitative analysis of the sell strategies; and provides the
basics for the next two parts that define the pricing and
allocation mechanisms.
[0289] Deficiency and Present Trading
[0290] When capacity is short it means there are bottlenecks in
resources that require business-oriented management. This case is
relevant for tier three service providers that lease limited
capacity network resources, through which to run their service
traffic.
[0291] In present-only trading, all allocated resources may be
bought by the buyers, and it is very possible that some or all of
the buyers will not get what they are asking for, due to the
deficiency. Therefore, since the seller does not provide all the
buyers' requests it is possible that the buyer will have to
consider the risks involved in trading with such a provider. We
discuss this issue in the buyers' game part herein. However, we
refer here to two different situations:
[0292] 1. The monopolistic seller: who can increase his prices
until he reaches equilibrium, as in eq.7: n = 1 N B .times. q j
.function. ( n ) = c j l l i ( 9 ) ##EQU46##
[0293] However, we should remember that we are dealing with
differentiated SPOT prices, which means that the price may be
evaluated according to the seller's trade roles and policies. Thus,
although the pricing is an important parameter in the trade, other
objectives should be considered to reflect the sellers' policy. For
example: a seller might be interesting in a good relationship with
a specific buyer, so he will wish to supply him with all his
requests even in a shortage and even if he is not making the best
offers.
[0294] 2. A competitive market: meaning that the seller needs to
adjust his pricing according to the market pricing level. If the
market is efficient (i.e. prices are transparent) then eq. 9 above
is the result, since prices are evaluated by market forces.
Therefore, the seller dilemma is to define the best mixture of
services. A good mix will differentiate him from other sellers and
as a result will bring him more revenue. The service mix will be
dealt in the Allocation Engine part below.
[0295] Deficiency and Future Trading
[0296] The case of deficiency and future trading is interesting,
mainly in the competitive environment. If the seller monopolizes
the market, then he can raise prices to the equilibrium point (eq.
9). In addition a monopolistic seller will have no motivation to
sell options, because if he does so he gives his customers a better
opportunity to manage their investments and therefore to compete
with the seller in his own territory (if the buyer is a service
provider as well). However, in a competitive market, sellers are
always motivated to sell futures, to avoid situations of
underutilized resources
[0297] If the sale is in a competitive environment, which probably
is the more common situation, then although the seller has limited
resources (i.e. less then the demand), it is possible that in the
market there are enough resources and maybe even more then needed.
Consequently the deficiency is only from the sellers perspective,
and not from the buyers' perspective. If we have a non-cooperative
game, between the sellers i.e. they are not organized as a cartel
to keep their prices high, then the seller has to play a very
sensitive game. On the one hand, he would like to sell all his
capacity, but on the other hand, he wishes to protect his
reputation. That is to say if he promises to allocate a certain
amount of capacity, he should avoid being short and thus unable to
fulfill his promises.
[0298] Unlike a monopolistic situation, where increasing prices can
create a balance between supply and demand, here a simple auction
may cause prices to reach the market pricing level. One of the most
popular tools sellers use today, is to sell long term contracts.
With this tool the seller guarantees his customer loyalty (at least
for the contract's period), which means a guaranteed revenue
stream. The future trade floor therefore adds additional dimensions
to these long-term contracts--to create flexible trading and to
expand sales opportunities. Thus the main issue is to determine the
right offer mix to attract the buyers. With the right mix the
seller can guarantee his revenues, up to the point that the buyer
prefers to break the deals that is at the point where the penalty
cost is less then the difference between the buyer's price and the
market price.
[0299] Extra and Future & Present Trading
[0300] Technology developments have brought about the situation
that most of the US and European markets have huge unutilized
bandwidth resources. The resource market is generally long and in
most cases it is a competitive market as well.
[0301] In a monopoly market, the seller controls the market price
(up to the regulator limits). Therefore he can increase the prices
up along the demand curve, to maximize the total revenues. The DD
auction is unique as it sees every buyer as individual; and the
algorithms disclosed herein learn the individual demand curves.
[0302] In such cases every allocation can be realized. Therefore,
the seller game becomes less an issue of competing applications
(over limited resources), but more an issue of pricing being
offered in the ask stage in order to maximize the seller's expected
utility.
[0303] Such a situation is similar to the classic auction in that
the seller places ask requests and the buyer signals the amount he
would like to buy. However, the long or short states of the market
may merely be instantaneous situations. Thus if the buyer does not
have a smart broker to act for him, he may not discover the
seller's trading status. Therefore, he is likely to place bids with
higher costs then the minimum that was presented in the ask
request, to guarantee his desired allocation.
Part 3: The SPOT & Future Pricing Engine
[0304] The role of the pricing engine is to provide the right
prices to be placed within an ask request, thus
s.sub.i.sup.j=(q.sub.i.sup.j,p.sub.i.sup.j), where
p.sub.i.sup.j=p.sub.i.sup.j(cost, risk, fee) for a specific service
or a resource capacity which a seller i may offer to a potential
buyer j.
[0305] The pricing engine consists of two steps:
[0306] 1. Determine a common cost value for the offered capacity,
and
[0307] 2. Determine an adjust to provide a differentiated price
(i.e. cost, risk and fee) for each and every customer, based on his
SLA.
[0308] The pricing engine is as described above.
Part 4: The Allocation Engine
[0309] The allocation engine is preferably designed to receive bids
that include required quota and price from buyers. However, the
platform also uses ask requests, which means the buyers may receive
offers to buy specific quota for a specific price. In this case the
seller may define the price and therefore the preferred embodiment
may provide an algorithm to suit the pricing methodology.
[0310] Traditionally there are several allocation concepts, for
example:
[0311] 1. First come first served--which means that allocation
priority is decided according to the bid time. In such a case the
seller might lose potential income he may get from other bidders by
not allocating the resource. However, with this role there is
always a guarantee of maximum utilization. In short trading,
maximizing utilization is not the main target, since the demand is
greater than the supply. Therefore, such an allocation strategy is
less attractive when the market trades in short.
[0312] 2. Revenue proportional allocation--which means that the
allocation is proportional to the bidders prices:
[0313] Revenue proportional allocation is preferably achieved by
ordering bidders based on their bid prices and allocating resources
accordingly. Bids at the same price split their quota
proportionally according to the respective quantities requested.
For example, assume three buyers who have placed the following bids
respectively:
[0314] (55%, 1$), (25%, 0.7$), (50%, 0.7$), then the first player
will get 55% of the resource, and players two and three will split
the remain 45% between them--15% and 30% respectively. (Prices are
per unit).
[0315] 3. The PSP as defined in N. Semert, Raymond R, F. Liao, A.
Campbell and A. Lazar, "Pricing, Provisioning and Peering: Dynamic
Markets for Differentiated Internet Services and Implications for
Network Interconnections"; Columbia University 2000,the contents of
which are hereby incorporated by reference.
[0316] Using PSP, a player i gets the minimum of 1) his request, 2)
the remaining bandwidth after making allocations to all others
players that placed bids at a higher price. A player i is charged
for the bandwidth allocated to him by the amount of money the
seller could get from all other (that is remaining) players if he
would not have allocated the bandwidth to the present player.
[0317] There are two major problems with each of these traditional
allocation rules, firstly they assume a liquid market and secondly
they do not consider the products as duration dependent. Since the
telecom market is not in fact liquid and since it prefers to remain
as such, in order to apply a system to the telecom market it is
preferable to embrace a differentiated SPOT pricing method.
Differentiated spot pricing means that allocation and pricing are
set according to the seller's trade policies, that is
differentially for different customers or different types of
customers. In addition, duration dependent products require a
mechanism that continuously examines current resources states and
current BID and ASK requests to evaluate implications of current
product allocation to the provider utility.
[0318] In the following we discuss the concept and the operation of
such an allocation engine.
[0319] Firstly it is noted that old ask requests, that is ask
requests that have been on the system for some time, are replaced
by a new one if the utility of the new one is better, and this may
be achieved by allocating zero capacity to the old ask.
[0320] Considering problem (3) as defined above, assume we have a
group of objectives. Every allocation combination may receive a
grade according to its fulfillment level and then it becomes
possible to chose the combination that provides the highest rank in
the light of the group of objectives.
[0321] It is preferable to create a group of measures, such as:
quota, price, difference between differentiated SPOT and the bid's
price, bid history (for example how much quota the buyer usually
buys on average over a month, over days, or over specific hours),
importance of the buyer, which may be defined in levels by the
seller (e.g. gold, silver . . . ), and the application rank (as
defined by the seller and the buyer before the trade). We
preferably evaluate these measures for each bid. Each measure has
its weighting function, as defined by the seller. The weighting
function can be a weighting number or a conditional function. Then
the expected utility may be evaluated for every bid. An
implementation for solving the allocation problem can use the
technique that was proposed by Gini--in practice trial and error.
The technique guesses a solution, then checks the expected utility,
and then attempts to improve it by changing the allocation and
rechecking the utility. A preferred implementation extends the
technique by adding a guessing mechanism, and also an additional
allocation-adjustment mechanism, the latter being to handle not
only present allocations, as received up to the point in time at
which the calculation is made, but also duration-based allocations
to adjust continuously at future moments.
[0322] The guessing mechanism may rely for example on dynamic
learning of the players' bids, traffic behavior and service growth.
It is also possible to use information from long-term market
operation as a reasonable starting point for guessing for current
market prices. Such a guessing mechanism provides a vector of
probabilities regarding allocations at the calculated moment as
well as corresponding expected revenues. In other words the new
guessing mechanism provides an evaluation of the expected utility
giving the possible allocation vector.
[0323] The allocation made, which provides a solution for problem
(3) discussed above, is preferably proportional to the guessed
expected utility, considering not just the current received BIDs
but the entire body of received BIDs and ASKs and associated
history, as follows:
[0324] We define a set of allocation rules to answer the question
`how much does a specific player belong to a specific resource` and
the allocation is then carried out according to the answer to that
question.
[0325] For example a rule may be set as follows, `if the bid has
high expected utility then the bidder is associated with the
resource`. In this case a membership function is accorded to the
expected utility, so where it is higher it implies greater
belonging and then the corresponding bidder receives more quota for
that resource.
[0326] As another example, let us assume the following set of
rules:
[0327] If the bid has high expected-utility then the bidder is
associated strongly with the resource
[0328] If the bidder is a strategic customer then he is associated
with the resource.
[0329] If it is busy hour and the bidder is not a preferred
customer then the bidder is not associated with the resource.
[0330] Each rule defines a different type of association or
membership and one may use fuzzy AND and fuzzy OR functions to
aggregate all these roles.
[0331] We may also use the fuzzy rules to define un-measured
parameters, while measured parameters may be used for evaluating
the expected utility function.
[0332] Since this technique considers current and future BIDs and
ASKs it can handle duration dependent products allocation, while
enabling market forces to direct allocation to an optimal
solution.
[0333] Solution in the Allocation Space
[0334] One way to look at the problem that the allocation engine
tries to solve, is how the provider should allocate its network
resources to different services networks, whilst dealing with
dynamic services. The solution is preferably an efficient algorithm
that obtains different customers Asks for different products and
different allocating times and produces as a result an allocation
vector coupled with a vector of relevant pricing.
[0335] Dealing with dynamic services means that Asks may be for any
different times in the future and for different durations.
Therefore, to find a solution it is preferable to examine the
impact of the players and their activities at each calculation
point and for every balance point while predicting possible future
activities. An iterative algorithm is required, whose efficiency
and optimality depends on its predicting ability. Such a type of
solution has been discussed hereinabove.
[0336] Another way to look at the above problem is to transform it
into allocation space, where time becomes a parameter rather then a
variable. By doing so one in effect freezes the time and the
dynamics and deals with a static or semi-static problem. The idea
is to take the multi trade floors model as discussed above and to
set each trade floor to deal with trade of a specific duration
product that may be allocated at a specific allocation time. It
becomes apparent that the problem to be solved is how much resource
to allocate to each and every trade floor and what should be the
allocation and pricing mechanism within these trade floors.
[0337] To explain the solution concept we focus on a scenario in
which a customer would like to buy products from the provider. A
series of messages pass between the customer's client and the
broker and between the broker and the trade floor, according to the
protocols discussed above.
[0338] We assume that the provider defines the available products
and the broker presents these products to his served customer. Each
product presented includes the ingress and egress points, the
capacity (e.g. required BW and QoS) and the duration.
[0339] As the customer issues a request for information regarding a
selected product, the broker forwards the question to the trade
floor that deals with the relevant allocation time and duration.
Subsequent processing is detailed below. We assume that the trade
floor provides a minimum expected utility that can be valid up to a
pre-defined time. The broker then calculates the required price
that benefits the provider and presents it as an offering to his
customer, using a function such as: P.sub.r=f(EXP(U(w)))
[0340] Finally, the customer can issue an Ask. The trade floor
receives the Ask and allocates the product to the customer.
[0341] We now detail the trade floor algorithm.
[0342] As the broker receives a request for an offer, he transfers
the request to a sub-module which maps the request from the
customer's service network topology into the provider network
topology. Such a map-new-service module preferably uses a searching
algorithm on a price graph.
[0343] Let R=(L.sub.1L.sub.2, . . . L.sub.r) be the provider
network resources. Then the function map-new-service carried out by
the module provides a subset of R.sup.s=(L.sub.1,L.sub.2, . . .
L.sub.r.sub.s) .epsilon. R, which is the set of r.sup.s links that
support the new service s.
[0344] Each resource link Lj is marked or colored a with
utility-cost tag. Initially the utility-cost tag will have been set
by the provider as the minimum expected utility the provider wishes
to obtain from any customer use. However, when a customer issues a
request to buy, the utility cost of those resources that support
the service are updated, which means that if the resource utility
is higher, the customer is required to pay more for using these
resources.
[0345] Then, for every resource that is part of the service there
are three calculations to be made:
[0346] 1. Find the total resource capacity for trade.
[0347] 2. Find the total ordered resource.
[0348] 3. Calculate the required resource expected utility.
[0349] The required expected utility to be offered to the broker is
the sum of all expected utilities of resources being used.
[0350] The uniqueness of the proposed algorithm is that the
required expected utility is calculated based on the availability
and usage of the resource. If the resource is free at a specific
moment, then its required utility is the minimum utility. However,
if the resource was ordered by some services (i.e. by some
customers), then its required utility increases.
[0351] Let u be the total ordered resource Lj for a specific
moment; and a--be the total resource Lj that was allocated for
trading for the same specific moment. Then, u can be considered as
the total ordered resource, before the current request, or after
the current request (e.g. u=u.sup.-1+q) or any number between them
(e.g. u=u.sup.-1+q/.beta.; while for .beta.=2 it is the average
between the `previous` and the `after`. The parameter u can be set
based on learned information regarding the buying probability of
each ASK.
[0352] Let us define a trade floor for each resource Lj that deals
with allocation of capacity for duration D at time Ta (which we
call the balance point). The amount of resource available in each
of these trade floors may be calculated every time there is a
request for a price.
[0353] Let D=(d.sub.1,d.sub.2, . . . d.sub.N.sub.D) be the vector
of N.sub.D different durations that the provider define to be sold
as different products. Lets A .function. ( D , T a ) = ( a 1 T a ,
a 2 T a , .times. .times. a T D N D ) ##EQU47## be the vector of
possible allocations of resources to be available for trade in
those trade floors that deal with N.sub.D products that should be
allocated at Ta for different possible durations D.
[0354] We may define two types of products--`fixed allocation time`
and `flexible allocation time`. Products with a fixed allocation
time can be scheduled for predefined times, for example a 24 hour
product can be allocated from 0:00 to 24:00, or an 8 hour product
can be scheduled to 8:00, 16:00 or 24:00. Products with flexible
allocation times can be scheduled for any chosen time (given the
minimum step size). For example, a 24 hour product can be allocated
to any hour, for example to the next 24 hours (i.e. 6:00 to 6:00,
etc').
[0355] Lemma 1: For given durations D, L flexible allocation
products from total of N.sub.D durations and total resource
capacity Q, the allocation vector A(D,Ta) must support: Q = i = 1 L
.times. j = 0 d i .times. a i T a - d i + j + i = L N D .times. a i
T a - d i [ 7 ] ##EQU48##
[0356] Proof: At any specific moment Ta the provider needs to
reserve enough capacity to support all products that are to be sold
before the moment Ta and therefore are going to make use of
resources at that moment. The first part of the equation deals with
L flexible allocation products, while up to moment Ta there can be
different allocations that were reserved at Ta-d.sub.i,
Ta-d.sub.i+1,Ta-d.sub.i+2, . . . ,Ta moments (total d.sub.i
possible times). The second part of the equation deals with
N.sub.D-L fix allocation products that can be allocated at
different moments Ta-d.sub.i.
[0357] The question is how to find an allocation vector A
.function. ( D , T a ) = ( a 1 T a , a 2 T a , .times. .times. a T
D N D ) ##EQU49## that reflects the market demand for a specific
resource at time Ta. To solve this problem and find such an
allocation vector we use an iterative mechanism that starts with
best effort guessing and adjusts the vector based on feedback.
[0358] We assume that the provider guesses an allocation vector A 0
.function. ( D , T a ) = ( a T a 1 0 , a T a 2 0 , .times. .times.
a T D N D 0 ) ##EQU50## that satisfies Eq. 7.
[0359] Now we define U(D,T.sub.a)=(u.sub.1,u.sub.2, . . .
u.sub.N.sub.D) as the vector of total ordered resources, to be
allocated at t=Ta, for different durations D=(d.sub.1,d.sub.2, . .
. d.sub.N.sub.D). We assume that we have stored a vector of total
ordered resources within a database, for every resource R, every
duration D and every possible allocation time Ta.
[0360] Now we define the nominal point EU*, where the average trade
floor activity is to be handled. Then at the nominal point, the
(.sup.u.sup.i/.sub.a.sub.i)* ratio is given by: ( u i / a i ) * = 1
EU 2 .times. ln .function. ( EU * - EU 0 EU 1 ) [ 8 ] ##EQU51##
[0361] Since u.sub.i represents actual orders collected at a
specific trade floor, it reflects the market behavior regarding
specific product duration at a specific time. It is well known that
market behavior has oscillations over the periods of a day (24
hours), over the week (7 days) and sometimes even over the month
(31 days). Therefore, it is possible to use the following feedback
mechanism, to adjust the allocation vector to be closer to the
normal pricing point:
[0362] The following feedback mechanism can adjust the allocation
between the trade floors: for every duration d.sub.i the allocation
a.sub.i is adjusted for Ta=same hour on the same day as follows: if
.times. .times. u i / a i < ( u i / a i ) * .times. .times. then
.times. .times. a i + = k 1 .times. a i .times. .times. k 1 < 1
.times. .times. if .times. .times. u i / a i > ( u i / a i ) *
.times. .times. then .times. .times. a i + = k 2 .times. a i
.times. .times. k 2 > 1 [ 9 ] ##EQU52##
[0363] In the first case the actual orders are smaller then the
normal point, therefore it is reasonable to decrease the available
resource for trade at similar times.
[0364] In the second case the actual orders are higher then the
normal point, therefore it is reasonable to increase the available
resource for trade at similar times.
[0365] Again, after finding the new allocation vector, we need to
normalize it and solve the condition equation for the correct
allocation.
[0366] Multi Domain Solution
[0367] Since service deployment may require more then one carrier
being involved and time constraints (i.e. establishing new physical
links), it is necessary to expand the bidding and asking
procedures. Suppose player i wants to create a new link that
involves purchasing using a few carriers, then he needs to define a
plan PL k i ##EQU53## where k=(1 . . . K) represents plan k out of
K possible plans the carrier may have. A plan PL k i ##EQU54## is a
vector of all alternative chains of tasks
T.sub.j.sup.i=(c.sub.j.sup.i,t.sub.s,t.sub.E), where j is a seller
index that allocates capacity c.sub.j.sup.i to support player i's
service traffic at a time period starting at t.sub.s and ending at
t.sub.E. Reference is now made to FIG. 13, which is a simplified
diagram showing typical network relationships for a carrier. FIG.
13 shows a number of players 1 . . . 4, and the network has two
nodes A and B for present consideration. Let us say that player 1
wishes to build a route between ports A and B. He has two
alternatives 1.fwdarw.2.fwdarw.4 and 1.fwdarw.3.fwdarw.4. Thus, we
can write the plan vector as follow: PL k : A .fwdarw. B i = 1 = [
T 2 1 T 4 1 T 3 1 T 4 1 ] ( 1 ) ##EQU55##
[0368] According to the above definition, player 1 may have
relationships with all players, even with those he has no direct
connection (i.e. player 4 in the example). This definition enables
wider possibilities for inter-carrier relationship, allowing a
carrier to have self-control and quality assurance. In addition it
expands the market liquidity, since in a world where all players
can buy and set their own direct links through a carrier they are
not connected with, the ability to know and manage all players
relationships becomes extremely complex to the point where a seller
may prefer to have a known or published floor price for all
potential buyers.
[0369] As is clear from the example, it is possible to have a
situation where player 1 buys capacity c.sub.4.sup.1 from player 4,
while entering from different edges. If all prices were elastic
according to destinations in a carrier's network, then each route
may in practice amount to the same c.sub.4.sup.1. However, to make
it more general, it is preferable to include the attributes of each
capacity c.sub.4.sup.1(2,B,BR,QoS) and c.sub.4.sup.1(3,B,BR,QoS),
which means there are two T.sub.4.sup.1 tasks in the bidding
process. That is to say, even if the prices on the two routes are
the same, other attributes such as quality of service may not
be.
[0370] Eqn. (1) above may now be written as: PL k : A .fwdarw. B i
= 1 = [ T 2 1 .function. ( 1 , 4 , BR , QoS , t s , t e ) T 4 1
.function. ( 2 , 4 , BR , QoS , t s , t e ) T 3 1 .function. ( 1 ,
4 , BR , QoS , t s , t e ) T 4 1 .function. ( 3 , 4 , BR , QoS , t
s , t e ) ] ( 2 ) ##EQU56##
[0371] Beside the capacity/resources market, there is the
telecommunication services market. A capacity buyer is a services
seller and vice versa. Therefore, it is always possible to say that
both players are sellers and buyers, while market forces lead them
to match.
[0372] The question for the buyer is through which carrier to route
traffic. It should be borne in mind that the buyer actually is also
a seller--albeit a traffic seller. Therefore the buyer's question
may be modified to find the path that will maximize their expected
utility. Such a path may be found by a searching programming. If we
use an annealing (Gini technique)--or stochastic--technique then we
can reduce the value changes and then find a semi-static solution.
For such a process it is preferable to consider a different filter
for each resource, since each resource has a different dynamic.
[0373] Reference is now made to FIG. 14, which shows a series of
domains having inter-domain brokers arranged therebetween.
[0374] A further reason why the possible routes around the network
is of interest is to avoid loops. As discussed above, loop
avoidance is needed to prevent the same offer arriving several
times at the same broker or even entering infinite loops, thus
leading to confusion and network overload. A protocol is thus
provided, specifically aimed at Inter-network brokers, to avoid
such loops. The protocol is based on being able to identify
specific offers and thus to be able to delete duplicate copies of
the same bid. Identification of offers may, in the current
embodiments, be via identification of the corresponding provider,
or simply by applying a number to the offer, or a combination
thereof.
[0375] It is noted that a loop avoidance mechanism, whilst a part
of inter-domain trading, may also be provided as part of
intra-domain trading, for example in domains in which there are
multiple providers as well as multiple consumers, and the domain is
set up such that loop formation is possible.
[0376] A preferred embodiment of the loop avoidance mechanism
requires that each provider is assigned a provider ID. The ID is
preferably unique at least to the domain. The combination of the ID
with a domain ID is preferably unique for all associated
domains.
[0377] In general, within a domain, an offer is generated by a
provider's broker following a request from the provider, and is
broadcast to each other broker in the domain. The offer is received
by each other broker and processed, and a reply is sent to the
originating broker. However, the inter domain broker works
differently. If it receives an offer from within its domain, it
broadcasts it to its twin inter domain broker, that is the inter
domain broker of the other domain with which it works. If it
receives an offer from outside its domain, it broadcasts the offer
to each broker within its domain. An offer originating at A may
reach B by several routes including direct routes and loops.
[0378] A first preferred embodiment operates at the level of the
inter-domain brokers. Each provider adds its ID to any passing
offer, so that the offer builds up a chain of Ids that identify the
route it has taken. The broker simply avoids passing on any offer
that already includes an ID number of the domain to which it is
forwarding the offer.
[0379] The above embodiment avoids looping of offers although it
will be noted that it does not prevent forwarding of offers that
have followed entirely different routes. A further disadvantage of
the above embodiment is that the provider ID numbers are made
available to different domains. Information about commercial
relationships could thus be compromised. Thus in a second preferred
embodiment, the provider ID is replaced with a request number. Only
the originating domain knows the relationship between the request
number and the provider. The request number is preferably provided
at the domain level so that there is a risk that two domains could
inadvertently assign the same number. Such a risk may be minimized
by making the numbers large so as to reduce the probability of
identical numbers being selected. The broker simply checks the
request number to ensure that it is not a number he has already
passed on.
[0380] In a further embodiment the request ID may be supplied by an
agreed party or 3.sup.rd party server.
[0381] In the following, a listing of protocol commands is given
for a trading protocol that allows bids and offers to be defined
and supports inter-domain trading.
Main Protocol Commands
[0382] The inter-domain protocol as given below is based on TCP/IP,
but may equally well operate with other like protocols that provide
similar reliable interfaces. The inter-domain protocol includes
three commands sets as follows:
[0383] 1. Allocation commands set,
[0384] 2. Miscellaneous commands set, and
[0385] 3. Accounting commands set
In general each and every command is followed by an ACK
message--OK, ERR and the like, and may have different types.
Allocation Commands Set
[0386] The following two commands can be generated by the customer,
asking the provider to buy a product, or to sell a product:
TABLE-US-00001 Request_to_buy {Issuer ID (optional) Issuer ID list
(optional) Request ID number (mandatory) Request IDs list
(mandatory) Time of issuing (mandatory) Last time to receive BID =
0 - open for ever = t minutes/hours before start time of allocation
= Specific time Media type = IP bandwidth (mandatory) = ATM VC =
... Capacity (for media type ATM VC it includes four attributes:
ingress point, (mandatory) egress point , (mandatory) Bit Rate, = 0
- open and the cost must be specified = #Number - the minimum
required bit rate QoS parameters (optional) ) Start time of
allocation = 0 - as soon as possible, i.e. now. = specific time
(mandatory) End time of allocation = the sum of Start time and
Duration = specific time Duration = 0 - the minimum duration
available (i.e. for the maximum rate available) = end time minus
start time = lower then the difference between the end and the
start times - to find the best deal between the times for the
specified duration. (mandatory) Continue buy = 0 - only once =
Repetition time (every hour/day/week/...) (mandatory) Price (cost,
= 0 - open, = #Number - the maximum cost the issuer willing to pay.
(mandatory) Risk, (optional) Fee = Percent = Constant = min/max
between percents and constant (optional) ) } {Issuer ID (optional)
Issuer ID list (optional) Request ID number (mandatory) Request IDs
list (mandatory) Time of issuing (mandatory) Last time to receive
BID = 0 - open for ever = t minutes/hours before start time of
allocation = Specific time Media type = IP bandwidth (mandatory) =
ATM VC = ... Capacity (for media type ATM VC it includes four
attributes: ingress point, (mandatory) egress point , (mandatory)
Bit Rate, = #Number - the maximum bit rate to be provided QoS
parameters (optional) ) Start time of allocation = 0 - as soon as
possible, i.e. now. = specific time (mandatory) End time of
allocation = the sum of Start time and Duration = specific time
Duration = end time minus start time = lower then the difference
between the end and the start times - to find the best deal between
the times for the specified duration. (mandatory) Continue sell = 0
- only once = Repetition time (every hour/day/ week/...)
(mandatory) Price (cost, = 0 - open, = #Number - the minimum cost
the issuer willing to receive for the service he sells. (mandatory)
Risk, (optional) Fee = Percent = Constant = min/max between
percents and constant (optional) ) }
[0387] The following two commands can be generated by the provider,
answering the requester with a proposal to buy or to sell:
TABLE-US-00002 {Bidder ID (optional) Request ID number (mandatory)
Time of Bidding (mandatory) Bid expiration = Open = t minutes that
the bidder reserves the offer and wait for the requestor for an
answer. Capacity (for media type ATM VC it includes four
attributes: ingress point, (mandatory) egress point , (mandatory)
Bit Rate, (mandatory) QoS parameters (mandatory/optional) ) Start
time of allocation = 0 now. = specific time (mandatory) End time of
allocation = specific time (mandatory) Duration = end time minus
start time (optional) Price (cost, (mandatory) Risk, (optional) ) }
{Bidder ID (optional) Request ID number (mandatory) Time of Bidding
(mandatory) Bid expiration = Open = t minutes that the bidder
reserves the offer and wait for the requestor for an answer.
Capacity (for media type ATM VC it includes four attributes:
ingress point, (mandatory) egress point , (mandatory) Bit Rate,
(mandatory) QoS parameters (mandatory/optional) ) Start time of
allocation = 0 now. = specific time (mandatory) End time of
allocation = specific time (mandatory) Duration = end time minus
start time (optional) Price (cost, (mandatory) Risk, (optional) )
}
[0388] The following two commands can be generated by the customer,
as a final answer who won or lost auction: TABLE-US-00003 {Issuer
ID (optional) Request ID number (mandatory) Capacity (for media
type ATM VC it includes four attributes: ingress point, (optional)
egress point , (optional) Bit Rate, (optional) QoS parameters
(optional) ) Start time of allocation = 0 now. = specific time
(optional) End time of allocation = specific time (optional)
Duration = end time minus start time (optional) Price (cost,
(optional) Risk, (optional) ) } {Issuer ID (optional) Request ID
number (mandatory) Bid ID number (optional) }
[0389] The following command can be generated by a player that
wants to buy or to sell an option. TABLE-US-00004 {Issuer ID
(optional) Issuer ID list (optional) Request ID number (mandatory)
Request IDs list (mandatory) Time of issuing (mandatory) Option
time of issuing (mandatory) Request type = to buy an option = to
sell an option (mandatory) Option expiration date (mandatory)
Option type = PUT or CALL (mandatory) Last time to receive BID = 0
- open up to the expiration date = t minutes/hours before
expiration date = Specific time Media type = IP bandwidth
(mandatory) = ATM VC = ... Capacity (for media type ATM VC it
includes four attributes: ingress point, (mandatory) egress point ,
(mandatory) Bit Rate, = #Number (mandatory) QoS parameters
(optional) ) Start time of allocation = 0 - at the expiration date.
= Other specific time (mandatory) End time of allocation = the sum
of Start time and Duration = specific time (mandatory) Duration =
end time minus start time = lower then the difference between the
end and the start times - to enable flexible option of finding the
best deal at given time. (mandatory) Continue buy = 0 - only once =
Repetition time (every hour/day/ week/...) (mandatory) Price
(Option cost (mandatory) Media cost, (mandatory) Risk, (optional)
Fee = Percent = Constant = min/max between percents and constant
(optional) ) }
[0390] The following command can be generated by a player that
wants to response to a request for buying or selling an option.
TABLE-US-00005 {Bidder ID (optional) Request ID number (mandatory)
Bid type = to buy an option = to sell an option (optional) Time of
Bidding (mandatory) Option time of issuing (optional) Bid
expiration = Open = t minutes after bidding time Option expiration
date (optional) Option type = PUT or CALL (optional) Capacity (for
media type ATM VC it includes four attributes: ingress point,
(mandatory) egress point , (mandatory) Bit Rate, = #Number
(mandatory) QoS parameters (optional) ) Start time of allocation =
0 - at the expiration date. = Other specific time (optional) End
time of allocation = the sum of Start time and Duration = specific
time (optional) Duration = end time minus start time = lower then
the difference between the end and the start times - to enable
flexible option of finding the best deal at given time. (optional)
Continue buy = 0 - only once = Repetition time (every hour/day
/week/...) (mandatory) Price (Option cost (mandatory) Media cost,
(optional) Risk, (optional) Fee = Percent = Constant = min/max
between percents and constant (optional) ) }
[0391] The following two commands can be generated by the option
seller that answer who won or lost the auction to buy/sell the
option. TABLE-US-00006 {Issuer ID (optional) Request ID number
(mandatory) Bid ID number (optional) Bid type = to buy an option =
to sell an option (optional) Option expiration date (optional)
Option type = PUT or CALL (optional) Capacity (for media type ATM
VC it includes four attributes: ingress point, (optional) egress
point , (optional) Bit Rate, (optional) QoS parameters (optional) )
Start time of allocation = 0 now. = specific time (optional) End
time of allocation = specific time (optional) Duration = end time
minus start time (optional) Price (cost, (mandatory) Risk,
(optional) ) } {Issuer ID (optional) Request ID number (mandatory)
Bid ID number (optional) }
[0392] The following command can be generated by the last option
holder to signal the relevant provider to supply him with the
capacity allocated in the option at the expiration date:
TABLE-US-00007 {Issuer ID (optional) Bidder ID (optional) Request
ID number (mandatory) }
Miscellaneous commands set The following four commands are part of
the basic interaction between the brokers, and allow new brokers to
be setup, old brokers to be deleted, hereinafter "tear down", and
allowing working or updating of existing brokers:
[0393] During setup of a new broker or customer agent the newcomer
identifies itself internally and externally, thus: TABLE-US-00008
{Broker ID number Address (IP) Provider ID number Served customer
ID Setup time Other important information }
[0394] For tear-down of a broker or a customer agent it must notify
all brokers that are in contact with it, thus: TABLE-US-00009
{Broker ID number Address (IP) Provider ID number Served customer
ID Tear down time Reason for tearing down Replacer broker Other
important information }
[0395] Every x time period each broker sends a message that he is
alive TABLE-US-00010 {Broker ID number Address (IP) Provider ID
number Served customer ID Other important information }
[0396] If some of the configuration information was changed the
broker need to update all brokers that are in contact with him,
thus TABLE-US-00011 {Broker ID number Address (IP) New information
that was updated }
Accounting Commands Set
[0397] The accounting commands set supports a variety of
information parameters such as total BIDs received, total costs,
total purchased capacity, etc.
[0398] There are two commands designed to be sufficiently flexible
to cover the different parameters: [0399] {specify the type of
required information} [0400] {provide the required information in
ASCII format, or any other format}
[0401] The previously described embodiments of the present
invention operate to provide fixed amounts of a resource, such as
bandwidth on a network, at a variable price, in an "auction"
format. According to another optional but preferred embodiment of
the present invention, there is provided the ability to purchase a
variable amount of a resource but at a fixed price, in a "reverse
auction" format. It should be noted that the previously described
methods and system for performing the "auction" format of the
present invention are also operable for the "reverse auction"
format, but with the following adaptations.
[0402] For example, the user may optionally state only a fixed
price to be paid, without any further information, preferably with
a date or time period on which the resource is to be received.
Preferably, the user provides some type of qualification to the
minimum amount of the resource to be received; for example, the
user may optionally state that a minimum 30 amount of bandwidth is
required, and/or other minimum quality parameter(s) which are to be
met, such as minimum delay and loss for example, for networks such
as ATM or IP networks for example. In cases where the minimum
amount requested cannot be met, the user may optionally receive
notification such as a `busy tone`, which means that the service is
not available at that moment, based on the pre-defined prices. In
such a case, the user may optionally request the service at another
time, or alternatively may request (from the resource platform for
example) the best quality that is obtainable for the previously
determined price.
[0403] The user may only know at the time of use of the bandwidth
how much is to be provided, other than the minimum (if any), as the
total amount of bandwidth may depend upon availability at the time
of use. This type of "reverse auction" may optionally be used for
applications where a minimum amount of bandwidth is required, but
additional bandwidth enhances quality, such as a video conference
application for example.
[0404] The "reverse auction" mechanism may optionally be used as a
tool for controlling the amount of money spent on services, for
example for large organizations which want to limit the budget used
by their employees. This tool prevents employees from spending
beyond their budget by purchasing excessively expensive services.
Since it is possible that employees may be less sensitive to
expenses made on behalf of their organization, this mechanism
motivates employees to search for better service, for a given
price, in order to increase their own satisfaction with the
service. In addition, this mechanism shapes demand for the most
efficient use of services and resources.
[0405] The previously described resource platform may optionally be
implemented as follows. As previously described, the platform
preferably includes an agent-based interaction mechanism for
allowing the resource provider and the users to indicate their
requirements (such as a minimum amount of a resource for example),
and to translate the requirements into offers and bids, and a
pricing engine for ascertaining a resource allocation price for the
offers and bids. However, for this implementation, the pricing
engine is preferably an availability engine, since the price is
fixed; the engine therefore determines the amount of bandwidth or
other resource to be provided, rather than the price. The pricing
engine preferably uses a learning mechanism for learning demand
behavior of individual users so that it can translate their
requirements into a suitable amount of bandwidth rather than price,
which is fair to them and fair to the provider. Thus, the
time-consuming, and in the case of duration-dependent products,
product destroying, bargaining stage of resource allocation is
avoided.
[0406] The platform preferably allows for parceling of the
resources into products of given time duration and quality of
service and a risk factor may be introduced into the price of the
product according to the duration. For this implementation, the
effect of the risk factor is to determine the amount of the
resource to be provided, such as the amount of bandwidth to be
provided. Trading of resources may be on demand but future and
option trading of the resources are also supported.
[0407] According to another optional implementation of this
embodiment of the present invention, the resource provider may
preferably provide different pricing for bandwidth which is ordered
in advance and/or at non-peak hours. For this implementation, the
user again preferably specifies a minimum quality according to one
or more parameters, such as a minimum amount of bandwidth. The
resource provider may then optionally provide additional bandwidth
for the fixed price, optionally according to how far in advance the
bandwidth is ordered and/or the time at which the bandwidth is to
be provided.
[0408] It is appreciated that certain features of the invention,
which are, for clarity, described in the context of separate
embodiments, may also be provided in combination in a single
embodiment. Conversely, various features of the invention which
are, for brevity, described in the context of a single embodiment,
may also be provided separately or in any suitable
subcombination.
[0409] It will be appreciated by persons skilled in the art that
the present invention is not limited to what has been particularly
shown and described hereinabove. Rather the scope of the present
invention is defined by the appended claims and includes both
combinations and subcombinations of the various features described
hereinabove as well as variations and modifications thereof which
would occur to persons skilled in the art upon reading the
foregoing description.
* * * * *