Patent Application
20100291943
The present invention relates to a method and apparatus for use in a communications network, and in particular to a method and apparatus for allocating pooled server or gateway nodes to a terminal.
Communications networks such as Global System for Mobile communications (GSM) and 3G use gateway nodes to allow a Mobile Terminal (MT) to access communications networks, and server nodes to provide services to the MT. Server and gateway 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 server/gateway nodes for a given service. This pre-configured information is stored in each MT, and other nodes that may require this information. When a MT wishes to select a server or gateway, selection algorithms are used to make the selection. Statically configured pools provide load distribution between nodes of similar functionality, increased availability and simplified node dimensioning due to better traffic estimates in large geographical regions.
Static pooling of server and gateway nodes is extensively used in current mobile systems. In 3G networks, Serving GPRS Support Nodes (SGSN) and Mobile Switching Centres (MSC) are pooled using Iu-flex. In GSM networks, these nodes are pooled using A-flex and Gb-flex.
Iu-flex is described in 3GPP in Release 5 TS 23.236, and allows Radio Network Controllers (RNCs) to select an MSC from a pool of MSCs and a SGSNs from a SGSN pool. The same concept is used in GSM, in which a Base Station Controller (BSC) can select an MSC from a pool of MSCs (using A-flex) and a SGSNs from a SGSN pool (using Gb-flex). Sets of core network nodes from which an access network node may choose are referred to as pools or clusters.
Using Iu/A/Gb-flex, pools of MSCs and SGSNs may serve a service area. In this case, all RNCs (or BSCs for GSM) are connected to all MSCs/SGSNs, and vice versa. These connections may be “physical” through direct links, “logical” through SDH VPs or ATM PVCs, or “virtual” through IP connectivity. The service area of a pool is termed a “pool service area”.
When a mobile station (MS) attaches or roams to a pool service area it is assigned a specific MSC/SGSN according to a load distribution algorithm. The MS is not aware of the identities of other members of the pool, and uses the selected MSC or SGSN for all communications whilst the MS remains in the pool service area. Note, however, that if the MS leaves the pool service area and subsequently re-attaches, it may be assigned a different MSC/SGSN according to the network requirements at the time the MS re-attaches.
RNCs and BSCs route messages according to configured tables. A MS can signal to the RND/BCS that a node is unavailable, in which case the RNC/BSC may select a different node for the MS depending on the load balancing requirements of the network.
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 MS sends a DNS query to the DNS server, which returns a list of IP addresses identifying members of a MSC/SGSN pool. The MS 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 through the usage of the so-called resource records (RR). In the basic DNS server described in IETF RFC 1034/1035, pools can be configured with multiple “address” RRs (A RR) for a given host name. When the DNS server receives a request for a list of addresses, it returns all RRs matching the query. Choosing the one to be used is the clients' task.
A more enhanced service-based pooling solution is specified in RFC 2782, 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.
An example of DNS-based pooling in mobile networks is GGSN pooling. When a MS attaches to a network, as part of the connection establishment process (Activate PDP context request) in GSM and 3G networks, an SGSN sends a DNS query in order to locate the GGSN that has a connection to the Packet Data Network (PDN), which is identified by the Access Point Name (APN) in the request sent by the MS. The DNS server has a database that maps an APN string to the IP address of the GGSN node. If multiple GGSNs are connected to the same external PDN, the DNS server returns multiple entries in the response sent to the SGSN. The SGSN chooses the first address (if more than one was returned) contained in the DNS response and sends a Create PDP Context Request on the Gn interface to the GGSN node. This procedure makes it possible to implement load sharing between GGSN nodes connected to the same PDN (which can be considered to be a GGSN pool). Configuration of “GGSN pools” is done locally in the DNS.
DNS pooling has certain drawbacks. DNS pooling uses a static database, and so each affected node must be reconfigured in the event of a change in the network topology. Furthermore, a DNS server has no way of knowing the status of an address associated with an APN. A DNS server returns an address regardless of the GGSN status. Standard DNS servers also indiscriminately return all addresses associated with a name, resulting in an inefficient routing of GGSN GTP connections. DNS may direct a SGSN to a more distant GGSN even though a local GGSN could provide access to the same external PDN. As GPRS networks grow in size and complexity intelligent services will be needed. A solution has been developed, as illustrated in
The solution illustrated in
1. Status Monitoring, which checks if GGSNs 102, 103, 104 are reachable over the Gn network, ensures that the traffic can flow through a GGSN to the PDN on the Gi interface and back after a GTP tunnel has been established, and if GGSNs 102, 103, 104 use external services such as RADIUS for authentication or DHCP to assign addresses, then the state of these services is monitored and reported.
2. Load Monitoring, which make it possible to optimize the number of connections for each GGSN 102, 103, 104. GGSNs 102, 103, 104 may have different capacities. DNS load balancing techniques like Round Robin distribute PDP Contexts evenly, which can resulting in the overloading of lower capacity GGSNs. Load values are preconfigured in a server to reflect the different capacities of the GGSNs 102, 103, 104 or alternatively load information is monitored by polling each GGSN 102, 103, 104 for attributes such as CPU utilization, packet throughput, number of connections, etc.
Actual monitoring techniques may differ from network to network and from operator to operator. Active monitors using ICMP ECHO, SNMP gets, or GTP probes can be used to report status and load. For situations where monitoring a service such as RADIUS is required, intelligent monitors that utilize the RADIUS protocol can be used. These more advanced monitors can be used to verify that a service is running and determine whether or not the service is performing the tasks required by the mobile network.
In situations where active monitoring adds unwanted network traffic, passive monitoring is used to evaluate the state of the network by listening to traffic for relevant messages. Such messages include route advertisements, keep alive messages, SNMP traps, etc. For example OSPF, RIP or BGP route announcements can be monitored for key IP addresses like the GTP VIP. When the route for one of these addresses is determined to be unreachable, the DNS server is notified.
By combining filtering rules with status and load information, an optimized list of GGSNs 102, 103, 104 is sent to the SGSN 101. Three main types of traffic steering apply to mobile networks, as follows:
The system architecture of future mobile networks, referred to as System Architecture Evolution (SAE) or Long Term Evolution (LTE) is under development (see 3GPP TS 23.401 (S2-070591) V 0.2.1, “3GPP System Architecture Evolution: GPRS enhancements for LTE access; Release 8”). A proposed architecture is illustrated schematically in
Serving SAEGW 202 functions include:
PDN SAEGW functions include:
The interface S1 provides access to Evolved RAN radio resources for the transport of user plane and control plane traffic and it includes S1_MME 204 and S1_U 205. The S1 reference point enables MME and SAEGW separation and also deployments of a combined MME 201 and Serving SAEGW 202 solution.
The concept of pooling is mentioned in the SAE/LTE document for the core network nodes (MMEs 201 and SAEGWs 202, 203) in order to reduce capacity, to increase reliability and to allow for simplified planning. MME pooling is a mechanism by which a Node B can handle multiple MMEs as if they were a single logical entity. When a MT requests a service, a mechanism selects one of the physical MME nodes and binds the MT to the selected MME. A similar pooling concept is defined for user plane nodes. For example, when a MT attaches to the network, it is the task of the MME (or other control plane entity) to select a given pair of serving/PDN SAEGWs 202, 203 from the pool, and so MTs (and Node Bs) do not see difference between SAEGWs within the same pool.
The User Plane (SAEGW) and Control Plane (MME) pool areas need not necessarily be the same, and can be affected by any of:
It is likely that different network operators will choose different scenarios for MME/SAEGW pool design, depending on the size of their network, connectivity constraints (e.g., due to regional administration), mobility patterns, etc. A potential SAE architecture for pooling/selection should be able to cope with all different possibilities of pool selection.
The main problem with static pooling is that the pools must be configured on multiple nodes. Maintaining pooling details therefore requires a considerable amount of configuration work. For example, if a network is extended it may require re-design of the existing pools and thus re-configuration of not only the newly introduced hosts, but also the existing ones. Similarly, changes in topology, service network, etc require re-configuration.
A common problem of the static and DNS-based pooling solutions is the lack of information available about dynamic network changes, such as a server being unavailable or a change in the network topology. The solution illustrated in
The inventors have realised the problems and limitations inherent in the static provisioning of pooling information for network resources such as servers and gateways. According to a first aspect of the invention, there is provided a method for selecting a network resource from a plurality of network resources in a communications network. A selection node receives a request for a network resource from a terminal, and then retrieves, from at least one further network node, data relating to the plurality of network resources. On the basis of the retrieved data, the selection node selects a network resource from the plurality of network resources. A response is then sent to the terminal, the response including information identifying the selected network resource. The central selection of network resources reduces the need to configure selection functionality in many different network nodes and improves the efficiency of using pooled network resources.
As an option, the network resource is selected from one of a server or gateway function. The data relating to the plurality of network resources is optionally retrieved from at least one database. The data comprises information relating to the status and capabilities of each network resource of the plurality of network resources. This allows the selection node to make a selection based on the capabilities of each network resource, and select the most suitable network resource for the terminal. The database is optionally dynamically updated as the capabilities and status of each network resource of the plurality of network resources changes, to ensure that the selection node receives the most up-to-date information about the network resources and their availability.
As a further option, the data relating to the plurality of network resources is any of a topology of each network resource in the network, a current load on each network resource, and a current capacity of the network on a path between the terminal and the network resource. This sort of information can be obtained without recourse to a database and gives the selection node information about current network conditions.
As an option, the method comprises retrieving from a Domain Name Server identities for each network resource of the plurality of network resources.
Optionally, the method further comprises retrieving, from a Home Subscriber Server, subscription and service information relating to a user or the terminal. This allows a network resource to be selected on the basis of the user's subscription or terminal's capabilities.
The request and the response are optionally Domain Name System messages. This allows the invention to be easily integrated with existing networks.
The retrieved data optionally comprises information selected from any of:
When selecting a network resource, the method optionally comprises discounting those network resources from the plurality of network resources that do not fulfil requirements of reachability or available services. In this way, unavailable or unsuitable network resources are not sent to the terminal.
When selecting a network resource, the method optionally includes balancing the load on network resources of the plurality of network resources. This ensures that network resources are used more efficiently, and reduces the risk of overload on one network resource whilst another is being under-used.
Optionally, the response to the terminal entity comprises an IP address of the network resource.
The communications network is optionally selected from a System Architecture Evolution network and an IP Multimedia Subsystem network.
According to a second aspect of the invention, there is provided a selection node for use in a communications network. The selection node comprises a receiver for receiving a request from a terminal for a network resource, and means for retrieving, from at least one further network node, data relating to a plurality of network resources. The selection node further comprises means for selecting a network resource from a plurality of network resources on the basis of the retrieved data, and a transmitter for sending a message to the terminal, the message including information identifying the selected network resource. The selection node reduces the need to configure selection functionality in many different network nodes and improves the efficiency of using pooled network resources.
Optionally, the means for retrieving data comprises means for retrieving data from a plurality of network nodes, as information from a variety of sources may be relevant to the selection process.
The network resource is optionally selected from one of a server or gateway function.
Optionally, the means for retrieving data relating to the plurality of network resources comprises means for retrieving data from at least one database, the data comprising information relating to the status and capabilities of each network resource of the plurality of network resources. As a further option, the means for retrieving data relating to the plurality of network resources comprises means for retrieving any of a topology of each network resource in the network, a current load on each network resource, and a current capacity of the network on a path between the terminal and the network resource. In this way information can be obtained that informs the selection node of current network conditions and information stored about the network resources.
The retrieved data optionally comprises information selected from any of a location on the network of each of the plurality of network resources, routing information for each of the plurality of network resources, current load on each of the plurality of network resources, current capacity of each of the plurality of network resources, current network capacity on a path between the terminal and each of the plurality of network resources, security information relating to each of the plurality of network resources, services available from each of the plurality of network resources, subscription information relating to a user or the terminal, and operator policy information.
The selection node optionally comprises means for discounting those network resources from the plurality of network resources that do not fulfil requirements of reachability or available services, to prevent unsuitable or unavailable network resources from being selected. The selection node optionally comprising means for balancing the load on network resources of the plurality of network resources, to reduce that risk that the network resources are not overloaded or under-used.
According to a third aspect of the invention, there is provided a terminal for use in a communications network. The terminal comprises a processor for generating a request message for a network resource, the request message comprising a Domain Name System query, the Domain Name System query further comprising the identity of the terminal encoded in a Fully Qualified Domain Name. By sending the request message in the form of a DNS query, the message can be forwarded directly to a DNS server, reducing the processing required for processing the message at various network nodes. Furthermore, by encoding the identity of the terminal in a FQDN, the terminal can be identified by a selection function even if the selection function is receiving signalling from a host communicating on behalf of the terminal.
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.
The following description discloses an enhanced gateway/server selection concept in a SAE/LTE system. However, it will be appreciated that the concept may be used in other types of network. The concept enables automatic selection of the most appropriate server or gateway for a communicating host from a plurality of network resources.
The queries to the data sources may be triggered by the request from the requestor 303, but the selection logic 301 may initiate queries independently in advance, in order to shorten response time.
The topology database 308 is dynamically updated by a Database synchronization function 309. The Database synchronization function 309 has the following functions:
Taking each of the above steps in turn, the request for the most suitable gateway/server uses on any type of suitable signalling capable to exchange the required information. In a preferred embodiment, the request is based on a DNS query, because DNS is supported by vast majority of IP hosts, so the impact on requestor functionality is low.
Assuming that a DNS query is used for a gateway/server request, then the service identification is based on a string encoded into the fully qualified domain name (FQDN) of the query, e.g., _inet.tcp.example.net, where _inet denotes the required service, e.g., an Internet connection.
The required Host parameter for the selection is the host's location. This is identified from the requestor's IP address in the case where the Host is the requestor itself. However, if the Host and Requestor are not identical, then the Host identifier is transferred in the DNS query message. This may be done by either of:
Turning now to steps 403 and 404, the server or gateway pool for service, and the IP addresses of the members of the pool must be identified. In a preferred embodiment, pool identification for the service is based on standard DNS features, and so the data source for the pools is a standard DNS server. Configuration of the DNS server with the list of selectable nodes for each service is performed by the network management system.
The pool identification comprises the following steps:
In a preferred embodiment, the initial request is in a form of a DNS query. This is so that the request may be forwarded by the selection logic 301 to the DNS server 306 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 and transfer it to the requestor.
The process of selecting a server or gateway pool is illustrated in
Turning now to step 405, the topology information, as well as status, capability and functionality of pool members, is identified. The data source for the above information is a topology database 308 that is dynamically updated, and the proposed system architecture is illustrated schematically in
The initial configuration of the database 308 may be done by the management system, such as the O&M system of the mobile network. In order to keep the topology database 308 updated, in a preferred embodiment of the invention a Database synchronization function 309 is provided, as illustrated in
During terminal attachment, a number of relevant SAE-GW scenarios are possible. The following assumes co-located serving and PDN SAEGws, and provides examples of important parameters for selection relevant to each of these scenarios.
In an IMS scenario, an anchor point must be selected to the “closest” GW site to achieve the shortest path with local switching, and so a site location is needed in the anchor point selection.
In a network redundancy scenario, GW-selection is based on an “up-and-running” GW set. Faulty GWs must be blocked and not used in the pool. “Up-and-running” information is required in anchor-point selection, and load information may also optimize the node-capacity usage, and so load information may also be included in anchor-point selection.
In a mobility specific GW/SAEGW scenario, an issue is to reselect a GW based on capability, in order to ensure that a GW that has the capability to deal with, for example, MIP, is used. In this instance, mobility type is used in the anchor point selection.
In Enterprise scenarios, in the situation of an out-door-in scenario in which an in-door network is covered with out-door eNodeBs of a cellular network, Enterprise traffic is routed via the operator backbone, and so an IPSec tunnel is required. In a GW/LTE within an Enterprise network scenario, an in-door network with eNodeBs and a GW is connected to a LAN. There is therefore local switching within the network, and so no need for an IPSec tunnel, but if traffic is routed via the operator network to the Enterprise network, an IPSec tunnel is required. In these scenarios, GW/SAEGW with connectivity to the Enterprise network and GW with IPSec capability should be used in anchor point selection. Furthermore, in certain circumstances, Enterprise-GW should be used in anchor point selection.
Where the Internet is used as a transport network, an IPSec and Denial of Service (DoS) resistant GW is required, and only traffic with a “relaxed” QoS requirement should be sent. Where Internet traffic is forwarded directly to the Internet, the closest GW to “internet peering” parameter should be used in anchor point selection. In addition a DoS resistant GW is required and a GW conforming to particular QoS info may be selected.
In a service specific GW scenario, one GW is provided for all services. An anchor point is selected based on the type of service, and so site location and service information is used in anchor point selection.
In a mobility scenario, the MME forces a GW reselection based on a location change of the user. GW reselection is possible either within or between pools. In this scenario, topology (site location) information is required in anchor point selection.
From the cases described above, the following set of parameters can be derived for SAE GW selection:
In order to select the most appropriate pool element, specific selection algorithms are required in the selection logic. The selection algorithm is typically different for control plane (server) or user plane (gateway) element selection so the existing algorithms for CP servers may not be directly applicable for gateways. Closeness on the transport topology is often a more important factor for the GW node selection as it provides better characteristics and efficient transport usage, but at the same time, the nodes should be protected from overload.
One way to select an element from the pool is on the basis of load and minimum cost, as follows:
1) Fetch the associated required capability with the APN.
2) Delete any pool-members that are not reachable (“up-and-running”)
3) Delete pool-members that do not fulfil the capability requirements (Security, Qos, IP-sec, Mobility-type etc.)
4) Select pool members that only fulfil requirements of access to expected services (e.g. Enterprise-VPN, Campus, Internet Peering)
5) Calculate the path length (i.e. the number of hops) in the topology database from the RBS.
6) Calculate/map a cost for “good-to-have” capabilities “P” that are not necessary.
7) Calculate cost=(a*Load+b*path_length+c*P), where a, b, and c are arbitrary selected constants.
8) Select the pool-member with minimum cost.
An element may also be selected from a pool on the basis of user subscription. In this case, subscription information can be retrieved from a node that handles user subscriptions, such as an HSS. This allows the use of advanced pooling, examples of which are:
1) Selection restrictions in HSS: For VPN-connection, an APN-can be assigned. An APN can have several IP-addresses i.e. a VPN connection subscriber can be connected to several SAE-GWs. Instead of different configuring each IP-address using the DNS, this can be restricted to limited set of SAE-GWs. One reason to use a restricted set of Pool-members is limitations in key-management for establishment of IP-sec tunnels into the SAE-GWs.
2) “APN in HSS”. To simplify the management, DNS-names are stored in a HSS. In this case, an APN-string from the Mobile Terminal is overridden by the HSS-configured DNS-name. Thus a common APN for a large group of users can be used, and explicit names can be retrieved from HSS.
3) “type of users”: Different subscription can have different restrictions in terms of capacity, rate and mobility. If a subscriber has a fixed-wireless subscription, their mobility is limited, and thus only a local SAEGW need be used. Thus, the HSS, can be have information regarding the DNS-name of the GW.
In the examples above, the following selection algorithm can be applied:
1) Fetch the DNS names from HSS.
2) Fetch the associated required capability with the DNS-name.
3) Delete pool-members that do not fulfil the capability requirements (Security, Qos, Ip-Sec, Mobility-Type Etc.)
4) Select pool members that only fulfil requirements of access to expected services (e.g. Enterprise-VPN, Campus, Internet Peering)
5) Calculate the path length (i.e. the number of hops) in the topology database from the RBS.
6) Calculate/map a cost for “good-to-have” capabilities “P” that are not necessary.
7) Calculate cost=(a*Load+b*path_length+c*P), where a, b, and c are arbitrary selected constants.
8) Select the pool-member with minimum cost.
Once an element has been selected from the pool, the IP address of the selected element is returned by the selection logic in a DNS answer. According to the proposal, the DNS answer will always include a single IP address.
An example of a terminal attachment in a SAE network architecture is illustrated in
When a terminal 701 attaches to the network, the following tasks are performed:
A signalling sequence diagram for terminal 701 attachment including the selection based on the proposed architecture is illustrated in
Once the terminal 701 has been assigned a SAEGW 314, other selection tasks are possible during service activation in the service domain, including both control plane server selection and user plane server selection, such as selection of an application server (AS) 901 by a CSCF 902, or selection of a Media Server (MS) 903 by the AS 901.
The invention is not limited to the cases discussed above, but may be used in other potential selection scenarios in SAE. One example is support for SAEGW relocation in mobile terminal idle mode. It can be useful to re-select a SAEGW in some situations, for example to achieve 51 path optimization for a mobile user. If the SAEGW pool size is small then the S1 path may not be too large, but on the other hand user mobility could often cause SAEGW relocation, which may affect ongoing sessions and may consume scarce control resources. In the case of an idle terminal and available control resources, it would be desirable to support SAEGW re-location by selecting a SAEGW.
The selection logic may help also in the selection of a proper local PDN SAEWG as an IP POP for a roaming user for optimized network usage (local breakout)
Referring to
Referring to
The invention provides a common architecture (single central logic) for selection of an element from a pool of elements, instead of having the selection logic implemented and configured in different control nodes. 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 from a pool of gateways or servers 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 invention is that it is based on standard DNS queries, so it does not require significant changes to the existing node functions and signalling chains. In most cases, all IP hosts support DNS. Compared to the DNS-based selection, the present invention allows for a fully topology-aware selection by using the topology database that provides:
Architectural enhancements allow the possibility of implementing DNS-based selection for the cases when the DNS requestor and the communicating host are not the same (e.g., SAEGW selection for a newly attached MT by the MME). Furthermore, automated management of pool configuration is provided for a given service by dynamic knowledge of node capability, status and functionality-related information in the topology database via Opaque LSAs. A number of important scenarios may be supported, like plug-n-play, network failures or network upgrades.
Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be read as implying that any particular element, step, or function is essential such that it must be included in the claims' scope. The scope of patented subject matter is defined by the claims.
The following acronyms are used in this specification:
SGSN Serving GPRS Support Node
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP08/50747 | 1/23/2008 | WO | 00 | 7/21/2010 |
