METHOD AND SYSTEM FOR OFF-LOADING DATA TRAFFIC IN A TELEPHONE NETWORK

Abstract: A method and system for off-loading data traffic in a telephone network having an ingress switch switchably connectable to a source of data traffic and a source of voice traffic and having a tandem switch downstream of the ingress switch, so as to re-route the data traffic away from a Public Switched Telephone Network (PSTN) thereby reducing congestion thereon. A digital cross connect based device connected between the ingress and tandem switches allows discrimination between the data traffic and the voice traffic downstream of the ingress switch prior to reaching the tandem switch, and diverts the data traffic to a data network.

Description: Method and system for off-loading data traffic in a telephone network FIELD OF THE INVENTION This invention relates to telephone switching circuits for re-routing Internet calls. REFERENCES Throughout this specification, reference will be made to the following publications which provide a good summary of the current state of the art. [1] "Architectural Solutions to Internet Congestion Based on SS7 and Intelligent Network Capabilities: A Bellcore White Paper ^ (www.accessproducts.com/htm/white5.htm) by Dr. Amir Atai and Dr. James Gordon. [2] Economics of Internet Offload and Voice/ Data Integration - Bellcore White Paper by Dr. James Gordon and Dr. Amir Atai - TM-25927, Issue 1, December 1998. [3] The Internet Engineering Task Force (IETF), which is working on solutions (www.ietf.org). In particular, on October 27, 1997 a 0.1 Version draft was circulated of the Media Gateway Control Protocol - which is expected to become and IETF standard in 1999. [4] The Internet and the Local Telephone Network: Conflicts and Opportunities by: Sian Morgan - IEEE Communications Magazine - January 1998. [5] ADC Newnet - Connect7 product description - www.newnet.com [6] Trillium Digital Systems, Inc. - Signalling System 7 products description - www.trillium.com [7] DGM&S Telecom - SignalWare product description - www.dgms.com [8] Hewlett Packard Company - HP OpenCall SS7 Platform description - Hewlett-Packard Journal, August 1997, Article 7 - www.hp.com [9] Microlegend Tutorial - WWW.microlegend.com/whatss7.htm [10] ISDN by Gary C. Kessler, published 1990 by McGraw-Hill, Inc. [11] Nortel Networks - 1 Meg Modem description - www.nortel.com BACKGROUND OF THE INVENTION The Public switched Telephone Network (PSTN), was designed to carry voice traffic not data. A typical voice call in a circuit-switched network such as the PSTN lasts an average of 3 - 5 minutes, whereas a typical data call, such as an Internet connection, lasts more than 20 minutes. Thus, the increasing proliferation of Internet traffic on the PSTN ties up switch resources as well as interoffice trunks and leads to traffic jams which congest the voice network. Such congestion would obviously be reduced if separate networks were used to convey voice and data traffic. However, the prevalence of the existing PSTN infrastructure as well as the fact that the PSTN provides a ready connection point to the Internet militate against the provision of separate networks. According to current projections and trends, Internet traffic could double in the next three years and this will exacerbate the problem as by far the vast majority of users gain modem access to the Internet via the PSTN, which is already overstretched even as just a voice network. Current proposals to ameliorate the bottleneck are based on a staged migration from the present mode of operation towards some packet network solution, whilst temporarily enhancing the voice network with the addition of more lines and trunks to maintain the required grade of service. Such approaches are highly expensive. In the long term, the cost is likely to be offset by increased revenue to the service providers from data traffic; but in the short term little revenue benefit is to be expected and the temporary patching of the PSTN voice network is not likely to have long term benefit. It would clearly be more economical to find a solution which is based on the existing PSTN network with a minimum of patching. In order to allow all subscribers to interconnect without requiring unduly complex and costly switching arrangements, the PSTN infrastructure is designed based on the implicit assumption that not all subscribers will go "on-line" simultaneously. As shown in Fig. 1, essentially, the PSTN 10 comprises three sets of switches: (i) an ingress switch 11 which is coupled to each subscriber 12 and 12' and facilitates their connection to the network (ii) an egress switch 13 which is coupled to the destination subscribers 14, and (iii) a tandem switch 16, which is used to transfer voice calls from the ingress switch 11 to the egress switch 13. In Fig. 1, the egress switch 13 is also connected to the data network 15, and is very typical of an Internet Service Provider (ISP) Point of Presence (POP). Thus the egress switch 13 is the destination point for the call originating in the ingress switch 11 in the event that the caller wishes to access the Internet. As previously mentioned, between the ingress switch 11 and the egress switch 13, there may be connected one or more tandem switches 16. It is to be understood that each Central Office (CO) switch in the network can act as the ingress switch or the egress switch of a specific call, based on which CO is connected to the caller, and which is connected to the called party or ISP POP. In this simplified diagram, other interconnections are not shown, but it is understood that in some cases, the ingress switch may be the same as the egress switch or that there may be a direct connection between certain ingress and certain egress switches. In general a number of ingress switches are connected to one tandem switch, and a call may pass through more than one tandem switch between the ingress and egress switches. Thus, in Fig. 1, a call originating at a user connected to the ingress switch 11 destined to access a data network such as the Internet, will pass through the ingress switch 11, the tandem switches 16 and the egress switch 13 before being diverted to the data network 15 via a Remote Access Server (RAS) 17. This is unsatisfactory because all three types of switch are loaded throughout the whole duration of the Internet connection: which, as noted, may be very significant. In addition, the data traffic offload is concentrated, or tunneled, to only a few egress switches. These switches easily become overloaded, causing service degradation or even denial. In order to avoid this congestion, off-loading has been proposed whereby data traffic is segregated from voice traffic and re-routed to the ISP and the data network 15 at an earlier stage than the egress switch 13. Fig. 2 shows prior art off loading solutions, in which a Remote Access Server (RAS) is added to the network as a boundary between the PSTN 14, controlled by the SS7 network, and the packet data networks which comprise the Internet. The RAS can be connected to any of the switching points in the network, including the ingress switch 11 or the tandem switch 16, or as in Fig. 1 to the egress switch 13. Between the ingress and egress switches may be connected one or more tandem switches 16 which function rather like the points on a railway track for diverting a call along the correct route to the desired called subscriber. Fig. 2 summarizes two different known approaches to off-loading data traffic from the PSTN to the data network 15. One approach is the use of an RAS 17 as explained above, where the RAS can be connected to any switch in the network, including the ingress switch 11, the tandem switch 16, and of course the egress switch 13 (since, as explained above, in effect each CO switch can be an ingress or egress switch depending on the direction of the call). This is expensive, as each CO requires an RAS for each ISP, as well as dedicated lines from the RAS to each ISP. These lines are underutilized. In addition, if the RAS is placed at the tandem switch, no load is taken off the tandem switch, which is very expensive. Another approach is called pre-switch architecture, in accordance with which, data calls are intercepted prior to hitting the ingress switch and are immediately transferred on to the data network. One example of such an approach is shown, using a Digital Loop Carrier (DLC) 18 connected to the ingress switch 11 via a connection 19, which can carry voice band calls. The DLC 18 is likewise connected to a subscriber 20 via another telephone line 21 which can carry both voice and data. The data is identified by the DSLAM and immediately sent to the data network along a line 21'. while the voice is transferred to the ingress switch 11 via connection 19 to be routed along the regular channels through the tandem and egress switches to the destination 14. Such an approach reduces congestion on the tandem switch 16 and on the egress switch 13 since data packets never reach them. By such means, Internet calls are converted to packet format as early as possible, to eliminate congestion in the following exchanges and trunks in the PSTN 10. Pre-switch architectures, which intercept calls on the line side of ingress switches, have the advantage of totally by-passing the PSTN, including ingress switches. PSTN elements may, however, still be involved to some extent in call-related signaling and billing. However, each ingress switch must have an access to the data network, and for each data carrier (ISP), a means for segregating or billing traffic must be devised. The lines to the data network are also often underutilized, and must be designed to meet peak loads for data traffic. These drawbacks tend to favor post-switch architectures also shown in Fig. 2. In this case, the RAS's 22, 23 and 24 are connected to the data network by dedicated lines 25, 26 and 27 and are respectively collocated with , the ingress switch 11, the tandem switch 16 and the egress switch 13. It is to be noted that of these possible configurations, only where the data is intercepted by RAS 22 and redirected to the data network 15 is there a reduced traffic load on tandem switch 16. Re-directing data after it reaches the tandem switch 16, such as by RAS 23 or RAS 24, is unsatisfactory because it does nothing to offload the tandem switch 16. This means, in effect, that in order to accommodate the anticipated increased future Internet load, such configurations require yet more tandem switch capacity. This significantly adds to the cost of the system because tandem switch capacity is expensive. Furthermore, all these configurations require that the RAS 22, 23 or 25 be connected via a leased dedicated line to the data network which as explained above, is not efficient. If both RAS 22 and RAS 23 are used, as might be needed to handle a number of ISP's, each ingress and tandem switch will require leased lines, leading to waste in terms of underutilized capacity. It is crucial to an appreciation of the present invention that the location in the network at which the congestion resulting from increased Internet traffic is removed, greatly impacts on the economics of the network. This derives partly from the cost differences of the various switching components in the network and partly on account of the different costs involved in changing the infrastructure, such as the cost of leased lines from the RAS to the data network. Thus, the ingress switch 11 multiplexes a large number of subscriber lines to a relatively small number of voice and/or data carriers. In order to accommodate increased Internet traffic, the ingress switch must increase line availability. The connection from the ingress switch to the tandem switch is an inter-exchange carrier between two different exchanges and is consequently expensive. The egress switch 13 does the reverse and therefore must also be equipped with a large number of output trunks each going to a different subscriber. The tandem switch 16 has an almost one-to-one concentration meaning that for every input switch line a corresponding output switch line is required. This capacity is expensive to add. Yet a further important consideration relates to the fact that Internet and voice traffic reach peak congestion at different times of day. Fig. 3 shows graphically typical loading of voice and Internet traffic at different times of day, measured in Erlangs - a standard measure of traffic intensity. It is seen that voice traffic reaches its peak loading at mid-morning and mid-evening whilst Internet traffic reaches its peak loading late at night when there is comparatively little voice traffic. Specifically, the peak loading of both voice and Internet traffic is approximately 0.2 Erlang, whilst owing to the non-overlapping peaks, the combined loading amounts to only 0.3 Erlang. It should be noted that the specific numbers used here are for illustration purposes only - and reference is made to [4] for more detail. In a post-switch architecture wherein voice and data traffic are segregated after the ingress switch, each of the output carrier, or lines, of the ingress switch itself must have a capacity of 0.2 Erlang. Thus, even though the combined traffic on the two outlets 28 and 25' of the ingress switch 11 (shown in Fig. 2) is typically limited to 0.3 Erlang, the capacity of carrier 28 must have 0.2 Erlang and the capacity of carrier 25' must also have 0.2 Erlang to maintain the required grade of service, for a total capacity of 0.4 Erlang. This means that, so far as the carrier expenses are concerned, no saving is achieved by segregating the voice and data traffic immediately after the ingress switch. On the contrary, by segregating the voice and data downstream of the ingress switch, a single set of output carriers thereof handles both voice and data traffic simultaneously and therefore can have an overall capacity of only 0.3 Erlang. It thus emerges that segregating at the ingress switch is actually counter-productive. This drawback would clearly be overcome by segregating the voice and data traffic downstream of the ingress switch. If this is done after the tandem switch, then additional capacity must be added to the tandem switch in order to accommodate the increased data traffic. Bellcore[l] has proposed that the RAS be placed right after the ingress switch and be controlled by the SS7 signaling network. Such a proposal has been implemented by several companies, such as Bay Network, Ascend and Cisco. However, it is not always operationally practical or economical to collocate the RAS with the ingress switch since the ingress switch is often unmanned, and the RAS is provided by the Internet Service Provider whilst the ingress switch belongs to the telephone company. In addition, each ingress switch will require separate RAS's for each ISP, which will be underutilized. In addition, in many cases the leased lines from the RAS to the data network will also be underutilized. Fig. 4 shows an alternative post-switch architecture proposed by Bellcore which, in order to overcome this problem, employs a scaled-down tandem switch 29 called a "skinny tandem". While a pure tandem switch is only designed to transfer calls, the skinny tandem 29 would also have the ability to terminate calls destined to the data network. However, to date, this concept has not found practical realization. The use of a skinny tandem would off-load the data after the ingress switch 11 but before the tandem switch 16 in order to allow the tandem switch 16 to have lower capacity. It would also require that the ingress switch pack the data calls on carriers 30 destined specifically for the skinny tandem 29. This requires added processing for the ingress switches 11. The skinny tandem 29, would however be expensive in that it is designed as a tandem switch with each call being switched from the incoming line to the outgoing destination. The Internet Engineering Task Force, which is working on solutions for Internet problems may be accessed at www.ietf.org. In particular, on October 27, 1997 there was circulated a 01 Version draft of the Media Gateway Control Protocol [3]. This protocol is for the concept of creating a bridge between the phone network control and the data network, which would among other things simplify the implementation of services such as Voice Over IP (VOIP). There has been postulated a device known as a Media Gateway Controller which connects to the SS7 network, and terminates its signaling needs, and outputs using MGCP (Media Gateway Control Protocol) to non-SS7 devices called Media Gateways (MG). In conclusion, prior art solutions based on post-switch off-loading require the connection of additional leased dedicated lines which in themselves are expensive. Moreover, to the extent that off-loading occurs after the tandem switch, they may require the connection of additional tandem switch capacity, making their installation expensive. It would therefore be desirable to provide an improved post-switch architecture which reduces congestion on the tandem switches, thereby affording a more economical solution. SUMMARY OF THE INVENTION It is therefore an object of the invention to provide a post-switch architecture which reduces congestion on the tandem switches. According to a broad aspect of the invention there is provided a method for off-loading data traffic in a telephone network having an ingress switch switchably connectable to a source of data traffic and a source of voice traffic and having a tandem switch downstream of the ingress switch, so as to re-route the data traffic away from a Public switched Telephone Network (PSTN) thereby reducing congestion thereon, the method comprising the steps of: (a) discriminating between the data traffic and the voice traffic downstream of the ingress switch prior to reaching the tandem switch, and (b) diverting the data traffic to a data network. A telephone network according to the invention comprises: a Public switched Telephone Network (PSTN) for conveying voice traffic, a data network for conveying data traffic, an ingress switch switchably connectable to a source of data traffic and a source of voice traffic, a tandem switch downstream of the ingress switch, and a Digital Cross Connect operative under control of a signaling system of the PSTN and being connected between the ingress switch and the tandem switch for segregating the data traffic from the voice traffic and re-routing the data traffic to the data network thereby reducing congestion on the PSTN. BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: Fig. 1 is pictorial representation of a prior art telephone network wherein voice and data traffic are conveyed together; Fig. 2 is pictorial representation of a prior art telephone network employing off-load architectures; Fig. 3 shows graphically typical loading of voice and Internet traffic at different times of day; Fig. 4 is pictorial representation of a prior art telephone network employing a scaled-down tandem switch; Fig. 5 is pictorial representation showing functionally a telephone network employing an off-load architecture according to a first embodiment of the invention; Fig. 6 is schematic representation of a detailed embodiment of a CrossSwitch™ for use with the telephone network shown in Fig. 5; Figs. 7 and 8 are pictorial representations showing alternative switching arrangements for off-loading data to the data network using the CrossSwitch shown in Fig. 6; Figs. 9a, 9b, 9c and 9d are pictorial representations showing successive switch connections of the CrossSwitch™ shown in Fig. 6 during the act of routing a voice call or off-loading data to the data network; Fig. 10 is pictorial representation showing how the CrossSwitch effects switching of voice or data and SS7 signaling between the ingress and tandem switches; Fig. 11 is a flow diagram showing the principal steps performed by the CrossSwitch when routing voice traffic from the ingress switch to the tandem switch; Fig. 12 is a flow diagram showing the principal steps performed by the CrossSwitch when routing data traffic from the ingress switch to the RAS; and Fig. 13 shows a detail of a network employing more than one interconnected CrossSwitch™. DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Fig. 5 shows functionally a Public switched Telephone Network (PSTN) showing generally as 31 for conveying voice traffic and a data network 32 for conveying data traffic. An ingress switch 33 is switchably connectable to a computer 34 (constituting a source of data traffic), which is an example of modem-borne data, such as Internet traffic, which travels from the computer 34 towards the data network 32 and back. The ingress switch 33 is also connected to a regular telephone handset 35 (constituting a source of voice traffic). A tandem switch 36 is connected downstream of the ingress switch 33, and a digital cross connect and gateway of the inventive type is connected between the ingress switch 33 and the tandem switch 36. The digital cross connect and gateway constitutes a digital cross connect based device and will be referred to hereinafter by the term CrossSwitch™ which is intended for use as a trademark by the Assignee and is referenced as 37 in Fig. 5. One or more Remote Access Servers (RAS) 38 are connected to output ports of the CrossSwitch™ 37. The CrossSwitch™ 37 is connected to the SS7 signaling network 39, and functions to segregate the data traffic from the voice traffic and to re-route the data traffic to the data network 32 via one of the RAS's 38, thereby reducing congestion on the PSTN 31. Voice calls, or data calls which are not rerouted, continue on their regular path in the PSTN 31 to the tandem switch 36, and from there to an egress switch 40 for connection to an end destination 41 in the case of a voice call, or to an Access Server 42 in the event of a data call which has not been re-routed. Also shown is a signaling transfer point (STP) 43 which is coupled to the CrossSwitch™ 37 as well as to STPs 44 and 45, which are themselves respectively coupled to the ingress switch 33 and to the tandem switch 36, thus allowing access by the ingress switch 33 and the tandem switch 36 to the SS7 signaling network 39. A switching control point (SCP) 46, which functions as a database for storing information relevant to customer services, is coupled to the STP 43 and a VoIP Server 47 is connected to a port of CrossSwitch™ 37 so as to allow for Voice over IP calls, which transverse the data network 32, and need to be delivered into the PSTN network 31. Fig. 6 shows schematically a more detailed high level block diagram of CrossSwitch™ 37 for use with the system shown in Fig. 5. The CrossSwitch™ 37 comprises two basic blocks, a Digital Cross Connect 50 and an SS7 Gateway 51. The SS7 gateway 51 includes an SS7 interface 52, which is used to enable the Digital Cross Connect 50 to operate under control of the SS7 signaling network. The SS7 interface 52 can communicate with the Digital Cross Connect 50, such as Tadiran's T::DAX®, via a control path 53, preferably using TL-1 protocol or the MGCP protocol. The Digital Cross Connect 50 used should be capable of a rapid switching rate, in order not to slow up the network. Such a gateway is similar to any of a number of products announced, including ADC NEWNET Connect7, or HP Opencall, which handle all SS7 signaling functions for a telephone network device. The SS7 gateway 51 also contains a Circuit Map Table 54, and a Routing table 55. The Routing table 55 contains a list of ISP phone numbers, or other phone numbers that represent "data destinations", that can be routed to the data network via the connected RAS 38, and the location of the output ports connected to the RAS 38. The Circuit Map Table 54, contains the list (map) of what connections currently exist in the Digital Cross Connect 50, i.e. which incoming trunks, also known as channels, are connected to which outgoing trunks. The control for these calls is handled in the SS7 network 39. The digital Cross Connect 50 preferably must be capable of switching at the DS0 level - i.e. at the individual channel level, also known as a 1/0 cross connect. All incoming channels to the device have their destination checked against the routing table. Any destination not listed as a locally connected RAS trunk, is transferred transparently (i.e. unchanged) by the CrossSwitch™. While the routing table is shown as internal to the gateway, it may alternatively be outside of the gateway, such as in the SCP 46 as shown in Fig. 5. In that case, the destination would be queried using an SS7 signaling technique knows as TCAP. Alternatively, the routing table may be held in the gateway 51, and only updates need be periodically downloaded from the SCP 46 via a TCAP query. Yet another possibility is for the routing table to be contained partially within the gateway 51 and partially outside thereof. Shown are Incoming Trunks from the ingress switch connected to ports φl - φ5 of the Digital Cross Connect 50, and Trunks to the tandem switch 36 connected to ports φlO - φl3. Also shown are ports φ20, φ21 and φ23 which are connected to RAS 38. It will be appreciated that the tandem switch, situated as it is between the ingress and egress switches, must be able to route traffic in both directions since the ingress and egress switches effectively exchange functions depending on the direction of traffic flow. The whole purpose in off-loading before the tandem switch is to allow existing tandem switches to continue to be used, without an increase in capacity, notwithstanding increased data traffic. This is possible because, if the data traffic is diverted before it reaches the tandem switch, no additional volume will be handled by the tandem switch. During the period that a channel from the ingress switch 33, which is normally connected to the tandem switch 36 is diverted by the CrossSwitch™ 37 in order to divert Internet traffic, it can happen that voice traffic is routed in the opposite direction by the tandem switch 36. This happens because all the channels shown are bi-directional. If this happens, the traffic will encounter a "circuits busy" signal, since the CrossSwitch™ 37 will have no available trunk to connect the call to the ingress switch 33, which in the case of this call is functioning as an egress switch. The tandem switch 36, is not aware that the normally open trunk to the ingress switch 33 is being utilized elsewhere, since it is connected via the CrossSwitch™ 37 which normally passes calls directly. Preferably, the CrossSwitch™ 37 must therefore be adapted to block the trunk from the tandem switch 36 so that no attempt will be made to route traffic in the reverse direction along this trunk so long as no trunk is cross connected to it at the ingress switch 33 side. This is done by using a Remote Maintenance Block Message over the SS7 network 39, as will be discussed in detail. In addition it will be noted in Fig. 6 that, at start up, the ingress switch trunk φ5 is not connected to any tandem switch trunk. This extra capacity exists at the ingress switch side because some traffic from the ingress switch 33 will in general not be forwarded to the tandem 36, but will instead be routed to the data network via the RAS 38, and trunks φ20, φ21 and φ23. At start up, or whenever a similar situation arises in operation, wherein there is no available trunk on the tandem side, trunk φ5 is initially blocked using a Remote Maintenance Block message sent over the SS7 network 39 to the ingress switch 33. In the event that a data call (i.e. a single trunk) is transferred to the data network via RAS 38, it is necessary to control RAS 38 using a suitable protocol. This can be handled in a number of ways: 1. PRI - this ISDN standard method can be used. Reference is made to ISDN[10] by Kessler, in particular chapter 7 for a clear explanation of SS7 and ISDN. SS7 signaling is done on a single 64KBS channel, which can be sent on one channel in the ISDN stream for all calls to the RAS. Referring to Fig. 7, in this case, the connection to RAS 38 is a PRI line, with the D channel (the control channel) being the translated signaling information from the SS7 interface 52 (shown in Fig. 6). Since the SS7 Interface 52 has the routing table and the incoming call destination (via the SS7 signaling system), it maps this revised information into the D channel. The D channel carries control signals from the RAS modems for the active calls. Signaling information includes commands such as on hook and off hook etc. The D channel is passed on a fixed channel line 58 which is set up, for this purpose, from the SS7 Interface 52 to the RAS 38 via the digital cross connect switch 50. 2. An RAS with an SS7 interface can be used. Then the call control is passed directly via standard SS7 signaling protocol to the RAS. 3. An RAS with a proprietary control interface may be used. Referring to Fig. 8, a control channel 59 using any interface such as MGCP may be used. Using a similar architecture, an SS7 protocol may be used, in which case the SS7 gateway 51 will be acting as a concentrator, allowing a number of SS7 controlled devices to share one physical SS7 connection 60. To understand how the CrossSwitch™ 37 handles calls, the architecture of the CrossSwitch™ 37 will now be explained so as to clarify the function of the Digital Cross Connect 50 and the mapping table 54. It will be recalled from Fig. 6 that the CrossSwitch™ 37 comprises two major components: the SS7 interface 52 and the Digital Cross Connect switch 50, coupled via a control path 53 which may use any protocol such as TL-1 or MGCP or even SS7. In such a configuration the Map Table has the following initial Trunk Mappings: Figs. 9a to 9d show pictorially successive switch connections of the CrossSwitch™ shown in Fig. 6 during the act of routing a voice call or off-loading data to the data network and will be used shortly in conjunction with the flow diagrams shown in Figs. 11 and 12 to explain the operation of the CrossSwitch™ 37. Referring to Fig. 9a. it is seen that trunk φ5 of the ingress switch 33 has no available trunk to tandem switch 36. and is therefore placed in a Blocked State so that the local ingress switch will not try to place a call over that trunk. This Blocked State is communicated to the ingress switch 33 via the SS7 network 39. All other voice calls placed from the ingress switch 33 towards the tandem switch 36 will be passed without any switching being done using the cross connections shown. The Routing Table contains all the NPAs/NXXs (Numbering Plan and routing information) and the Routed to Trunk Sub Group. An example of a routing table could be: The above table shows by way of example a phone number 212-926-1000 which is a known ISP access phone number, but this could be any known number. A number of ISP numbers, or other "data destination" numbers could each be mapped to one or more RAS's connected to CrossSwitch™ 37. Now that a Mapping table and a Routing Table are defined, calls can be handled. But before a call is placed, it will be helpful to review how the ingress switch 33, CrossSwitch™ 37 and the tandem switch 36 communicate. Fig. 10 shows the signaling model used in the USA. Thus, there is illustrated the ingress switch 33, the tandem switch 36, the cross connect switch 37 and the RAS 38. Quasi-associative signaling is employed whereby signaling data does not share the same physical media as the incoming voice or data traffic, however all messages relating to a given call follow the same non-associated path through the signaling network 39 (shown in Fig. 5). Voice traffic is sent from the ingress switch 33 to the tandem switch 36 via the CrossSwitch™ 37 along a path designated as 65 and 65'. However, the signaling is sent along an alternative signal path designated generally as 66 to the signaling transfer point (STP) 43. The signaling message contains all the required fields including the calling number, the called number, the trunk of the call, the point code for the next hop (i.e. the intermediary destination of the call), in our case the CrossSwitch™ 37. As explained above with reference to Fig. 5 of the drawings, the STP 43, is also connected via the SS7 network 39 or directly, to CrossSwitch™ 37, and following the point code information, transfers the signaling message to the SS7 Interface 52 in the CrossSwitch™ 37 via path 68. For calls which are passed on to tandem switch 36, the trunk, a DS0 channel, is passed along path 65'. The SS7 interface 52 in the CrossSwitch™ 37 substitutes the point code of tandem switch 36 as the code for the next hop, and using the Map Table substitutes the trunk connected to the tandem, for the trunk information from the ingress switch 33. The signaling information is then sent over path 69 via the SS7 signaling network 39 and its associated STP 43 to STP 45 and thence to the tandem switch 36. It will be recalled from Fig. 5 that the ingress switch 33, CrossSwitch™ 37 and tandem switch 36 are each connected to the SS7 signaling network 39, and may be connected to one or more STP's, but not necessarily to the same one. STP 43, 44 and 45 may be separate units, or may be a single STP depending on the location and architecture of the PSTN 31 of the area. 5 Alternatively, in the case of data traffic which is diverted to the RAS 38 by the CrossSwitch™ 37, the call is temiinated at the CrossSwitch™ 37 and the second hop 69 and 65' is absent. Instead, the traffic is transferred over path 65" to the RAS 38. As previously noted, the RAS may be an SS7 device, in which case it will be responsible to terminate the call, or the SS7 gateway 51 may inform the SS7 l o network 39 that this is the termination point of the call. Fig. 11 is a flow diagram showing all of the major components that could be involved in the call, and illustrating how a voice call is placed through this network. At step 70 a customer places a voice call from the phone to a phone not 5 serviced by this ingress switch. • At step 72 the ingress switch looks in its map table for a first hop destination (in the event that it is not directly connected to the egress exchange.) It directs the call to a trunk connected to this destination. • At step 74 the ingress switch then builds a IAM message with all of 0 the required fields including: • Calling Number • Called Number • Trunk call is on (3). • Point Code pair for next hop (CrossSwitch™) 5 • Also at step 74 the ingress switch then sends the IAM message to the STP for routing to the Point Code. • At step 76 the STP receives the message and then routes that message to the CrossSwitch™ based on the Point Code that is associated with it. • At step 78 the CrossSwitch™ (SS7 interface) receives the IAM message and using the Routing Table confirms that the call is not destined for a locally connected RAS (i.e. it is not Local Incoming Data, but instead is Local Incoming Voice). • At step 80 the CrossSwitch™ uses the Mapping Table to see which tandem trunk is currently connected to the incoming voice trunk from the ingress switch. The incoming call is on trunk 3 therefore the outgoing trunk to the tandem is trunk 12. • It is thus to be noted that no switching is performed by the CrossSwitch™ for this call. The incoming trunk 3 is already connected to outgoing trunk 12. and the voice traffic is therefore connected to the tandem switch 36. • At step 82 the CrossSwitch™ SS7 interface now builds the IAM message to the tandem with the trunk number changed from 3 to 12 and the Point Codes changes to point to the tandem switch. • At step 84 the CrossSwitch™ SS7 interface now sends the IAM message to the STP for routing, • At step 86 the STP receives the message and then routes that message to the tandem switch based on the Point Code that is associated with it. • At step 88 the tandem switch then receives the IAM message and handles it, and the incoming traffic on Trunk 12 as a normal call. It must be noted that many other SS7 messages are generated for this call but this example is intended to show how the CrossSwitch™ handles voice calls without putting in additional switching delay, as no switching is done by the CrossSwitch™ for voice calls. Fig. 12 is a flow diagram showing all of the major components that could be involved in a data call. With the aid of Figs. 12 and 9b there will now be illustrated how a data call is placed through this network by a subscriber of the local switch to a remote service such as an ISP not connected to her or his local switch. • At step 90 a data call is placed through this network. • At step 92 the ingress switch looks in its map table for a first hop. It directs the call to a trunk connected to this destination, in our case the CrossSwitch™. 5 • At step 94 the ingress switch then builds a IAM message with all of the required fields including: • Calling Number • Called Number • Trunk call is on (trunk 4). l o • Point Code pair for next hop (CrossSwitch™) • Also at step 94 the ingress switch then sends the IAM message to the STP for routing to the Point Code. • At step 96 the STP receives the message and then routes that message to the CrossSwitch™ based on the Point Code in the message. 5 • At step 98 the CrossSwitch™ in the SS7 interface receives the message and using the Routing Table identifies the call as a data call for a locally connected RAS. It points the call to the Local Incoming Data routing group (port φ20 - φ23). • At step 100 the CrossSwitch™ uses the Mapping Table to see which 0 tandem trunk is currently connected to the incoming trunk from the ingress switch. The incoming call is on trunk φ4 therefore the CrossSwitch™ must switch the channel from trunk φl3 (tandem switch) to trunk φ30 (RAS). To do this the following step will be executed: 5 • At step 102 a SS7 Remote Maintenance BLOCK message is constructed for this channel on trunk φl3, to prevent the tandem switch from sending traffic on to this trunk. • At step 104 the SS7 interface sends this message to the STP with the Point Code of the tandem switch. • At step 106 when the tandem switch receives the Remote Maintenance BLOCK message it will take this trunk out of service. • At step 108 the CrossSwitch™ will then connect trunk φ4 to trunk φ21 and the mapping table is updated to reflect this connection. • At step 110 the SS7 interface packs the signaling information on to an individual channel of the PRI line to the RAS device. Alternatively, the RAS can be connected to the SS7 signaling system, in which case an SS7 transfer message will be sent from the SS7 Interface of the CrossSwitch™ to the RAS, similarly to what was outlined above. In either case, the RAS will function to handle the signaling information. Another non-limiting alternative, is to have the RAS controlled via a proprietary system under control of the SS7 Interface 52, in which case SS7 interface 52 will also function to terminate the call. • The data call is now setup. • At step 112 the CrossSwitch™ now checks the mapping table to see if there are any free (unassigned) trunks to the ingress switch which can be connected to the blocked trunk of the tandem switch. • In the example above trunk φ5 from the ingress switch is unassigned and can be connected to trunk φl3 on the tandem side. • At step 1 14 the CrossSwitch™ then updates the Mapping Table to indicate this connection., and cross connect 50 does the cross connection. • At step 1 16 the SS7 interface prepares and send two UNBLOCK Messages, one for trunk φ5 to the ingress switch and one for trunk φl3 on the tandem switch. The situation is now as shown in Fig. 9b. For call completion on a voice call the CrossSwitch™ leaves the connection in place so that the following voice calls can be set up without any switching delay. However, on a completion of a data call the circuit is taken down when the call is completed. At this point, if there are any free tandem channels available the CrossSwitch™ will cross connect the now available ingress switch cannel to that tandem channel and sends a UNBLOCK Message to the channel for that trunk now being connected. If there are no trunks available, a block message to the ingress switch will be sent for the trunk that was just used for the completed data call, and the situation as shown in Fig. 9c will occur. The mapping table will simultaneously be updated to show this situation. The detailed steps in the case where there is no available tandem trunk are as follows: • Update the mapping table to show trunk φ21 is available, and that trunk φ4 to the ingress switch is blocked and available. • Construct and send a block message for trunk φ4 to the ingress switch via the STP network In the event that an available in trunk φl4 to the tandem switch is found the steps are as follows: • Update the mapping table to show trunk φ4 connected to trunk φl4, and direct cross connect 50 to create the connection. • Prepare two unblock messages - one to the ingress switch for trunk φ4, and one to the tandem switch for trunk φl4. • Send both messages. The situation will now be as shown in Fig. 9d. It is to be noted that there are many other signaling messages being sent during this time. It will be recalled that the same architecture shown in Fig. 5 can be used for Voice over IP calls, which transverse the data network 32, and need to be delivered into the PSTN network 31. This can be accomplished by the CrossSwitch™ 37 using the same method described, with the call being now set up from the VoIP server 47. The VoIP server 47 will initiate the SS7 signaling for the call, in the event that it is an SS7 device, and will place it on a port of the CrossSwitch™, or as shown, the signaling may be initiated by the SS7 gateway 51, from the information being passed on the D channel from the VoIP Server 47 to the Digital Cross Connect 50. The CrossSwitch™ will now under control of this SS7 message connect the VoIP call to an available trunk to the ingress switch 33 or the tandem switch 36 using the same blocking and unblocking techniques if required. The control methods of the VoIP Server 47 have the same options described above for the RAS 38. It should be noted, that the use of the term IP or Internet is meant to be descriptive of any data network, in particular any packet switched network. In addition, the CrossSwitch™ can monitor the status of the RAS devices connected to it. In the event that the connected RAS is approaching saturation, the CrossSwitch™ can send a TCAP query via the SS7 or other signaling network to another CrossSwitch™. Alternatively, signalling may be done on an assigned channel of a leased line, or any other method of transferring status information may be used. Traffic may then be moved to another CrossSwitch™, which contains an RAS pool which is not as saturated, prior to reaching saturation. This may be done to achieve load balancing. Fig. 13 shows such a connection, having a first and second CrossSwitch™ depicted 120 and 121, respectively, and connected in a network via a leased line 122. A pair of ingress switches 123 and 124 is connected to respective input ports of the first CrossSwitch™ 120 and a tandem switch 125 is coupled to an output port thereof. Likewise, a pair of ingress switches 126 and 127 is connected to respective input ports of the second CrossSwitch™ 121 and a tandem switch 128 is coupled to an output port thereof. Each CrossSwitch™ 120 and 121 has output ports connected to a respective RAS 129 and 130. The leased line 122 may be utilized to transfer traffic from the first CrossSwitch™ 120 to the second CrossSwitch™ 121 and vice versa to achieve load balancing. Whilst the invention has been described with particular reference to some preferred embodiments, it will appreciated that modifications will be apparent to those skilled in the art and the invention contemplates such modifications as fall within the scope of the appended claims.

Claims: CLAIMS: 1. A method for off-loading data traffic in a telephone network having an ingress switch switchably connectable to a source of data traffic and a source of voice traffic and having a tandem switch downstream of the ingress switch, so as to re-route the data traffic away from a Public switched Telephone Network (PSTN) thereby reducing congestion thereon, the method comprising the steps of: (a) discriminating between the data traffic and the voice traffic downstream of the ingress switch prior to reaching the tandem switch, and (b) diverting the data traffic to a data network. 2. The method according to Claim 1, wherein step (a) includes the step of comparing a destination address with a table of known data network addresses and assuming that incoming traffic is voice traffic in an absence of a match. 3. The method according to Claim 1, wherein step (b) includes disposing a digital cross connect based device between the ingress switch and the tandem. 4. The method according to Claim 3, including the step of blocking a trunk connected to the digital cross connect based device when incoming traffic is diverted to the data network so as to prevent voice traffic from being routed along said trunk in an opposite direction. 5. A telephone network comprising: a Public switched Telephone Network (PSTN) for conveying voice traffic, a data network for conveying data traffic. an ingress switch switchably connectable to a source of data traffic and a source of voice traffic, a tandem switch downstream of the ingress switch, and a digital cross connect based device connected between the ingress switch and the tandem switch for segregating the data traffic from the voice traffic and re-directing the data traffic to the data network thereby reducing congestion on the PSTN. 6. The telephone network according to Claim 5, wherein the digital cross connect based device includes a first plurality of ingress trunks from the ingress switch and a second, smaller plurality of egress trunks to said tandem. 7. The telephone network according to Claim 5. being adapted to block a trunk 5 connected to the digital cross connect based device when incoming traffic is diverted to the data network so as to prevent voice traffic from being routed along said trunk in an opposite direction. 8. The telephone network according to Claim 5, wherein the digital cross connect based device is connected proximate the ingress switch. ιo 9. The telephone network according to Claim 5, wherein an output of the digital cross connect based device is connected to the data network via a Remote Access Server. 10. The telephone network according to Claim 5, wherein an output of the digital cross connect based device is connected to a Remote Access Server. 15 11. The telephone network according to Claim 5, wherein the digital cross connect based device is connected proximate the tandem switch. 12. The telephone network according to Claim 11, wherein an output of the digital cross connect based device is connected to the data network via a Remote Access Server. 0 13. The telephone network according to Claim 5, wherein the digital cross connect based device includes a signaling network for controlling the digital cross connect based device using a standard signaling method for telephone traffic. 14. The telephone network according to Claim 13, wherein the digital cross connect based device is controlled using SS7 signaling. 5 15. The telephone network according to Claim 5, wherein the digital cross connect based device is adapted to control more than one Remote Access Server each serving a respective Service Provider. 16. The telephone network according to Claim 5, wherein the digital cross connect based device includes a route map containing data network addresses each 0 relating to a destination in the data network to which data must be off-loaded. 17. The telephone network according to Claim 13, wherein a route map containing data network addresses each relating to a destination in the data network to which data must be off-loaded is maintained remote from the digital cross connect based device. 5 18. The telephone network according to Claim 17, wherein the route map is accessed via a TCAP query using the signaling network. 19. The telephone network according to Claim 13, wherein: the digital cross connect based device includes a first route map containing a first portion of data network addresses each relating to a destination in the data l o network to which data must be off-loaded, and a second route map containing a second portion of data network addresses each relating to a destination in the data network to which data must be off-loaded is maintained remote from the digital cross connect based device. 20. The telephone network according to Claim 13, wherein there is provided a 5 first digital cross connect based device and a second digital cross connect based device and the first digital cross connect based device is adapted to: (a) monitor a status of a device connected thereto, and (b) if the device is approaching saturation, to i) send a query to the second digital cross connect based device for 0 establishing whether there is spare capacity in the second digital cross connect based device and, if so, ii) move traffic to the second digital cross connect based device.

Inventors: GALLER SIMON, RUBINSTEIN ZVI, GALLER, SIMON, RUBINSTEIN, ZVI
Applicants: ECI TELECOM LTD, GALLER SIMON, RUBINSTEIN ZVI, ECI TELECOM LTD., GALLER, SIMON, RUBINSTEIN, ZVI
Application year: 2000
Main classification: H04Q11
IPC codes: H04L12, H04M3