EP1875705A1 - Message handling in an ip multimedia subsystem - Google Patents

Message handling in an ip multimedia subsystem

Info

Publication number
EP1875705A1
EP1875705A1 EP05823792A EP05823792A EP1875705A1 EP 1875705 A1 EP1875705 A1 EP 1875705A1 EP 05823792 A EP05823792 A EP 05823792A EP 05823792 A EP05823792 A EP 05823792A EP 1875705 A1 EP1875705 A1 EP 1875705A1
Authority
EP
European Patent Office
Prior art keywords
session
signalling
initiation protocol
user
notification server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP05823792A
Other languages
German (de)
French (fr)
Other versions
EP1875705B1 (en
Inventor
Anders Lindgren
Christer Boberg
Anders Danne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP1875705A1 publication Critical patent/EP1875705A1/en
Application granted granted Critical
Publication of EP1875705B1 publication Critical patent/EP1875705B1/en
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Definitions

  • the present invention relates to Session Initiation Protocol message handling in an IP Multimedia Subsystem (IMS), and in particular, though not necessarily, to a method and apparatus for deferring the delivery of Session Initiation Protocol messages to ensure provision of an appropriate service level to IP Multimedia Subsystem users.
  • IMS IP Multimedia Subsystem
  • IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
  • the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services which are considered in more detail below.
  • IMS IP Multimedia Subsystem
  • 3GPP Third Generation Partnership Project
  • IMS IP Multimedia Subsystem
  • 3GPP Third Generation Partnership Project
  • IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks.
  • the IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers).
  • SIP Session Initiation Protocol
  • SDP Session Description Protocol
  • SIP was created as a user-to-user protocol
  • IMS allows operators and service providers to control user access to services and to charge users accordingly.
  • FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network.
  • Call/Session Control Functions operate as SIP proxies within the IMS.
  • the 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S- CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P- CSCF.
  • P-CSCF Proxy CSCF
  • S- CSCF Serving CSCF
  • I-CSCF Interrogating CSCF
  • a user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. The user receives a unique URI from the S-CSCF that it shall use when it initiates a dialog.
  • the IMS authenticates the user, and allocates an S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
  • the I-CSCF receives the required S- CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities.
  • HSS Home Subscriber Server
  • S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.
  • the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides (of the IMS). [For the terminating call the request will include the P-CSCF address and the UE address.]
  • Application Servers are provided for implementing IMS service functionality.
  • Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or "linked in” by an S-CSCF over the 3GPP defined ISC interface.
  • IFC Initial Filter Criteria
  • S-CSCF Session Establishment
  • Different IFCs may be applied to different call cases.
  • the IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile.
  • Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is "owned" by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
  • a notification server might be used, for example, to provide a presence service to IMS subscribers.
  • a presence service allows subscribers to publish details of their current availability, location and contact addresses to other subscribers.
  • a subscriber subscribes to a presence service by sending a SIP SUBSCRIBE method to its S-CSCF, with the S-CSCF forwarding the SUBSCRIBE method to the notification server based on the IFC settings.
  • the notification server may direct new Subscribe Requests to other notification servers, e.g. when a notifiaction server acts as a subscribing proxy on behalf of a subscribing user.
  • a subscriber publishes a change to his or her current presence information by sending a SIP PUBLISH method to the notification server via the S-CSCF.
  • a notification server may apply a rate limitation to the sending of notifications, e.g. to allow all notification generated within a given time window to be sent as a single block of data.
  • a user In the event that a user is involved in an ongoing SIP session which requires a relatively high quality of service, e.g. a voice call, the sending of a push message from the network to that subscriber can disrupt the ongoing session to an unacceptable extent.
  • a method of handling the delivery of push messages from a notification server of a Session Initiation Protocol based network to a network user comprising: signalling to said notification server the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session; and deferring the delivery of some or all push messages, scheduled for delivery to said user during the ongoing session, until the session has finished.
  • Embodiments of the present invention allow the sending of low priority traffic to be deferred during an ongoing session which has a higher priority.
  • the signalling of the start and end of a Session Initiation Protocol session may be triggered, for example, by receipt within the Session Initiation Protocol network of a SIP INVITE, BYE, or CANCEL message relating to the session.
  • the invention is applicable in particular to an IP Multimedia Subsytem (IMS) network.
  • IMS IP Multimedia Subsytem
  • said signalling step is facilitated by adding the notification server into the SIP signalling path, whereby SIP messages relating to the session are forwarded to the notification server by the Serving Call State Control Function (S-CSCF). This is facilitated by appropriately configuring the Initial Filter Criteria for said user.
  • S-CSCF Serving Call State Control Function
  • said signalling step is facilitated by signalling sent to the notification server from a session application server, e.g. a PoC application server. More particularly, said signalling is conveyed in SIP PUBLISH messages sent to the notification server by the session application server. In this case, the notification server is not added into the SIP path for the session related signalling.
  • a session application server e.g. a PoC application server.
  • said signalling is conveyed in SIP PUBLISH messages sent to the notification server by the session application server.
  • the notification server is not added into the SIP path for the session related signalling.
  • the notification server may apply a prioritisation process to sessions of different types, deferring the sending of messages during certain session types but not during other session types.
  • the notification server may also prioritise according to push message type or source, deferring certain messages but not others.
  • the invention is applicable in particular to deferring the sending of push messages during voice calls, e.g. during PoC sessions.
  • An example of a push type message which may be deferred is a presence service related message.
  • a notification server arranged to handle the delivery of push messages from a Session Initiation Protocol based network to a network user, the notification server comprising: means for receiving notifications identifying the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session for said user; and means for deferring the delivery of some or all push messages scheduled for delivery to said user during the ongoing session, until the session has finished.
  • a Session Initiation Protocol application server comprising means for receiving session setup and termination related signalling in respect of a user for the purpose of authorising and controlling the session, and means for signalling to a notification server, responsible for sending push messages to the user, at least certain changes in the session status.
  • the application server is a Push-to- talk over Cellular application server.
  • Figure 1 illustrates schematically an IP Multimedia Subsystem core network within the context of a 3G network
  • Figure 2 illustrates schematically a number of entities involved in the provision of IP Multimedia Subsystem services to IP Multimedia Subsystem subscribers
  • Figure 3 is a signalling diagram illustrating a procedure for deferring delivery of push messages to IP Multimedia Subsystem subscribers according to a first embodiment of the invention.
  • Figure 4 is a signalling diagram illustrating a procedure for deferring delivery of push messages to IP Multimedia Subsystem subscribers according to a second embodiment of the invention.
  • IMS IP Multimedia Subsystem
  • NS notification server
  • the NS 3 facilitates provision of a presence service to subscribers of the home network within which the S-CSCF and the NS are located. It will be appreciated that the NS will communicate with NSs of other networks (and possibly other NSs within the same home network) in order to provide a national or international presence service.
  • FIG 2 illustrates a SIP enabled terminal 4 which communicates with the IMS via an access network 5.
  • the NS 3 receives presence information from other notification servers 6, as well as from other subscribers (not shown) registered with the home network.
  • messages are routed via the S-CSCF(s).
  • Figure 2 also illustrates a second SIP application server 7.
  • the SIP application server 7 is, by way of example, a Push-to-talk over Cellular (PoC) server arranged to facilitate subscriber access to the PoC service which is a walkie-talkie style voice call service.
  • the S-CSCF 2 communicates with a Home Subscriber Server (HSS) 8 of the home network.
  • HSS Home Subscriber Server
  • a subscriber of the home network subscribes to the presence service facilitated by the NS.
  • the watcher instructs his client to add a particular peer user (here referred to as a "presentity") to his presence watching list using an "add buddy" instruction.
  • This causes the watcher's client to send to the S-CSCF (within the IMS) a SIP SUBSCRIBE message containing the identity of the presentity, or the identity of the presence watcher list that includes the identity f the presentity.
  • the S-CSCF will already have the IFCs for the watcher assuming that the watcher is already registered with the IMS.
  • the S-CSCF must authenticate and authorise the watcher via the Home Subscriber System, and obtain the IFCs from the HSS.
  • One of the IFCs is set to cause the SUBSCRIBE message to be forwarded from the S-CSCF to the NS.
  • the SUBSCRIBE message contains an expiry time, and up to that time the NS will forward to the watcher notifications whenever the (requested) information for the presentity changes.
  • the watcher When the watcher wishes to initiate a Voice-over-IP session with a peer user, in this example a PoC session, the watcher causes a SIP INVITE to be sent by his client to the IMS network.
  • the S-CSCF receives the INVITE, and examines the IFCs for the watcher which were downloaded at registration of the watcher. In this example, one of the IFCs indicates that the INVITE should be forwarded to the NS. (As an alternative to using IFCs to trigger the sending of the INVITE to the NS, the S-CSCF can be configured to always send INVITEs to the NS.)
  • the INVITE is received by the NS, and the initiation of a PoC session is logged in respect of the watcher.
  • the INVITE is then returned to the S-CSCF, which examines the IFCs again and determines that the INVITE should be forwarded to the PoC application server for authorisation. Assuming that authorisation is given, the INVITE is returned to the S-CSCF which forwards it towards the called party.
  • the final phase of the signalling flow begins with an action on the part of the watcher to terminate the PoC session.
  • This causes the watcher's client to send to the S-CSCF a SIP BYE.
  • the IFCs for the watcher indicate that the NS should be added in to the message path.
  • the NS logs the PoC session as ended. Receipt of a SIP CANCEL message (e.g. generated by the PoC application server in response to a failed authorisation of the watcher) at the NS would have the same result.
  • the sending of notifications to the watcher is inhibited.
  • the receiving NS will check whether any sending restrictions are currently in place for the watcher, and will determine that this is indeed the case. Any deferred notifications are retained at the NS, and are sent only after receipt of the BYE message.
  • the INVITE message may be received at the S-CSCF from some third party client, where the watcher is the called party. Receipt of this INVITE will cause the S-CSCF to examine the appropriate IFCs (for watcher as terminating party), and the INVITE to be forwarded to the NS. Similarly, the BYE message may originate with the remote client.
  • FIG. 4 illustrates a signalling flow associated with an alternative embodiment of the invention.
  • This embodiment addresses a disadvantage inherent to the embodiment described above with reference to Figure 3, namely that the requirement to add the NS to the SIP message path introduces a delay in the end-to-end signalling process.
  • the solution is to enable one or more application servers that have a knowledge of the session state to inform the notification server of this state.
  • the PoC application server will receive the initial SIP INVITE from the watcher (step 6).
  • the PoC application server will handle this message in the normal way.
  • it will notify the NS via the S-CSCF of the change in status of the watcher by sending a SIP PUBLISH method to the NS (step 7).
  • the NS will defer the sending of notifications to the watcher.
  • the NS may apply a prioritisation scheme to handle different session types and different notifications.
  • this scheme may cause notifications to be sent during voice calls but not during video calls, the former being less bandwidth/processing intensive than the latter.
  • the scheme may also, for example, prioritise notifications relating to the presence of users in dependence upon priorities applied to these users by the watcher: the watcher may wish to receive notifications in respect of a close relative during an ongoing session, but not in respect of work colleagues.
  • prioritisation may also be carried out at the session server, e.g. the PoC server, in terms of which events should be notified to the NS.

Abstract

A method of handling the delivery of push messages from a notification server 3 of a Session Initiation Protocol based network 1 to a network user 4. The method comprises signalling to said notification server 3 the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session, and deferring the delivery of some or all push messages, scheduled for delivery to said user 4 during the ongoing session, until the session has finished.

Description

Message Handling in an IP Multimedia Subsystem
Field of the Invention
The present invention relates to Session Initiation Protocol message handling in an IP Multimedia Subsystem (IMS), and in particular, though not necessarily, to a method and apparatus for deferring the delivery of Session Initiation Protocol messages to ensure provision of an appropriate service level to IP Multimedia Subsystem users.
Background to the Invention
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services which are considered in more detail below.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.218, TS 23.228, TS 24.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
Figure 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S- CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P- CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. The user receives a unique URI from the S-CSCF that it shall use when it initiates a dialog. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates an S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if one is not already selected. The I-CSCF receives the required S- CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides (of the IMS). [For the terminating call the request will include the P-CSCF address and the UE address.]
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or "linked in" by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be "linked in" during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is "owned" by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
An example of a SIP AS is a notification server (NS). A notification server might be used, for example, to provide a presence service to IMS subscribers. A presence service allows subscribers to publish details of their current availability, location and contact addresses to other subscribers. A subscriber subscribes to a presence service by sending a SIP SUBSCRIBE method to its S-CSCF, with the S-CSCF forwarding the SUBSCRIBE method to the notification server based on the IFC settings. The notification server may direct new Subscribe Requests to other notification servers, e.g. when a notifiaction server acts as a subscribing proxy on behalf of a subscribing user. A subscriber publishes a change to his or her current presence information by sending a SIP PUBLISH method to the notification server via the S-CSCF. A notification server may apply a rate limitation to the sending of notifications, e.g. to allow all notification generated within a given time window to be sent as a single block of data.
Summary of the Invention
A problem has been identified in the provisioning of push-type SIP services such as the notification service. In the event that a user is involved in an ongoing SIP session which requires a relatively high quality of service, e.g. a voice call, the sending of a push message from the network to that subscriber can disrupt the ongoing session to an unacceptable extent. This applies in particular to IMS services where subscribers are making use of relatively low bandwidth (radio) access networks, and/or where terminal processing capacity is limited.
According to a first aspect of the present invention there is provided a method of handling the delivery of push messages from a notification server of a Session Initiation Protocol based network to a network user, the method comprising: signalling to said notification server the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session; and deferring the delivery of some or all push messages, scheduled for delivery to said user during the ongoing session, until the session has finished.
Embodiments of the present invention allow the sending of low priority traffic to be deferred during an ongoing session which has a higher priority. The signalling of the start and end of a Session Initiation Protocol session may be triggered, for example, by receipt within the Session Initiation Protocol network of a SIP INVITE, BYE, or CANCEL message relating to the session.
The invention is applicable in particular to an IP Multimedia Subsytem (IMS) network.
In one embodiment of the invention applicable to the IMS case, said signalling step is facilitated by adding the notification server into the SIP signalling path, whereby SIP messages relating to the session are forwarded to the notification server by the Serving Call State Control Function (S-CSCF). This is facilitated by appropriately configuring the Initial Filter Criteria for said user.
In another embodiment of the invention also applicable to the IMS case, said signalling step is facilitated by signalling sent to the notification server from a session application server, e.g. a PoC application server. More particularly, said signalling is conveyed in SIP PUBLISH messages sent to the notification server by the session application server. In this case, the notification server is not added into the SIP path for the session related signalling.
The notification server may apply a prioritisation process to sessions of different types, deferring the sending of messages during certain session types but not during other session types. The notification server may also prioritise according to push message type or source, deferring certain messages but not others.
The invention is applicable in particular to deferring the sending of push messages during voice calls, e.g. during PoC sessions.
An example of a push type message which may be deferred is a presence service related message.
According to a second aspect of the present invention there is provided a notification server arranged to handle the delivery of push messages from a Session Initiation Protocol based network to a network user, the notification server comprising: means for receiving notifications identifying the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session for said user; and means for deferring the delivery of some or all push messages scheduled for delivery to said user during the ongoing session, until the session has finished.
According to a third aspect of the present invention there is provided a Session Initiation Protocol application server comprising means for receiving session setup and termination related signalling in respect of a user for the purpose of authorising and controlling the session, and means for signalling to a notification server, responsible for sending push messages to the user, at least certain changes in the session status.
In a particular embodiment of the invention, the application server is a Push-to- talk over Cellular application server.
Brief Description of the Drawings
Figure 1 illustrates schematically an IP Multimedia Subsystem core network within the context of a 3G network;
Figure 2 illustrates schematically a number of entities involved in the provision of IP Multimedia Subsystem services to IP Multimedia Subsystem subscribers;
Figure 3 is a signalling diagram illustrating a procedure for deferring delivery of push messages to IP Multimedia Subsystem subscribers according to a first embodiment of the invention; and
Figure 4 is a signalling diagram illustrating a procedure for deferring delivery of push messages to IP Multimedia Subsystem subscribers according to a second embodiment of the invention.
Detailed Description of Certain Embodiments The provision of the IP Multimedia Subsystem (IMS) within a 3G network has already been described with reference to Figure 1. In order to illustrate embodiments of the invention, reference will be made to the simplified schematic diagram of Figure 2 which shows an IMS core network 1 comprising a Serving Call State Control Function (S-CSCF) node 2 and a notification server (NS) 3. For the purpose of this discussion, the NS 3 facilitates provision of a presence service to subscribers of the home network within which the S-CSCF and the NS are located. It will be appreciated that the NS will communicate with NSs of other networks (and possibly other NSs within the same home network) in order to provide a national or international presence service.
Figure 2 illustrates a SIP enabled terminal 4 which communicates with the IMS via an access network 5. The NS 3 receives presence information from other notification servers 6, as well as from other subscribers (not shown) registered with the home network. In accordance with the defined standards, messages are routed via the S-CSCF(s). Figure 2 also illustrates a second SIP application server 7. In this case, the SIP application server 7 is, by way of example, a Push-to-talk over Cellular (PoC) server arranged to facilitate subscriber access to the PoC service which is a walkie-talkie style voice call service. The S-CSCF 2 communicates with a Home Subscriber Server (HSS) 8 of the home network.
A first embodiment of the present invention will now be described with reference the signalling diagram of Figure 3. A subscriber of the home network, designated "watcher" in Figure 3, subscribes to the presence service facilitated by the NS. In a first signalling phase, the watcher instructs his client to add a particular peer user (here referred to as a "presentity") to his presence watching list using an "add buddy" instruction. This causes the watcher's client to send to the S-CSCF (within the IMS) a SIP SUBSCRIBE message containing the identity of the presentity, or the identity of the presence watcher list that includes the identity f the presentity. The S-CSCF will already have the IFCs for the watcher assuming that the watcher is already registered with the IMS. Alternatively, if the watcher is not already registered, the S-CSCF must authenticate and authorise the watcher via the Home Subscriber System, and obtain the IFCs from the HSS. One of the IFCs is set to cause the SUBSCRIBE message to be forwarded from the S-CSCF to the NS. The SUBSCRIBE message contains an expiry time, and up to that time the NS will forward to the watcher notifications whenever the (requested) information for the presentity changes.
When the watcher wishes to initiate a Voice-over-IP session with a peer user, in this example a PoC session, the watcher causes a SIP INVITE to be sent by his client to the IMS network. The S-CSCF receives the INVITE, and examines the IFCs for the watcher which were downloaded at registration of the watcher. In this example, one of the IFCs indicates that the INVITE should be forwarded to the NS. (As an alternative to using IFCs to trigger the sending of the INVITE to the NS, the S-CSCF can be configured to always send INVITEs to the NS.) The INVITE is received by the NS, and the initiation of a PoC session is logged in respect of the watcher. The INVITE is then returned to the S-CSCF, which examines the IFCs again and determines that the INVITE should be forwarded to the PoC application server for authorisation. Assuming that authorisation is given, the INVITE is returned to the S-CSCF which forwards it towards the called party.
The final phase of the signalling flow begins with an action on the part of the watcher to terminate the PoC session. This causes the watcher's client to send to the S-CSCF a SIP BYE. Again, the IFCs for the watcher indicate that the NS should be added in to the message path. Upon receipt of the BYE, the NS logs the PoC session as ended. Receipt of a SIP CANCEL message (e.g. generated by the PoC application server in response to a failed authorisation of the watcher) at the NS would have the same result.
In the interval between receipt of the INVITE and the BYE messages, the sending of notifications to the watcher is inhibited. For example, in the event that the NS receives a SIP PUBLISH message from the presentity or a SIP NOTIFY message from another NS forwarding presence information for some other presentity, the receiving NS will check whether any sending restrictions are currently in place for the watcher, and will determine that this is indeed the case. Any deferred notifications are retained at the NS, and are sent only after receipt of the BYE message.
It will be appreciated that the INVITE message may be received at the S-CSCF from some third party client, where the watcher is the called party. Receipt of this INVITE will cause the S-CSCF to examine the appropriate IFCs (for watcher as terminating party), and the INVITE to be forwarded to the NS. Similarly, the BYE message may originate with the remote client.
Figure 4 illustrates a signalling flow associated with an alternative embodiment of the invention. This embodiment addresses a disadvantage inherent to the embodiment described above with reference to Figure 3, namely that the requirement to add the NS to the SIP message path introduces a delay in the end-to-end signalling process. The solution is to enable one or more application servers that have a knowledge of the session state to inform the notification server of this state. With reference to Figure 1 , in the case of a PoC service, the PoC application server will receive the initial SIP INVITE from the watcher (step 6). The PoC application server will handle this message in the normal way. In addition however, it will notify the NS via the S-CSCF of the change in status of the watcher by sending a SIP PUBLISH method to the NS (step 7). In the same way as described with reference to Figure 3, thereafter, and until the NS receives from the PoC application server a PUBLISH method indicating that the PoC session for the watcher has ended, the NS will defer the sending of notifications to the watcher.
In either of the embodiments described above, the NS may apply a prioritisation scheme to handle different session types and different notifications. For example, this scheme may cause notifications to be sent during voice calls but not during video calls, the former being less bandwidth/processing intensive than the latter. The scheme may also, for example, prioritise notifications relating to the presence of users in dependence upon priorities applied to these users by the watcher: the watcher may wish to receive notifications in respect of a close relative during an ongoing session, but not in respect of work colleagues. In the case of the second embodiment (Figure 4), prioritisation may also be carried out at the session server, e.g. the PoC server, in terms of which events should be notified to the NS.
It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.

Claims

CLAIMS:
1. A method of handling the delivery of push messages from a notification server of a Session Initiation Protocol based network to a network user, the method comprising: signalling to said notification server the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session; and deferring the delivery of some or all push messages, scheduled for delivery to said user during the ongoing session, until the session has finished.
2. A method according to claim 1 , the signalling of the start and end of a Session Initiation Protocol session being triggered by receipt within the Session Initiation Protocol network of a SIP INVITE, BYE, or CANCEL message relating to the session.
3. A method according to claim 1 or 2, wherein said Session Initiation Protocol based network is an IP Multimedia Subsytem (IMS) network.
4. A method according to claim 3, wherein said signalling step is facilitated by adding the notification server into the SIP signalling path, whereby SIP messages relating to the session are forwarded to the notification server by the Serving Call State Control Function (S-CSCF).
5. A method according to claim 4, wherein said notification server is added to the SIP signalling path by appropriately configuring the Initial Filter Criteria for said user.
6. A method according to claim 3, wherein said signalling step is facilitated by signalling sent to the notification server from a session application server.
7. A method according to claim 6, wherein said signalling is conveyed using the SIP PUBLISH method.
8. A method according to any one of the preceding claims, wherein the notification server applies a prioritisation process to sessions of different types, deferring the sending of messages during certain session types but not during other session types.
9. A method according to any one of the preceding claims, wherein the notification server prioritises the sending and deferring of push messages according to push message type or source.
10. A method according to claim 3 or to any one of claims 4 to 9 when appended to claim 3, wherein said session is a PoC session.
11. A method according to any one of the preceding claims, wherein said push messages are presence service related messages.
12. A notification server arranged to handle the delivery of push messages from a Session Initiation Protocol based network to a network user, the notification server comprising: means for receiving notifications identifying the start of a Session Initiation Protocol session and the end of a Session Initiation Protocol session for said user; and means for deferring the delivery of some or all push messages scheduled for delivery to said user during the ongoing session, until the session has finished.
13. A Session Initiation Protocol application server comprising means for receiving session setup and termination related signalling in respect of a user for the purpose of authorising and controlling the session, and means for signalling to a notification server, responsible for sending push messages to the user, at least certain changes in the session status.
14. An application server according to claim 13, the application server being a Push-to-talk over Cellular application server.
EP05823792A 2005-04-28 2005-12-21 Message handling in an ip multimedia subsystem Not-in-force EP1875705B1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE0500970 2005-04-28
PCT/EP2005/057067 WO2006114135A1 (en) 2005-04-28 2005-12-21 Message handling in an ip multimedia subsystem

Publications (2)

Publication Number Publication Date
EP1875705A1 true EP1875705A1 (en) 2008-01-09
EP1875705B1 EP1875705B1 (en) 2008-11-05

Family

ID=35759350

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05823792A Not-in-force EP1875705B1 (en) 2005-04-28 2005-12-21 Message handling in an ip multimedia subsystem

Country Status (7)

Country Link
US (1) US8185094B2 (en)
EP (1) EP1875705B1 (en)
CN (1) CN101167329B (en)
AT (1) ATE413764T1 (en)
DE (1) DE602005010913D1 (en)
ES (1) ES2317341T3 (en)
WO (1) WO2006114135A1 (en)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7610345B2 (en) 2005-07-28 2009-10-27 Vaporstream Incorporated Reduced traceability electronic message system and method
US9282081B2 (en) 2005-07-28 2016-03-08 Vaporstream Incorporated Reduced traceability electronic message system and method
US9537704B2 (en) * 2006-05-24 2017-01-03 At&T Intellectual Property I, L.P. Method and apparatus for migrating active communication session between terminals
EP2191425B1 (en) * 2007-08-14 2018-01-10 Samsung Electronics Co., Ltd. Method and system for sip based dynamic advertisement of presence information
US20090052365A1 (en) * 2007-08-20 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Method and Communication Node for Optimising Time Sensitive Communications
JP5221667B2 (en) * 2007-10-30 2013-06-26 アルカテル−ルーセント ユーエスエー インコーポレーテッド Method, apparatus and system for supporting distributed IMS charging
CN101483613B (en) 2008-01-09 2012-02-15 国际商业机器公司 Method and device for providing QoS control capability to presenting server, and system thereof
US20090248799A1 (en) * 2008-03-31 2009-10-01 Telefonaktiebolaget Lm Ericsson (Publ) Method and server for user identifier update
WO2010043017A1 (en) * 2008-10-16 2010-04-22 Research In Motion Limited Scheduling policy and quality of service through the presence access layer
US20150205464A1 (en) * 2014-01-22 2015-07-23 Microsoft Corporation Updating a user interface to a service
CN109698799B (en) * 2019-01-14 2020-06-02 广州荔支网络技术有限公司 Message pushing method and device and mobile terminal
CN112118544B (en) * 2020-08-18 2022-04-15 杭州叙简科技股份有限公司 PoC signaling processing method, apparatus, electronic device and medium

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6885861B2 (en) * 2001-08-24 2005-04-26 Nokia Corporation Service mobility and recovery in communication networks
DE60115967T2 (en) * 2001-10-31 2006-08-03 Nokia Corp. A METHOD FOR HANDLING MESSAGES BETWEEN A TERMINAL AND A NETWORK OF DATA
US20040230659A1 (en) * 2003-03-12 2004-11-18 Chase Michael John Systems and methods of media messaging

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006114135A1 *

Also Published As

Publication number Publication date
ATE413764T1 (en) 2008-11-15
CN101167329A (en) 2008-04-23
WO2006114135A1 (en) 2006-11-02
US20090023399A1 (en) 2009-01-22
CN101167329B (en) 2011-09-07
DE602005010913D1 (en) 2008-12-18
EP1875705B1 (en) 2008-11-05
ES2317341T3 (en) 2009-04-16
US8185094B2 (en) 2012-05-22

Similar Documents

Publication Publication Date Title
US8185094B2 (en) Message handling in an IP multimedia subsystem
EP2096823B1 (en) Methods and apparatus for registering a user to an IMS on the user's behalf by a SIP Application Server
US9210196B2 (en) Method and apparatus for identifying an IMS service
EP2317725B1 (en) Method and apparatus for initiating IMS based communications
EP2090070B1 (en) Service adaptation in an IP multimedia subsystem network
CA2630678C (en) Message handling in an ip multimedia subsystem
US20100099447A1 (en) Method and Apparatus for Use in a Communications Network
WO2005027459A1 (en) Ims subscriber access control
EP1925140B1 (en) Method and apparatus for keeping information up to date at an ims client
EP2140664B1 (en) Method and apparatus for use in a communications network

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070921

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20080310

RIN1 Information on inventor provided before grant (corrected)

Inventor name: DANNE, ANDERS

Inventor name: BOBERG, CHRISTER

Inventor name: LINDGREN, ANDERS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: DANNE, ANDERS

Inventor name: BOBERG, CHRISTER

Inventor name: LINDGREN, ANDERS

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 602005010913

Country of ref document: DE

Date of ref document: 20081218

Kind code of ref document: P

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2317341

Country of ref document: ES

Kind code of ref document: T3

LTIE Lt: invalidation of european patent or patent extension

Effective date: 20081105

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090305

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090205

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090406

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090205

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

26N No opposition filed

Effective date: 20090806

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081221

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20090105

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20081221

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090506

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091231

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20091231

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20090206

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20111202

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20081105

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FI

Payment date: 20171227

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20171227

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20171229

Year of fee payment: 13

Ref country code: ES

Payment date: 20180102

Year of fee payment: 13

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602005010913

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181221

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20181221

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190702

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181221

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20200204

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20181222