COMMUNICATION SYSTEM AND METHOD

Abstract: The described invention relates to a communication method and system having at least one communication network (1) to which a plurality of subscribers are attachable (2) and which comprises at least one subscriber information register (7) storing subscriber information including location information related to the subscribers, at least one gateway support node (4) for handling connections to and/or from other networks, and at least one serving node (5) for handling connections with connection originating or terminating elements (2). At least one network element (5) is provided in addition to the gateway support node which stores information (6) regarding the addresses of serving nodes presently or recently in charge of handling connections to and/or from connection originating or terminating elements. The gateway support node can therefore address this network element for connection, and requires reduced own storage capacity.

Description: COMMUNICATION SYSTEM AND METHOD FIELD OF THE INVENTION The present invention relates to a communication method and system having at least one communication network to which a plurality of subscribers are attachable. The system may comprise at least one subscriber information register such as a home location register (HLR) storing information related to the subscribers. The subscriber information register can be accessed when information on one or more subscribers is needed for handling connections and the like. BACKGROUND OF THE INVENTION Communication systems for mobile communication such as GSM (Global System for Mobile Telecommunications) , GPRS (General Packet Radio Service) , or UMTS (Universal Mobile Telecommunications System) networks usually comprise one or more home location registers (HLRs) for permanent storage of subscriber information such as IMSI (International Mobile Subscriber Identity) , one or more VLRs (Visitor Location Registers) providing access to the subscriber equipment, one or more MSCs (Mobile Switching Centers) for transmitting data to the user equipments, and the like. When a connection is to be connected to a subscriber e.g. from an external network, the home location register will normally be accessed for receiving information necessary for properly routing of the connection. One of several possible procedures to be performed between a user equipment such as a mobile station (MS) and the network for connecting an external network is a so-called "PDP context activation", wherein PDP stands for packet data protocol. Such a PDP context activation may be performed in particular in a packet switched network such as a GPRS network wherein several information elements such as requested or negotiated QoS (Quality of Service) and/or PDP address are transmitted between the user equipment (MS) and a support node handling the communication with the user equipment. Such a "PDP context activation" procedure is a standardized process and is e.g. described in the publication ETSI (European Telecommunications Standards Institute) EN 301 344 Vβ.3.2 (1999-07), pages 59 ff . This process will therefore not be explained here in further detail. (For more detailed information, it is referred to the above mentioned document.) The "PDP context activation" procedure may be initiated by a mobile station intending to attach to the network after switch-on, for instance, or may be requested by the network and is then called "network-requested PDP context activation" (NRCA) procedure, see for instance EN 301 344, section 9.2.2.2. Such a network-requested PDP context activation procedure allows e.g. a GGSN (Gateway GPRS support node) to initiate the activation of a PDP context. When receiving a PDP (Packet Data Protocol) PDU (Protocol Data Unit), the GGSN may check if a PDP context has already been established for that PDP address. If no PDP context has previously been established, the GGSN may try to deliver the PDP PDU by initiating a network-requested PDP context activation procedure. The GGSN may send a message (containing e.g. IMSI, International Mobile Subscriber Identification) to the home location register HLR requesting routing information for GPRS. When the HLR determines that the request can be served, it returns a message to the GGSN indicating routing information. When the HLR determines that the request cannot be served (e.g. the IMSI is unknown in HLR) , the HLR will send back a negative response indicating the reason for non-service. Furthermore, the gateway node may store an information "Mobile Station Not Reachable for GPRS" (MNRG flag) indicating whether or not a user equipment such as a mobile station can be reached .. In addition, the gateway node is usually adapted to store the address of the support node with which the gateway established the last connection for transmitting data to and/or from a user equipment (e.g. last PDP context). GGSN also should store the mapping between PDP address (ie IP address) and IMSI. The gateway hence requires a large storage capacity for storing these information which will be retained even for presently not active user equipments. SUMMARY OF THE INVENTION The present invention provides a solution which does not require unduly large storage capacity of the gateway support node (s) . The invention provides a system having at least one communication network to which a plurality of subscribers are attachable and which comprises at least one subscriber information register such as a HLR storing subscriber information including location information related to the subscribers, at least one gateway support node for handling connections to and/or from other networks, and at least one serving node for handling connections to User Equipment. The system comprises at least one network element, in addition to, and normally different from the gateway support node, which preferably is provided for accessing the subscriber information register when information on one or more subscribers is necessary for handling connections directed to these subscribers. The at least one network element comprises a memory storing information containing a context for every user equipment. This context contains: - address of a serving node presently or recently in charge of handling connections toward user equipment, and/or - information on the user equipment reachability, and/or - logical name or subscriber identity to network address mapping, or network address to logical name or subscriber identity mapping. The subscriber identity may e.g. be the identity used within the network such as IMSI, MSISDN etc. which subscriber identity is different from the address used by another network such as an external network connected to a gateway node of the present network. This address may e.g. be a address for connection routing such as a PDP address of the user equipment. The context may e.g. contain the mapping of the address used in the external network (e.g. PDP address in in GSM and/or UMTS systems) and an identifier of the user equipment (e.g. IMSI in GSM and/or UMTS systems), and/or the addresses of support nodes presently or recently in charge of handling connection to the user equipment .Note that the general term user equipment used in this application, refers to a Mobile Station in GSM and/or UMTS systems. The at least one network element preferably additionally stores information about presently unreachable user equipment (this information being for example the MNRG flag in GSM and/or UMTS systems) . For clarity, this new network element will be called NRCA support node throughout this application) . It however may be implemented into a variety of ways such as a server dedicated for this task, or a function integrated in another network element like a signaling Gateway (e.g. gateway converting signaling between IP network and PSTN network) or an Interworking support node which is implemented as an independent support node, or as part of a Serving support node. In a preferred embodiment, the NRCA support node is adapted to be able to generate interrogation access requests for accessing the subscriber information register. The network preferably comprises at least one server for storing unique subscriber identifier information (IMSI). According to one embodiment of the invention, the gateway support node(s) and the network element (s) are adapted to generate and/or receive messages containing an IP address instead of an IMSI (International Mobile Subscriber Information) of a subscriber. The network element (s) is capable of deriving the IMSI from the PDP address (i.e. IP address). Alternatively, or additionally, the gateway support node(s) and the network element (s) may be adapted to generate and/or receive messages containing a logical name of a user instead of an IMSI (International Mobile Subscriber Information) thereof, one network element containing the correspondence between the logical name and the IMSI information. The invention furthermore provides a method for or in a system as described above, wherein the at least one network element stores information regarding the addresses of serving nodes presently or recently in charge of handling a connection to user equipment. The interrogation access requests may e.g. be caused by network-requested PDP Context Activation requests (NRCA) . The invention is particularly relevant for an UMTS or GPRS network implementing NRCA procedures but is also applicable to other types of networks such as GSM having registers which are to be accessed when initiating or performing connections. According to the invention, at least some of the connection parameters previously stored in a gateway support node are now stored outside thereof, e.g. in an NRCA support node. These parameters preferably include the MNRG flag, and/or the old support node address such as old SGSN address to which a previous connection to an again selected user equipment was directed, IMSI of said user equipment to which NRCA procedure may be performed, and possibly also run timers. In this case, the subscriber information register such as HLR (home location register) preferably stores the address of the NRCA support node instead of the address of the gateway support node (e.g. GGSN, i.e. gateway GPRS support node). This is needed so that when HLR indicates when an MS is reachable again, it can inform the elements containing MNRG flag (here NRCA support node) , to turn off the flag. But HLR does not need to be modified for that. It will just store NRCA support node address in the field reserved for GGSN address. When receiving an incoming packet for a given PDP address, the gateway support node sends a message (e.g. GTP message "GTP send routing info for GPRS") to the NRCA support node. This message may or may not contain a user equipment identifier such as IMSI. If the gateway support node maintains, in its memory or an external memory such as in a LDAP server, a mapping between IMSIs- and IP addresses, the IMSI will be included in the message. Then the message sent could be GTP message so called "GTP send routing info for GPRS" according to GPRS/UMTS standards . In an alternative embodiment, the standard GTP message sent from the gateway support node to the NRCA support node may be replaced by a modified GTP message containing the user IP address instead of IMSI. This is of particular advantage in networks using and transmitting the IP addresses instead of IMSI. The NRCA support node then preferably maintains, in its memory or an external memory such as in a LDAP server, a mapping between IMSIs and IP addresses. This alternative embodiment provides the benefit of avoiding the necessity of storing IMSI in the gateway support node. Further, it leads to a reduction of the signalling and delay caused by the routing of the connection. It may be noted that both embodiments described above provide the possibility to store the mapping between the IMSI and the PDP address in the memory of a different network entity such as in an LDAP server (LDAP, lightweight directory access protocol) . This mapping changing rarely, a LDAP server is well suited for this task, as it may be queried regularly, but would be updated quite rarely. The gateway support node is preferably equipped with a timer means which is started when an incoming packet is received, and will determine how long this incoming packet (and possibly following ones) is stored before being deleted. This timer is stopped when an activate PDP context request is received. After the PDP context activation procedure stored packet can be forwarded to the user equipment. Note that this timer should be long enough to allow the NRCA procedure to be completed. The gateway support node is programmed or structured so as not to generate any new "GTP send routing info for GPRS" message as long as the timer is running. When the timer expires, all packets received for this PDP (packet data protocol) address are deleted, and new "GTP send routing info for GPRS" messages can again be generated. When the NRCA support node receives a message such as "GTP send routing info for GPRS" request from the gateway support node, it will first find the old SGSN address by either interrogating HLR (HLR can always be found based on IMSI) , or by checking whether it has stored an old SGSN address for the user equipment (identified for instance by its IMSI) . If such an old SGSN address is found, and if there is no indication that the MS is not reachable, the NRCA support node sends a PDU (protocol data unit) notification request to this SGSN. The SGSN 3 sends a "request PDP context activation" message to the mobile station MS 2. The PDP context activation is performed towards the gateway support node 4 (as it is the only one handling this IP address) . The GGSN can then forward packet to the user equipment. It should be noted that the invention may be implemented with any other protocol than GTP, as long as similar information is carried . In a preferred implementation, the NRCA support node function is integrated in an Interworking GSN (GPRS support node) , meaning that the MNRG flag and the "old SGSN address" may preferably be stored in an Interworking GSN (GPRS support node) which usually is provided for converting a GTP (GPRS tunnelling protocol) message into a MAP (mobile application part) message for HLR interrogation. This structure and functioning of an Interworking GSN is known and standardised, see e.g. ETSI EN 301 344 V6.3.2, section 5.6.2.7.2. This support node is provided with a memory for storing these parameters. In a further preferred embodiment, the IP address may also be replaced by a user logical name which will then be indicated in a message addressed to the gateway support node, and will be used for transmitting the packets to the user identified by this logical name. In this embodiment, suitable in particular if every user of NRCA is not having a static IP address, a modified DNS server sends a message containing logical name and/or subscriber identity (IMSI) (e.g. a modified "GTP send routing info for GPRS") to the GGSN or NRCA support node informing that it has received a request from an external entity to derive the IP address based on the logical name. In this alternative embodiment, the gateway support node, if it has received the message from DNS will send, in step 2.) of Fig. 2 to be described below, a modified "GTP send routing info for GPRS" message to the NRCA support node 5 in which the user logical name are indicated instead of IMSI. When receiving such message (from modified DNS, or GGSN) , the NRCA support node then preferably maintains, in its memory or an external memory such as in a LDAP server, a mapping between IMSIs and logical names. Once that the context is activated, the GGSN updates the DNS server with the IP address allocated for this particular logical name. The DNS can then provide this •information to the requesting entity trying to reach the user. According to the present invention, there is no need to store a context for active or even for non-active addresses in the gateway support node. This simplifies the implementation of the gateway support node(s). Furthermore, it reduces the necessary buffer capacity in the gateway support node(s), or alternatively allows the storage of more PDP contexts (for active addresses). A further advantage resides in the possibility of separately handling the complex requirements of the NRCA feature. In addition, the GTP to MAP conversion may be implemented in an Interworking support node so that there is no need to implement such a conversion feature in the serving support nodes such as SGSNs. Hence, the SGSNs can be implemented having a simpler structure. The invention furthermore provides network elements as defined in any one of claims 22 to 29. 5 BRIEF DESCRIPTION OF THE FIGURES Fig. 1 shows a schematic representation of one embodiment of the present invention; 1.0 Fig. 2 illustrates steps performed in an embodiment of a method according to the invention; and •Fig. 3 illustrates a GTP and MAP-based GSN-HLR signalling between a support node IGSN and a home location register HLR. 15 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE PRESENT INVENTION 20 Fig. 1 shows an embodiment of a telecommunication system which comprises a network 1. The network 1 preferably is a packet- switched network such as a GPRS (General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System) network. The network 1 comprises a plurality of user equipments such as 25 mobile stations (MS) 2 which are able to communicate with other user equipments or terminals arranged in the same or another network. For placing or receiving a connection, a user equipment 2 is supported by a support node 3 which here is a SGSN (Serving GPRS support node) and which communicates 30 (exchange of user traffic data and signalling) with a further node 4 which may be a gateway node such as a GGSN (Gateway GPRS support node) . In a practical implementation of the network 1, one or more support nodes 4 and/or support nodes 3 will be provided. A subscriber information register such as a home location register (HLR) 7 stores location information and other information on a plurality of user equipments 2. In the present embodiment, the support node 4 is adapted to communicate with the HLR 7 via an NRCA support node 5. Each of these support nodes 4 is sending information to the support node 5 when a Network requested context activation is required. The support node 5 is then further requesting or sending information from or to the home location register 7. Hence, the support node 5 may handle signalling from all support nodes 4. The GGSN 4 and/or the SGSN 3 may additionally be adapted to communicate directly with the register 7. For limiting the maximum storage capacity necessary in the gateway support node(s) 4, the support node 5 comprises a memory 6 which stores information such as "MNRG flag" , and/or the relation between IMSI and IP address and/or "Old SGSN address", i.e. the address of the SGSN with which the GGSN established the last PDP context. According to the invention, information related to a specific process such as a NRCA process is stored in a network element such as an NRCA support node 5 via which a HLR inquiry may be performed for this process (e.g. NRCA). Furthermore, this NRCA network element 5 shall contact the serving support node 3 with requests such as a PDU notification request message. This is normally done, in the prior art, by the gateway support node. According to the standards, the Interworking support node 5 may perform a GTP to MAP message conversion (e.g. a conversion from a GTP send routing info message to MAP send routing info message) , but do not store context related to subscriber (information may only be stored for the time of a transaction). The gateway support node has according to standards to: - store context related to subscriber (such as "MNRG flag" , and/or the relation between IMSI and IP address and/or "Old SGSN address") - decide to query the HLR or not. If the MS is marked non- reachable, or if the old SGSN address is stored, the HLR may not be queried. According to this invention, the implementation of the gateway support node is simplified with respect to handling of NRCA requests because the NRCA-related information may be stored in 'the NRCA support node 5. The inquiries of the HLR 7 from the gateway support node 4 are handled by the NRCA support node 5. The NRCA support node 5 decides to query the HLR or not, based on the parameter it is storing. Therefore, some of the tasks normally performed by the gateway support node 4 are carried out by the NRCA support node 5. In th s case, it is the task of the NRCA support node to check the NRCA parameters like "mobile not reachable for GPRS" flag and the "old SGSN address". If "mobile not reachable reason cause" is not set and an SGSN address is present in the NRCA node, the NRCA node sends the PDU notification request message to the stored SGSN address. The SGSN 3 sends a "request PDP context activation" message to the mobile station MS 2. The PDP context activation is performed toward the gateway support node 4 (as it is the only one handling this user IP address) . The invention can also be implemented, in an alternative embodiment, by storing the PDP address (or IP address) to IMSI mapping in an LDAP server. The IMSI is used to find the HLR address, so the entity performing the MAP interrogation needs the means to derive the IMSI related to a request. Although, in the above, NRCA is mainly used for explaining the problems and solution underlying the present invention, same is not restricted to NRCA requests but is applicable to all network structures handling connections between a gateway node and one or more user equipments. Fig. 2 illustrates an embodiment of a method according to the invention . Generally, the network-requested PDP context activation procedure is standardised and e.g. described in EN 301 344 V6.3.2 (1999-07) of ETSI (European Telecommunications Standards Institute), see page 61 ff., section 9.2.2.2. The network- requested PDP context activation procedure allows the GGSN to initiate the activation of a PDP (Packet Data Protocol) context. When receiving a PDP PDU (Protocol Data Unit), the GGSN 4 checks if a PDP context is established for that PDP address. If no PDP context has been previously established, the GGSN 4 may try to deliver the PDP PDU by initiating the network-requested PDP context activation procedure. The criteria used by the GGSN to determine whether or not to try to deliver the PDP PDU to the MS 2 may be based on subscription information . To support network-requested PDP context activation, the GGSN 4 has to have static PDP information about the PDP address. To determine whether network-requested PDP context activation is supported for a PDP address, the GGSN 4 checks if there is static PDP information for that PDP address. Once these checks have been performed, the GGSN 4 may initiate the network- requested PDP context activation procedure. In the preferred embodiment of the invention, GGSN have no static info about the PDP address. It is using GGSN configuration and/or an APN configuration to determine if NRCA procedure should be attempted. APN configuration would mean NRCA is tried (or not) for all IP addresses belonging to APN. GGSN configuration would mean NRCA is tried (or not) for all IP addresses belonging to GGSN. The signalling and messages shown in Fig. 2 will be described below in greater detail. 1.) When receiving a PDP PDU, the GGSN 4 determines whether a network-requested PDP context activation procedure has to be initiated. The GGSN 4 starts a timer T (not shown) and may store subsequent PDP PDUs received for the same PDP address. 2.) The GGSN 4 sends a "send routing info for GPRS" message to the NRCA support node 5 (e.g. IGSN) which message may contain the information IMSI or the IP address or the logical name. Although not shown, the NRCA support node 5 may acknowledge the request of step 2.) by sending back a message to GGSN 4. In this case timer T may be started after the acknowledge is received. 3.) If the "old SGSN address" is present (if not present see step 5) in the memory 6 of NRCA support node 5, and either no "mobile station not reachable reason" information is present, or, if present, this information "mobile station not reachable reason" indicates "no paging response", the NRCA support node 5 will send a PDU notification request (indicating IMSI, PDP type, PDP address, access point name APN) message to the old SGSN address. 4.) If a MM (mobility management) context of the mobile station 2 is indicating "GPRS idle" or "UMTS PS detached", the SGSN 3 returns, in step 4.), a PDU notification response (cause) message to the NRCA support node 5, with' cause equal to "MS GPRS detached" The NRCA support node 5 sets the "MNRG" flag for that PDP address in its memory 6, and sends a failure report (IMSI, NRCA support node number) message to the HLR 7 to request MNRG to be set in the HLR 7, or "IMSI not known". If the SGSN 3 does not have information about that user, the SGSN 3 returns, in step 4.), a PDU notification response (cause) message to the NRCA support node 5, with cause equal to "IMSI not known" . The NRCA support node 5 then queries the HLR to request the address of the SGSN handling last the MS as in step 5. If SGSN has an active MM context, the cause indicated in the response of step 4.) represents "activation proceeds", and the SGSN 3 in this case moves to step 8.), that is sends a "request PDP context activation" message to the mobile station 2. 5.) The NRCA support node 5 sends a "MAP send routing info for GPRS" message to the HLR which message contains the information IMSI. The HLR returns the SGSN address to the NRCA support node . 6.) The NRCA support node 5 will send a PDU notification request (indicating IMSI, PDP type, PDP address, access point name APN) message to the SGSN address. 7.) If SGSN has an active MM context, the cause indicated in the response of step 4.) represents "activation proceeds", and the SGSN 3 in this case moves to step 8.), that is sends a "request PDP context activation" message to the mobile station 2. If the cause is "MS GPRS detached" or "IMSI not known", and if the SGSN 3 has an MM context for that user, the SGSN 3 sets MNRG to indicate the need to report to the HLR 7 when the next context with that MS 2 is performed. When the NRCA support node 5 receives, in step 4., a PDU notification response indicating that the request PDP context activation could not yet be sent to MS 2, the NRCA support node 5 may send a "send routing information for GPRS" message to the HLR 7 indicating the IMSI received in step 2 or derived from parameter received in step 2. This corresponds to step 5.). When the HLR 7 determines that the request can be served, it returns a "send routing information for GPRS Ack (IMSI, SGSN address, mobile station not reachable reason) " message to the NRCA support node 5. The "mobile station not reachable reason" parameter is included if the MNRG flag is set in the HLR 7. The "mobile station not reachable reason" parameter indicat'es the reason for the setting of the MNRG flag as stored in the MNRR (mobile station not reachable reason) record (see GSM 03.40). If the MNRR record shows reason other than "no paging response", the HLR 7 shall include the NRCA support node 5 number in the "GGSN-list" of the subscriber to which the mobile station 2 is assigned. (Here, the GGSN-list in fact contains the number of NRCA support node 5 instead of same of GGSN 4) . If the HLR 7 determines that the request can not be served (e.g., IMSI is unknown in HLR), the HLR 7 sends a "send routing information for GPRS Ack (IMSI, MAP error cause)" message back to NRCA support node 5. The information "MAP error cause" indicates the reason for the negative response. If the SGSN address is present in this response, and either "mobile station not reachable reason" is not present, or "mobile station not reachable reason" indicates "no paging response", the NRCA support node 5 will send, in step 6.), a "PDU notification request (IMSI, PDP type, PDP address, access point name APN)" message to the SGSN indicated by the HLR 7. Otherwise, the NRCA support node 5 shall set the MNRG flag for that MS 2. The SGSN 3 returns a "PDU notification response (cause)" message to the NRCA support node 5 in step 7.), in order to acknowledge that it shall request the MS 2 to activate the PDP context indicated with PDP address. The "PDU notification request" of step 6.) may also fail for the same reason as described with regard to step 3. In step 8.), the SGSN 3 sends a "request PDP context activation (TI, PDP type, PDP address, APN)" message to request the MS 2 to activate the indicated PDP context. In step 9.), the PDP context is activated with the PDP context activation procedure, as defined in the standards, see for instance section "PDP context activation procedure" of EN 301 344. In practice, the NRCA support node 5 containing the memory 6 may be an independent node, or may be integrated in a SGSN 3, an IGSN or another signalling gateway. A signalling gateway will be used for SS7 to IP conversion in a network organised according to 3GPP Release 2000. Implementing this feature in a signalling gateway is therefore one of the practical solutions. 1 Fig. 3 schematically illustrates the signalling between a gateway support node 4 and the HLR 7 effected via the support node 5. The signalling path shown in Fig. 3 allows the GGSN 4 or NRCA support node 5 to exchange signalling information with the HLR 7. According to Fig. 3, the memory device 6 is implemented in the NRCA support node 5. The function and structure of the memory device 6 is identical or similar to the above-described structure and functioning of the memory device 6. When several support nodes 5 are provided in the network 1 which are able to communicate with the HLR 7, each support node 5 is equipped with a memory device 6. As shown in Fig. 3, the support node 5 provides an interworking function which effects protocol conversion in particular in a case where no SS7 interface is installed in the gateway support node 4. In such a case, any GSN 5 having a SS7 interface installed in the same PLMN (public land mobile network) as the GGSN 4 can be used as a GTP-to-MAP protocol converter to allow signalling between the GGSN 4 and the HLR 7. Fig. 3 illustrates the GTP and MAP-based GGSN-HLR signalling, wherein the interworking function provides the interworking between the different protocol types GTP (GPRS tunnelling protocol) and MAP for the signalling between GGSN 4 and HLR 7. The MAP (Mobile Application Part) protocol is used between the NRCA support node 5 and the HLR 7. The signalling plane shown in Fig. 3 is standardised and is e.g. illustrated in European Standard EN 301 344 V6.3.2 (1999-07) of ETSI (European Telecommunications Standards Institute), section 5.6.2.7.2). TCAP means Transaction Capabilities Application Part. SCCP stands for Signalling Connection Control Part. MTP2 and MTP3 are abbreviations of message transfer part layer 2 and 3, respectively. LI stands for layer 1. Because of standardisation of the signalling exchange, this section will not be described in detail. In the embodiment shown in Fig. 3, the memory device 6 is provided in the GSN 5 so that only one memory device 6 may be installed in the network 1. Each GGSN 4 (or, if having the capability) , each SGSN 3 will communicate with the GSN 5 for accessing the HLR 7. In the present example, the subscriber information register storing information on one or more subscribers necessary for handling connections directed to subscribers, is implemented as a home location register. It may also have different structure and/or information contents. The invention can be implemented with regard to all subscriber information registers which have to be accessed when receiving requests such as network- requested PDP context activation procedures. Although the invention has been described above mainly by referring to a GPRS system, it may equally be applied to any , other packet-switched network, such as UMTS, or to any GSM network, or other networks.

Claims: CLAIMS 1. Communication system having at least one communication network to which a plurality of subscribers are attachable and which comprises at least one subscriber information register storing subscriber information including location information related to the subscribers, at least one gateway support node for handling connections to and/or from other networks, and at least one serving node for handling connections toward user equipment, comprising at least one network element, different from the gateway support node and subscriber information register, having a memory storing context related to at least one user equipment, said context containing: - address of said serving node presently or recently in charge of handling connections toward user equipment, and/or information on the user equipment reachability, and/or - logical name or subscriber identity to network address mapping, or network address to logical name or subscriber identity mapping. 2. Communication system according to claim 1, wherein the at least one network element is adapted to access the subscriber information register when information on one or more subscribers is necessary for handling connections directed to these subscribers. 3. Communication system according to any one of the preceding claims, wherein the at least one network element is an Interworking support node which is implemented as an independent support node, or as part of a Serving support node. 4. Communication system according to any one of the preceding claims, wherein the network is adapted to generate interrogation access requests for accessing the subscriber information register. 5. Communication system according to any one of the preceding claims, wherein the network element is a protocol-converting element. 6. Communication system according to any one of the preceding claims, wherein the network comprises at least one server for storing unique subscriber identifier information (IMSI) . 7. Communication system according to any one of the preceding claims, wherein the gateway support node(s) and the network element (s) are adapted to generate and/or receive messages containing an IP address instead of an IMSI (International Mobile Subscriber Information) of a subscriber, the network element containing or cooperating with a mapping indicating the correspondence between the IP addresses and the IMSI information. 8. Communication system according to any one of the preceding claims, wherein the gateway support node(s) and the network element (s) are adapted to generate and/or receive messages containing a logical name of a user instead of an IMSI (International Mobile Subscriber Information) thereof, the network element containing or cooperating with a mapping indicating the correspondence between the IP addresses and the IMSI information. 9. Communication system according to any one of the preceding claims, wherein the subscriber information register is a home location register. 10. Communication system according to any one of the preceding claims, wherein the subscriber identity to network address mapping is an IMSI to PDP address mapping. 11. Communication method for or in a system having at least one communication network to which a plurality of subscribers are attachable and which comprises at least one subscriber information register storing subscriber information including location information related to the subscribers, at least one gateway support node for handling communications to and/or from other networks, and at least one serving node for handling connections toward user equipment, comprising at least one network element, different from the gateway support node and subscriber information register, which stores context related to at least one user equipment, said context containing: - address of said serving node presently or recently in charge of handling connections toward user equipment, and/or - information on the user equipment reachability, and/or logical name or subscriber identity to network address mapping, or network address to logical name or subscriber identity mapping. 12. Communication method according to claim 11, wherein the network element accesses the subscriber information register when information on one or more subscribers is necessary for handling connections directed to these subscribers. 13. Communication method according to claim 11 or 12, wherein the at least one network element is an Interworking support node which is implemented as an independent support node, or as part of a Serving support node. 14. Communication method according to any one of the preceding claims 11 to 13, wherein the network is adapted to generate interrogation access requests for accessing the subscriber information register. 15. Communication method according to any one of the preceding claims 11 to 14, wherein the network element is adapted to perform a protocol-conversion. 16. Communication method according to any one of the preceding claims 11 to 15, wherein the network comprises at least one server for storing unique subscriber identifier information (IMSI) . 17. Communication method according to any one of the preceding claims 11 to 16, wherein the gateway support node(s) and the. network element (s) generate and/or receive messages containing an IP address instead of an IMSI (International Mobile Subscriber Information) of a subscriber, the network element containing or cooperating with a mapping indicating the correspondence between the IP addresses and the IMSI information. 18. Communication method according to any one of the preceding claims 11 to 17, wherein the gateway support node(s) and the network element (s) generate and/or receive messages containing a logical name of a user instead of an IMSI (International Mobile Subscriber Information) thereof, the network element containing or cooperating with a map indicating the correspondence between the IP addresses and the IMSI information. 19. Communication method according to any one of the preceding claims 11 to 18, wherein the subscriber information register is a home location register. 20. Communication method according to any one of the preceding claims 14 to 19, wherein the interrogation access requests are caused by network-requested PDP Context Activation requests (NRCA) . 21. Communication method according to any one of the preceding claims 11 to 20, wherein the subscriber identity to network address mapping is an IMSI to PDP address mapping. 22. Network element, in particular for use in a communication system as defined in any one of claims 1 to 10, or in a method as defined in any one of claims 11 to 21, said network element being different from a gateway support node or a subscriber information register, and having a memory storing context related to at least one user equipment, said context containing: - address of a serving node presently or recently in charge of handling connections toward user equipment, and/or information on the user equipment reachability, and/or logical name or subscriber identity to network address mapping, or network address to logical name or subscriber identity mapping. 23. Network element according to claim 22, being adapted to access the subscriber information register when information on one or more subscribers is necessary for handling connections directed to these subscribers. 24. Network element according to claim 22 or 23, wherein the network element is an Interworking support node which is implemented as an independent support node, or as part of a Serving support node. 25. Gateway node, in particular for use in a communication system as defined in any one of claims 1 to 10, or in a method as defined in any one of claims 11 to 21, said gateway node being adapted to send, when receiving an incoming packet for an inactive address, a message containing at least, said IP address, or logical name or subscriber identity, to another network element different from a subscriber information register which message requests the another network element to initiate a connection to a user equipment assigned to the address . 26. Gateway node according to claim 25, comprising or cooperating with a timer set to a defined time interval which timer is started when receiving an incoming packet for an inactive address, or when receiving an acknowledgment message from the another network element, the gateway node storing the packet and eventually also subsequently received packet or packets directed to the same address, as long as the timer is running . 27. Gateway node according to claim 26, wherein the gateway node is adapted to stop the timer when a connection is established between the gateway node and the user equipment to which the packet is directed. 28. Gateway node according to claim 25, 26, or 27, wherein the subscriber information register is a home location register. 29. Gateway node according to any one of claims 25 to 28, wherein the another network element is an Interworking support node which is implemented as an independent support node, or as part of a Serving support node. 30. Communication system, in particular as defined in any one of claims 1 to 10, and preferably comprising a gateway node as defined in any ' one of claims 26 to 29, comprising a DNS (Domain Name Server) which contains a mapping between logical names and IP addresses, the DNS being adapted to send a message containing logical name and/or subscriber identity informing the gateway node or another node when receiving a request to derive an IP address based on a logical name. 31. Communication system as defined in claim 30, the gateway node being adapted to update the DNS with the IP address allocated to the logical name when a connection is established between the gateway node and the user equipment to which the logical name is associated. 32. Communication system, in particular as defined in any one of claims 1 to 10, and preferably comprising a gateway node as defined in any one of claims 26 to 29, comprising name translation means which contains a mapping between logical names and addresses, the name translation means being adapted to send a message containing a logical name and/or a subscriber identity to the said gateway node when receiving a request to translate a logical name into an address. 33. Communication system as claimed in claim 32, wherein the said name translation means is a DNS (Domain Name Service) server. 34. Communication system as claimed in claim 32 or 33, wherein the said address is an IP address. 35. Communication system as claimed in claim 32, 33 or 34, wherein the said logical name is a domain name.

Inventors: HAUMONT SERGE, HAUMONT, SERGE
Applicants: HAUMONT SERGE, NOKIA CORP, HAUMONT, SERGE, NOKIA CORPORATION
Application year: 2000
Main classification: H04Q7
IPC codes: H04W8, H04W60