WO1996011551A1

WO1996011551A1 - Communications traffic management arrangement

Info

Publication number: WO1996011551A1
Application number: PCT/GB1995/002399
Authority: WO
Inventors: Gillian Holmes
Original assignee: British Telecommunications Public Limited Company
Priority date: 1994-10-10
Filing date: 1995-10-10
Publication date: 1996-04-18
Also published as: AU3615095A; CA2202282A1; GB9707049D0; GB2308274A; NZ293663A; EP0787411A1

Abstract

An overflow service is provided in a virtual private network (VPN). Calls between private branch exchanges (1, 2) will be switched at a Service Switching Point (3) under the control of a Service Control Point (4). If the capacity of the VPN is already fully in use, then a further call attempt will trigger a congestion message. The Service Switching Point responds to a congestion message by routing the further call attempt onto overflow capacity, not normally allocated to the VPN. A maximum overflow capacity can be set, in accordance with a service level agreement between the network operator and the VPN customers, for instance by counting the number of re-route attempts. An advantageous embodiment provides a private branch exchange with a 'hunt' group of lines for giving access to the network for a user. This provides a simple way of determining when capacity in the VPN is not available to provide a requested connection to a user.

Description

COMMUNICATIONS TRAFFIC MANAGEMENT ARRANGEMENT

The present invention relates to traffic management arrangements in communications, and finds particular application in virtual private networks. In a virtual private network, a customer is allocated communications capacity from a larger communications network, under the control of software. That is, part of a large communications network is allocated to the customer simply by a question of network and service management. There are no physically dedicated communication lines permanently associated with that customer. The capacity allocated to the customer may be allocated in accordance with a service level agreement or other contractual relationship. A particular advantage of virtual networks is that, if the customer uses up their allocated capacity, it is possible to offer them additional capacity from the larger network to carry overflow traffic. Relevant conditions for this facility, which may for instance be limited to particular users of a customer, can be set out in the service level agreement.

In order to provide overflow capacity, it is necessary to provide a mechanism which will redirect call traffic when the allocated capacity is exceeded. In order to trigger that redirection, it is possible to put counters in transmission switches of the network which count calls in progress and thus will detect when the allocated capacity is reached. This, however, is a relatively expensive solution.

According to a first aspect of the present invention, there is provided a virtual communications network, comprising allocated traffic-carrying capacity together with service switching and control means, for providing one or more services, selected from an available set of services, to a customer, the available set of services including an overflow service which operates to route traffic by means of traffic-carrying capacity not allocated to the virtual network in the event that capacity is not available in the virtual network, wherein the overflow service is triggered by a response to an attempt to route traffic via the virtual network. The response might be for instance a congestion message, or "busy" indication.

It is possible, using a preferred embodiment of the present invention, to avoid the use of counters to monitor the capacity of a virtual network which is in current use. Instead of counting all "calls in progress", or equivalent traffic instances, traffic intended for the virtual network can simply be routed via the virtual network until "congestion" arises, or a "busy" indicator, whereafter traffic is routed alternatively. The virtual network will have been allocated traffic-carrying capacity out of a larger overall network capacity and the most convenient overflow capacity will then be obtained via the larger network.

The relevant equipment can be provided in a relatively simple manner by means of technology now in use for communications networks, particularly where a network has an "Intelligent Network" (IN) type of architecture. In networks provided in the past for use in public communications, such as the public switched telephone networks (PSTNs) run by state utilities, the transmission switches in a network have been able to recognise a call destination for an incoming call, route it appropriately, and can usually perform some traffic management such as providing secondary routeing to the destination if a primary route to that destination is not available. In an IN type of architecture, considerably more sophisticated call processing can be provided, the best known type probably being that based on number translation in which an originally called number is substituted by another number determined for instance by a service profile associated with a customer. This can mean for instance that an incoming call can be routed differently at different times of day, or that the incoming call is routed to a local destination determined by the origin of the incoming call.

In the type of IN architecture currently in use, trigger tables are used in association with the transmission switches to determine whether the dialled destination number of an incoming call needs traditional or IN call processing. If it is a call of the old PSTN type, the switch applies traditional routeing to set up a connection across the transmission network to the called destination. If however the call is of an IN type, requiring more sophisticated call processing, then it will be recognised by means of the trigger tables and the more sophisticated call processing is brought into play. This type of technology is described in a special report published in Telephone Engineer & Management, entitled "The Promise of Intelligent Networks", by Warren G Bender, dated 1 February 1 989. A more recent description was published in the IEE Review in March 1 994, called "Putting Thought Into Networks", by Simon Glynn.

IN architectures provide intelligence, i.e. decision-making software, elsewhere than embedded in the transmission switches of a network and can be particularly flexible in terms of the provision and management of services.

It is by means of an IN architecture that virtual networks can be provided. This is discussed in the IEE Review article referenced above. A call to a destination in a virtual network will be recognised as requiring IN call processing and dealt with accordingly. That is, it will not only be routed appropriately within the virtual network but any other service to be provided within the virtual network will be provided by means of the IN infrastructure.

It is in this context that an overflow service according to an embodiment of the present invention might be provided. It may further be the case that overflow traffic is charged at a higher rate to the customer, in accordance with the service level agreement. It may also be the case, in embodiments of the present invention, that the amount of overflow capacity available to a virtual network is limited to a predetermined maximum. From these points of view, therefore, it may be preferable to put in place maximum overflow capacity. This can be implemented by counting the instances of overflow traffic in progress at any one time. If an additional attempt at a traffic instance arises, above the maximum overflow capacity, the service switching and control means might then simply connect an announcement (or other form of message) and clear the attempted traffic instance. Although this involves a counter, it can be installed in the service switching and control means rather than in transmission switches of the network. This is advantageous because there can be significantly fewer service switching and control means provided in relation to a network than transmission switches. Additionally, because only the overflow traffic is counted, the number or capacity of the counters can be kept relatively low.

In an example of a virtual network arrangement in an IN environment, there might be provided service switching points, associated with transmission switches of the larger network, to which the virtual private network (VPN) users gain access via private branch exchanges (PBXs). If a first user, connected by means of a first PBX, wants to make a call across the VPN to a second user, connected by means of a second PBX, then if there is no capacity available in the VPN to do that for some reason, the response to the attempt to route traffic may be a congestion indicator of some sort, generated according to a normal design feature of the network. However, a particularly advantageous embodiment of the present invention arises if a "hunt" group is provided at the PBX. This, in combination with the feature "reroute on busy", provides a particularly simple means for triggering overflow without having to count each traffic instance arising in the VPN.

Hunt groups are known. They are groups of communication lines, for instance trunk (known in the US more commonly as long distance) connections, which have a single allocated number so that the group looks like a single number to the user. Each group may in practice though comprise multiple lines, for instance thirty, which the network hunts through until it reaches a free line on which to make a connection. In the particularly advantageous embodiments of the present invention mentioned above, the SSP associated with the first user will be caused to reroute because the hunt group at the second user's PBX has hunted through all the lines of its group and reached the last without finding an available line.

According to a second aspect of the present invention, there is provided a method of routing communications traffic by means of traffic-carrying capacity, some of which is allocated to a virtual network, comprising the steps of: i) receiving a request for a traffic instance to be carried by the virtual network; ii) attempting to route the traffic instance by means of the virtual network; iii) generating a congestion indicator, or the like, in the event that there is no available capacity in the virtual network to carry the traffic instance; and iv) responding to the congestion indicator by routing the traffic instance by means of capacity which is not allocated to the virtual network.

Again, in preferred embodiments, the congestion indicator or the busy message which causes the overflow routing is preferably generated as a direct response to lack of further capacity in the VPN for the traffic instance requested, at the time when the capacity of the VPN cannot meet the new request for a traffic instance, and not in response to an ongoing monitoring exercise such as counting all traffic instances in the VPN. That is, the overflow is in response to a message returned for instance from a called number PBX, or from the SSP associated with the called number PBX, and not in response to a reference to a data store, for instance in a service control point being used to keep a direct measure of usage in the VPN by counting.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which Figure 1 shows, in block schematic format, elements of a virtual communications network together with overflow capacity provided by a public switched network; and

Figures 2 and 3 show, in two parts, a flow diagram of a process for providing overflow capacity to a virtual communications network customer. It should be noted that the network described below is a switched voice network but networks carrying non-voice traffic are included in the scope, of the present invention.

Referring to Figure 1 , a virtual private communications network will provide communications links between private branch exchanges 1 ,2 of a customer's network. Users of that customer will have terminal equipment connected directly to those private branch exchanges 1 ,2. Calls from a first private branch exchange 1 , coming onto the virtual network, will be switched at a Service Switching Point (SSP) 3, under the control of a Service Control Point (SCP) 4. Each SSP 3,5 comprises a Customer Access Point (CAP) 6, Call Control (CC) 7 and Service Switching Control Function (SSCF) 8. Calls incoming from a customer PBX 1 are received at the SSP 3 via the CAP 6. The SSCF 8 provides a database for call information, updatable in real time, and Call Control 7 provides management functions affecting call set up and routing. The SSP 3 triggers the SCP 4 which translates the dialled number and returns a destination address in the virtual network. The SSP 3 routes the incoming call accordingly.

A network arrangement of this type is known as an "Intelligent Network" • architecture and suitable equipment is known. Non-inventive aspects of suitable equipment are not therefore described in further detail herein. An overflow situation occurs when a call attempting to terminate on a dedicated access line in the virtual private communications network (VPN) meets congestion at the link between the CAP 6 and the terminating customer's equipment, or between a terminating SSP 5 and a remote Customer Access Point if no other routing is available in the VPN. The overflow service then allows a re¬ route to try and ensure that the call is connected. This is "Direct Termination Overflow" (DTO).

DTO comes into operation as follows. In order to establish the service for a particular customer site, at "Day 1 ", a "DTO status" is set, in the SCP 4, against each dialled number that terminates on that particular customer site. If DTO status has been allocated in this way, then for a call incoming to a relevant dedicated access line, the SCP 4 will include a "DTO trigger arming flag" in the calling set up message sent to the SSP 3 with an initial destination address. It will also return the received information of calling party for storage within the SSP 3. On receipt of this, the SSCF 8 within the SSP 3 stores the received information and tells Call Control 7 to monitor for a congestion message. The SSP 3 then tries to route the call.

If there is no available route via the VPN, a congestion message will be received at the originating SSP 3. Call Control detects it and, instead of simply connecting an announcement as it would where DTO is not a service provided, it informs the SSCF 8. The SSCF 8 now packages together its stored information and re-presents the dialled number to the SCP 4, at the same time setting a re- trigger flag to indicate that this is a re-trigger.

The SCP 4 performs a second translation and returns a new destination and "DTO trigger arming flag" and increments a counter.

The process repeats until one of the following occurs:

1 . Call successfully connected,

2. Call re-routes to off-net destination, or

3. Call re-trigger attempts exceed maximum allowed number

In 2 above, the feature will cease at this point as once the call has been handed over to an external carrier there can be no further DTO. In 3 above, the maximum number of re-tries has been exceeded. This is detected by the value of the counter which has been incremented for each re- triggering to the SCP 4. In this case the SCP 4 will instruct the SSP 3 to connect an announcement and clear the call. In the above, the originating SSP 3 receives a congestion message. This may be generated by known means, perhaps using switch technology designed for network management. However, a particularly advantageous arrangement is the use of a hunt group in the PBX, which causes a busy message when all the lines in the group are found to be busy. The VPN then responds in the manner of "reroute on busy". This offers a particularly simple technical solution to providing direct termination overflow for a VPN without having to monitor all the traffic instances in progress on the VPN.

Referring to Figure 2 and 3, the process in operation is as follows. The process goes to start, STEP 201 , in the event of an incoming call. An incoming trunk to the SSP 3 is seized by the PBX 1 , STEP 202, and the SSP 3 receives the destination number, STEP 203, for example 1 1 2233.

The SSP 3 will trigger the SCP 4, STEP 204, sending it the received destination number and details of the originating PBX 1 .

The SCP 4 carries out a privilege check, STEP 205, checking the privileges allowed for the calling user. If the calling user is entitled to the privileges it has requested, the SCP 4 translates the destination number, STEP 206, using any

"time of day/day of week" or origin-dependent factors, and checks any privileges for the called user, STEP 207. If either privilege check fails, then the SSP 3 will return an appropriate message, STEP 21 8, to the calling user. If both privilege checks have been successful, and an overflow feature is available, STEP 208, then the SCP 4 returns a network address to the SSP 3 plus any digits required by the PBX, for example 8000, together with any additional information required by the SSP 3 for routing and a mid-call trigger arm for the overflow feature, STEP 209. If the overflow feature is not available, the SCP 4 simply returns the address and digits, without the mid-call trigger arm, STEP 21 1 .

The SSP 3 will now route the call based on the information received from the SCP 4, STEP 210. That is, it routes the call to a second SSP 5 in the virtual private network. The SSP 3 will also do a check for the mid-call trigger arm for the overflow feature, STEP 212. If the trigger arm is present, the SSP 3 will store all the information originally sent to SCP 4, in the SSCF 8, STEP 213. The SCP 3 will also tell Call Control 7 to monitor for a congestion signal, STEP 214. If there is not a mid-call trigger arm present in the information returned from the SCP 4 to SSP 3, the DTO process goes no further, STEP 219.

The terminating Customer Access Point, or SSP 5, will now look for a trunk to the destination. If a trunk is available, the terminating Customer Access Point, or SSP 5, will return "Called User Answer" and the DTO process comes to a stop STEP 219. If, however, all trunks to the destination are busy, for instance because the last line of a hunt group has been tried and found busy, it will return a congestion message to the SSP 3 which monitors for receipt, STEP 21 5. If a congestion message is received at STEP 21 5, then the SSP 3 goes into the overflow process, (DTO Process Part II) STEP 217.

Referring to Figure 3, when a congestion signal has been received by the SSP 3, the overflow process starts, STEP 301 , with the SSP 3 re-triggering the SCP 4, STEP 302. That is, Call Control detects the congestion signal at the SSP 3 and informs the SSCF 8. The SSCF 8 assembles the stored information and re- sends it to the SCP 4 along with an indication that this is a re-trigger because of overflow. The SCP 4 firsts checks, STEP 306, the number of re-trigger attempts already made, indicated by the counter. If the counter shows that a further re- trigger would exceed the number of overflow attempts allocated, the SCP 4 simply instructs the SSP 3 to send an appropriate message to the calling user, and to clear the call, STEP 307. If however, the number of re-trigger attempts already made is less than the total allocated, the SCP 4 does a re-translation based on the overflow condition, STEP 303, and returns a new destination to the SSP 3, for example public number 456789 8000. At the same time, it increments the counter, STEP 308. In this case, the SSP 3 will now route the call via the Public Switched

Network 9, STEP 304, forwarding the public number. The carrier for the Public Switched Network 9 connects the call to the destination PBX 2, forwarding the extension digits 8000, and "Called User Answer" is returned across the virtual private network, STEP 305. The overflow process then terminates, STEP 21 9.

In the above description, and particularly with reference to Figure 1 , it will be noted that the Service Swithing Control Function (SSCF) 8 which provides call context is not necessarily sited in or with the service switching point. It may alternatively be sited for instance in or with the service control point (SCP) 4.

Inventive aspects of the present invention are set out in the following numbered paragraphs:

1 . A virtual communications network, comprising allocated traffic-carrying capacity together with service switching and control means, for providing one or more services, selected from an available set of services, to a customer, the service or services provided including an overflow service which operates to route traffic by means of capacity not allocated to the virtual network in the event of congestion in the virtual network, wherein the overflow service is triggered by a congestion indicator response to an attempt to route traffic via the virtual network.

2. A virtual communications network according to paragraph 1 wherein the overflow service operates to route traffic by means of the larger network.

3. A virtual communications network according to either one of the preceding paragraphs wherein the congestion indicator response comprises a message generated by a unit comprising switching equipment of the network and returned across the network in response to said attempt.

4. A virtual communications network according to either one of paragraphs 1 or 2 wherein the congestion indicator response comprises a message generated by a service switching point of the network and returned across the network in response to said attempt.

5. A virtual communications network according to either one of paragraphs 1 or 2 wherein the congestion indicator response comprises a message generated by a private branch exchange of the network and returned across the network in response to said attempt. 6. A virtual communications network according to any one of the preceding paragraphs, further comprising monitoring means for monitoring the extent to which traffic has been routed by means of the capacity not allocated to the virtual network. 7. A virtual communications network according to paragraph 6 which further comprises means for setting a maximum overflow capacity such that traffic instances arising when the maximum overflow capacity is already in use will not be routed. 8. A virtual communications network according to either one of paragraphs 6 or 7 wherein the monitoring means comprises a counter in the service switching and control means.

9. A virtual communications network according to any one of the preceding paragraphs wherein said congestion indicator comprises a congestion message returned to the service switching and control means.

10. A virtual communications network according to any one of the preceding paragraphs wherein the service switching and control means includes two or more service switching points and at least one service control point.

1 1 . Communications routing equipment for providing access for a user to a virtual communications network, the equipment comprising a private branch exchange connected directly or indirectly to a service switching point of the network, wherein the service switching point is provided with means for receiving a request from the network to establish a communications connection to said user via the private branch exchange, the private branch exchange is provided with a hunt group of lines for establishing a communications connection to said user by means of the network, and the private branch exchange has means for returning a message to the service switching point when the following conditions are met: i) the private branch exchange has received a request from the service switching point to establish a communications connection to said user; ii) the private branch exchange has found the last line in the hunt group to be busy.

1 2. A method of routing communications traffic by means of traffic-carrying capacity, some of which is allocated to a virtual network, comprising the steps of: i) receiving a request for a traffic instance to be carried by the virtual network; ii) attempting to route the traffic instance by means of the virtual network; iii) generating in the virtual network, in response to said attempt, a congestion indicator in the event that capacity of the virtual network is not available to carry the traffic instance; and iv) responding to a congestion indicator by routing the traffic instance by means of capacity which is not allocated to the virtual network.

1 3. A method according to paragraph 1 2 wherein said attempt to route the traffic instance comprises an attempt by a private branch exchange of the network to route said traffic instance by means of a hunt group to a user's terminal, and said congestion indicator is generated when the last line of the hunt group is found to be busy.

Claims

2. A virtual communications network according to Claim 1 wherein the overflow service operates to route traffic by means of the larger network.

3. A virtual communications network according to either one of the preceding claims wherein the congestion indicator response comprises a message generated by a unit comprising switching equipment of the network and returned across the network in response to said attempt.

4. A virtual communications network according to either one of Claims 1 or 2 wherein the congestion indicator response comprises a message generated by a service switching point of the network and returned across the network in response to said attempt.

5. A virtual communications network according to either one of Claims 1 or 2 wherein the congestion indicator response comprises a message generated by a private branch exchange of the network and returned across the network in response to said attempt.

6. A virtual communications network according to any one of the preceding claims, further comprising monitoring means for monitoring the extent to which traffic has been routed by means of the capacity not allocated to the virtual network.

7. A virtual communications network according to Claim 6 which further comprises means for setting a maximum overflow capacity such that traffic instances arising when the maximum overflow capacity is already in use will not be routed.

8. A virtual communications network according to either one of Claims 6 or 7 wherein the monitoring means comprises a counter in the service switching and control means.

9. A virtual communications network according to any one of the preceding claims wherein said congestion indicator comprises a congestion message returned to the service switching and control means.

10. A virtual communications network according to any one of the preceding Claims wherein the service switching and control means includes two or more service switching points and at least one service control point.

13. A method according to Claim 12 wherein said attempt to route the traffic instance comprises an attempt by a private branch exchange of the network to route said traffic instance by means of a hunt group to a user's terminal, and said congestion indicator is generated when the last line of the hunt group is found to be busy.