Abstract:
Virtual dedicated voice connections between parties to a packet-switched system can be created by reserving capacity for such connections in the packet-switched system. The capacity reservable by any one party is limited to prevent over-subscription of resources in the packet switched. The system incorporates a call admission control processor for controlling access to the packet-switched call routing system such that a voice call attempt is successful only if capacity for such a dedicated connection has previously been reserved. The capacity reserved for the virtual connections is made available for use by other traffic when not required for voice sessions.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is the U.S. national phase of International Application No. PCT/GB2007/003773 filed Oct. 5, 2007, which designates the U.S., and is also a continuation-in-part of U.S. Ser. No. 11/598,230 filed Nov. 13, 2006, the entire contents of both of which are hereby incorporated by reference. 
    
    
     This application is related to the following commonly assigned, copending applications: 
     U.S. patent application Ser. No. 11/489,718 filed Jul. 20, 2006; 
     U.S. patent application Ser. No. 11/489,719 filed Jul. 20, 2006; 
     U.S. patent application Ser. No. 11/594,972 filed Nov. 9, 2006; 
     U.S. patent application Ser. No. 11/594,973 filed Nov. 9, 2006; 
     U.S. patent application Ser. No. 11/598,230 filed Nov. 13, 2006; 
     U.S. patent application Ser. No. 11/702,665 filed Feb. 6, 2007; and 
     U.S. patent application Ser. No. 11/702,669 filed Feb. 6, 2007. 
     BACKGROUND 
     1. Technical Field 
     This invention relates to telecommunications systems, and in particular to the provision of dedicated connections between defined points. 
     Modern telecommunications systems allow almost any telecommunications device to be connected to any other using conventional switched networks (circuit switched or packet switched). 
     2. Related Art 
     Early attempts to integrate voice and data systems relied on carrying digital data over a circuit-switched system initially designed for analogue signals, in particular voice. Conversely, modern packet-switched telecommunications systems, such as those running under the “Internet Protocol”, are configured for digital data, and analogue data, notably voice, has to be adapted to fit the protocol. Voice, in particular, has rather different requirements from those of data. Small values of latency (delay) are much more significant to a human listener than they are to a machine processing incoming data. Jitter—the variability of the delay—is even more significant. Conversely, the amount of redundancy in human speech is such that a human listener can still comprehend a voice signal that has suffered impairment to a much greater degree than would be acceptable in a data signal. 
     Existing “Voice over Internet Protocol” systems have procedures in place to reflect these different priorities, but call quality can still fall below that expected on a switched circuit, in particular because in a packet-switched system, unlike a conventional circuit-switched call, resources are shared and the underlying connection requirements are “best effort”. Contention for resources, for example between a number of simultaneous voice calls, can result in insufficient bandwidth being available to support the call traffic required. In comparison, provided a line is available, a circuit-switched system dedicates capacity dedicated solely to a single connection for the duration it is required. 
     The problems of latency and of contention with other subscribers for bandwidth, mean that dedicated point-to-point links are still preferred for certain applications. Such dedicated point-to-point physical circuits are expensive to provide as they require dedicated infrastructure to be installed over the entire length of the link, and there are few synergies available to reduce the cost of installing several such links. They are also less robust to system failure, and replacement or diversion (whether in an emergency or otherwise) requires major re-installation work. 
     The present invention addresses these issues by providing a method of creating virtual dedicated connections between parties to a packet switched system by populating a session parameter database with parameters for permitted sessions, and controlling access to a packet switched call routing system such that, when a session request is set up between a first party and a second party, the session is connected only if specified parameters of the requested session, including the identities of the first party and the second party, have previously been stored in the session parameter database. 
     BRIEF SUMMARY 
     The packet-switched system preferably operates under the “Internet Protocol” and is either a private or limited-user system: such systems are known as Intranets and Extranets respectively. They have many of the characteristics of the public “Internet”, and indeed usually interface with it, but they make use of dedicated resources and normally have access controls such as “firewall” systems to prevent unauthorised access. 
     Unlike a physical leased line, the capacity on the virtual connections may be made available for use by general traffic when not required for sessions meeting the parameter set. Such use may be subject to limitations, for example on bandwidth, protocols etc. For example it may be limited to non-voice traffic. Moreover, as the virtual dedicated connection is carried over a packet switched system, it is easy to reconfigure should it become necessary, for example because of relocation of either party to the connection, or of any intermediate part of the link. 
     One aspect of the present invention provides call control means for a packet-switching system, comprising a session parameter database, a data entry portal for populating the session parameter database with permitted session parameters, including the identifies of permitted combinations of calling party and called party, and a session admission control process for processing session requests received from calling parties, the session admission control processor comprising means for receiving a request for a first party to set up a session to a second party, data retrieval means for cooperating with the session parameter database to identify whether parameters corresponding to the session request have been stored in the session parameter database, and session connection means for completing the connection if the specified parameters of the requested session have previously been stored in the session parameter database. 
     By establishing in advance the parameters which characterise connections that may be authorised, over-subscription can be avoided. Users may establish more than one session at once, provided that the parameters for each individual session have all been authorised. 
     The capacity reservable by any one party may be limited to prevent over-subscription of the resources in the routing system. To ensure capacity is not reserved unnecessarily, establishment of an authorised session may require the cooperation of both parties. 
     The amount of bandwidth (capacity) reserved for an individual connection may be selected depending on factors such as the quality of the link required, and the speed or other characteristics of the users&#39; terminal equipment, and other parameters such as the coding process to be used in the sessions. 
     A connection may be to a dynamic location—for example connection may be made to a user&#39;s fixed or mobile terminal depending on factors such as time of day of the user&#39;s forwarding settings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       An embodiment of the invention will now be described by way of example only, with reference to the drawings, in which 
         FIG. 1  is a schematic illustration of an installation including a call admission control layer according to the invention. 
         FIG. 2  is a schematic illustration of a user terminal configured to be used with the invention. 
         FIG. 3  is a flow diagram illustrating the process by which capacity may be reserved. 
         FIG. 4  is a flow diagram illustrating the process by which a user may register with the system. 
         FIG. 5  is a flow diagram illustrating the process by which reserved capacity may be used to connect a voice call. 
     
    
    
     DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
     Referring to  FIG. 1 , the system illustrated comprises a registration processor  15  and a session authorisation processor  16 . The registration processor  15  controls access to the system, and the session authorisation processor  16  controls the reservation of capacity. Access to the system for reservation purposes is made by a user terminal  18 ,  19  through a user portal  10 , whilst sessions are set up through a session border controller  17 . (For brevity, the users will be referred to by the same reference numerals as the respective terminals  18 ,  19  they are using). 
     The capacity reservation process will now be discussed, with reference to  FIG. 3 . A session parameter database  13  maintains the details of all the permitted reserved-capacity sessions. It also stores details of the source and destination URIs (universal resource indicator) for each end of the established sessions, together with the sample interval and codecs used. These latter factors determine the capacity (bandwidth) required to maintain a speech-quality link. When a user first subscribes to the system a specified amount of bandwidth is configured (several hundred kilobits/sec), which can be broken down into call slot reservations. 
     Once a user is identified to the system, he may request a virtual reserved-capacity session with another party  19 . The user  18  identifies the other party using a directory facility, for example by email address. This identity is sent by way of the portal  10  to the session authorisation processor  16  (step  33 ) which checks with the session parameter database  13  whether there remains sufficient unallocated capacity to make the new allocation (step  34 ). It should be noted that the assessment is based on the capacity not already allocated to virtual links, and not on the capacity allocated to such links but not currently in use. 
     If sufficient capacity is available—that is to say, sufficient capacity from the user&#39;s allocation remains available, a message is sent to the other party  19  (step  35 ) to request authorisation of this capacity for the new virtual link. The other party may accept such a link, in which case it will be added to the session parameter database  13  (step  36 ). The other party may, instead, decline. This may be done if, for instance, the other party has a large number of such connections established already, leaving insufficient remaining capacity for the newly-requested link without deleting some other reserved link. 
     If the link is accepted, network capacity is reserved in the session parameter database  13  for “Voice over Internet Protocol” (VoIP) sessions between these two parties  18 ,  19 . The data is made accessible to a session admission control processor  12  (step  37 ) so that connections can be made using the reserved capacity, and confirmation sent to both users  18 ,  19  (steps  38 ,  39 ). As this is a virtual connection over a packet switched network, when no such call is in progress the reserved capacity is available for other purposes, such as carrying less time-critical non-voice traffic. The speed with which such traffic can be carried will depend on how much of the capacity reserved for voice links is actually required at any given moment. 
     When capacity is reserved for a dedicated virtual link, a representation of the new link&#39;s availability is generated for display on both users&#39; user displays. In response to the notifications  38 ,  39 . Each user&#39;s terminal  18 ,  19  is configured to facilitate connection to the other&#39;s URI. As shown in  FIG. 2 , this can be done by allocating a button  22  on the control panel of a user device, and an associated indicator light  21 , to the new link. Alternative user interfaces may be used, for example an icon or a pop-up on a computer screen, which can be activated by moving a cursor over it using an user input device such as a computer mouse. As another example, a standard Internet Protocol telephone may be used, one of the “soft keys” and the associated display being configured appropriately. 
     The user terminals are therefore configured to allow a user to readily establish sessions with one or more of the parties with whom capacity has previously been reserved. 
     Registration with the system will now be discussed, with reference to  FIG. 4 . When a user connects to the system he accesses the SBC  17  through his terminal  18 ,  19  (step  30 ). The SBC  10  first corresponds with the authentication processor  15  (step  31 ) which checks the user name against a set of valid site IP addresses stored in the user identity store  11  for that user (step  32 ), and if the user is registering from a valid address, it then performs a password check. This ensures that any user attempting to use the system is indeed the user that he claims to be, and allows the SBC  10  to identify location information, specifically the IP address, currently associated with that user. 
     As shown in  FIG. 5 , when a user  18 , having registered with the system, wishes to establish a voice connection with a party  19  for which a dedicated link has previously been reserved, he operates the control  22  representing the called party, which causes the user terminal  18  to transmit a request  40  to the session border controller (SBC)  17  for a link to be set up to the terminal  19  currently associated with the URI specified in the request. The SBC  17  cooperates with the session admission control processor  12  (step  41 ) to establish this link. The session admission control processor  12  first checks that the parameters of the requested session match parameters in the session parameter database  13  (step  42 ) checks with the location database  14  for the current location (IP address) of the selected counterparty (step  43 ) and with the user identity database  11  to ensure the URIs and current locations of both the calling party and the called party are valid (step  44 ). If these checks are validated, the session admission control processor  12  generates a session initiation attempt  45  to the user terminal  19  corresponding to the current IP address held for the called party. This causes the destination user&#39;s terminal  19  to generate an indication  21  that an incoming session attempt is being made. If the called party wishes to accept the session, he activates the corresponding control  22  on his terminal  19  to transmit an authorisation  46  to the session admission control processor  12  which, in turn, transmits an instruction  47  to the session border controller  17  to establish the link ( 48 ,  49 ). 
     Either party  18 ,  19  may set up a call to the other, irrespective of which party initially reserved the capacity. 
     The session admission control processor  12  is arranged such that no VoIP session can be initiated unless the connection capacity has been previously reserved by the control system  16  and its parameters stored in the session parameter database  13 . When a customer  18  looks for a destination party  19  on the network the lookup process in the SBC  17  directs the user to the session admission control processor  12 , which is configured so that the “voice” class of service can only be accessed this way. 
     The number of connections available to a customer is regulated by the authorisation server  16  to ensure that the total capacity of all the links available to a user  18  do not exceed the available bandwidth. Users can only provision within this authorised capacity. The entries in the database are policed to ensure that the user  18  setting up the call is using his own calling domain, and the target user  19  is always checked and consulted before the call is allowed.