WO2013072403A1

WO2013072403A1 - Method for supporting pdn connectivity of a mobile terminal and mobile terminal

Info

Publication number: WO2013072403A1
Application number: PCT/EP2012/072693
Authority: WO
Inventors: Tarik Taleb; Stefan Schmid; Johannes LESSMANN
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2011-11-15
Filing date: 2012-11-15
Publication date: 2013-05-23
Anticipated expiration: 2014-05-15

Abstract

A method for supporting PDN (Packet Data Network) connectivity of a mobile terminal (1) in a mobile operator network, wherein said mobile terminal (1) is capable of establishing PDN connections via different anchor points in the core network, is c h a r a c t e r i z e d i n that the method comprises the steps of said mobile terminal (1) initiating a process for establishing an IP session with a target node (2) with respect to an application, and performing a decision process in which a suitable anchor point for establishing a PDN connection for said IP session is selected by taking into consideration at least one of application type information and E2E connection information according to configurable selection rules. Furthermore, a mobile terminal with PDN connectivity support is disclosed.

Description

METHOD FOR SUPPORTING PDN CONNECTIVITY OF A MOBILE TERMINAL AND MOBILE TERMINAL

The present invention relates to a method for supporting PDN (Packet Data Network) connectivity of a mobile terminal in a mobile operator network, wherein said mobile terminal is capable of establishing PDN connections via different anchor points in the core network.

Furthermore, the present invention relates to a mobile terminal with PDN connectivity support, wherein said mobile terminal is capable of establishing PDN connections via different anchor points in the core network.

Along with the ever-growing community of mobile data users and the tremendous increase in the traffic associated with a wide range of emerging bandwidth- intensive mobile applications, mobile operators are facing a challenging task to accommodate such huge traffic volumes, far beyond the original network capacity. To cope with this problem and also to compensate for the decrease in the ARPU (Average Revenue per User), selectively offloading traffic as close to the Radio Access Network (RAN) as possible is one of the key solutions in which many operators have shown interest. Such traffic offload can be achieved based on local data anchor gateways located close to the RAN, which essentially leads to a decentralized mobile network deployment.

In such a decentralized network, Packet Data Network Gateways (PDN-GWs), Serving GWs (S-GWs), and Mobility Management Entities (MMEs), are locally deployed to serve the local community of users. The benefits of such decentralized mobile networks are manifold, among them the opportunity on the side of mobile network operators to make use of their resources in an optimized way. However, efficient usage of network resources requires selecting data anchor gateways - or anchor points to put it more generally, i.e. termination points of the packet data interface towards external PDNs (Packet Data Networks) - in an optimal fashion. In the present invention terms like 'data anchor gateways' or 'anchor points' will be employed synonymously to generally denote the GW in the mobile network that provides mobile terminals an IP address and serves as a mobility anchor for a PDN connection (in case of LTE/EPC (Long Term Evolution/Evolved Packet Core)) or in a PDP (Packet Data Protocol) context (in case of GPRS, General Packet Radio Service). Examples of those gateways are the PDN-GW (EPC) or GGSN (Gateway GPRS Support Node) in case of GPRS. This GW basically connects a mobile terminal to a PDN such as the Internet, a Corporate Network, or an IMS (IP Multimedia Subsystem) network.

Further, the concept of Access Point Name (APN) has been designed for GPRS and was carried over to UMTS (Universal Mobile Telecommunications System) and EPS (Evolved Packet System) as a scheme to separate logical from physical points of interconnection between a 3GPP operator's IP network and connected-to external PDNs. An APN allows to associate one logical name with a particular type of traffic and maps it flexibly - but constant for the duration of an IP/PDN connection - to a route and point of interconnection. The mapping is done by the network based on DNS (Domain Name System) and the UE may not be aware of it. The UE is not concerned with details of the backend connectivity. This is suitable for the typical, highly centralized network deployments; yet, with new traffic and load scenarios coming into play, especially traffic offload at decentralized points, this is no longer sufficient. The UE, not necessarily the user, may become involved at least partially with network topology for the sake of its optimal backend connectivity, e.g. minimal network resource consumption, cost and/or latency; even with active data transmission over relatively long durations and with larger scale mobility. At this point it is noted that although the terminology used hereinafter basically refers to the Evolved Packet System (EPS), the concept of the present invention can be equally applied to other 3GPP's mobile networks such as GPRS.

Fig. 1 illustrates the problems associated with the above mentioned anchor point selection process in decentralized mobile network deployment. In Fig. 1 , at a certain point in time, a UE is connected to a server - current server - via PGW1 (PGW: Packet Data Network Gateway, playing the role of data anchor gateway). This PGW1 could have been selected by Mobility Management Entity (MME) based on the geographical and/or the topological distance to UE. At a later point in time, the same UE wants to connect to a different server, denoted target server. The UE has two options: 1 ) either to connect to the target server via the current gateway, PGW1 , or to establish a new PDN (Packet Data Network) connection via another PGW, exemplarily denoted PGW2 in Fig. 1.

In Fig. 1 , the numbers nearby the links represent a routing cost associated with the respective link (e.g. hop count, etc). As can be seen, the route according to option 1 (UE-PGW1 -target server) incurs a cost of 6, whereas the alternative route according to option 2 (UE-PGW2 -Target server) incurs a cost of 5. Thus, given the above, the question that has to be answered is whether the UE shall still use PGW1 , or whether it shall ask for a new PDN connection via PGW2?

In view of the above it is an objective of the present invention to improve and further develop a method and a mobile terminal of the initially described type in such a way that, by employing mechanisms that are readily to implement, the process of optimal anchor point selection is improved, both from the network perspective and from the mobile terminal's perspective.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method for supporting PDN connectivity of a mobile terminal in a mobile operator network is characterized in that the method comprises the steps of

said mobile terminal initiating a process for establishing an IP session with a target node with respect to an application, and

performing a decision process in which a suitable anchor point for establishing a PDN connection for said IP session is selected by taking into consideration at least one of application type information and E2E connection information according to configurable selection rules. Furthermore, the above mentioned objective is accomplished by a mobile terminal comprising the features of claim 21. According to this claim such a mobile terminal with PDN connectivity support is characterized in that said mobile terminal comprises means for initiating a process for establishing an IP session with a target node with respect to an application of a particular type, wherein said mobile terminal is equipped with a logic adapted to performing a decision process in which a suitable anchor point for establishing a PDN connection for said IP session is selected by taking into consideration at least one of application type information and E2E connection information according to configurable selection rules.

According to the present invention it has first been recognized that an improvement of the optimal anchor point selection process, both from a network perspective and from a mobile terminal's perspective, is achievable when, in addition to load balancing and geographical and/or topological proximity, the network takes into consideration E2E (end-to-end) connection and/or application type information within a data anchor gateway selection process. In other words, according to the present invention E2E connection and application type is reflected in anchor point selection. Regarding the latter, it is likely that certain functionalities (e.g. content caches) or services (e.g. machine-to-machine, M2M) may only be available via specific data anchor gateways (e.g., PDN GWs). Hence, the application type could enhance the anchor point selection. Also, the application type gives an indication how critical the selection of a more optimal anchor point really is. In some cases, e.g. when the load on a candidate anchor point is already above a critical threshold, it might be more advisable to leave its remaining resources to more sensitive applications, and stick to the current anchor or choose a second-best one for the session under consideration.

It is noted that in accordance with embodiments of the present invention the mobile terminal only selects the PDN connection. However, it is the network (e.g. MME) that selects the anchor point, in particular based on an APN provided by the mobile terminal when establishing a new PDN connection.

As a major advantage of the present invention, it enables mobile communications via optimal data anchor gateways. Optimality of the data anchor gateways is based on load balancing, geographical and/or topological proximity not only of the mobile node to the data anchor gateways but also vis-a-vis the whole end-to-end connection, and/or the application type. By applying such E2E connection and/or application type-oriented smart selection of data anchor gateways, efficient usage of the network resources will be achieved. Further, the present invention results in E2E route optimization along with the associated energy savings.

According to a preferred embodiment the E2E connection information may include information on the location and/or IP address of the mobile terminal as well as information on the location and/or IP address of the target server. Depending on the respective application, the IP address of the target server may be exchanged by the corresponding URL and/or FQDN (Full Qualified Domain Name). In an embodiment the mobile terminal decides according to configurable criteria whether to request a new PDN connection for establishing said IP session. The configurable criteria may take into consideration at least one of application type information and information regarding the target node's location. For instance, upon receiving the IP address of the target server, the mobile terminal may run a logic that decides whether the mobile terminal should consult MME, DNS, ANDSF (Access Network Discovery and Selection Function) or any other relevant node in the mobile core network for a new PDN connection to establish the new IP session with the target node. Triggers for this logic could be, e.g., the range of the target node's IP address, content size, application/service type (e.g., video), application running time/service duration, location and/or time difference (compared to the currently existing PDN connection set), etc.

The application type itself could be represented in multiple ways, for example, but not limited to any of MIME (Multipurpose Internet Mail Extensions) type, server URL and/or domain name, and/or a target node's IP/network address and/or transport protocol type and ports, or even an application ID as currently being discussed and defined in the ongoing 3GPP Work Item on "Data Identification in Access Network Discovery and Selection Function (ANDSF)" (DIDA) [3GPP TR 23.855]. The important issue here is that the application type must reveal enough information for the anchor point selection process. For example, a target server domain name such as 'facebook.com' does not say much about the requested content, as Facebook hosts many media types. On the other hand, a MIME type such as application/video does not allow to judge whether the requested video will be cached in the operator network or not, i.e. whether an anchor point with cache support is preferable or not.

Embodiments of the present invention can benefit from the outcome of the DIDA WID and other relevant work attempting to define unique identifiers for known and widely used applications. A mobile terminal can be pre-configured with a list of such application names mapped to unique application IDs. This list could be regularly updated by the network via one or more suitable nodes such as ANDSF. As explained below, when a UE attempts launching an application, it sends the application ID to DNS, MME or ANDSF to get instructions on whether a new/optimal PDN connectivity shall be established to accommodate the traffic of the application.

Advantageously, in case the mobile terminal decides to request a new PDN connection for establishing the IP session, it transmits at least one of application type information and E2E connection information, in particular the target node's IP address, towards the mobile core network, in particular to a mobility management entity MME. According to a preferred embodiment the mobile core network, in particular a mobility management entity MME, may indicate information on the location of the target node, application type information and/or information on anchor points currently used by the mobile terminal within an APN query sent to a DNS server. In turn, an entity within the mobile core network, in particular a DNS server, MME or ANDSF determines an optimal APN or anchor point for the mobile terminal according to configurable criteria based on information received within the APN query or within a PDN connection request.

Advantageously, the DNS reply's TTL value is chosen to be smaller than a configurable threshold value. This proves to be beneficial since the higher a TTL value the higher is the chance that the mobile terminal is not triggered to query the DNS server (since previously resolved server names are still available in the mobile terminal's local DNS cache) and no new anchor point would be selected even though a better one might be available. According to an embodiment an optimal APN or anchor point determined by an entity within the mobile core network, in particular a DNS server, may be reported to the mobile terminal or to MME within a DNS reply message. Alternatively, a list of suitable anchor points determined by an entity within the mobile core network, in particular a DNS server, may be reported to the mobile terminal within a DNS reply message, wherein the suitable anchor points are ranked according to a predefined intelligent ranking scheme (considering, for instance, load information, etc.). Based on the list, the DNS, MME, ANDSF, or any external functions at other dedicated nodes to be interrogated by the DNS, MME or ANDSF may decide the optimal anchor point for the mobile terminal based on the IP address/location of the mobile terminal, the IP address/FQDN/location of the target node, application/MIME/service type/ID (e.g., video applications could be handled by anchor points, i.e. PGWs, with cache support), task type (e.g., in case of MTC (Machine Type Communications), emergency warning, delay tolerant measurement), user class (i.e. user can be the mobile user or the owner/operator of the target node such as MTC server), and/or the mobile node's "home zone".

The mobile core network, in case it decides that an existing PDN connection of the mobile terminal can suitably be used for establishing the IP session with the target node, may reject any PDN connectivity request initiated by the mobile terminal. More specifically, the mobile core network may send a Request Reject message in response to a mobile terminal-initiated PDN connectivity request specifying the cause and indicating to the mobile terminal to establish the IP session to the target node via the current data anchor gateway.

Advantageously, in order to simplify the required signaling messages the DNS servers and/or ANDSFs provided in the mobile core network are configured to find out from the mobile terminal's IP address the current location of the mobile terminal and/or the anchor point currently being used by the mobile terminal. Furthermore, DNS servers and/or ANDSFs provided in the mobile core network may be equipped with some intelligence adapted to infer the application type/ID from well-known domain names, URLs, e.g., video for www.youtube.com, IP subnetwork and/or transport protocol/ports. As mentioned already above, a DNS server may indicate to the mobile terminal in the DNS reply message to establish the IP session with the target node via another anchor point than the anchor point currently being used by said mobile terminal. To this end, the DNS server may insert a FLAG or the APN via which a more optimal anchor point can be reached in the DNS reply.

In reaction to such a DNS reply, the mobile terminal may ignore and dismiss the indication in case of conflicting information from the application layer. For instance, the application layer could indicate that the IP session is going to be short. In such case, the mobile terminal may "overrule" the proposal from the mobile core network and may continue to use the existing PDN connection also for the establishment of the IP session with the target server. According to a preferred embodiment of the mobile terminal may be provided a priori with operator policies that it refers to in order to decide, which APN to use for PDN connectivity to access a specific range of IP servers, to launch a particular application type, and/or to carry out a specific task. There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the patent claims subordinate to patent claims 1 and 21 on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing

Fig. 1 is a schematic view of a mobile operator network illustrating the problem underlying the present invention,

Fig. 2 is a diagram showing the message exchange flow of an anchor point selection process in accordance with an embodiment of the present invention, Fig. 3 is a flow diagram of a logic run by the mobile terminal for deciding on the issuance of a new PDN connection request in accordance with an embodiment of the present invention,

Fig. 4 is a diagram showing the message exchange flow of an anchor point selection process in accordance with a further embodiment of the present invention, and Fig. 5 is a diagram showing the message exchange flow of an anchor point selection process in accordance with a still further embodiment of the present invention.

Generally, the embodiments of the present invention described hereinafter in connection with Figs. 2-5 are based on two main assumptions. First, it is assumed that the mobile operator network is decentralized, i.e., data anchor gateways (such as Packet Data Network - PDN GW in case of the Evolved Packet System (EPS)) are not placed in the same geographical location in a centralized fashion, but rather distributed over the mobile network coverage. In the second assumption, it is assumed that mobile terminals are capable of establishing multiple connections via different data anchor gateways, i.e., mobile terminals supporting multiple access point names (APNs) in 3GPP networks, and that is via the same or different wireless access technologies.

It is again noted that while the following embodiments are based on LTE and the Evolved Packet System (EPS), the concept of the present invention can be equally applied to other 3GPP's mobile networks such as the General Packet Radio Service (GPRS). Thus, the described embodiments are in no way intended to limit the present invention to any specific network technology.

Furthermore, it is noted that the embodiments of the present invention described hereinafter in connection with Figs. 2-5 are related to the scenario as described in connection with Fig. 1 , i.e. it is assumed that a UE is already having at least one existing connection via a particular PGW. However, as will be easily appreciated by a person skilled in the art, the described scenarios could easily apply to the case when a UE wants to attach to the network initially and get its first PDN connection.

According to a first embodiment of the present invention, illustrated in Fig. 2, UE 1 has an ongoing PDN connection via current PGW1 . At a later instance, UE 1 wants to connect to a target server 2 identified with a URL, which is assumed to be www.server.com, and an IP address, which is assumed to be IP@. A different PGW, PGW2, is assumed to be optimal for establishing the connection between the UE 1 and the target server 2.

In a first step, UE 1 sends a query to a name resolution server indicating the target server's 2 URL. For the sake of explanations, as a name resolution server, a DNS server 3 is assumed in the present as well as in the following embodiments. In response, the name resolution (i.e. DNS) server 3 provides the IP address of the target server 2, i.e. IP@. Upon receiving the IP address of the new target server 2, the UE 1 runs a logic that decides whether the UE 1 should consult the Mobility Management Entity MME 4 for a new PDN connection to establish the new IP session to the target server 2. In Fig. 1 , this logic is indicated by Circle 1 . Triggers for this logic could be based on the range of the target server's 2 IP address, on content size, on the application type (e.g., video, email, audio, etc), on a location and/or time difference compared to the existing PDN connection(s), etc. Fig. 3 illustrates an embodiment of such logic that is run by the UE 1 in order to decide whether or not to request a new PDN connection. According to this embodiment, in a first step the UE checks the instant of time of the last PDN connection request. In case the last PDN connection request was made less than a configurable period of time ago, the UE does not request a new PDN connection. Otherwise, the UE continues by checking the application type. If the application type fulfills certain criteria, i.e. if the application is of type a-i , a₂, a_n, the UE continues by checking whether a common prefix of the IP address of the target server and a reference IP address (named ReferenceJP), which refers to the UE's own IP address, is smaller than a given threshold n. I.e., the "ReferenceJP" is an IP address that is taken to measure the proximity of the target server's IP address to some reference in order to decide whether they are sufficiently different for a new PDN connection to make sense. If the application type does not fulfill certain criteria, i.e. if the application is not of type a-i , a₂, a_n, the UE continues by checking whether the IP address of the target server is part of certain subnets. If so, the UE requests a new PDN connection, otherwise it does not. In the present embodiment, the variables "x", "a_x", "subnet/, "n", and "ReferenceJP" are configurable.

Turning back to Fig. 2, if the UE 1 decides to ask for a new PDN connection, it issues the "UE-initiated PDN connectivity Request" to the MME 4 as part of the "UE-requested PDN connectivity" procedure of 3GPP TS 23.401. In addition to the APN (Access Point Name), which is indicated in the PDN connectivity request according to the above standard, the UE 1 indicates the IP address of the target server 2 and/or the application type/ID to MME 4. Modified information elements according to the embodiment of the present invention of Fig. 2, the additional new values/fields IP@ and application type are marked in bold, italic and underlined in Fig. 2. Instead of sending the target server's 2 IP address, the UE 1 could also send the URL, Fully Qualified Domain Name (FQDN), or any other known identifier of the target server 2 to the MME 4.

In return, MME 4 sends an APN query to DNS server 3 indicating the APN (like in the above standard) and (in addition according to the present embodiment) IP@ of the target server 2, optionally PGW1 - the current PGW (or list of PGWs) the UE 1 is connected to - and/or application type. Upon receiving the APN query, the DNS server 3 acquires a logic, indicated by Circle 2, to decide an optimal anchor point based on UE location, target server location, and/or application type. For instance, according to the logic it could be provided that, e.g., video applications are handled by PGWs with cache support. If the retrieved optimal anchor point is different than PGW1 , the DNS server 3 inserts the new PGW, PGW2 in the present case, in the DNS reply and sends it to MME 4. The MME 4 uses this information and establishes for the UE 1 the PDN connection to PGW2. The procedure terminates with a request accept message as in the usual UE- requested PDN connectivity procedure (TS 23.401 , section 5.10.2). Alternatively, in response to an APN query from the MME 4 as described above, the DNS server 3 may suggest a list of anchor points (different than the current PGW1 ) ranked in order of preferences following a certain intelligent ranking scheme. This ranking method could be determined by the DNS server 3 itself or could be explicitly requested/specified by the MME 4 . In turn, the MME 4 follows the ordered list of suggested PGWs to select the optimal PGW for the requesting UE 1. The following gives an example of a suitable logic in Circle 2 in terms of pseudocode where the "importance threshold I" can be configured and the chosen routing metric is hop count. anchor := current_anchor;

minimum :=∞;

for all available anchor gateways do

if candidate is suitable for given application_type and

importance (application_type) > I

he := hop_count(UE, candidate) + hop_count(candidate, target_server);

if he < minimum

minimum := he;

anchor := candidate;

return anchor;

Consequently, in accordance with the above pseudo-code, in a first step the DNS server 3 determines all available anchor points. Then, the DNS server 3 preselects those anchor points that are suitable for a given application type. For instance, in case of a video application only those anchor points comprising content cache functionality may be preselected as suitable candidates. However, this preselection is only performed in case the "importance" of the application type exceeds a predefined threshold. In this regard, the term "importance" may refer to, e.g., certain QoS or priority requirements of the application. If, on the other hand, the applications type is below the importance threshold since, for example, the application is uncritical in terms of the above requirements (e.g. in case of e-mail applications) no preselection is performed and all available anchor points are regarded as potential candidate anchor points. Additionally or alternatively to the "importance" parameter described above, another kind of "importance" threshold related to the load of a data anchor gateway may be considered in the context of the anchor point preselection process. According to this embodiment, if the load of a particular data anchor gateway is above a configurable threshold, this gateway will not be preselected as suitable candidate.

According to the above embodiments, based on the available and, as the case may be, preselected candidate anchor points the minimum distance from the UE 1 via the respective anchor point to the target server 2 is determined in terms of hop counts. As will be appreciated by those skilled in the art, other routing metrics can be deployed likewise. In the last step, the candidate anchor point having the minimum distance is selected as anchor point for the PDN connection from the UE 1 to the target server 2. One aspect to consider here regards the DNS reply's time-to-live (TTL) value. Obviously, the UE 1 would normally not bother querying a DNS server 3 if a specific server name has been resolved previously and an entry is still available in the UE's 1 local DNS cache. This could lead to the fact that the mechanism described above would not be triggered and no new anchor point could be selected even though a better one might be available. To avoid this and allow for some dynamicity (e.g. known server with new application type, or changed UE location due to mobility), the DNS reply's TTL value should be reasonable small, probably in the order of minutes. Another aspect to note here is that the way the above embodiment makes use of DNS is different from other "location-based" DNS resolution mechanisms as used, e.g. in CDNs like the Akamai solution. While Akamai will also dynamically resolve a server name to varying IP addresses based on the location of source and target host, the proposition according to the above embodiment does not actually resolve an end host at all. Rather, it asks for the IP address of an intermediate gateway (i.e., PDN Gateway), that is best positioned between source and target host. Hence, whereas Akamai determines a suitable target host, given a source host, according to the above embodiment a suitable intermediate anchor point/gateway is determined, given both a source and a target host (and an application type, which Akamai does not use at all).

Further, it is important to note that even the current standard DNS specification has the notion of "services" or applications and allows to find servers that provide a certain service (e.g. email, LDAP, etc.). In DNS, this is stored in the MX or SRV resource record type. However, according to the present invention, the application type is used in a much broader way. It can be used to determine anchor points providing certain functionality (e.g. M2M services, or cache access), but it could also be used, for instance, to assess the importance of optimal anchor point selection as discussed above. The latter use case is certainly completely orthogonal to the current DNS usage.

Fig. 4 illustrates the flow of main messages according to another embodiment of the present invention. The embodiment shown in Fig. 4 resembles the embodiment described in connection with Fig. 2 up to the point where the MME 4 sends the APN query to DNS server 3. Therefore, in order to avoid repetitions, the respective description is omitted here. In contrast to the embodiment of Fig. 2, in the APN query of the present embodiment, the MME 4 indicates only the APN. In response the DNS seven 3 replies with a list of appropriate PGWs that are ranked, e.g., based on load information. Obviously, if the MME 4 is preconfigured with a list of suitable PGWs for each APN or maintains a cache of previous APN query resolutions, the DNS query could be omitted at this point. The MME 4 then runs a logic to decide the optimal anchor point from the list of PGWs based on UE location, target server location, and/or application type (e.g., video applications could be handled by PGWs with cache support).

In the embodiments of Figs. 2 and 4, if the network decides that the PGW does not need to change, the network, namely MME 4, sends a Request Reject message in response to the UE-initiated PDN connectivity request to indicate to the UE 1 to establish the IP session to the target server 2 via the current PGW.

Obviously, the selection of an optimal anchor point (i.e. the logic represented by Circle 2 in Figs. 2 and 4) can take into consideration and balance various further parameters, in addition to the application type and topological distance, as described above in connection with Fig. 3. Ideally, the MME 4 (in the variant of Fig. 4) has acquired information about the different candidate anchor points' current load situation. In that case, as mentioned earlier, based on the provided application type it might decide to not select the most optimal candidate, if the latter's load has exceeded a certain threshold and is to be kept free for applications of more critical application types.

On the other hand, the MME 4 might still select a loaded anchor point, if there is a strong likelihood that additional sessions from the same UE requiring the same anchor point will follow in the future. This could be the case, for example, when a UE initially connects to a roaming partner's PLMN (e.g. in a different country) with a visited PLMN's PGW (i.e., local breakout scenario). In this situation, it is very likely that multiple future sessions will be targeted for the UE's home country, for which a different PGW, e.g. a home PLMN PGW, will be the better choice. Essentially, the notion of a "home zone" of a UE could also directly assist in the decision whether the UE's anchor point will be in the visited or home PLMN instead of configuring this statically based on the APN only. The "home zone" of a UE could be specified as an IP address range, a PLMN ID, etc.

Fig. 5 illustrates the flow of main messages according to still another embodiment of the present invention. In this embodiment, the UE 1 makes a DNS query indicating the URL of the target server. In the query, the UE 1 may also include the current location (e.g. PGW1 ), and/or the application type (e.g. in form of an application ID), and/or its "home zone". This implies adequate modifications at the DNS implementation at UEs, and intuitively at DNS, which is not compliant with the current specifications of the DNS protocol. Regarding the UE location, however, it is to be noted that the DNS 3 may also find out from the IP address of the UE 1 its current location (i.e. PGW1 ). Regarding the application type, the DNS may be equipped with some intelligence that can infer the application type/ID from well-known URLs (e.g., video for www.youtube.com).

As in the embodiment described in connection with Figs. 2 and 4, DNS server 3 is assumed to a have the logic - indicated by Circle 1 in Fig. 5 - to decide what data anchor gateway is optimal for the UE 1 based on the UE location, the target server's 2 IP address, and the application/service type (i.e., if known to DNS). If the DNS server 3 - or an external function, e.g. ANDSF (Access Network Discovery and Selection Function), which has implemented the logic and which performs the anchor point selection process and provides the result to the DNS 3 - judges that the current PGW needs to be changed (e.g. because there is a closer PGW for the UE 1 or a better PGW in terms of accessing the service), the DNS server 3 inserts a FLAG or the APN (via which the determined optimal PGW can be reached) in its reply. It shall be noted that in current DNS specifications, there are optional fields in the DNS reply messages that can be used for carrying such flag or APN.

The UE 1 receives FLAG (or APN) as an indication to ask for a new PGW for the specific connection to be established with target server 2. Still UE 1 can dismiss this operation if the application layer indicates otherwise, e.g., if the session is going to be short. If, however, UE 1 decides to establish a new PDN connection for the new IP session - the respective logic being indicated by Circle 2 in Fig. 5 - it issues a normal PDN connectivity request indicating the APN received from the DNS server 3 or any of the other solution variants described above. As mentioned earlier, the DNS reply's TTL value needs to be chosen carefully so that a long- lasting cache entry does not lead to the UE 1 accessing stale information which is not optimal for the current (changed) request.

Another variant to the above mentioned solutions would be by having UE 1 querying directly the ANDSF for an appropriate APN (e.g., after resolving the domain name). Following the same logic of Circle 1 at the UE 1 in Fig. 2, whenever the UE 1 sees the need for establishing a new PDN connectivity for launching a particular application, it sends a query to the ANDSF indicating the PGWs/APNs currently used by the UE 1 , the application type/ID and/or the URL/FQDN/IP address of the target server 3. The ANDSF then runs a logic similar to that of Circle 2 in Fig. 2 to sort out an adequate PGW/APN, which is communicated to the UE 1. If the ANDSF proposes a new APN/PGW different from the APNs/PGWs currently used by the UE 1 , the UE 1 requests MME 4 to establish a new PDN connectivity specifying the APN recommended by the ANDSF. As in the OPIIS (Operator Policies for IP Interface Selection) WID (3GPP TR 23.853), ANDSF could also provide a priori (and optionally on a regular basis) some operator policies that indicate to the UE 1 which APN to use for PDN connectivity to a specific range of IP servers and/or application IDs/types.

Generally it should be noted that in all embodiments described above, the logic for selecting an optimal data anchor gateway can be part of the DNS, MME or ANDSF, or it can be implemented with a dedicated and external function that the MME, DNS, or ANDSF can interrogate.

Finally, it shall be mentioned that the solutions and embodiments described above can also be applied for the case of Machine Type Communications (MTC), particularly in case of Mobile Originated communications. Indeed, in case an MTC device needs to communicate to an MTC server or a group of MTC servers, the MTC device may interrogate the DNS, ANDSF, or MME (as in the above embodiments) for the best P-GW (or best MTC Interworking Function MTC-IWF as in TR 23.888) to connect to for communicating to a specific MTC server (or one MTC server out of a set of MTC servers administrated by a particular MTC user). In the interrogation message, the MTC device may indicate the MTC user class (e.g., Golden customer), the MTC operation/task type (e.g., emergency warning or delay tolerant measurement), the MTC server location, the MTC device location, and/or other MTC-related information. The node that receives the interrogation message (i.e., DNS, ANDSF, MME or the like) runs a logic similar to the one described in connection with Circle 2 in Fig. 2 to sort out the adequate APN/PGW.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for supporting PDN (Packet Data Network) connectivity of a mobile terminal (1 ) in a mobile operator network, wherein said mobile terminal (1 ) is capable of establishing PDN connections via different anchor points in the core network,

c h a r a c t e r i z e d i n that the method comprises the steps of

said mobile terminal (1 ) initiating a process for establishing an IP session with a target node (2) with respect to an application, and

performing a decision process in which a suitable anchor point for establishing a PDN connection for said IP session is selected by taking into consideration at least one of application type information and E2E connection information according to configurable selection rules.

2. Method according to claim 1 , wherein said E2E connection information include information on the location and/or IP address of said mobile terminal (1 ) as well as information on the location and/or IP address of said target node (2).

3. Method according to claim 1 or 2, wherein said mobile terminal (1) decides according to configurable criteria whether to request a new PDN connection for establishing said IP session.

4. Method according to claim 3, wherein said configurable criteria take into consideration at least one of application type information and information regarding said target node's (2) location.

5. Method according to any of claims 1 to 4, wherein the application type is indicated by corresponding MIME type information, by a server URL and/or a domain name, and/or said target node's IP/network address and/or transport protocol type and ports.

6. Method according to any of claims 1 to 5, wherein the application type is indicated by an application identifier.

7. Method according to any of claims 1 to 6, wherein said mobile terminal (1 ) is pre-configured with a list of applications mapped to unique application identifiers.

8. Method according to any of claims 1 to 7, wherein said mobile terminal (1 ), in case it decides to request a new PDN connection for establishing said IP session, transmits at least one of application type information and E2E connection information, in particular said target node's (2) IP address, towards said core network, in particular to a mobility management entity MME (4).

9. Method according to any of claims 1 to 8, wherein the core network, in particular a mobility management entity MME (4), indicates information on the location of said target node (2), application type information and/or information on anchor points currently used by said mobile terminal (1 ) within an APN query sent to a DNS server (3).

10. Method according to any of claims 1 to 9, wherein an entity within said core network, in particular a DNS server (3), MME (4) or ANDSF determines an optimal APN or anchor point for said mobile terminal (1 ) according to configurable criteria based on information received within an APN query or a PDN connection request.

1 1. Method according to any of claims 1 to 10, wherein DNS reply's TTL value is chosen to be smaller than a configurable threshold value.

12. Method according to any of claims 1 to 1 1 , wherein an optimal APN or anchor point determined by an entity within said core network, in particular a DNS server (3), is reported to said mobile terminal (1 ) or to said MME (4) within a DNS reply message.

13. Method according to any of claims 1 to 12, wherein a list of suitable APNs or anchor points determined by an entity within said core network, in particular a DNS server (3), is reported to said mobile terminal (1 ) or to said MME (4) within a DNS reply message, wherein said suitable APNs or anchor points are ranked according to a predefined ranking scheme.

14. Method according to any of claims 1 to 13, wherein said core network, in case it decides that an existing PDN connection of said mobile terminal (1 ) can suitably be used for establishing said IP session, rejects PDN connectivity requests initiated by said mobile terminal (1 ).

15. Method according to any of claims 1 to 14, wherein a DNS server (3) and/or a ANDSF are configured to find out from said mobile terminal's (1 ) IP address the current location of said mobile terminal (1 ) and/or the anchor point currently being used by said mobile terminal (1 ).

16. Method according to any of claims 1 to 15, wherein a DNS server (3) and/or an ANDSF are equipped with some intelligence adapted to infer the application type/ID from well-known domain names, URLs, IP sub-netowrk and/or transport protocols/ports.

17. Method according to any of claims 1 to 16, wherein a DNS server (3) indicates to said mobile terminal (1 ) in the DNS reply message to establish said IP session with said target node (2) via another anchor point than the anchor point currently being used by said mobile terminal (1 ).

18. Method according to claim 17, wherein said indication is performed by insertion of a FLAG or the APN via which a more optimal anchor point can be reached in the DNS reply.

19. Method according to claim 17 or 18, wherein said mobile terminal (1) ignores said indication in case of conflicting information from the application layer.

20. Method according to any of claims 1 to 19, wherein said mobile terminal (1 ) is provided a priori with operator policies that it refers to in order to decide, which

APN to use for PDN connectivity to access a specific range of IP servers or IP sub-network for a particular application type, and/or to carry out a specific task.

21. Mobile terminal with PDN (Packet Data Network) connectivity support, in particular for executing a method according any of claims 1 to 20, wherein said mobile terminal (1 ) is capable of establishing PDN connections via different anchor points in the core network,

c h a r a c t e r i z e d i n that said mobile terminal (1 ) comprises means for initiating a process for establishing an IP session with a target node (2) with respect to an application of a particular type, wherein said mobile terminal (1 ) is equipped with a logic adapted to performing a decision process in which a suitable anchor point for establishing a PDN connection for said IP session is selected by taking into consideration at least one of application type information and E2E connection information according to configurable selection rules.