WO2013010585A1

WO2013010585A1 - Logical rules based domain name server setup

Info

Publication number: WO2013010585A1
Application number: PCT/EP2011/062434
Authority: WO
Inventors: Joachim Charzinski
Original assignee: Nokia Siemens Networks Oy
Priority date: 2011-07-20
Filing date: 2011-07-20
Publication date: 2013-01-24

Abstract

It is provided an apparatus, comprising converting means adapted to convert a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating means adapted to evaluate the second parameter to obtain a second evaluation result; providing means adapted to provide a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

Description

Title

Logical rules based domain name server setup

Field of the invention The present invention relates to an apparatus, a method, a system, and a computer program product related to name servers. More particularly, the present invention relates to an apparatus, a method, a system, and a computer program product for the usage of logical rules in domain name servers or their management systems. Background of the invention

Abbreviations

APN access point name bogw breakout gateway

BTS base transceiver station

DNS domain name system

EDGE Enhanced Data Rates for GSM Evolution

EPC evolved packet core

GGSN gateway GPRS support node

GPRS general packet radio service

GSM global system for mobile communication

GTP GPRS tunnelling protocol

GW gateway

HSPA high speed packet access l-HSPA Internet HSPA IP Internet protocol

ISDN integrated services digital network

LBO local breakout

LTE long term evolution

MME mobility management entity

M O mobile network operator

MSISDN Mobile Station International ISDN Number

PDN packet data network

PDP packet data protocol

P-GW PDN gateway

RNC radio network controller

SGSN serving GPRS support node

SGW serving gateway

SIPTO selected IP traffic offload

TDB topology database

TEID tunnel endpoint identifier

TS technical specification

UDB user database

UE user equipment (e.g. terminal)

UMTS universal mobile telecommunications system The present application is in the field of packet switched transport of traffic in cellular networks such as GSM (GPRS, EDGE), 3G (UMTS, HSPA) and LTE. It is relevant both for residential access points (femto base stations, home (e)nodeBs) and for pico and macro base stations (BTS, (e)nodeB), controllers (RNC) and dedicated offload equipment to be placed on the transport network on the way to a packet gateway. It contributes a solution to the problem of offloading bulk traffic from the 3GPP radio access network and core networks of a mobile network operator (MNO) without additional interfaces between a breakout gateway function and the rest of the packet core by providing a simple method for the packet core to control whether data path changes such as local Internet offload and local IP access are allowed for a specific context.

Within this application, the term "bulk traffic" may preferably be used to refer to IP traffic that does not increase operator revenues with increased volume, e.g. general Internet or peer-to-peer traffic within a flat rate contract of a user. However, the term "bulk traffic" is not limited to this meaning and may mean any IP traffic.

Fig. 1 shows a reference network consisting of terminals 101 and 102 (UE, user equipment), a base station 103, a radio network controller (RNC) function 104 (which may be integrated with the base station 103 in the case of Internet-HSPA or evolved HSPA or may be separated from the base station, e.g. by a backhaul network), a first packet gateway (GGSN, S/P-GW) 105 located centrally in the packet core network, an SGSN 106, a DNS server 107, the Internet 108, a second (local) packet gateway 109 and an offload network 110. When the SGSN 106 receives a context setup request for a given APN (access point name), it may query the name server 107 with a location specific request (e.g. rnc104.gprs.operator.net) or extend this request by additional user specific parameters such as the subscriber's MSISDN (e.g. 491727002286.rnc104.operator.net). The SGSN 106 may then choose an appropriate GGSN function (e.g. core GGSN 105 or local gateway 109) depending on location and/or user specific policies.

Fig. 2 shows the basic control plane message sequence chart for PDP context activation with the following messages:

UE to SGSN: activate PDP context (APN)

SGSN to DNS server: DNS query (APN) 303 DNS server to SGSN: DNS response (GGSN IP address)

304 SGSN to GGSN: create PDP context request

305 GGSN to SGSN: create PDP context response

306 SGSN to UE: activate PDP context accept

A problem arises if more parameters are included in the DNS request, the more complex the mapping between the parameter space and the DNS namespace gets, as DNS only provides a hierarchical way of modelling data.

It is known a hierarchical DNS based approach to let an SGSN or MME determine a suitable gateway for a user at a given location. There are two ways to implement non- hierarchical lookups with this approach. Either all combinations of parameters have to be provided in the DNS configuration to completely populate a fully hierarchical name space, or an independent mechanism in the network - restricted access to closed user groups and fall-back to alternative APNs - is used to complement DNS based gateway lookup.

Current 3GGP proposals for local gateway selection suggest to use DNS to determine an IP address for local gateway, especially for the home (e)nodeB case.

Some Internet based services use DNS for other logical but still strictly hierarchical addressing, e.g. in the context of "web bugs" (logging DNS requests to specially crafted artificial domain names) and tracking cookies (see Fig. 3 for an example of pseudo domain names created by Omniture). This application of DNS already shows that DNS can be used for more than the main purpose of looking up an IP address for a given domain name.

Alternatively, the SGSN (or MME) may determine the gateway to use by contacting a policy server (ip.com prior art database publication number IP.com number: IPCOM000190087D, Nov. 17, 2009) or by integrating the gateway selection rules directly into its GW selection process, possibly using additional input from external sources. This approach requires implementation of a non-standard policy interface in the SGSN/MME element.

Wildcard entries in DNS configuration are supported by several DNS server implementations. These allow catching default cases without enumeration of all possibly requested names, but they have to be configured manually for a domain.

Summary of the invention It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus, comprising converting means adapted to convert a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating means adapted to evaluate the second parameter to obtain a second evaluation result; providing means adapted to provide a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

In the apparatus, the converting means may be further adapted to convert the first field into a first parameter; the evaluating means may be further adapted to evaluate the first parameter based on the second evaluation result to obtain a first evaluation result; and the providing means may be adapted to provide the network address additionally based on the first evaluation result.

In the apparatus, the predefined format may be an internet protocol format and/or the hierarchy may be of a domain name hierarchy. In the apparatus, the first field and the second field may be each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field may be related to a different first property than the second field.

The apparatus may further comprise retrieving means adapted to retrieve a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating means may be additionally adapted to evaluate the second property to obtain a third evaluation result; and the providing means may be adapted to provide the network address additionally based on the third evaluation result.

According to a second aspect of the invention, there is provided an apparatus, comprising converting processor adapted to convert a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating processor adapted to evaluate the second parameter to obtain a second evaluation result; providing processor adapted to provide a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

In the apparatus, the converting processor may be further adapted to convert the first field into a first parameter; the evaluating processor may be further adapted to evaluate the first parameter based on the second evaluation result to obtain a first evaluation result; and the providing processor may be adapted to provide the network address additionally based on the first evaluation result.

The apparatus may further comprise retrieving processor adapted to retrieve a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating processor may be additionally adapted to evaluate the second property to obtain a third evaluation result; and the providing processor may be adapted to provide the network address additionally based on the third evaluation result.

According to a third aspect of the invention, there is provided a domain name server, comprising an apparatus according to any of the first and second aspects.

According to a fourth aspect of the invention, there is provided a system, comprising a name server apparatus according to the first aspect; and a resolver apparatus comprising inquiring means adapted to inquire the name server apparatus for the hierarchical address; receiving means adapted to receive, in response to the inquiry, the network address from the name server apparatus; and routing means adapted to route a message based on the network address.

According to a fifth aspect of the invention, there is provided a system, comprising a name server apparatus according to the second aspect; and a resolver apparatus comprising inquiring processor adapted to inquire the name server apparatus for the hierarchical address; receiving processor adapted to receive, in response to the inquiry, the network address from the name server apparatus; and routing processor adapted to route a message based on the network address.

According to a sixth aspect of the invention, there is provided an apparatus, comprising evaluating means adapted to evaluate a second parameter to obtain a second field and to evaluate a first parameter based on the evaluation of the second parameter to obtain a first field; building means adapted to build a hierarchical address of a hierarchy comprising the first field and the second field, wherein the first field is at a higher hierarchical level of the hierarchy than the second field; providing means adapted to provide a pair of the hierarchical address and a network address, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

In the apparatus, the predefined format may be an internet protocol format and/or the hierarchy may be of a domain name hierarchy.

In the apparatus, the first field and the second field may be each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field may be related to a different first property than the second field.

The apparatus may further comprise obtaining means adapted to obtain a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating means may be adapted to additionally evaluate the second property to obtain at least one of the first field and the second field.

The apparatus may further comprise triggering means adapted to trigger the obtaining means to obtain the second property.

The apparatus may further comprise retrieving means adapted to retrieve the network address from a topology database. According to a seventh aspect of the invention, there is provided an apparatus, comprising evaluating processor adapted to evaluate a second parameter to obtain a second field and to evaluate a first parameter based on the evaluation of the second parameter to obtain a first field; building processor adapted to build a hierarchical address of a hierarchy comprising the first field and the second field, wherein the first field is at a higher hierarchical level of the hierarchy than the second field; providing processor adapted to provide a pair of the hierarchical address and a network address, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

The apparatus may further comprise obtaining processor adapted to obtain a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating processor may be adapted to additionally evaluate the second property to obtain at least one of the first field and the second field.

The apparatus may further comprise triggering processor adapted to trigger the obtaining processor to obtain the second property.

The apparatus may further comprise retrieving processor adapted to retrieve the network address from a topology database. According to an eighth aspect of the invention, there is provided a management system comprising an apparatus according to any of the sixth and seventh aspects.

According to a ninth aspect of the invention, there is provided a system, comprising a management apparatus according to the sixth aspect; and a name server apparatus comprising name pair receiving means adapted to receive the pair of the hierarchical address and the network address from the management apparatus; request obtaining means adapted to obtain a request comprising the hierarchical address; and responding means adapted to provide, in response to the request, the network address.

According to a tenth aspect of the invention, there is provided a system, comprising a management apparatus according to the seventh aspect; and a name server apparatus comprising name pair receiving processor adapted to receive the pair of the hierarchical address and the network address from the management apparatus; request obtaining processor adapted to obtain a request comprising the hierarchical address; and responding processor adapted to provide, in response to the request, the network address.

According to an eleventh aspect of the invention, there is provided a method, comprising converting a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating the second parameter to obtain a second evaluation result; providing a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

The method may be a method of a domain name server. The method may further comprise converting the first field into a first parameter; evaluating the first parameter based on the second evaluation result to obtain a first evaluation result; and providing the network address additionally based on the first evaluation result.

In the method, the predefined format may be an internet protocol format and/or the hierarchy may be of a domain name hierarchy.

In the method, the first field and the second field may be each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field may be related to a different first property than the second field.

The method may further comprise retrieving a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; evaluating the second property to obtain a third evaluation result; and providing the network address additionally based on the third evaluation result.

According to a twelfth aspect of the invention, there is provided a method, comprising evaluating a second parameter to obtain a second field; evaluating a first parameter based on the evaluation of the second parameter to obtain a first field; building a hierarchical address of a hierarchy comprising the first field and the second field, wherein the first field is at a higher hierarchical level of the hierarchy than the second field; providing a pair of the hierarchical address and a network address, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

The method may be a method of a management system. In the method, the predefined format may be an internet protocol format and/or the hierarchy may be of a domain name hierarchy.

The method may further comprise obtaining a second property, wherein the second property may be one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the second property may be additionally evaluated to obtain at least one of the first field and the second field.

The method may further comprise triggering the obtaining of the second property.

The method may further comprise retrieving the network address from a topology database.

According to a thirteenth aspect of the invention, there is provided a computer program product including a program comprising software code portions being arranged, when run on a processor of an apparatus, to perform the method according to any one of the eleventh and twelfth aspects.

The computer program product may comprise a computer-readable medium on which the software code portions are stored, and/or wherein the program is directly loadable into a memory of the processor. According to embodiments of the invention, at least the following advantages are achieved: It is provided a way of freely expressing and implementing rules for gateway assignment based on arbitrary combinations of many parameters such as location of terminal, terminal type, user subscription, user mobility history, user traffic volume history, roaming status, gateway and network load situation. Thus, the options for the operator to control offloading are increased and, at the same time, the load on the name server and/or the load on the operator to manage the name server may be reduced. The solutions are backward compatible, namely no modifications on the interface of the SGSN to the name server and the I P network are required.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives. Brief description of the drawings

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein

Fig. 1 shows a reference network;

Fig. 2 shows a message sequence chart for DNS based gateway selection; Fig. 3 shows DNS subdomains used by Omniture Inc. for tracking cookies;

Fig. 4 shows an example network with four RNC functions;

Fig. 5 shows an exemplary hierarchical DNS name space model for the example network of Fig. 4;

Fig. 6 shows a decision table for the example of Fig. 5;

Fig. 7 shows a decision flow in a DNS server according to an embodiment of the invention for realizing the example mappings of Fig. 5; Fig. 8 shows the example network of Fig. 4 augmented by a policy server function;

Fig. 9 shows a message sequence corresponding to the message sequence of Fig. 2, Error! Reference source not found, when an additional server, e.g. policy server, is queried dynamically by a DNS server according to an embodiment of the invention;

Fig. 10 shows a DNS server according to an embodiment of the invention connected to multiple external databases;

Fig. 11 shows the decision flow of Fig. 7 wherein the user rule lookup is replaced by a function TNO(id) indicating Traffic-Not-Offloadable status;

Fig. 12 shows an apparatus according to an embodiment of the invention;

Fig. 13 shows a method according to an embodiment of the invention;

Fig. 14 shows a management element according to an embodiment of the invention converting operator specified rules into configuration for DNS name server;

Fig. 15 shows a logical representation of mapping contract type and location to gateway address for a management element according to an embodiment of the invention;

Fig. 16 shows an example for a configuration file generated by a management system according to an embodiment of the invention;

Fig. 17 shows an example name space for the logical representation of Fig. 15;

Fig. 18 shows a wildcard optimized DNS tree for the example of Fig. 5;

Fig. 19 shows an example for including RNC location mapping data from an external database in the automated DNS zone file generation according to an embodiment of the invention; Fig. 20 shows an inclusion of user database triggered changes to temporarily change a treatment of a single subscriber according to an embodiment of the invention; Fig. 21 shows an apparatus according to an embodiment of the invention; and Fig. 22 shows a method according to an embodiment of the invention.

Detailed description of certain embodiments

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given for by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details. Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

Today, there is no efficient way of freely expressing and implementing rules for gateway assignment based on arbitrary combinations of many parameters such as location of terminal, terminal type, user subscription, user mobility history, user traffic volume history, roaming status, gateway and network load situation.

In order to explain the problem, the example network in Fig. 4 is used. It shows four base stations (121 , 122, 123, 124) with four associated RNC functions (stand-alone RNCs 131 and 132 and l-HSPA integrated versions 133 and 134) and different local gateways 201 and 204 as well as the core gateway 250.

Assume that the operator policy is to offload bulk traffic (i.e., traffic to and from customers with a "bulk" type of contract) locally when possible (GGSN 201 for RNC functions 131 and 132, GGSN 204 for RNC function 134) and use the core gateway otherwise ("VIP" type of contracts or RNC functions such as RNC 133 without corresponding local gateway). Assume in addition that there is the need for temporarily serving some "bulk" subscribers (with identity Ix) via the core gateway (e.g. because they have recently had a service interruption after moving out of a local gateway's service area and should not experience another interruption again). Assume furthermore that the policy for RNC function 134 is to offload even "VIP" type customers because the base station 124 is located in an area without possibility for handovers into other cells (e.g. on a future airplane with mobile access enabled, on a service island of a network just being built up, in an otherwise unserved basement etc). Assume as an example that the DNS request format being used by the operator is of the format subschberldentity.contractClass.rncLocation.mnc02.mcc262.3gppnetwork.org

This is just for simplicity of explanation and not meant to exclude formats similar to the description in 3GPP TS 23.003 Sec. 9.1.2 where a format like ggsn-cluster-A.provinceB.mnc012.mcc345.gprs or Sec. 19.4.2.3 where a format like tac-lb<TAC-low-byte>.tac-hb<TAC-high- byte>.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org is advised. Operators should be able to choose if they want to precede subdomain parts with their function (as in tac-hb<TAC-high-byte>) or rely on the domain hierarchy sufficiently determining the notion of each part of the domain name.

The sequence of the fields represents their hierarchy. In the examples outlined above, the hierarchy level gets higher from left to right.

The corresponding hierarchical DNS namespace is sketched in Fig. 5. Wildcards in the lowest level domain are used to avoid excessive listing of all possible subscriber identities. Due to the hierarchical authority delegation principle used in DNS, wildcards cannot be used in higher levels when a lower level is still to be evaluated.

Fig. 5 shows the example of the hierarchical name space tree corresponding to the example network situation and policy presented above. The problem is that this tree explodes as more values are allowed per level. According to embodiments of the invention, all subdomains (e.g. of mnc<MNC>.mcc<MCC>.3gppnetwork.org or the corresponding .gprs domain) are handled by a DNS server such as DNS server 107. This special DNS server, instead of building up a static hierarchical tree of subdomains, may interpret requests as database query and may execute some logical rules on it. The DNS server may return results (DNS response) just like a normal DNS server. The DNS server 107 may evaluate all subdomains under the common domain at the same time and may also emulate the corresponding authority and name server pointer information in case it receives requests that include only a sub-tree of the domain name.

In the example of the DNS hierarchy shown in Fig. 5, which can be represented as a logical decision table as shown in Fig. 6, the lookup flow within DNS server 107 may be as indicated in the flow chart of Fig. 7: The DNS server 107 may first convert the subdomain fields received in the DNS query into separate query parameters (in the case of this example: id, loc and type) and may then perform logical operations to determine the address to be returned in the DNS response. This address may be an IPv4 or IPv6 address and is only schematically entered in the above examples as references to the gateway elements 201 , 204 and 250 according to Fig. 4.

Conventionally, complete DNS trees (similar to that of Fig. 5) have to be configured in the name servers. According to some embodiments, the hierarchies that need to be configured in conventional name servers may be substituted by a lookup process based on logical rules. Especially when multiple parameters are taken into account for gateway selection, or when a lot of cases end up in selecting a default gateway, the complexity of configuration may be significantly reduced. Compared to implementations that include the database lookup directly in the SGSN or MME, embodiments of the invention may still use standard procedures already available in SGSN or MME (DNS lookup for gateway selection). Thus, the solution is backwards compatible.

In some embodiments of the invention, the following exemplary parameters may be contained in the DNS request and may be evaluated by the DNS server:

o access point name

o location of terminal or RNC function terminal type

user subscription.

In addition, other network servers such as a policy server 11 1 as shown in Fig. 8 may interwork with the DNS. Apart from the policy server 11 1 , the network of Fig. 8 corresponds to that of Fig. 4. The DNS server may query the policy server to look up updated or user specific rules. Corresponding messages 312 and 313 between the DNS server 107 and the additional server 1 11 are shown in Fig. 9. Thus, the DNS server may additionally obtain further parameters not signaled in the DNS request from other network servers such as the policy server 111. Exemplary additional parameters are: Exemplary additional parameters are: o user mobility history

o user traffic volume history

o roaming status

o gateway and network load situation

o time of day

o special promotion actions and user's subscription status

According to some embodiments, the RNC may be separate or integrated into BTS (I- HSPA) or not present (LTE), with the corresponding packet core changes (EPC with MME and S/P-GW).

The example embodiment shown has an architecture for direct tunnel, but other embodiments may use local GGSNs according to normal rel.6 architecture with a data path through SGSN. In these embodiments, the working principle may be similar, but the solution might be less effective.

DNS server 107 and/or policy server 1 11 may be duplicated for redundancy reasons

In some embodiments, the DNS server may interact multiple internal and external databases, as shown in Fig. 10. Fig. 10 shows DNS server 107 connected to multiple external databases, such as policy server 11 1 with connection to subscriber data management 1 15, terminal capabilities database 112, load and/or performance monitoring system 113 and topology database 1 14 containing gateway locations.

Coding of subdomain parameters in the DNS request may be according to fixed position in the request string, e.g.

<subscriberldentity>.<rncLocation>...,

or the fields may include an indication of what parameter is meant, as in id<subscriberldentity>.loc<rncLocation>

or it may be a mixture of different approaches.

A pre-defined wildcard string (e.g. "na") may be defined to indicate in the DNS request that the corresponding parameter is not known to the requester (SGSN 106).

Further examples rules are as follows: Similar to the rule set visualized in Fig. 7, rule sets such as the following pseudo code might be configured:

if ((contract == bulk) && (terminal == pc_type) && ((time_of_day == peak) ||

(load_situation == high)) then return ipAddress(localGatewayl_ookup(location)) else return ipAddress(selectCoreGateway())

Fig. 11 shows the decision flow of Fig. 7 , wherein the local user status table is replaced by a dynamic request TNO(id) to policy server 111. TNO(id) indicated a Traffic-Not- Offloadable status for a user with a given id, which e.g. may be looked up dynamically in policy server 111 shown in Fig. 8.

Fig. 12 shows an apparatus according to an embodiment of the invention. The apparatus may be a name server such as a DNS. Fig. 13 shows a method according to an embodiment of the invention. The apparatus according to Fig. 12 may perform the method of Fig. 13 but is not limited to this method. The method of Fig. 13 may be performed by the apparatus of Fig. 12 but is not limited to being performed by this apparatus. The apparatus comprises converting means 10, evaluating means 20, and providing means 30.

In contrast to a hierarchical approach, the converting means 10 may convert a field of a lower hierarchy level comprised in a received hierarchical address into a parameter (S10). The evaluating means 20 may evaluate the second parameter to obtain an evaluation result (S20). Based on the evaluation result, the providing means (30) may provide a network address suitable as routing address of a network element (S30), such as an IP address.

According to some other embodiments, the logical rules may be implemented in a management system used to configure the name server. Namely, some embodiments of the invention may comprise a management system or part thereof that takes as an input a set of logical rules describing which gateway should be selected under what circumstances and produces as output a set of one or more configuration files for a DNS name server process defining the name space corresponding to the rules.

Fig. 14 shows the management system 140 according to an embodiment of the invention converting the operator specified rule set 141 into configuration files for the name server 107. In some of these embodiments, the name server itself may work like a conventional name server.

As an example use case, the logical representation of a mapping between two parameters (contract type, location) to gateway addresses may be considered. Let the DNS format of the queries be type<contractType>.loc<rncLocation>.mnc<MNC>.mcc<MCC>.3gppnetwork.org.

The rule in this example is simply to return a breakout gateway depending on the location for all non-VIP contract users and to return the core gateway's address (250) for all VIP users except in location rnc134 where the breakout function is also to be used by VIP users. The corresponding flow chart is shown in Fig. 15.

After describing such a rule set either graphically or in logical code formulation, such as if not (type==vip) return(bogw(loc)) else if (loc==rnc134) return(204) else return (250)

to the management system 130, the management system 130 may generate a corresponding configuration file for the DNS server 107, as shown in Fig. 16, which represents the zone data for the namespace tree shown in Fig. 17. A corresponding engine may e.g. iterate a number of loops through

all possible parameter values.

Conventionally, complete DNS trees (similar to that of Fig. 17) have to be configured in the name servers. According to embodiments of the invention, the situation may be improved by automatically generating the corresponding zone data for the name server based on logical rules. Especially when multiple parameters are taken into account for gateway selection, or when a lot of cases end up in selecting a default gateway, the complexity of configuration may be significantly reduced.

The parameters contained in a DNS request and evaluated by the DNS server may be similar to those of the other embodiments, e.g.

o access point name

o location of terminal or RNC function

o terminal type

o user subscription.

Further parameters not signaled in the DNS request but obtained e.g. from policy or other network server lookups, may be evaluated such as: o user mobility history

o user traffic volume history

o roaming status

o gateway and network load situation

o time of day

o special promotion actions and user's subscription status. According to some embodiments, the RNC may be separate or integrated into BTS (I- HSPA or evolved HSPA) or not present (LTE), with the corresponding packet core changes (EPC with MME and S/P-GW).

The name space tree may be automatically optimized by using wildcards, as indicated by Fig. 18 for the example from Fig. 5.

The generated configuration file(s) may be automatically configured to the DNS server 107, and the DNS server may automatically be triggered to change its configuration to using the new files (e.g. by restarting)

The whole process may also regularly (e.g. periodically) include updates from other databases to generate new zone files, e.g. considering new network load data.

The management system 140 may include a graphical, textual, file or network protocol based interface for loading new logical rules. The management system 140 may include a "what-if component that allows a network operator to first validate the given rule sets by examples before actually deploying configuration changes to name servers. The management system 140 may produce additional information such as glue records and authority data for multiple domain hierarchy levels to be included in the DNS server configuration.

<subscriberldentity>.<rncLocation>...,

or the fields can include an indication of what parameter is meant, as in

id<subscriberldentity>.loc<rncLocation>,

or it may be a mixture of different approaches. A wildcard string (e.g. "na") may be defined to indicate in the DNS request that the corresponding parameter is not known to the requester (SGSN 106).

Parts of the required enumeration of parameters may be obtained from a separate database, as indicated in the example of Fig. 19 for using a topology database to map RNC locations to local gateway addresses. Fig. 19 shows interworking of the management system 140 with a topology database 142 for enumeration and resolution of RNC locations into gateway addresses. In message(s) 311 , the management system requests information from the topology database 142, which is then delivered in message(s) 312. These steps can be repeated multiple times before new configuration data are transferred in step 302. Instead of or in addition to the topology database, other internal or external databases may be used as indicated with respect to the other embodiments above.

In the case where single subscriber identities are temporarily taken out of the local gateway assignment despite their bulk contract status (e.g. because they have suffered from connection resets after cell changes), this may optionally be reflected by an extension of the DNS configuration process, as shown in Fig. 20. Fig. 20 shows how asynchronous updates from a user data base 143 may be included. The user database may notify the management system in step 323 to temporarily configure an exception rule for a single user identity or a group of users, which is then included in the zone files and transferred to the name server in step 324. After some time (e.g. by a timeout), the configuration may be undone or new configuration files may be produced and loaded into the DNS server in step 326. This change may be initiated by the user database as shown in step 325, or it may be performed automatically by the management system. In some embodiments, multiple temporary reconfigurations may be active at the same time.

Fig. 21 shows an apparatus according to an embodiment of the invention. The apparatus may be a management system such as a management system of a DNS. Fig. 22 shows a method according to an embodiment of the invention. The apparatus according to Fig. 21 may perform the method of Fig. 22 but is not limited to this method. The method of Fig. 22 may be performed by the apparatus of Fig. 21 but is not limited to being performed by this apparatus. The apparatus comprises evaluating means 60, building means 70, and providing means 80.

The evaluating means 60 may evaluate a second parameter to obtain a field of a lower hierarchy level and may evaluate a first parameter based on the evaluation of the second parameter to obtain a field of a higher hierarchy level (S60). The building means 70 may build a hierarchical address comprising the field of the higher hierarchy level and the field of the lower hierarchy level according to their respective hierarchy levels (S70). The providing means 80 may provide a pair of the hierarchical address and a network address, wherein the network address is of a predefined format suitable as routing address of a network element (S80), such as a pair of domain name address and IP address.

Embodiments of the invention are described with respect to a domain name server of an IP network. However, instead of the domain name, another hierarchical name may be used, as long as the name represents a hierarchy. E.g., the sequence of fields in the hierarchical name may follow a sequence from lower hierarchy to higher hierarchy or from higher hierarchy to lower hierarchy. In some embodiments, the sequence of fields in the hierarchical name may be not a monotonous function of the hierarchy, if this non- monotonous function is predefined.

The network address may be an IP address, e.g. of IP v4 or IP v6. However, it may be any other address of a protocol which is suitable for routing to a network element such as MPLS labels or tunnel identifiers. In some embodiments, the management system of the DNS may be incorporated in the

DNS, or the DNS and the management system may be separate entities. In some embodiments, the network element inquiring the DNS may be incorporated in the DNS, or the DNS and the inquiring network element may be separate entities. In some embodiments, the DNS may resolve a hierarchical address based on logical rules only. In some embodiments, it may resolve a hierarchical address according to the hierarchy and according to logical rules. E.g., the DNS may resolve the higher hierarchical levels according to the hierarchy and the lower hierarchical levels according to logical rules. In some embodiments, the DNS may decide based on specific criteria (e.g. higher level fields) whether to resolve a hierarchical name based on the hierarchy or on logical rules. E.g., for some values of a higher hierarchy field, the resolution is performed according to the hierarchy and for others according to logical rules.

Some embodiments of the invention may be employed within fixed networks.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they are differently addressed in the mobile network. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware.

According to the above description, it should thus be apparent that exemplary embodiments of the present invention provide, for example a domain name server, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). Further exemplary embodiments of the present invention provide, for example a management entity, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claims

1. Apparatus, comprising converting means adapted to convert a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating means adapted to evaluate the second parameter to obtain a second evaluation result; providing means adapted to provide a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

2. The apparatus according to claim 1 , wherein the converting means is further adapted to convert the first field into a first parameter; the evaluating means is further adapted to evaluate the first parameter based on the second evaluation result to obtain a first evaluation result; and the providing means is adapted to provide the network address additionally based on the first evaluation result.

3. The apparatus according to any of the preceding claims, wherein the predefined format is an internet protocol format and/or the hierarchy is of a domain name hierarchy.

4. The apparatus according to any of the preceding claims, wherein the first field and the second field are each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field is related to a different first property than the second field.

5. The apparatus according to any of the preceding claims, further comprising retrieving means adapted to retrieve a second property, wherein the second property is one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating means is additionally adapted to evaluate the second property to obtain a third evaluation result; and the providing means is adapted to provide the network address additionally based on the third evaluation result.

6. Domain name server, comprising an apparatus according to any of the preceding claims.

7. System, comprising a name server apparatus according to any of claims 1 to 5; and a resolver apparatus comprising inquiring means adapted to inquire the name server apparatus for the hierarchical address; receiving means adapted to receive, in response to the inquiry, the network address from the name server apparatus; and routing means adapted to route a message based on the network address.

8. Apparatus, comprising evaluating means adapted to evaluate a second parameter to obtain a second field and to evaluate a first parameter based on the evaluation of the second parameter to obtain a first field; building means adapted to build a hierarchical address of a hierarchy comprising the first field and the second field, wherein the first field is at a higher hierarchical level of the hierarchy than the second field; providing means adapted to provide a pair of the hierarchical address and a network address, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

9. The apparatus according to claim 8, wherein the predefined format is an internet protocol format and/or the hierarchy is of a domain name hierarchy.

10. The apparatus according to any of claims 8 and 9, wherein the first field and the second field are each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field is related to a different first property than the second field.

11. The apparatus according to any of claims 8 to 10, further comprising obtaining means adapted to obtain a second property, wherein the second property is one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the evaluating means is adapted to additionally evaluate the second property to obtain at least one of the first field and the second field.

12. The apparatus according to claim 11 , further comprising triggering means adapted to trigger the obtaining means to obtain the second property.

13. The apparatus according to any of claims 8 to 12, further comprising retrieving means adapted to retrieve the network address from a topology database.

14. Management system comprising an apparatus according to any of claims 8 to 13.

15. System, comprising a management apparatus according to any of claims 8 to 13; and a name server apparatus comprising name pair receiving means adapted to receive the pair of the hierarchical address and the network address from the management apparatus; request obtaining means adapted to obtain a request comprising the hierarchical address; and responding means adapted to provide, in response to the request, the network address.

16. Method, comprising converting a second field comprised in a received hierarchical address of a hierarchy into a second parameter, wherein a first field comprised in the hierarchical address is at a higher hierarchical level of the hierarchy than the second field; evaluating the second parameter to obtain a second evaluation result; providing a network address based on the second evaluation result, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

17. The method according to claim 16, further comprising converting the first field into a first parameter; evaluating the first parameter based on the second evaluation result to obtain a first evaluation result; and providing the network address additionally based on the first evaluation result.

18. The method according to any of claims 16 and 17, wherein the predefined format is an internet protocol format and/or the hierarchy is of a domain name hierarchy.

19. The method according to any of claims 16 to 18, wherein the first field and the second field are each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field is related to a different first property than the second field.

20. The method according to any of claims 16 to 19, further comprising retrieving a second property, wherein the second property is one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; evaluating the second property to obtain a third evaluation result; and providing the network address additionally based on the third evaluation result.

21. Method, comprising evaluating a second parameter to obtain a second field; evaluating a first parameter based on the evaluation of the second parameter to obtain a first field; building a hierarchical address of a hierarchy comprising the first field and the second field, wherein the first field is at a higher hierarchical level of the hierarchy than the second field; providing a pair of the hierarchical address and a network address, wherein the network address is of a predefined format different from a format of the hierarchical address and suitable as routing address of a network element.

22. The method according to claim 21 , wherein the predefined format is an internet protocol format and/or the hierarchy is of a domain name hierarchy.

23. The method according to any of claims 21 and 22, wherein the first field and the second field are each related to a first property out of a location of a network element, a location of a terminal, a contract type, a subscriber identity, a terminal type, and an access point name, wherein the first field is related to a different first property than the second field.

24. The method according to any of claims 21 to 23, further comprising obtaining a second property, wherein the second property is one of a user mobility history, a user traffic history, a roaming status, a gateway load status, a network load status, a time of a day, a special promotion action status, and a user subscription status; and wherein the second property is additionally evaluated to obtain at least one of the first field and the second field.

25. The method according to claim 24, further comprising triggering the obtaining of the second property.

26. The method according to any of claims 21 to 25, further comprising retrieving the network address from a topology database.

27. A computer program product including a program comprising software code portions being arranged, when run on a processor of an apparatus, to perform the method according to any one of claims 16 to 26.

28. The computer program product according to claim 28, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored, and/or wherein the program is directly loadable into a memory of the processor.