Method of Aggregating a Plurality of Network Traffic

The present invention relates generally to the field of communications and more particularly to a method of aggregating a plurality of network traffic.

Inter-exchange carriers (IXC) provide discounts on interLATA (Local Access and Transport Area) calls to their customers if they will aggregate their calls (network traffic) to a single point. To facilitate this service, inter-exchange carriers (IXC) offer to provide private facilities from each of the customer's locations to the single point of presence. FIG. 1 illustrates the situation. A customer having facility A 12, facility B 14 and facility C 16 has to aggregate all their interLATA calls. Facility A is coupled to a central office (CO) 18 that has a dedicated DS-1 line 20 to the IXC's POP 22. The central office 18 includes an alternate route selection system (ARS) 24. The ARS 24 can route interLATA calls to another IXC via another DS-1 or public office routes if, for instance, there is no capacity left on the DS-1 line 20. Facility B 14 and facility C 16 are coupled to CO 26. A second dedicated DS-1 line 28 connects the CO 26 to the POP 22. A second ARS 30 duplicating the function of the ARS 24 is required for the second CO 26. A duplicate ARS and another DS-1 line will be required for every CO used by a customer facility. Leasing DS-1 lines can be very expensive, especially if they are not used at capacity all the time. However, if the DS-1 lines are constantly being used at capacity, then a number of calls (network traffic) are having to be routed to a second route, public or another DS-1, that is more expensive.

Thus there exists a need for a method of aggregating calls (network traffic) that is flexible enough to handle peak loads without the customer having to pay for unused capacity and does not require duplication of systems, such as ARSs.

FIG. 1 is a block diagram of a prior art system for aggregating calls;

FIG. 2 is a schematic diagram of an intelligent network capable of implementing the invention;

FIG. 3 is a schematic diagram of the intelligent network of FIG. 2 and illustrates another implementation of the invention;

FIG. 4 is a schematic diagram of an intelligent network and illustrates another implementation of the invention;

FIG. 5 is block diagram of a system for defining certain features of the invention;

FIG. 6 is a flow chart of an embodiment of the steps a Service Switching Point (SSP) and a Switching Control Point (SCP) use in implementing the invention; and

FIG. 7 is a flow chart of an embodiment of the steps a hub SSP and the SCP use in implementing the invention.

The invention uses the advanced intelligent networks (AIN) features to aggregate calls (a plurality of network traffic) from a subscriber's multiple facilities to a single or plurality of hub service switching point (SSP). The calls are routed by the public switched network to a hub service switching point (SSP) and then to the IXC POP. In one embodiment there are several hub SSPs. In addition, the service provides flexible capacity to serve the subscriber's changing requirements.

FIG. 2 illustrates the process the advanced intelligent network uses to implement the invention. A subscriber 50 places an abbreviated call (network traffic access request) by dialing 6000 at one of his plurality of locations. The subscriber must have the ability to enter an access code to facilitate triggering. The call is received at service switching point A (SSP A, one of a plurality of central office switches) 52. The SSP 52 sends a query (information analyzed query) 54 to a switching control point (SCP) 56 over a signal system seven (SS7) signaling link. The query contains the calling party ID (i.e., 847-438-3001) and dialed digits (i.e., 6000). The SCP 56 translates the dialed digits into a corresponding routing number (e.g., 217-936-1234) and determines that the call is a direct dial interLATA call (interLATA network traffic request). In this example the call is also out of network. The SCP 56 determines that the call is to be redirected to the hub SSP C 58. The SCP 56 sends a response (analyze route message, routing instruction) 60 over the SS7 signaling link, that directs the SSP A 52 to route the call to the hub SSP C 58. This is accomplished by having the called party ID portion of the message set equal to the directory number of the hub SSP 58. The translated or true called routing number is returned in the redirected party ID parameter. The SSP (central office) 52 then routes 62 the call (network traffic) to the hub SSP (hub central office) 58 over the public network that connects SSP A, SSP B and SSP C together. In addition, the SSP 52 sends an initial address message (IAM) over the signal system 7 (SS7) signaling links that connects the SSPs 52, 58, 68, to the SCP 56. The IAM contains the translated or true called number (i.e., 217-936-1234) and the called number, which is the directory number of the hub SSP 58. The hub SSP (hub central office) 58 triggers on the called number and sends a second query (second information analyzed query) 70 to the SCP 56. The SCP 56 then sends a second response (second analyze route message) 72 containing routing information (translated or true routing number) to a single IXC POP 74, a billing information and a primary trunk group. Based on the routing information received in the second response, the hub SSP 58 routes the call to the IXC POP 74 over a shared or private facility 76. Thus the calls are aggregated with other calls (a plurality of other network traffic) at the hub SSP 58 and routed to one of the plurality of inter-exchange carrier selections. When a shared facility 76 is used to route the call the hub SSP 58 sends an IAM to the IXC 74 using SS7 signaling. When a shared facility 76 having feature group D signaling is used a charge number (hub SSP number) and a called number (i.e., 217-938-1234) are passed to the IXC 74. When a private facility 76 having standard tie lines is used, only the called number is passed on to the IXC 74. When private facilities having a primary rate ISDN are used, the charge number and the called number are passed to the IXC 74.

The IXC 74 then routes the call using standard long distance techniques to a SSP E 78 in the LATA 2 of the dialed number. The SSP 78 routes the call to the called party 80.

FIG. 3 shows the same facilities as in FIG. 2 but illustrates an off network call. In this example, the calling party 50 dials an access code (i.e., 9) and then dials a plurality of digits (i.e., 217-936-1234#). The "#" is optional and expedites processing of the call. The SSP 52 receives the access code and dialed digits. Upon determining that the access code is present, the SSP 52 sends a query 54 containing the plurality of digits to the SCP 56. The SCP 56 will determine that the call is an interLATA call and check to see if the number is restricted. The restriction of called numbers will be discussed in more detail with respect to FIGS. 5-6. Assuming the call is not restricted, the SCP sends a response 60 redirecting the call to the hub SSP 58. The call is then processed in the same manner as described in FIG. 2.

FIG. 4 is a schematic diagram of an intelligent network and illustrates another implementation of the invention. In the implementation of FIG. 4 a plurality of hub SSPs 100, 102 are used to aggregate calls. Calls originating from facilities A and B 104, 106 are routed by SSP A 108 and SSP B 110 in an alternating pattern as received to hub SSPs 100, 102 (next hub service switching point). To accomplish this SSP A 108 and SSP B 110 send a query over the SS7 signaling lines 112, 114 to the SCP 116. The SCP 116 preforms the steps discussed with respect to FIGS. 2 & 3. In addition, the SCP 116 alternatively routes calls to each of the plurality of hub SSPs 100, 102. The hub SSPs 100, 102 will preform exactly the same operation to route the call to the IXC 118 as in FIGS. 2 & 3. When the call originates from facility C 120, the call will be routed by SSP C 122 to next hub SSP 100, 102. When a call originates from facility D 124 it is directly connected to the hub SSP 100. In this case the hub SSP 100 uses a centrex translation to route the call to the IXC 118. In addition, the hub SSP 100 will handle the call restriction process by using the centrex translations, instead of the SCP doing the call restrictions. The IXC 118 will then route the call to a destination SSP F 126.

FIG. 5 is block diagram of a system for defining certain features of the invention. One of the features provided by the invention, is the ability to restrict calls. Once a plurality of originating phones numbers have been selected for the aggregation service. The customer's administrator using a terminal 140 can input a plurality of lines (subset of the originating phone numbers, defined group of originating numbers) to be restricted. The administrator can restrict the lines from making international calls (01XXX) or making operator assisted calls (0 or 0+) or from specifying a carrier (10XXX). In addition the lines can restricted from making calls to a selected group of numbers (NPA NXX or NXX). This information is then transmitted to a service management system (SMS) 142. The information is then transmitted from the SMS 142 to the SCP 144. The SCP 144 determines if the dialed number meets a predefined criteria (selected group of numbers) and therefore is restricted. The SCP 144 communicates this information to the SSP 146 over an SS7 signaling link 148, 150 containing a signal transfer point 152. This allows the administrator to restrict all the phone lines from a factory facility from placing international calls, for example.

FIG. 6 is a flow chart of an embodiment of the steps a Service Switching Point (SSP) and a Switching Control Point (SCP) use in implementing the invention. The process starts, step 160, by the SSP receiving an off-hook signal from a customer telephone, at step 162. The SSP sends a dial tone to the customer telephone at step 164. The SSP then receives the dialed digits (destination number) at step 166. At step 168 the SSP determines if an access code (or Customized Dialing Plan trigger) is present. When the access code or CDP trigger is not present, centrex translation/POTS (plain old telephone service) processing is pursued at step 170. Step 170 is performed when the calling facility is directly connected to the hub SSP.

When the access code is present, an information analyzed query is sent to the SCP at step 172. The SCP then determines if the call is restricted at step 174. When the call is restricted a restricted call response message is sent to the SSP at step 176. The SSP then plays the terminating announcement that the call is not authorize at step 178, which ends the processing at step 180.

When the call is not restricted at step 174, the SCP determines if the dialed digits (plurality of dialed digits) require a direct dialed interLATA call at step 182. The service of toll aggregation requires that the call be the direct dialed interLATA. However, if the call is not the direct dialed interLATA call a routing response is sent to the SSP at step 184. The SSP then routes the call based on the routing response at step 186, which ends processing at step 180.

When the call is the direct dialed interLATA call, an analyze route response is transmitted to the SSP at step 188. The SSP then routes the call to the hub SSP for aggregation at step 190 and sends an initial address message to the hub SSP, which ends the processing for initiating SSP at step 192.

FIG. 7 is a flow chart of an embodiment of the steps a hub SSP and the SCP use in implementing the invention. The process starts by the hub SSP receiving the IAM and determining that the called number is a 3/6/10 digit trigger at step 200. Based on this trigger the hub SSP transmits an information analyzed query to the SCP at step 202. Next the SCP determines if the original called party ID is present at step 204. When the original called party ID is not present, sending a cannot complete response to the hub SSP at step 206. A terminating announcement is played that the call cannot be completed at step 208, which ends the call processing for the hub SSP at step 210.

When the original called party ID is present, sending an analyze route message to the hub SSP at step 212. The hub SSP then routes the call to the IXC based on the data received at step 214, which ends the call processing for the hub SSP at step 210.

Using the methods described above a subscriber has a flexible service that can handle peak loads, without paying for extra capacity. In addition, the customer no longer is required to lease DS-1 lines from each of his facilities to the IXC POP. This can significantly reduce the costs of aggregating calls to get a discount from the IXC. While the invention has been described in conjunction with specific embodiments thereof, it is evident that many alterations, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description. Accordingly, it is intended to embrace all such alterations, modifications, and variations in the appended claims.