U.S. patent application number 11/266352 was filed with the patent office on 2006-03-30 for method for, and a topology aware resource manager in an ip-telephony system.
This patent application is currently assigned to OPERAX AB. Invention is credited to Anders Larsson, Joakim Norrgard, Olov Schelen, Jim Sundqvist.
Application Number | 20060069779 11/266352 |
Document ID | / |
Family ID | 22861689 |
Filed Date | 2006-03-30 |
United States Patent
Application |
20060069779 |
Kind Code |
A1 |
Sundqvist; Jim ; et
al. |
March 30, 2006 |
Method for, and a topology aware resource manager in an
IP-telephony system
Abstract
A method and arrangement in a communications network. The object
is to provide a way of handling recourse management issues and
admission control within an IP telephony system. The object is
achieved by a topology aware resource manager collecting routing
information concerning the IP network, obtaining resource
information concerning resources within the IP network, creating a
resource map by combing the routing information and resource
information, and performing recourse management issues and
admission control within the system by the resource map and by
interacting with a gatekeeper.
Inventors: |
Sundqvist; Jim; (Lulea,
SE) ; Larsson; Anders; (Lulea, SE) ; Norrgard;
Joakim; (Lulea, SE) ; Schelen; Olov;
(Norrfjarden, SE) |
Correspondence
Address: |
YOUNG & THOMPSON
745 SOUTH 23RD STREET
2ND FLOOR
ARLINGTON
VA
22202
US
|
Assignee: |
OPERAX AB
LULEA
SE
|
Family ID: |
22861689 |
Appl. No.: |
11/266352 |
Filed: |
November 4, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10363628 |
Jun 5, 2003 |
|
|
|
PCT/SE01/01876 |
Sep 3, 2001 |
|
|
|
11266352 |
Nov 4, 2005 |
|
|
|
60229544 |
Sep 5, 2000 |
|
|
|
Current U.S.
Class: |
709/225 |
Current CPC
Class: |
H04M 7/006 20130101;
H04L 45/00 20130101; H04L 41/12 20130101 |
Class at
Publication: |
709/225 |
International
Class: |
G06F 15/173 20060101
G06F015/173 |
Claims
1. A topology aware resource manager (RM) within an Internet
Protocol IP telephony system (400) for transmission of multimedia
over an IP network, the system comprising a gatekeeper (Gk),
wherein the resource manager (RM) comprises: means for collecting
routing information concerning the IP network; means for obtaining
resource information concerning resources within the IP network;
means for creating a resource map by means of combing said routing
information and resource information; characterised in that the
resource manager (RM) comprises: means for via the gatekeeper (Gk)
performing path sensitive resource management issues and admission
control within the system (400) by means of said resource map and
by interacting with the gatekeeper (Gk), wherein the IP network is
routed using a distance vector protocol, or static routing, the
resource manager (RM) comprises means for using measurements such
as trace route and/or the Simple Network Management Protocol (SNMP)
auto discovery to retrieve routing information of the IP
network.
2. The resource manager (RM) according to claim 1, wherein it
comprises means for obtaining resource information from call set-up
requests from the gatekeeper (Gk).
3. The resource manager (RM) according to claim 1, wherein the IP
system is routed using link-state routing protocol, the resource
manager (RM) comprises means for participating in the routing and
acting as a router within the system (400) without advertising any
routes of its own, to retrieve routing information of the IP
network.
4. The resource manager (RM) according to claim 1, wherein the IP
network is routed using a distance vector protocol, or static
routing, the resource manager (RM) comprises means for using
measurements by Simple Network Management Protocol (SNMP) auto
discovery to retrieve routing information of the IP network.
5. The resource manager (RM) according to claim 1, wherein it
comprises means for using the resource map for evaluating what
network path an initiated call between a source endpoint and a
destination endpoint within the system (400) will use.
6. The resource manager (RM) according to claim 5, wherein it
comprises means for, calculating, for each link along that path, if
there are sufficient resources to admit the call.
7. The resource manager (RM) according to claim 6, wherein said
calculation is reported to the gatekeeper (Gk).
8. The resource manager (RM) according to claim 1, wherein it
comprises means for updating the resource map by monitoring
on-going calls in the IP telephony system and recalculating the
resource usage per link whenever any change occurs within the
system (400).
9. The resource manager (RM) according to claim 8, wherein the
resource map shows that the resources are too limited to be able to
fulfil all on-going calls, the resource manager (RM) comprises
means for prioritising which calls that should be kept and which to
terminate.
10. The resource manager (RM) according to claim 8, wherein the
resource map shows that the resources are too limited to be able to
fulfil all on-going calls, the resource manager (RM) comprises
means for reporting this to the gatekeeper (Gk), making it possible
for the gatekeeper (Gk) to prioritise which calls that should be
kept and which to terminate.
11. The resource manager (RM) according to claim 1, wherein it is
used in a multi part conference scenario involving more than two
end-points within the system (500) which system further comprises a
multi-point controller (MC), the resource manager (RM) comprising
means for interacting with the multi-point controller (MC) for
performing said resource management issues and admission
control.
12. The resource manager (RM) according to claim 11, wherein said
interaction with the multi-point controller (MC) is performed via
the gatekeeper (Gk).
13. The resource manager (RM) according to claim 11, wherein
resources are available, but not enough to fulfil the amount of
resources requested in a call initiation, the resource manager (RM)
comprises means to reject the call with conditions, i.e. by
offering said available resources to the initiator of the call.
14. An Internet Protocol (IP) telephony system comprising a
gatekeeper (Gk), one or more routers (R) and multiple a plurality
of end-points characterised in that the system further comprises a
topology aware resource manger (RM) according to claim 1.
15. A method for handling performing resource management issues and
admission control within an Internet Protocol IP telephony system
(400) adapted for transmission of multimedia over an IP network,
the system (400) comprising a topology aware resource manager (RM);
characterised in that the method comprises the following steps to
be performed by the resource manager (RM): collecting routing
information concerning the IP network; obtaining resource
information concerning resources within the IP network; creating a
resource map by means of combing said routing information and
resource information; via the gatekeeper (Gk) performing
path-sensitive resource management issues and admission control
within the system (400) by means of said resource map and by
interacting with a gatekeeper (Gk), wherein the IP network is
routed using a distance vector protocol, the method comprising the
further step of: the resource manager (RM) using measurements such
as trace route and/or the Simple Network Management Protocol (SNMP)
auto discovery to retrieve routing information of the IP
network.
16. The method according to claim 15, comprising the further step
of the resource manager (RM) obtaining resource information from
call set-up requests from the gatekeeper (Gk).
17. The method according to claim 15, wherein the IP system is
routed using link-state routing protocol, the method comprising the
further step of: the resource manager (RM) participating in the
routing and acting as a router within the system (400) without
advertising any routes of its own, to retrieve routing information
of the IP network.
18. The method according to claim 15, wherein the IP network is
routed using a distance vector protocol, the method comprising the
further step of: the resource manager (RM) using measurements by
Simple Network Management Protocol (SNMP) auto discovery to
retrieve routing information of the IP network.
19. The method according to claim 15, comprising the further step
of: using the resource map for evaluating what network path an
initiated call between a source endpoint and a destination endpoint
within the system (400) will use.
20. The method according to claim 15, comprising the further step
of: calculating, for each link along that path, if there are
sufficient resources to admit the call.
21. The method according to claim 20, comprising the further step
of: reporting said calculation to the gatekeeper (Gk).
22. The method according to claim 15, comprising the further step
of: the resource manager (RM) updating the resource map by
monitoring on-going calls in the IP telephony system and
recalculating the resource usage per link whenever any change
occurs within the system (400).
23. The method according to claim 22, wherein the resource map
shows that the resources are too limited to be able to fulfil all
on-going calls, the method comprising the further step of: the
resource manager (RM) prioritising which calls that should be kept
and which to terminate.
24. The method according to claim 22, wherein the resource map
shows that the resources are too limited to be able to fulfil all
on-going calls, the method comprising the further step of: the
resource manager (RM) reporting this to the gatekeeper (Gk), making
it possible for the gatekeeper (Gk) to prioritise which calls that
should be kept and which to terminate.
25. The method according to claim 15, wherein it is used in a multi
part conference scenario involving more than two end-points within
the system (500), which system further comprises a multi-point
controller (MC), the method comprising the further step of: the
resource manager (RM) interacting with the multi-point controller
(MC) for performing said resource management issues and admission
control.
26. The method according to claim 25, wherein said interaction with
the multi-point controller (MC) is performed via the gatekeeper
(Gk).
27. The method according to claim 25, wherein resources are
available, but not enough to fulfil the amount of resources
requested in a call initiation, the method comprising the further
step of: the resource manager (RM) rejecting the call with
conditions, i.e. by offering said available resources to the
initiator of the call.
28. A computer program product directly loadable into the internal
memory of a processing means within a topology aware resource
manager (RM) and/or a gatekeeper (Gk) within an IP telephony system
(400) system, comprising the software code means for performing the
steps of claim 15.
29. A computer program product stored on computer usable medium,
comprising readable program for causing a processing means in
topology aware resource manager (RM) and/or a gatekeeper (Gk)
within an IP telephony system (400) system, to control an execution
of the steps of claim 15.
Description
[0001] The present invention relates to a method and arrangement in
a communications network in accordance with the preambles of the
independent claims. More specifically it relates to IP telephony
recourse management issues and admission control within an IP
telephony system.
BACKGROUND OF THE INVENTION
[0002] Telephony is one of the most important inventions in
mankind. Since its birth Mar. 10, 1876, installing copper wires to
each and everyone that needed communication capabilities has spread
the technology worldwide. By coupling copper wires together between
caller and called, a connection between these was achieved and they
could eventually communicate with each other through their circuit.
This kind of technology has become known as circuit-switched
telephony. Anyone familiar with classical telephony know that there
has been a great evolution within this circuit-switched telephony
with, for instance, the AXE platform the Ericsson Corporation
developed as their switching solutions. Knowledge about statistical
multiplexing of calls within the networks has made it possible to
build networks with worldwide coverage to limited costs.
[0003] During the last decade, the classical circuit-switched
telephony service has met a competitor in the more cost efficient
packet-switched telephony built upon the Internet protocol suite
Transport Control Protocol/Internet Protocol (TCP)/(IP). This
telephony is usually referred to as IP telephony, which currently
is being standardized and frequently installed instead of the old
circuit-switched telephony.
[0004] The packet-switch IP telephony networks are commonly touted
using one of the well-known IP touting protocols such as OSPF (Moy
J., OSPF Version 2, IETF, RFC2328), IS-IS (Oran D., OSI IS-IS
Intra-domain Routing Protocol, IETF, RFC1142) or RIP (Malkin G.,
RIP Version 2, IETF, RFC2453). These protocols can be classified
either as being link-state or distance vector protocols based on
the algorithms they use for route computation and distribution of
routing information. All routers running a link state protocol
within a domain have a complete view of the network, knowing all
the networks and routers within the domain. A distance vector
router knows only the routers and networks in its immediate
surrounding (directly connected).
[0005] Most commercial IP telephony systems follow the
International Telecommunication Union-Telephony (ITU-T)
Recommendation H.323. This recommendation was early adopted by
major IP telephony vendors in their systems solutions. In FIG. 1,
an overview of the major components in an H.323 system is
shown.
[0006] These major components are terminals T, gateways G, and
gatekeepers Gk. The three first components are referred to as
endpoints of the H.323 system since these can initiate or terminate
media streams. The gatekeeper is the manager of the H.323 system.
The managing domain is referred to as a zone. There is one, and
only one, gatekeeper available in each zone.
Terminals
[0007] Terminals T are endpoints that provide real-time two-way
communications, i.e. it is possible to talk and listen to another
H.323 terminal T or another telecommunications system via a
gateway. It can also participate in a multipoint conference through
the MCU, which will be introduced below. An H.323 terminal T must
support the voice service. Besides the voice service, the terminal
T can also provide video and data services, but these are optional.
To be able to negotiate channel usage and do capability exchange
between end-points, the terminal T must also support H.245. Other
required components are call setup and signalling via Q.931,
registration/admission/status (RAS) for gatekeeper communication,
and RTP/RTCP for transportation of real-time services, e.g. voice
and video.
[0008] Besides these required components, the terminal T could also
have MCU capabilities.
Gateway
[0009] A gateway G is an interface between an H.323 system and
another telecommunication systems, e.g. PSTN. The gateway G is
optional and is only required when an endpoint communicates with
other terminal types 102, e.g. ISDN, PSTN etc. The gateway G
handles both the call control and the call transportation
translation between the H.323 system and the non-H.323 system.
Multipoint Control Units
[0010] The multipoint control units (MCU) support conferences
between three or mote endpoints. The MCU comprises a mandatory
multipoint controller (MC) and optionally one or more multipoint
processors (MP). The MC can be co-located with another end-point,
e.g. in a terminal. The MC handles negotiations between terminals
during audio and video capability exchange. The MC also determines
if any of the related media streams should be distributed with
multicast. In case mixing of media streams are required, the MP
handles this. As depicted in FIG. 2, Multipoint communication can
be made either in a centralised or a decentralised manner. In
centralised multipoint conferencing, all communication between
endpoints E is made via the MC. In the MC, the media streams are
mixed together and distributed to involved endpoints E. In
decentralised multipoint conferencing, the MC handles the
negotiations while the endpoints E them self distributes the media
streams. This distribution can be made with the resource efficient
technology multicast. A mesh of unicast media distribution can also
be used. Besides the centralised and the decentralised distribution
method, hybrids between these are possible.
Gatekeeper
[0011] The gatekeeper Gk is the most important component of an
H.323 enabled network. It performs two important call control
functions; address translation and bandwidth management. Address
translation means that the gatekeeper Gk translates from aliases
for terminals and gateways to IP addresses. The bandwidth
management implementation is vendor specific. A commonly used
method is to specify a threshold for the number of simultaneous
calls that can be made within the zone the gatekeeper Gk manages.
Other methods might exist but these are in that case vendor
specific. Calls can be made directly between endpoints or via the
gatekeeper Gk. The latter is referred to as gatekeeper-routed
calls.
[0012] Even though H.323 primarily was developed for non-guaranteed
quality of service networks, the recommendation has been expanded
to cover Quality of Service (QoS) issues as well. For instance, QoS
Support for H.323 using RSVP is discussed in appendix II of ITU-T
Recommendation H.323 version 2, Packet-based multimedia
communication systems, Geneva, 1997.
[0013] Lack of topology awareness and path sensitive admission
control is the most important drawback of current implementations
of H.323 gatekeepers. In FIG. 3, a topology for an H.323 enabled
network 300 is shown. In the network there are three edge routers
ER, one gatekeeper Gk and one gateway G to PSTN. In this network
the routers R that connects LAN segments are geographically
distributed, e.g. Stockholm, Gothenburg, Malmo, etc. Between these
geographically distributed routers R the bandwidth is limited. The
gatekeeper Gk manages the whole network which then defines a zone.
The gatekeeper Gk and the gateway G are geographically located
where the number of users is highest. The gatekeeper Gk could be
located anywhere, but for practical reasons these are co-located.
The logical location for the gateway G is to place it where most of
the calls are made. This will result in less routing of calls
through the rest of the network, which would be the case if the
gateway G were located in a LAN segment far away from the majority
of the users.
[0014] The gatekeeper Gk can be configured to allow X simultaneous
calls on a heuristic basis. If the perceived quality is degraded,
the threshold of simultaneous calls can be decreased. This
heuristic decision base will cause problems. One user can, with or
without malicious intentions, cause low overall utilisation and
denial of service to other users. By starting sessions that use a
thin bottleneck link, the heuristics will be adjusted to allow very
few sessions in the zone. Other users that are connected with
well-provisioned links will then be denied access, even if the
bottleneck link would not be involved in those sessions. Other
problems will occur when the usage behaviour is changed in some
way, or when there are topology changes. Changed user behaviour
could be that more users than usually gets their calls routed over
a thin or loaded link, which could cause packet drops or increased
delays. Topology change could be caused by link failure. This
causes rerouting of packets meaning that the packets then take
alternate paths through the network. Topology change can also be
that a link characteristic is changed in some way, e.g. increased
or decreased bandwidth, delay, etc.
[0015] Another problem is that gatekeeper-routed calls cannot be
guaranteed high service quality in case direct calls are allowed.
If a gatekeeper Gk performs bandwidth management for
gatekeeper-routed calls in a zone and is unaware of simultaneous
direct calls, the total traffic volume may exceed available
bandwidth at some link. The problem here is that both
gatekeeper-routed and direct calls use the same resources. This is
due to that the gatekeeper Gk performs bandwidth management and
approves bandwidth requests on gatekeeper-routed calls while direct
calls can be made within the network without informing the
gatekeeper about the bandwidth usage. In the case where direct
calls are used within the IP telephony network, service
differentiation, i.e. mechanisms in network elements that
prioritise and forward important calls before less important calls,
is necessary as soon as some sort of guarantees for a service is
required. Gatekeeper approved calls can then be marked as important
and forwarded first while direct calls are marked as less
important.
[0016] For ongoing calls, problems might occur if there are
additional endpoints that want to join the session and these
endpoints are located on networks segments without available
resources or where the available resources are not sufficient to
provide predictable service. This issue will only occur when there
is a multipart conference involving more than two endpoints.
[0017] Yet another problem is that different H.323 zones might be
separated by non-H.323 enabled networks. Currently there are no
means to provide a predictable service in this case because
resources are not controlled in a non-H.323 network. QoS support
for H.323 using RSVP is currently under development. However, QoS
support using RSVP is not scalable, especially not when there are
calls made between endpoints in different zones where there are a
non-H.323 enabled network in between. RSVP does per call signalling
and reservations that would load the networks with signalling
instead of useful traffic, i.e. media streams, and set-up per call
state in routers.
[0018] Current H.323 systems do not allow reservations in advance,
which makes it hard to plan meetings with predicted quality.
[0019] Yet another problem in the H.323 standard is that a
bandwidth request is always approved or rejected. A more flexible
approach between the bandwidth management functionality and the
end-user is preferred.
[0020] The European patent document EP 0942560 discloses an
apparatus and method for speech transport with adaptive packet
size. It aims to minimize end-to-end delays caused by network
traffic and low capacity routers in the network topology between
two IP telephony devises. The aim is achieved by adopting packet
sizes for speech transport. However, the document do not address
how admission control can be done in speech transport systems, i.e.
evaluating if there are sufficient capacity in the network before
starting sessions and for communicating admission decisions to the
system.
SUMMARY OF THE INVENTION
[0021] The object of the present invention is to provide a way of
handling recourse management issues and admission control within an
IP telephony system.
[0022] The above-mentioned object is achieved by a method, a
resource manager and a system according to the characterising part
of the independent claims.
[0023] Thanks to that the topology aware resource manager provided
by the present invention, comprises means for collecting routing
information concerning the IP network, means for obtaining resource
information concerning resources within the IP network, means for
creating a resource map by means of combing said routing
information and resource information, and means for interacting
with the gatekeeper it is possible for the resource manager to
perform recourse management issues and admission control within the
system.
[0024] The method provided by the present invention comprising the
steps of: [0025] collecting routing information concerning the IP
network; [0026] obtaining resource information concerning resources
within the IP network; [0027] creating a resource map by means of
combing said routing information and resource information; makes it
possible to perform recourse management issues and admission
control within the system, by means of said resource map and by
interacting with a gatekeeper.
[0028] Preferred embodiments are set force in the dependent
claims.
[0029] An advantage of the present invention is that increased
utilisation of the network that will be achieved.
[0030] Another advantage of the present invention is that it is be
possible to prioritise certain traffic and still allow other
traffic in the same network. This gives flexible system
solutions.
[0031] Another advantage of the present invention is that it makes
it possible to reserve resources in advance to allow planned
meetings and events.
[0032] Yet another advantage of the present invention is that it
makes it possible to allow calls with predictable quality through
non-H.323 domains if these domains where QoS enabled with
inter-domain communicative resource managers. It would be In these
inter-zones segments resources can be reserved in advance for
traffic aggregates to avoid per call signalling in these segments,
i.e. trunk bandwidth. This is a very resource efficient feature of
the described technology. Reservations in advance are allowed to
vary over time, e.g. reserve more bandwidth during working hours
and less otherwise. In other words, the user of the described
technology can schedule resources by predicting the resource need
over time.
[0033] A further advantage of the present invention is the flexible
interaction between service provider and end-user that a full
resource map can provide if this is a customer need.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] FIGS. 1-3 are related to the state of the art and are
described above.
[0035] FIG. 1 shows an overview of the major components in an H.323
system according to the state of the art.
[0036] FIG. 2 is a diagram depicting multipoint communication
according to the state of the art.
[0037] FIG. 3 is a block diagram illustrating a topology for an
H.323 enabled network according to the state of the art.
[0038] FIG. 4 is a block diagram illustrating an exemplary topology
aware resource manager entity RM within an IP telephony system,
according to a first embodiment of the present invention.
[0039] FIG. 5 is a block diagram illustrating an exemplary topology
aware resource manager entity RM within an IP telephony system 500,
according to a second embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0040] FIG. 4 is a block diagram illustrating an exemplary topology
aware resource manager entity RM within an IP telephony system 400,
according to a first embodiment of the present invention. The
resource manager RM comprises topology aware resource manager
functionality. It is comprised in an IP telephony system e.g. an
H323 system. Such a system is described FIG. 1, above under
"background of the invention". Hence, in addition to the resource
manager RM, the IP telephony system typically comprises IP
telephony components such as one or many gatekeepers Gk, gateways
G, and terminals, as well as IP network elements such as routers R,
edge routers ER and Local Area Network (LAN) segments to which the
terminals typically are connectable. The IP telephony system (400)
is used to enables end-users to use an IP network as the
transmission medium for multimedia.
[0041] The resource manager RM interacts with the gatekeeper Gk and
handles all resource management issues for initiated and ongoing
calls and admission control for call set-up requests. The
interaction between the RM and the Gk can be implemented in a
number of ways, e.g. via a communication protocol, inter process
communication, functional calls between integrated software
modules, etc.
[0042] Topology awareness is the availability of correct routing
and resource information, which is essential to a system which
performs resource management and admission control. The resource
manager RM retrieves routing information concerning the IP network,
i.e. the topology of the IP network.
[0043] In the case wherein the IP network is routed using
link-state routing protocol, the resource manager RM participates
in the routing and acts as a router, i.e. the RM peers with other
routers, without advertising any routes of its own, to retrieve
routing information of the IP network The basic principle on which
link-state protocols are built ensures that all routers have the
complete routing information. When participating in the routing
protocol, the resources manager RM receives the routing information
as fast as any other router in the routing domain and can therefore
detect changes in the topology instantly.
[0044] In the case wherein the IP network is routed using a
distance vector protocol, or static routing, the method of peering
cannot be used. In this case, the routing information is retrieved
by measurements such as trace route (See Kessler G., A Primer on
Internet and TCP/IP Tools, IETF, RFC1739) and/or the use of Simple
Network Management Protocol (SNMP) auto discovery (see Keshav et
Al, Discovering Internet Topology,
http://www.cs.cornell.edu/skeshav/papers/discovery.pdf, July 1998).
SNMP is a set of protocols for managing complex networks. When the
resource manager RM has retrieved the routing information, it uses
a network management protocol, such as SNMP (see Case et Al,
Introduction to Version 3 of the Internet-standards Network
Management Framework, IETF, RFC2570), to collect information on the
routers and their interfaces (e.g. the interface type and speeds).
The information is used by the RM to complement the gained routing
information and make sure that it has an accurate routing
topology.
[0045] The resource manager RM combines the touting information and
resource information it gets from call set-up requests from the Gk
to create a resource map. The resource map contains information of
how much resources (e.g. bandwidth) that are available and reserved
over time on a per link basis. The resource manager RM uses the
resource map to assist the gatekeeper Gk in the decision whether
there are resources available or not, for a call that someone is
initiating.
[0046] In the case of gatekeeper-routed calls, the gatekeeper Gk is
responsible for approving or rejecting initiated calls from
terminals. The gatekeeper Gk interacts with the resource manager RM
and asks the resource manager RM if there will be enough resources
through the routed path between the source endpoint and the
destination endpoint of an initiated call, to give the predictable
quality. The resource manger RM answers the question by evaluating
what network path the call will use and for each link along that
path it calculates if there are sufficient resources to admit the
call, i.e. the resource manager RM performs path-sensitive
admission control on the resource request. The admission control is
performed based on the information in the resource map. This will
solve the above-mentioned problem addressed as the changes in user
behaviour. No heuristic model can cope with changes in user
behaviour, but the topology aware resource manager RM does that by
being up to date about the resource utilisation. The same goes for
the problem with denial of service.
[0047] Another problem addressed above is the changes in topology.
The resource manager RM monitors on-going calls in the IP telephony
system and recalculates the resource usage per link whenever any
change occurs i.e. updates the resource map. If the updated
resource map show that resources are too limited to be able to
fulfil all on-going calls the resource manager RM will report this
to the to the gatekeeper Gk. If the resources are limited as just
described, it is possible to let either the resource manager RM or
the gatekeeper Gk prioritise which calls that should be kept and
which to terminate. By performing this prioritisation, degraded
quality for everyone involved is avoided. This prioritisation also
makes the number of lost calls minimised. Another way to prioritise
services whenever topology changes occur is to let video streams
gets lower priority compared to the voice service.
[0048] FIG. 5 is a block diagram illustrating an exemplary topology
aware resource manager entity RM within an IP telephony system 500,
according to a second embodiment of the present invention. In this
second embodiment, the resource manager RM is used in a multipart
conferencing scenario involving more than two endpoints. Within a
multipart conferencing there will always be a multipoint controller
MC involved in the communication. The IP telephony system shown in
FIG. 5 is the same typically IP telephony system as the one in
illustrated in FIG. 4 except for that it additionally comprises a
multi-point controller MC. The system may comprise more than one
multi-point controller. The multi-point controller MC has knowledge
about which endpoints that participates in the multipart conference
and the MC will also control these endpoints. The resource manager
RM provides the admission control to the multi-point controller MC,
either directly or indirectly via the gatekeeper Gk, in the same
way as provided to the Gk as describe above. The resource request
may in this case contain more than two endpoints.
[0049] In a multipart conferencing call, a task to add participants
as resource efficiently as possible arises. In this case, the
resource manager RM recommends the multi-point controller MC, by
means of the resource map, which distribution method
(centralised/decentralised or an appropriate hybrid between these)
to use to make it possible for the added part to join the session
in a resource efficient manner. The distribution method to use is
depending on the resource map and hence, only the resource manager
RM has the possibility to answer this.
[0050] In case there are no resources available with predictable
quality, different methods to handle this exists. The user can get
service without priority or the user can be rejected to participate
in the conference due to lack of resources.
[0051] In case different priorities are used, there must be either
two multicast sessions of which one is prioritised and the other is
not, or a separate unicast session to the part that suffers from
lack of resources. [0052] In the multicast case, the part with less
predictable resources must listen to the session without priorities
and the traffic will therefore never be distributed to that part of
the network. [0053] In the unicast case, one part of the session
can relay its traffic as unicast without priority to the part with
lack of predictable resources.
[0054] For both the unicast case and the multicast case, the
bandwidth request is approved or rejected. From an end-user point
of view it is more convenient to have a reject with conditions,
which is possible when using the resource manager RM according to
the present invention.
[0055] For instance, the end-user requests for 64 kbit/s voice
service and 128 kbit/s video service. The available resources are
not sufficient to fulfil this request but only 128 kbit/s is
available which is found out by the resource manager RM by means of
the resource map. The answer from the resource manager RM could
then be e.g. "Your request cannot be fulfilled, only 128 kbit/s can
be reserved for you. Please respond to this message within 5
minutes to reserve these 128 kbit/s." A preliminary booking of
resources is made by the resource manager RM, based on the original
request from the gatekeeper Gk or multi-point controller MC. This
preliminary booking request is then cancelled unless there is a
response to the message sent from the resource manager RM to the
gatekeeper Gk or MC. For the end-user, it is then possible to
select which service to prioritise in favour of the other. I.e.
that is in case there is a wish to put either of the services in
favour of the other. The same goes if only one service is
considered. The user wants e.g. to run high-quality voice, but due
to lack of resources he accepts medium-quality voice with
predictable quality rather than high-quality voice without
possibilities to predict the quality.
[0056] Even though the state of the art describes H.323 and the
solution according to the present invention is adapted to that
recommendation other similar IP telephony solutions are possible,
e.g. there exists a competing IP telephony solution according to
the IETF standard SIP where the same solutions are applicable.
[0057] The resource manager RM comprises means for performing the
method steps described above.
[0058] The resource manager functionality is implemented by means
of a computer program product comprising the software code means
for performing functionality. The computer program is run on a
standalone server interacting with gatekeepers, or is run on the
same hardware as the gatekeeper functionality. It can be integrated
with software that implements gatekeeper functionality, it may also
run on routers or other network entities. The resource manager
functionality may also be distributed to run on multiple nodes
and/or distributed geographically over a network. The above is also
applicable for interaction with other entities performing the same
functionality as gatekeepers. The computer program is loaded
directly or from a computer usable medium, such as a floppy disc, a
CD, the Internet etc
[0059] The present invention is not limited to the above-described
preferred embodiments. Various alternatives, modifications and
equivalents may be used. Therefore, the above embodiments should
not be taken as limiting the scope of the invention, which is
defined by the appending claims.
* * * * *
References