US 20060069779 A1
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.
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
3. The resource manager (RM) according to
4. The resource manager (RM) according to
5. The resource manager (RM) according to
6. The resource manager (RM) according to
7. The resource manager (RM) according to
8. The resource manager (RM) according to
9. The resource manager (RM) according to
10. The resource manager (RM) according to
11. The resource manager (RM) according to
12. The resource manager (RM) according to
13. The resource manager (RM) according to
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
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
17. The method according to
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
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
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
calculating, for each link along that path, if there are sufficient resources to admit the call.
21. The method according to
22. The method according to
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
24. The method according to
25. The method according to
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
27. The method according to
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
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
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.
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.
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.
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).
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
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 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.
Besides these required components, the terminal T could also have MCU capabilities.
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
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
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.
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.
Lack of topology awareness and path sensitive admission control is the most important drawback of current implementations of H.323 gatekeepers. In
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.
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.
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.
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.
Current H.323 systems do not allow reservations in advance, which makes it hard to plan meetings with predicted quality.
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.
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.
The object of the present invention is to provide a way of handling recourse management issues and admission control within an IP telephony system.
The above-mentioned object is achieved by a method, a resource manager and a system according to the characterising part of the independent claims.
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.
The method provided by the present invention comprising the steps of:
Preferred embodiments are set force in the dependent claims.
An advantage of the present invention is that increased utilisation of the network that will be achieved.
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.
Another advantage of the present invention is that it makes it possible to reserve resources in advance to allow planned meetings and events.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The resource manager RM comprises means for performing the method steps described above.
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
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.