Patent Description:
Internet networks and mobile communication networks, such as Global System for Mobile communications (GSM) and <NUM>, use gateway nodes to allow hosts to access communications networks, and server nodes to provide services to the host. Edge nodes such as Access and Service Edge nodes are frequently "pooled" in a network, to allow load sharing and balancing between pool members, along with increased availability and better utilization of resources. Conventionally, pools are either statically configured, and static pooling can also be based on the Domain Name System (DNS).

Statically configured pools are based on the concept of statically pre-configuring information about selectable edge nodes for a given service. Selection algorithms are used to select a suitable edge node for use by a host. Statically configured pools allow for better sharing of the load distribution between nodes having similar functionality, and simplified node dimensioning due to more accurate estimates of traffic over larger geographical areas.

Another type of statically configured pooling is DNS-based pooling. Rather than configuring pools in each node that may require this information, the configuration is performed in a DNS server. A host sends a DNS query to the DNS server, which returns a list of IP addresses identifying members of a pool. The host then selects one address from the list based on an internal selection algorithm.

A refinement of this idea is for the DNS server to introduce limited selection before sending the list of IP addresses to the MS. Examples of these are "sort lists" and "round robins". A Sort List is a DNS feature where the order of addresses in the list of IP addresses are ordered based on the source address of the query. A Round Robin is a DNS feature to balance traffic between two or more addresses. Round Robin is used in General Packet Radio Services (GPRS) networks to distribute the load between multiple Gateway GPRS Support Nodes (GGSNs).

A disadvantage to using Sort Lists in the DNS server is that there is no guarantee that the original order will always be maintained as the information is passed from DNS server to DNS server. To ensure the correct order is maintained, Sort Lists must be configured in all the DNS servers in a network, adding considerable complexity to large DNS solutions. In some cases it may not be possible to set Sort Lists on all servers.

Round Robin operates using static information obtained from a DNS database. The status and actual load on a node are not taken into account when the DNS server responds to a request. Round Robin may override the structure of a response sent from an authoritative server or the effect of a Sort List.

DNS pooling also enables service-specific selection by using so-called "resource records" (RRs). In a basic DNS server described in IETF RFC <NUM>/<NUM>, pools can be configured with multiple "address" RRs (A RRs) for a given host name. When the DNS server receives a request for a list of addresses, it returns all RRs matching the query, and the entity making the requests then selects an address from the list.

A more enhanced service-based pooling solution is specified in RFC <NUM>, which describes a SRV RR-enabled DNS server. Server pools are configured using multiple "service" resource records (SRV RRs) for a service. A RR format also includes PRIO and WEIGHT parameters. The DNS server's response to a request contains all possible choices of server with priority and weight info, allowing the MS to make a server selection on the basis of pre-defined rules based on the received priority and weight parameters.

A problem with static pooling is that the pools must be configured and updated at any node that may be affected by changes in the pooling. Pooling membership therefore requires a considerable amount of configuration work. For example, if a network is extended it may require a re-design of existing pools, and possibly the introduction of new members into pools. Re-configuration in affected nodes is therefore required not only to take account of newly introduced pool members, but also existing ones. Similarly, changes in the network topology require operator intervention.

A further problem with static and DNS-based pooling is that it cannot take account of changes in the network without being reconfigured. So, for example, static pooling cannot take account of current network conditions such as the current load on the transport network. The selection process may therefore lead to overload on some pool elements, whilst other pool elements are underutilized. As a consequence, QoS requirements for a given service cannot be guaranteed. Furthermore, the load on pool elements such as edge nodes cannot be taken into account for load sharing purposes. Other characteristics of the pool elements cannot be taken into account either. Such characteristics include connectivity to specific networks, supported services, and so all pool elements must be configured similarly and have all required features in order to avoid selecting a pool element that does not have the required features. Using static or DNS-based pooling, there is no or limited topology information available.

Static pooling makes configuration management of pools cumbersome. For example, in a scenario where less expensive, and therefore less reliable pool elements are used, network redundancy provided by pooling would allow for high network reliability. In this scenario, however, adding and removing pool elements to/from pools may become a frequent event, affecting configuration significantly. <CIT> discloses an IP address access selector functioning on the basis of network condition data provided by a network resource controller.

The inventors have recognized the problems associated with static and DNS-based pooling methods, and devised a method and apparatus as in the appended independent claims to mitigate those problems.

Preferred embodiments are covered by the appended dependent claims.

The following description sets forth specific details, such as particular embodiments, procedures, techniques, etc. for purposes of explanation and not limitation. In some instances, detailed descriptions of well known methods, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Moreover, individual blocks are shown in some of the drawings. It will be appreciated that the functions of those blocks may be implemented using individual hardware circuits, using software programs and data, in conjunction with a suitably programmed digital microprocessor or general purpose computer, using application specific integrated circuitry, and/or using one or more digital signal processors.

Referring to <FIG> herein, when a host <NUM> is attached to a fixed access network, and requires service from an Access Edge (AE) or Service Edge (SE) node, the most appropriate AE <NUM> or SE <NUM> node for the host to use is selected from a pool <NUM> of AE/SEs. The selection is based on subscription-related information (requested service type, required QoS, etc.), and also on the status (load and reachability) of AE/SEs, transport link capacity information, topology information (AE/SE locations on geographical and logical topology, and current terminal location) and the capabilities or functionalities of different AEs/SE members within the pool <NUM>. Examples of capabilities and functionalities include supported features (e.g., security support, supported tunnel types etc.) and the type of interface to services (e.g., Internet peering, VPN, IMS etc.). This nomadic access to network services allows for session continuity if needed.

A central entity is provided to make the selection of the AE <NUM> or SE <NUM> from a pool. This entity is referred to as selection logic <NUM>. When the selection logic receives a request <NUM> for a service from the host <NUM> (or on behalf of the host <NUM>), the selection logic <NUM> selects the most appropriate endpoint for the host based on the above criteria and establishes communication between the host and selected AE <NUM> or SE <NUM>. The selection logic <NUM> communicates with a plurality of data sources to obtain data on which to base the selection. The selection logic <NUM> may make queries on-demand (i.e., triggered by the request), and may also issue queries to data sources independently in advance, in order to shorten response time. Examples of data sources that the selection logic <NUM> may use include an Authorization, Authentication and Accounting (AAA) server <NUM>, a DNS server <NUM>, a Dynamic Host Configuration Protocol server <NUM>, and a topology database <NUM>.

Once the selection logic <NUM> has selected a server it sends a reply <NUM> to the host <NUM> (or agent acting on behalf of the host), and in the reply <NUM> includes an identity of the selected AE <NUM> or SE <NUM>. In the example shown in <FIG>, the selection logic <NUM> has selected SE <NUM>, and the host <NUM> uses the identity of the SE <NUM> to establish a communication path <NUM> between the host <NUM> and the SE <NUM>.

<FIG> is a flow chart showing a method of a method for selecting the most appropriate edge node from a plurality of edge nodes based on the service information, status and capability/functionality of the nodes as well as transport information. The following numbering refers to the numbering of <FIG>:.

Turning now to more detail and specific embodiments of the invention, the request for service is based on any type of signalling capable of exchanging the required information. However, for a network-based selection it is assumed that there is no application-specific protocol for selection. Three of the more important possibilities are a DNS query, a Dynamic Host Configuration Protocol (DHCP) query, and an AAA request. Taking each in turn:.

If the host already has an IP address, the service request can be made using a DNS request. An advantage of DNS is that DNS is supported by vast majority of IP hosts, so the impact on requestor functionality is low. For example, a Windows® host may be configured with server Fully Qualified Domain Names (FQDNs) for a given network connection, in which case they will initiate the connection with a DNS query. Furthermore, standard DNS features for service-specific pooling may be exploited in a natural way without greatly altering DNS.

In the DNS query, a service identification can be based in the usual way on a string encoded into the FQDN of the query, e.g., _inet. net , where _inet denotes the given service, e.g., an Internet connection.

In this case the 'request' comes in the form of a DHCP query. This embodiment supports the selection of proper gateway or IP POP for a non-3GPP terminal (e.g. PDAs, laptops) attaching to the network. When such a terminal attaches to an L2 access point, it sends a DHCP request to the DHCP server asking for configuration information to be used on the new link. This can be thought of as a trigger then a specific request for service.

According to this embodiment of the invention, every DHCP request from each IP subnet in the network is relayed to the selection logic <NUM> deployed somewhere in the operator's network. Therefore, access routers must be provided with DHCP relay capability. After the selection process the DHCP reply is further relayed to a DHCP server that finally allocates an IP address to the terminal. This may coincide with the selected IP POP for the given terminal and service. As a design option, the Selection logic may be implemented in an enhanced DHCP server.

The terminals can move from one access to another so it is important to identify their actual location. This can be based on the IP address of the first DHCP server's IP address relaying the DHCP query. The Service identification can be based on interfacing to a data source that can relate the Terminal to the subscribed services. For example, to an AAA server that knows the service subscription information.

According to an alternative embodiment, an Authentication-based request is sent to the selection logic <NUM>. If the host <NUM> is equipped with layer two authentication capabilities such as <NUM>. 1x (e.g. WPA in wireless LAN cards), the host <NUM> must authenticate itself each time it attaches to an access point. Generally, the authentication is forwarded to an AAA server <NUM> that knows the service subscription information and can authenticate the terminal. (This is the case e.g., for <NUM>.

The selection logic <NUM> oversees the authentication process between the AAA server <NUM> and the host <NUM> and thus notices the attachment of the host <NUM> and performs the selection needed. As before, the host location can be identified from the authenticator's IP address (the AAA server <NUM> at the access edge relaying the authentication request). The service identification is based on interfacing to a AAA or HSS server.

Turning now to the parameters for selection, end points such as AEs and SEs can be based on different selection parameters, as described below:.

From the examples described above, the types of parameters and situations required for AE/SE selection can be grouped into the following categories:.

The major benefits of the selection process include:.

Examples of parameters that can be taken into account and that can be derived from the scenarios are:.

In order to identify a server or gateway pool for service, and the IP addresses of each pool member, any suitable signalling may be used. DNS signalling is most suitable, and in this case a standard DNS server is used as the data source. Configuration of the DNS server with a list of selectable pool entities for each service is done by the network management system. Referring to <FIG>, pool identification comprises the following steps:.

It is advantageous if the initial request to the selection logic <NUM> is also in a form of a DNS query. This is because, in general, this request may simply be forwarded by the selection logic <NUM> to the DNS server <NUM> with little or no modification of the original request. It is also faster to filter out the most appropriate entry from the answer from the DNS server <NUM> and transfer it to the requestor. This reduces the response time.

The selection logic <NUM> may be embedded within the DNS server <NUM>, which reduces response time even further, although the selection logic <NUM> may be a separate node from the DNS server <NUM>.

As described above, it is also useful to identify topology information, as well as status, capability and functionality of each pool member. One way to achieve this is to provide a topology database <NUM> that is dynamically updated. The selection logic <NUM> consults the topology database <NUM> to find the closest servers/gateways, transport capacity and node status/load information etc. The topology database <NUM> can be a standard relational database that may be built into the same box as the selection logic <NUM> but may also be a separate node.

Initial configuration of the database <NUM> may be performed by a management system. In order to keep the topology database <NUM> updated, a Database synchronization function <NUM>, as illustrated in <FIG>, is proposed. The Database synchronization function <NUM> has the following main functions:.

The database synchronization function <NUM> dynamically updates the topology database <NUM> to reduce the risk that any information extracted from the topology database <NUM> is out of date. The database synchronization function <NUM> either updates the topology database <NUM> periodically, or whenever the database synchronization function <NUM> detects a change in the network or network nodes that it is monitoring.

In order to select the most appropriate pool element from the pool, specific selection algorithms are required. The selection algorithm is typically different for control plane (server) or user plane (gateway) element selection.

Once the pool element has been selected, it is returned to the requestor. In the case of a DNS query, a single IP address of the selected pool element is returned in the DNS response. In the case of a DHCP query, the DHCP reply contains the IP address of the selected element as the default gateway. In case of an AAA query, the IP address of the selected element is not contained in the AAA answer. Instead, since each authentication process is followed by a DHCP request in order that the terminal acquires an IP configuration, the IP address will be given in the DHCP answer, similarly as for the case with the DHCP query.

In order to illustrate some of the above features of the invention, and by way of an example, consider the case in which an endpoint provides Home VPN access service for nomadic terminals (NTs) across different access types: home (ATM, Ethernet, wholesale provider), mobile (i.e., cellular accesses) and Internet, i.e., from the coverage of a neutral Service Provider. A terminal attached to a VPN service from the Internet. It is assumed that the Access Node (AN) is owned by another service provider that has no service-level agreements with the home provider of the subscription. Thus, the terminal may be provided with a public IP address from this provider, but no authentication is possible through the AN, and also no DHCP relay or special tunnelling is possible from this AN.

Since there is no support from the access side, the terminal must initiate attachment to the VPN service. Also, the terminal needs to handle mobility in some way. Once the terminal has obtained a local IP address with DHCP, it initiates a MIP registration request towards the endpoint (which is the MIP HA). The endpoint interrogates the AAA server for authentication and a repository (LDAP) server for other service-specific information (NAT/FW settings), and then replies with a MIP registration reply specifying a CoA that is in the address range of the customer's home VPN.

The proposed modification into this sequence including network-based endpoint selection is illustrated in <FIG>. The terminal issues a DNS request <NUM> before initiating the MIP registration request. The network is configured such that this request reaches the Selection Logic (SL) that infers the service type using FQDN filtering. The SL then issues an AAA request for authentication and contacts the LDAP server for QoS information. It then contacts the DNS server to find potential endpoints for this VPN service. Using IP address filtering the SL infers the peering (AE) to the given AS the terminal currently resides. It also has an interface to the topology DB for other topology and performance-related information. Based on these information elements, it selects the most appropriate endpoint and replies to the terminal with a DNS response <NUM> containing the IP address of the selected endpoint.

Referring to <FIG>, there is illustrated schematically a selection node for use in a communications network. The selection node comprises a receiver <NUM> that receives a request for a network service. Means for receiving data relating to a plurality of edge nodes is obtained by querying at least one remote node from an obtaining function <NUM> that is capable of querying remote nodes and receiving responses from the remote nodes. A processor <NUM> is provided for selecting, on the basis of the obtained data, an edge node that provides a path between the host entity and the requested network service. A transmitter <NUM> is also provided for sending a response to the host entity that made the original request, the response providing information identifying the selected edge node. It will, of course, be appreciated that the selection node may have a separate physical implementation or may be a function provided in another node.

The invention as described above provides several advantages over prior techniques for selecting a pool element from a pool where a terminal attaches via a fixed access network. It provides enhanced network resilience, since any node capable of interfacing with a given service may be selected for all terminals, based on their actual reachability and status. Furthermore, it provides increased network efficiency, as transport usage is made more efficient through a full topology-aware selection. This is especially useful in case of nomadic terminals. Using load balancing of the nodes interfacing with a given service provides not only better characteristics, and using load balancing also reduces the overall number of service nodes that are required for a given service. Pooling allows for an optimized AE/SE design in a multi-edge network.

A specific advantage of the proposed architecture is that it provides a single central logic for selection instead of having the selection logic implemented and configured in different control nodes, which would be the case for application-based selection. This reduces capital and operating expenditure, as there is no need to implement and configure selection-related functionality in all different logical nodes that may be in charge of selection in the network. Operating expenditure reduction is especially manifested in a number of use cases (network extension, maintenance etc.) for which the centralized selection gives better support.

Another advantage of the scheme is that it provides a dynamic selection process, which provides better utilization of core network resources by using load information in the selection, improved response times and characteristics for QoS-sensitive services by choosing the shortest possible user plane path and service node with the lightest load, and selection of a proper node for a given terminal or subscription using dynamically obtained knowledge of node capability and functionality-related information (IPSec support, tunnel type support etc.).

Another advantage is that the proposed interface with the selection logic is based on standard functions (DNS, DHCP, AAA queries), and so significant changes are not required to existing node functions and signalling chains. Almost all IP hosts should support DNS, and so the implementation of the DNS based solution has a minimum standardization impact. This also allows utilizing all standard pooling-related DNS features in a straightforward way, as described in this disclosure.

Although various embodiments have been shown and described in detail, the scope of patented subject matter is defined by the claims.

Claim 1:
A method for selecting an edge node from a plurality of edge nodes in a fixed access communications network, the method comprising:
at a selection node, receiving from a host entity a request for a network service;
obtaining, from a dynamically updated database, data comprising information relating to a status and capabilities of each edge node from a plurality of edge nodes, wherein the database is dynamically updated as the status and capabilities of each edge node from the plurality of edge nodes is changed, which allows edge nodes to be changed, removed, upgraded or added, wherein at least some of the data is obtained
prior to the host entity's request being received;
on a basis of the obtained data, selecting an edge node from the plurality of edge nodes, the selected edge node providing a path between the host entity and the requested network service; and
sending a response to the host entity, the response including information identifying the selected edge node.