WO2005122617A1

WO2005122617A1 - Apparatuses and method to provide a network-requested pdp context activation procedure

Info

Publication number: WO2005122617A1
Application number: PCT/EP2004/006146
Authority: WO
Inventors: Angel Boveda De Miguel
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2004-06-08
Filing date: 2004-06-08
Publication date: 2005-12-22

Abstract

Apparatuses (130, 140, 110, 120) for providing a Network Requested PDP Context Activation procedure. A location server (130) comprises a PDP context activation controller component (131) which is arranged to receive (303, 308) an event notification of incoming data for a user. The PDP context activation controller component (131) in the HLR obtains from a user location storage (133) an identifier of the SGSN (140) which is serving access to the mobile terminal of the concerned user, and sends (304) to said SGSN a request to start a PDP Context for said terminal. The event notification of incoming data can be sent from a server which provides an interface function between a GPRS network (100) and a packet data network (200), such as a domain name server (110) or a proxy server (120), which comprise mediation components (111, 121) arranged to communicate (303, 308) with a location server; or be sent directly from an application server (201,202).

Description

APPARATUSES AND METHOD TO PROVIDE A NETWORK- REQUESTED PDP CONTEXT ACTIVATION PROCEDURE

FIELD OF THE INVENTION

[0001] The present invention relates to mobile communications networks providing data packet services and, more precisely, to the apparatuses involved in said provision.

BACKGROUND

[0002] The General Packet Radio Service (GPRS) is a well- known data packet bearer service commonly provided by PL N (Public Land Mobile Network) operators to their subscribers. GPRS allows a user who has a subscription with a PLMN operator to access from his mobile terminal (MT hereinafter) to data services provided by application serving entities that reside in packet data networks, such as the Internet, a private intranet, a service data network of a PLMN, etc. The kind and specific characteristics of said application serving entities can vary largely and depend basically on the nature of the data services they provide (e.g. weather information, travel book services, links to information services provided by other server entity, network access control in a Internet Service Provider ISP, etc) . Since the specific characteristics of said application serving entities are not relevant for the present invention, the generic term "application servers", ASs, shall be used hereinafter to refer to them.

[0003] The specific network infrastructure for providing

GPRS based services is common for mobile networks; i.e., telecommunications networks implementing mobile communications systems such as GSM (Global System for

Mobile communications) or UMTS (Universal Mobile

Telecommunications System) . In a mobile system, a GPRS enabling infrastructure (i.e. a GPRS network) is accomplished, among other modifications, by the introduction of ^• two kind of specialized server entities

(also known as GPRS core network nodes) in cooperation with some of the existing infrastructure of said system. These specialized nodes are named: Serving GPRS Support Node SGSN, and Gateway GPRS Support Node GGSN, and they form a common packet domain network infrastructure used in a 2^nd generation GSM system providing GRPS and also in a 3^rd generation mobile system, such as UMTS.

[0004] In short, a SGSN is the server entitled to serve access to a mobile terminal MT to the GPRS network (i.e. to serve GPRS access); it keeps track of its location and also performs security and access control functions. A SGSN is connected to the radio access network and also to one or more GGSNs through the communication infrastructure of a PLMN operator. A SGSN also communicates with a HLR (Home Location Register) to, among other purposes, update location information of a MT of a user. In turn, a GGSN is a server that provides interworking between a GPRS network and packet data networks where the ASs reside. A given GGSN is referenced by one (or more) "Access Point Name(s)" APN; wherein an APN is an identifier which comprises a network identifier which defines a packet data network said GGSN is connected, and can also comprise a PLMN identifier of the network operator said SGSN belongs to. To offer GPRS, a given PLMN operator can have a GPRS network comprising one or more SGSNs and one or more GGSNs; wherein, according to some particular implementations, both kinds of servers can be co-located within the same apparatus. [0005] It shall be noticed here that the term "HLR" is commonly used to refer to a location server which, in a mobile network, stores subscription data and location information about (all/some) users of said system, regardless whether said system provides GRPS or not. For example, for a user attached to a 2^nd generation GSM system providing GRPS, a HLR stores, as location information, information about the SGSN serving GRPS access to said user. Other terms are also used to refer to this kind of server entity; for example, in a UMTS system having an IMS (Internet Protocol IP Multimedia Subsystem) , the term "HSS" (Home Subscriber Server) is used to refer to the same kind of server. In particular, a HLR server adapted to serve as location server for basic voice service users as well as for GPRS users, may be further enhanced to serve IMS users as HSS. Accordingly, the generic term "location server" shall be used across this application, in addition to the term "HLR", to refer to a server in a mobile network that, among other functions it might have, is the master storage place storing location information of all, or a plurality, of the users of a said system.

[0006] Roaming between different PLMN operators has been also meant for GPRS; thus, in practical terms, it can be considered that, for a given GPRS user having a subscription with a PLMN operator, a GPRS network comprises the GPRS (sub) network of his PLMN (home-PLMN) , as well as all the GPRS (sub) networks of the other PLMN (visited-PLMN) operators his PLMN has a roaming agreement with. In order to allow roaming of a GPRS users across different PLMN operators, a SGSN of a PLMN operator can communicate with a location server of another PLMN operator, and with a GGSN of said another operator. For example, if a GPRS user having a subscription with a PLMN (i.e. his home-PLMN) roams into a geographical area controlled by another PLMN (i.e. a visited-PLMN) then, the SGSN in the visited-PLMN which is serving GPRS access to the MT of this user can communicate with a HLR in the home-PLMN (i.e. with the location server of this user on his home network) to update location information of this user.

[0007] In order to use GPRS services, a MT shall first make its presence known to the network by performing a GPRS attach. Once attached, in order to send and receive packet data by means of GPRS services , the MT shall activate the so called "PDP context" (Packet Data Protocol context) that it wants to use. In short, a PDP context provides a PDP address (a network address such as an Internet Protocol IP address, an X.121 address, etc) to allow an MT to communicate with a AS in a packet data network, as well as the necessary data in the corresponding SGSN and GGSN serving said PDP context to allow the routing of data information to and from said MT. Although a given MT can be assigned permanently to a particular PDP address (e.g. an IP address) , a PDP addresses uses to be dynamically assigned to a MT only when a PDP context is activated. Once a MT has activated a PDP context, this MT gets a virtual path through the GPRS network with the GGSN selected for said PDP context, and, from said GGSN to a packet data network; thus, the MT can communicate with a AS connected to said packet data network through said GGSN.

[0008] Two ways to activate a PDP context can be initiated according to 3GPP Specification for GPRS 23.060 v6.2.0 (Sep-2003); the first one is initiated by a GPRS attached MT, and the second one, known as "Network-Requested PDP Context Activation" NRPCA, is initiated by the GPRS network. The purpose of NRPCA is to reach a MT which is attached to GPRS but does not have a PDP context activated yet . [0009] In particular, a Network-Requested PDP Context Activation procedure NRPCA is started by a GGSN which receives from a AS a data message for a user, or which receives an event notification of incoming data for a user (e.g. from a proxy server interposed between the GPRS network of a PLMN operator, or from a domain name server which receives an address query from an AS). Fig.l, which has been taken from the aforementioned 3GPP Specification 23.060, illustrates a NRPCA procedure started at reception of a data message (e.g. an IP data packet) in a GGSN (flow I) to be delivered to the MT of a user. Next (flows II) , the GGSN uses the IMSI (International Mobile Subscriber Identifier) of said user to communicate with his HLR to obtain location information about the SGSN which is serving GPRS access to a MT of said user. Once obtained, the GGSN communicates (flows III) with said SGSN to confirm that a PDP context shall be started for said MT. Subsequently (flow IV) , the SGSN starts a PDP context activation by sending a request for PDP context activation to the MT. The subsequent signaling flows for completing the PDP context activation (shown as collapsed in flow V) take place between said MT, said SGSN and said GGSN as when the PDP context is requested primarily from the MT. A further flow

(not shown in Fig.l) is the sending of the received data message from the GGSN to the MT.

[00010] It shall be noticed that the GGSN which triggers the NRPCA procedure is within the home-PLMN of the served user, being this due to certain reasons, some of which shall now be commented. Firstly, in order to query to the HLR of a served user, a GGSN has to know the IMSI of said user. Thus, a GGSN has to know the IMSI of a user even when no PDP context is activated through it for a MT of said user; being this only possible when, for example, due to a particular subscription category of a user on his home- PLMN, his MT gets always assigned to a static PDP address in a particular GGSN of said home-PLMN. On the other hand, an AS wanting to send some data to the MT of a GPRS user is usually unaware about details of the physical location said MT; in other words, it has no knowledge of a routable network address for communicating with said MT (e.g a network address, such as an IP address, which maps into the GGSN serving a PDP context for said MT) unless it has activated a data session with said MT. Besides, it could happen that a previously used address is no longer valid to communicate with said user (e.g. dynamic PDP addresses are applied in the GPRS network) ; or even that the data message that the AS wants to sends can be contained in a single data packet (e.g. an IP packet), and thus, the AS would need to know just an address of an entry point for the GPRS network. So, the only element that an AS commonly has about a given user is an identifier of said user usable to identify him on his home-PLMN (e.g. a Mobile Subscriber ISDN Number MSISDN, a Uniform Resource Identifier URI, etc) .

[00011] However, in roaming situations, the use of a GGSN in the home-PLMN can cause unnecessary long transmission paths between the SGSN serving GPRS access for the concerned user in the visited-PLMN and a GGSN selected in the home-PLMN. For example, since some implementations regard a co-location within the same physical apparatus of a SGSN and a GGSN, it can imply a waste of transmission resources to select another distant GGSN. These long transmission paths can be of a particular relevance in situations where the visited-PLMN and the home-PLMN are in distant geographical locations (e.g. they operate in different countries) and, for example, the AS which causes the triggering of the NRPCA is specialized in providing local information concerning the visited country; and thus, likely to be physically close to the GPRS infrastructure of the visited-PLMN. In this case, the transmission path will go from the AS (e.g. in country "A") to the GGSN of the home-PLMN (e.g. in country "B"), and then back to the visited SGSN (e.g. in country "A"). On the other hand, if the PDP context activation is started by a MT roaming in a visited-PLMN, a GGSN can (e.g. depending on APN/GGSN selection policies) be selected in the visited-PLMN by the SGSN serving said user in said visited-PLMN; however, this advantageous feature is lost if, according to the known art, a GGSN is selected in the home-PLMN to serve always a Network-Requested PDP context.

[0010] The current approach for NRPCA requires the implementation of a SS#7 (Signaling System Number 7) communication stack in GGSNs; being this due to the fact that a GGSN has to implement the so called "Gc" interface with a location server (HLR) in order to query it for obtaining location information (the Mobile Application Part MAP operation "SendRoutinglnformation_For_GPRS" is used for querying to the HLR of a user with this purpose) . However, the higher is the number of the signaling interfaces and protocol stacks held in a given server (such as a GGSN) , the more complex become its operation, its maintenance, and, commonly, the more expensive becomes it. [0011] It is therefore an object of the present invention to provide the means for starting a Network-Requested PDP Context Activation procedure NRPCA in an alternative manner which alleviates some of the aforementioned disadvantages .

SUMMARY OF THE INVENTION [0012] The aforementioned object is achieved by a location server as claimed in claim 1 in cooperation with a serving GPRS support node as claimed in claim 9 and in cooperation with, either or both: a domain name server as claimed in claim 12, or a proxy server as claimed in claim 15. The aforementioned object is also achieved by a method as claimed in claim 18. Embodiments of the invention are set out in the dependent claims .

[0013] In one aspect, the invention relates to a location server which stores subscription data of a GPRS user. The location server comprises: means to store in relationship an identifier of the user and an identifier of a SGSN serving GPRS access to a mobile terminal of said user; means to receive an event notification of incoming data, said event notification comprising an identifier of said user; and means to send to said SGSN a request to start a PDP context activation for said mobile terminal at reception of the event notification, said request comprising an identifier of said user in said SGSN.

[0014] According to an embodiment, the location server further comprises means to translate a first identifier of a user received in said event notification of incoming data, into a second identifier of said user stored in said location server.

[0015] According to another embodiment, the location server further comprises means to select an Access Point Name APN which is usable to select a GGSN for said PDP context, and wherein the request to start a PDP context activation that is sent from the location server to the SGSN, further comprises said Access Point Name.

[0016] According to further embodiments, the location server further comprises: means to receive from said SGSN a response to said request to start a PDP context activation, which comprises a PDP address for the activated PDP context, means to send a response to said event notification, which comprises said PDP address, and means to store said PDP address in relationship with an identifier of said user; wherein said means to store said PDP address can be checked at reception in said location server of an event notification of incoming data, so as to send back a response to said notification comprising a stored PDP address for an active PDP context for the concerned user.

[0017] In another aspect, the invention relates to a SGSN for serving GPRS access to a mobile terminal of a GPRS user. The SGSN comprises: means to receive a request to start a PDP context activation from a location server, said request comprising an identifier of said user; and means to start a PDP context activation for said mobile terminal at reception of said request.

[0018] According to an embodiment, the request received from the location server further comprises an Access Point Name APN, and the SGSN further comprises means to select a GGSN for serving said PDP context according to said Access Point Name.

[0019] According to a further embodiment, the SGSN further comprises means send a response to said request from said location server which comprises a PDP address for the activated PDP context .

[0020] In another aspect, the invention relates to a domain name server that provides an interface between a GPRS network and application servers in a packet data network for providing a name-to-address translation function to obtain an address usable to route a data message to the mobile terminal of a GPRS user. The domain name server comprises: means to receive an address query originated from an application server, said query comprising an identifier of a user of said GPRS network; and means to send an answer to said address query comprising a PDP address usable to route a data message to a mobile terminal of said user attached to said GPRS network. To obtain said PDP address, the domain name server according to the invention further comprises means to send an event notification of incoming data for said user to a location server of said GRPS network, wherein said event notification comprises an identifier of said user.

[0021] The user identifier sent in the event notification from the domain name server to the location server may vary according to some embodiments . In a first alternative embodiment, the user identifier is the one received in the received address query. According to a second alternative embodiment, the domain name server of the invention further comprises means to translate a first identifier of a user received in an address query, into a second identifier of said user stored in said location server.

[0022] According to another embodiment, the domain name server of the invention further comprises means determine, from an identifier of said user, a location server in said GPRS network that is assigned to said user.

[0023] In another aspect, the invention relates to a proxy server that provides an interface between a GPRS network and application servers in a packet data network for transferring a data message towards the mobile terminal of a GPRS user. The proxy server comprises: means to receive a data message from an application server, said data message comprising an identifier of a user of said GPRS network; and means to forward the received data message towards a mobile terminal of said user using a PDP address which is usable to route a data message to said mobile terminal . To obtain said PDP address, a proxy server according to the invention further comprises means to send an event notification of incoming data for said user to a location server of said GRPS network, wherein said event notification comprises an identifier of said user.

[0024] The user identifier sent in the event notification from the proxy server to the location server may vary according to some embodiments. In a first alternative embodiment, the user identifier is the one received in the received data message. According to a second alternative embodiment, the proxy server of the invention further comprises means to translate a first identifier of a user received in data message, into a second identifier of said user stored in said location server.

[0025] According to another embodiment, the proxy server of the invention further comprises means determine, from an identifier of said user, a location server in said GPRS network that is assigned to said user.

[0026] According to still a further embodiment, the domain name server or the proxy server of the invention can further comprise means to store a PDP address in relationship with an identifier of a GPRS user.

[0027] By triggering a Network-Requested PDP Context Activation procedure from a location server, there is not need to compulsorily seize a GGSN in the home-PLMN of the concerned user. For the GGSN which is finally seized to serve the PDP context, the activation procedure for said PDP context is as if it was initiated by the user; thus, said GGSN can serve a PDP Context which has been "Network- Requested" without having to implement the optional "Gc" interface.

[0028] Besides, since a SGSN and a location server according to the invention can store a PDP address of a PDP context active for a user, any of them can prevent a further PDP Context to be created at reception of data from an application server for said user by answering back from any of them with said PDP address, or, alternatively, allow one to be created but reusing the same PDP address.

[0029] By triggering a Network-Requested PDP Context Activation procedure from a location server which has location info about the location of the mobile terminal of the concerned user, as well as information about the particularities of the subscription of this user, said location server can advantageously determine an Access Point Name which can be used to select a GGSN for said PDP context according to the geographical location of the user, and/or according to the visited-PLMN, and/or according to any particularity of his subscription.

BRIEF DESCRIPTION OF DRAWINGS

[0030] Figure 1 shows a simplified signaling flow of a Network-Requested PDP Context Activation procedure according to the state of the art.

[0031] Figure 2 shows an schematic view of some servers in a GPRS network and a packet data network, as well as the interrelationship between their corresponding functional components .

[0032] Figures 3, 4 and 5 show the logical structure of some of the functional components shown in Fig.2.

[0033] Figure 6 shows a simplified signaling flow of a Network-Requested PDP Context Activation procedure according to the invention. DETAILED DESCRIPTION

[0034] Some exemplary embodiments of the invention shall now be described in detail with references to figures 2, 3, 4 , 5 and 6.

[0035] Fig.2 shows some servers that can intervene in the establishment of a data communication between an application server AS (202,201) in a packet data network (200) , and the mobile terminal MT (160) of a user that is attached to a GPRS network (100) . As described earlier, to obtain said data communication, a PDP context needs to be activated for said MT in order to obtain a PDP address usable to route a data message towards said MT. Although a GPRS network (100) usually comprises a plurality of said servers (mainly, if it comprises various GPRS domains of various PLMN operators) , for the sake of simplicity only one server of each type has been shown in Fig.2. Also, for the sake of simplicity, in the following examples it has been assumed that the concerned user has only one terminal (160) ; however, as it is well-known, a user may have a subscription that comprise more than one user terminal, wherein, for example, any of them can be addressable using a single identifier (e.g. a MSISDN number) assigned to said user for his subscription, or using different identifiers (e.g. each assigned to a different terminal). [0036] In addition to the aforementioned ASs (202,201),

Fig.2 shows: a domain name server (110), a proxy server (120), a location server (130), a SGSN (140) and a GGSN (150), as well as a schematic representation of the communication links in these networks (numerals 3Ox) . As cited earlier, the term "location server" should not be understood in this application as referring exclusively to, for example, a HLR capable only for a 2^nd generation GSM system providing GPRS, but also as referring to equivalent servers which, in mobile systems, provide an equivalent function and which can be further enhanced according to the invention.

[0037] It is well-known that a server entity which serves or mediates in the services provided by or through a telecommunications network is, regardless its specific construction details, comprised of one or more functional components, each arranged to perform a specific sub- function of the total functionality implemented by said server entity, and, eventually, arranged to cooperate with other functional component (s) in said server entity. In particular, in modern communications networks these server entities are commonly implemented in computer-based apparatuses comprising software and hardware; wherein a given server entity may be implemented within a single computer-based apparatus, or its functionality be distributed across various cooperating apparatuses, and wherein a specific functional component can comprise a part of software, hardware, or a combination of both; said parts being designed to perform a specific (sub) function and, if proceeds, to cooperate with software and/or hardware parts which implements other functional component (s) . Accordingly, the following description shall be given referring to those functional components which intervene directly or indirectly to accomplish with the invention, without falling into specific construction details dealing with implementation aspects, which are well-known by those skilled in the art, and therefore, which are not relevant for the invention, and considering (for simplicity reasons) that any of the server entities cited hereinafter (e.g. : 110, 120, 130, 140) are implemented each in a single apparatus .

[0038] Initially, the MT (160) of a user has attached to the GPRS network (100) according to the state-of-the-art GPRS procedures (as described, for example, in the aforementioned 3GPP Specification 23.060). In short, this is accomplished by an interaction between the mobile terminal with a SGSN (140) in said network through the radio access network (not shown) . In this MT-SGSN interaction, a location controller functional component LCS (142) in the SGSN takes care of the signaling to and from the MT, as well as of its processing and subsequent actions derived from said signaling which, among other, involve a communication with the location server that holds the subscription of said user. In this SGSN-location server communication, the LCS (142) in the SGSN communicates (300) with a location controller functional component LCH (132) in the location server (130) to, among other, update the location information stored in said location server about the SGSN serving GPRS access to a MT of said user. The LCH (132) in the location server (130) then stores an identifier of said SGSN in a storage component (133) in relationship with other data about said user (such as his user identifiers -MSISDN, IMSI, URL, etc-, charging characteristics, basic and supplementary services, etc).

[0039] An application server AS (201,202) in a packet data network (200) may want to send some data to the MT (160) of a user. However, as commented earlier, said AS has commonly no knowledge of a routable address (e.g. an IP address) for communicating with said MT (i.e. a network address which maps into the GGSN serving a PDP context for said MT) , unless it has activated a data session with said MT. Besides, an address previously used in a data session might not be valid to communicate again with this user from the AS (e.g. dynamic PDP addressing is applied in the GPRS network, the user has moved to a new location, a previous PDP context has been deactivated, etc) . Even more, it might happen, for example, that the data message which is to be sent from the AS to the MT can be contained in a single data packet (e.g. an IP packet); thus, it might happen that the AS just need to know the address of an entry point for the GPRS network (e.g. a proxy server, a GGSN) where to send said data packet. In any case, a AS that sends some data to the MT of a GPRS user needs to use some kind of identifier for said user. Then this identifier can be used to request a connection by different techniques as will be later detailed.

[0040] In general terms, the identifier used by an AS to refer to a given GPRS user in a mobile system can comprise a globally unique identifier (e.g. a Uniform Resource Identifier URI) , or a locally unique identifier within the home-PLMN of this user (such as his MSISDN or his IMSI) . In the first case, a routable address to get an entry point in the home-PLMN can be obtained by using common name-to- address translation techniques (such as Domain Name System DNS) . In the second case, the AS can route a data message towards a well-known entry point in the home-PLMN, including a locally unique identifier of the served user in said PLMN (or in the whole GPRS network) , and use a globally unique identifier of said PLMN to get his message routed to said entry point. Both kind of situations are considered in Fig.2 and in the signaling flow of Fig.6.

[0041] In the schematic representation of Fig.2, AS 201 has been assumed to know a globally unique identifier of a user (e.g.: "john_doe.operatorX.com",

"555555555.gprsnet.com", etc) that can be used to obtain a routable address (such as an IP address) by using a name- to-address translation service, such as the one provided by a DNS infrastructure. Therefore, AS 201 can communicate (301) with a domain name server (203) by issuing an address query which comprises said identifier to obtain in turn a routable address where to send data for a MT (160) of said user. According to known name-to-address resolution techniques, and eventually after various hops between various other mediating domain name servers (not shown in

Fig.2) the address query ends up in a domain name server which is entitled to serve name-to-address translation for the received identifier. In the case exemplified in Fig.2 a domain name server (110) provides name-to-address translation for some or all user identifiers of one or more

PLMN operators of a GPRS network (100) ; thus, the domain name server (110) is arranged to communicate (302) with other entities (203 , 201, etc) in the packet data network (200) to provide a name service.

[0042] The domain name server 110 has an address service mediation component ASM (111) which, according to the invention, can communicate (303) with a location server (130) for activating a PDP context for the MT of a user when it receives an address query, and thus, to obtain a

PDP address which allows AS 201 to communicate with the corresponding GGSN (150) serving said PDP context in order to send data (306) to said MT using said PDP address.

[0043] In the example case illustrated in Fig.2, AS 202 has been assumed to know, in addition to an identifier of the user in the GPRS network or in his PLMN operator, an address of a proxy server (120), which is an entry point in the GPRS network (100) . This address may have been dynamically obtained by using a domain name service (as cited above), or could be pre-stored in the AS 202. Therefore, AS 202 can communicate (307) with the proxy server (120) so as to send it one or more data packets for a MT (160) of the served user.

[0044] The proxy server 120 has a data message relaying mediation component DMRM (121) which is arranged to forward a received data message (e.g. a data packet or a set of data packets) towards the MT of a user through a GGSN serving a PDP context for said MT. According to the invention, when receiving a data message from an AS, the DMRM (121) communicates (308) with the location server (130) for activating a PDP context for the MT of a user, and thus, to obtain a PDP address which allows it to communicate (309) with the GGSN (150) serving the corresponding PDP context to deliver to it a received data message which shall then be sent (306) towards the MT. The data message relaying mediation component DMRM (121) in the proxy 120 could also be arranged to receive a data message and answer back with the corresponding PDP address to the AS 202, so as the AS 202 can finally forward (not shown) the data message to a GGSN (150) .

[0045] Fig.5 shows a generic internal structure of a address service mediation component ASM (111) in the domain name server 110, or a data message relaying mediation component DMRM (121) in the proxy server 120. A communication unit COMM is provided in the ASM (111) or in the DMRM (121) to send and receive communications (302,303,307,308,309) with other server entities (130,150,203,202), either, in the packet data network (200) and in the GPRS network. The communication unit COMM can comprise, for example, one or more communication circuit boards with one or various physical connections, as well as one or more communication protocol stacks (e.g. (DNS/TCP/IP/Ethernet, MAP/TCAP/SCCP/MTP, etc) to accomplish with the necessary signaling and/or data transfer. A processing unit PROC is in cooperation with the communication unit COMM, so as to receive information sent from other server entities, to process it, and, if proceeds, to generate, via a generation unit GEN (which can implement, for example, an adaptation layer for the high- layer parts of the communication stack) , the corresponding subsequent information to be delivered via the communication unit COMM. The address service mediation component ASM (111) or the data message relaying mediation component DMRM (121) can further comprise other storage and/or sub-processing means which can be accessed by the processing unit PROC to perform some specific actions, as will be later detailed. Also, the data message relaying mediation component DMRM (121) in the proxy server (120) usually comprises a data message storage buffer (not shown in Fig.5) where to store temporarily a received data message until a PDP address is obtained to route it towards a GGSN.

[0046] The domain name server 110 and the proxy server 120 provide an interface function between a packet data network (200) and a GPRS network (100) ; and, regardless their specific basic functionality, they can be arranged to provide a set of functions to accomplish with some advantageous embodiments of the invention, as will be described hereinafter. [0047] Referring now to Fig.6, flow 1 shows the arrival of an address query to the domain name server 110, or the reception of a data message in the proxy server 120. The communication unit COMM delivers the content of the received communication to the processing unit PROC. As cited earlier, the address query or the data message comprises an identifier of the user. This identifier might be an identifier not known by other nodes in the GPRS network (e.g. a HLR, a SGSN, or a GGSN) . Thus, an identifier translator (ID-ID MAPP) can be provided in the mediation component (111,121) to translate, for example, between a URI of a user (such as a mail URL) and a MSISDN or a IMSI of said user. The identifier translator (ID-ID MAPP) can be accomplished, for example, by using a simple data storage table which can be queried by the processing unit PROC and which keeps in relationship a plurality of identifiers of a user.

[0048] Similarly, a data storage table could keep track of a valid PDP address in relationship with an identifier of a user (IP-ADDR/ID) . This table can be updated for a PDP context which has been activated for a MT of this user with the mediation of this domain name server (110) or proxy (120) , or can be updated from other server entities mediating in a PDP context establishment (e.g. HLR, SGSN, GGSN) . The validity of an entry in said table (IP-ADDR/ID) , can be subject to a time limit (e.g. a predefined time limit running from PDP context activation) , or can be updated in the domain name server (110) or in the proxy server (120) from any of said servers mediating in a PDP context establishment (e.g. at PDP context activation/deactivation) . Therefore, at reception of an address query (flow 1) , the PROC in the ASM (111) can detect, by checking the table IP-ADDR/ID, that there is a valid PDP address for this user, and could prompt to the GEN to send an answer back towards the querying AS (flow 11 [lb]), directly or through the querying domain name server (203); thus avoiding the starting of a new PDP context for a MT. Alternatively, it could proceed as described hereinafter, but including also the PDP address in the notification it will send to the location server (HLR) in flow 2 (which can start a new PDP context that reuses the same PDP address) . On the other example case, at reception of a data message (flow 1) , the PROC in the DMRM (121) could act in a similar manner, and it can route the received data message using a stored valid PDP address through the GGSN (150) which, in turn, would route it toward the MT (160) through the SGSN (140) (flow ll[la]). Also, the PROC in the DMRM (121) can act as described above in reference to the PROC in the ASM (111) , and include the PDP address in the notification sent in flow 2.

[0049] A further embodiment shall now be described which can be implemented in a domain name server (110) or in a proxy server (120) , when they are providing an interface function for a GPRS network (100) which comprises various PLMN operators , or comprises one PLMN operator which has various location servers. In this case, the aforementioned described mediation component (111,121) can further comprise a location server selector (HLR-SEL) to resolve an identifier of a user into an identifier of the location server assigned to serve said user. The identifier used as input can be either: the identifier received in a communication (2: 302,307), or an identifier obtained by the identifier translator ID-ID MAPP using said received identifier. Accordingly the selector HLR-SEL can be queried from the processing unit PROC to obtain the location server that corresponds to a given user identifier. A simple data storage table that links a set of identifiers with the identifiers of the corresponding location servers can accomplish this. A more complex realization for the HLR-SEL can involve querying to a data repository server storing this information, wherein the HLR-SEL would then comprise the means to query said external data repository. [0050] Once an appropriate identifier for the user has been obtained and a location server for that user has been identified, the processing unit PROC sends the necessary data to the generation unit GEN which, in turn, will order to the communication unit COMM to send a message to said location server, which notifies it an event of incoming data for the user identified with a user identifier included in said notification, as shown in flow 2 of Fig.6. As cited above, the user identifier sent in the data event notification can be the one received, or other one related to the same user. It shall be noticed that, although no data message have been received yet for said user in the case of an address query, the disclosed behaviour is carried out in a similar manner as if said data message was indeed received for said user, since a routable address is needed as a response to said address query. As other message flows referred later, the communication sent in flow 2 can be accomplished by utilizing any existing high- layer communication protocol (such as DIAMETER, MAP, etc) running on its specific low-layer communication stack, or by utilizing an "ad-hoc" high-layer communication protocol designed specifically for this purpose which can run over a well-known low-layer communication stack (such as a TCP/IP or UDP/IP communication stack) .

[0051] Flow 2 of Fig.6 shows also an application server AS sending a data event notification to the location server (HLR) ( interworking case not shown in Fig.2). In fact, according to the invention, a location server may be also an entry point in a GPRS network for a given AS; thereby allowing the triggering of a NRPCA according to the invention, and thus, taking advantage of the knowledge of the data about the served user (and his terminal) held on his location server. A suitable application for this case is, for example, when the communicating AS belongs to the service network of a given PLMN operator, or, in general, when an AS is acquainted with the location server (s) of some PLMN operators (e.g. the AS knows the location server of a user, or knows a specific location server; which, although might be not the one assigned to serve a given user, could in turn know about the corresponding one, and could either: be queried from the AS, or even transfer the notification to the corresponding location server) . The term "service network" (as opposed to the term "core network") is commonly used to refer to the plurality of ASs in packet data networks that provide services (i.e. services beyond the basic bearer services) , and which are arranged to communicate (directly or indirectly) with the servers (nodes) that provide the basic bearer services to the user terminals of a communication network (i.e. the servers that constitute the so called "core network" of said communications networks) . In this kind of interworking scenario, a PLMN can either or both: provide some services by using ASs residing in a packet data network under its domain, or provide services using ASs of another external providers (usually known as "service providers") that reside in another packet data network domains, which can require connections through public data networks (such as the Internet) . In any case, the AS referred above as communicating directly with the location server (AS not shown in Fig.2) , as well as any of the other ASs shown in Fig.2 (201,202), may, or may be not, in a packet data network under the domain of a certain PLMN operator. Thus the packet data network (200) , schematically represented in Fig.2, can comprise private packet data networks of one or several PLMN operators, public packet data networks, and combinations thereof .

[0052] The processing of the arrival of a event notification of incoming data (flow 2) in a location server (HLR, 130) shall now be described in detail with reference to Fig.3, which shows a generic internal structure of a PDP context activation functional component PDPCAC (131) in the location server 130. In short, the PDPCAC (131) in the HLR is arranged to communicate (304) with a SGSN to start a PDP context activation at reception of a event notification of incoming data.

[0053] The PDP context activation component PDPCAC in an location server (130) comprises: a communication unit COMM for sending and receiving communications with other server entities, a processing unit PROC to process the information contained in a received communication and to take subsequent actions, and a communication generation GEN for allowing the corresponding subsequent information to be structured and delivered via the communication unit COMM (i.e. units GEN and COMM perform equivalent tasks as the described earlier with reference to the unit GEN and COMM in the ASM or in the DMRM) . In this particular case, some or all these functional units (COMM, PROC, GEN) of the PDP context activation component PDPCAC can be implemented using common resources (e.g. software modules and/or hardware parts) shared by other functional components in the location server. For example, the communication unit COMM and the generation unit GEN can be shared by the LCH, as well as by the PDPCAC.

[0054] The content of the communication received in flow 2 is delivered in the PDPCAC (131) of the location server (HLR, 130) by the communication unit COMM to the processing unit PROC. According to a basic embodiment, the PROC can access the storage component (133) to obtain an identifier of the SGSN (e.g. a SS#7 number of the SGSN, or an IP address of the SGSN) serving GPRS access to a MT of the user who is identified by the received identifier. This basic embodiment can suffice whenever the user identifier is one of the commonly stored by an location server in relationship with the subscription of a given user (such as the user's IMSI or MSISDN). However, it might be that the server sending the notification received in flow 2 just forward a received identifier (e.g. a non-IMSI or non- MSISDN identifier such as an URI) , for example, because it ignores whether the received identifier can be immediately usable in the location server, or it does not know how to map said received identifier to one stored in the location server for the involved user. Accordingly, the PDPCAC (131) can further comprise an identifier translator ID-ID MAPP (similar to the one described earlier for the mediation components -111,121- in the domain name server and proxy server), and thus, arranged to provide the MSISDN or IMSI that corresponds to a received user identifier. Once obtained, the IMSI or MSISDN can be used to obtain the SGSN identifier from the storage component (133) .

[0055] Once the identifier of the SGSN serving GPRS access to the MT of the concerned user has been obtained, the PROC unit sends the necessary information to the GEN unit (user identifier in the SGSN, SGSN identifier, etc) so as to build up a request to activate a PDP context to be sent through the COMM unit towards said SGSN (flow 3) .

[0056] In a further embodiment, the PDPCAC (131) of the location server (130) can also comprise, or have access to, a data storage table (IP-ADDR/ID) to keep track of a valid PDP address in relationship with an identifier of a user. So, at reception of a data event notification (flow 2), the PROC in the PDPCAC (131) can check the table IP-ADDR/ID and detect whether there is a valid PDP address for this user, and, if this is the case, it can send it back to the GEN, so as to send an answer back towards the querying server (flows 10 [1] or 10 [2]); thus avoiding the starting of a new PDP context for a MT (or, as described earlier with reference to the proxy server or domain name server, proceed to start a new PDP context, but reusing the same PDP address) . The IP-ADDR/ID table (which, although shown independently in Fig.3, can be stored in the storage 133) can be updated for a PDP context which has been activated for a MT from this location server, or can be updated from a SGSN or GGSN serving a MT initiated PDP context for the MT of a user. [0057] According to a further embodiment, the request to activate a PDP context to be sent to the SGSN (flow 3) can further comprise one (or more) Access Point Name(s) APN(s) that could then be used to select in said SGSN a GGSN which relates to said APN. The APN can be determined according to various criteria which can comprise, for example: the location of the concerned user, and/or specific data related to the subscription of said user, and/or the AS which causes the triggering of the Network-Requested PDP Context Activation NRPCA. To carry out this, the PDPCAC (131) of a location server (130) can further comprise an

APN selector (APN-SEL) which, in a simple realization, can be accomplished by a data storage table whose content can comprise a set of APN identifiers together with some further data that shall now will be described (a more complex realization can involve querying an external data repository storing this information, wherein the APN-SEL in the PDPCAC would then comprise the means to query said external data repository) . [0058] For example, in relationship with a given APN, the table of the APN selector (APN-SEL) in the PDPCAC (131) can comprise the identifiers of one or more SGSNs . Also, the table could store one or more APNs in relationship with the identifier of a SGSN. Then, once determined the SGSN of a user by the PROC unit, the APN selector (APN-SEL) would provide it the APN(s) that could be sent in the request of flow 3; thereby allowing to select, based on said APN, a GGSN which can be the more advantageous taking into account the geographical location of the user (e.g. a GGSN which is close to the serving SGSN, a GGSN in the visited-PLMN said SGSN belongs to, etc) . Additionally, or alternatively, the table of the APN selector can further comprise references to some data stored (133) in relation to the subscription of a user. These references, that could be grouped for example in user subscription categories (e.g. cat_class-l, cat_class-2, ... , cat_class-n) , could be used to determine the corresponding APN by linking them to the identifiers of one or more APNs in the APN selector table. Thus, in this case the PROC could obtain from the stored subscription data for the concerned user (133) the corresponding data to index said references. Additionally or alternatively, the APN selector (APN-SEL) can further comprise a storage relationship between APNs and identifiers of ASs similar to the storage relationship described above for APNs and SGSNs. Therefore, an identifier of the AS that causes the triggering of the NRPCA procedure (that could also be received in the data event notification) , can influence the selection of a APN. Accordingly, more than one interaction to select an APN can take place between the PROC unit and the APN selector APN-SEL. If, for example, using one criteria (e.g. SGSN identifier) , more than one APN is obtained in a first interaction, some of these APNs can be further filtered using other different criteria (e.g. user's subscription data or AS identifier). In any case, more than one APN could be delivered to the SGSN in the request sent in flow 3.

[0059] The relationship between: a particular SGSN and/or AS and the corresponding APN, can be established so as to minimize the GPRS communication path between a MT (served by said SGSN) and the GGSN which is related to said APN, and/or to minimize the communication path between said GGSN and the AS through the packet data network; and thus, to optimize the total transmission path (GPRS communication path, plus packet data network communication path) between an AS and the MT which it communicates .

[0060] A state-of-the-art SGSN (140) comprises a PDP context activation functional component PDPAC (141) arranged to coordinate a PDP context activation requested by the MT of a user, or a Network-Requested PDP Context Activation NRPCA, by communicating (305) with the MT (160) and with the corresponding GGSN (150). Fig.4 shows a generic internal structure of said PDPAC (141) , wherein some elements are further modified to accomplish with the invention, as will be later described. In short, to accomplish with a Network-Requested PDP Context Activation procedure according to the state-of-the-art, the PDPAC (141) in a SGSN (140) is arranged to receive a request from a GGSN to start a PDP context activation for the MT of a user who is identified by his IMSI, and to further send to said MT a request a request for PDP context activation (as described earlier with reference to Fig.l). For this purpose, the PDPAC (141) of the SGSN (140) comprises, according to the known art: a communication unit COMM arranged to provide the reception and sending of communications to/from a MT and to/from a GGSN, a processing unit PROC that processes the information of communications received related to PDP context activation, and a communication generation unit GEN cooperating with the processing unit PROC and with the communication unit COMM to allow the information related to PDP context activation to be delivered towards said MT and said GGSN.

[0061] To accomplish its function, the processing unit PROC of the PDPAC (141) of a SGSN (140) can further cooperate with some other sub-elements comprised in the PDPAC (141) , as well as with sub-elements of other functional components in the SGSN. For example, it can cooperate with a GGSN selector (GGSN-SEL) which implements the selection logic described in the "Annex A" ("APN and GGSN selection") of the aforementioned 3GPP Specification 23.060. The processing unit PROC can, according to the known art, further access some data (MM-INF, PDP-INF) it has stored for the MT of a user, and which relates to mobility management data and PDP information.

[0062] To accomplish with the invention, the PDP context activation functional component PDPAC (141) of the SGSN (140) is modified as described below with reference to the reception of the PDP activation request from a location server (flow 3 in Fig.6).

[0063] Firstly, the communication unit COMM is adapted to communicate with a location server (HLR, 130) so as to be able to receive a request to start a PDP context activation from it. Nowadays, the so called "Gr" interface allows communications between a SGSN and a HLR using MAP signaling over a SS#7 communication stack. Therefore, the "Gr" MAP interface could be enhanced so as to support the conveyance of this specific request sent from a location server. Alternatively, other communication means as described earlier could be used to receive said request from a location server (e.g. involving the use of another protocol different from MAP as well as using another communication stack which is not necessarily a SS#7 stack) . The processing unit PROC is also modified so as to behave at reception of a request for PDP activation from a location server in a similar way as when receiving it from a GGSN (as described earlier with reference to Fig.l), and thus, to start the corresponding signaling towards the involved MT and GGSN. The processing unit PROC can also be modified so as to consider the APN(s) indicated by the location server as prevailing over the currently implemented APN selection logic (cited above) . Alternatively, the aforementioned GGSN selector GGSN-SEL can be arranged to override some or all its current APN selection logic when the processing unit PROC indicates that a APN has been indicated by a location server; wherein this arrangement can comprise the checking by the GGSN-SEL of some related data, such as the identifier of the location server serving the concerned user (that could also be received in flow 3), or some other data which are currently stored by a SGSN with regard to a served user.

[0064} The modifications described above will cause that, at reception of a request to activate a PDP context received from a location server (flow 3), subsequent flows 4 to 8 (which are equivalent to flow IV and collapsed flow V of fig.l) take place to provide said PDP context (comprising the provision of the corresponding PDP address) ; wherein the GGSN selected to serve said PDP context may have been selected according to the APN received from the location server, as described above. The processing unit PROC can be further modified so as to, if the request to activate a PDP context comes from a location server, check whether a PDP context is already activated for the concerned user which can be suitable for this request (e.g. by checking the PDP information PDP-INF); and, if so, answer back (flow 9) with the corresponding PDP address used in said PDP context.

[0065] Further, the communication generation unit GEN and the communication unit COMM are also modified in the PDPAC (141) of a SGSN so as to, respectively, build and send a response (flow 9) to the request (flow 3) received from the location server (HLR, 130), which comprises the PDP address that corresponds to the PDP context that has been activated. The same protocol and communication stack used to receive the request (flow 3) can also be used to send this response (flow 9) . Although the response of flow 9 appears in Fig.6 as sent to the location server (HLR, 130), an alternative implementation could be to send it to the server that initiated the request (e.g. domain name server 110, proxy server 120, or an application server AS) . To accomplish with this alternative implementation a routable identifier of said initiating server (e.g. an IP address of said server, or a URI which maps into an IP address of said server) can also be received in flow 3. This routable identifier would have be then received by the corresponding PROC units and indicated to the corresponding GEN units in the affected signaling flows (flows 2 and 3) .

[0066] Continuing with the example case illustrated in Fig.6, a response to the operation invoked in flow 3 arrives to the location server (HLR, 130). There, the processing unit PROC of its PDPCAC (131) shall then prompt to the communication generation unit GEN to build up a response which comprises the received PDP address and send it through the communication unit COMM towards the server that sent the event notification of incoming data (flows 10 [1] or 10 [2]). As cited earlier, the processing unit PROC of the PDPCAC (131) in the location server can further store (IP-ADDR/ID) the received PDP address in relationship with an identifier of the concerned user.

[0067] When the response to event notification of incoming data a arrives (flow 10 [1]) to the domain name server (110) , the processing unit PROC of its address service mediation component ASM (111) instructs the communication generation unit GEN to build up the corresponding response to the address query, which comprises the obtained PDP address, and to send it through the communication unit COMM (flow 11 [lb]). The address service mediation component ASM (111) of the domain name server (110) can further comprise an address translator (IP-ADDR TRL) to translate the received PDP address into another address (of the same or different type) ; being this applicable, for example, whenever private IP addresses are assigned as PDP addresses, and network address translators (NAT) are needed to allow the data exchange with ASs that require the use of real IP addresses. [0068] When, according to the other example case, the response arrives to the proxy server (120) (flow 10 [1] ) , the processing unit PROC of its data message relaying mediation component DMRM (121) instructs the communication unit COMM to forward the received data message it had stored using the received PDP address (flow ll[la]) .

[0069] As cited earlier, the processing unit PROC of the both mediation components, 111 or 121, can be further arranged to store (IP-ADDR/ID) the received PDP address in relationship with an identifier of the concerned user.

[0070] When a response to an address query arrives to a requesting AS (flow 11 [b] ) , or when a response to a previously sent data event notification arrives to the AS which sent it (flow 10 [2]); the AS can use the received PDP address to send the data message towards the MT of the concerned user, as shown, respectively, in flows 12 [lb] and 11[2] .

[0071] Server entities in a state-of-the-art telecommunications network (e.g.: 110, 120, 130, 140) are commonly implemented in computer-based apparatuses. Accordingly, computer programs having computer-readable program codes are loaded in computer-based apparatuses of telecommunications networks, causing each of them to behave according to a predefined manner that is in accordance to their specific functionality. Thus, those skilled in creating and/or modifying computer programs intended to be loaded in computer-based location servers (130), SGSNs (140), or servers providing an interface between a packet data network (200) and a GPRS network (100) (such as a domain name server 110, or a proxy server 120) would, without departing of the teachings of the present invention, readily apply those teachings to create and/or modify computer programs which, when executed in any of said computer-based servers, would make them to behave respectively according to any of the described embodiments .

[0072] The invention has been described in respect to some exemplary embodiments in an illustrative and non- restrictive manner. Variations can be readily ^' apparent to those of ordinary skill in the art. For this reason, the invention is to be interpreted and limited in view of the claims .

Claims

1. A location server (130) for storing subscription data of a general packet radio service user, the location server comprising - a storage (133) for storing in relationship an identifier of said user and an identifier of a serving general packet radio service support node (140) providing general packet radio service access to a mobile terminal (160) of said user; CHARACTERIZED in that it further comprises a packet data protocol context activation controller (131) for handling signaling to start a packet data protocol context activation for said mobile terminal, said signaling comprising: - the reception of an event notification of incoming data (2), said event notification comprising an identifier of said user, and the sending of a request to start (3) a packet data protocol context activation for said mobile terminal to said serving general packet radio service support node, said request (3) comprising an identifier of said user in said serving general packet radio service support node, wherein said packet data protocol context activation controller is responsive to the reception of said event notification (2) so as to send said request to start (3).

2. The location server of claim 1, wherein said packet data protocol context activation controller comprises an identifier translator (ID-ID MAPP) to translate a first identifier of said user received in said notification (2) into second identifier of said user.

3. The location server of claim 1, wherein said packet data protocol context activation controller comprises a selector (APN-SEL) for selecting an Access Point Name for said packet data protocol context, and wherein said request to start (3) further comprises said Access Point Name.

4. The location server of claim 1, further comprising a packet data protocol address storage (IP-ADDR/ID) to store a packet data protocol address corresponding to an active packet data protocol context of a user in relationship with an identifier of said user.

5. The location server of claim 4, wherein said signaling to start a packet data protocol context activation further comprises the sending of an answer (10 [1], 10 [2]) to said event notification (2), and wherein said packet data protocol context activation controller is responsive to the reception of said event notification so as to check said address storage (IP-ADDR/ID) and to send an stored packet data protocol address in said answer .

6. The location server of claim 1, wherein said signaling to start a packet data protocol context activation further comprises : the reception of a response (9) to said request to start (3), said response comprising a packet data protocol address corresponding to said packet data protocol context, and the sending of an answer (10 [1] , 10 [2] ) to said event notification (2) comprising said address, wherein said packet data protocol context activation controller is responsive to the reception of said response so as to send said answer.

7. The location server of claims 4 and 6, wherein said packet data protocol context activation controller is responsive to the reception of said response (9) so as to store said received address in said address storage (IP-ADDR/ID) .

8. The location server of any of preceding claims, wherein the packet data protocol context activation controller comprises: at least a communication unit (COMM) to exchange signaling, and at least a processing unit (PROC) for processing the signaling received by a communication unit and for initiating a communication unit to transmit the signaling to be sent.

9. A serving general packet radio service support node (140) for providing general packet radio service access to a mobile terminal (160) of a general packet radio service user, the serving general packet radio service support node comprising a packet data protocol context activation controller (141) for handling signaling to activate a packet data protocol context for said terminal, said signaling comprising the sending of a request to activate (IV) a packet data protocol context to said mobile terminal; CHARACTERIZED in that said signaling further comprises the reception of a request to start (3) a packet data protocol context activation for said mobile terminal from a location server (130) storing subscription data of said user, said request to start (3) comprising an identifier of said user in said serving general packet radio service support node, wherein said packet data protocol context activation controller is responsive to the reception of said request to start (3) so as to send said request to activate (IV) .

10. The serving general packet radio service support node of claim 9, wherein said request to start (3) comprises an Access Point Name, and wherein said packet data protocol context activation controller (141) further comprises a selector (GGSN-SEL) to select a gateway general packet radio service support node (150) for said packet data protocol context according to said Access Point Name.

11. The serving general packet radio service support node of claim 9, wherein said signaling further comprises the sending of a response (9) to said request to start (3) comprising a packet data protocol address corresponding to the activated packet data protocol context, and wherein said packet data protocol context activation controller (141) is responsive to a packet data protocol context activated with said request to start (3) so as to send said response (9).

12. A domain name server (110) for providing an interface function between a general packet radio service network (100) and an application server (201) in a packet data network (200), the domain name server comprising an address service mediator (111) for handling signaling to obtain a packet data protocol address usable to route a data message to a mobile terminal (160) of a general packet radio service user, said signaling comprising: the reception of an address query (1) comprising an identifier of said user, and the sending of an answer (11 [lb]) to said address query comprising said packet data protocol address; CHARACTERIZED in that said signaling further comprises the sending of an event notification of incoming data (2) to a location server (130) of said general packet radio service network (100) , said event notification comprising an identifier of said user, wherein said address service mediator is responsive to the reception of said address query (1) so as to send said event notification (2) .

13. The domain name server of claim 12, wherein said address service mediator comprises an identifier translator (ID-ID MAPP) to translate a first identifier of said user received in said address query (1) into second identifier of said user for being sent in said event notification (2).

14. The domain name server of claims 12 or 13 , wherein said address service mediator comprises a selector (HLR-SEL) to resolve an identifier of a user into an identifier of a location server (130) assigned to said user.

15. A proxy server (120) for providing an interface function between a general packet radio service network (100) and an application server (201) in a packet data network (200), the proxy server comprising a data message relying mediator (121) for handling the transfer of a received data message comprising an identifier of a general packet radio service user towards a mobile terminal (160) of said user; CHARACTERIZED in that, to obtain a packet data protocol address usable to route a data message to said terminal, said message relying mediator is responsive to the reception of a data message (1) so as to send an event notification of incoming data (2) to a location server (130) of said general packet radio service network (100) , said event notification comprising an identifier of said user.

16. The proxy server of claim 15, wherein said message relying mediator comprises an identifier translator (ID-ID MAPP) to translate a first identifier of said user received in said data message (1) into second identifier of said user for being sent in said event notification (2) .

17. The proxy server of claims 15 or 16, wherein said message relying mediator comprises a selector (HLR-SEL) to resolve an identifier of a user into an identifier of a location server (130) assigned to said user.

18. A method to trigger the start a network-requested packet data protocol context activation procedure for a mobile terminal (160) of a general packet radio service user; CHARACTERIZED in that it comprises the steps of: - receiving an event notification of incoming data (2) in a location server (130) storing subscription data of said user, said event notification comprising an identifier of said user, obtaining an identifier of a serving general packet radio service support node (140) providing general packet radio service access to a mobile terminal (160) of said user, and sending to said serving general packet radio service support node a request to start (3) a packet data protocol context activation for said mobile terminal to said serving general packet radio service support node, said request to start comprising an identifier of said user in said serving general packet radio service support node.

19. The method of claim 18, further comprising the step of translating a first identifier of said user received in said notification (2) into second identifier of said user.

20. The method of claim 18, further comprising the previous step of storing in said location server a packet data protocol address corresponding to an active packet data protocol context of a user in relationship with an identifier of said user.

21. The method of claim 20, further comprising the step of checking whether a packet data protocol address is already stored in relationship with an identifier of said user before sending said request to start (3), and further comprising the step of: sending said request to start (3), if no address is stored, or the step of: sending an answer (10 [1], 10 [2]) to said event notification (2), if an address is stored, wherein said answer comprises said stored address.

22. The method of any of claims 18, 19 or 21, further comprising the step of selecting in said location server an Access Point Name for said packet data protocol context, and wherein said request to start (3) further comprises said Access Point Name.

23. The method of any of claims 18, 19, 21 or 22, further comprising the steps of: receiving in said location server a response (9) to said request to start (3) comprising a packet data protocol address corresponding to said packet data protocol context, and sending an answer (10 [1] , 10 [2 ] ) to said event notification (2) comprising said address.

24. The method of claim 23, further comprising the step of storing said address in relationship with an identifier of said user.

25. A computer program for triggering the start a network- requested packet data protocol context activation procedure for a mobile terminal (160) of a general packet radio service user from a computer-based location server (130) storing subscription data of said user; CHARACTERIZED in that it comprises: a computer-readable program code for causing said computer-based location server to process the reception of an event notification of incoming data (2), said event notification comprising an identifier of said user, a computer-readable program code for causing said computer-based location server to obtain an identifier of a serving general packet radio service support node (140) providing general packet radio service access to a mobile terminal (160) of said user, and a computer-readable program code for causing said computer-based location server to send to said serving general packet radio service support node a request to start (3) a packet data protocol context activation for said mobile terminal to said serving general packet radio service support node, said request to start comprising an identifier of said user in said serving general packet radio service support node .

26. The computer program of claim 25, further comprising a computer-readable program code for causing said computer-based location server to translate a first identifier of said user received in said notification (2) into second identifier of said user.

27. The computer program of claim 25, further comprising a computer-readable program code for causing said computer-based location server to select an Access Point Name for said packet data protocol context and to include it in said request to start (3) .

28. The computer program of claim 25, further comprising a 5. computer-readable program code for causing said computer-based location server to process the reception of a response (9) to said request to start (3) comprising a packet data protocol address corresponding to said packet data protocol context, and to send an0 answer (10 [1] , 10 [2] ) to said event notification (2) comprising said address .

29. The computer program of claim 28, further comprising a computer-readable program code for causing said computer-based location server to store said address in5 relationship with an identifier of said user.