GB2347045A - Gateway discovery - Google Patents

Abstract

Gateway-location requests from within an administrative domain of a packet-switched network are serviced by gateway location servers to identify a gateway with particular characteristics for passing a call from the packet-switched network to a circuit-switched network. Each server stores gateway data and utilises a tree data structure to interrelate gateways to the numbers they serve. Each node (410-415) of the tree represents a particular number prefix string and may have one or more gateways (A,B,C) associated with it, this association indicating that a gateway gives access to all number with the corresponding number prefix. The tree structure is so populated that the set of gateways, if any, serving the numbers encompassed by the number prefix of a node is constituted by the gateway or gateways identified by the node and the nodes traversed in descending to that node from the root node of the tree structure.

Description

Gateway Discovery Field of the Invention The present invention relates to a system and method for handling gateway-location requests from within an administrative domain of a packet-switched network, to identify a gateway with particular characteristics for passing a call from the packet-switched network to a circuit-switched network. The present invention relates, in particular, to a tree data structure, and its internal representation, in a gateway discovery system.

Background of the Invention With the growth of VoIP ("Voice over Internet Protocol") in which voice calls are carried as data packets on packet switched IP networks (for example, the public Internet), there is a need for inter-working between such networks and the old public switched telephone network (PSTN) and similar circuit-switched networks. The components that couple IP networks to the PSTN and similar networks are called gateways.

Figure 1 illustrates a known VoIP network based on the H. 323 protocol suite. As shown, the overall architecture divides the IP network 11 (generally a number of inter-connected smaller networks) into administrative domains (AD1-AD5). Each administrative domain AD is usually composed of equipment and network connections under common control and is divided into zones 13 each based around a gatekeeper 14. The endpoints 15 (terminals etc.) connected to the network within a zone are registered with the gatekeeper 14 of a zone. To place a VoIP call from one endpoint 15 to another requires the calling endpoint to contact its zone gatekeeper and have the latter talk to the zone gatekeeper of the desired called endpoint in order to obtain the IP address of the latter. Each administrative domain has a border gatekeeper 12 for the inter-exchange of information with other administrative domains.

Each zone 13 may also include one or more gateways 16 providing access from the IP network to the PSTN 17 in order to permit VoIP to terminate at, or originate from, standard telephones 18 (including mobile phones).

Of course, VoIP telephony (sometimes called Internet Telephony when practiced over the public Internet) may be effected according to signalling protocol standards other than H. 323. In particular, the SIP (Session Initiation Protocol), SAP (Session Announcement Protocol) and SDP (Session Description Protocol) protocol suite of the IETF (Internet Engineering Task Force) appears to present a viable alternative to H. 323. It is not critical to the present invention which particular signalling protocol suite is used for the basic VoIP network signalling and, for convenience, the terminology usually associated with the H. 323 protocols will be used when making reference to the basic VoIP system supported by the present gateway discovery method and system. Thus, the H. 323 term"gatekeeper" is used although the corresponding element according to the IETF protocol suite would be a SIP server.

For various reasons, there are likely to be a large number of companies operating gateways.

A problem with having large numbers of gateways available is how to discover the best gateway to use for converting a VoIP call into a PSTN call. Gateways have a number of properties, both on the IP and the PSTN side, characterising the their own capability, and since a given telephone will be reachable through a large number of gateways, a VoIP user might want to select a gateway with specific properties. The requirements of users might be very different although a common query will probably be to find the cheapest solution.

Another problem with having a large number of gateways is that whatever system is used to locate these gateways will need to be able to efficiently store and search large amounts of gateway data. It is an object of the invention to provide means facilitating such storage and/or handling.

Summary of the Invention According to the present invention, there is provided, in a gateway-discovery system, a tree data structure for relating E-164 numbers to gateways serving those numbers, the tree data structure having a plurality of nodes each of which: holds a number prefix segment, and --is associated with a number group encompassing at least one number and specified by a concatenation of the number prefix segments of the nodes traversed in descending the tree structure from its root node to the node concerned; at least one of said nodes identifying a gateway giving access to the number group associated with the node, and the tree structure being such that the set of gateways, if any, serving the number group specified by a node is constituted by the gateway or gateways identified by that node and the nodes traversed in descending to that node from the root node of the tree structure.

Preferably, each place position within said number prefix segments is represented by a binary word with the state of each of ten bits of the word indicating the presence or absence of a corresponding respective decimal digit value at that place position whereby a single binary word can be used to represent multiple digit values at the same place position of the number prefix segment, including non-consecutive ranges.

Brief Description of the Drawings A gateway discovery system and method employing the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which: . Figure 1 is a diagram of a known VoIP arrangement using the H. 323 protocol suite; . Figure 2 is a diagram illustrating the overall architecture of the gateway discovery system employing the present invention; . Figure 3 is a diagram illustrating the distribution of gateway data within the intra-AD part of a system employing the present invention; . Figure 4 is a diagram illustrating the gateway-data update process effected at a GLS server employing the present invention; . Figure 5 is a diagram illustrating the process of gateway summary generation at the Figure 4 GLS server ; . Figure 6 is a diagram illustrating the communication of gateway summary data between the components of a gateway discovery system employing the present invention; . Figure 7 is a diagram illustrating for the Figure 3 embodiment how a gateway location request is handled in the case where an appropriate gateway is directly known to the GLS server receiving the request; . Figure 8 is a diagram illustrating for the Figure 3 embodiment how a gateway location request is handled in the case where an appropriate gateway is known to a GLS server in the same domain as the one receiving the request; . Figure 9 is a is a diagram illustrating for the Figure 3 embodiment how a gateway location request is handled in the case where an appropriate gateway is in a different domain to the GLS server receiving the request; . Figure 10 is a diagram illustrating replication of gateway data between GLS servers; . Figure 11 is a diagram illustrating load sharing between GLS servers that have overlapping number responsibility; . Figure 12 is a diagram illustrating an tree data structure embodying the present invention for use in storing gateway data at a GLS server ; . Figure 13 is a diagram illustrating a tree structure embodying the present invention built according to a preferred update algorithm; . Figure 14 is a diagram illustrating a gateway summary generation process effected by a GLS server when applying a basic exclude/retain simplification rule; . Figure 15 is a diagram illustrating a gateway summary generation process effected by a GLS server when applying a banding simplification rule; . Figure 16 is a diagram illustrating a fully-meshed relationship between border elements of the gateway discovery system; . Figure 17 is a diagram illustrating a peering relationship between border elements of the gateway discovery system ; . Figure 18 is a diagram illustrating a federation relationship between border elements of the gateway discovery system; . Figure 19 is a diagram illustrating a clearing-house relationship between border elements of the gateway discovery system; Figure 20 is a diagram illustrating a trading house relationship between border elements of the gateway discovery system; and . Figure 21 is a diagram illustrating a hybrid relationship between border elements of the gateway discovery system; Best Mode of Car'nu Out the Invention The gateway discovery system and method to be described below is intended to service gateway-location requests from gatekeepers 14 and other elements for the contact details of a gateway that can provide access to a specified PSTN (or PLMN or similar) number and has particular desired characteristics. The gateway-location request will include the specified number to be contacted and the characteristics required of the gateway. The present system and method are not concerned with how the PSTN number has been obtained or how the gateway contact details are subsequently used to set up a call to the number.

As illustrated in Figure 2, the overall architecture of the gateway discovery system employing the invention involves two main parts that inter-work to provide a total solution. The first part is the intra-AD architecture involving, for each AD of the IP network 11, a group 20 of one or more Gateway Location Servers (GLS) 22 that together know the details of the gateways 16 in their respective associated ADs (these details being the numbers for which the gateways can provide access and the access characteristics). The second part is the inter-AD architecture comprising a respective border element 21 for each GLS group 20 (ie each AD), these border elements 21 hold summary data about available gateway accesses to the PSTN and intercommunicate with each other as well as with their respective GLS groups 20.

When a gateway-location request is generated in an AD, it is passed to the related GLS group 20 which will examine the data it holds on the gateways 16 in the same AD to see if the request can be satisfied by any of these gateways. If this is possible, contact details for the gateway 16 concemed are returned to the requestor. However, if no satisfactory intra-AD gateway is found, the GLS group 20 contacts the local border element 21 to see if the latter can help on the basis of the summary data available to it.

This summary data may indicate that a GLS in a different group 20 may know of a suitable gateway and in this case, the GLS group servicing the gateway-location request can then seek further information from the indicated foreign GLS 22 to satisfy the request (as indicated by arrow 23 in Figure 2).

Before describing the gateway discovery system in more detail, it is worth outlining the notation used herein for E-164 numbers by reference to several examples illustrating how number prefixes can usefully be used to reduce the amount of information needed to specify collections of numbers: 0044117*. All numbers beginning with 0044117 0044117 [1-4] *. All numbers beginning with 00441171,00441172,00441173, 00441174 0044117*1*. All numbers beginning with 0044117 followed by one free digit, by the"1"digit and by a free number of free digits.

More particularly, the symbol"*"acts as a wild card representing all values and the symbol"."is an expandability indicator indicating that the symbol"*"is to be taken as repeated up to the maximum permissible number of times. Thus in Figure 2, one gateway 16 gives access to all number beginning with 0044117 whilst the other gateway gives access to all numbers starting with 0044118 or 0044120.

Further consideration will next be given, with reference to Figure 3, to the intra-AD architecture and how gateway details are distributed between the GLSs concerned. In the Figure 3 example, the represented administrative domain 100 has three GLS 110, 210 and 310 each of which is assigned responsibility for a subset of the total E-164 number range to be covered (not necessarily the full range, that is, not necessarily the whole world). Having number responsibility for a subset of numbers means that the GLS server concerned is responsible for answering gateway location requests arising in the AD for the numbers in that subset. The assignment of number responsibility to the GLS servers of an AD is preferably done by the administrator controlling that AD. For any given AD, the number of GLS servers and their number responsibilities can be decided independently of any other administrative domains. Each GLS server in an AD is aware of the number-responsibilities of all other GLS servers that operate in its AD.

In the Figure 3 example, the AD 100 is primarily concerned with E. 164 numbers in USA, Europe and Japan and has its own gateways (131,231,232,331) for accessing these regions. The GLS server 110 is assigned responsibility for USA numbers, the GLS server 210 is assigned responsibility for European numbers, and the GLS server 310 is assigned responsibility for numbers in Japan. Because it is also desired to permit access to numbers outside of the USA, Europe and Japan (rather than banning such access), responsibility for numbers outside of USA, Europe and Japan is also assigned, -in this case, each of the servers is given responsibility for the full range outside of USA, Europe and Japan. As already noted, each GLS is aware of the numberresponsibility of the other GLS servers in the AD 100 (see callouts 111, 211 and 311).

As well as having responsibility for particular number ranges, each server will generally be responsible for interfacing the gateway discovery system with particular gatekeepers of the same AD both for receiving gateway-location requests and for receiving details of gateways associated with those gatekeepers (generally a gateway will be registered with a gatekeeper but where this is not the case, the gateway may be registered directly with a GLS server of the same AD). In the Figure 3 example, GLS server 110 is responsible for communicating with gatekeepers 121 and 122, GLS server 210 is responsible for communicating with gatekeepers 221 and 222, and GLS server 310 is responsible for communication with gatekeeper 321. It should be noted that the association of a gateway with a particular GLS server (either directly or via a gatekeeper) is not constrained by any required relationship between the numbers served by the gateway and the number-responsibility of the GLS server; thus the gateway 131 may give access to numbers some or all of which are outside of the USA (for example, to telephone numbers in London and Tokyo).

Each GLS server maintains detailed information about all gateways serving numbers in the number range (s) for which they are responsible. If a gateway associated with a particular GLS server gives access to numbers outside the number-responsibility of the server, then it is the duty of the latter to pass on the details of the gateway to the relevant GLS server or servers in the same AD (that is, those other GLS servers having number responsibility for the numbers accessible through the gateway). Thus if gateway 131 gives access to telephone numbers in New York, London and Tokyo, then the details of this gateway are passed (directly or via gatekeeper 122) to GLS server 110 (arrowl50) which thereupon stores these details in respect of the New York numbers, and passes them on to GLS server 210 in respect of London numbers (arrow 151) and to GLS server 310 in respect of Tokyo numbers (arrow 152).

The gateway details published by a gateway (GW) or its related gatekeeper to the associated GLS server can, for example, comprise: GW ID, * GW Contact point (typically the address of the gatekeeper with which the GW is registered), * Cost (for terminating a call through this GW), codes supported, * Payment methods supported, and Authentication/ Authorization/Accounting Server address, Membership of the GW to Clearing Houses or Federations Figure 4 illustrates the process of a GLS server 50 receiving gateway details 51 on a gateway A, these details comprising the GW-ID ("A"), the access number range for the gateway ("+4411 [7-9] *."), the call cost ("2p/min"), codec supported ("G. 711"), and payment method ("Credit card"). For the sake of example, the GLS 50 is shown as having number responsibility for"+44117*.", that is, a subset of the numbers to which gateway A gives access. On receiving the details of gateway A, the GLS server 50 effects an update process 56 in which it adds a new record 52 to its gateway information base (GIB) that already includes records 54 and 55 for gateways K and L respectively. Since the gateway A gives access for the full number range for which GLS 50 is responsible, the access number range for record 52 is set to that number range, namely"+44117*.". As well as updating its GIB, the server 50 forwards the gateway details 53 for the number ranges not covered by GLS server 50 to the responsible server (s). Details of suitable data structures for the GIB will be given later on in this description.

Each GLS server is responsible for periodically sending a summarized version of the data held in its gateway information base to the border element of the AD in which the GLS server is situated. This summarized version will generally indicated that the particular GLS server concerned knows about gateways that can access specified number ranges-that is, the summary will include the gateway access number ranges and the identity/address of the relevant GLS server but generally not the gateway identity or contact details. Other key access details can be included s desired such as cost per minute. Figure 5 illustrates a simple case of summary generation in which two gateway records 57 and 58 from the GIB of a GLS server are combined by eliminating all gateway attributes other than cost and access number ranges-since the cost attributes of the two records are the same the two records can be combined into a single record 59. A more detailed description of the summary generation process will be given hereinafter.

As illustrated in Figure 6, the border element 61 of AD 60 receives summary data 62 from the GLS servers 63 of AD 60 and aggregates them. The border element 61 also receives summary data 64 published by other border elements 67-69 associated with other ADs and indicating the numbers accessible through the gateways of those other ADs. Depending on the aggregation policy being operated by the border element 61, the aggregated summary data for its own AD 60 may be aggregated with the summary data from the other border elements into a single GIB 70 or may be kept in a separate information base.

Summary data held by the border element is also published by border element 61 to other border elements with which it has associations. The nature of the association between the various border elements will determine precisely what information each border element publishes to each of the other elements with which it is associated. For example, the border element 61 may pass to border element 69 not only the summary data for AD 60 but also the summary data it has received from border element 68. A number of possible associations between border elements will be described later.

Border elements seek to obtain all summary data required to enable them to optimally respond when queried by GLS in their own AD about gateway access through gateways in other domains. To aid in this knowledge acquisition, border elements can also decide to actively build up their knowledge about other domains by querying the border elements of those domains. In addition, in case a border element does not, at a particular moment, have sufficient information to respond to a query from its own AD, a broadcast channel is also preferably provided between the ADs; all cooperating border elements are arranged to constantly listen on this channel with a view to one or more of them being able to respond to a query placed on this channel as a fallback method by a member border element seeking solution of a query.

Having described how gateway information is distributed around the components of the gateway discovery system, a description will now be given with reference to Figures 79 as to how gateway-location requests generated in the AD 100 of Figure 3 are resolved.

In Figure 7, endpoint A registered with gatekeeper 121 wishes to call phone B that has a number ("TelB") within the range of number responsibility of GLS server 110 and is accessible through gateway 131 in accordance with the attributes ("AttribA/B") specified by endpoint A. In this case, the following steps occur: [1] Endpoint A tells gatekeeper 121 that it wishes to call number TelB with access attributes AttribA/B.

[27 Gatekeeper 121 makes a gateway-location request to GLS server 110 for contact details of a gateway for accessing TeIB with attributes AttribA/B.

[37 GLS server 110 recognizes that TelB is within its number responsibility and examines its GIB to see if there are any gateways within AD 100 capable of accessing TelB with attributes AttribA/B. On finding that gateway 131 can provide such access, server 110 responds to the gateway-location request by sending gatekeeper 121 the contact details for gateway 131, namely the gateway ID and the address of the gatekeeper 122 with which the gateway 131 is registered.

//Gatekeeper 121 contacts gatekeeper 122 to initiate call setup through gateway 131.

In the Figure 8 scenario, the number TelB of the phone B that endpoint A wishes to contact lies within the number responsibility range of GLS server 210 and is accessible through gateway 232 with the desired attributes AttribA/B. Matters proceed as follows: [17 Endpoint A tells gatekeeper 121 that it wishes to call number TelB with access attributes AttribA/B.

//Gatekeeper 121 makes a gateway-location request to GLS server 110 for contact details of a gateway for accessing TelB with attributes AttribA/B.

[37 GLS server 110 recognizes that TelB is not within its number responsibility but within that of GLS server 210 and accordingly server 110 sends a request to server 210 to resolve the query.

[47 GLS server 210 receives the request from server 110 and examines its GIB to see if there are any gateways within AD 100 capable of accessing TelB with attributes AttribA/B. On finding that gateway 232 can provide such access, server 210 responds to the request from server 110 with the contact details of gateway 232.

[57 GLS server 110 now responds to the original gateway-location request by sending gatekeeper 121 the contact details for gateway 232.

[6] Gatekeeper 121 contacts gatekeeper 222 with which gateway 232 is registered to initiate call setup through gateway 232.

In the Figure 9 scenario, the number TelB of the phone B that endpoint A wishes to contact again lies within the number responsibility range of GLS server 210 but now there is no gateway in AD 100 capable of providing access to TelB in accordance with the access attributes AttribA/B specified by endpoint A. Matters proceed as follows: [1] Endpoint A tells gatekeeper 121 that it wishes to call number TelB with access attributes AttribA/B.

[27 Gatekeeper 121 makes a gateway-location request to GLS server 110 for contact details of a gateway for accessing TelB with attributes AttribA/B.

//GLS server 110 recognizes that TelB is not within its number responsibility but within that of GLS server 210 and accordingly server 110 sends a request to server 210 to resolve the query.

[47 GLS server 210 receives the request from server 110 and after examining its GIB ascertains that there are no gateways within AD 100 capable of accessing TelB with attributes AttribA/B. GLS server 210 now requests border element 90 of AD 100 for help in identifying an access to TelB through a gateway belonging to another AD. This request to border element 90 is made with a simplified set of required access attributes {AttribA/B} simple this simplified set having been derived from the attributes AttribA/B by applying the same simplification rules as used for generating the summary data 62 (Figure 6) sent by the GLS server 210 to the border element 90. It will be appreciated that it is not essential for the GLS server 210 to carry out this request simplification since the border element can extract the appropriate information from the full set of access attributes; however, it is more efficient to use a simplified request generated by the GLS server.

[57 Border element 90 checks the summary data held in its local GIB 70 (Figure 6) and finds that three GLS servers 91,92 and 93 in other Ads know of gateways providing access to TelB in accordance with {AttribA/B} simple. The contact details for these GLS servers are returned by border element 90 to GLS server 210.

[67 GLS server 210 next contacts one or more of the servers 91,92 and 93 to certain if any of these servers knows of a gateway providing access to TelB in accordance with the full set of attributes AttribA/B. If a contacted one of the servers 91-93 knows of such a gateway, it responds with the contact details of the latter. If none of the servers 91-93 can help until /7/If gateway contact details have been supplied in step [6], these are now returned by server 210 to server 110 ; if suitable gateway was found, a suitable reporting message is returned instead.

//GLS server 110 now responds to the original gateway-location request by either sending gatekeeper 121 the contact details for the identified gateway or by returning the failure report.

/9/Assuming that a gateway was found, gatekeeper 121 now uses the contact details of the gateway to set up the call.

The information received back by GLS server 210 from border element 90 about GLS servers in other domains is preferably cached at server 210 as a"hint"for later use against a similar query, these hints being examined if search of the local GIB at server 210 has proved unsuccessful in finding a gateway, and before the border element 90 is contacted. Although the"hints"may go out of date this is not critical because this will become apparent as soon as server contacts the relevant out-of-AD server indicated in the hint. Since every gateway-location request is always handled by the GLS server responsible for the involved number (s), the effect is that each GLS caches hints for the number-range it administers.

Whilst a GLS server will often only request information from its border element in order to respond to a gateway-location request, a GLS server can be arranged to preemptively ask for information from its border element about accesses to specific numbers or number ranges.

The above-described gateway discovery system is highly scalable since it does not require each GLS to store detailed information about all world gateways. The system also allows each company to organize and control their network in their own way.

Furthermore, when the overall network is stable and the caches at the GLS servers contain all relevant information all gateway location queries can be resolved locally within an Administrative Domain (AD) even when the gateway satisfying a request belongs to another AD.

In the described system, the GLS servers can take full advantage of data aggregation, enabling the system to deal with situations where gateway reachable numbers are advertised in an extended format rather than in a compact format. An example of such a situation is the so-called"virtual gateway"where a user endpoint runs an IP-phone application as a low cost (virtually zero cost) gateway to the user desk phone. Since each IP-phone application can be seen as a gateway advertising just one E. 164 address, it is advantageous for the GLS servers to be able to effect aggregation of the data they receive.

The described gateway-discovery system is also flexible in that it can readily cope with increasing loads. More particularly, if a GLS gets overloaded for whatever reason (for instance, too many queries per second, or too large a database to manage), load rebalancing of load can be achieved by simply reassigning part of the E. 164 number range for which that server is responsible to another GLS.

With the respect to the inter-AD part of the described system, since only aggregated data is exchanged amongst AD border elements, substantial bandwidth saving between Ads can be achieved as compared to arrangements that pass full gateway details.

. Redundme If each GLS server is assigned responsibility for its"own"number ranges plus a part of one or more other GLS number ranges, a spatial data replication of responsibility and gateway data is obtained (in this respect, when a GLS server receives new gateway data, it will distribute it to every GLS server having number responsibility for any of the numbers accessible through that gateway, even where there are multiple servers with responsibility for the same number). Figure 10 illustrates such a replication in the case of four GLS servers (GLS1-4) where the number responsibilities of each server are graphically depicted as overlapping regions (GLS 1 has responsibility for the number region bounded by the chain dashed line, GLS2 for the region bounded by the solid line, GLS3 for the region bounded by the dashed line, and GLS 4 for the region bounded by the dotted line). Now if any one such GLS server become unavailable, the other ADs can still provide coverage for the full number range intended. Of course, where a GLS server receives a gateway location request for a number within its number responsibility, it will handle that request itself, even though the number may also be within the number responsibility range of another server. Different levels of replication can be effected according to the AD policy.

Where the gateway data is replicated across GLS servers, it is also possible to achieve a degree of load balancing by distributing gateway-location requests (for example, by random selection, on a temporal basis) between the GLS servers capable of handling them.

Figure 11 illustrates this process for a number ("+441173129872") that falls within the number responsibility of both GLS2 and GLS3. A first gateway-location request ("query#1") received by GLS4 for this number is forwarded by it to GLS2 whereas a second request ("query#2") received by GLS4 for the same number is forwarded to GLS 3.

Gateway Data Storage. Aggregation and Summary Generation This section concerns how the gateway data is aggregated, stored and subsequently summarized at the GLS servers, and how the summarized data is aggregated and stored at the border elements. In particular, tree data structures for efficiently effecting these operations are described.

From the GLS point of view, aggregation can be defined as the process of re-organizing received gateway information so that it can be expressed with the minimum amount of data in the GIB (gateway information base); unlike a general purpose database, the data structures used by the GLS servers for storing gateway data can exploit the particular properties of the data being stored (namely, the E. 164 prefixes structure) to make aggregation more effective. The initial aggregation performed by a GLS on the gateway data it is store, is a lossless aggregation (that is, no information is lost) and the data structure chosen to hold the aggregated data must be adapted to enable efficient aggregation whilst minimising storage requirements. However, the data structure must also facilitate fast data retrieval (and thus a fast query resolution) and summary generation.

GIB Tree Data Structure-Basically, each node of the tree data structure used in the GIB represents a telephone prefix and may or may not have additional information associated with it. Such information, if present, represents the details of the gateway (GW) serving the set of numbers corresponding to the prefix. The node's children define sub-trees that represent further specification of the parent prefix.

Figure 12 shows an example tree structure having six nodes 410-415, node 410 being the root node of the tree. Each node holds three information elements, namely: Element 421 an E-164 prefix segment; Element 422 a list of zero, one or more gateways associated with the node, further details of which are held in gateway records (records 425, 426 and 427 for gateways A, B and C of the present example); Element 423 a list of references to zero, one or more dependent nodes.

Each node 410-415 encompasses a group of numbers specified by the concatenation of the prefix segments of the nodes traversed in descending the tree from the root node 410 to the node concerned (the"*."symbols of intermediate prefix segments being dropped in this concatenation). Thus, the group of numbers encompassed by the node 413 is the concatenation of the prefix segments"+44","117"and" [0-2] *." of nodes 410,411 and 413 respectively, namely the group of numbers"+44117 [0-2] *.". Where a gateway is identified in element 422 of a node, that gateway is taken as giving access to the number group associated with the node. Thus, the group of numbers"+44117 [0 21*."associated with node 413 is accessible through gateway B. However, as these numbers are a subset of the numbers encompassed by nodes 411 and 410, the numbers are also accessible through any gateways associated with these latter nodes (in this case, there are no such gateways).

GLS lossless aggregation process-As soon as new gateway data are received by the GLS the related prefixes are inserted into the tree according the following algorithm : [A]-For each Pin in Pin-List go to [B] [B]-ifanEP (Pin, Pcurr) existsgoto [B. 1] else go to [C] [B. 1] -if (EP (Pin, Pcurr) = Pcurr) go to [B. 1. 1] else go to [B. 1.2] [B. 1. 1]-Pin = (Pin-EP) -Pcurr = Pcurr's child -go to [A] [B. 1.2]-substitute Pcurr with EP (Pin, Pcurr) -insert (Pin-EP) and (Pcurr-EP) into Pin-List -go to [A] [C]-if CP (Pin, Pcurr) exists go to [C. 1] else go to [D] [C. 1]-if (CP (Pin, Pcurr) is shorter than Pin and Pcurr) go to [C. 1. 1 else go to [D] [C. 1. 1]-substitute Pcurr with CP (Pin, Pcurr) -insert (Pin-CP) and (Pcurr-CP) into Pin-List -go to [A] [D]-if OV (Pin, Pcurr) exists go to [D. 1] else go to [D. 2] [D. 1]-split Pin and Pcurr in three new prefixes: P1= (Pin-Pcurr), P2=OV (Pin, Pcurr), P3= (Pcurr-Pin) ; -insert P1, P2, P3 into Pin~List -go to [A] [D. 2]-add Pin under Pcurr.

Where: Pin = List of prefixes to be inserted into the tree Pin = Prefix being inserted into the tree Pcurr = Prefix associated with the current tree node being examined EP = Exact prefix (for instance if P1=441 [1-5] *. and P2=441 [3-8] *. then EP (P1, P2) = 441 *.) CP = Common prefix (for instance if P1= [1-5] 4*. and P2= [3-8] 5*. then CP (P1, P2) = [3-5] *.) OV = Overlap (for instance if P1= [1-5] *. and P2= [3-8] *. then OV (P1, P2) = [3- 5] *., but if P1= [1-5] 4*. and P2= [3-8] 5*. then OV (P1, P2) = EMPTY) This algorithm allows building a tree that always fulfill to the following properties: a-All nodes positioned at the same depth fromkthe root of the tree never share an exact prefur ;. b-All nodes position at the same depth from the root of the tree never share a common prefix ;. c-All nodes positioned at the same depth from the root of the tree never share a common intersection ; Such properties are needed to guarantee that for each fully specified E. 164 address, prefixes containing it are always located along one and just one path i. e., a sequence of nodes from the root to a leaf of the tree, and not spread across the entire tree.

For instance, by applying the previous algorithm with: Pin-List = (+44 [1-21*. (A), +44 [341*. (B), +4411-214*. (C), +44 [2-31*. (D), +4*. (E)} } where A, B, C, E represent the gateways (GW) advertising the correspondent prefix, the result is as shown in Figure 13. Now, given for example the E. 164 address +442434567, the only valid path for this number through the tree is the one shown bold in Figure 13 through nodes 440-443. This path shows that in order to terminate a call to the number under consideration, four GWs are available: E, A, D, C. As a rule of thumb, GWs advertising more specific prefixes (for ex. C, +44 [1-2] 4*.) are likely to be cheaper than GWs advertising more general ones (i. e. E, +4*).

Summary Generation at the GLS-According to GLS dependant policies, a summary of the GLS gateway data is periodically generated and sent to the Administrative Domain border element; this summary, or part of it, will be eventually forwarded to neighbouring border elements. The process used by the GLS to generate the summaries is, in fact, more than just abstraction and constitutes a form of lossy aggregation as it involves both discarding less important information and then compacting the remaining data as much as possible. An important feature is the objective to reduce the number of tree nodes by starting from the bottom and recursively considering all the attributes (i. e. the details) associated to each node's children. A simplification process is applied to the attributes which involves discarding and/or abstracting some or all of the attributes, according to GLS internal policies, with the objective of obtaining two or more nodes with exactly the same remaining attributes -these nodes are then aggregated. For example, a basic simplification rule that could be adopted is to eliminate all attributes, other than"Cost" ; Figure 14 illustrates how this rule works for one particular example. In this example, a node 450 is associated with the group of numbers"+44117 [0-3] *." which are accessible through gateway A, whilst a second node 451 is associated with a group of numbers"+44117 [8-9] *." accessible through gateway B. If all gateway parameters (including identity) are excluded by simplification step 460, then the nodes 450,451 have the same associated gateway cost data and can be combined by aggregation step 465 into a single node 470 incorporating the gateway cost data.

Of course, more complex simplification rules than simple elimination/retention can be applied. For instance, for the"cost"attribute, the cost values can be banded so as to increase the likelihood of matching with a peer node. Figure 15 illustrates the application of such a rule to three nodes 480,481 and 482 that have various associated costs that can be grouped into three bands 490,491 and 492 allowing the three nodes to be consolidated into one new node 495.

It is possible to permit every AD choose its own summary generation rules offering the most appropriate trade-off between bandwidth and level of detail advertised provided that the summary-generation rule is sent along with such information ; however, it is preferable that ADs use at least a common base for the summary-generation rule Aggregation at the Border Element-The gateway-related data received at the border element is aggregated using a tree data structure and lossless aggregation algorithm similar to that employed at each GLS. However, the data now relates the summarised attributes to particular GLSs rather than to specific gateways so that the data structure now stores at each node for which gateway access is to be indicated, the GLS address (or other ID) and the access attribute (s) concerned (eg cost band); whether the GLS address and the access attributes are stored directly in the tree data structure or in a linked database is an implementation detail.

Efficient representation of telephone numbers for GLS-Since in principle each GW is able to reach every E. 164 address of the world (through the PSTN), the amount of data that a GLS must store is likely to be huge. Therefore, in order to make the storage task scalable an efficient representation of E164 addresses is required within the GLS. This is achieved by representing each symbol of the E. 164 address prefixes (expressed in the manner used herein, for example :"0044117 [1-4] *.") in one word (16 bit) as shown below:

Symbol Word Description EMPTY 0000000000000000 No symbol 0 0000000000000001 digit"0" 1 0000000000000010 digit"1" 2 0000000000000100 digit"2" 3 0000000000001000 digit"3" 4 0000000000010000 digit"4" 5 0000000000100000 digit"5" 6 0000000001000000 digit"6" 7 0000000010000000 digit"7" 0000000100000000 digit"8" 0000001000000000 digit"9" 0000001111111111 All the digits 0000010000000000 Expandability flag Now, every digit of an E. 164 address can be represented by a combination of the previous 16-bit words. For example : 0044117 [1-4] *. is represented by: 0000000000000001 - (0) 0000000000000001- (0) 0000000000010000- (4) 0000000000010000- (4) 0000000000000010- (1) 0000000000000010- (1) 0000000010000000- (7) 0000000000011110- ([1-4]) 0000011111111111- (*.) Digit-to-digit comparison of prefixes can be performed by simply AND, OR, or XOR homologous words, enabling more complex operations like inclusion detection or overlap detection/extraction between prefixes, to be carried out very quickly. It should be noted that in order to manage a big database of telephone prefixes, operations such as comparison and inclusion detection have to be carried out as quickly as possible.

Another significant advantage of this implementation technique, is the possibility to easily express non-continuos interval of numbers. This is a desirable characteristic, since it enables a higher level of aggregation of telephone prefixes. For instance, the following prefixes: 00441170*., 0044117 [2-3] *., 00441178*. can be expressed by just a non-continuous one: 0044117 {0, [2-3], 8} *.

This is easily accomplished with the digit {0, [2-3], 8} combination being represented by setting the appropriate bits in the corresponding 16-bit word: 0000000100001101 Inter-AD Network Models As already indicted, different communication arrangements are possible between the border elements of different AdD; in particular both distribution and propagation communication models for AD-to-AD information exchange can be supported which permits the overall architecture to scale and adapt to different configurations ranging from a few big ADs to several hundreds of big ADs (Telcos, big ITSP, big companies) and thousands of potential small ADs (small companies, universities, banks,...).

Thus, an AD run by a big Telco or a big ITSP will likely be interested in collecting the maximum amount of data from all over the world, and quickly update their GLS information according to local aggregation policies. In this case, high capacity dedicated connections and large distributed database are available to the AD, and a distribution model between ADs is most suitable as it allows information to rapidly flow from a source to all recipients, without any intermediate processing.

On the other hand, small ADs run by local ITSP will not likely be able to cope with large amount sof frequently updated information, because of their smaller capabilities (low bandwidth connection and/or small GLS database). They are probably more interested in receiving already aggregated information updates, periodically propagated on the inter-ADs network. Of course, in this case a certain delay is introduced for an update to propagate from a source to all recipients, since information is processed by intermediate ADs.

Although the purpose of both models is to deliver information from a source to one or more recipients, they cannot be considered mutually exclusive, since the first cannot easily support a world wide network with many low capacity ADs, while the second cannot guarantee low delay propagation, nor stability. Having both working together in a hybrid environment dramatically reduce these limitations taking full advantage from respective strength points.

The inter-AD architecture is also determined by the business-related considerations that impose certain restrictions on which ADs should talk to each other and how. The following examples show a variety of different scenarios and assume ADs connected by means of an IP network such as the Internet. a) Fully meshed ADs.-Figure 16 In this scenario information advertised by one border element are received by all others. This scenario could be implemented having ADs connected to the public Internet and broadcasting info to the others by means of a multicast channel 505. b) Peering ADs.-Figure 17 In this scenario two ADs establish a peering agreement 506 and customised price plan. Such plan should be available only to the operators of the two Ads concerned and therefore the corresponding information is preferably encrypted with a shared secret key to guarantee privacy. c) Federated ADs.-Figure 18 This scenario comes from the previous two: two or more ADs federate (see 507) to share information and possibly an intra-federation discounted price plan, as in the case of a peering agreement. The federation members multicast private information to each other on a federation multicast network 508 and encryption can be used to guarantee intra-federation privacy. d) Clearing House AD.-Figure 19 A Clearing House 510 provides settlement, authentication and billing services to subscribing ADs 512 that need to inter-operate but do not have any established relationship or agreement. On the inter-AD network 505 the Clearing House 510 behaves like a normal AD, collecting and advertising information, but in fact it is a trusted third-party, acting as a proxy on behalf of its subscribers. e) Trading House AD.-Figure 20 A Trading House 520 provides a trusted and secure environment to dynamically perform commercial transactions between ADs. On the inter-AD network 505 it behaves like a collecting-only AD with the additional possibility to collect and or invite software agents from others ADs. When an AD wants to perform a commercial transaction, it sends a software agent to the Trading House 520. This could be something like a"bidding agent"525, whose purpose could be for instance to"buy a quantity of minutes at the lowest price for a given set of numbers", or an "offering agent"524, whose purpose could be to"offer a quantity of conversation minutes for a given set of numbers at a given price". Thanks to the information collected on the inter-AD network, upon receiving a bidding-agent 525 the Trading House 520 can invite ADs that can serve required numbers to send an offer-agent 524, and finally provide an environment where the agents interact to reach a deal. f) Hybrid environment.-Figure 21 The described inter-AD arrangement allows any combination of above described scenarios, enabling a hybrid, very flexible environment, where ADs can interact in a variety of ways, establishing permanent or dynamic relationships.

As already indicated, to be able to support other than the most simple summary-data publishing policy, a border element must be able to selectively publish summary data to border elements in other ADs. This ability can be used to provide operator-specific discount plans, by generating different summaries for different target border elements.

This allows an AD to offer a basic price plan plus a certain number of customised price plans to different operators.

Claims (1)

1. CLAIMS 1. In a gateway-discovery system, a tree data structure for relating E-164 numbers to gateways serving those numbers, the tree data structure having a plurality of nodes each of which: holds a number prefix segment, and --is associated with a number group encompassing at least one number and specified by a concatenation of the number prefix segments of the nodes traversed in descending the tree structure from its root node to the node concerned; at least one of said nodes identifying a gateway giving access to the number group associated with the node, and the tree structure being such that the set of gateways, if any, serving the number group specified by a node is constituted by the gateway or gateways identified by that node and the nodes traversed in descending to that node from the root node of the tree structure.

   2. In a gateway-discovery system, a tree data structure according to claim 1, wherein at leas the last place position in said number prefix segments can have multiple simultaneous values, including non-consecutive ranges.

   3. In a gateway-discovery system, a tree data structure according to claim 1, wherein each place position within said number prefix segments is represented by a binary word with the state of each of ten bits of the word indicating the presence or absence of a corresponding respective decimal digit value at that place position whereby a single binary word can be used to represent multiple digit values at the same place position of the number prefix segment, including non-consecutive ranges.

   4. In a gateway-discovery system, a tree data structure according to claim 2, wherein an eleventh bit of each said binary word is used to indicate whether or not the values represented by said ten bits are to be treated as repeated in place positions not explicitly represented in the corresponding said number prefix segment.

   5. A method of updating a tree data structure of the form set out in claim 1, said method involving receiving a list of number prefixes served by a gateway and inserting these prefixes into the data structure accoding to the following procedure: [A]-ForeachPininPinListgoto [B] B]-if an EP (Pin, Pcurr) exists go to [B. 1) else go to [C] [B. 1]-if (EP (Pin, Pcurr) = Pcurr) go to [B. 1. 1] else go to [B. 1.2] [B. I. 1]-Pin = (Pin-EP) -Pcurr = Pcurr's child -go to [A] [B.

   1.2]-substitute Pcurr with EP (Pin, Pcurr) -insert (Pin-EP) and (Pcurr-EP) into Pin-List -go to [A] [C]-if CP (PinPcurr) exists go to [C. 1] else go to [D] [C. 1]-if (CP (Pin, Pcurr) is shorter than Pin and Pcurr) go to [C. 1.1] else go to [D] [C. 1. 1]-substitute Pcurr with CP (Pin, Pcurr) -insert (Pin-CP) and (Pcurr-CP) into Pin-List -go to [A] tD]-if OV (Pin, Pcurr) exists go to [D. 1] else go to [D. 2] [D. 1]-split Pin and Pcurr in three new prefixes: P 1 = (Pin-Pcurr), P2=OV (Pin, Pcurr), P3= (Pcurr-Pin); -insert P1, P2, P3 into Pin-List -go to [A] [D. 2] -add Pin under Pcurr. where: Pin = List of prefixes to be inserted into the tree Pin = Prefix being inserted into the tree Pcurr = Prefix associated with the current tree node being examined EP = Exact prefix CP = Common prefix OV = Overlap