US20030123388A1 - Admissions control in a connectionless communications network - Google Patents

Admissions control in a connectionless communications network Download PDF

Info

Publication number
US20030123388A1
US20030123388A1 US10034521 US3452101A US20030123388A1 US 20030123388 A1 US20030123388 A1 US 20030123388A1 US 10034521 US10034521 US 10034521 US 3452101 A US3452101 A US 3452101A US 20030123388 A1 US20030123388 A1 US 20030123388A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
call
server
bandwidth
packet
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10034521
Inventor
Patrick Bradd
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nortel Networks Ltd
Original Assignee
Nortel Networks Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14Backbone network devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • H04L29/0602Protocols characterised by their application
    • H04L29/06027Protocols for multimedia communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/72Reservation actions
    • H04L47/724Reservation actions involving intermediate nodes, e.g. RSVP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/801Real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/806Broadcast or multicast traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/822Collecting or measuring resource availability data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/1043MGC, MGCP or Megaco
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1073Registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1083In-session procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/40Services or applications
    • H04L65/403Arrangements for multiparty communication, e.g. conference
    • H04L65/4038Arrangements for multiparty communication, e.g. conference with central floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/80QoS aspects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/10Flow control between communication endpoints
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W72/00Local resource management, e.g. wireless traffic scheduling or selection or allocation of wireless resources

Abstract

A method of providing call admission control which does not require using MIDCOM protocol methods, Packetcable protocols or COPS-RSVP approaches is described which is simple to implement, cost-effective and which is able to deal with particular situations such as conference calls. Each link in a communications network over which it is required to perform call admissions control is provided with a middlebox connected at each end of that link such that admissions control can be carried out at one end of the link. Call services are provided by Call Servers, each of which has access to a database containing pre-specified information about all middleboxes in that call server's realm. The database also has information about maximum bandwidths for the link associated with each middlebox. The call servers are used to keep a running tally of the amount of VolP call bandwidth associated with each middlebox on the edge of a low-bandwidth link, and to accept or refuse calls on the basis of the bandwidth information on a per-call basis.

Description

    FIELD OF THE INVENTION
  • [0001]
    The present invention relates to a method and apparatus for admissions control in a connectionless communications network.
  • BACKGROUND TO THE INVENTION
  • [0002]
    Admissions control is a significant problem in communications networks and especially in connectionless, packet-based, communications networks. For example, consider a particular link in a communications network. If that link becomes congested, the traffic is unable to flow through the link and packets are dropped. This results in deterioration in quality of service for all services provided over that link. In particular situations this has especially severe impact, for example, when the link provides the main access route from a communications network of a particular enterprise or residential customer to a core communications network.
  • [0003]
    These problems are particularly relevant for voice over internet protocol (VOIP) solutions. If a link is already carrying the maximum number of VOIP calls, or other non-voice traffic, adding additional calls seriously degrades the voice quality of existing calls using that link. The new call added to the link also has poor voice quality. Continuing to add calls to the link degrades the quality of all calls until none of those calls are recognisable.
  • [0004]
    The term “Voice over Internet Protocol call” is used herein to refer calls involving any suitable type of media over internet protocol. For example, speech calls, fax calls, modem calls or video calls.
  • [0005]
    [0005]FIG. 4 shows a voice over internet protocol (VOIP) communications network in which admissions control is required. A local area network 40 (LAN), or any suitable type as known in the art, is connected via an access link A to a core communications network 42. Any suitable type of access link can be used as is known in the art, for example, Gigabit Ethernet, Digital Subscriber, or leased line. However, link A is unable to support calls into the core from all endpoints in the LAN simultaneously. Those endpoints are said to be “concentrated” behind link A. Concentration can be implemented in network designs for example where many of the calls are anticipated to stay on the LAN behind an access link to a core network and/or where not all of the endpoints will need to make calls into the core network at the same time. In this way a customer's LAN may be connected to a core network via a single access link that supports both voice and data at the same time. In such situations there is a need to detect when over utilisation of the access link is likely to occur in order that preventative measures can be taken. However there are currently no suitable methods for detecting link over-utilisation and communicating this to a call server or other management node in order that link over-utilisation can be prevented.
  • [0006]
    Another example is illustrated in FIG. 5. In this case an enterprise network 50 is connected via a fixed wireless link 51 to a core network 52. The fixed wireless link has limited bandwidth and is unable to support calls from all endpoints in the enterprise network at one time. In addition varying amounts of bandwidth are required for calls, depending on the type of call required (e.g. voice calls can use a multitude of different codecs, each of which have their own bandwidth characteristics, fax call, etc.) and this further increases the complexity of the admissions control problem.
  • [0007]
    One known form of admissions control for the “access” portion of a network is found in the Packetcable (Trade Mark) standards for dynamic quality of service (DQOS). Packet Cable is a set of protocols developed by Cable Television Laboratories, Inc. The protocols are designed to enable quality of service enhanced communications using packetised data transmission technology to a subscriber's home over the cable network. A network superstructure that overlays the two-way data-ready digital cable television network is used. The Packetcable protocols are thus specifically designed for such cable television networks. Another disadvantage of these protocols from the point of view of admissions control is that all the internet protocol media endpoints (e.g. user terminals and other packet media endpoints) and devices on the edge of low-bandwidth links (i.e. in the Packetcable architecture, the CMTS) are required to fully support the reservation protocol (RSVP). In addition those endpoints and devices are required to support mechanisms to send and receive session identifier information from a call server. Also the call server and the devices at the edge of the low bandwidth link need to support the common open policy service (COPS) protocol. This is problematic because many existing communications networks are formed from equipment made by different manufacturers and where many of the nodes or endpoints do not support RSVP or COPS where needed. In addition, the Packetcable protocols require all layer-3 aware devices in a media path to support RSVP in order that call admission control can be effected. However, this is not the case for many communications networks. For example, FIG. 5 shows a low-bandwidth link 51 where nodes at either end of that link are only layer-2 aware devices. Therefore Packetcable protocol type call admission control mechanisms would not be effective. Other disadvantages of the Packetcable approach to call admission control include that no support for layer 2 flows is provided and the fact that all devices in the network which support RSVP are required to have some policy awareness.
  • [0008]
    The reservation protocol is defined in the Internet engineering task forces' request for comments (RFC) 2205 whilst COPS is defined in RFC 2748.
  • [0009]
    The known approach to call admissions control mentioned above which uses the Packetcable standards is now described in more detail. This approach involves the Common Open Policy Service (COPS) with RSVP. An example of a typical architecture for COPS and RSVP admissions control is given in FIG. 6 which shows two access networks connected to a core communications network via Policy Enforcement Points (PEPs). The core network comprises a policy decision point (PDP) and a call server. Using this approach, the originating and terminating parties make an admissions request to the call server using H.248, or any other suitable device control protocol such as media gateway control protocol (MGCP) or NCS where NCS is the Packetcable specific version of MGCP as indicated in FIG. 6. The call server then grants an appropriate service ticket to each of those parties. Next, the originating party or originating PEP spawns a network admission request through the network. A similar request is spawned by the destination party or destination PEP to request a call flow in the opposite direction and so provide a 2-way flow. The PDP receives the admission requests and forwards those to the call server.
  • [0010]
    The call server verifies the service tickets. The PDP decides whether to accept or refuse the request on the basis of available bandwidth on the low-bandwidth access link and if accepted, opens a reserved path for media for the new call. However, the COPS and RSVP approach is problematic because significant post dial delay occurs as a result of the admission process and also the other problems mentioned above with respect to the Packetcable approach apply. In addition, the means by which the call server and PDP communicate is not yet fully standardized.
  • [0011]
    More recently the Internet Engineering Task Force (IETF) have set up a working group to consider ways in which middleboxes can be controlled. The term “middlebox” is used herein to refer to an entity in a communications network which is associated with a low-bandwidth link and which is able to allow or disallow individual traffic flows over that link. For example, the middlebox may be a node connected to one end of a low-bandwidth link. Also, the middlebox may be part of a node which is not directly connected to one end of a low-bandwidth link but which is able to allow or disallow individual traffic flows over that link. The IETF working group is referred to as the MIDCOM (middlebox communications) working group. In the future it may be possible to use protocols developed by the MIDCOM working group to control such middleboxes in order that they themselves perform admissions control. However, these MIDCOM protocols are not yet developed and ratified. Indeed, we understand that the MIDCOM working group is currently working on the control of middleboxes for network address translation and firewall purposes, but not for admissions control purposes. It will be some time before this is the case and those protocols are deployed on all the required nodes in existing communications networks. In addition such MIDCOM methods would require a means by which a call server is automatically able to identify which middleboxes are relevant for a particular call. However, “middlebox discovery” mechanisms like this are not currently known.
  • [0012]
    Thus a means of providing call admission control which does not require using MIDCOM protocol methods, Packetcable protocols or COPS-RSVP approaches is required which is simple to implement, cost-effective and which is able to deal with particular situations such as conference calls, lawful intercept (known in North America as CALEA), and other potential call service situations is required.
  • [0013]
    The invention seeks to provide an improved method and apparatus for performing admissions control which solves or at least mitigates one or more of the problems mentioned above.
  • [0014]
    Further benefits and advantages of the invention will become apparent from a consideration of the following detailed description given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.
  • SUMMARY OF THE INVENTION
  • [0015]
    A method of providing call admission control which does not require using MIDCOM protocol methods, Packetcable protocols or COPS-RSVP approaches is described which is simple to implement, cost-effective and which is able to deal with particular situations such as conference calls and/or lawful intercept Each link in a communications network over which it is required to perform call admissions control is provided with a middlebox connected at each end of that link such that admissions control can be carried out at one end of the link. Call services are provided by Call Servers, each of which has access to a database containing pre-specified information about all middleboxes in that call server's realm. The information in the database is manually configured for example although this is not essential. The database also has information about which media endpoints are behind what middle box, and maximum bandwidths for the link associated with each middlebox. The call servers are used to keep a running tally of the amount of VoIP call bandwidth associated with each middlebox on the edge of a low-bandwidth link, and to accept or refuse calls on the basis of the bandwidth information on a per-call basis
  • [0016]
    According to a first aspect of the present invention there is provided a call server for use in a connectionless, packet, communications network in order to provide admissions control, said communications network comprising a plurality of middleboxes, each middlebox being associated with a different link in the communications network and arranged to control packet flow over that link, said call server comprising:
  • [0017]
    an input arranged to receive a call admission request from an originating packet media endpoint, said call admission request comprising information about the originating packet media endpoint, and a destination packet media endpoint;
  • [0018]
    an input for accessing information about all first middleboxes associated with the originating node and all second middleboxes associated with the destination node, together with information about the amount of available bandwidth on the link associated with each of those middleboxes;
  • [0019]
    a processor for determining whether to accept the call admission request on the basis of the accessed information about available bandwidth;
  • [0020]
    an output arranged to output the results of the determination as to whether to accept the call admission request.
  • [0021]
    This provides the advantage that the call server effectively provides admission control capability on behalf of the middleboxes. Because the call server is able to access information about middleboxes and the available bandwidth on the low-bandwidth links associated with those middleboxes it is able to perform call admission control. This is achieved without the need to modify existing packet media endpoints such as media gateways and internet protocol endpoints. In addition, it is not necessary for those packet media endpoints to be fully RSVP enabled or for the middleboxes to be MIDCOM enabled with respect to call admissions control. Another advantage is that call admission control over the low-bandwidth links is achieved even where nodes at either or both ends of the low-bandwidth link are layer-2 but not layer-3 aware. This is because effectively the call server performs the admission control determinations.
  • [0022]
    The information about the destination packet media endpoint is preferably provided by a destination or called party number representing the packet media endpoint.
  • [0023]
    Preferably the processor is arranged to determine whether to accept the call admission request on the basis of the accessed information about available bandwidth together with information about the bandwidth requirements for the call. For example, a pre-specified value of the bandwidth requirements for any call can be used. Alternatively the call server can determine what bandwidth is needed as explained in more detail below.
  • [0024]
    Preferably the processor is further arranged to determine whether all the first middleboxes are the same as all the second middleboxes and to accept the call admission request in such cases. This provides the advantage that when the call path does not traverse a low-bandwidth link associated with a middlebox then the call is simply accepted.
  • [0025]
    Advantageously said processor is further arranged to identify which of the first middleboxes are not also second middleboxes and vice versa, and wherein said processor is arranged to determine whether to accept the call admission request on the basis of accessed information about available bandwidth only for links associated with those identified middleboxes. This ensures that when the call path or flow does traverse one or more low-bandwidth links associated with middleboxes, then call admission control is performed for each of those links.
  • [0026]
    According to another aspect of the present invention there is provided a method of performing admissions control in a connectionless, packet, communications network, said communications network comprising a plurality of middleboxes, each middlebox being associated with a different link in the communications network and arranged to control packet flow over that link, said method comprising the steps of, at a call server:
  • [0027]
    receiving a call admission request from an originating packet media endpoint, said call admission request comprising information about the originating packet media endpoint and a destination packet media endpoint;
  • [0028]
    accessing information about all first middleboxes associated with the originating packet media endpoint and all second middleboxes associated with the destination packet media endpoint, together with information about the amount of available bandwidth on the link associated with each of those middleboxes;
  • [0029]
    determining whether to accept the call admission request on the basis of the accessed information about available bandwidth; and
  • [0030]
    outputting the results of the determination as to whether to accept the call admission request.
  • [0031]
    The communications network is preferably an internet protocol communications network at layer 3. At layer 2, a variety of protocols could be used, such as ATM, Ethernet, PPP, etc. A variety of layer 1 physical layers can also be provided. The calls are preferably voice over internet protocol calls.
  • [0032]
    The middle boxes at both ends of the low-bandwidth link are arranged to use quality of service (QOS) mechanisms as known in the art to prioritise VoIP traffic from other non-VoIP traffic accessing the low-bandwidth link. This is accomplished using well known classification techniques such as packet marking, port based, VLAN based, etc., as well as traffic shaping, and traffic dropping as known in the art. The end-result is that the voice traffic always has priority over non-voice traffic. If there is ever voice traffic to be sent, it is always sent over the low-bandwidth link ahead of non-voice traffic. This results, essentially, in the voice traffic having complete access to all the available bandwidth on the access link. The term “voice traffic” is used here and in the document as a whole to refer to any suitable type of media in a voice over IP call, for example, speech, fax, video and modem.
  • [0033]
    Preferably said information about bandwidth requirements for the call comprises session description protocol (SDP) information received from both the originating and destination packet media endpoints. SDP is specified in the IETF's RFC number 2327. This provides a simple and effective means by which bandwidth requirement information can be obtained by the call server on a per-call basis. The call server is also able to adjust the bandwidth requirements used for the call if these requirements change in the SDP information, for example, as codec requirements are negotiated between the packet media endpoints during call setup time, prior to answer. (A codec is a device for converting speech into signals suitable for transfer by a packet based protocol.) Even post-answer, it is possible to use SDP changes to change the codec being used, and the call server is preferably arranged to take this into account when doing admissions control. Suppose that the call server detects a change to a new codec that requires more bandwidth than previously required for a call. In that case, if there is not enough bandwidth on a link used in this call to change to the new codec, then the Call Server is preferably arranged to force the call to remain at the current, un-modified bandwidth.
  • [0034]
    In one embodiment said call is a voice call and said information about bandwidth requirements for the call comprises information about one or more codecs to be used in the call. Also, the call may be a conference call to be established using a conferencing service in the communications network. In addition the call may be subject to lawful intercept as explained in more detail below.
  • [0035]
    In another embodiment the communications network comprises two or more call servers, and wherein said method further comprises: receiving said call admission request at an origination call server associated with the origination packet media endpoint and determining whether a destination call server, associated with the destination packet media endpoint is the same as the origination call server. This provides the advantage that admissions control for calls which traverse realms of more than one call server can be carried out.
  • [0036]
    Advantageously, when said determination indicates that the destination call server and the origination call server are different, the method comprises allowing the origination and destination packet media endpoints to negotiate as to a codec to be used for the call and to send information about that codec to both the origination and destination call servers. This codec can be used to determine an indication of bandwidth requirements for the call based on the codec information. Preferably, the negotiation about which codec to use is accomplished using known methods such as via session initiation protocol (SIP) or SIP-T. These protocols are able to carry SDP information regarding the call between the origination and destination call servers as described below.
  • [0037]
    Preferably, for all middleboxes associated with the origination packet media endpoint, the origination call server accesses information about available bandwidth and for all middleboxes associated with the destination packet media endpoint, the destination call server accesses information about available bandwidth.
  • [0038]
    Furthermore, if the call request is refused, instructions are sent to the origination packet media endpoint to provide a refusal indication to a calling party terminal which initiated the call request.
  • [0039]
    Also, if the call request is accepted, a database of middlebox information is updated with information about the call and updated again when that call ends.
  • [0040]
    Advantageously, one or more of said middleboxes are arranged to perform call admission control themselves under MIDCOM protocol control. This means that the method of the present invention can be implemented in communications networks which contain a mixture of MIDCOM enabled and non-MIDCOM enabled equipment. However the present invention does not seek to provide a MIDCOM protocol based solution although some embodiments of the present invention are operable in networks which contain a mixture of MIDCOM enabled and non-MIDCOM enabled equipment.
  • [0041]
    The invention also encompasses a communications network comprising at least one call server as specified above. Preferably, every originating and every destination packet media endpoint connected to a particular middlebox is controlled by the same call server. By specifying requirements for network topology in this way it is possible to use a simplified method of call admissions control as described herein.
  • [0042]
    The invention also encompasses a computer program arranged to control a call server such that the method specified above is carried out. Any suitable programming language may be used for the computer program as is known in the art.
  • [0043]
    The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0044]
    In order to show how the invention may be carried into effect, embodiments of the invention are now described below by way of example only and with reference to the accompanying figures in which:
  • [0045]
    [0045]FIG. 1 is a flow diagram of a call admission control method according to an embodiment of the present invention;
  • [0046]
    [0046]FIG. 2 is a flow diagram of another call admission control method according to another embodiment of the present invention;
  • [0047]
    [0047]FIG. 3 is a schematic diagram of a communications network comprising a call admission control system;
  • [0048]
    [0048]FIG. 4 is a schematic diagram of a prior art voice over internet protocol (VoIP) communications network;
  • [0049]
    [0049]FIG. 5 is a schematic diagram of a prior art voice over internet protocol (VoIP) communications network;
  • [0050]
    [0050]FIG. 6 is a schematic diagram of a typical COPS and RSVP admissions control architecture according to the prior art;
  • [0051]
    [0051]FIG. 7 is a schematic diagram of another communications network comprising a call admission control system;
  • [0052]
    [0052]FIG. 8 is a schematic diagram of a communications network comprising a conference bridge and a call admission control system according to an embodiment of the present invention.
  • [0053]
    [0053]FIG. 9 is a schematic diagram of a communications network comprising a call admissions control system and a lawful intercept system.
  • DETAILED DESCRIPTION OF INVENTION
  • [0054]
    Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved.
  • [0055]
    The term “low bandwidth link” is used to refer to a connection between two nodes in a communications network, where the capacity of the link is less than the capacity required should all entities connected to one end of the link issue communications over that link simultaneously. Typically there is only one such low bandwidth link between the two nodes referred to immediately above although this is not always the case.
  • [0056]
    The term “packet media endpoint” is used to refer to a terminal that is suitable for connection (possibly indirectly) to a middlebox or to refer to a node via which terminals access a middlebox (e.g. a media gateway).
  • [0057]
    The term “call agent” is used to refer to a node which is able to control a middlebox via the MIDCOM protocol. For example, a call server or a media gateway controller may be a call agent if these entities are MIDCOM enabled. In the present invention it is not essential for the call server to be MIDCOM enabled and in a preferred embodiment it is not MIDCOM enabled.
  • [0058]
    The present invention addresses the problem of admissions control by using a call server which has access to a pre-configured database of information about middleboxes and the available bandwidths at the low-bandwidth links associated with those middleboxes. By using pre-configured information in this way, a simple and effective means of call admission control is obtained and there is no need to make changes to existing IP media endpoints or to have MIDCOM enabled middleboxes. In addition, by specifying particular requirements for network design and topology it is possible to deal with situations in which more than one call server is involved. It is also possible to deal with complex service interactions such as conference calls and lawful intercept. In addition, the solution works for low bandwidth links where the edges of the low bandwidth link (i.e. the middle boxes) are capable of looking at either the layer 2 or layer 3 of the flow.
  • [0059]
    This is now explained in more detail with reference to FIGS. 1, 2 and 3. FIG. 3 gives a schematic diagram of a communications network comprising a call admission control system according to the invention and FIGS. 1 and 2 are flow diagrams of methods of call admission control in the network of FIG. 3.
  • [0060]
    [0060]FIG. 3 shows a Voice over IP communications network 30 comprising a plurality of nodes interconnected by links and for clarity only some of the nodes and links are shown. The communications network 30 comprises one or more call servers and in this example two call servers 31, 32 are shown and these are interconnected by link 38, which may be indirect and which uses a suitable protocol such as SIP-T for inter-call-server communication. Each call server 31, 32 is associated with one or more middleboxes 35; that is, the call server is able to control packet media endpoints that are behind those middleboxes with which the call server is associated. As explained above each middlebox is connected (possibly indirectly) to one or more packet media endpoints 36 and those packet media endpoints are connected to one or more terminals via which users are able to access the communications network. It is also possible for a single packet media endpoint to be connected behind more than one middlebox and thus more than one low bandwidth link although this is not shown in FIG. 3 for reasons of clarity.
  • [0061]
    Considering an individual call server, this is used to provide services to terminals connected to packet media endpoints. For example, in FIG. 3, call server 31 can be thought of as serving realm A and being associated with the middleboxes, packet media endpoints and terminals in its realm. Similarly call server 32 serves realm B. The two call servers 31, 32 are connected to one another either directly or indirectly. Communication between call servers 31, 32 is accomplished through the use of a well known inter-call-server communication protocol such as SIP-T as known in the art.
  • [0062]
    Accessible by each call server is a database or other information store 33, 34. These contain pre-specified information about all the middleboxes in the particular call server's realm. This information comprises:
  • [0063]
    For each middlebox in the realm, which packet media endpoints are associated with that middlebox, as well as, for each packet media endpoint, what the associated middlebox is;
  • [0064]
    For each middlebox in the realm the maximum possible bandwidth of the low-bandwidth link associated with that middlebox;
  • [0065]
    For each middlebox in the realm the current available bandwidth on the associated low-bandwidth link;
  • [0066]
    Optionally, information about whether each middlebox supports MIDCOM based protocol admissions control.
  • [0067]
    With reference to FIG. 1, when a call request is made by a user of a terminal, a call request message is sent from that terminal to the associated call server via an packet media endpoint and one or more middleboxes. The call request message is preferably in the form of a device control call origination message using a protocol such as H.248, media gateway control protocol or any other suitable protocol as known in the art.
  • [0068]
    The call request takes place in multiple stages although this is represented in FIG. 1 as one stage for clarity. The stages of the call request are known in the art and the exact details depend on the particular device control protocol used. An outline of the type of steps involved is:
  • [0069]
    Offhook from packet media endpoint to call server.
  • [0070]
    Call server tells packet media endpoint to create connection and collect digits.
  • [0071]
    Packet media endpoint tells call server the preferred bandwidth requirements for the call as well as IP addressing details, etc. (i.e. SDP information).
  • [0072]
    Packet media endpoint sends digit information to the call server and the call server uses this to form the destination packet media endpoint identity.
  • [0073]
    For example, consider a call request from terminal C in FIG. 1. The request message would proceed to packet media endpoint F, through middlebox 1 and to origination call server 31. The call request message contains information about the call destination as well as the origination and destination packet media endpoints (as mentioned above) and also information about the bandwidth requirements for the call (see box 10 of FIG. 1).
  • [0074]
    The origination call server 31 next checks whether the origination and destination packet media endpoints are both in its realm (see box 11 of FIG. 1). For example, if the destination party is terminal D in FIG. 3 then this is the case; the origination packet media endpoint F and the destination node E are both in realm A. In such cases the method proceeds as in FIG. 1; otherwise the method of FIG. 2 is adopted.
  • [0075]
    Considering the case where the method of FIG. 1 applies, the call server next checks whether call admission control is required. For example, if the origination and destination terminals are both served by the same packet media endpoint, then the call does not need to flow over a low bandwidth link and so no call admission control is needed. In order to check this, the call server 31 accesses its middlebox database 34. Details of all first middleboxes associated with the origination packet media endpoint are found. For example, these could be middlebox 1 in FIG. 3. Then details of all second middleboxes associated with the destination packet media endpoint are found. These could be middlebox 2 in FIG. 3. The call server 31 then checks these two sets of middleboxes for any items which are only in one of the sets. If all of the first middleboxes are the same as the second middleboxes then no call admission is required (see boxes 12 and 13 of FIG. 1) and the call request is accepted. Otherwise, any first middleboxes which are not also second middleboxes and vice versa are identified. For each of these middleboxes information about currently available bandwidth is obtained (see box 14 of FIG. 1).
  • [0076]
    If the bandwidth required for the call is less than each of the available bandwidths for those middleboxes then the call is accepted (see boxes 15 and 16 of FIG. 1). Otherwise the call is refused (see box 17 of FIG. 1). For example, consider a call from terminal C to terminal D. The low bandwidth links associated with both middleboxes 1 and 2 have to have enough available capacity for the proposed call. (The call server may not have empirical information about the available bandwidths but instead may use a counter or token system representing units of bandwidth or any other suitable scheme for indicating the relative amount of bandwidth).
  • [0077]
    When a call is accepted, the appropriate middlebox database is updated once the call begins and when the call ends. When a call is refused it is possible for the end user to be informed, for example by sending an instruction from the call server 31 to the destination packet media endpoint to play a special tone or a recorded announcement.
  • [0078]
    When call admission is barred then it is unlikely that a centralised announcement resource can be used to play an announcement, because of congestion in the network for example. Also, in order to use a centralised announcement resource the call admission control process would need to be carried out again. In view of this a treatment tone is preferably used or an announcement resource at the packet media endpoint itself.
  • [0079]
    As described with reference to FIG. 1, the call server receives information about the bandwidth requirements for the proposed call. This is preferably achieved via SDP information from the packet media endpoints (as mentioned above). In a preferred embodiment involving VoIP calls, the call server obtains the bandwidth requirement information by examining session description protocol (SDP) messages from each of the packet media endpoints in its realm. These message enable the call server to determine which codecs will be used in the call, as is known in the art. Then, based on the codec to be used in the call, the call server is able to allocate one or more bandwidth credits to the call. A codec using more bandwidth requires more credits. Thus in this embodiment, the call server also has access to pre-specified information about all possible codecs that may be used in calls in its realm and the amount of bandwidth needed by those codecs.
  • [0080]
    The method of FIG. 1 thus does not require the middleboxes to have MIDCOM capability and the packet media endpoints may be of any suitable type whether RSVP enabled or not. The method is therefore operable for networks formed from mixed equipment with some entities being MIDCOM controllable and some not if required.
  • [0081]
    In the case that the destination packet media endpoint is in a different realm from the origination packet media endpoint the method of FIG. 2 is used. The origination call server 31 receives a call request from packet media endpoint E for example, where the destination packet media endpoint is G for example. The call server recognises that packet media endpoint G is not in its realm, but instead in the realm of destination call server 32. This is achieved without reference to the middlebox database. Rather, standard call server translation and routing methods are used as is known in the art to determine that access node G is in the realm of destination call server 32. The origination and destination packet media endpoints are then allowed to negotiate as to which codec will be used for the call (in the case of a VoIP call) as is known in the art. (As explained above, a codec is a device for converting speech into signals suitable for transfer by a packet-based protocol and one or more codecs are associated with each call server.) Information about which codec is to be used is then sent to each of the origination and destination call servers 31, 32 (see box 22 of FIG. 2). This is preferably achieved using standard inter-call-server signalling such as SIP-T as known in the art.
  • [0082]
    Using the codec information, or other information about bandwidth requirements for the call both call servers 31, 32 allocate bandwidth credits for the call (see box 23 of FIG. 2). That is, each call server determines an indicator of how much bandwidth is needed for the call. Each call server then accesses its middlebox database to check whether the available bandwidth is enough for the call. This is done in a similar way described with respect to FIG. 1. That is, each call server determines which of its middleboxes are involved in the call and checks the available bandwidth on each of the associated low-bandwidth links.
  • [0083]
    As a result, if any of the call servers decides to refuse the call, the call is refused (see box 24 of FIG. 2). Otherwise, the call is accepted (see box 25 of FIG. 2). If the call is refused a treatment tone or an announcement is made as described above with reference to FIG. 1.
  • [0084]
    Thus the method of FIG. 1 involved checking for situations where no call admission control is needed. However, the method of FIG. 2 does not require such a check because the origination and destination packet media endpoints are always different when the call servers are different provided a particular network design is followed. That is, the network design should not have any middleboxes which are members of more than one realm. Such a situation is illustrated in FIG. 7 which is the same as FIG. 3 except that middlebox 3 is in both realms A and B.
  • [0085]
    In a preferred embodiment, the call server determines whether call admission control is required by using information from the middlebox database. For example, if the middlebox database shows that the access node concerned is behind a middlebox and also if the middlebox database shows that the call server is required to perform call admissions control on behalf of that middlebox.
  • [0086]
    However it is not essential for the call server to make this determination as described above. Another option is to add an identifier to call request messages as now described.
  • [0087]
    In order to inform the call server(s) that call admission control is required an identifier may be added to the call request message. This indicates the need for the call server to count the admissions through each middlebox on behalf of those middleboxes. However, in the case that some of the middleboxes are MIDCOM enabled and able to carry out their own call admission control, such an indicator is useful. For example, if the call server knows that a particular middlebox is MIDCOM enabled in that way, it can simply request call admission control from that middlebox.
  • [0088]
    In a preferred embodiment the call server uses a tag (called CAC-CSCount for example) to note in the middlebox database each middlebox that cannot perform call admission control via MIDCOM. Using the methods of FIGS. 1 and 2 the call server then effectively keeps track (using a counter mechanism) of the amount of bandwidth passing the low bandwidth link connected to the middle boxes as described above. Pre-specified in the middlebox database is information about the maximum amount of bandwidth allowed through the low bandwidth link connected to each middlebox. This information is obtained in any suitable manner, for example by theoretical calculations or by empirical measurement. If the current value of the bandwidth counter would exceed the maximum amount of bandwidth specified then the proposed call is refused.
  • [0089]
    The method is also able to deal with situations involving conference calls where a centralised conferencing service is used. For example, consider the situation in FIG. 8 which shows an access network 80 connected to a core network 81 comprising a conference bridge 83 via a low bandwidth link 82. If terminal A sets up a call to terminal C then a call path 84 is established and no admissions control is needed. However, if A proceeds to conference B into the existing call then three 2-way speech paths need to undergo admissions control, one path between each of A, B and C and the conference bridge 83. This is possible using the method of FIG. 1 for each of those paths.
  • [0090]
    The method is also able to deal with situations involving lawful intercept whereby calls from a particular entity are intercepted for security or other lawful purposes. This is illustrated schematically in FIG. 9 which is similar to FIG. 8. Consider user A in FIG. 9 and suppose user A to be a lawful intercept target.
  • [0091]
    In order for lawful intercept to proceed a centralised resource (referred to as a centralised receptor) is used in the core network. This means that all A's calls must pass the low bandwidth link, even if those calls would not otherwise need to do so (for example, calls to user B in FIG. 9). As a result user A's calls to user B could be dropped as a result of call admissions procedures associated with the low bandwidth link. This could alert user A to the fact that lawful intercept is being used. In order to prevent this, the present invention drops another existing call to provide enough bandwidth for A's call should this be required. In that way, A's call is not dropped and A does not have reason to become suspicious. A key requirement for lawful intercept is that lawful intercept targets are not aware that calls involving them are being monitored.
  • [0092]
    In FIG. 3 the middlebox databases 33, 34 are shown as separate from the call servers 31, 32. However, this is not essential. The middlebox database may be integral with its associated call server, or it may be a separate entitiy. This is an implementation decision.
  • [0093]
    Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person for an understanding of the teachings herein.

Claims (25)

  1. 1. A call server for use in a connectionless, packet, communications network in order to provide admissions control, said communications network comprising a plurality of middleboxes, each middlebox being associated with a different link in the communications network and arranged to control packet flow over that link, said call server comprising:
    (i) an input arranged to receive a call admission request from an originating packet media endpoint, said call admission request comprising information about the originating packet media endpoint, and a destination packet media endpoint;
    (ii) an input for accessing information about all first middleboxes associated with the originating node and all second middleboxes associated with the destination node, together with information about the amount of available bandwidth on the link associated with each of those middleboxes;
    (iii) a processor for determining whether to accept the call admission request on the basis of the accessed information about available bandwidth;
    (iv) an output arranged to output the results of the determination as to whether to accept the call admission request.
  2. 2. A call server as claimed in claim 1 wherein said processor is arranged to determine whether to accept the call admission request on the basis of the accessed information about available bandwidth together with information about the bandwidth requirements for the call.
  3. 3. A call server as claimed in claim 1 wherein said processor is further arranged to determine whether all the first middleboxes are the same as all the second middleboxes and to accept the call admission request in such cases.
  4. 4. A call server as claimed in claim 1 wherein said processor is further arranged to identify which of the first middleboxes are not also second middleboxes and vice versa, and wherein said processor is arranged to determine whether to accept the call admission request on the basis of accessed information about available bandwidth only for links associated with those identified middleboxes.
  5. 5. A method of performing admissions control in a connectionless, packet, communications network, said communications network comprising a plurality of middleboxes, each middlebox being associated with a different link in the communications network and arranged to control packet flow over that link, said method comprising the steps of, at a call server:
    (i) receiving a call admission request from an originating packet media endpoint, said call admission request comprising information about the originating packet media endpoint and a destination packet media endpoint;
    (ii) accessing information about all first middleboxes associated with the originating packet media endpoint and all second middleboxes associated with the destination packet media endpoint, together with information about the amount of available bandwidth on the link associated with each of those middleboxes;
    (iii) determining whether to accept the call admission request on the basis of the accessed information about available bandwidth; and
    (iv) outputting the results of the determination as to whether to accept the call admission request.
  6. 6. A method as claimed in claim 5 wherein said step (iii) of determining comprises determining whether to accept the call admission request on the basis of the accessed information about available bandwidth together with information about bandwidth requirements for the call.
  7. 7. A method as claimed in claim 5 which further comprises determining whether all the first middleboxes are the same as all the second middleboxes and accepting the call admission request in such cases.
  8. 8. A method as claimed in claim 5 which comprises identifying which of the first middleboxes are not also second middleboxes and vice versa, and wherein said step (iii) of determining whether to accept the call admission request is made on the basis of accessed information about available bandwidth only for links associated with those identified middleboxes
  9. 9. A method as claimed in claim 5 wherein said communications network is selected from an internet protocol communications network and a voice over asynchronous transfer node communications network.
  10. 10. A method as claimed in claim 5 wherein said originating packet media endpoint is selected from a media gateway and an internet protocol endpoint.
  11. 11. A method as claimed in claim 5 wherein said information about bandwidth requirements for the call comprises session description protocol (SDP) information received from both the originating and destination packet media endpoints.
  12. 12. A method as claimed in claim 5 wherein said information about bandwidth requirements for the call comprises information about one or more codecs to be used in the call.
  13. 13. A method as claimed in claim 5 wherein said call is a conference call to be established using a conferencing service in the communications network.
  14. 14. A method as claimed in claim 5 wherein said communications network comprises two or more call servers, and wherein said method further comprises: receiving said call admission request at an origination call server associated with the origination packet media endpoint and determining whether a destination call server, associated with the destination packet media endpoint is the same as the origination call server.
  15. 15. A method as claimed in claim 14 wherein said determination indicates that the destination call server and the origination call server are different and in that case, allowing the origination and destination packet media endpoints to negotiate as to a codec to be used for the call and to send information about that codec to both the origination and destination call servers.
  16. 16. A method as claimed in claim 15 wherein both the origination and destination call servers determine an indication of bandwidth requirements for the call based on the codec information.
  17. 17. A method as claimed in claim 16 wherein for all middleboxes associated with the origination packet media endpoint, the origination call server accesses information about available bandwidth and for all middleboxes associated with the destination packet media endpoint, the destination call server accesses information about available bandwidth.
  18. 18. A method as claimed in claim 17 wherein the destination call server and the origination call server determine whether to accept the call on the basis of the information about available bandwidth.
  19. 19. A method as claimed in claim 5 wherein if the call request is refused, instructions are sent to the origination packet media endpoint to provide a refusal indication to a calling party terminal which initiated the call request.
  20. 20. A method as claimed in claim 5 wherein if the call request is accepted, the database of middlebox information is updated with information about the call and updated again when that call ends.
  21. 21. A method as claimed in claim 5 wherein one or more of said middleboxes are arranged to perform call admission control themselves under MIDCOM protocol control.
  22. 22. A communications network comprising at least one call server as claimed in claim 1.
  23. 23. A communications network as claimed in claim 22 and wherein every originating and every destination packet media endpoint connected to a particular middlebox is controlled by the same call server.
  24. 24. A computer program arranged to control a call server such that the method of claim 5 is carried out.
  25. 25. A computer program as claimed in claim 24 which is stored on a computer readable medium.
US10034521 2001-12-28 2001-12-28 Admissions control in a connectionless communications network Abandoned US20030123388A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10034521 US20030123388A1 (en) 2001-12-28 2001-12-28 Admissions control in a connectionless communications network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10034521 US20030123388A1 (en) 2001-12-28 2001-12-28 Admissions control in a connectionless communications network
US11355640 US7397763B2 (en) 2001-12-28 2006-02-16 Admissions control in a connectionless communications network

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11355640 Continuation US7397763B2 (en) 2001-12-28 2006-02-16 Admissions control in a connectionless communications network

Publications (1)

Publication Number Publication Date
US20030123388A1 true true US20030123388A1 (en) 2003-07-03

Family

ID=21876924

Family Applications (2)

Application Number Title Priority Date Filing Date
US10034521 Abandoned US20030123388A1 (en) 2001-12-28 2001-12-28 Admissions control in a connectionless communications network
US11355640 Active 2022-05-02 US7397763B2 (en) 2001-12-28 2006-02-16 Admissions control in a connectionless communications network

Family Applications After (1)

Application Number Title Priority Date Filing Date
US11355640 Active 2022-05-02 US7397763B2 (en) 2001-12-28 2006-02-16 Admissions control in a connectionless communications network

Country Status (1)

Country Link
US (2) US20030123388A1 (en)

Cited By (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040192318A1 (en) * 2003-02-27 2004-09-30 Interdigital Technology Corporation Method of optimizing an implementation of fast-dynamic channel allocation call admission control in radio resource management
US20040218578A1 (en) * 2003-03-20 2004-11-04 Interdigital Technology Corporation Method of fast dynamic channel allocation call admission control for radio link addition in radio resource management
US20040255285A1 (en) * 2003-02-27 2004-12-16 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation escape mechanism in radio resource management
US20040258036A1 (en) * 2003-02-27 2004-12-23 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation background interference reduction procedure in radio resource management
US20050002506A1 (en) * 2003-07-02 2005-01-06 Doug Bender System and method for routing telephone calls over a voice and data network
US20050009533A1 (en) * 2003-06-17 2005-01-13 Mathilde Benveniste Quality-of-service and call admission control
US20050026623A1 (en) * 2003-04-17 2005-02-03 Interdigital Technology Corporation Method for implementing fast-dynamic channel allocation call admission control for radio link reconfiguration in radio resource management
US20050074012A1 (en) * 2003-10-06 2005-04-07 Garakani Mehryar Khalili Adaptive call admission control for calls handled over a compressed clear channel
US20050083922A1 (en) * 2003-10-21 2005-04-21 Nec Corporation Network, server apparatus, IP corresponding terminal device, and speech-quality control method used in the same
US20050140349A1 (en) * 2003-12-31 2005-06-30 Ho Duc V. Apparatus and method for managing voltage buses
WO2005062558A1 (en) * 2003-12-22 2005-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Control of mobile packet streams
WO2005086964A2 (en) * 2004-03-11 2005-09-22 I2Telecom International, Inc. DYNAMICALLY ADAPTING THE TRANSMISSION RATE OF PACKETS IN REAL-TIME VoIP COMMUNICATIONS TO THE AVAILABLE BANDWIDTH
US20060002297A1 (en) * 2004-07-01 2006-01-05 Allan Sand Flow admission control in an IP network
US20060031393A1 (en) * 2004-01-28 2006-02-09 Cooney John M System and method of binding a client to a server
US20060034296A1 (en) * 2004-08-16 2006-02-16 I2 Telecom International, Inc. System and method for sharing an IP address
US20060088025A1 (en) * 2004-10-20 2006-04-27 Robb Barkley Portable VoIP service access module
US20060099933A1 (en) * 2004-06-16 2006-05-11 Avaya Technology Llc Call admission control of a shared-access resource during a handover
US20060116128A1 (en) * 2004-06-16 2006-06-01 Avaya Technology Llc Call admission control of shared-access resources through a call-handling server
US20060153076A1 (en) * 2001-12-28 2006-07-13 Patrick Bradd Admissions control in a connectionless communications network
US20060233183A1 (en) * 2005-04-18 2006-10-19 Santera Systems, Inc. Methods, systems, and computer program products for dynamic blocking and unblocking of media over packet resources
DE102005036298B3 (en) * 2005-08-02 2006-12-14 Siemens Ag Transmission mode selecting method for use over communication network, involves transmitting selected modes to call control and initiating further selection of mode, where transmission of user data is performed using further selected mode
US20060280162A1 (en) * 2005-06-09 2006-12-14 Sbc Knowledge Ventures, L.P. Proactive congestion control scheme for VoIP traffic on IP routers
US20070104185A1 (en) * 2005-11-10 2007-05-10 Edward Walter Voice over internet protocol codec adjustment
US20080080414A1 (en) * 2006-10-02 2008-04-03 Pascal Thubert Backhaul-level call admission control for a wireless mesh network
WO2008085753A2 (en) * 2006-12-27 2008-07-17 Sr Télécom & Co, S.E.C. Air link bandwidth allocation for voice over ip communications
US7411905B1 (en) * 2003-09-05 2008-08-12 Sprint Communications Company L.P. Segmented IP backbone network access
EP1976204A1 (en) * 2007-03-27 2008-10-01 NEC Corporation Congestion control system, service edge node, guidance server, congestion control method, program therefor, and recording medium recorded therewith
US20080239957A1 (en) * 2003-07-07 2008-10-02 Nobuyuki Tokura Ransmission Capacity Allocation Method, Communications Network, and Network Resource Management Device
WO2008151532A1 (en) 2007-06-08 2008-12-18 Huawei Technologies Co., Ltd. Method for licit monitoring and device thereof
US7480283B1 (en) * 2002-03-26 2009-01-20 Nortel Networks Limited Virtual trunking over packet networks
US7643414B1 (en) * 2004-02-10 2010-01-05 Avaya Inc. WAN keeper efficient bandwidth management
EP2234328A1 (en) * 2007-12-20 2010-09-29 ZTE Corporation Processing method for resource request in ngn
US7957401B2 (en) 2002-07-05 2011-06-07 Geos Communications, Inc. System and method for using multiple communication protocols in memory limited processors
US20110273984A1 (en) * 2002-06-10 2011-11-10 Qualcomm Incorporated Packet Flow Processing in a Communication System
CN101356784B (en) 2006-05-09 2012-09-12 西门子企业通讯有限责任两合公司 Method, network agent and bandwidth broker for managing the available bandwidth for connections between terminals in a packet-oriented communication network
EP2536073A1 (en) * 2011-06-13 2012-12-19 Juniper Networks, Inc. Prioritizing Lawful Intercept Sessions
US20130170501A1 (en) * 2011-12-28 2013-07-04 Futurewei Technologies, Inc. Service Router Architecture
US8504048B2 (en) 2007-12-17 2013-08-06 Geos Communications IP Holdings, Inc., a wholly owned subsidiary of Augme Technologies, Inc. Systems and methods of making a call
US8804758B2 (en) 2004-03-11 2014-08-12 Hipcricket, Inc. System and method of media over an internet protocol communication
RU2611969C2 (en) * 2011-07-08 2017-03-01 Майкрософт Корпорейшн Communication system for communication session establishing in real time

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7899170B2 (en) * 2005-04-28 2011-03-01 Apple Inc. Multi-participant conference setup
US9497229B2 (en) * 2007-05-16 2016-11-15 At&T Intellectual Property I, L.P. Methods and apparatus to manage internet protocol (IP) multimedia subsystem (IMS) network capacity
US8418194B2 (en) 2007-08-31 2013-04-09 Centurylink Intellectual Property Llc System and method for dynamic bandwidth allocation
US8355486B2 (en) 2007-10-31 2013-01-15 Centurylink Intellectual Property Llc System and method for inbound call billing
US7782884B2 (en) 2008-07-07 2010-08-24 Embarq Holdings Company, Llc System and method for adjusting bandwidth based on a time of day profile
US9467308B2 (en) * 2008-08-01 2016-10-11 At&T Intellectual Property I, L.P. Methods and apparatus to control synchronization in voice over internet protocol networks after catastrophes
US8340292B1 (en) 2010-04-01 2012-12-25 Sprint Communications Company L.P. Lawful intercept management by an authorization system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6798786B1 (en) * 1999-06-07 2004-09-28 Nortel Networks Limited Managing calls over a data network
US6907004B1 (en) * 2000-10-31 2005-06-14 Cisco Technology, Inc. Method and system for manual admission control with user options

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030123388A1 (en) * 2001-12-28 2003-07-03 Patrick Bradd Admissions control in a connectionless communications network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6798786B1 (en) * 1999-06-07 2004-09-28 Nortel Networks Limited Managing calls over a data network
US6907004B1 (en) * 2000-10-31 2005-06-14 Cisco Technology, Inc. Method and system for manual admission control with user options

Cited By (97)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060153076A1 (en) * 2001-12-28 2006-07-13 Patrick Bradd Admissions control in a connectionless communications network
US7397763B2 (en) * 2001-12-28 2008-07-08 Nortel Networking Llp Admissions control in a connectionless communications network
US7480283B1 (en) * 2002-03-26 2009-01-20 Nortel Networks Limited Virtual trunking over packet networks
US7944817B1 (en) 2002-03-26 2011-05-17 Nortel Networks Limited Hierarchical virtual trunking over packet networks
US8942168B2 (en) * 2002-06-10 2015-01-27 Qualcomm Incorporated Packet flow processing in a communication system
US20110273984A1 (en) * 2002-06-10 2011-11-10 Qualcomm Incorporated Packet Flow Processing in a Communication System
US7957401B2 (en) 2002-07-05 2011-06-07 Geos Communications, Inc. System and method for using multiple communication protocols in memory limited processors
US7212826B2 (en) 2003-02-27 2007-05-01 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation escape mechanism in radio resource management
US20040255285A1 (en) * 2003-02-27 2004-12-16 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation escape mechanism in radio resource management
US20040258036A1 (en) * 2003-02-27 2004-12-23 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation background interference reduction procedure in radio resource management
US7130637B2 (en) * 2003-02-27 2006-10-31 Interdigital Technology Corporation Method for implementing fast dynamic channel allocation background interference reduction procedure in radio resource management
US20040192318A1 (en) * 2003-02-27 2004-09-30 Interdigital Technology Corporation Method of optimizing an implementation of fast-dynamic channel allocation call admission control in radio resource management
US7107060B2 (en) * 2003-02-27 2006-09-12 Interdigital Technology Corporation Method of optimizing an implementation of fast-dynamic channel allocation call admission control in radio resource management
US20040218578A1 (en) * 2003-03-20 2004-11-04 Interdigital Technology Corporation Method of fast dynamic channel allocation call admission control for radio link addition in radio resource management
US7136656B2 (en) * 2003-03-20 2006-11-14 Interdigital Technology Corporation Method of fast dynamic channel allocation call admission control for radio link addition in radio resource management
US7110771B2 (en) * 2003-04-17 2006-09-19 Interdigital Technology Corporation Method for implementing fast-dynamic channel allocation call admission control for radio link reconfiguration in radio resource management
US20050026623A1 (en) * 2003-04-17 2005-02-03 Interdigital Technology Corporation Method for implementing fast-dynamic channel allocation call admission control for radio link reconfiguration in radio resource management
US8223637B2 (en) * 2003-06-17 2012-07-17 Avaya Inc. Quality-of-service and call admission control
US20050009533A1 (en) * 2003-06-17 2005-01-13 Mathilde Benveniste Quality-of-service and call admission control
US20090323920A1 (en) * 2003-07-02 2009-12-31 I2 Telecom International, Inc. System and methods to route calls over a voice and data network
US20050002506A1 (en) * 2003-07-02 2005-01-06 Doug Bender System and method for routing telephone calls over a voice and data network
US8379634B2 (en) 2003-07-02 2013-02-19 Augme Technologies, Inc. System and methods to route calls over a voice and data network
US8792479B2 (en) 2003-07-02 2014-07-29 Hipcricket, Inc. System and methods to route calls over a voice and data network
US7606217B2 (en) 2003-07-02 2009-10-20 I2 Telecom International, Inc. System and method for routing telephone calls over a voice and data network
US20080239957A1 (en) * 2003-07-07 2008-10-02 Nobuyuki Tokura Ransmission Capacity Allocation Method, Communications Network, and Network Resource Management Device
US7411905B1 (en) * 2003-09-05 2008-08-12 Sprint Communications Company L.P. Segmented IP backbone network access
WO2005036840A2 (en) * 2003-10-06 2005-04-21 Cisco Technology, Inc. Adaptive call admission control for calls handled over a compressed clear channel
US7369559B2 (en) 2003-10-06 2008-05-06 Cisco Technology Inc. Adaptive call admission control for calls handled over a compressed clear channel
US20050074012A1 (en) * 2003-10-06 2005-04-07 Garakani Mehryar Khalili Adaptive call admission control for calls handled over a compressed clear channel
WO2005036840A3 (en) * 2003-10-06 2005-06-23 Cisco Tech Ind Adaptive call admission control for calls handled over a compressed clear channel
US20050083922A1 (en) * 2003-10-21 2005-04-21 Nec Corporation Network, server apparatus, IP corresponding terminal device, and speech-quality control method used in the same
US7778195B2 (en) * 2003-10-21 2010-08-17 Nec Infrontia Corporation Network, server apparatus, IP corresponding terminal device, and speech-quality control method used in the same
US8155116B2 (en) 2003-12-22 2012-04-10 Telefonaktiebolaget Lm Ericsson (Publ) Control of mobile packet streams
US20070286185A1 (en) * 2003-12-22 2007-12-13 Anders Eriksson Control of Mobile Packet Streams
WO2005062558A1 (en) * 2003-12-22 2005-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Control of mobile packet streams
US20050140349A1 (en) * 2003-12-31 2005-06-30 Ho Duc V. Apparatus and method for managing voltage buses
US8606874B2 (en) 2004-01-28 2013-12-10 Hipcricket, Inc. System and method of binding a client to a server
US9401974B2 (en) 2004-01-28 2016-07-26 Upland Software Iii, Llc System and method of binding a client to a server
US7676599B2 (en) 2004-01-28 2010-03-09 I2 Telecom Ip Holdings, Inc. System and method of binding a client to a server
US20060031393A1 (en) * 2004-01-28 2006-02-09 Cooney John M System and method of binding a client to a server
US7643414B1 (en) * 2004-02-10 2010-01-05 Avaya Inc. WAN keeper efficient bandwidth management
WO2005086964A3 (en) * 2004-03-11 2006-10-26 I2Telecom International Inc DYNAMICALLY ADAPTING THE TRANSMISSION RATE OF PACKETS IN REAL-TIME VoIP COMMUNICATIONS TO THE AVAILABLE BANDWIDTH
US8335232B2 (en) 2004-03-11 2012-12-18 Geos Communications IP Holdings, Inc., a wholly owned subsidiary of Augme Technologies, Inc. Method and system of renegotiating end-to-end voice over internet protocol CODECs
US20100238834A9 (en) * 2004-03-11 2010-09-23 I2Telecom International, Inc. System and method of voice over internet protocol communication
US7460480B2 (en) 2004-03-11 2008-12-02 I2Telecom International, Inc. Dynamically adapting the transmission rate of packets in real-time VoIP communications to the available bandwidth
US8842568B2 (en) 2004-03-11 2014-09-23 Hipcricket, Inc. Method and system of renegotiating end-to-end voice over internet protocol CODECs
US8804758B2 (en) 2004-03-11 2014-08-12 Hipcricket, Inc. System and method of media over an internet protocol communication
US20090067341A1 (en) * 2004-03-11 2009-03-12 I2Telecom International, Inc. System and method of voice over internet protocol communication
WO2005086964A2 (en) * 2004-03-11 2005-09-22 I2Telecom International, Inc. DYNAMICALLY ADAPTING THE TRANSMISSION RATE OF PACKETS IN REAL-TIME VoIP COMMUNICATIONS TO THE AVAILABLE BANDWIDTH
US20060099933A1 (en) * 2004-06-16 2006-05-11 Avaya Technology Llc Call admission control of a shared-access resource during a handover
US8665714B2 (en) 2004-06-16 2014-03-04 Avaya Inc. Call admission control of shared-access resources through a call-handling server
US20060116128A1 (en) * 2004-06-16 2006-06-01 Avaya Technology Llc Call admission control of shared-access resources through a call-handling server
US20120087241A1 (en) * 2004-07-01 2012-04-12 Rockstar Bidco, LP Flow admission control in an ip network
US8081571B2 (en) * 2004-07-01 2011-12-20 Rockstar Bidco, LP Flow admission control in an IP network
US7684322B2 (en) * 2004-07-01 2010-03-23 Nortel Networks Limited Flow admission control in an IP network
US9172648B2 (en) 2004-07-01 2015-10-27 RPX Clearinghouse, LLC Flow admission control in an IP network
US20060002297A1 (en) * 2004-07-01 2006-01-05 Allan Sand Flow admission control in an IP network
US20100177636A1 (en) * 2004-07-01 2010-07-15 Allan Sand Flow Admission Control in an IP Network
US8908509B2 (en) * 2004-07-01 2014-12-09 Rockstar Consortium Us Lp Flow admission control in an IP network
US7782878B2 (en) 2004-08-16 2010-08-24 I2Telecom Ip Holdings, Inc. System and method for sharing an IP address
US20060034296A1 (en) * 2004-08-16 2006-02-16 I2 Telecom International, Inc. System and method for sharing an IP address
US20070248081A1 (en) * 2004-10-20 2007-10-25 I2Telecom International, Inc. Portable VoIP Service Access Module
US7336654B2 (en) 2004-10-20 2008-02-26 I2Telecom International, Inc. Portable VoIP service access module
US20060088025A1 (en) * 2004-10-20 2006-04-27 Robb Barkley Portable VoIP service access module
US20080025291A1 (en) * 2004-10-20 2008-01-31 I2 Telecom International, Inc. Portable VoIP Service Access Module
US7613111B2 (en) * 2005-04-18 2009-11-03 Santera Systems, Llc Methods, systems, and computer program products for dynamic blocking an unblocking of media over packet resources
US20060233183A1 (en) * 2005-04-18 2006-10-19 Santera Systems, Inc. Methods, systems, and computer program products for dynamic blocking and unblocking of media over packet resources
US20060280162A1 (en) * 2005-06-09 2006-12-14 Sbc Knowledge Ventures, L.P. Proactive congestion control scheme for VoIP traffic on IP routers
US7773503B2 (en) 2005-06-09 2010-08-10 At&T Intellectual Property I, L.P. Proactive congestion control scheme for VoIP traffic on IP routers
DE102005036298B3 (en) * 2005-08-02 2006-12-14 Siemens Ag Transmission mode selecting method for use over communication network, involves transmitting selected modes to call control and initiating further selection of mode, where transmission of user data is performed using further selected mode
US9350784B2 (en) 2005-08-02 2016-05-24 Unify Gmbh & Co. Kg Method and communication system for selecting a transmission mode for transmitting payload data
US8908684B2 (en) 2005-08-02 2014-12-09 Unify Gmbh & Co. Kg Method and communication system for selecting a transmission mode for transmitting payload data
US7738368B2 (en) 2005-11-10 2010-06-15 At&T Intellectual Property I, L.P. Voice over internet protocol codec adjustment
US20070104185A1 (en) * 2005-11-10 2007-05-10 Edward Walter Voice over internet protocol codec adjustment
CN101356784B (en) 2006-05-09 2012-09-12 西门子企业通讯有限责任两合公司 Method, network agent and bandwidth broker for managing the available bandwidth for connections between terminals in a packet-oriented communication network
US7822064B2 (en) * 2006-10-02 2010-10-26 Cisco Technology, Inc. Backhaul-level call admission control for a wireless mesh network
US20080080414A1 (en) * 2006-10-02 2008-04-03 Pascal Thubert Backhaul-level call admission control for a wireless mesh network
WO2008085753A2 (en) * 2006-12-27 2008-07-17 Sr Télécom & Co, S.E.C. Air link bandwidth allocation for voice over ip communications
WO2008085753A3 (en) * 2006-12-27 2008-11-20 Sr Telecom & Co S E C Air link bandwidth allocation for voice over ip communications
US8345556B2 (en) 2007-03-27 2013-01-01 Nec Corporation Congestion control system, service edge node, guidance server, congestion control method, program therefor, and recording medium recorded therewith
EP1976204A1 (en) * 2007-03-27 2008-10-01 NEC Corporation Congestion control system, service edge node, guidance server, congestion control method, program therefor, and recording medium recorded therewith
US20080239964A1 (en) * 2007-03-27 2008-10-02 Haruo Mitsutake Congestion control system, service edge node, guidance server, congestion control method, program therefor, and recording medium recorded therewith
EP2157804A1 (en) * 2007-06-08 2010-02-24 Huawei Technologies Co., Ltd. Method for licit monitoring and device thereof
US20100080127A1 (en) * 2007-06-08 2010-04-01 Yu Yin Interception method and device thereof
WO2008151532A1 (en) 2007-06-08 2008-12-18 Huawei Technologies Co., Ltd. Method for licit monitoring and device thereof
EP2157804A4 (en) * 2007-06-08 2011-11-16 Huawei Tech Co Ltd Method for licit monitoring and device thereof
US8504048B2 (en) 2007-12-17 2013-08-06 Geos Communications IP Holdings, Inc., a wholly owned subsidiary of Augme Technologies, Inc. Systems and methods of making a call
US9276965B2 (en) 2007-12-17 2016-03-01 Hipcricket, Inc. Systems and methods of making a call
US8526304B2 (en) 2007-12-20 2013-09-03 Zte Corporation Processing method for resource request in NGN
EP2234328A4 (en) * 2007-12-20 2012-10-10 Zte Corp Processing method for resource request in ngn
EP2234328A1 (en) * 2007-12-20 2010-09-29 ZTE Corporation Processing method for resource request in ngn
US20100304775A1 (en) * 2007-12-20 2010-12-02 Zte Corporation Processing method for resource request in ngn
EP2536073A1 (en) * 2011-06-13 2012-12-19 Juniper Networks, Inc. Prioritizing Lawful Intercept Sessions
US8601118B2 (en) 2011-06-13 2013-12-03 Juniper Networks, Inc. Prioritizing lawful intercept sessions
RU2611969C2 (en) * 2011-07-08 2017-03-01 Майкрософт Корпорейшн Communication system for communication session establishing in real time
US20130170501A1 (en) * 2011-12-28 2013-07-04 Futurewei Technologies, Inc. Service Router Architecture
US9838308B2 (en) * 2011-12-28 2017-12-05 Futurewei Technologies, Inc. Improving the architecture of middleboxes or service routers to better consolidate diverse functions

Also Published As

Publication number Publication date Type
US7397763B2 (en) 2008-07-08 grant
US20060153076A1 (en) 2006-07-13 application

Similar Documents

Publication Publication Date Title
US7586899B1 (en) Methods and apparatus providing an overlay network for voice over internet protocol applications
US7209439B2 (en) Pool-based resource management in a data network
US6714987B1 (en) Architecture for an IP centric distributed network
US7069337B2 (en) Policy-based synchronization of per-class resources between routers in a data network
US5134610A (en) Network transit prevention
US7516198B1 (en) Arrangement for providing content-based quality of service for a service flow based on parsing XML tags detected from a server response to a client request
US6574335B1 (en) Method for simulating a ring back for a call between parties in different communication networks
US6577718B1 (en) Method for call forwarding without hairpinning and with split billing
US7380011B2 (en) Methods and systems for per-session network address translation (NAT) learning and firewall filtering in media gateway
US7571238B1 (en) Authorizing communication services
US20030028806A1 (en) Dynamic allocation of ports at firewall
US6529499B1 (en) Method for providing quality of service for delay sensitive traffic over IP networks
US20050047340A1 (en) Technique for end-to-end admission control of real-time packet flows
US7013338B1 (en) Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US20030120135A1 (en) Method for remote medical consultation and care
US20020194362A1 (en) Edge-based per-flow QoS admission control in a data network
US6714515B1 (en) Policy server and architecture providing radio network resource allocation rules
US20040109414A1 (en) Method of providing differentiated service based quality of service to voice over internet protocol packets on router
US6587433B1 (en) Remote access server for multiple service classes in IP networks
US7151772B1 (en) Method for performing lawfully-authorized electronic surveillance
US7142532B2 (en) System and method for improving communication between a switched network and a packet network
US20020114274A1 (en) Packet based network for supporting real time applications
US20020181462A1 (en) System and method for providing end-to-end quality of service (QoS) across multiple internet protocol (IP) networks
US6324279B1 (en) Method for exchanging signaling messages in two phases
US20070133563A1 (en) Service Parameter Interworking Method

Legal Events

Date Code Title Description
AS Assignment

Owner name: NORTEL NETWORKS LIMITED, CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BRADD, PATRICK;REEL/FRAME:012433/0766

Effective date: 20011220