|Publication number||US20060069779 A1|
|Application number||US 11/266,352|
|Publication date||Mar 30, 2006|
|Filing date||Nov 4, 2005|
|Priority date||Sep 5, 2000|
|Also published as||DE60139016D1, EP1320971A1, EP1320971B1, US7606885, US20030187986, WO2002021797A1|
|Publication number||11266352, 266352, US 2006/0069779 A1, US 2006/069779 A1, US 20060069779 A1, US 20060069779A1, US 2006069779 A1, US 2006069779A1, US-A1-20060069779, US-A1-2006069779, US2006/0069779A1, US2006/069779A1, US20060069779 A1, US20060069779A1, US2006069779 A1, US2006069779A1|
|Inventors||Jim Sundqvist, Anders Larsson, Joakim Norrgard, Olov Schelen|
|Original Assignee||Operax Ab|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (13), Classifications (11)|
|External Links: USPTO, USPTO Assignment, Espacenet|
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.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7489687||May 31, 2002||Feb 10, 2009||Avaya. Inc.||Emergency bandwidth allocation with an RSVP-like protocol|
|US7633942 *||Oct 15, 2002||Dec 15, 2009||Avaya Inc.||Network traffic generation and monitoring systems and methods for their use in testing frameworks for determining suitability of a network for target applications|
|US7835303||Apr 2, 2007||Nov 16, 2010||At&T Intellectual Property Ii, L.P.||Packet-switched network topology tracking method and system|
|US7860024 *||Dec 30, 2002||Dec 28, 2010||At&T Intellectual Property Ii, L.P.||Network monitoring method and system|
|US7877500||Feb 7, 2008||Jan 25, 2011||Avaya Inc.||Packet prioritization and associated bandwidth and buffer management techniques for audio over IP|
|US7877501||Feb 7, 2008||Jan 25, 2011||Avaya Inc.||Packet prioritization and associated bandwidth and buffer management techniques for audio over IP|
|US8028088||May 9, 2008||Sep 27, 2011||Netsocket, Inc.||System and method for service assurance in IP networks|
|US8176154||Sep 30, 2002||May 8, 2012||Avaya Inc.||Instantaneous user initiation voice quality feedback|
|US8543681||Oct 15, 2002||Sep 24, 2013||Volli Polymer Gmbh Llc||Network topology discovery systems and methods|
|US8593959 *||Feb 7, 2007||Nov 26, 2013||Avaya Inc.||VoIP endpoint call admission|
|US8780716||Sep 12, 2008||Jul 15, 2014||Netsocket, Inc.||System and method for service assurance in IP networks|
|US20040073690 *||Sep 30, 2002||Apr 15, 2004||Neil Hepworth||Voice over IP endpoint call admission|
|US20120005338 *||Jan 5, 2012||Netsocket, Inc.||System and Method for Service Assurance in IP Networks|
|International Classification||H04L12/66, H04M7/00, H04L12/56, H04L12/24, G06F15/173|
|Cooperative Classification||H04M7/006, H04L45/00, H04L41/12|
|European Classification||H04L41/12, H04L45/00|