HK1097129B - Method, system and network device for routing a message to a temporality unavailable network user - Google Patents

Description

Method, system and network device for routing messages to temporarily unavailable network users

Technical Field

The present invention relates to a method, system and network device for routing messages, such as Multimedia Messaging Service (MMS) notifications, to temporarily unavailable network users, such as clients within an internet protocol multimedia subsystem (IMS).

Background

In order to achieve access independence and maintain smooth interaction with wired terminals over the internet, the IMS specified in 3GPP technical specification TS23.228 has been developed to comply with IETF (internet engineering task force) "internet standards". The IP multimedia core network (IM CN) subsystem enables network operators of mobile or cellular networks to provide their customer multimedia services based on and in accordance with internet applications, services and protocols. The aim is to develop said services using the mechanisms provided by the internet and IM CN subsystems, with mobile network operators and other third party providers including operators in the internet space. The IMS thus enables the conversion and access of voice, video, messaging, data and web-based technologies for wireless users, and combines the growth of the internet with the growth of mobile communications.

Fig. 1 shows the architecture of an IMS network according to the above 3GPP (third generation partnership protocol) technical specification. The architecture is based on the principle that the service control for the home subscribed services of the roaming user is within the home network HN, e.g. the serving call state control function (S-CSCF) is located within the home network HN. In fig. 1, a current or legacy S-CSCF is shown₀10 and future or new S-CSCFn 12, between which a terminal device or User Equipment (UE)40 may transition due to a required change in the user profile or network coverage area of said UE40The performance changes.

In general, the S-CSCF performs session control services for the served UE. The S-CSCF maintains the session state AS required by the network operator to support services that may be provided by an Application Server (AS)60, which application server 60 may be located within the home network HN or the visited network VN. Different S-CSCFs may have different functions within the operator' S network. The functions performed by the S-CSCF during the corresponding session are e.g. login, session flow management, charging and resource utilization management. When a user roams to a visited network VN which supports a proxy CSCF (P-CSCF)30, the proxy CSCF (P-CSCF)30 enables the session control to be transferred to a corresponding S-CSCF located at the home network HN and providing traffic control. Furthermore, a polling CSCF (I-CSCF)50 is provided within the home network HN, within the operator network, as the point of contact for all connections directed to users of the network operator, or roaming users currently located within the service area of the network operator. There may be multiple I-CSCFs within the operator's network. The functions performed by the I-CSCF50 include assigning an S-CSCF to a user performing a login procedure, routing a request received from another network to the S-CSCF, maintaining an address of the S-CSCF in a customer database, such as the Home Subscriber Server (HSS)20 as shown in fig. 1, and/or forwarding the request or response to the S-CSCF determined based on the change in address from the HSS 20.

The P-CSCF 30 is the first point of contact within the IMS. Its address is discovered by the UE40 according to a PDP (packet data protocol) context activation. The P-CSCF 30 acts as a proxy, accepting requests and serving them internally, or in translating, possibly forwarding them after translation. The P-CSCF 30 may also act as a user agent, i.e. in an abnormal situation it may terminate and generate transactions independently. The P-CSCF 30 performs the function of forwarding a registration request received from the UE40 to an I-CSCF determined using the domain name provided by the UE40, such as the I-CSCF50, and forwarding the request or response to the UE 40.

More details of the functionality of the different CSCF elements shown in fig. 1 can be taken from the above-mentioned 3GPP technical specifications.

The IETF has specified a Session Initiation Protocol (SIP) event package for login, as defined in "draft-IETF-mapping-reg-event". Through its REGISTER method, SIP allows a user agent, which is the interface between a user and a web application (e.g., a browser), to generate, modify, and delete logins. The login may also be modified by an administrator to enforce policies. Thus, these entries represent a piece of state within the network that can be dynamically changed. There are many situations in which a user agent may utilize notification of such a state change. The event package defines a mechanism by which the user agent can request and get the notification.

The SIP REGISTER method provides a way for a user agent to manipulate login. Contacts may be added or deleted and the current contact set may be interrogated. The login may also change to the result of administrator policy. For example, if the user is suspected or a fraudster, his login may be deleted, thereby making it unable to receive any requests. The login expires after a period of time if not updated. Thus, the login represents a dynamic state slice maintained by the network. The SIP events framework defines a generic framework for subscribing to and notifying events related to the SIP system. The framework defines the methods SUBSCRIBE and NOTIFY and introduces the concept of a package. A package is a specific application of an event framework to a specific event category such as login status.

The SUBSCRIBE message of the registration package may include a body for filtering subscriptions. Sending the SUBSCRIBE message may or may not have the body. The default login policy is to trigger a notification according to the SUBSCRIBE message and generate the notification each time the status of any logged-on contacts for the subscribed resources changes. The notification includes only information about the contact whose state has changed. The notification forwarded using the NOTIFY message includes within its body a login information file describing some or all contacts related to a particular recording address.

Within the 3GPP IMS release 5 technical specifications TS 24.229, 24.228 and 23.218, the SIP login status event package is used to inform the client of the event package about the login status of the user. 3GPP IMS release 6 introduces new services into the system, such as presence, messaging, conferencing, and MMS. There are services like MMS that can take advantage of the capabilities of IMS networks. The IMS network can provide accurate information about the user's login status using the SIP login status event package, and also allows for carrying MMS notifications using SIP message requests.

IMS clients are either logged in or logged out according to the IMS release 5 specification. However, despite being logged in, the IMS client is still unreachable, for example due to battery loss, temporary radio coverage loss at the user's current location, which is especially prevalent in large cities or areas where the radio coverage is spotty for some reason. Therefore, if the service user cannot be reached, an external service using the IMS network cannot be notified.

Disclosure of Invention

It is therefore an object of the present invention to provide a method, system and network device by means of which an application server using an IMS network for forwarding messages can be made aware of whether a service user is unavailable.

This object is achieved by means of a method of routing a message to a temporarily unavailable network user, the method comprising the steps of:

subscribing to a status event package for the network user;

generating a notification when the status event package of the network user is changed to a status indicating that the network user is available again, or that the network user is logged in again; and

routing the message to the network user in response to receiving the notification.

Furthermore, the above object is achieved by a network device for serving a network user within a data network, the network device being configured to store a status event package indicating that the network user is logged off or logged on but unavailable, and to generate a notification of the status event package to a user if the status event package indicates that the network user is available.

Further, the above object is achieved by a network server for generating a message to be routed to a network user, the server being configured to subscribe to a status of an unavailable network user and to route the message to the unavailable network user in response to receiving a status notification indicating that the unavailable network user is available.

Finally, the above object is achieved by means of a system for routing messages to temporarily unavailable network users, said system comprising a network server and a network device as defined above.

Thus, the external application server can subscribe to the login status of the network user and get a notification of whether the network user is logged in. Furthermore, the network user is not available even if logged on.

Thus, external services using an IMS network may utilize notifications regarding the availability experienced by the IMS network.

In the present invention, the term "available" should be understood to cover situations where all users are not reachable, i.e. situations where the network user does not wish to be disturbed, e.g. due to a conference.

The subscribing step may be performed in response to receiving a message indicating that the network user is unavailable or unregistered.

Further, the notification may include information indicating that the network user is reachable again even if the login status is not affected. In particular, this information may be event or marker information. The information may be set to indicate a state available to the network user after the terminal device of the network user successfully performs an outgoing session setup or an incoming session setup attempt. The re-login can be determined based on a notification of a reassignment of the network user. The subscription may then be updated in response to the notified re-registration.

Drawings

The invention will be described below on the basis of a preferred embodiment and with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic block diagram of a network architecture in which a preferred embodiment of the present invention may be implemented;

fig. 2 shows a message signaling and processing diagram indicating the delivery of a notification to an IMS client according to the first preferred embodiment;

fig. 3 shows a message signaling and processing diagram indicating the delivery of a notification to an IMS subscriber according to a second preferred embodiment;

fig. 4 shows a message signaling and processing diagram indicating a subscription login status event package according to a third preferred embodiment.

Detailed Description

The preferred embodiment will be described below based on MMS notification delivery within the IMS network architecture shown in fig. 1.

The IMS architecture shown in fig. 1 refers to a set of core network entities that provide multimedia services using services provided by the packet switched domain. The HSS20 is the master database for a particular subscriber, and includes the functionality of a conventional Home Location Register (HLR), as well as new functionality provisioned to the IP network, such as IMS. The HSS20 is the entity that includes subscription-related information to support the network entities that actually handle the call and/or session.

Fig. 2 shows a schematic signalling diagram according to the first preferred embodiment, where the AS60 uses the login/logoff information of the login status event package to deliver its MMS notification to the IMS client of the UE40 to be notified when said client logs in again and is thus available.

According to a first preferred embodiment a SIP based solution for MMS notification using existing capabilities of the IMS network is proposed.

When the AS60 intends to deliver an MMS notification to an IMS user or client, it generates SIP MESSAGE a request and includes the direct or indirect notification AS payload of the request (step 1), which AS60 may be an MMS server. If the IMS client is not registered at this time, the MESSAGE MESSAGE is not passed to UE40, but is rejected by a default S-CSCF, e.g., the S-CSCF, using a SIP error response₀Whereas a SIP error response is, for example, SIP480 temporarily unavailable. Here, AS60 corresponds to a SIP AS within the IMS network architecture and acts AS a SIP user agent. It is assumed that the AS60 is able to initiate its own request and delegate it to the user by interrogating the user' S-CSCF over the Sh interface, or sending the request to the I-CSCF 50. Since the user is not currently logged in, it is assumed that login status information may also be provided when the user logs out. Thus, the logged-on state configuration is equivalent to a service that is also associated with a logged-off state. If the user has a service associated with a deregistered state, i.e. the HSS20 stores a user profile for the deregistered state, the default S-CSCF will be allocated to handle the request. Since the user is not logged in, the S-CSCF does not exist_O10 stored paths directed to the UE 10, and thus the S-CSCF_O10 will respond with a 4xxSIP failure response rejecting the incoming SIP MESSAGE request.

More details on path generation can be taken from the 3GPP technical specification TS 24.229.

According to fig. 2, the I-CSCF50 initiates an inquiry (step 2) to the HSS20 to obtain routing information in response to receiving SIP MESSAGE a request from the AS 60. The I-CSCF5 then0 forwards the MESSAGE request to the default S-CSCF in step 3_O10, the default S-CSCF_OThe 10 responds to the AS60 with a SIP480 temporarily unavailable response in steps 4a and 4 b. Since the MESSAGE request is rejected, the AS60 SUBSCRIBEs to the login status of the user by forwarding the SUBSCRIBE request for the login status event in the same way AS the MESSAGE request was previously sent, e.g. by delegating the request to the I-CSCF50 (step 5), which I-CSCF50 can ask the HSS20 for the user' S-CSCF in step 6. Based on previously allocated S-CSCF_O10, there may be a need to allocate a new default S-CSCF to handle the SUBSCRIBE request.

When S-CSCF_OWhen the SUBSCRIBE request is received in step 7, it must authenticate and authorize the request as required by the IETF specification RFC 3265. In steps 8a and 8b, a successful subscription is confirmed with a SIP 200OK response. In 3GPP IMS, the authentication is solved by means of the IETF technical specification RFC 3325, where the AS60 inserts its trusted identity into the SIP request. Based on this, S-CSCF_O10 may determine whether the AS60 is an authorized user of the particular user login status and if so, it may install the subscription. According to 3GPP technical specification N1-030285, all application servers of the HN are authorized to subscribe to the registration event package. Thus, if AS60 belongs to the HN, AS60 is authorized.

However, when the user or IMS client logs in (again) in step 9, the NOTIFY request sent in steps 10a and 10b will inform the AS60 of the change in the user's login status. The AS60 acknowledges the reception with a SIP 200OK response in steps 11a and 11 b. Thus, the AS60 may restart its MESSAGE request and send it via the S-CSCF in steps 12 and 14 (HSS interrogation of I-CSCF50 in step 13)_O10 to the UE40 for the final forwarding and delivery of the MMS notification to the IMS user of said UE40 in step 15.

Fig. 3 shows a schematic signaling diagram according to the second preferred embodiment, where the AS60 delivers its MMS notification to the IMS subscriber of the UE40 using a refresh subscription based on subscription migration to the newly allocated S-CSCFn 12.

In fig. 3, steps 1 to 9 correspond to the first preferred embodiment shown in fig. 2, and therefore are not described again for reasons of simplicity.

However, when a user or IMS subscriber (again) logs in step 9, it may be possible to assign a new S-CSCFn 12 for it, since the assigned S-CSCF has to have the correct capabilities in relation to the logged-in status. In this case the old S-CSCF will be addressed via the Cx interface described in 3GPP technical specification TS23.228_OThe reassignment is notified 10 (step 10). At this time, at the S-CSCF_OBefore the user' S profile is deleted 10 it moves the subscription to the newly assigned S-CSCFn 12 by issuing a SIP NOTIFY request in steps 11a and 11b, which includes a subscription status header containing the value "terminate". The AS60 responds with a SIP 200OK acknowledgement in steps 12a and 12 b.

According to the IETF specification RFC 3265, when subscription migration is performed, the AS60 initiates a re-subscription in step 13. After the I-CSCF50 performs the HSS query in step 14, the SUBSCRIBE request is forwarded to the S-CSCFn 12 in step 15. The S-CSCFn 12 responds with a SIP 200OK acknowledgement in steps 16a and 16 b. Thus, with migration, the subscription refresh SUBSCRIBE request will terminate at the newly assigned S-CSCFn 12, the S-CSCFn 12 will perform the authentication and authorization steps as described above, and the subscription will be installed.

Since the user or IMS subscriber is currently logged in, the NOTIFY request sent by the new S-CSCFn 12 in steps 17a and 17b will inform the AS60 of the change in the user' S login status. Thus, after acknowledgement (not shown), the AS60 may restart its MESSAGE request and route it to the UE40 via the S-CSCFn 12 (HSS query in step 19) in steps 18 and 20 to forward and deliver the MMS notification to the IMS subscriber of the UE40 in step 21.

At this point, the AS60 may decide to terminate the subscription to the user's login status, or it may maintain the subscription. Assuming the latter case, the subscription will be terminated when the user logs off itself or the network decides to perform a network initiated logoff procedure. This is because the S-CSCFn 12 is now de-allocated and another S-CSCF may be assigned to handle the de-registration state. This process is described in 3GPP technical specifications N1-030296 and TS 24.229.

Thus, in case the subscription of the AS60 is terminated, i.e. it receives a NOTIFY request comprising a subscription status header containing the value "terminated", if the AS60 still wishes to receive a login status regarding the user, it has to update its subscription according to the S-CSCFn 12.

According to a third preferred embodiment, a network user or an IMS client may be identified as logged on but still not available. To this end, the S-CSCF is adapted to maintain additional information within a login status event or new status event package indicating whether the user is reachable. For example, the customer may not be reachable if there is a battery loss or a temporary radio coverage loss at the customer's current location. The S-CSCF may identify this situation if the terminating service was not successfully delivered to the client. Thus, a new event is introduced for the client being logged in but not reachable, e.g. a "not reachable" or "out of coverage" status. Thus, when the client logs in, the status may be "reachable" or "unreachable".

In particular, the state "reachable" may be set if the terminating service to the client is successful, or the incoming session establishment attempt is successful, or the terminal device or UE40 performs normal outgoing session establishment, or there is a normal re-login of the UE 40. However, when the state is set to "unreachable", it still does not block the terminating traffic. But when a message sent from the AS60, such AS an MMS server, fails, the AS60 may subscribe to the S-CSCF in order to discover that the user is reachable again. To this end, the AS60 subscribes to the login event package or other new event packages for the client.

Thus, better granularity for the login event package is provided, so that the AS60 subscribing to this event package can make use of more accurate information about the availability of the user.

Fig. 4 shows a signalling diagram indicating the subscription of the AS60 to the status event package of the IMS client of said UE 40. In step 1, the MMS notification is routed within an SIP MESSAGE request as defined in IETF technical Specification RFC 3428 to the I-CSCF50, which I-CSCF50 initiates in step 2 an inquiry to the HSS20 to get a current S-CSCF directed to serving the UE40_O10, routing information. After having received the routing information, the I-CSCF50 forwards the SIP MESSAGE request to the S-CSCF in step 3_O10. It may then be determined that the UE40 is currently unreachable. At this time, the terminating S-CSCF_O10 may determine that the direct message is not forwarded to the terminating user. The decision may be based on some application logic, or for example on caller preferences and/or callee capabilities. The required information, which may indicate an unreachable status within the error cause of the response message, such as a SIP480 temporarily unavailable message, is available at the P-CSCF 30. According to the IETF technical specification RFC 3261, a cause phrase within the response message may be used to convey event status information. The corresponding state rows are as follows:

Status Line＝SIP-Version SP Status-Code SP Reason-PhraseCRLF

the determination of the unreachable status of the UE40 may be based on waiting at the P-CSCF 30 for a response timeout to a MESSAGE request directed to the UE 40. The P-CSCF 30 thus assumes that the UE40 is unreachable and generates a response message indicating an unreachable status.

Thus, a message SIP480 indicating that the client has not been found or is unavailable is sent to the AS60 via the I-CSCF50 in steps 4a and 4b for a time being unavailable.

In response to this negative answer, the AS60 goes through steps 5a and 5bThe SIP SUBSCRIBE request is forwarded by the I-CSCF50 and after HSS interrogation (not shown) to the S-CSCF_O10. The S-CSCF_O10 confirms the subscription with a SIP 200OK acknowledgement routed to the AS60 via the I-CSCF50 in steps 6a and 6 b. As long as the successful transaction of the UE40 is performed by the S-CSCF_O10 determines, for example, a mobile originated transaction or a mobile terminated transaction or a re-login of the UE40, the S-CSCF_OThe SIP NOTIFY request including the status "login" and the event "reachable" is issued 10, i.e. via the I-CSCF50 in steps 7a and 7 b. The NOTIFY request is acknowledged by the AS60 in steps 8a and 8b with a corresponding SIP 200OK response.

Thus, the AS60 is informed that the UE40 can arrive again and can go via the I-CSCF50 in step 9, via the S-CSCF in steps 11a to 11c_O10 and the P-CSCF 30 forward the SIP MESSAGE request including the MMS notification (HSS query including the I-CSCF50 in step 10) to the UE 40. In response, the UE40 forwards a SIP 200OK acknowledgement to the AS60 in steps 12a to 12 d.

Thus, the AS60 may be informed of the connection status of the UE40 and thus be able to successfully forward the MMS notification to the UE 40.

It should be noted that the present invention is not limited to the above preferred embodiments. The invention may be implemented within any data network in which a subscription to a login status of a client may be implemented, informing the client of the reachable or unreachable status or re-login of the relevant network user. The embodiments may thus vary within the scope of the attached claims.

Claims (23)

1. A method of routing a message to a temporarily unavailable network user (40), the method comprising the steps of:

routing the message from the network server to the network user (40) through the network device when the network user (40) is available again,

the method is characterized by comprising the following steps:

said network server subscribing to a status event package for said network user (40), an

Receiving a notification at the network server when the status of the network user (40) is changed to a status indicating that the network user (40) is available again, or that the network user (40) is logged in again,

wherein the network server performs the subscribing step in response to receiving a response indicating that the network user is unreachable or not logged in, an

Wherein the network server performs the routing step in response to receiving the notification.

2. The method of claim 1, wherein said state event package is a login state event package.

3. A method according to claim 1 or 2, wherein said network user's re-availability status is a network user's reachabitability status.

4. A method according to claim 1 or 2, wherein said notification comprises information indicating that said network user is reachable or out of coverage.

5. The method of claim 4, wherein the information is event or marker information.

6. A method according to claim 4, wherein said information is arranged to indicate a status available to said network user following an initial login of said network user.

7. A method according to claim 4, wherein said information is arranged to indicate a status of said network user outside of coverage if terminal traffic for said network user has failed.

8. The method of claim 7, wherein the out-of-coverage condition is determined based on an error cause of the response message.

9. A method according to claim 4, wherein said information is arranged to indicate a state reachable by said network user if a terminal device (40) of said network user performs an outgoing session setup or a re-login.

10. A method according to claim 1 or 2, wherein re-login is determined based on a notification of a reassignment of the network user.

11. The method of claim 10, further comprising the step of updating said subscription in response to a re-login of said notification.

12. A method according to claim 1 or 2, wherein said message is an MMS notification.

13. A network device for serving a network user (40) and a network server (60) in a data network and routing messages from the network server (60) to temporarily unavailable network users (40), the network device (10, 12) comprising:

means for routing the message to the network user (40) when the network user is available again,

it is characterized in that the preparation method is characterized in that,

the network device (10, 12) further comprises:

means for generating a response to the network server (60) to indicate that the network user (40) is unreachable or not logged in,

means for subscribing the network server (60) to a status event package of the network user (40) upon receipt of a subscription request, wherein the subscription request is sent from the network server upon receipt by the network server of the response indicating that the network user (40) is unreachable or not logged in,

means for generating a notification when the status of the network user is changed to indicate that the network user is available again, or the network user is logged in again, an

Means for routing the message to the network user (40) in response to receiving the message, wherein the message was sent by the network server from the network server in response to receiving the notification.

14. A network device according to claim 13, wherein said notification comprises information indicating that said network user is reachable or out of coverage.

15. The network device of claim 14, wherein the network device comprises: -means for setting said information to a state indicating availability of said network user after initial login of said network user or when an outgoing session set-up or an incoming session set-up attempt performed by a terminal device (40) of said network user is successful.

16. The network device according to claim 14 or 15, wherein the network device comprises: means for setting the information to indicate a status of the network user outside of coverage when a terminal service to the network user fails.

17. A network device according to any one of claims 13 to 15, wherein said network device comprises means for a call state control function (10, 12) of an IMS network.

18. A network server for generating messages to be routed to network users (40) and routing messages to said network users (40) when a temporarily unavailable network user (40) is available again,

it is characterized in that the preparation method is characterized in that,

the network server (60) comprises:

means for subscribing to a status event package for the unavailable network user (40) in response to receiving a response generated by a network device (10, 12) indicating that the network user (40) is unreachable or not logged in, and

means for routing the message to the network user (40) in response to receiving the notification generated by the network device (10, 12) when the status of the network user (40) is changed to a status indicating that the network user (40) is again available, or that the network user (40) is logged in again.

19. The network server according to claim 18, wherein said network server (60) comprises: means for performing the subscription in response to receiving a message indicating that the network user is unreachable or not logged in.

20. The network server according to claim 18 or 19, wherein said state event package is a login state event package and said network server (60) comprises: means for subscribing to a login status event package for the network user.

21. The network server according to claim 18 or 19, wherein said network server (60) comprises: means for updating the subscription in response to the notified network user re-logging in.

22. A network server according to claim 18 or 19, wherein said network server (60) is an MMS server.

23. A system for routing messages to unavailable network users, the system comprising a network server according to any one of claims 18 to 22 and a network device according to any one of claims 13 to 17.