WO2009078769A1

WO2009078769A1 - Ims network location registry

Info

Publication number: WO2009078769A1
Application number: PCT/SE2007/051020
Authority: WO
Inventors: Johan Bolin; Carl Christer Boberg
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-12-18
Filing date: 2007-12-18
Publication date: 2009-06-25

Abstract

A new IMS NLR (Network Location Registry) -node (23) arranged to store information related to the one or more Access Networks (28a-c) to which an IMS user is attached, and the information can be used by a Location Server (22) in determining the geographic location of the IMS user. The stored information comprises the public identities, IMPUs, associated with the private identity of the IMS user, and the Access Networks associated with each IMPU, and in which the IMPU is explicitly registered.

Description

IMS Network Location Registry

TECHNICAL FIELD

The present invention relates to an IMS Network Location Registry-node and to a method in an IMS Network Location

Registry-node, as well as to a Location Server and a method in a Location Server of using information stored in said IMS Network Location Registry-node.

BACKGROUND

The IMS (Internet Protocol Multimedia Subsystem) of the 3GPP (3^rd Generation Partnership Project) enables an operator to deliver multimedia services to users based on IP (Internet Protocol) transport, independently of the access technology and of the type of user terminal. The conventional IMS architecture is illustrated in figure 1 and includes three main layers, i.e. an access layer, a session setup/control layer and a service layer, the continuous lines in the figure indicating signalling an the discontinuous indicating a media transport. The services in the service layer are access independent, and the core network, comprising a HSS (Home Subscriber Server) 14 and a CSCF (Call Session Control Function) 13, can be connected to several different access networks, both cellular and wire lined. The service layer comprises various applications, such as the IMS Location Server (LS) 11, which is capable of providing location information regarding an IMS user, e.g. for presence-enabled "buddy"-lists, yellow pages with local information, local charging tariffs, and emergency calls. Further, the PSTN (Public Switched Telephony Network) 15 is normally accessibly via a MGW (Media Gateway) 16 and a MGCF (Media Gateway Control Function) 12.

The SIP (Session Initiation Protocol) is the main signalling protocol for handling the packet switched session in an IMS network, and the SIP is capable of establishing, modifying and terminating multimedia session, such as voice, video and chat. The CSCF (Call Session Control Function) processes the SIP signalling and provides session control, including routing and monitoring of the SIP messages, interaction with the HSS and communication with the policy architecture, and the functions of the CSCF can be divided into Serving Call Session Control, S- CSCF, an Interrogating Call Session Control, I-CSCF and a Proxy Call Session Control P-CSCF.

Thus, the layered IMS system comprises application servers in the service layer, providing services, such as telephony, push- to-talk and group management. Further, the session- and the user management take place in the IMS core, comprising the HSS and the CSCFs, of which the CSCFs are managing the sessions between users and services. The P-CSCF is the entry point to the IMS, the P-CSCF routing the SIP signalling between a user and the users home network, and the S-CSCF handles the session setup between the users and the services. Additionally, the P-CSCF uses the I-CSCF to find the correct S-CSCF.

The above-mentioned HSS 14 (Home Subscriber Server) is a master database containing user and subscriber information supporting the network entities handling calls and sessions, providing e.g. identification, authorization, authentication, and mobility management, and when a user registers in the IMS domain, the user profile is downloaded from the HSS to the CSCF.

The HSS stores the user identities and user related information, such as the user service profile, and each user may have one or more user service profiles. One user may also have more than one public IMS identity, IMPU, and each service profile always has one default (root) IMPU. When a user registers in the IMS, i.e. switches on an IMS user terminal, plugs in an IMS IP telephone, or starts an IMS compatible client on a PC, the information relating to the access network will be stored in the HSS, and if the user changes access network, e.g. in a handover from a mobile network to a wireless LAN network, a re-registering is performed, which updates the information in the HSS.

However, the access independence of the services in the IMS is a disadvantage for a service that actually requires information from the lower access layer, e.g. a positioning service or a security-related service requiring information regarding the access networks to which a user is attached. A positioning service needs to know the access network to which a user is attached in order to determine the geographical location of the user by using a conventional positioning functionality of the access network, and the location information may be needed in several services, e.g. an emergency call service that is required to provide the geographical location of the caller. In emergency calls, the emergency caller's location is needed for enabling a connection of the phone call to the nearest emergency centre, and for enabling the emergency centre to guide e.g. an ambulance, fire department or the police to the caller.

In a mobile access network, the HLR (Home Location Registry) stores information regarding the registered users and the allocated MSC (Mobile Switching Centre) and the SGSN, from which an approximate geographical location of the caller may be determined, and in a conventional wire-line telephony, the caller may be located from the line number, i.e. the number of the physical connection (the copper wire) , and a database provisioned with corresponding street address.

However, in the IMS, the user may have several registered identities, e.g. IMPUs (IP Multimedia Public Identities), and each IMPU may be attached to more than one access network of different types. Consequently, a user may be simultaneously attached to more than one type of access networks, using different registered identities. Additionally, several different operators may be involved, and the operator owning the access network is often not the same as the operator of the IMS session management network, i.e. of the IMS Core. Therefore, it is a problem to provide services with reliable information regarding the access networks to which an IMS user is attached.

SUMMARY

The object of the present invention is to address the problem outlined above, ant this object and others are achieved by the IMS Network Location Registry, NLR, and the method in an IMS Network Location Registry, NLR, as well as to a Location server, according to the appended claims.

According to one aspect, the invention provides an IMS Network Location Registry-node arranged to store information related to the one or more Access Networks to which an IMS user is attached. Said stored information comprises one or more public identities, IMPUs, associated with the private identity of the IMS user, and one or more Access Networks associated with each IMPU, and in which the IMPU is explicitly registered.

Said stored information may further comprise contact information regarding the Position Determination System in each of said Access Networks in which said IMPUs are explicitly registered, time stamps for the registration events in each of the Access Networks, and implicitly registered IMPUs of the IMS user.

The information may be transferred from the S-CSCF-node using the 3^rd Party Register-function and the Subscribing to Event :reg- function, and information regarding the Access Networks may be included in the P-Access-Network-Info-header of the received 3^rd Party Register-messages. Information regarding the IMPU explicitly triggering a registration event may be included in the received Notify message of a Registration event.

The information may be adapted to be used by a Location Server in determining the geographic location of an IMS user, and the Network Location Registry-node may be co-located e.g. with a Location Server, with an HSS or with a Presence Server.

According to another aspect, the invention provides a Location Server arranged to determine the geographic location of an IMS- user by requesting and receiving information from a Network Location Registry-node, according to the first aspect of this invention .

According to another aspect, the invention provides a method of storing information in an IMS Network Location Registry-node, said information associating an IMS user with one or more IMPUs, and each IMPU with one or more Access Networks in which the IMPU is explicitly registered. The method comprises the following steps, which are performed by the IMS Network Location Registry- node via a node co-located with the NLR, e.g. a Location Server or a Presence Server:

- Receiving a Register-message indicating an Access Network and an IMPU associated with a service profile registered in said Access Network;

- Receiving a Notify-message indicating a Registration event and the IMPU explicitly triggering the event;

- Storing said IMPU explicitly triggering the Registration event associated with the IMS user, and storing said indicated Access Network associated with the IMPU.

The received Register message and said received Notify-message may be transferred from an S-CSCF-node, and the received Register message may be a 3^rd Party Register-message, in which the information is included in the P-Access-Network-Info-header, and the received Notify message may be a Subscribing to Event : reg-notification message.

The IMS Network Location Registry-node may further store contact information regarding the Position Determination System of the stored Access Networks, as well as time stamps associated with the registration events, and implicitly registered IMPUs.

According to still another aspect, the invention provides a method in an IMS Location Server of determining the geographic location of an IMS user from information stored in an IMS Network Location Registry-node. The IMS Location Server performs the following steps:

- Requesting information associated with the IMS user from the IMS Network Location Registry-node, said information comprising the IMPUs of the IMS user, and the Access Network in which each IMPU is explicitly registered;

- Receiving information from the IMS Network Location Registry- node associated with the one or more Access Networks in which each IMPU of the IMS user is explicitly registered, said information including contact information for the Position Determining System in each of said Access Networks;

- Requesting position information from each of the Position Determining Systems; - Calculating the geographic position of the IMS user from the received position information.

Further, the Location Server may request and receive time stamps associated with registering events from the IMS Network Location Registry-node, to be used in the step of calculating the geographic location of the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail, and with reference to the accompanying drawings, in which:

- Figure 1 is a block diagram illustrating a conventional IMS architecture,

- figure 2 is a block diagram illustrating an architecture comprising an NLR, according to this invention, - figures 3a-c show signalling diagrams illustrating storing of access network-information associated with a user terminal in the NLR,

- figure 4 is a block diagram illustrating the architecture of a Location Server utilising the information from a NLR to determine the geographical location of a user terminal,

- figures 5a-b show signalling diagrams illustrating a Location Server utilising the information from an NLR to determine the geographic location of a user terminal, and - figure 6 illustrates schematically an exemplary content in an IMS NLR (Network Location Registry) , according to this invention .

DETAILED DESCRIPTION In the following description, specific details are set forth, such as a particular architecture and sequences of steps in order to provide a thorough understanding of the present invention. However, it is apparent to a person skilled in the art that the present invention may be practised in other embodiments that may depart from these specific details.

Moreover, it is apparent that the described functions may be implemented using software functioning in conjunction with a programmed microprocessor or a general purpose computer, and/or using an application-specific integrated circuit. Where the invention is described in the form of a method, the invention may also be embodied in a computer program product, as well as in a system comprising a computer processor and a memory, wherein the memory in encoded with one or more programs that may perform the described functions.

The concept of the invention is to provide information regarding each of the access networks to which an IMS user is attached, since an IMS user may have several IMPUs (IP Multimedia Public Identities) , and each IMPU may be registered in more than one access network of different type. By providing information of each of the different access networks in which the user is explicitly registered, e.g. to a Location Server, the Location server will be able to determine the geographic location of the user by means of conventional access network positioning capabilities.

According to this invention, the access network information is provided in a new Network Location Registry-node, NLR, the information comprising the private identity (IMPI, IP Multimedia Private Identity) of a registered user, the explicitly and implicitly registered public identities (IMPUs) for each user, the different access networks in which each of the IMPUs are explicitly registered, and preferably the contact information of the Positioning Determination System in each access networks. This new NLR (Network Location Registry-node) may e.g. be located in a Presence Server, directly in the Location Server, or in the HSS, and the NLR is established and updated by combining data from the conventional 3^rd Party Register-function and the Subscribing to Event:reg function of the S-CSCF. Thereby, the Network Location Registry receives the P-Access-

Network-Info-header and the XML list with registered identities, in order to associate a private IMS user identity (IMPI) with one or more public IMS user identities (IMPUs), and to associate each IMPU with the one or more access networks in which the IMPU is explicitly registered.

Thus, a Network Location Registry according to this invention associates a private IMS user identity (IMPI) with the users one or more public IMS identities (IMPUs), and further associates each IMPU with the one or more access networks in which the IMPU is explicitly registered. Preferably, the Network Location Registry is also provided with the contact information for each access network, as well as with time stamps associated with Registration events, or with any other SIP traffic event, and in which access network the event occurred. Thereby, the NLR is able to indicate in which access network the user was last active, which will enable e.g. a Location Server to perform a more accurate determination of the geographical location of the IMS user.

Further, the SIP headers can be provided with additional information, e.g. with IP-layer information, such as NAT (Network Address Translation) -info, in the P-Access-Network- Info, or with the address of terminals, gateways or proxies in the call flow.

Figure 2 shows three exemplary access networks of different type, Access Network 1 (ANl) 28a, Access Network 2 (AN2) 28b, and Access Network 3 (AN3) 28c, for IMS user terminals of different type. A mobile telephone provided with an IMS client may be registered in the first access network, ANl, which is a cellular network, and the mobile phone has a PDP-Context and is connected to the P-CSCF via the packet network and an SGSN (Serving GPRS Support Node) and a GGSN (Gateway GPRS Support Node) . (The SGSN and the GGSN are not illustrated in the figure) . The second illustrated access network, AN2, is a

TISPAN-compliant IP network, to which an IP-Multimedia telephony client may be registered. The third illustrated access network, AN3, is an IP network without any CLF (Connectivity Session Location and Repository Function) , and the P-CSCF can add information regarding the address of the border gateway, typically an IP address. Further, figure 2 illustrates an HSS 24 containing user and subscriber information, and the CSCFs managing the sessions between users and services. The P-CSCF 27 is the entry point to the IMS, the S-CSCF 25 handles the session setup between the users and the services, and the I-CSCF is used by the P-CSCF to find the correct S-CSCF. Additionally, the figure shows an application server 21, a Location Server 22, as well as an IMS Network Location Registry, NLR, 23, according to this invention. In an IMS architecture, the IMS client terminal, i.e. the user terminal, as well as the P-CSCF knows in which access network a user terminal is registered. Since an IP-routmg/Metro network can be located between a local access network and the P-CSCF, the point-of-presence address used by P-CSCF may not be the IP- address of the user terminal, but instead the point-of-presence from the P-CSCF perspective. In addition to the location of a user experienced from the outside, the user terminal typically knows the network location within the local access network more accurately than only within which network it is. In a WLAN network, the user terminal normally knows the address of the network Access Point, but if the access network is a private network, the user terminal may normally not know the network location it appears to have from outside, e.g. the IP point-of- presence. However, the P-CSCF is able to identify which network the user (or session) is attached to via the BGW (Border Gateway) , and according to the SIP, the P-Access-Network-Info header field carries information of the access network, provided either by the user terminal itself or by the P-CSCF. According to the 3GPP, the P-Access-Network-Info header of a mobile network is provided by a user terminal from the Cell-id, and the Cell-id is a globally unique id, including an operator identifier, i.e. a CGI (Cell Global Identity) or a SAI (Service Area Identity) . In a non-3GPP access network, i.e. not a radio access network, the P-CSCF provides the P-Access-Network-Info- header with location related information, which may be e.g. a geographical address, or an address identifying the network.

Thus, the P-Access-Network-Info header field, comprising access network information, is normally included in the SIP messages between the client and the home S-CSCF. According to this invention, the 3^rd party register-function of the S-CSCF forwards the 3^rd party register messages to the application servers, and the 3^rd party register-messages are provided with the access network-info of the P-Access-Network-Info header for the creation and updating of the Network Location Register. Thereby, a Location server will be able to determine the geographical location of a user upon request by using the information stored in the Network Location Register. According to an alternative embodiment of this invention, the P-Access Network-Info is forwarded to the application servers in another suitable SIP message .

An IMS user may have several IMPUs for different services and contexts, and the user may also have several service profiles in order to differentiate the services that are available in the different contexts. When one IMPU is registered in an access network, other IMPUs within the same service profile may be registered implicitly, i.e. included in the same Implicit Register Set (IRS) . Thereby, a user may have several IMPU: s registered at the same time. Thus, in a converged IMS scenario, in which the IMS user has both mobile and wire line network connections, one of the IMPUs is a mobile phone number, i.e. an E-164 number, and when the IMS user registers from a fixed line connected device, e.g. a PC or even a mobile phone but connected via a WLAN, the E-164 IMPU will be registered implicitly, even if the mobile phone is not attached to the network.

The user contact information indicates the connection for routing the traffic to the user, and the IMPU and the user contact information are unrelated. Thus, a user may be registered with several IMPUs using only one connection, or with only on IMPU over several connections. The Register messages also include the user contact information in a Contact header, comprising an IP address indicating the point-of-presence of the user terminal, and this field is normally provided by the user terminal. However, the IP address may be a private IP address that is only useful within the local network. Alternatively, this field is provided by P-CSCF, e.g. by providing an address to a NAT (Network Address Translation) or a fire wall, together with additional information, such as port number or session id, from which the NAT or the fire wall will be able to obtain the IP address.

As described above, the new Network Location Registry, according to a preferred embodiment of this invention, is established and updated by means of 3^rd Party Register-messages forwarding information from the S-CSCF regarding in which access network a user is registered. However, an IMS-user may be registered in several access networks at the same time, and in order to provide a service with the current geographical location of an IMS user that is attached to more than one access network, the Location server has to select the most likely current location of the user, or the most feasible for the particular service or application. When the IMS user registers in an access network, the 3^rd Party Register-message will only include the user identity (IMPU) associated with the registered Service Profile, not specifically the explicitly registered IMPU. Hence, the Location server will not know if the IMPU associated with the registered service profile actually correspond to the explicitly registered IMPU, and not to an implicitly registered IMPU. In order to forward information to application servers, and to the Network Location Registry, regarding the explicitly registered IMPU, a preferred embodiment of this invention uses a Subscription to Registration events (Event: reg) in the S-CSCF. Thereby, the Notify message of a Registration event includes a list, such as en XML-list, comprising the registered user ID (IMPU) explicitly triggering the register event.

Thus, according to a preferred embodiment of this invention, the 3^rd Party Register-function of the S-CSCF provides a Location server, and thereby a new Network Location Registry co-located with the Location Server, with the P-Access-Network header- information comprising an attached access network, including the network location, and in some cases even a geographical location, and the Subscription to Registration event-function in the S-CSCF provides the Network Location Registry with the IMPU explicitly triggering the Registration event, thereby enabling creation and updating of the new IMS Network Location Registry.

The figures 3a-3c show signalling diagrams illustrating an exemplary scenario, in which a user first registers on a PC

(Personal Computer) , indicated by UE 1 in figure 3a, and later on a mobile phone, indicated by UE 2 in figure 3b, and the creation and updating of a Network Location Register, NLR, 37 according to this invention. In this embodiment, the NLR is co- located with the Location Server, and the updating of the NLR is performed by the Location Server.

In step Sl in figure 3a, the UEl 31a initiates a Registering procedure, the assumed user being located in the home network. In step S2, the P-CSCF 33 queries the CLF (Connectivity Session Location and Repository Function) of the Resource Controller to get location information, and in step S3, location information is returned to P-CSCF and provisioned in the P-Access-Network header. In step S4, a Register message is sent to the users home S-CSCF 34, via the I-CSCF. The Register message includes Contact info etc, and an Authentication is executed in step S5. In step S6, the Registration is performed in the HSS 35, and if the registration is successful, a Public UID (IMPU) is registered. In step S7, a user service profile of the IMPU is loaded from the HSS to the S-CSCF 34. (However, a private user Id may have several public user profiles) . In step S8, the 3^rd Party Register is sent from the S-CSCF 34 to the LS Location Server 36 forwarding the P-Access-Network-info, and the LS 36 sets up a Registration Event Subscription for user identities, in step S9, in order to receive more information of the user. Consequently, in step SlO, a Notify on RegEvent forwards the IMPU explicitly triggering the event, and a Feature Execution is performed in which previous steps are correlated and processed (not indicated in the figure) . Since the user was not registered before, the users IMPU tree structure gets registered in the Network

Location Registry 37 by the LS 36 in the NLR updating step SIl. In figure 3b, a user turns on a mobile terminal, indicated by UE 2, 31b, which performs a registration procedure, in step S12, and the P-Access-Network-Info includes the cell-id; e.g. utran- cell-id-3gpp=234151D0FCEll. In step S13, a Register message is sent to users home S-CSCF, via the I-CSCF, and the Register message includes Contact info. Since the user is already registered, and the same user profile is used in step S14, no additional service profile is loaded. In step 15, a 3^rd Party Register is sent to the LS 36, the 3^rd Party Register message including e.g. P-Access-Network-mfo and Contact info, and in step S16 a Notify on RegEvent is sent to the LS. In step S17, a Feature Execution is performed. Since the user is already registered, the user IMPU tree structure in the NLR 37 is updated by the LS 16 in step S18, and the tel-uri IMPU is flagged as explicitly registered, associated with a location.

In figure 3c, the user turns off the mobile terminal, i.e. UE 2, 31b, and a De-registration procedure is initiated, in step S19. A registration with "expires=0" is performed, which is forwarded to S-CSCF 34 by the P-CSCF 33 in step S20, and m step S21, the S-CSCF 34 sets the SIP registration timer to 0, i.e. a de- registration . The HSS 35 is informed, in step S22, that the user (UE 2) has de-registered the tel-uri IMPU, and the Location information in the S-CSCF is either cleared or stored. In step S23, a 3^rd Party Register with "expires=0" is sent to the LS, comprising the P-Access-Network-info and Contact info, together with a Notify on RegEvent, which is sent in step S24. In step S25 a Feature Execution is performed, and in step S26, the user IMPU tree structure in the NLR 37 is updated by the LS 36, and the tel-uri IMPU will be flagged as explicitly de-registered, and the location field is cleared.

The NLR, according to this invention, enables a Location server to determine an IMS users geographical location by using a conventional network-based or network-assisted positioning service of the access network, e.g. A-GPS. The service requesting the geographical location may be a commercial service, an emergency call centre making a dispatch location determination, a security service determining e.g. a lawful intercept, or as part of a process within the IMS network to manage charging or authorization. The entry point for a location request, e.g. an MLP (Mobile Location Protocol) -request or an SIP Subscribe, is the Location Server (LS), and the Location Server exposes a number of basic services providing Location information of a user to IMS and non-IMS applications, services and systems. The Network Location Registry (NLR) keeps a set of data for each user, e.g. structured as a tree structure, in order to associate the users private identity (IMPI) with one or more public identities (IMPUs), and with the access networks in which each of the IMPUs are explicitly registered. The geographic positioning of a user within one particular access network can be performed by a (conventional) positioning system or capability within the access network, which is hereinafter referred to as a Position Determination System (PDS) . The type of positioning system depends on the type of access network, and typically consists of a Mobile Positioning System in a 3GPP mobile network, a Mobile Positioning Centre/Position Determination Entity in CDMA networks, a CLF (Connection and session Location Repository) in a Tispan network or an Access Controller in a WiFi network.

The Network Location Registry, according to this invention, provides information regarding the access network to which user is attached, and regarding the explicit identity by which a user has been registered in the access network. Using the information regarding the access network (s) to which the user is attached, the Location Server is able to contact the Position Determination System, PDS, of the particular access network in order to obtain the geographic position of the user. If a user is explicitly registered in several access networks, suitable algorithms and procedures will be applied by the Location Server in order to determine the geographic location. Thereby, the access network information provided by the NLR, according to this invention, will enable a Location Server to calculate the geographic position of the user.

Figure 4 illustrates an exemplary architecture of a Location Server 41 utilising the information from an NLR 42 to determine the geographical location of a user terminal (not illustrated in the figure) . The NLR provides the Location Server with information regarding the access network 43, 44, 45 to which the user terminal is attached, as well as information of how to contact a conventional Position Determination System, PDS, of said access networks. Thereafter, the Location Server is able to determine the geographical location of the user terminal from the PDS in the access network to which the user terminal is attached.

The Network Location Registry, NLR, according to this invention, may be invoked e.g. in a Standard Location Immediate Reguest (SLIR) , an establishment of a Subscription, a Triggered

Notification or a Network Induced Location Request (NILR) , or in some other scenario.

The signalling diagrams 5a and 5b illustrates the role of the Network Location Registry 52 in an exemplary SLIR scenario, in which the Location Server 51 is queried with a request for a user location with a single immediate request. Since a user may be identified with several different public identities in the IMS, the response may be different depending on which user identity that is used in the request. Therefore, two different requests with different identifiers, belonging to two different Implicit Registry Sets (IRS), are illustrated in the figures 5a and 5b, respectively.

In the scenario illustrated in the signalling diagrams 5a and 5b, as well in the NLR illustrated in figure 6, the user Bob, having the private identity (IMPI) Bob.Baker.6501@Network.com, has one Personal Implicit Registry Set (IRSl) with three IMPUs, and one Professional Implicit Registry Set (IRS2) with two IMPUs. The user Bob is attached and registered with his mobile device to both a 3GPP Mobile Network, ANl, and to a Wireless

Local Area Network, AN2, and he is also registered on his office PC in a TISPAN Wireline Network, AN3. On the mobile device, Bob has explicitly registered both a Personal and a Professional identity, but he has only explicitly registered a Professional identity on the PC. The not explicitly identities within the same IRS are registered implicitly.

In step Sl in figure 5a, the location of the Personal identity IMPU Bob.Baker@Network.com is requested by a querying entity sending a Subscribe with Exp=0 to the Location Server 51, the Subscribe including the requested QoS. In step S2, an internal processing regarding e.g. privacy and policies is performed. In step S3, a Network Location Registry, NLR, 52, according to this invention, is queried by the Location Server to obtain information regarding in which access networks

Bob.Baker@Network.com can be found. In step S4, the response to the query informs the Location Server that Bob.Baker@Network.com is attached to two different access networks, and provides the contact information to the PDS in those two networks. The first network, ANl, is a 3GPP Mobile Network, the second network, AN2 , being a Wireless LAN 802. Hg. In step S5, internal processing is performed to decide in which of the access networks to perform the conventional positioning. In this example, the Location server chooses to perform a positioning in both access networks, and this step may also include a mapping of the IMS Identity to a domain identity, such as an IP address or MSISDN (Mobile Subscriber ISDN) , that is the user key for the PDS serving the domain. In step S6, the PDSl is queried to determine the user position within access network 1, and a Response from PDSl is received in step S7. In step S8, the PDS2 is queried to determine the user position within access network 2, and in step S9, a Response is received from PDS2. In step SlO, the Location Server 52 performs an internal positioning calculating procedure, e.g. if the two responses differ, or regarding the encoding of location format. The information from the NLR may also be used when composing the answer, to highlight if some identities are explicitly registered in one or multiple networks. In step SIl, the result is forwarded from the Location Server 52 to the gueering entity.

In figure 5b, the location of the Professional Identity IMPU

Bob.Baker@Company.com is requested by sending a Subscribe with Exp=0 to the Location Server 51. The Subscribe includes the requested QoS in step Sl, and in step S2 an internal processing regarding e.g. Privacy and Policies are performed. In step S3, the NLR 52 is queried to get information of in which networks to find Bob.Baker@Company.com. In step S4, the response tells the LS that Bob.Baker@Network.com is attached to three access networks, as well as the contact information to the PDS in those three networks, the 3GPP Mobile Network, ANl, the Wireless LAN 802. Hg, AN2, and the TISPAN Wireline Broad Band, AN3. In step S5, Internal Processing is performed by the Location Server to decide in which network to use of the positioning. In this example the Location Server chooses to perform positioning in all the networks. This step may also include mapping the IMS Identity to a domain identity such as an IP address or MSISDN that is the user key for the PDS serving the domain. In step S6, the PDSl is queried to determine the users position within the first access network, ANl, and in step S7, a response is received from PDSl. In step S8, the PDS2 is queried to determine the users position within the second access network, AN2, and in step S9, a response is received from PDS2. In step SlO, the PDS2 is queried to determine the users position within the third access network, AN3, and in step SH a response is received from PDS3. In step S12, an internal positioning calculating procedure is performed by the Location Server, e.g. if the three responses differ or regarding encoding of location format. The information from the NLR may also be used when composing the answer, to highlight if some identities are explicitly registered in one or multiple networks. In step S13, the result from the Location Server 51 is forwarded to the querying entity.

Figure 6 illustrates an exemplary embodiment of the NLR structure for the Bob Baker-record, indicating his Private ID (IMPI) in the first column 61, the Implicitly Registry Set in the second column 62, the associated Public IDs, IMPUs, in the third column 63, and in which access network each IMPU is explicitly registered in the fourth column 64. In the fifth column 65, time stamps is provided to indicated the point of time of the events, and this information is advantageously used e.g. by a Location Server to determine the geographical position of a user that is explicitly registered in more than one access network. The contact information regarding the Position Determination Systems in each of the Access Networks indicated in column 64 is preferably also included in the NLR, and associated with the Access Network.

While the invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention.

ABBREVIATIONS

HSS: Home Subscriber Server

MGW: Media Gateway

MGCF: Media Gateway Control Function SIP: Session Initiation Protocol

CSCF: Call Session Control Function PSTN: Public Switched Telephony Network IMS: Internet Protocol Multimedia Subsystem HLR: Home Location Registry MSC: Mobile Switching Centre

SGSN: Serving GPRS Support Node GGSN: Gateway GPRS Support Node IMPU: IP Multimedia Public Identity IMPI: IP Multimedia Private Identity

NLR Network Location Registry CGI Cell Global Identity SAI Service Area Identity IRS Implicit Registry Set CLF Connectivity Session Location and Repository Function NAT Network Address Translation

Claims

1. An IMS Network Location Registry-node arranged to store information related to the one or more Access Networks to which an IMS user is attached, characterized in that said stored information comprises:

- one or more public identities, IMPUs, associated with the private identity of the IMS user;

- one or more Access Networks associated with each IMPU, and in which the IMPU is explicitly registered.

2. IMS Network Location Registry-node according to claim 1, wherein said stored information further comprises contact information regarding the Position Determination System in each of said Access Networks in which said IMPUs are explicitly registered.

3. An IMS Network Location Registry-node according to any of the preceding claims, wherein said information further comprises time stamps for the registration events in each of the Access Networks.

4. An IMS Network Location Registry-node according to any of the preceding claims, wherein said information further comprises implicitly registered IMPUs of the IMS user.

5. An IMS Network Location Registry-node according to any of the preceding claims, wherein said information is transferred from the S-CSCF-node using the 3^rd Party Register-function and the Subscribing to Event : reg- function .

6. An IMS Network Location Registry-node according to claim 5, wherein information regarding the Access Networks is included in the P-Access-Network-Info-header of the received 3^rd Party Register-messages.

7. An IMS Network Location Registry-node according to claim 5 or 6, wherein information regarding the IMPU explicitly triggering a registration event is included in the received Notify message of a Registration event.

8. An IMS Network Location Registry-node according to any of the preceding claims, wherein said information is adapted to be used by a Location Server in determining the geographic location of an IMS user.

9. An IMS Network Location Registry-node according to any of the preceding claims, wherein said node is co-located with a Location Server.

10. An IMS Network Location Registry-node according to any of the preceding claims, wherein said node is co-located with an HSS.

11. An IMS Network Location Registry-node according to any of the preceding claims, wherein said node is co-located with a Presence Server.

12. A Location Server-node arranged to determine the geographic location of an IMS-user by requesting and receiving information from a Network Location Registry- node, according to any of the preceding claims.

13. A method of storing information in an IMS Network Location Registry-node, said information associating an

IMS user with one or more IMPUs, and each IMPU with one or more Access Networks in which the IMPU is explicitly registered, the method characterized by the IMS Network Location Registry-node performing the steps of: - Receiving a Register-message indicating an Access Network and an IMPU associated with a service profile registered in said Access Network;

14. A method according to claim 13, in which the steps of receiving and storing are performed via a Location Server- node co-located with the Network Location Registry-node.

15. A method according to claim 13 or 14, wherein said received Register message and said received Notify-message are transferred from an S-CSCF-node.

16. A method according to any of the claims 13 - 15, wherein said received Register message is a 3^rd Party Register-message, in which the information is included in the P-Access-Network-Info-header .

17. A method according to any of the claims 13 - 16, wherein said received Notify message is a Subscribing to Event : reg-notification message.

18. A method according to any of the claims 13 - 17, wherein the IMS Network Location Registry-node further stores contact information regarding the Position Determination System of the stored Access Networks.

19. A method according to any of the claims 13 - 18, wherein the IMS Network Location Registry-node further stores time stamps associated with the registration events.

20. A method according to any of the claims 13 - 19, wherein the IMS Network Location Registry-node further stores implicitly registered IMPUs.

21. A method in an IMS Location Server of determining the geographic location of an IMS user from information stored m an IMS Network Location Registry-node, according to any of the claims 1 - 12, the method characterized by the IMS Location Server performing the following steps: - Requesting information associated with the IMS user from the IMS Network Location Registry-node, said information comprising the IMPUs of the IMS user, and the Access Network in which each IMPU is explicitly registered; - Receiving information from the IMS Network Location Registry-node associated with the one or more Access Networks in which each IMPU of the IMS user is explicitly registered, said information including contact information for the Position Determining System in each of said Access Networks;

Requesting position information from each of the Position Determining Systems;

Calculating the geographic position of the IMS user from the received position information.

22. A method according to claim 21, wherein the Location Server requests and receives time stamps associated with registering events from the IMS Network Location Registry- node, to be used in the step of calculating the geographic location of the user.