KR20080003397A - A method and arrangement for handling client-related information in an application server - Google Patents

Abstract

A method and arrangement for handling client-related information in an application server (206) connected to a telecommunication network (202), for a client (200) who has registered with said telecommunication network. A message (3:4) is received from the client that results in the activation of a client state in the application server. Registration events, i.e. events when the client's registration is changed, are then monitored e.g. by creating a subscription (3:5) for the registration events. If a registration event notification (3:7) is received concerning the client, the client state is updated in response thereto.

Description

{A METHOD AND ARRANGEMENT FOR HANDLING CLIENT-RELATED INFORMATION IN AN APPLICATION SERVER}

The present invention generally relates to a method and apparatus for processing information relating to a client of an application server connected to a telecommunications network. In particular, the present invention contemplates reducing the amount of signaling when the client state is maintained at the application server.

With the advent of 3G mobile telephony, new packet-based communication technologies have been developed to deliver multimedia content. For example, GPRS (Universal Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technology, in addition to conventional circuit-switched voice calls, provide packet-switching of data representing images, text, documents, animations, audio files, video files, and the like. Supports wireless multimedia telephony communications, including communications The term "multimedia content" will be used herein to refer to any data carried by a packet-switched transport.

Recently, an open standard called "IP Multimedia Subsystem (IMS)" has been developed by the Third Generation Partnership Project (3GPP) to provide multimedia services for mobile clients in the packet domain. In general, IMS is a platform that is somewhat independent of the access technology used, and basically enables services based on IP transport that is not limited to any limited set of specific services.

The provision for session establishment is defined as so-called "SIP" (standard IETF RFC 3261 and others according to session initiation protocol), an application-layer control (signaling) protocol that creates, modifies, and terminates sessions via packet-switched logic. SIP is commonly used by IMS networks to establish multimedia sessions.

1 schematically shows a basic network structure for providing a multimedia service by an IMS service network. It should be noted that the figures are very simplified and only illustrate the selection of network nodes useful for understanding the context of the present invention. The calling mobile terminal A is connected to the first radio access network 100 and the called mobile terminal B is connected to the second radio access network 102 in a communication session S including one or more multimedia services. Communicate with Alternatively, terminal A may communicate with a content server or computer or a fixed terminal that delivers some multimedia content to the terminal, such as a piece of music, film or game.

The IMS network 104 is connected to the first radio access network 100 and processes a session related to terminal A, as initiated by its user. In fact, the IMS network 104 receives and processes any service request or data from the user of terminal A. In this figure, the corresponding IMS network 106 processes the session on behalf of the terminal B, and the two IMS networks 104, 106 can be controlled by several operators. Similarly, the IMS network 106 receives and processes any service request or data from the user of terminal B. Alternatively, terminals A and B can of course be connected to the same access network and / or belong to the same IMS network.

The illustrated session S is managed using SIP signaling by a node called S-CSCF (serving call session control function) assigned to the terminal A of the IMS network 104, and the multimedia service used is Enabled and performed by the application server 110. Basically, the S-CSCF node 108 acts as a proxy for the application server 110 facing the terminal A, and the IMS of the terminal B from the terminal A, as indicated by the dotted arrows. Send a SIP message to the network 106. In addition, the main database element HSS (home subscriber server) 112 stores subscriber and authentication data as well as service information, among which the service information is required for the application server 110 to patch to perform service for the client. Can be. Typically, S-CSCF node 108 fetches information from HSS 112, which application server 110 requests by terminal A, as determined by the “trigger” at HSS 112. Determine if the service is being processed.

A node called I-CSCF (Query Calling Session Control Function) 114 is connected to another IMS network, in this case network 106, and acts as a gateway for SIP messages from other IMS networks. I-CSCF 114 receives a SIP message from IMS network 106 of terminal B, as indicated by another dotted arrow. The node called P-CSCF (Proxy Call Session Control Function) 116 serves as an entry point from any access network, such as network 100, to IMS network 104, and the client and IMS network 104 All signaling flows in between are routed through the P-CSCF 116.

The various functions of the I-CSCF and P-CSCF nodes 114, 116 need not be described further herein to further understand the context of the present invention. Of course, IMS network 104 includes several other nodes and functions, such as additional S-CSCF nodes and application servers, which are not shown here for the sake of brevity. Basically, IMS network 106 includes nodes of the same type as network 104. The illustrated application server 110 may be configured to provide one or more specific multimedia services to a client.

Two important examples of services that can be used by an IMS network are "Instant Messaging (IM) and" current "services, using SIP signaling to control sessions. Instant messaging is an" almost "service between terminals. Real-time ", ie, sending relatively short messages (e.g. including text, pictures, logos, audio / video clips, etc.) with short delays. In this context," current "is basically dynamic and changes in the client. It is a possible state profile, and the current service basically contains the publication of the client's "current data" for use by other users, which in turn can be used to control other services. Specifies the condition of the client and his / her equipment. The term "current" is used in a very broad sense and the following "client state" refers to, for example, current data:

-Busy personal status during meetings, eg during breaks

The state of the terminal being switched on and off in addition to, for example, coverage, etc.

-Geographic location of the client / terminal

Terminal capabilities such as SMS, MMS, conversation, IM, video, etc.

Terminal selection, eg call forwarding, language, etc.

Other client information such as interest, occupation, personal characteristics, mood, personal logo, logo according to current mood.

This information, or any selected portion thereof, is stored in the application server of the IMS network whenever the client changes any of his / her current data, based on the so-called "event publishing" received from the network or client. Depending on some services, the client may also subscribe to selected current data of one or more other users, for example according to a user list. This current subscription is typically also handled by the application server of the IMS network.

SIP messages called "SIP PUBLISH" are generally used by clients, or rather "User Agent Clients (UAC), to upload dynamic data to application servers in an IMS network. The publication of data can be used by any service for this purpose, such as PoC, IM and current service. Another SIP message called "SIP SUBSCRIBE" is used by the client to subscribe to the dynamic data of another client as handled by the application server. In this description, the term "client state" will be used to indicate the maintenance of information related to the client at the application server for a limited time, as determined by a preset end time, sometimes referred to as Time To Live (TTL). Information related to such a client may be about a client's subscription to published client data or data of another user. However, such a service can result in a large amount of messages sent from the client towards the IMS network, especially for the current service.

Therefore, the client state or requested data subscription for the issued client data must have an end time, so that the published data or data subscription becomes invalid as the time expires. If no timeout occurs by the client, the application server will use a default expiry time, typically one hour in the current case. In current service implementations, in accordance with various standards of the IETF, 3GPP and OMA, even if data / subscriptions do not change during this period, data publication or subscriptions often must be refreshed to maintain valid data / subscriptions at the application server.

The conventional procedure for maintaining data related to a client issued at an application server will now be described with reference to the block diagram shown in FIG. The client terminal 200 is powered on by its user and is currently connected to an access network although not shown for communication with other terminals and also with a multimedia services network 202, such as the IMS network described above. The service network 202 includes a "registration unit" 204, an application server 206 and an HSS 208, among other nodes and components according to the IMS network shown in FIG. The registration unit 204 may thus be an S-CSCF as described above, and generally handles the registration of the client with the service network. Here, it is assumed that when initially accessing the access network, a temporary IP address is assigned to the terminal so that the terminal can generally communicate over IP.

In a first step (2: 1), the terminal 200 transmits a registration request message to the registration unit 204 in order to be registered as an active terminal in the service network 202. Thereafter, the terminal is registered at the HSS 208 as represented by step 2: 2 according to the conventional path which is not described further herein. Thereafter, the terminal is forced to refresh registration by periodically sending a "re-registration" message or a message to registration unit 204, as generally indicated by dotted arrows 2: 3. . Typically, a re-registration message must be sent every 30 to 60 minutes to maintain registration.

At some point during this ongoing routine, terminal 200 sends a client data issue message, such as a SIP PUBLISH message, to application server 206 at step 2: 4. The application server 206 will then store new client data that will be valid for a time-out period set to 30 minutes or one hour. In general, the client data publish message results in activating the "client state" at the application server 206 while the published data is valid. In order to maintain this client state at the application server 206, ie published data, even if the data is not changed, the time-out period ends, as is generally indicated by the dotted arrow (2: 5). The issued data must be refreshed by periodically sending a "reissue" message before. If the client has several active client states in the network 104, the burden of such refresh messages can be significant.

If the terminal 200 eventually turns off, the "unregistered" message is eventually sent to the registration unit in step 2: 6. Typically, the terminal also has the burden of sending a "unissued" message to the application server 206, although not shown to deactivate the issued data. Otherwise, even if the terminal is turned off, the data issued from when the last reissue message is sent will remain valid in the application server 206 until the time-out period last expires. This can result in inappropriately activating the client state after the client has finished using it and until the TTL is terminated. In particular, this may be the case, for example, when the terminal 200 temporarily disconnects its wireless connection due to battery discharge, thereby preventing transmission of unissued messages.

Basically, some procedures will be used when a client sends a subscription request for data from another client as described above. In this case, the message of step (2: 4) would be a subscription request message, such as a SIP SUBSCRIBE message, which results in activating another client state at the application server 206. In addition, the refresh message in step 2: 5 will be a "resubscribe" message sent periodically to maintain this client state. However, as described below, there is a problem associated with having a client terminal 200 that periodically sends reissue and / or resubscribe messages.

As a current solution, the client must either refresh the published data or increase the end time for the published data for the following reasons. Initially, we wanted to have a short end time for the client state, such as published data or data subscriptions, in order to maintain the client state to the application server to this day, and as a result, this would re-issue the publication very periodically. There is a need. The main reason for having a short end time may be the fact that the application server 206 will not know whether the client is shut down without sending an unissued or unsubscribed message to change the data or subscription state to an "off" state. Thereafter the client state is maintained in vain, and an essential notification may be sent periodically to the terminal that the subscription to the data of another client may be activated rather than being able to receive them until the TTL ends.

Secondly, this aspect places a large amount of additional load on both the access network used as well as the service network 202, which is generally based on radio access, in the IMS case. In addition, in the case of a mobile client, the periodic transmission of a reissue or resubscribe message will consume the terminal battery as in step (2: 5) above and will already consume wireless bandwidth. It would therefore be advantageous to have a relatively long end time for the client state with respect to the signaling load. Thus, in the above-described conventional solution, the end time for the client of the application must be set in a compromise between these conflicting factors.

It is an object of the present invention to address at least some of the problems outlined above. In particular, it is an object to reduce the signaling load from a client having an active client state at the application server. Another object is to ensure that information related to the client in the application server can be maintained to this day using minimal signaling messages.

It is another object of this and other purposes to obtain a method and apparatus for processing information relating to a client of an application server connected to a telecommunications network for a client registered to the telecommunications network according to the attached independent claims. In this way, a message is received primarily from the client resulting in activating the client state at the application server. Thereafter, a registration event, that is, an event is monitored when the client's registration changes. At some point, a registration event notification considering the client is received and the client status is updated in response to the received registration event notification.

The message received from the client may include a request for publication of the client data or a subscription request for the client data, or may be a session initiation message, eg, a SIP INVITE message. Monitoring the registration event may include a subscription to the registration event or may monitor the registration event of a third party.

The registration event notification received typically indicates that the client's registration with the telecommunications network has been deactivated. Registration of the client may be deactivated when receiving an unregistered message from the client. Typically, the registration of the client with the telecommunications network is valid for a limited time, and the registration of the client with the telecommunications network is deactivated when the registration validity time expires. The client state is preferably deactivated at the application server in response to deactivation of client registration with the telecommunications network.

Typically, the client state in the application server also has a validity for a limited time, and the end time of the client state validity is preferably set considerably longer than the time end of the registration validity. For example, the end time of client state validity is set to at least 10 times the end time of registration validity.

The telecommunications network is an IMS network, and registration event notifications are received from the S-CSCF, which handles the registration of clients with the IMS network. In this case, SIP is used to send and receive messages with the client.

Also provided is an apparatus of an application server connected to a telecommunications network that processes information related to the client for a client registered in the telecommunications network. The apparatus comprises means for receiving from the client a message resulting in activating the client state at the application server, means for monitoring a registration event, ie an event when the client registration is changed, means for monitoring a registration event notification considering the client. And means for updating the client status in response to the received registration event notification.

The apparatus also includes means for receiving the message from the client, including the issue of client data, means for receiving the message from the client, the request including a subscription request to the client, and sending the message as a session initiation message, eg, a SIP INVITE message. The method may further include means for receiving from the client. The means for monitoring the registration event may be adapted for monitoring a subscription event for a registration or for a third party.

The apparatus may further comprise means for receiving the registration event notification indicating that the registration of the client with the service network has been deactivated. Registration of the client with the service network may be deactivated when receiving an unregistered message from the client. Typically, the registration of the client with the service network has a validity for a limited time and is deactivated when the registration validity time expires.

The apparatus further includes means for deactivating the client in response to deactivating the registration of the client with the telecommunications network. Typically also the client state in the application has a limited time validity. And the apparatus further comprises means for setting an end time of client state validity significantly longer than the registration validity end time, and preferably further comprising means for setting an end time of client state validity to at least 10 times the end time of registration validity. Include.

The telecommunications network is typically an IMS network and the registration event notification is received from an S-CSCF node that handles the registration of a client with the IMS network. In this case, SIP is used to send and receive messages with the client.

Additional features and advantages will be described in the detailed description below.

The invention will now be described in more detail by preferred embodiments with reference to the attached drawings.

1 is a schematic diagram of a basic communication scenario in which the present invention may be used;

Fig. 2 illustrates a conventional procedure for maintaining client data in the application server.

3 illustrates a procedure for processing information related to a client in an application server, according to one embodiment; And

4 is a signaling diagram illustrating a procedure of maintaining a client server, according to another embodiment.

Basically, the solution can use the existing routing of the client sending the re-registration message to the registration unit as described in step (2: 3) of FIG. This can be used to "refresh" any client state activated on the application server. In this way, in addition to refreshing the client registration, issued data or data subscriptions can be automatically refreshed without the client sending periodic reissue and resubscribe messages to the application server.

An embodiment of the present solution will now be described with reference to the block diagram shown in FIG. 3 using the same reference numerals for corresponding elements. Also, the first part of the procedure is basically the same as that described with respect to FIG. Therefore, the terminal 200 transmits a registration request message in the first step 3: 1, and the terminal is registered with the HSS 202 in the next step 3: 2. In addition, the terminal also needs to periodically send a re-registration message to the registration unit 204 in order to maintain the "active" and valid registration as indicated by step 3: 3.

At some point during this ongoing procedure, terminal 200 sends a message to application server 206 that results in activating the client state, typically at the application server, at step 3: 4. As described above, this message is typically a client data issue message or a data subscription request message, but can also be a session initiation message, i. E. A SIP INVITE message, if the session has been active for a long time. The application server 206 will typically maintain a client state that includes information relating to some clients regarding published data or subscriptions to the data.

However, in order to avoid sending periodic refresh messages that maintain this client state at the application server 206, the application server 206 begins to monitor registration events related to the client's registration. In this example, the application server 206 sends a subscription request for a registration event to the registration unit 204 in step 3: 5. Alternatively, the registration event of the third party can be monitored.

As used herein, the term "registration event" refers to any event when client registration changes. One important registration event is that when the client sends an unregistered message as in step (2: 6) of Figure 2 above, the client's registration is eventually deactivated in the service network 202. The registration of the client may also be deactivated if no refresh re-registration messages are received during the last timeout period, for example due to a release of the wireless connection or battery discharge.

Therefore, if the registration unit 204 receives an unregistered message from the client 200 in step 3: 6, it sends a registration event notification considering the client to the application server in the next step 3: 7, to the application server. Notify that the client is no longer registered as active in the service network 202. The same registration event notification can be sent if the registration times out without refreshing. As a result, the application server 206 will finally update the client status in response to the received registration event notification. Typically, you will deactivate the client state in response to deactivation of the client's registration with the service network.

In this solution, whenever the issued data changes, the terminal can also return the issued data by periodically sending a "reissue" message, as in step (3: 4), even though it may send additional issue messages. No need to flash Since the application server can now be based on registration event notifications from the registration unit 204 which controls the client state, the end time for the client state is very large to ensure that no refreshing reissue or resubscribe message is sent. It can be set long. Preferably, the end time for the client state is set to be considerably longer than the end time for client registration, for example 10 seconds or more. This will significantly reduce the amount of signaling from the client, and the information related to the client stored on the application server will still remain to this day.

Of course, although not shown, the client sends a specific unissued or unsubscribed message to the application server 206 to deactivate the client state, but this does not affect the solution of the present invention.

An exemplary signaling procedure according to the preferred embodiment will be described with reference to FIG. 3 with respect to the issue of data by the client. The figure shows a user agent client 400a, registration unit 400b, HSS 400c and application server 400d operating on a client terminal, all of which are identical to the corresponding elements in FIG. In this example, SIP signaling is used in the IMS network. In the IMS network, although omitted in this figure for simplicity, it should be emphasized that, as shown in the background section, basically all signaling with the client is actually handled by the P-CSCF node.

When the client starts his / her terminal 400a, the user agent client (UAC) transmits a SIP REGISTER message to the registration unit 400b at step 402, indicating the "Public User Identity (PUI). ) "And fix it to the IP address assigned to the terminal. In response, the UAC 400a is registered with the network by a signaling dialog between the registration unit 400b and the HSS 400c, as shown schematically at step 404. After registration of the client, the registration unit 400b sends a SIP 200 OK message to the UAC 400a at step 406.

UAC 400a will also periodically send a refresh REGISTER message to registration unit 400b to maintain registration although not shown. The registration unit 400b will keep the registration active and use a timer function to determine when the registered PUI will be unregistered if the timer expires. When registration is terminated, the PUI is not available for communication on that device. In addition, when UAC wants to initiate, modify or remove data, commonly referred to as published data on application server 400d, it will send a new PUBLISH message to application server 400d. It should be emphasized that several different UACs may use the same terminal, either of which may send a PUBLISH message to initiate or modify its specific service data.

In an additional step 408, the initiating SIP PUBLISH message is sent from the UAC 400a to the application server 400d for any PUI. In response, the application server 400d sends a SIP SUBSCRIBE (reg. Event), which is a subscription request, to the registration unit 400b in step 410 to inform the user of any change in the registration status of the PUI. Start subscription. Alternatively, registration unit 400b may always send a registration event to application server 400d using third party registration.

The application server 400d will now know that the PUI is unregistered because the registration unit 400b has a timeout function related to the registration TTL without requesting UAC to send a reissue message. In order to minimize the traffic between the registration unit 400b and the application server 400d, the application server 400d is only unregistered, since there is no point for the application server 400d to be notified about registrations that re-release the message. You can subscribe to the event. In fact, the application server 400d does not need an active timer for all of the issued data because it can safely make that if unregistered will be notified by the registration unit 400b. UAC 400a may always send a PUBLISH message to the application server whenever the issued data needs to be changed, as indicated by optional step 412.

As a result, when the terminal of the client is powered off, a SIP REGISTER (off) message is sent from the UAC 400a to the registration unit 400b in step 414. The subsequently issued data is not validated as registration unit 400b sends a SIP NOTIFY (reg. Event (off)) message to application server 400d in final step 416.

Although the present invention has been described with reference to specific exemplary embodiments, the description is generally for illustrative purposes only and should not be taken as limiting the scope of the invention, as defined by the appended claims.

Claims (28)

A method for processing information relating to a client in an application server connected to the telecommunication network for a client registered in a telecommunication network, the method comprising: Receiving a message from the client resulting in activating a client state at the application server; Monitoring a registration event, ie when the registration of the client changes; Receiving a registration event notification for the client; And -Updating the client status in response to the received registration event notification, for processing information related to the client in an application server connected to the telecommunications network for the client registered with the telecommunications network. How to. The method of claim 1, And wherein said message received from said client comprises issuance of said client data. The method of claim 1, And wherein said message received from said client comprises a subscription request for client data. The method of claim 1, And wherein said message received from said client is a session initiation message, i. E. SIP INVITE. The method according to any one of claims 1 to 4, Monitoring the registration event comprises subscribing to a registration event. The method according to any one of claims 1 to 4, Monitoring the registration events comprises monitoring a registration event of a third party. The method according to any one of claims 1 to 6, The received registration event notification indicates that the registration of the client with the telecommunications network is not activated. The method of claim 7, wherein Registration of the client with the telecommunications network is deactivated upon receipt of a non-registration message from the client. The method of claim 7, wherein Registration of the client with the service network has a validity for a limited time, and is deactivated when the registration validity time expires. The method according to any one of claims 7 to 9, And wherein said client state is deactivated in said application server in response to deactivating registration of said client with said telecommunications network. The method of claim 10, The client state of the application server has a validity for a limited time, and an end time of the client state validity is set to be considerably longer than the registration validity end time associated with a client in an application server connected to a telecommunications network. How information is processed. The method of claim 11, And the end time of the client state validity is set at least 10 times the end time of the registration validity. The method according to any one of claims 1 to 12, Wherein the telecommunications network is an IMS network and the registration event notification is received from an S-CSCF that handles the registration of a client with the IMS network. How to. The method of claim 13, SIP is used to send and receive messages to and from the client, wherein the application server connected to the telecommunications network processes information related to the client. An apparatus in an application server connected to the telecommunications network for processing information related to a client for a client registered in the telecommunications network, Means for receiving a message from the client resulting in activating a client state at the application server; Means for monitoring a registration event, ie an event when the registration of the client changes; Means for receiving a registration event notification for the client; And Means for updating the client status in response to the received registration event notification; processing information related to a client for a client registered to the telecommunications network. Device within. The method of claim 15, And means for receiving said message from said client comprising said issuing said client data. The method of claim 15, wherein And means for receiving said message from said client comprising a subscription request for client data. The method according to any one of claims 15 to 17, And means for receiving said message from said client as a session initiation message, such as, for example, SIP INVITE. The method according to any one of claims 15 to 18, Means for monitoring the registration event is adapted to subscribe to a registration event. The method according to any one of claims 15 to 19, Means for monitoring the registration event is adapted to monitor a registration event of a third party. The method according to any one of claims 15 to 20, Means for receiving the registration event notification indicating that registration of a client with the telecommunications network has been deactivated. The method of claim 21, Registration with a client with the telecommunications network is deactivated upon receipt of an unregistered message from the client. The method of claim 21, And wherein the registration of the client with the service network has a validity for a limited time and is deactivated when the registration validity time expires. The method according to any one of claims 21 to 23, wherein And means for deactivating the client in response to deactivating registration of the client with the telecommunications network. The method of claim 24, And means for setting said client state of said application server for a limited time validity and for setting an end time of said client state validity significantly longer than said registration validity end time. Devices within the server. The method of claim 25, And means for setting an end time of the client state validity to at least 10 times the end time of the registration validity. The method according to any one of claims 15 to 26, Wherein the telecommunications network is an IMS network and the registration event notification is received from an S-CSCF that handles the registration of a client with the IMS network. The method of claim 27, Device in an application server connected to a telecommunications network, wherein a SIP is used to send and receive messages with the client.

Images