Method and apparatus for configuring service settings for a mobile subscriber

A method for configuring service settings for a mobile subscriber in a mobile communication network wherein the mobile subscriber is associated with a first instant communication client which is adapted to communicate via an instant messaging protocol with an instant communication server, and wherein the instant communication server is associated to a mobile switching center of the mobile communication network. The method includes: sending, by the first instant communication client, an instant service command via the instant communication server to a second instant communication client, associated with the mobile switching center; converting, by the mobile switching center, the instant service command into a service setting message; and sending the service setting message to a user database to modify service settings for the mobile subscriber.

CROSS REFERENCE TO RELATED APPLICATION

This application is a 35 U.S.C. §371 national stage application of PCT International Application No. PCT/EP2011/0662889, filed on 20 Sep. 2011, the disclosure and content of which is incorporated by reference herein in its entirety. The above-referenced PCT International Application was published in the English language as International Publication No. WO 2013/041125 A1 on 28 Mar. 2013.

TECHNICAL FIELD

The present invention relates to a method for configuring service settings for a mobile subscriber in a mobile communication network wherein the mobile subscriber is associated with a first instant communication client which is adapted to communicate via an instant messaging protocol with an instant communication server, and wherein the instant communication server is associated to a mobile switching center of the mobile communication network. Further the invention is about a mobile switching center which is adapted to perform the method.

BACKGROUND

The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language (XML) protocol for near-real-time messaging, presence, and request-response services. These services are also named as instant messaging services. The core features of the XMPP are defined in the IETF standard RFC 3920. The basic syntax and semantics were developed originally within the Jabber open-source community. Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a TCP connection, and servers also communicate with each other over TCP connections. Being an open standard, XMPP has got quite attraction in the open source community world wide and numerous free software packages exist implementing XMPP clients and XMPP server on different platforms. Some companies are basing their chat and voice offerings on XMPP specifications.FIG. 1shows a schematic diagram of a mobile communication network which is connected to a TCP/IP-based network100, which can be the Internet or any other TCP/IP based network. In this embodiment, three XMPP servers111,121,131are connected to the Internet100. Two XMPP clients112,122are associated to two of the XMPP server111,121via a TCP/IP connection. The XMPP clients112,122can e.g. be a personal computer or a laptop which are connected to the internet100via a normal dial-connection. As an example the address113of the first XMPP client112“client1” is “client1@XMPPserver1.domain/device1” wherein the address123of the second XMPP client122is “client2@XMPPserver2.domain/device2”. InFIG. 1and inFIG. 4, the addresses113,123,133are disclosed in a simplified form because the domain indicator and the device indicator are missing for better view. These addresses are in accordance with the standardized XMPP JID (Jabber identity) which is a combination of a user ID, a server ID and a device ID. By these addresses113,123,133all XMPP clients112,122,1can be identified and data can be routed via the internet.FIG. 1further discloses a mobile communication network, wherein only selected components of the mobile communication network are depicted. A mobile terminal or user equipment18comprises a XMPP client1. The XMPP client1can be an application which is stored in the UE18. The XMPP client1can be associated to a XMPP server131e.g. via a TCP-based connection. As an example the address133of the XMPP client1is “client3@XMPPserver3.domain/UEdevice”. This connection can be realized by a wireless LAN connection, wherein the UE18is associated to a WLAN router19which is further connected to the Internet100. Another possibility is that the UE18is connected via the radio network17to a packet switched (PS) network or to an evolved packet switched (EPS) network. One setup of a PS network is depicted inFIG. 1by a Serving GPRS Support Node (SGSN) node15and Gateway GPRS Support Node (GGSN)16which is linked via an IP based core network connection and via the Internet100to the XMPP server131. The embodiment accordingFIG. 1further discloses a connection between the SGSN node15of a packet switched network and a mobile switching node14, which can be a MSC-S node14of a circuit switched (CS) network. This link between both nodes, which is called Gs interface, depicts the possibility of transferring data between both networks. A further packet switched network is the Evolved Packet Core (EPC) network, wherein one node is the Mobility Management Entity (MME), which can be linked to the MSC-S via a SGs interface.FIG. 1does not depict further gateway nodes which might be necessary to implement a connection between a circuit-switched network and a packet switched network.

FIG. 2shows a block diagram of a prior-art mobile switching node14, which is in this embodiment a MSC-S node14, wherein only selected parts are depicted. The MSC-S14comprises a GSM call control function143which contains mobile traffic coordinators for originating and/or terminating calls and emergency calls. The coordinators are mainly used for call transaction setup, call forwarding, call supervision and call release. It allows also to direct and to handle calls towards other circuit switched networks. The GSM call control function143is linked with the core network interface145which hosts the core network interfaces of the MSC-S. The core network interface145analyses incoming signalling which is either forwarded to another node in the core network or handled locally and terminated at a radio network interface. For outgoing signalling a routing function146is consulted to determine the next destination node and the physical interface to reach it. The core network interface145is IP (Internet Protocol) based. The GSM call control function143is further connected to a GSM mobility function142which allows the mobile terminal to roam between radio location areas and to continue ongoing calls also across radio network borders. One main function is the handover procedure to hand over a mobile terminal from one area to another. The GSM mobility function142or mobility management function therefore contains a logic coordinator for mobility, roaming and handover procedures and handles the location updating functions and handover functions. Furthermore the GSM mobility function142contains functions for packing or unpacking of signalling messages to the terminal and to the radio network belonging to mobility. Signalling messages can be used e.g. in case of authentication, identification and location updating.

The GSM mobility function142is connected to the A-/lu-interface function141which hosts the radio network interface resources of the MSC-S14. The MSC-S14further comprises a charging function144which is connected to the GSM call control function143and the core network interface145. The charging function144is a basic function in the MSC-S14to collect traffic case related data to be used for offline billing.

The MSC-S14further comprises a VLR data storage147which stores the subscriber data. The VLR147is connected via an interface6to a home location register4(HLR) which is a central database that contains details of each mobile phone subscriber that is authorized to use the core network.

The MSC-S further comprises a GSM authentication component148which implements the GSM authentication algorithm. The GSM authentication component148is also connected via the interface6to the HLR4to receive and verify authentication data from the central database.

FIG. 3depicts a block diagram of a well known XMPP server131. The XMPP server131contains a XMPP stanzas router1311which is the backbone of the XMPP server131. The XMPP stanzas router1311accepts connections from XMPP server components and passes XML (extended markup language) packets between XMPP server components. A client to server component (c2s)1312handles communication with associated XMPP clients. The XMPP stanzas router1311is connected to a XMPP session manager1316. The session manager1316implements the bulk of the instant messaging features like message passing, presence, roster and subscription. The session manager1316is connected to data storage in order to provide persistent data storage. The associated data storage is not depicted inFIG. 3. It could be located outside the XMPP server131or it could be part of the XMPP server131. Additionally the session manager1316handles the XMPP extensions of service discovery and privacy lists. A c2s component1312is connected to the XMPP stanzas router1311and is e.g. responsible for connecting XMPP clients112,122,1to the XMPP server131, passing communication packets to a session manager1316of the XMPP server131, authenticating XMPP clients112,122,1, registering users and triggers activity with the session manager1316. A server to server (s2s) component1315is connected to the XMPP stanzas router1311and handles communications with external XMPP servers by passing communication packets between other internal components and external servers. The s2s component1315further performs dial-back function to authenticate remote XMPP servers. A multi user chat (muc)1314is connected to the XMPP stanzas router1311to implement support for chat rooms. A publish subscribe component (pubsub)1313implements a generic functionality for providing presence. The pubsub component1313is connected to the Stanzas router1311. The XMPP server131is connected via a TCP/IP connection to the Internet100such that it possible to reach this server from any other device connected to the Internet100. The s2s component1315and the c2s component1312communicate via the Internet100with external clients112,122,1and external server111,121.

If a mobile subscriber of a mobile terminal wants to change service settings in the mobile communication network, like call forwarding or call barring he has to use a mobile terminal to send commands to the MSC-S which afterwards set-up the settings in the user database. If the user does not have a 2G/3G mobile terminal available he cannot change the service settings even if the user is equipped with an XMPP client1. XMPP technology includes several technologies used to send commands from one XMPP client to another XMPP client. With these commands it is possible to remote control other XMPP clients which are associated with the same user. One technology is the ad-hoc command protocol as defined in the XMPP extension protocol standard XEP-0050. This XMPP extension provides workflow capabilities that can be used for any structured interaction between two XMPP entities.

SUMMARY

It is an object of the present invention to provide above described instant messaging services to configure services in a mobile communication network. This object is achieved by the independent claims. Advantageous embodiments are described in the dependent claims.

According to one aspect this object is achieved by a method for configuring service settings for a mobile subscriber in a mobile communication network wherein the mobile subscriber is associated with a first instant communication client. The instant communication client is adapted to communicate via an instant messaging protocol with an instant communication server, and wherein the instant communication server is associated to a mobile switching center of the mobile communication network. The method comprises the step of sending, by the first instant communication client, an instant service command via the instant communication server to a second instant communication client, associated with the mobile switching center. Further the method comprises the step of converting, by the mobile switching center, the instant service command into a service setting message and to send the service setting message to a user database to modify service settings for the mobile subscriber. With this method it is possible for a subscriber of a mobile communication service to manage mobile communication services, like call forwarding or call barring, with an instant communication client without using a mobile phone device.

In a further embodiment of the invention the second instant communication client is assigned to the mobile subscriber.

In a further embodiment the second instant communication client is established and registered at the instant communication server after the first instant communication client has been registered at the instant communication server. The mobile switching center is able to handle the establishment and cancellation of the second instant communication client flexible according to the amount of remaining memory.

In a further embodiment the second instant communication client is established by obtaining mobile subscriber data from the user database. No manual input is needed from an operator.

In a further embodiment the first instant communication client queries a list of supported instant service commands from the second instant communication client and sending the instant service command only if the instant service command is in the list of supported instant service commands. This will prevent the use of ad-hoc commands which are not supported by the second communication client or the user database. Sending non-supported ad-hoc commands can cause additional network traffic.

In a further embodiment a service setting message is automatically sent to the user database to activate a call forwarding service to the first instant communication client if the first instant communication client has been registered at the instant communication server, or to deactivate a call forwarding service to the first instant communication client if the registration of the first instant communication client at the instant communication server has been canceled.

In a further embodiment the mobile switching center queries the number of the visitor location register, VLR, of a second mobile switching center which serves the mobile subscriber from the user database and using the queried VLR number when converting the instant service command into a service setting message.

The object is further achieved by a mobile switching center, comprising an instant communication server, adapted to receive an instant service command from a first instant communication client and to route the instant service command to a second instant communication client. The instant communication server can be a part of software which has been installed in the memory of the mobile switching center. The instant communication server could also be a hardware module in the mobile switching center which is connected to other hardware modules of the mobile switching center. The mobile switching center further comprises a second instant communication client, adapted to receive the instant service command and forward the instant service command to a converter if the instant service command is for setting up a service in a user database. The second instant communication client can be a virtual instance or a bot which is established in the memory of the mobile switching center.

Further the mobile switching center comprises a converter, adapted to receive the instant service command from the second instant communication client, to convert the instant service command into a service setting message, and to send the converted service setting command to a user database. The converter can be realized in a processing unit.

The mobile switching center can be further adapted to perform all the steps of the prescribed methods

The present invention also concerns computer programs comprising portions of software codes in order to implement the method as described above when operated by a respective processing unit of a user device and a recipient device. The computer program can be stored on a computer-readable medium. The computer-readable medium can be a permanent or rewritable memory within the user device or the recipient device or located externally. The respective computer program can also be transferred to the user device or recipient device for example via a cable or a wireless link as a sequence of signals.

In the following, detailed embodiments of the present invention shall be described in order to give the skilled person a full and complete understanding. However, these embodiments are illustrative and not intended to be limiting.

DETAILED DESCRIPTION

FIG. 4depicts one embodiment of the invention. A XMPP server3is associated to the MSC-S2of a mobile communication network which can also be understood as a MSC/VLR. It is possible that the XMPP server3is an integral part of the MSC-S2. Therefore the MSC-S2is enhanced by the XMPP server3. The XMPP server3can also be a server node which is logically associated to the MSC-S2to use at least some of the MSC-S functions. The embodiment accordingFIG. 4further discloses a Gs-connection between the SGSN node15of a packet switched network and the MSC node2of a circuit switched network. This link between both nodes depicts the possibility of transferring data between both mobile networks.FIG. 4does not depict further gateway nodes which might be necessary to implement a connection between a circuit-switched network and a packet switched network. Another alternative for a packet switched network is the EPC network which comprises a MME. The MME is connected via a SGs interface to the MSC-S2.

FIG. 5depicts one embodiment of a MSC-S2with an integrated XMPP server3according to one aspect of the invention. The XMPP server3can be a separate module which is inserted as a hardware component into the MSC-S hardware. The XMPP server3could be a separate plug-in-card which can be inserted into a rack which comprises among others several MSC-S plug-in-cards. Another possibility is that the XMPP server3is an instance running in the memory of the MSC-S2as an application or procedure. The XMPP server3is logically associated to the MSC-S2. In the embodiment ofFIG. 5the XMPP stanzas router35of the XMPP server3is connected to the GSM call control function23of the MSC-S for XMPP-CS interworking to perform the conversion between the XMPP protocol and the CS protocol at breakout. Further the XMPP session manager34of the XMPP server3is connected to the charging function24of the MSC-S2to add XMPP related data to the charging information. E.g. when the session manager34reports information about a chat session to the charging function of the MSC-S2the operator of this mobile network is able to charge e.g. the duration of the chat or the number of chat messages.

The XMPP session manager34is further connected to the visitor location register (VLR)27of the MSC-S2. The VLR27is associated to the MSC-S2and can be located inside the MSC-S2or can be an outside entity which is e.g. inserted into a rack which comprises among others the MSC-S2plug in card. This subscriber storage area can now be used as persistent data storage for the XMPP protocol for offline messages or privacy lists.

The GSM authentication function28of the MSC-S2is connected via the c2s component36with the XMPP stanzas router35. The GSM authentication function28can be used by the c2s component36to authenticate a XMPP client or user.

The XMPP stanzas router35is connected via the s2s component33with the core network interface25and the routing function26of the MSC-S2. The routing function26acts in support of the s2s component to resolve hostnames for the s2s component25as part of the XMPP dial-back authentication. The dial-back authentication, as mentioned in the RFC standard 3920, is for verification of the identity of an originating XMPP server. The s2s component33can reuse the existing IP network interface of the MSC-S node2and the core network of the mobile communication network to send communication data to another XMPP server111,121which can be located anywhere in the Internet100or in another node of the same or another mobile communication network.

According to one embodiment of the invention, the c2s component36is connected to a second XMPP client50. This second XMPP client50can be a virtual instance or bot which has been established or instantiated in the storage of the MSC-S2as a virtual instance or a procedure. The establishment of the second XMPP client50can be triggered by the XMPP server3after an external XMPP client1has been registered at the XMPP server3. The second XMPP client50can be associated to the same user as the registered external XMPP client1in the UE18. This can e.g. be done by obtaining mobile subscriber data from a user database when the second XMPP client50is established. The user database could be the implemented VLR27or the external home location register (HLR)4. The second XMPP client50remains active over a predefined time after the first registration of the external first XMPP client1at the XMPP server3and will be deleted or inactivated if e.g. the external XMPP client1remains silent over a specific time period or has been de-registered at the XMPP server3.

Each virtual XMPP client50is associated to a converter51which is adapted to convert messages from the virtual XMPP client50into a format which can be processed by the entities of the mobile communication network (e.g. HLR4) or vice versa. The converter51can be an integrated part of the second XMPP client50or it can be a further module in the MSC-S2which is linked to the virtual XMPP client50and via a HLR interface6with the HLR4.

One example of a message format which can be processed by the HLR4is the mobile application part (MAP) message. The MAP message is used for communication between different SS7-instances of a mobile communication network, e.g. HLR, the VLR or the MSC. The converter51is adapted to convert MAP messages into XMPP messages such that the virtual XMPP client50is able to process these messages.FIG. 5shows a connection between the virtual XMPP client50via the converter51and over a HLR interface6to the HLR4so that the virtual XMPP client50is able to communicate with the HLR4via the converter51.

FIG. 6shows an embodiment of the invention as a flow chart wherein after an initial step two different procedures (activate service and remove service) are depicted in one chart. This figure shows a XMPP client1, a MSC2and a HLR4which communicate with each other. The MSC2can also be a MSC server (MSC-S) and comprises a XMPP server3which is adapted to communicate with the XMPP client1and with the virtual or second XMPP client50. Further the MSC2comprises a converter51which is adapted to communicate with the virtual XMPP client50and with the HLR4. The figure is limited to these components due to clarity reasons. Interfaces and other modules in the MSC2, the HLR4and the XMPP client1are not depicted.

In a first step601the XMPP client1registers at the XMPP server3to inform the XMPP server3that the XMPP client1is active and can be reached. The XMPP server3knows the user identification of the XMPP client1after registration. After the XMPP client1has been registered at the XMPP server3, a second XMPP client50is established in the MSC and will be registered in a next step602to the XMPP server3. The second XMPP client50is associated to the same user as the XMPP client1. After both clients1,50have been registered at the XMPP server3, they are able to send commands towards each other and the XMPP server3is able to route these commands from the sending XMPP client1,50to the receiving XMPP client1,50. In a further embodiment of the invention, the XMPP client1queries the supported commands from the virtual XMPP client50in a step603to be aware of the commands which can be used. The virtual XMPP client50sends back in a next step604a list of all supported commands. Both communication steps must be routed via the XMPP server3. The list of supported commands according to the invention are commands which affects the management of the mobile communication network, like forwarding of calls or blocking of calls. It is also possible that the XMPP client1does not need the supported command list from the virtual XMPP client50because the commands could be predefined.

To activate a service in the HLR4, the XMPP client1sends an ad-hoc command in a step605according to the XMPP extension XEP-0050 via the XMPP server3to the virtual XMPP client50. An example for a service is “Call Forwarding”. The ad-hoc command further includes an action indicator which indicates if the action should be executed or canceled. These ad-hoc commands can only be sent to a XMPP client1,50. It is not possible to send ad-hoc commands according to the XMPP extension XEP-0050 to a XMPP server3. The commands must be routed over the XMPP server3to the recipient. The virtual XMPP client50detects that this ad-hoc command is used to manage the setup of a user preference in the mobile communication network and forward the ad-hoc command to converter51. The converter51converts in a next step511the ad-hoc command according to the XMPP extension XEP-0050 into a MAP message for activating the service and sends this MAP message via the HLR interfaces to the HLR4in a step606. In case of the prescribed example “Call Forwarding” the MAP message is CFU (Call Forwarding Unconditional). The HLR4activates the service607. If the MAP message is a CFU message the HLR4changes the related forwarding service settings in the subscriber's subscription profile. If the setting is successful the HLR4sends back a MAP message608to the converter51which indicates a successful result. The converter51converts511this MAP message into an ad-hoc command with the same content and sends the ad-hoc command to the virtual XMPP client50. The virtual XMPP client50sends in a next step609the ad-hoc command via the XMPP server3to the XMPP client1to indicate that the service has successfully been activated. To remove a service the XMPP client1sends an ad-hoc command610over the XMPP server3to the virtual XMPP client50which indicates that a service should be canceled. The virtual XMPP client50detects that this command has to be worked by a HLR4and forward this message to the converter51. The converter51converts the ad-hoc command into a MAP message and sends in a next step611this message to the HLR4to de-activate a service612. The result will be send in a next step613to the converter51, converted511by the converter51into an ad-hoc command and send to the virtual XMPP client50via the XMPP server3to the XMPP client1as a next step614. Both procedures (activate and remove services) can be compared with regard to the communication steps.

As an additional feature the activation and de-activation of services like the call forwarding service or call barring service can be automatized. If the external XMPP client1logs off or de-register from the XMPP server or if the XMPP client1becomes unreachable in case of a mobile packet data access the virtual XMPP client50can automatically cancel any call forwarding service to this specific XMPP client1using the same procedure as shown inFIG. 6. It might also be possible to automatically activate the service call barring to block a call to a de-registered or unreachable XMPP client1. Further it is possible that if the XMPP client1has been registered at the XMPP server3, the virtual XMPP client50will automatically activate the call forwarding service so that every call to this subscriber will automatically be forwarded to the XMPP client1. This automatization can be implemented by using well known XMPP mechanisms. The XMPP client50subscribes to the presence information of the XMPP client1. The XMPP server3then takes care to inform the XMPP client50when XMPP client1registers or de-registers.

FIG. 7shows a special setup where the mobile subscriber18is registered in another MSC which does not comprise a XMPP server or virtual XMPP client. The XMPP client1of the subscriber is still in registered at the XMPP server3of the MSC2which is not the serving MSC for the mobile subscriber18. If the XMPP client1of the mobile subscriber18wants to set a service in the HLR4it is not possible for the MSC2to change settings in the HLR4via MAP message for this not registered subscriber.FIG. 7shows just the message flow between the MSC2and its containing entities and the HLR4. An ad-hoc command for setting a service has been received in a first step701by the XMPP server3from a XMPP client1wherein the subscriber18of this XMPP client1is not registered at this MSC2. The ad-hoc command will be routed to the second or virtual XMPP client50. The XMPP client50recognizes that the received ad-hoc command is for setting up a service in the HLR4and send the ad-hoc command to the converter51indicating that the MSC2is not the serving MSC for the subscriber. The converter51converts511the ad-hoc command into a MAP service setting (SS) procedure. Before this MAP SS-procedure will be send to the HLR4in step704the converter51will send a MAP: Any Time Interrogation (Location) message702to HLR4to query the VLR number of the VLR which actually serves the subscriber18. The HLR4sends back in a next step703the VLR number in a MAP: Any Time Interrogation message (VLR-Nr.). The converter51uses the received VLR number of the serving MSC/VLR and fake to be the serving MSC by using the received VLR number in the MAP service setting message704. This VLR number is not used for other purposes like routing. The HLR4will activate the service in a further step706. The converter51receives the MAP: result successful message in a next step706and convert511this message into an ad-hoc command: status completed. This ad-hoc command is send to the virtual XMPP client50in a next step707which forward this command via the XMPP server3to the external XMPP client1of the subscriber18. This roaming situation can also be applied for the cancellation of service in the HLR4.