WO2009130389A1

WO2009130389A1 - Creating virtual mobile numbers in community networks

Info

Publication number: WO2009130389A1
Application number: PCT/FI2009/050320
Authority: WO
Inventors: Markku Rautiola; Matti Saarenpää
Original assignee: Concilio Networks Oy
Priority date: 2008-04-25
Filing date: 2009-04-24
Publication date: 2009-10-29
Also published as: FI20085378A0

Abstract

A method for making a client of a community network accessible by an identity of a public mobile telephone system, said a community network including a community network server and a plurality of community network clients. The community network is connected to a core network of a public mobile telephone system a gateway unit operating as a gateway between the core network and the community network and as a visitor location register towards the core network of the public mobile telephone system. The method comprises: allocating, in a visitor location register unit comprised by the gateway unit, MSISDN numbers to said community network clients lacking a valid identity in the public mobiletelephone system; and carrying out a location update procedure of said allocated MSISDN numbers towards a home location register of the public mobile telephone system, said location update procedure being in accordance with the procedures of the public mobile telephone system.

Description

CREATING VIRTUAL MOBILE NUMBERS IN COMMUNITY NETWORKS

Field of the invention

The present invention relates to community networks, and more particularly to creating virtual mobile numbers in community networks.

Background of the invention

A social network a.k.a. a community network is a social structure generally made of individuals or organizations that are tied by one or more specific types of interdependency, such as values, visions, idea, friends, or favored airline routes. Social networking focuses on the building and verifying of online social networks for communities of people who share interests and activities, or who are interested in exploring the interests and activities of others. It is mostly and primarily a web based service, and it provides a collection of various ways for users to interact, such as chat, messaging, email, video, voice chat, file sharing, blogging, discussion groups, and so on. In general, social networking services allow users to create a profile for themselves. Users can upload a picture of themselves and can often be 'friends' with other users. In most social networking services, both users must confirm that they are friends before they are linked, however, some social networking sites have a 'favorites' feature that does not need approval from the other user. Social networks usually have privacy control that allows the user to choose who can view their profile or contact them, etc.

People in their social networks primarily interact via communication media such as chat, voice chat, video, email, or blogging rather than face to face. Chat often refers to online chat in an internet chat room or instant messaging system. Instant messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not necessarily, short. Instant messages are often used in a conversational mode, wherein the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. Voice chat is a modern form of communication used on the instant messaging systems. The means of communicating with voice chat is through any of the messengers, mainly Yahoo! Messenger, AOL Instant Messenger or Windows Live Messenger. Voice chat has led to a significant increase in distant communications where two or more people from opposite ends of the world can talk almost free of cost. Voice chat systems use Voice over Internet Protocol (VoIP) protocol for the transmission of voice through the Internet or other packet switched networks. VoI P is often used a bstractly to refer to the actual transmission of voice rather than the protocol implementing it. VoIP is also known as IP Telephony and Internet telephony.

Presence information is a status indicator that conveys ability and willingness of a potential communication party to communicate. A user's client provides presence information (presence state) via a network connection to a presence service, which is stored in what constitutes his personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his availability for communication. Presence information has wide application in many communication services and is one of the innovations driving the popularity of instant messaging or recent implementations of voice over IP clients. A user client may publish a presence state to indicate its current communication status. This published state informs others who wish to contact the user of his availability and willingness to communicate.

People in social networking sites using instant messaging systems can be reached also from basic telephony networks, i.e. from PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network), by just calling them normally e.g. from a mobile handset. The call in this case is routed, for example, through the PLMN to the instant messaging system via an appropriate gateway which converts the PLMN call into an instant messaging session and vice versa. Addressing of a person in the instant messaging system is based on a telephone number because it is the only way to select the destination end point and route the call to that end point in a telecommunication network. However, in the present instant messaging systems addressing of the destination end point cannot be based on a real mobile number because the instant messaging system end points do not include any SIM cards. On the other hand, assigning SIM cards to each instant messaging system end point would be practically impossible due to the vast number of end points and to technical limitations in client devices.

Summary of the invention

Now there has been invented an improved telecommunication system, by which the drawbacks of the prior systems are alleviated. Various aspects of the invention include a method, a telecommunication system and a gateway element, which are characterized by what is stated in the independent claims. Various embodiments of the invention are disclosed in the dependent claims.

According to a first aspect, a method according to the invention is based on the idea of making a client of a community network accessible by an identity of a public mobile telephone system, said a community network including a community network server and a plurality of community network clients. The community network is connected to a core network of a public mobile telephone system a gateway unit operating as a gateway between the core network and the community network and as a visitor location register towards the core network of the public mobile telephone system. The method comprises: allocating, in a visitor location register unit comprised by the gateway unit, MSISDN numbers to said community network clients lacking a valid identity in the public mobile telephone system; and carrying out a location update procedure of said allocated MSISDN numbers towards a home location register of the public mobile telephone system, said location update procedure being in accordance with the procedures of the public mobile telephone system.

According to an embodiment, the method further comprises: allocating a particular MSISDN number to a particular community network client for the time said community network client remains present in the community network; and releasing said MSISDN number for reuse, when said community network client is no longer present in the community network.

According to an embodiment, the method further comprises: allocating the same MSISDN number for a plurality of community network clients, provided that a contact list of a single community network client does not include the same MSISDN number twice.

According to an embodiment, the community network is connected to a core network of a public mobile telephone system via a SIP network; the SIP network comprising a community gateway operating as a gateway between the SIP network and the community network; a roaming gateway operating as the visitor location register towards the core network of the public mobile telephone system; and a SIP server for providing SIP message-based communication between the roaming gateway and the community gateway.

The arrangement according to the invention provides significant advantages. Now an instant messaging system end point can be treated as a mobile handset/user, to which the mobile core network may route calls and short messages according to the GSM/UMTS procedures. The gateway arrangement according to the embodiments registers all allocated virtual MSISDNs to the home location register of the mobile core network, whereby the registration of the MSISDNs to the instant messaging system end points is made according to the known the location update procedure of the GSM. Since the HLR keeps the instant messaging system end points registered at all times, the HLR sees the instant messaging system end points as normal circuit switched GSM/UMTS users and e.g. terminating calls and text messages to these users are routed by normal GSM procedures to the gateway.

Further aspects of the invention include a telecommunication system and a gateway element arranged to operate in accordance with the above-described method. These and other aspects of the invention and the embodiments related thereto will become apparent in view of the detailed disclosure of the embodiments further below. List of drawings

In the following, various embodiments of the invention will be described in more detail with reference to the appended drawings, in which

Fig. 1 shows an overall view of the system according to a first embodiment of the invention;

Fig. 2 shows an overall view of the system according to a second embodiment of the invention;

Fig. 3 shows a signalling chart of a virtual mobile number allocating method according to a first embodiment of the invention; and

Fig. 4 shows a signalling chart of a virtual mobile number allocating method according to the second embodiment of the invention. Description of embodiments

The more specific structures, operations and functions of the embodiments of the overall system utilizing the invention is described for the part of the public mobile telephone network with terms, interfaces and protocols known from the GSM and the UMTS and specified by the 3GPP. For the part of the generic IP based multimedia network the operation is described with terms, interfaces and protocols specified by IETF.

In the overall system according to a first embodiment shown in Fig. 1 , a public land mobile network (PLMN) consists of a radio access network

(100) and a core network (101 ). In GSM, the core network (101 ) includes in turn core network elements (not shown) such as a mobile services switching center/visitor location register server (MSC/VLR), a home location register (HLR), an equipment identity register (EIR), and service and gateway nodes (SGSN and GGSN) of a packet radio network. The core network (101 ) provides basic telephony and supplementary services as well as data services for mobile stations (10), (11 ) and (12), which get access to those services using the services of radio access network (100). A community network (104) includes a community gateway (CGW) (2), an XMPP (Extensible Messaging and Presence Protocol) Server (5) and an XMPP Client (6). The CGW (2) constitutes now the gateway functionalities primarily applied in the following embodiments.

The CGW (2) represents core network's (101 ) VLR (20) towards the core network (101 ) for circuit-switched mobile network services used to make location updates to the core network's (101 ) HLR. In other words, the CGW registers all the instant messaging system end points allocated MSISDNs to the HLR of the mobile core network, keeping those registered at all times. This registration is made by the location update procedure of GSM exactly the same way as VMSC (VLR) makes it. Hence HLR sees the instant messaging system end points as normal circuit switched GSM/UMTS users and e.g. terminating calls and text messages to these users are routed by normal GSM procedures to the gateway solution. Thus, an instant messaging system end point may now be regarded as a mobile handset/user handled by the mobile core network which routes calls and short messages to the user according to the GSM/UMTS (or even CDMA) procedures. In those procedures GMSC asks from the HLR which is the address of the VMSC where the call should be routed. The location update need to be made only as often as the HLR requires the refreshment i.e. periodical location update. According to the made analysis, the HLR or other network elements do not perceive any special difference with the instant messaging system end point compared to a GSM user.

The CGW (2) also represents core network's (101 ) serving MSC (ServMSC) (21 ) towards the core network (101 ) for short message transfer in PLMN between SMSC (not shown) and the mobile stations (10), (1 1 ) and (12). The CGW (2) includes an ISUP/SIP GW (25), which communicates with core network (101 ) and PSTN network (102) telecom switches. It maps signaling from various telecom switches, e.g. ISUP signaling, to XMPP messages and controls media GWs (not shown) thus allowing the community network (104) and the core network (101 ) and PSTN (102) to be interconnected both on signaling and media streaming. The CGW (2) is aware of the presence information of the presentity because it includes the entity that manipulates this presence information. That entity is a presence user agent (PUA) (24) towards the XMPP Server (5) and may be, for example, a generic libjingle application acting as an XMPP Client (6) to the XMPP Server (5) services.

The XMPP Server (5) provides the community network (104) services such as presence, chat, voice chat and contact management services. Chatting and voice chatting are preferably provided using instant messaging, which offers real-time communication for short messages and voice and allows easy collaboration between parties, i.e. XMPP Clients (6).

In a system according to a second embodiment shown in Fig. 2, the system according to Fig. 1 has been extended with a SIP network, wherein the gateway functionalities described above are implemented. In practical applications, a SIP network-based implementation interconnecting the PLMN (101 ) and the community network (104) may provide advantages e.g. in client location update procedures and further by offering advanced telephony features. Accordingly, the SIP network (103) includes a roaming gateway (RGW) (1 ), the community gateway (CGW) (2), the telecommunication network gateway (ISUP/SIP GW) (3) and a SIP Server (4). The community network (104) includes the XMPP (Server (5) and the XMPP Client (6), but the community gateway (CGW) (2) is functionally implemented in the SIP network (103). The RGW (1 ) and the CGW (2) constitute now the gateway suite primarily applied in the following embodiments.

Now the RGW (1 ) represents core network's (101 ) VLR (20) towards the core network (101 ) for circuit-switched mobile network services used to make location updates to the core network's (101 ) HLR. Thus, now the RGW is the entity that registers all the instant messaging system end points allocated MSISDNs to the HLR of the mobile core network, keeping those registered at all times. The actual registration procedure is made in similar manner as described above, i.e. the same way as VMSC (VLR) makes it in the location update procedure of GSM.

The RGW (1 ) also represents core network's (101 ) serving MSC (ServMSC) (21 ) towards the core network (101 ) for short message transfer in PLMN between SMSC (not shown) and the mobile stations (10), (1 1 ) and (12). The RGW (1 ) includes also a SIP user agent (SIP UA) (22) functionality towards the SIP Server (4) in order to act as a client to the SIP Server (4) on the behalf of the MS (10), (11 ) and (12) and the MS's (10), (1 1 ) and (12) users, one SIP user agent instance for each mobile station. The SIP UA (22) includes also functionality to route the SIP registration and SIP session dialog to and from the SIP Server (4) as well as the downstream SIP session dialog creation request to the right ISUP/SIP GW (3) and further to the right destination core network (101 ) based on the location of the target mobile station (10), (11 ) or (12).

The CGW (2) includes a SIP UA functionality (23) towards the SIP Server (4) in order to act as a client to the SIP Server (4) and as a presence agent. The CGW (2) further includes the presence user agent (PUA) (24) for manipulating the presence information towards the XMPP Server (5) and for receiving the presence information from other presentites in the community network (104) through the XMPP Server (5).

The ISUP/SIP GW (3), now depicted as an element separate to the RGW and the CGW, communicates with core network (101 ) and PSTN network (102) telecom switches. It maps signaling from various telecom switches, e.g. ISUP signaling, to SIP messages and controls media GWs (not shown) thus allowing the SIP network (103) and the core network (101 ) and PSTN (102) to be interconnected both on signaling and media streaming.

The SIP Server (4) provides services for users, i.e. SIP UAs, of the SIP network (103). The SIP Server (4) is responsible for e.g. more advanced telephony features such as CLIP and CLIR, call forward on busy/no answer/unconditional, call hold/waiting, denied origination/- termination, find me/follow me, three-way calling, conferencing etc. The SIP Server (4) may also include a SIP registrar to keep track of the SIP UAs registered into the SIP network (103).

The XMPP Server (5) again provides the community network (104) services, but it should be noted that also the SIP Server (4) may provide presence, chat, voice chat and contact management services.

The presence service in the community network (104) is a service which accepts, stores and distributes presence information. The XMPP Client (6) provides its user's presence state via a network connection to the XMPP Server (5), which presence state is stored in what constitutes said user's personal availability record (called a presentity) and can be made available for distribution to other users (called watchers) to convey his/her availability for communication. The XMPP Client (6) may publish a presence state to indicate its current communication status. The most common use of the presence today is to display an indicator icon on instant messaging clients, typically from a choice of graphic symbol with an easy-to-convey meaning, and a list of corresponding text descriptions of each of the states. Common states on the user's availability are 'free', 'busy', 'away', 'do not disturb', 'out to lunch'. Such states exist in many variations across different modern instant messaging clients. Current standards support a rich choice of additional presence attributes that can be used for presence information, such as user mood, location, or free text status.

The analogy with free/busy tone on PSTN is inexact, as the 'on-hook' telephone status really shows the availability of network connectivity for reaching the called number, not really with the availability of the device or its user. But when we compare the scenario of only one line and can indicate availability and unavailability status (free/busy tone), the benefit for the calling party is very similar: They can decide if they want to start commu nication i n a d ifferent way (try usi ng another communication method or postpone the call). Presence goes insofar further as it allows to know, if the state is free or busy even before trying to begin a conversation.

Instant messaging allows instantaneous communication between a number of parties simultaneously, by transmitting information quickly and efficiently, featuring immediate receipt of acknowledgment or reply. In certain cases instant messaging involves additional features, which make it even more popular, i.e. to see the other party, e.g. by using web-cams, or to talk directly for free over the internet.

Contact management services in the following examples are based on the services provided by the community network (104) to the XMPP Clients (6). Those services may be provided by any suitable voice chat system. As is generally known, Rocket Messenger and AOL were among the first to offer voice chat facilities. Later Yahoo! Messenger became the most dominant voice chat service as it provided unique features. These included individual voice chat with another person, as well as conference call type voice chat facilities categorized in Yahoo! Rooms. Other well-known voice chat systems and services are Skype, YahoolVoice and Google Talk.

However, for the sake of illustration, the contact management services in the following examples are described as provided by Google Talk and Gmail. Google Talk is a Windows application for Voice over IP and instant messaging, offered by Google. Presence events and instant messaging between the Google Talk servers and its clients uses an open protocol, XMPP, allowing users of other XMPP clients to communicate with Google Talk users. VoIP in Google Talk is based around the Jingle protocol. However, the technology used within the Google server network is not publicly known. In order to be able to use Google Talk a Google (i.e. Gmail) account is needed for the service. When signing into Google Talk (and Gmail at the same time), user's Gmail contacts are preloaded into the Google Talk client. To add a Google Talk user to the contacts list, acceptance to a separate invitation is required from that Google Talk user. Google Talk contacts need to have mobile numbers (i.e. MSISDNs) defined in the contact information. In practice, adding of a mobile number to a contact needs to be done in the Gmail service, since it is impossible to give telephone numbers to the contacts in the Google Talk client. The Gmail can be launched directly from the Google Talk client, which is convenient also for the user because both Google Talk and Gmail share the same contacts and sign in to the Gmail account takes place simultaneously with the sign in to the Google Talk. When the user makes modifications to his/her Google Talk/Gmail contacts list, those changes will be retrieved from Google Talk/Gmail by the CGW (2). The used Google Talk server is in this example is the XMPP Server (5).

The CGW (2) retrieves and stores the Google Talk/Gmail contacts preferably in vCard format because ordinary mobile handsets' contacts applications typically support for importing and exporting contact data in vCard format. vCard defines a format for an electronic business card, which format is suitable as a personal data interchange format between applications or systems. vCard defined electronic business card forms now the profile for directory information for a white-pages person object. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g. formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). A user can set his/her availability status or customize a message that appears on the contacts list indicating his/her presence status. Presence status in turn conveys ability and willingness of a user to communicate with his/her contacts. However, vCard profile attributes do not include any attribute that would describe presence status or state of the particular object (i.e. the user) associated with the vCard.

Thus, the presence state of the user may be presented as a 'component' of the name of the user the vCard represents, and/or either in the telephone number's preferred type parameter value of the user the vCard represents or as an additional telephone number of the user, or in both ways. Said 'component' is preferably a string in the family or first name contact field of the vCard and shows now the presence state of the user. In the following, the operation of the gateway solution according to the embodiments is described more in detail by referring to the signaling charts of Fig. 3 and 4. The description of the operation is based on the terms and functions according to the 3GPP and IETF specifications.

According to the first embodiment, during the start-up, the VLR in the CGW makes the location updates (300) to the core network HLR for the telephone numbers, i.e. virtual mobile subscriber numbers, to be allocated to the community network contacts of the users of the core network. The VLR in the CGW makes the location updates for these virtual mobile subscriber numbers 'roleplaying' location updating procedure of a mobile station of the core network, however also without authentication and identification, because there are no SIM cards allocated for the virtual mobile service numbers and because a single virtual mobile subscriber number is not dedicated to a single user, i.e. one and the same virtual mobile subscriber number can be allocated to different contacts of different users. Location updates are done by the VLR in the CGW for all the virtual mobile subscriber numbers in the CGW database.

In the case, where a virtual mobile subscriber number is not a 'non- SIM' one but is, for example, a PSTN number, the VLR in the CGW shall not perform location update for that particular subscriber number.

Thus, now an instant messaging system end point is to be taken as a mobile handset/user handled by the mobile core network which routes calls and short messages to the user according to the GSM/UMTS procedures. The gateway solution according to the present invention registers all allocated virtual MSISDNs to the mobile core network HLR, keeping those registered at all times. This registration of the MSISDNs to the instant messaging system end points is made according to the known the location update procedure of the GSM. Hence the HLR sees the instant messaging system end points as normal circuit switched GSM/UMTS users and e.g. terminating calls and text messages to these users are routed by normal GSM procedures to the gateway solution. In those procedures GMSC asks from the HLR which is the address of the VMSC where the call should be sent. During the start-up, or whenever a user add a new contact to his/her community network contacts, or whenever the presence state of a contact of the user has changed, the PUA in the CGW retrieves (302) the community network contacts of the user with their presence states from the XMPP Server or updates (302) the user's own presence state to the XMPP Server. Presence state of the user to be updated by the PUA in the CGW is the default presence state of the user in his/her service profile. The PUA in the CGW creates (304) a new vCard for every new contact and updates the new presence states to the existing vCards, for example, as follows:

VCARD:BEGIN

VERSIONS.1 N:Lassila(Available on Google Talk);Ari;Ari

TEL;MOBILE:

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com

END:VCARD

VCARD:BEGIN VERSIONS.1

N:Oukka(away);Heikki;Heikki

TEL;MOBILE: 045 444 5555

EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi

END:VCARD

After that the PUA in the CGW informs (306) the VLR in the CGW of this. Upon receipt of the indication, the VLR in the CGW shall allocate

(308) the virtual mobile subscriber numbers for the new contacts of the user in concern and store them into the TEL contact field of the VCards, for example:

VCARD:BEGIN VERSIONS.1 N:Lassila(available);Ari;Ari TEL;MOBILE:045 333 4444

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com END:VCARD VCARD:BEGIN VERSIONS.1

N:Oukka(away);Heikki;Heikki TEL;MOBILE:045 444 5555 EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi END:VCARD

Allocated virtual mobile subscriber numbers are re-used so that e.g. only 1 ,000 telephone numbers are needed for e.g. 1 million users community. Each contact of a user must have a separate virtual mobile subscriber number, however, different contacts of different users may have the same virtual mobile subscriber numbers.

After this, the VLR in the CGW shall inform (310) the PUA in the CGW of the modified vCards. The PUA in the CGW needs the virtual mobile subscriber numbers in order to be able to route the calls and messages to the right contacts in the community network, and therefore the PUA stores (312) the updated information in the modified vCards. Incoming calls and messages to the same virtual mobile subscriber number are separated by the PUA in the CGW based on the calling/sending party, i.e. depending on the calling/sending party an incoming call/text message to the same virtual mobile subscriber number is routed to the different XMPP Client in the community network. Virtual mobile subscriber numbers may be normal E.164 numbers and may be stored into the mobile stations MS contacts databases preferably without country codes. Thus, unexpected expensive international mobile calls and text messages to community network contacts can advantageously be avoided, when roaming abroad.

As stated already, to add a Google Talk user to the contacts list, acceptance to a separate invitation is required from that Google Talk user. In the case, where that user is using his/her mobile station MS and not signed in to the community network from an XMPP client, the separate invitation is sent preferably as a text message to the mobile station MS. First the XMPP Server sends (314) the acceptance request to the PUA in the CGW, which informs (316) the ServMSC in the CGW of that. After that the ServMSC in the CGW shall send a text message (318) to the mobile station MS as the acceptance request. When the ServMSC in the CGW receives a text message (320) from the mobile station MS indicating e.g. acceptance from the user, it informs (322) the PUA in the CGW of that. The PUA in the CGW shall then send the acceptance (324) to the XMPP Server.

The presence state of a Google Talk user can be changed by the user from his/her mobile handset by sending a text message to the community network (104). When the text message is received by the ServMSC (21 ) in the CGW (2), it informs the PUA (24) in the CGW (2) of the presence state change. The PUA (24) in the CGW (2) shall then send the text string received in the text message to the XMPP Server (5) as a new presence state of the user in the community network (104).

According to the second embodiment, the same basic messages and actions are performed as in the first embodiment, but routing the communication via the SIP network creates some further steps to be carried out. Thus, during the start-up, the VLR in the RGW makes the location updates (400, 402) to the core network HLR for the telephone numbers, i.e. virtual mobile subscriber numbers, to be allocated to the community network contacts of the users of the core network and also to the SIP network. Again the VLR in the RGW makes the location updates for these virtual mobile subscriber numbers 'roleplaying' location updating procedure of a mobile station of the core network, either with or without authentication and identification, although there are no SIM cards allocated for the virtual mobile service numbers. Location updates are done by the VLR in the RGW for all the virtual mobile subscriber numbers in the RGW database.

In the case, where a virtual mobile subscriber number is not a 'non- SIM' one but is, for example, a PSTN number, the VLR in the RGW shall not perform location update for that particular subscriber number. The VLR in the RGW performs also the SIP UA registration (404) to the SIP Server on the behalf of the mobile stations MS using the RGWs own fully-qualified domain name (FQDN) as the contact address for the public identity to be registered to the SIP Server. The public identity to be registered in this case is the actual MSISDN of the user. This registration is done for all the actual MSISDNs in the RGW. The virtual mobile subscriber numbers are configured permanently to point to the CGW, they are not registered to the SIP Server at all.

During the start-up, or whenever a user add a new contact to his/her community network contacts, or whenever the presence state of a contact of the user has changed, the PUA in the CGW retrieves (406) the community network contacts of the user with their presence states from the XMPP Server or updates (406) the user's own presence state to the XMPP Server. Presence state of the user to be updated by the PUA in the CGW is the default presence state of the user in his/her service profile. The PUA in the CGW informs (408) the SIP UA in the CGW of the new contacts and changed presence states, and the SIP UA creates (410) a new vCard for every new contact and updates the new presence states to the existing vCards, for example, as described above:

VCARD:BEGIN VERSIONS.1

N:Lassila(Available on Google Talk);Ari;Ari

TEL;MOBILE:

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com

END:VCARD VCARD:BEGIN

VERSIONS.1

N:Oukka(away);Heikki;Heikki

TEL;MOBILE: 045 444 5555

EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi END:VCARD

After that the SIP UA in the CGW informs (412) the SIP UA in the RGW of this, which forwards (414) the indication to the VLR in the RGW. Upon receipt of the indication, the VLR in the RGW shall allocate (416) the virtual mobile subscriber numbers for the new contacts of the user in concern and store them into the TEL contact field of the VCards, for example as described above: VCARD:BEGIN VERSIONS.1 N:Lassila(available);Ari;Ari TEL;MOBILE:045 333 4444

EMAIL;TYPE=INTERNET:ari. lassila@concilionetworks.com END:VCARD VCARD:BEGIN VERSIONS.1 N:Oukka(away);Heikki;Heikki TEL;MOBILE:045 444 5555 EMAIL;TYPE=INTERNET:heikki.oukka@nethawk.fi END:VCARD

After this, the VLR in the RGW shall inform (418) the SIP UA in the RGW of the modified vCards, and the SIP UA in turn sends (420) the vCards to the SIP UA in the CGW. The SIP UA in the CGW needs the virtual mobile subscriber numbers in order to be able to route the calls and messages to the right contacts in the community network, and therefore the SIP UA stores (422) the updated information in the modified vCards. Incoming calls and messages to the same virtual mobile subscriber number are separated by the SIP UA in the CGW based on the calling/sending party, i.e. depending on the calling/sending party an incoming call/text message to the same virtual mobile subscriber number is routed to the different XMPP Client in the community network. Then a separate invitation to add a Google Talk user to the contacts list is sent preferably as a text message to the mobile station MS. First the XMPP Server sends (424) the acceptance request to the PUA in the CGW, which informs (426) the SIP UA in the CGW of that. The SIP UA in the CGW shall send the acceptance request (428) to the SIP UA in the RGW, which in turn informs (430) the ServMSC in the RGW of that. After that the ServMSC in the RGW shall send a text message (432) to the mobile station MS as the acceptance request. When the ServMSC in the RGW receives a text message (434) from the mobile station MS indicating e.g. acceptance from the user, it informs (436) the SIP UA in the RGW of that. The SIP UA in the RGW in turn sends a SIP MESSAGE (438) consisting of the received text message to the SIP UA in the CGW. Upon receipt of the SIP MESSAGE, the SIP UA in the CGW shall inform (440) the PUA in the CGW of the acceptance. The PUA in the CGW shall then send the acceptance (442) to the XMPP Server.

The community network (104) can be used also to make calls and send text messages to any foreign telephone number. For example, TringMe is a service, which uses Google Talk to provide telephone calls to any number worldwide. Another example is GTalk-to-VolP service, which makes the same as TringMe, but is however used a little bit different way. Common for both of these as well as for XMPP based community network (104) is that the foreign telephone number must be presented in the form of an XMPP client address and must be a member of an XMPP contact list of a user who intents to call or send a text message to that foreign telephone number.

A skilled man appreciates that any of the embodiments described above may be implemented as a combination with one or more of the other embodiments, unless there is explicitly or implicitly stated that certain embodiments are only alternatives to each other.

It is obvious that the present invention is not limited solely to the above- presented embodiments, but it can be modified within the scope of the appended claims.

Claims

Claims:

1. A method for making a client (6) of a community network (104) accessible by an identity of a public mobile telephone system, said a community network (104) including a community network server (5) and a plurality of community network clients (6), characterized in that the community network (104) is connected to a core network (101 ) of a public mobile telephone system a gateway unit (2) operating as a gateway between the core network (101 ) and the community network (104) and as a visitor location register towards the core network (101 ) of the public mobile telephone system; the method comprising allocating, in a visitor location register unit (20) comprised by the gateway unit(2), MSISDN numbers to said community network clients (6) lacking a valid identity in the public mobile telephone system; and carrying out a location update procedure of said allocated

MSISDN numbers towards a home location register of the public mobile telephone system, said location update procedure being in accordance with the procedures of the public mobile telephone system.

2. The method according to claim 1 , characterized by further comprising: allocating a particular MSISDN number to a particular community network client (6) for the time said community network client remains present in the community network; and releasing said MSISDN number for reuse, when said community network client is no longer present in the community network.

3. The method according to claim 1 or 2, characterized by further comprising: allocating the same MSISDN number for a plurality of community network clients (6), provided that a contact list of a single community network client does not include the same MSISDN number twice.

4. The method according to any of the claims 1 - 3, characterized in that the community network (104) is connected to a core network (101 ) of a public mobile telephone system via a SIP network (103); the SIP network (103) comprising a community gateway (2) operating as a gateway between the SIP network (103) and the community network (104); a roaming gateway (1 ) operating as the visitor location register towards the core network (101 ) of the public mobile telephone system; and a SIP server (4) for providing SIP message-based communication between the roaming gateway (1 ) and the community gateway (2).

5. A telecommunication system, comprising: a community network (104) including a community network server (5) and a plurality of community network clients (6); characterized in that the community network (1 04) is connected to a core network (101 ) of a public mobile telephone system via, a gateway unit (2) operating as a gateway between the core network (101 ) and the community network (104);; the gateway unit (2) further comprising a visitor location register unit (20) arranged to allocate MSISDN numbers to said community network clients (6) lacking a valid identity in the public mobile telephone system; and carry out a location update procedure of said allocated MSISDN numbers towards a home location register of the public mobile telephone system, said location update procedure being in accordance with the procedures of the public mobile telephone system..

6. The telecommunication system according to claim 5, characterized in that the visitor location register unit (20) is further arranged to allocate a particular MSISDN number to a particular community network client (6) for the time said community network client remains present in the community network; and release said MSISDN number for reuse, when said community network client is no longer present in the community network.

7. The telecommunication system according to claim 5 or 6, characterized in that the visitor location register unit (20) is further arranged to carry out the location update procedure for all MSISDN numbers present in its database.

8. The telecommunication system according to any of the claims 5 - 7, characterized in that the visitor location register unit (20) is further arranged to allocate the same MSISDN number for a plurality of community network clients (6), provided that a contact list of a single community network client does not include the same MSISDN number twice.

9. The telecommunication system according to any of the claims 5 - 8, characterized in the community network (104) is connected to a core network (101 ) of a public mobile telephone system via a SIP network

(103); the SIP network (103) comprising a community gateway (2) operating as a gateway between the SIP network (103) and the community network (104); a roaming gateway (1 ) operating as the visitor location register towards the core network (101 ) of the public mobile telephone system; and a SIP server (4) for providing SI P message-based communication between the roaming gateway (1 ) and the community gateway (2).

10. A gateway element arranged to interconnect a community network (104) and a core network (101 ) of a public mobile telephone system, characterized in that the gateway element (1 , 2) comprising a visitor location register unit (20) arranged to operate as a visitor location register towards the core network (101 ) of the public mobile telephone system; allocate MSISDN numbers to said community network clients (6) lacking a valid identity in the public mobile telephone system; and carry out a location update procedure of said allocated

MSISDN numbers towards a home location register of the public mobile telephone system, said location update procedure being in accordance with the procedures of the public mobile telephone system..

11. The gateway element according to claim 10, characterized in that the visitor location register unit (20) is further arranged to allocate a particular MSISDN number to a particular community network client (6) for the time said community network client remains present in the community network; and release said MS ISDN number for reuse, when said community network client is no longer present in the community network.

12. The gateway element according to claim 10 or 12, characterized in that the visitor location register unit (20) is further arranged to carry out the location update procedure for all MSISDN numbers present in its database.

13. The gateway element according to any of the claims 10

- 12, characterized in that the visitor location register unit (20) is further arranged to allocate the same MSISDN number for a plurality of community network clients (6), provided that a contact list of a single community network client does not include the same MSISDN number twice.