GEOGRAPHIC TRUNK GROUPS

CROSS REFERENCE TO RELATED APPLICATIONS

[000] This Patent Cooperation Treaty (PCT) application claims benefit of priority from United Slates Patent Application Serial No. 11/942,317, filed 19 November 2007, entitled "Geographic Trunk Groups." The aforementioned patent application is incorporated herein by reference for all purposes.

COPYRIGHT NOTICE

[001] Contained herein is materia! that is subject to copyright protection. The copyright owner has xio objection Io the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever. Copyright © 2006 Level 3 Communications, Inc.

TECHNICAL FIELD

[002] Embodiments of the present invention generally relate to communications through a network. More specifically, embodiments relate to defining logical groups of IP interconnections that have useful commonalities, and using the defined IP interconnection groups to route calls through one network to another network.

BACKGROUND

[003] In the field of network communications, Voice over Internet Protocol (VoIP) calls are typically setup over multiple networks, such as a backbone network and one or more customer or carrier networks. Typically, when a call request enters the backbone network, a core routing device determines how to most efficiently route the call out of the backbone network to the customer network. The core routing device chooses among a number of edge devices on the backbone network that interconnect with edge devices on the customer network. The choice of which edge device to route to within the backbone network is typically based on the called telephone number and/or an associated IP address. A routing tree of customer telephone numbers and customer IP addresses is accessed to determine the outbound edge device. In conventional systems, one or more outbound edge devices on the backbone network are dedicated to each customer network. For example, the routing trees, as well as other customer network-related data, are typically hard-coded in the

backbone edge devices. Such dedicated approaches have drawbacks related to lack of flexibility, lack of scalability, and heightened sensitivity to customer network changes. [004] When outbound devices aie dedicated to a customer, devices that perform call routing functions in the interior of the backbone network often need to be aware of (e.g., programmed with) details of the interconnections to customer network. For example, a core routing engine may need to have information about particular IP addresses that can be directly reached by the outbound edge devices. Such an arrangement tends to make the core routing devices inefficient because these devices often need to perform relatively complex processing to determine which outbound devices to use to route calls. In addition, the core router configuration is highly sensitive to changes in IP addresses on the customer network. Conventionally, the outbound devices have not shielded the core routing equipment from changes, but rather, a change to the customer ncLwork often ripples through the backbone network, requiring changes at multiple levels of the infrastructure. [005] Changes to network interconnections can also impact other aspects of telecommunications service, such as billing and operations. For example, IP addresses on the customer network may be associated with bills that are issued by the backbone network service provider to the customer network provider. When IP addresses change, if the billing system is not promptly updated, then bills may be wrong; e.g., the bills may not correspond to the actual number of VoIP addresses being serviced. There often is a separatioxi between the update to the backbone network infrastructure and the other business processes, so that the change will need to be made not only in the outbound edge devices, to maintain proper routing, but also in the billing systems, operations, and others. As such, customization to the customer network necessitates changes in various aspects of the backbone network. However, conventional approaches toward responding to such customer changes have generally not been coordinated or efficient.

[006J It is with respect to these and other considerations that embodiments of the present invention have been made.

BRIEF DESCRIPTION OF THE DRAWINGS

[007] Fig. 1 illustrates an exemplary operating environment within which embodiments υf the invention can operate to define and use internet Protocol (IP) trunk groups for routing calls from one network to another.

[008] Fig. 2 illustrates one general form of an IP trunk group configuration, in which the edge node of a VoIP backbone network is directly connected to an interface node of a carrier network.

[009] Fig. 3 illustrates another general form of an IP trunk group configuration, in which a load-balancer can be accessed by an interface node of the carrier network to provide load balancing across multiple backbone IP addresses included Li an IP trunk group.

[010J Fig. 4 illustrates yet another general form of an IP trunk group configuration, in which a load-balancer is logically positioned between one or more edge nodes of the backbone network and one or more interface nodes of the carrier network.

[011] Fig ^s - 5λ - 5d illustrate various exemplary scenarios in which Internet Protocol

(IP) trunk groups can be used.

[012] Figs. 6a and 6b illustrate logical interconnections provided by a geographic trunk group (GTG) according to embodiments of the invention.

[013] Figs. 7a - 7d illustrate communications in a GTG according to several embodiments of the invention.

[014] Fig. 8a illustrates a daLa structure with attributes, values, and constraints that can be used to define IP trunk groups in accordance with one embodiment.

[015] Figs. 8b - 8e illustrate a data structure with attributes and values that can be used to define GTG in accordance with one embodiment.

[016] Fig. 9 illustrates a scheme that can be used by a core routing engine to route incoming calls to outbound trunk groups.

[017] Fig. 10 is a flowchart illustrating an exemplary process for defining and provisioning IP trunk groups in a backbone network.

[018] Fig. I l is a flowchart illustrating an exemplary process carried out by a core routing engine for routing inbound calls to outbound IP trunk groups in accordance with one embodiment.

[019] Fig. 12 illusLralcs a general purpose computing device upon which embodiments of the present invention can execute.

[020] While the invention is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the invention to the particular embodiments described.

DETAILED DESCRIPTION

[021] Embodiments of the present invention relate to systems and methods for defining trunk groups for use in an Internet protocol (IP) environment. More specifically, embodiments relate to identifying IP interconnections that have common characteristics which etui be included in an IP trunk group definition. IP trunk groups that are defined can be used by one or more core routing engines to route incoming calls Io outbound IP trunk groups. Based on IP trunk group traffic distribution policies, inbound calls are distributed across IP edge nodes, which may perform traffic distribution across carrier network edge nodes.

[022] In addition, embodiments of the invention relate to routing an Internet

Protocol (IP) - based call through a first IP-based network to a second IP-based network using geographic trunk groups (GTG). λ GTG provides the ability to provide a location with multiple carrier servers and possibly multiple interfaces per carrier server to two or more backbone locations that have one or more Internet Protocol Media Gateways (IPMGs). Each GTG will have a set of attributes that define how each backbone IPMG in the GTG communicates with each carrier server in the GTG. In the most general terms, a GTG includes the routing from a backbone gateway location (including one or more backbone edge nodes) to a carrier location (including one or more carrier edge nodes). The GTG represent a connection between a single backbone gateway location and a single carrier location. As such, a GTG may contain multiple IPTGs.

[023] Prior to describing one or more preferred embodiments of the present invention, definitions of some terms used throughout the description are presented.

Definitions

[024] The term "Internet protocol trunk group" or "IP trunk group" refers to a group of one or more IP interconnections thai have similar attributes. The one or more IP interconnections can be identified by an IP trunk group (JPTG) identifier.

[025] The term "IP interconnection" refers to a logical path between two IP addresses over an IP network and endpoints at each end of the logical path. An IP interconnection may include numerous physical paths through the IP network (e.g., different paths for different packets).

[026] A "module" is a self-contained functional component. λ module may be implemented in hardware, software, firmware, or any combination thereof. [027] The terms "connected" or "coupled" and related terms are used in an operational sense and are no! limited to a direct connection or coupling. [028] The phrases "in one embodiment," "according to one embodiment," and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one embodiment of the present invention, and may be included in more than one embodiment of the present invention, importantly, such phases do not necessarily refer Io the same embodiment.

[029] If the specification states a component or feature "may", "can", "could", or

"might" be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.

[030] The terms "responsive" and "in response to" includes completely or partially responsive.

[031] The term "computer-readable media" is media that is accessible by a computer, and can include, without limitation, computer storage media and communications media. Computer storage media generally refers to any type of computer- readable memory, such as, but not limited to, volatile, non-volatile, removable, or nonremovable memory. Communication media refers to a modulated signal carrying computer-readable data, such as, without limitation, program modules, instructions, or data structures.

Exemplary System

[032] Fig. 1 illustrates an exemplary operating environment 100, which is suitable for employing Internet protocol trunk groups (IPTG) in accordance with one embodiment. IPTGs can introduce a level of abstraction between the interior infrastructure of a backbone network and customer networks, to which the backbone network routes calls. In this regard, the IPTGs can insulate interior infrastructure from customer network changes. In addition, IPTGs bundle various types of information about IP interconnections that can be used by various systems associated with the backbone network. As such, IPTGs can allow for scalability across the systems. Embodiments described herein are directed at Voice over IP

(VoIP), Session Initiation Protocol (SlP), and related technologies for purposes of illustration, although il will be understood by those skilled in the art that IPTGs and related concepts can be applied to other comiiiunication environments and protocols.

[033] In the embodiment of Fig. 1, a backbone network 102 provides communications services between users who may access the same or different communication networks, such as a switched network 104 and a carrier IP network 106. The switched network 104 could include the Public Switched Telephone Network (PSTN), a local exchange carrier (LEC) network, cellular networks, and/or an emergency services network. The carrier IP network 106 could include an Internet Service Provider (ISP) network, an autonomous system, or other customer carrier network. λ plurality of communication endpoints 108 are used to access the switched network 104, while a plurality of IP communication endpoints 110 are used to access the carrier IP network 106. Communication endpoints 108 could include, without limitation, conventional telephones, cellular telephones, facsimile machines (Fax), MODEMs, or telephones on a private branch exchange (PBX). IP communication endpoints 110 could include, wilhoul limitation, VoIP phones, soft phones, conference servers, IP interactive voice response (IVR) plalforms, or terminal adaptors.

[034] Calls routed by the backbone network 102 to the carrier IP network 106 are routed through a publicly accessible IP network, such as the Internet 112. Communications through lhe Internet 112 can be public or private. For example, Communications may by privately communicated over the Internet via an Ii ⁵ virtual private netwoik (VPN). It will be understood that one or more of the switched network 104, the backbone network 102, the lnterneL 1 12, and the carrier IP networks 106 could be composed of multiple sub-networks. [035] In one scenario, calls are communicated between the switched nelwoik 104 and the backbone network 102 in one format and/or protocol, while calls are communicated between the backbone network 104 and the carrier networks 106 in another format and/or protocol. As such, among other functions, the backbone network J 02 performs translation of the calls between the protocol of the switched network 104 and the Internet Protocol of the earner networks 106. In other scenarios, calls can be communicated between IP communication endpoinls 110 on one or more IP-based carrier networks 106.

[036] In the embodiment of Fig. 1, calls between the switched network J 04 and lhe backbone network 102 are communicated using l ime-division Multiplexing (TDM). More specifically, multiple TDM trunk groups facilitate the interface between the backbone network 102 and the switched network 104.

[037] Multiple IP interconnections exist betw ^τ een the backbone network 102 and the carrier IP networks 106 to facilitate call communication between these networks over lhe Internet 112. As is known, communications over the Internet arc packetized, and packets of a single communication could take multiple different paths through the Internet. When the packets reach their destination, they are reassembled. An IP interconnection includes two end nodes and the logical path formed between them by the one or more paths through the Internet that packets of a communicalion take. Multiple IP trunk groups 116 may be defined over sets of the IP interconnections, as is described in further detail below. Using the IPTGs 116, interior systems of the backbone network 102 can efficiently route calls from the switched network 104 and the carrier IP networks 106 and vice versa. The backbone network 102 can also route calls from one IP-based network 106 to another IP-based network 106.

[038] More specifically, core routing engines (CREs) 118 in the backbone network

102 route calls from TDM edge nodes 120 to IP edge nodes 122 or from IP edge nodes 122 to other IP edge nodes 122. IP edge nodes 122 route the received calls Io carrier edge nodes 124. The TDM edge nodes 120 and the IP edge nodes are typically gateway devices. In various embodiments, media gateways on the edge of the backbone network 102 are controlled by media gateway controllers. The media gateways and the media gateway controllers may or may not be separate devices. IP media gateways may be referred to as session border controllers (SBCs). Media gateways (MGs), MG controllers and other associated components are available and are manufactured and distributed by various equipment providers such as Sonus' ^M and Lucent™, just to name a few. The present invention is certainly not limited to any certain brand name, but rather various embodiments may be implemented using any one or more of these known providers. [039] When a CRE 118 receives call requests (e.g., SIP requests or INVlTEs) from a

TDM edge node 120, in general, the CRE i 18 chooses among multiple IP edge nodes 122 through which to route the call requests. The determination as to which of multiple IP edge

nodes J 22 Lo choose is fundamentally based on the called telephone number in the request. The called telephone number dictates the IP address of the destination on the carrier IP network 106. However, choosing the IP edge node 122 can be based on routing policies. These routing policies are generally configurable based on various criteria such as, but not limited to, device capabilities, load balancing, or device or system settings or connections. Exemplary routing policies are discussed further below, with reference to IP trunk groups, which facilitate implementation of the routing policies.

[040] Figs. 2 - 4 illustrate three basic types of IP interconnections that can form IP trunk groups. The IP interconnections are logical IP interconnections rather than physical. It is to be understood that these are not the only Lypes of IP trunk groups. The exemplary types illustrated in Figs. 2 - 4 have been developed with regard to variations in carrier IP network interconnection profiles and equipment capabilities. Selection of a type of IPTG can depend on numerous considerations such as, but not limited to, the ability and willingness of the carrier to support call distribution and load balancing across the backbone IP interconnection edge topology, the ability and willingness of the carrier to use congestion control mechanisms for both inbound and outbound flows, and the ability and willingness of the carrier Io normalize SlP signaling in accordance with SlP interface specifications of the backbone network and follow standardized SlP behaviors. While the foregoing are not the only considerations in determining the optimal IPTG interconnection type, they account for some important factors.

[041] Fig. 2 illustrates one possible type of IP interconnection 200 that can form a component of an IP trunk group (IPTG). In this embodiment, the backbone network 102 IP edge node 122 is logically connected to the carrier edge node 124 of the carrier network 106. The type of IP interconnection illustrated in Fig. 2 is referred to as an IP direct interconnection 200. IP direct interconnections 200 are "direct" SIP/IP connections between the backbone network IP edge nodes 122 and the carrier edge nodes 124. The term "direct" is used here merely to distinguish this type of interconnection from other types of interconnections described below that include Load Balancers (LBs). Although the IP interconnection 200 does not utilize LBs, it will be understood that between the IP edge node 122 and the carrier edge node 124 there may be routers and other devices that facilitate communication between the nodes.

[042] An IPTG formed from the IP interconnection type of Fig. 2 can be characterized by a number of elements. The logical path 202 of the interconnection 200 corresponds to the IPTG identification. λs discussed further below, the logical path 202 is given a name or other identifier with which the IPTG can be associated and referenced. λn internal IP address 204 is a SIP signaling IP address of the IP edge node 122 thai controls the iPTG. l he internal IP address 204 is private and internal to the backbone network 102. The IPTG is further characterized by lhe name or other identifier υf the IP edge node 122 that controls the IPTG. A public external IP Address 206 of Lhe IP edge node 122 is a SIP signaling IP address that is accessible to one or more carrier edge nodes 124. A public external IP address of the carrier edge node 124 is a SIP signaling IP address involved with the IPTG. The IPIG is further characterized by the name or other identifier of the carrier edge node 124.

[043] In embodiments that use IP direct interconnections 200, the backbone network 102 IP edge node 122 manages the IPTG on both an inbound (i.e., into the backbone network 102 from the carrier IP network 106) and outbound (from the backbone network 102 to the carrier IP network J 06) basis. For example, the IP edge nodes 122 determine the appropriate IP originating trunk group (OTG) for the call and pass an OTG identifier to the CRE. With regard to outbound calls, the IP edge nodes 122 translate the provided destination trunk group (DTG) into a specific carrier IP Address (or set of IP addresses). [044] In addition, for embodiments that use direct IP interconnections 200 the carrier edge node 124 manages load baLancing between multiple backbone network 102 IP edge nodes 122 for inbound calls. Likewise, outbound call load balancing between carrier edge nodes 124 is handled by the IP edge nodes 122 at the IP address layer, and the CRE at the IPTG layer. Stated differently, the backbone network 102 CRE 1 18 balances load between IPTGs while the backbone network 102 IP edge nodes 122 balance load between IP addresses, if there is more than one carrier IP address in the IPTG.

[045] Fig. 3 illustrates another type of IP interconnection 300. This type of IP interconnection 300 uses a SIP re-direct load balancer for inbound calls (i.e., from Lhe carrier network 106 to the backbone network 102), and follows the same convention as the IP direct interconnection type (e.g., 200, Fig. 2) for outbound calls (i.e., from the backbone network

102 to the carrier network 106). The type of IP interconnection shown in Fig. 3 is referred to as an inbound load-balanced IP interconnection.

[046] λn IPTG that includes an inbound load-balanced IP interconnection can be characterized by a number of elements. The logical path 302 between the carrier edge node 124 and the IP edge node 122 corresponds to the IPTG Identification. As discussed further below, Lhe logical path 302 is given a name or other identifier with which the IPTG can be associated and referenced. An internal IP address 304 is a SlP signaling IP address of the IP edge node 122 that controls the IPTG. The internal IP address 304 is private and internal to the backbone network 102. The IPTG is further characterized by the name or other identifier of the IP edge node 122 that controls the IPTG. A public external IP Address 306 of the IP edge node 122 is a SIP signaling IP address that is accessible to one or more carrier edge nodes 124. A public external IP address 308 of the carrier edge node 124 is a SlP signaling IP address involved with the IPTG. The IPTG is further characterized by the name or other identifier of the carrier edge node 124.

[047] In an inbound load-balanced IP interconnection a SIP re-direct load balancer

310 is employed so that inbound SIP signaling from the carrier edge nodes 124 is balanced across multiple IP edge nodes 122. The IPTG including an inbound load-balanced IP interconnection is further characterized by an IP Address 312 of the SIP re-direct load balancer 310. Inbound load-balanced IP interconnection 300 types are similar to direct IP Interconnections in the sense that in both types the backbone network 102 IP edge nodes 122 manage the IPTG on both an inbound and outbound basis. However, lhe SIP re-direct load balancer 310 provides a layer of abstraction between the carrier edge nodes 124 and lhe backbone network 102 edge node 122 topology.

[048] In lhe inbound load-balanced IP interconnection 300, inbound carrier calls are sent to the SII ³ re-direct load balancer 310. The LB 310 responds with a 300 MC SlP message containing one or more backbone network 102 IP edge node 122 external IP addresses. The IP edge nodes 122 determine the appropriate origination trunk group (OTG) and pass the OTG's identifier to the CRE 1 18. As with direct IP Interconnection type, for outbound calls the IP edge nodes 122 translate the provided DTG into a specific carrier edge node IP Address (or set of IP addresses). Outbound call load balancing between the carrier edge

nodes 124 is handled by the IP edge nodes 122 at the IP layer, and the CRE 118 at the IJ ⁵ TG layer.

[049] In some embodiments that are not shown, an outbound SIP re-direct load balancer can be employed at the backbone network 102. In this embodiment, the IP edge nodes 122 send calls Io the outbound load-balancer (not shown) and the outbound load- balancer responds with one or more external IP addresses of the carrier network edge nodes 124. This type of IP interconnection is referred to as an outbound load-balanced IP i n Ler connec lion.

[050] In yet another embodiment, both an outbound SIP re-direcl load balancer is employed at the backbone network 102 and an inbound SIP re-direcl load balancer is employed at the carrier network 106. This type of IP interconnection is referred to as a hybrid load-balanced IP interconnection.

[051] Fig. 4 illustrates yet another type of IP interconnection 400 that can be used in

IPTGs. The IP inlerconneclion 400 shown in Fig. 4 is referred to as a SIP proxy load balanced IP interconnection because a SIP proxy load balancer 402 is logically positioned between the IP edge nodes 122 of the backbone network 102 and the carrier edge nodes 124 of the carrier network 106. The SlP proxy load balancer is used for both inbound and outbound calls.

[052] An IPTG that includes a SIP proxy load-balanced IP interconnection 400 can be characterized by a number of elements. The logical path 404 between the carrier edge node 124 and the SIP proxy load-balancer 402 corresponds to the IPTG identification. The logical path 404 is given a name or other identifier with which the IPTG can be associated and referenced. An internal IP address 406 is a SIP signaling IP address of the IP edge node 122 thai controls the IPTG. The internal IP address 406 is private and internal to the backbone network 102.

[053] The IPTG is further characterized by the name or other identifier of the IP edge node 122 that controls Lhe IPTG. A public external IP Address 408 of the IP edge node 122 is a SIP signaling IP address that is included in the IPTG. A public external IP address 410 of the carrier edge node 124 is a SIP signaling IP address involved with the IPTG. The IPTG is further characterized by the name or other identifier of the carrier edge node 124 involved with the IPTG.

[054] The SIP proxy load balancer 402 used by the carrier edge nodes 124 is for inbound SlP signaling and the backbone IP edge nodes 122 for outbound SIP signaling. In the embodiment of Fig. 4, the backbone IP edge nodes 122 only partially manage the IPTG. λs with the inbound SIP re-direct load balanced type of IP interconnection 300 shown in Fig. 3, the SlP proxy load balanced interconnection 400 provides a layer ol abstraction between the carrier edge node and the backbone IP edge node 122 topology. In addition, the SIP proxy load balanced IP interconnection also abstracts the carrier edge node 124 topology and IP addressing from the backbone IP edge nodes 122. Because ol this bi-directional abstraction, the management of IPTGs is distributed between the edge nodes 122, 124 and the load balancers 400.

[055] Inbound calls arriving from carrier networks in a SlP proxy load balanced IP interconnection will be directed to a public IP address on the LB 402. The SlP Proxy LB 402 determines the correct IP OTG for the call and chooses the appropriate backbone IP edge node 122 to be used for the call. This selection can be based on varying algorithms to achieve load balancing, geographic POI optimization, etc.

[056] When an inbound call arrives at the backbone IP edge node 122, the call will already contain an IP OTG designation that was determined from the SlP Proxy LB 402. I hus, the backbone IP edge node is not responsible for determining the IP OTG and passes the IP OTG information on to the CKE 118.

[057] With regard to outbound calls from the backbone network 102 on a SIP proxy load balanced IP interconnection 400, the backbone IP edge nodes receive a specified IP DTG to be used for call termination. This IP DTG is resolved into the appropriate SIP Proxy LB 402 IP Address 412, rather than the carrier edge node IP address 410. As such, the backbone IP edge node is responsible for passing the call to the correct SlP Proxy LB 402 while maintaining the specified IP DTG in the call's signaling. Subsequently, the SIP Proxy LB 402 resolves the IP D IG into one or more carrier edge node IP addresses and forwards the call appropriately.

[058] Figs. 5a - 5d illustrate a number of different IP trunk group use scenarios and arrangements. In general, an IP ti imk group is defined by one IP address on the edge node of a first network, and one or more IP addresses on one or more edge nodes of a second network.

[059] In Fig. 5a, multiple IP interconnections 502a - 502n exist between an edge node 504 and multiple carrier interface nodes 506a - 506n. The edge node 504 has an external IP address 508. Each of the carrier interface nodes 506a - 506n have a corresponding external IP address 510a - 51On, respectively. In one scenario, a first IP trunk group 512 logically includes interconnections 502a - 502n. In another scenario, a second IP trunk group 514 and a third IP trunk group 516 are defined. The second IP trunk group 514 logically includes IP interconnection 502a, while the third IP trunk group 516 logically includes IP interconnections 502b - 502n.

[060] In Fig. 5b., a first IP interconnection 518a exists between a first IP address

520a of a first edge node 522 and a first IP address 524a of a carrier interface node 526. A second IP interconnection 518b exists between a second IP address 520b of the first edge node 522 and a second IP address 524b of the carrier interface node 526. In this scenario, two IP trunk groups are defined. A first IP trunk group 528 logically includes the IP interconnection 518a, and a second IP trunk group 530 logically includes the IP interconnection 5J 8b.

[061] In Fig. 5c, a first IP interconnection 532a exists between an IP address 534 of an edge node 536 and a first IP address 538a of a carrier interface node 540. A second IP interconnection 532b exists between the IP address 534 of the edge node 536 and a second IP address 538b of the carrier interface node 540. Three possible IP lrunk groups can be defined given this arrangement. A first IP TG 542 includes both IP interconnection 532a and IP interconnection 532b. A second IPlG includes only IP interconnection 532a, while a third IPTG includes only IP interconnection 532b.

[062] In Fig. 5d, multiple IP interconnections 544a - 544n exist between associated backbone IP edge nodes 546a - 546n and a single carrier edge node 548. In this arrangement, each IP interconnection 544 can be defined as an IPTG, but more than one of the IP interconnections 544 are not grouped together.

Geographic Trunk Groups

[063] In some embodiments, there may be locations with multiple carrier edge nodes that require multiple connections to one or more geogiaphically diverse IPMG at the backbone network, lhis often requires a full mesh between carrier servers and multiple

backbone IPMGs. An IPMG provides IP-to-JP border control and PSTN MG capabilities such as integrating security, session control, and media control. In some embodiments, an IPMG is a type of backbone edge node.

[064] The above definitions of IPTGs included one-to-one, one-tυ-many, and many- to-one implementations, such as in the examples illustrated in Figs. 5A through 5d. In order to manage a many-to-many interconnection of IPTGs, the concept of a geographic trunk group (GTG) is introduced. A GTG provides the ability Lo provide a location that includes multiple carrier servers (and possibly multiple interfaces per carrier server) to two or more backbone locations that have one or more IPMGs each. Each GTG includes a set of attributes thai define how each backbone IPMG in the GTG communicates with each carrier server in the GTG. In the most general terms, a GTG encompasses the routing from a backbone gateway location (including one or more backbone edge nodes) to a carrier location (including one or more carrier edge nodes). In some embodiments, a GlG represents a connection between a single backbone gateway location and a single carrier location. As such, a GTG may contain multiple IPTGs.

[065] Fig. 6a is a block diagram representing the logical interconnects provided by a GTG. In tire illustrated embodiment, the two GTGs 620, 625 are provided from two backbone GWs 610, 615 to a carrier site 630 for redundancy purposes.

[066] Fig. 6b is a block diagram representing a more detailed representation of an embodiment of logical interconnections provided by a GFG. As shown, a GVV Site 610, 615 may contain one or more IPMG 612, 614, 616, 618, where an IPMG can have one or more IP addresses. Each GW Site 610, 615 may also contain one or more load balance servers (LBSs). For example, as illustrated in fig. 6b, GVV Sites 610, 615 contain multiple LBS platforms 642, 644, 646, 648. Generally, all LBS platforms associated with a particular GW site share the same IP address, so that they logically appear as a single entity. The sharing of an IP address by an LBS platform allows the LBS to scale by adding more platforms as needed to meet the performance requirements of a GW Site. However, in some embodiments, it is envisioned that each LBS platform may have a unique IP address.

[067] Fig. 6b also shows that a GTG 620, 625 may include one carrier site 630, where a carrier site contains one or more IP Addresses. Usually, one IP Address represents one carrier server 635 at the carrier site 630. However, in some cases, a single carrier server 635

may contain multiple IP addresses. The GTG does not depend on this relationship, but the carrier site object may want to capture this information to help with troubleshooting or oilier carrier communication.

[068] As mentioned above, embodiments of the GTG model may use one or more

LBS to aggregate signaling, thereby making the GTG possible. Fig. 7a is a block diagram illustrating communications in a GTG to multiple IPMGs 712, 714, 176, 718, in. a backbone network from multiple carrier servers 735 al a carrier localion. An LBS 722, 724, 726, 728 j nay be utilized to derive an UlG, pick an ordered list of IPMG based on various criteria, and send a signaling invitation to a selected IPMG with the OTG tag. The IPMG and/or CRE (not shown) at the backbone network may then use the OTG tag to determine a GTG policy to apply and a class of service Io use for routing the communications.

[069] Fig. 7b is a block diagram illustrating communications in the GTG from an

IPMG 712, 714, 716, 718 to multiple carrier servers 735. Embodiments of the invention may assign a same IPTG to multiple IPMGs 712, 714, 716, 718, so thai a CRE 750 may use the IPMG DTG to identify a specific line to try for a call request. The IPMG 712, 714, 7J6, 718 may then pass the DTG tag Io the LBS 722, 724, 726, 728. Subsequently, the LBS 722, 724, 726, 728 derives an ordered list of carrier servers 735 of the GTG to send the call request based on carrier-defined criteria.

[070] Figs. 7c and 7d are block diagrams depicting a two-location carrier with three servers at each location connected to two backbone GW sites with two IPMGs each. Specifically, Fig. 7c depicts a carrier-lo-backbone call flow network implementation and Fig. 7d depicts a backbone network-to-carrier call flow implementation.

[071] Fig. 7c illustrates (he logical mesh between an LBS 722, 724, 726, 728 and multiple carrier locations 730, 740 with communications traveling from the carrier sites 730, 740 to the backbone network 750. In some embodiments, this logical mesh does not need management. Each LBS 722, 724, 726, 728 at a GW shares the same IP address that is advertised to the carrier 730, 740. An LBS 722, 724, 726, 728 aggregates n-number of carrier servers 735, 745 into a single OTG label. The LBS 722, 724, 726, 728 then sends the OTG tag to the IPMG 712, 714, 716, 718. Embodiments of GTGs allow the same IPTG to reside on multiple IPMG 712, 714, 716, 718. The backbone network, or more specifically a CRE 750 of

the backbone network, applies class of service and policies Io the logical GTG (and thereby IPTG) instead of to each individual trunk.

[072] Fig. 7ά illustrates the logical mesh between LBS 722, 724, 726, 728 and multiple carrier sites 730, 740 with communications traveling from the backbone network 750 to the carrier sites 730, 740. In some embodiments, the logical mesh does not need management. Some embodiments of the invention accommodate the LBS 722, 724, 726, 728 being any one of a proxy or a redirect sei ver. Each LBS 722, 724, 726, 728 at a GW 720, 725 shares the same IP address thai is advertised to lhe carrier 730, 740. In addition, each LBS 722, 724, 726, 728 aggregates n-number of carrier servers 735, 745 into a single DTG label. The IPMG 712, 714, 716, 718 lhen sends the DTG tag to the LBS 722, 724, 276, 728. The LBS 722, 724, 726, 728 then selects from a list of carrier servers associated with the GTG to route the communications.

[073] In some embodiments of the GTG implementation, a same IPTG (e.g., OTG,

DTG) can reside on multiple IPMG 712, 714, 716, 718. The backbone network 750 routes to the logical IPTG (IPMG: DTG or carrier server: OTG) instead of to each individual trunk. Class of service and other policies should apply to the entire IPTG, instead of each individual IP Irunk. However, in some embodiments, multiple IPTGs that cross an IPMG may each need their own policies. Additional advantages of GTGs include their ease of scaling. For example, scaling of carrier servers does not affect CRE Routing because when adding carrier servers at a carrier site, the LBSs may utilize updaLes in order to add the new carrier server(s) to an IPTG, instead of affecting the CRE routing. Likewise, the scaling of IPMG at the backbone network simply adds one more route to a CRE Nested Route Label for an IPTG.

DaIa Structures

[074] Fig. 8a illustrates an exemplary data structure 800 in the form of a data table, which can be used to store definitions of IP trunk groups. In this embodiment, regardless of the IP interconnection type used, there is a fundamental set of parameters that describe an IPTG for the purposes of call processing, reporting, mediation/billing, and provisioning. A standardized database of records may or may not be used to maintain these IPTG attributes so they can be used by other provisioning, reporting, routing, and configuration systems.

[075] In the table 800, there is a set of attribute names 802, a sel of attribute values

804 and a set of constraints 806. With regard to constraints 806, "S" means a Single Value is allowed per IPTG, "M" means that multiple values are allowed per IPTG, U means that a globally unique value is used per IPTG, and "N" means that a non-unique value can appear in multiple IPTGs.

[076] Referring now to the attribute names 802, every trunk group has a trunk group ID (TGID) 808. In the illustrated embodiment, the IPTG TGID field is a numeric value that serves as the overall name or reference for the IPTG. In one embodiment, the TGID is a globally unique value that is generated by an IPTG database when the associated IPTG is created.

[077] An internal IP data field 810 contains a single standard IP address, signaling port, and transport type that denotes where the backbone network internal signaling should be sent to reach a specified IP D I G. Each IPTG typically has a single Internal IP Address assigned to it, as IPTGs do not span multiple stateful edge devices. The internal IP data attribute 810 is used by the CRE in conjunction with the TGID to denote a route choice in the backbone network. The three informational elements of this field can be separated into individual related fields.

[078] A facility name attribute 812 denotes the name of the facility in the backbone network that corresponds to the internal IP address for the TGID. Each IPTG will typically have a single internal IP address assigned to it, as IPTGs do not span multiple staleful edge devices. In various embodiments, the facility name attribute is sized to accommodate a single 30 character alphanumeric value.

[079] An external IP data attribute 814 contains a single IP address, signaling port, and transport type that denotes the backbone IP edge node of the IPTG. The external IP data attribute 814 specifies the public-facing IP address on the backbone network IP edge node for tills associated TGID. In this embodiment, each TGlD will contain a single value for the backbone network external IP address. In SIP proxy load-balanced IP interconnections, the external IP data attribute will not be used because the IPTG is not anchored to the backbone network IP edge node on the carrier network facing side. The three informational elements of this field can be separated info individual related fields if desired.

[080] A carrier IP data attribule 816 designates IP addressing information for the carrier edge nodes involved with the IPTG. In one embodiment, the IP data value denotes the IP Address(es), signaling port(s), and transport lype(s) associated with the TGID. The carrier IP data value may contain multiple sets of IP information per a single TGIU. In one embodiment, the carrier IP data is sized to initially accommodate ten sets of IP information and is able to be increased in the future if needed. The information in the carrier IP data field 816 may be separated into multiple related fields if desired.

[081] A carrier facility name attribute 818 designates the facility name of the carrier

IP address(es) involved with the IPTG. In this embodiment, there is an associated facility name provided for every IP Address in the carrier IP data attribute 816. In one embodiment, lhc carrier facility name value is sized Lo initially accommodate ten facility names, with each facility name up to 20 alphanumeric characters, and the value may be able to be increased in terms of additional facility names in the future if needed.

[082] A size attribute 820 designates the size of the IPTG. In this embodiment, the size value contains a single three digit value that represents the TG's equivalent size in TIs. The size attribute is used by lhe CRE when performing proportional routing allocation between TGs. In various embodiments, business and process rules are built around how the size value is determined. This may involve applying system safeguards and/or constraints. [083] A pseudo carrier code (PCC)/cu stonier profile value (CPV) attribute 822 is used by the CRE to apply customized routing on an OTG basis. In one embodiment, the PCC/CPV value contains a single five digit value that represents the TGID's PCC. [084] An E911 type attribute 824 is used for proper routing of B91 1 calls for the

IP TG by the CRE. In this embodiment, the E91I value contains one of three possible values that represent the TGID's E91J service type: [085] N/A: this TGID does not require or is not allowed to use E91 1 service

[086] 12: this TGID requires E911 i2 type routing

[087] TRADITIONAL: this TGlD requires traditional CPN type E91 1 routing

[088] A route advance profile attribute 826 specifies a route advance profile related to the IPTG. In one embodiment, the route advance profile value contains a single three

digil value that denotes a specified route advance profile. The route advance parameters associated with each profile can be maintained in memory, and can be represented by an alphanumeric identifier, such as a three digit value. In accordance with some embodiments, the route advance profile attribute 826 is only applicable for IPTGs that are Bi-directional or

Inbound from a directionality standpoint, and egress-only IPTGs will have a default value of

000 in this field.

[089] A signaling normal izal ion profile attribute 828 is used for signaling normalization designation. Jn one embodiment the signaling normalization profile attribute

828 value contains a single three digit value that denotes a specified signaling normalization profile. These profiles can be maintained in memory and can be represented by an alphanumeric identifier, such as a three digit value.

[090] A directionality attribute 830 can be used to ensure that systems such as route analysis tools are aware of IPTGs that are available for call termination, hi one embodiment, the directionality attribute 830 contains one of three possible values that represent the lPTG's directionality:

[091] B (Bi-directional IPTG that supports both Ingress and Egress use)

[092] E (Egress-only IPTG supporting outbound use (DTG) only)

[093] I (Ingress-only IPTG supporting inbound use (OTG) only)

[094] A hunt sequence attribute 832 designates how an IP edge node should distribute calls across an IP I G when multiple carrier IP addresses exist. In one embodiment, the value for the hunt sequence attribute 832 can take on one of the following values:

[095] P: calls will be sent to the IP addresses as a function of their priority

[096] LB: calls will be evenly distributed between all carrier JP addresses

[097] The hunt sequence value can be used by the backbone edge device that manages the IP DTGs to ensure calls are distributed to carriers in the desired manner.

[098] A regulatory nature attribute 834 indicates the regulatory nature of calls arriving on the IPTG. In one embodiment, the value of the regulatory nature attribute is selected from two possible values

[099] E (all calls are considered to be Enhanced)

[0100] N (all calls are considered to be Non- Enhanced)

[0101] The regulatory nature attribute can be used by various backbone network provider systems to track the regulatory nature of the IF Inlercoanections.

[0102] A carrier ID attribute 836 denotes a carrier identifier for the carrier associated with the IPTG. In one embodiment the carrier ID value contains a single 20 character alphanumeric value representing the carrier's name as a function of other systems within the backbone network provider.

[0103] An allowable codecs attribute 838 denotes values associated with codecs and packetizalion Intervals. In one embodiment, values for the allowable codecs attribute contain up to ten values that denote the desired and/or supported media codec and packetization intervals for the IPTG. Each value may be in the formal of codecpacketization

(e.g. G.711:20ms). In one embodiment the allowable codecs value is sized to accommodate ten values, each no larger than 20 alphanumeric characters. The allowable codecs attribute

838 can be used by the backbone network to establish the supported and preferred media types for an IPTG.

[0104] A product ID attribute 840 denotes a product associated with the IPTG. In one embodiment, the product ID value contains a single 20 character alphanumeric value related to a the backbone network provider product name.

[0105] An interconnection type attribute 842 denotes the type of IP interconnection for the IPTG. Exemplary values for the interconnection type attribute are alphanumeric identifiers associated with the type. Exemplary types are described above, such as direct IP interconnection, SIP inbound re-direct load balanced IP interconnection, and SIP proxy load balanced IP interconnection.

[0106] A backbone network load balancer (LB) IP data attribute 844 is used for the

SIP load balanced IP interconnection types (e.g., inbound, outbound, hybrid, or proxy). The

LB IP data attribute 844 denotes the LB IP addresses, port, and transport mechanism that are associated with the TGID. In this embodiment the field for the value is sized to accommodate four IP addresses.

[0107] A backbone network load balance type attribute 846 denotes the type of backbone network load balancing used for the IPTG. In accordance with one embodiment,

the load balance type attribute 846 can take on the following values: redirect - related to a SlF re-direct load balanced IP interconnection; and proxy - related to a SlP proxy load- balanced IP Interconnection.

[0108] A carrier equipment data attribute 848 contains an alphanumeric value representing the carrier network's equipment (e.g., carrier edge node). In one embodiment, the carrier equipment data attribute value is a single 30 character alphanumeric value. It will be understood thai the attributes, fields, data, and formats illustrated in Fig. 10 and described above are for illustration purposes only. The invention is not limited to the illustrated and described implementation.

[0109] Figs. 8b through 8e illustrate exemplary data structures in the form of data tables which can be used to store the overall definitions of a GTG according to an embodiment of the invention. In this embodiment, regardless of the IP interconnection type used, there is a fundamental set of parameters that describe an GTG for the purposes of call processing, reporting, mediation/billing, and provisioning. A standardized database of records may or may not be used to maintain these GTG attributes so they can be used by other provisioning, reporting, routing, and configuration systems. In the tables of Figs. 8b - 8c, there is a set of attribute names 802 and a set of attribute values 804, as previously described with respect to table 800. One skilled in the art will appreciate that a set of constraints 806, similar to those used in table 800 may also be utilized, although not specifically illustrated in the table of Figs. 8b - 8e.

[0110] Fig. 8b illustrates an exemplary data structure 801 in the form of a data table, which can be used to store definitions of a GTG. Table 801 specifically provides the attributes for GTG 1 of Figs. 7c and 7d. Table 801 includes altribules that were previously defined with respect to table 800, with the addition of GW site attribute 850 and Customer Site attribute 852. GW Site 850 and Customer Site 852 define the specific locations of the GW and Customer site associated with the GTG.

[0111] Fig. 8c illustrates an exemplary data structure 803 that defines the IP TG mapping for an IPMG of a specific GTG. Specifically, table 803 is defining IPMG NY 01 712 of NY GW 710 in GTG 1 of Figs. 7c and 7d. Table 803 includes some previously-defined attributes, with [he new additions of the Local IP attribute 854 and the remote IP attribute 856. Local IP 854 defines the IP address of lhe IPMG associated with GTG 1, while remote IP

856 defines the LBS associated with GTG J . Table 803 varies depending on the IFMG being defined for a GTG.

[0112] Fig. 8d illustrates an exemplary data structure 805 that defines a GW location in a specific GTG. In particular, table 805 defines the NY GW site 710 of Figs. 7c and 7d.

Table 805 includes an IPMG addresses attribute 858 which defines the IF addresses of the

IPMG included in the particular GVV site (i.e., NY GW 710) of the GTG. Table 805 also includes the hunt sequence attribute to dictate how an IPMG is chosen within the GW site.

Lastly, table 805 includes an LBS address attribute 860 which defines the LBS IP address associated with the GVV site.

[0113] Fig. 8e illustrates an exemplary data structure 807 that defines a customer site location in a specific GTG. In particular, table 807 defines the NY location 730 of Figs. 7c and

7d. Table 807 includes a server addresses attribute 862 which defines the IP addresses of all of the servers located at the customer site. Table 807 also includes a hunt sequence attribute

838 to define the hunt protocol used to select a particular customer server at the customer site.

[0114] One skilled in the art will appreciate the multiple variations of the tables in

Figs. 8b through 8e may be utilized to define the multiple components included in a GTG.

The specific tables used in Figs. 8b through 8e are solely used for exemplary purposes.

[0115] Fig. 9 illustrates an exemplary scheme that can be carried out by a core routing engine of a backbone network for routing inbound calls to outbound IP trunk groups in accordance with one embodiment. When a SIP request comes into the core routing engine, the core routing engine extracts the called telephone number 902. The core routing engine then identifies a corresponding route label from among multiple route labels

904 a - 904n that are associated with telephone numbers.

[0116] Each route Jabei 904 has an associated set of TGIDs 906. For example, route label 904a has an associated set of TGIDs 906a, route label 906b has an associated set of

TGIDs 906b, and so on. A TGID may or may not be associated with more than one route label 904.

[0117] After the core routing engine determines the appropriate route label 904, the core routing engine determines which TGID to which the call should be sent. The core routing engine uses a TG traffic distribution policy 908 associated with the selected route

label 904 to choose the TGlD. In one embodiment, each TG traffic distribution policy 908 specifies an order in which lhe TGIDs should be used. Some exemplary traffic distribution policies are round robin, sequential, and percent allocation. Other traffic distribution policies can be used.

Exemplary Operations

[0118] Figs. 10 - 1 i illustrate processes that can be carried out to define one or more

IP trunk groups and use the defined trunk groups for routing calls through a backbone network. One or more of the operations shown in Figs. 10 - I J can be embodied in a computer program product and executed by a computing device, such as a core routing engine, an edge proxy server, oi a session border controller. The particular order of the operations shown is not absolute. Some of the operations can be rearranged, merged, and/or broken out into multiple operations, depending on the particular implementation, without departing from lhe scope of the present invention.

[0119] In Fig. 10, a process 1000 is illustrated for defining one or more IPTGs. In and identifying operation 1002, one or more sets of IP interconnections are identified, wherein each set can properly and desirably be aggregated into associated IP trunk groups. Each set of IP interconnections includes one or more IP interconnections. Generally, IP interconnections that are grouped together are logically similar or have commonalities that might offer economies of scale in grouping the interconnections Lo together, but this is not necessary.

[0120] A determining operation 1004 determines an IP interconnection type for each of the sets of IP interconnections identified in operation 1002. Some exemplary IP interconnection types are described above, but others may be developed and used in the determining operation 1004. A defining operation 1006 defines an IP trunk group for each set of one or more IP interconnections that were identified in operation 1002. In one embodiment, the defining operation 1006 involves selecting values for a plurality of attributes such as those shown in Fig. 6. The defining operation 1006 also involves specifying one or more policies, such as traffic distribution policies (at the IPTG level and at the IP address level), E911 routing policies, directionality policies, and so on.

[0121] A provisioning operation 1008 provisions the IPTG definitions and policies to one or more backbone network IP edge nodes. Another provisioning operation 1010 provisions lhe IPTG definitions at one or more backbone network core routing engines. Provisioning may involve storing the definitions in a database accessible by the core routing engines and the edge nodes, or otherwise configuring the core routing engines and the edge nodes with the IPTG definitions. After the IPTG definitions are provisioned at the core routing engines and the edge nodes, they are used for routing calls through the backbone network.

[0122] Fig. I I illustrates one possible algorithm 1100 for routing calls through a backbone network using IPTGs. In a receiving operation 1102, a core routing engine receives a call request. The call may come in on a TDM trunk through a PSTN gateway, which forwards the request to the core routing engine. The core routing engine accesses a set of routing labels to determine where and how to route the call. In a selecting operation 1104, the core routing engine selects an IP trunk group from a number of defined IPTGs. Selecting the IPTG is based at least in part upon the called telephone number and one or more policies associated with Lhe IPTGs.

[0123] A forwarding operation 1 106 forwards the call request Io the selected IPl ¹ G.

More specifically, the forwarding operation 1106 sends the call request to an internal IP address associated with the selected IP TG. A routing operation 1108 is carried out by an edge node that received the call request. In the routing operation 1108, the edge node determines which IP address to route the call request to. The IP address may be associated with a carrier edge node or a SIP proxy load balancer. An IP address of a carrier edge node may be obtained from a redirection device such as a DNS server or a SlP redirector load balancer.

Exemplary Computing Device

[0124] Fig. 12 is a schematic diagram of a computing device 1200 upon which embodiments of the present invention may be implemented and carried out. As discussed herein, embodiments of the present invention include various steps. A variety of these steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor

programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware.

[0125] According to the present example, the computing device 1200 includes a bus

1201, al least one processor 1202, al ieast one communication port 1203, a main memory 1204, a removable storage media 1205, a read only memory 1206, and a mass storage 1207. Processor(s) 1202 can be any know processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), AMD® Opteron® or Athlon MP® processor(s), or Motorola ® lines of processors. Communication port(s) 1203 can be any of an RS-232 port for use with a modem based dialup connection, a 10/100 Ethernet port, a Gigabit port using copper or fiber, or a USB port. Communication port(s) 1203 may be chosen depending on a network such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computing device 1200 connects. The computing device 1200 may be in communication with peripheral devices (not shown) such as, but not limited to, printers, speakers, cameras, microphones, or scanners.

[0126] Main memory 1204 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in lhe art. Read only memory 1206 can be any static storage device(s) such as Programmable Read Only Memory (PROM) chips for storing slatic information such as instructions for processor 1202. Mass storage 1207 can be used Io store information and instructions. For example, hard disks such as Lhe Adaptec® family of SCSI drives, an optical disc, an array of disks such as RAID, such as the Adaptec family of RAID drives, or any other mass storage devices may be used.

[0127] Bus 1201 communicatively couples processor(s) 1202 with the other memory, storage and communication blocks. Bus 1201 can be a PCI /PCl-X, SCSI, or USB based system bus (or other) depending on the storage devices used. Removable storage media 1205 can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc - Re-Writable (CD-RW), Digital Video Disk - Read Only Memory (DVD-ROM).

[0128] Based on the disclosure provided herein, one of ordinary skill in the art will appreciate a myriad of behaviors that may be quantified using the presented approach. Further, based on lhe disclosure provided herein, one of ordinary skill in lhe arL will recognize a variety of ways that the aforementioned information may be used. For example,

lhe aforementioned information may be used in a proactive way to modify the design of a particular transaction network to achieve better performance. Alternatively, the aforementioned information may be used in a reactive way to cure identified failures in a network under lesl. Again, based on the disclosure provided herein, one of ordinary skill in the art will appreciate a variety of ways that the information may be used. [0129] Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while Lhe embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations together with all equivalents thereof.