EP1305913B1 - Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf - Google Patents

Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf Download PDF

Info

Publication number
EP1305913B1
EP1305913B1 EP00956306A EP00956306A EP1305913B1 EP 1305913 B1 EP1305913 B1 EP 1305913B1 EP 00956306 A EP00956306 A EP 00956306A EP 00956306 A EP00956306 A EP 00956306A EP 1305913 B1 EP1305913 B1 EP 1305913B1
Authority
EP
European Patent Office
Prior art keywords
cscf
message
network element
network
procedure
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.)
Expired - Lifetime
Application number
EP00956306A
Other languages
German (de)
English (en)
Other versions
EP1305913A1 (fr
Inventor
Risto Kauppinen
Ilkka Westman
Petteri YLÄ-OUTINEN
Markus Martin
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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Priority to DE60042861T priority Critical patent/DE60042861D1/de
Priority to EP06118611A priority patent/EP1718018B1/fr
Publication of EP1305913A1 publication Critical patent/EP1305913A1/fr
Application granted granted Critical
Publication of EP1305913B1 publication Critical patent/EP1305913B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for 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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices

Definitions

  • the present invention relates to a network system and a method for controlling a network element which can be set to at least two different modes.
  • the invention relates to call control (CC) and in particular to the function of the so-called Call State Control Function (CSCF).
  • CSCF Call State Control Function
  • the CSCF is typically included in a network node like a Call Processing Server (CPS).
  • CPS Call Processing Server
  • the CSCF is the call control entity in the all-IP architecture responsible for supervising the call (or IP multimedia call). It handles the call establishment, supervision and disconnection signalling and may control resources associated with the call such as media gateways processing the various call related media streams.
  • the CSCF consists of two components: the Serving CSCF (S-CSCF) and the Interrogating CSCF (I-CSCF).
  • S-CSCF Serving CSCF
  • I-CSCF Interrogating CSCF
  • the Serving CSCF is used for mobile originated communications and also for supporting mobile terminated communications, it provides Serving Profile Database (SPD) and Address Handling (AH) functionality described below.
  • the Serving CSCF supports the signalling interactions with the UE (User Entity).
  • the Home Subscriber Server (HSS) is updated with the Serving CSCF address and the HSS sends the subscriber data to the Serving CSCF for storage.
  • the Interrogating CSCF is used for mobile terminated communications and is used to determine how to route mobile terminated calls.
  • the Interrogating CSCF interrogates the HSS for information to enable the call to be directed to the Serving CSCF.
  • the Interrogating CSCF provides Incoming Call Gateway (ICGW) and AH functionality described below.
  • ICGW Incoming Call Gateway
  • both Serving CSCF and Interrogating CSCF functionality can be involved.
  • Interrogating CSCF functionality is not required.
  • Both Serving CSCF and Interrogating CSCF components can be provided in a single CSCF if required.
  • the ICGW Incoming call gateway acts as a first entry point and performs routing of incoming calls. Furthermore, it performs an incoming call service triggering(e.g. call screening/call forwarding unconditional). Moreover, it performs a query address handling and communicates with the HSS.
  • the CCF (Call Control Function) carries out a call set-up/termination and state/event management. It interact with MRF in order to support multi-party and other services, reports call events for billing, auditing, intercept or other purpose, and receives and processes application level registration. Furthermore, it also performs a query address handling. In addition, it may provide service trigger mechanisms (service capabilities features) towards Application & services network (VHE/OSA), may invoke location based services relevant to the serving network and may check whether the requested outgoing communication is allowed given the current subscription.
  • VHE/OSA Application & services network
  • the SPD (Serving Profile Database) interacts with HSS in the home domain to receive profile information for the R00 all-IP network user and may store them depending on the SLA with the home domain. Furthermore, it notifies the home domain of initial user's access. In addition, it may cache access related information (e.g. terminal IP address(es) where the user may be reached etc.)
  • the AH (Address Handling) functionality performs analysis, translation, modification if required, address portability, and mapping of alias addresses. It furthermore may do temporary address handling for inter-network routing.
  • an Originating CSCF is the CSCF where the originating party is registered and where the originating party services are handled (and the CCF functionality is invoked).
  • the S-CSCF is the CSCF where the terminating party is registered and where the terminating party services are handled (using the CCF functionality).
  • a mobile station During setup of a connection, a mobile station first transmits a setup message to the O-CSCF which, in turn, forwards a setup message to a CSCF acting as an I-CSCF.
  • This CSCF in turn, forwards a message to another CSCF which acts as an S-CSCF.
  • the S-CSCF sends a setup message to the called party.
  • a setup for a connection is completed.
  • a CSCF receiving a setup message it is difficult for a CSCF receiving a setup message to distinguish whether it should act as an I-CSCF or as an S-CSCF.
  • an I-CSCF does not have to perform the Call Control Function (CCF).
  • CCF Call Control Function
  • a less optimal method is shown in Fig. 9 .
  • a SPD query is used for the decision.
  • an CSCF in this example, the CSCF 93
  • receives a setup message form the O-CSCF 92 it performs an SPD query in order to find out whether the setup concerns a registered subscriber. Thus, it accesses its SPD 98. If the answer is yes, the CSCF identifies itself as an S-CSCF (as in the case of CSCF 95), otherwise (as it is in the case of CSCF 93), it identifies itself as an I-CSCF.
  • the Location Request should then be done to the HSS 4. This problem does not only occur in the above-described examples. There are many situations in which a network element receiving a message like a setup message is not aware which function it should provide, i.e., in which mode it should operate.
  • Document US 5 612 950 discloses a method of managing communication in which several network nodes make transitions through different states.
  • the nodes can assume different link establishment states, wherein each node assumes a particular link state upon receiving a particular message.
  • Document US 5 111 451 describes an optical communication system in which two optical modems are synchronized.
  • the modems can assume two different operation modes: a slave mode or a master mode.
  • Document US 5 109 220 discloses a selective call controller, wherein a terminal operates in at least two modes, namely a "default" mode in which it receives and decodes DTMF signals, and a modem receive mode. Moreover, a controller and supervisor of the terminal comprises two input ports, wherein communication devices connected to one of the ports are recognized as modems and communication devices connected to the other port are recognized as DTMF telephones.
  • the object underlying the invention resides in removing the above drawbacks of the prior art and to ensure that a network element receiving a message like a setup message is aware which function it should provide, i.e., in which mode it should operate.
  • the object is solved by a network system as defined in the independent claim 1. Furthermore, the object is solved by a method as set out in the independent claim 12. Moreover, the above object is solved by a network element as defined in the independent claim 16.
  • the network elements mentioned above are devices carrying out Call State Control Functions (CSCF).
  • CSCF Call State Control Functions
  • the different modes can be an Interrogating CSCF (I-CSCF) functionality, a Serving CSCF (S-CSCF) functionality, an Originating CSCF (O-CSCF) functionality, a Media Gateway Control Function (MGCF) or the like.
  • I-CSCF Interrogating CSCF
  • S-CSCF Serving CSCF
  • O-CSCF Originating CSCF
  • MGCF Media Gateway Control Function
  • the message transmitted between the first and the second network element and/or between the second and the third network element can be a setup message.
  • the corresponding network elements can be set to the correct modes without additional commands and without the need of negotiations between the network elements.
  • the invention can be advantageously applied to the Session Initiation Protocol.
  • a database can be accessed in order to obtain information regarding a subscriber to which a setup is to be sent and to decide the mode of the second network element on the basis of the obtained information.
  • the aim of the invention lies to set different modes (like I-CSCF or S-CSCF) of a network element like a CSCF.
  • the mode of the network element can be set by one or more of the following ways:
  • the network element switches to a certain mode after the deduction process based on one or more of the following:
  • Fig. 1 illustrates a simplified block diagram of a network system according to a first embodiment of the invention.
  • a setup procedure between a first mobile station 1 and a second mobile station 7 is carried out.
  • the User Entities are not limited to mobile stations but can also be fixed telephones, computer modems or the like.
  • a call as meant in this description does not only refer to telephony calls, but also to IP multimedia calls.
  • the mobile station 1 sends a setup message to a CSCF 2. Since this CSCF receives the setup message from a mobile station, it knows that it has to act as an Originating CSCF, i.e., an O-CSCF. After receiving the setup message, the O-CSCF 2 forwards a setup message to a further CSCF 3. This CSCF 3 acts as an Interrogating CSCF, i.e., this CSCF takes care of location requests. In particular, it accesses a Home Subscriber Server (HSS) 4 which provides information regarding the location of the subscriber to which a connection is to be established, i.e., the mobile station 7.
  • HSS Home Subscriber Server
  • the I-CSCF 3 sends a setup message to a further CSCF 5.
  • the setup message comprises a flag "Location Request Done".
  • the CSCF 5 Upon receiving the setup message including this particular flag, the CSCF 5 immediately knows that it has to act as a Serving CSCF (S-CSCF).
  • S-CSCF Serving CSCF
  • the flag included in the setup message between the I-CSCF 3 and the S-CSCF 5 can be located in the setup message as an own field or it can be hidden in an existing field in a standardized manner.
  • the S-CSCF 5 accesses a Serving Profile Database (SPD) 6.
  • SPD Serving Profile Database
  • the SPD 6 interacts with the HSS in the home domain of a subscriber in order to obtain information regarding the user and to notify the home domain regarding the location of the subscriber, or the like.
  • the S-CSCF 5 sends a setup message to the mobile station 7 in order to complete the setup procedure.
  • a CSCF which receives a setup message including information concerning that a location request is already done knows that it should act as an S-CSCF.
  • a decision whether a particular CSCF should act like an I-CSCF or like an S-CSCF is performed by using a setup message with a special flag which is set when sent from the I-CSCF.
  • the method according to the first embodiment corresponds to items A.b. and X3 of the above-described general idea of the application.
  • a simple method is possible.
  • it is easy to organise the network.
  • Fig. 2 Parts denoted with the same reference numerals as in Fig. 1 are the same as that in Fig. 1 . Thus, a detailed description is omitted here.
  • the O-CSCF 22 sends a setup message to a further CSCF 23 upon receiving a setup message from the mobile station 1, as according to the first embodiment.
  • this setup message between the CSCFs 22 and 23 includes a flag "do location request".
  • the CSCF 23 identifies itself as an I-CSCF. That is, each time the CSCF 23 receives a message which requests it to perform a location requests, the CSCF automatically knows that it should act as an I-CSCF and not as an S-CSCF.
  • the I-CSCF 23 sends a setup message to the CSCF 25.
  • no special flag is included here.
  • a CSCF immediately knows upon receiving a setup message without a special flag that it should act as an S-CSCF.
  • the method according to the second embodiment corresponds to items A.b. and X3 of the above-described general idea of the application.
  • a simple method can be achieved for the decision whether a CSCF in question should act as an I-CSCF or an S-CSCF.
  • the setup message between the O-CSCF and the I-CSCF can contain the flag "do location request" and the setup message between the I-CSCF and the S-CSCF can contain the flag "location request is done”.
  • a CSCF in question can easily distinguish in response to receiving the first or the second flag whether it should act as an I-CSCF or as an S-CSCF.
  • a more reliable determination of the role of the CSCF is possible.
  • the O-CSCF 32 does not send a setup message to the I-CSCF but sends a location request to the I-CSCF 33.
  • the I-CSCF gets the required location information regarding the called party (i.e., the mobile station 7) from the HSS 4. Then, the I-CSCF sends the location information back the O-CSCF 32.
  • the O-CSCF 32 learns the location of the mobile station 7 and, therefore, the CSCF 35 to be contacted, and sends a setup message to the S-CSCF 35.
  • the S-CSCF 35 sends a setup message to the mobile station 7 in order to complete the setup procedure.
  • the third embodiment corresponds to items A.a. and X2 of the general idea of the application.
  • a CSCF which receives a setup message automatically knows that it should act as an S-CSCF since a CSCF which has to act as an I-CSCF receives a message containing only a location request. Therefore, the S-CSCF knows that no procedure like performing of a location request is to be done.
  • a simple method for deciding whether a particular CSCF should act as an I-CSCF or as an S-CSCF can be achieved.
  • a direct connection between the O-CSCF and the S-CSCF can be obtained since the O-CSCF obtains information regarding the location of the mobile station 7 and, thus, the S-CSCF which acts the serving CSCF for the mobile station 7.
  • the O-CSCF 2 sends a setup message to a G-CSCF 43.
  • This CSCF is a special CSCF which can only perform one function. That is, in contrast to the CSCF according to the previous embodiments, this CSCF cannot switch between different modes.
  • the function of the G-CSCF is a gateway function. In particular, no subscriber registration is possible in this CSCF.
  • the G-CSCF 43 automatically performs a location request procedure upon receiving a setup message. Thereafter, the G-CSCF 43 sends a setup message to a further CSCF 45.
  • This CSCF is adapted to operate in two different modes, as according to the previously described embodiments.
  • the CSCF 45 knows automatically upon receiving the setup message that it should act as an S-CSCF.
  • information regarding a predetermined procedure like processing of a location request is simply given by the fact that this processing is to be performed by a particular network element. That is, if another CSCF receives a setup message which does not include any flags regarding a location request, this CSCF knows that is has to act as a S-CSCF.
  • this example corresponds to items B.b.b. and X5 of the above-described general idea of the application.
  • an I-CSCF of another operator can only be connected from certain CSCF(s).
  • Every the CSCF listens to two different ports: the I-CSCF port and the S-CSCF port.
  • the I-CSCF port is the default port of IPT (Internet Protocol Telephony).
  • the CSCF sets itself into an I-CSCF or an S-CSCF mode.
  • the second example not forming part of the present invention corresponds to items B.a.a. and X4 of the above-described general idea of the application.
  • the O-CSCF 52 sends a setup message to the default port of the CSCF 53.
  • the CSCF knows that it should act as an I-CSCF and performs a location request by referring to a HSS 54. That is, when the CSCF has received the setup message at the default port, it identifies itself as an I-CSCF and performs a location request to the HSS.
  • the HSS 54 responds with the IP address and the S-CSCF port number of the CSCF where the subscriber (i.e., mobile station 7) is registered.
  • the I-CSCF 53 sends the setup message further to the given port of the S-CSCF 55.
  • the HSS 54 knows the S-CSCF port number and the IP address of the S-CSCF 55 which has to be contacted.
  • the S-CSCF port may be whichever port the S-CSCF has chosen provided that it isn't the default port of IPT.
  • the port refers to e.g. a TCP/IP port.
  • the TCP/IP port is a field in the Internet TCP and UDP protocol headers that identify the upper layer protocol and entity on top of the TCP or UDP protocol layer.
  • a port is an identifier in a lower layer protocol header that identifies the upper layer protocol.
  • the decision whether a CSCF should act as an I-CSCF or as an S-CSCF is performed by sending the setup message to a certain port of the CSCF when the I-CSCF functionality is wanted and to a different port when the S-CSCF functionality is wanted.
  • the port numbers of the IP protocol can be used.
  • a simple method for the decision can be achieved. Furthermore, as according to all embodiments and examples not forming part of the present invention, no complicated rules are needed in the basic call state models to decide which functionality should be started. The decision is made on the basis of the port number, via which the setup message was received. Furthermore, no extra standardisation is needed, because the setup is sent to the CSCF always to the default IPT port, except to the S-CSCF port in case the CSCF in question is selected as the S-CSCF.
  • the CSCF does not have different ports but different IP addresses. That is, depending on to which IP address of a particular CSCF a setup message is sent, the CSCF acts as an I-CSCF or as an S-CSCF.
  • this third example corresponds to items B.a.a. and X4 of the above-described general idea of the application.
  • the O-CSCF 62 sends a setup message to the I-CSCF IP address of the CSCF 63.
  • the CSCF 63 knows automatically that is should act as an I-CSCF and, correspondingly, performs a location request by referring to the HSS 64.
  • the I-CSCF 63 obtains from the HSS 64 the location of the called mobile station 7 and the S-CSCF IP address of the CSCF in charge of the mobile station 7.
  • the I-CSCF 63 sends a setup message to the S-CSCF IP address of the CSCF 65, which, in turn, automatically knows that it has to act as an S-CSCF.
  • an easy method for deciding whether a particular CSCF has to act as an I-CSCF or as an S-CSCF can be obtained. It is only necessary to provide two different IP addresses for each CSCF and to send a setup message to the corresponding IP address of the CSCF.
  • the setup message is sent from a specialised port. This corresponds to items B.a.b. and X1 of the above-described general idea of the application.
  • the O-CSCF 72 sends the setup from the O-CSCF port thereof to the CSCF (i.e., in the example of Fig. 7 , to the CSCF 73).
  • the CSCF 73 identifies itself as an I-CSCF because the setup was sent from the O-CSCF port of the CSCF 72.
  • the I-CSCF 73 makes a Location Request to the HSS 4, which responds with the IP address of the S-CSCF of the UE 7 to be contacted.
  • the I-CSCF sends the setup from the I-CSCF port with the IP address to the CSCF 75.
  • the CSCF 75 identifies itself as an S-CSCF, since it receives the setup message sent from the I-CSCF port of the I-CSCF 73.
  • the setup message is sent from a specialised address.
  • this example corresponds to the items B.a.b. and X1 of the above-described general idea of the application.
  • the O-CSCF 82 sends the setup message from an "O-CSCF" IP address to the CSCF 83.
  • the CSCF 83 identifies itself as an I-CSCF because the setup was received from the O-CSCF IP address.
  • the I-CSCF 83 makes a Location Request to the HSS 4, which responds with the IP address of the S-CSCF of the UE 7 to be contacted. Thereafter, the I-CSCF sends the setup message to the S-CSCF 85 having the IP address obtained from the HSS 4.
  • the CSCF 85 identifies itself as an S-CSCF because the setup message was received from the "I-CSCF" IP address.
  • a Location Request to HSS is performed in order to find out whether the setup concerns a registered subscriber.
  • the sixth example corresponds to items B.b.a and X7 of the above-described general idea of the application.
  • the CSCF 103 when the CSCF 103 receives a setup message from the O-CSCF 102, it performs a Location Request to the HSS 4 in order to find out, whether the setup concerns a registered subscriber. If the answer is yes, the CSCF is an S-CSCF, otherwise it is an I-CSCF.
  • the CSCF 103 obtains the information from the HSS 4 that the UE 7 is not a registered subscriber. Thus, the CSCF identifies itself as an I-CSCF.
  • the CSCF 105 obtains from its HSS 109 the information that the UE 7 is a registered subscriber. Hence, the CSCF 105 identifies itself as an S-CSCF.
  • I-CSCF functionality the different functions (in particular I-CSCF functionality and S-CSCF functionality) of a CSCF are only used as examples. It can also be distinguished between O-CSCF, I-CSCF, S-CSCF and MGCF functionality and others.
  • a flag is used for indicating that the location request has to be done or has been done.
  • this information can be carried by two or more flags.
  • this information can be written in one or more extra data field.
  • any address of the other levels of the protocol stack can be used.
  • the ethernet address i.e. media level address
  • the ethernet address can be used.
  • the I-CSCF and the S-CSCF are represented as separated entities.
  • the I-CSCF which performs the location request recognises that the called mobile station 7 is in the range of itself such that the I-CSCF has to operate as the S-CSCF.
  • the I-CSCF has to switch itself to the other mode, i.e., to the S-CSCF functionality.
  • This can be effected by sending a setup message including a flag to itself (as in the first and second embodiments), or by sending the setup message to the S-CSCF port or S-CSCF IP address (as in the first and second examples not forming part of the present invention), for example.
  • the O-CSCF can be the same entity. That is, the O-CSCF and the I-CSCF or the S-CSCF can be the same entity.
  • the CSCF contacted by the O-CSCF in order to perform a location request is not able to perform the location request.
  • this particular CSCF has to forward the setup message received unchanged to a further CSCF which presumably can perform the location request. That is, for example with respect to Fig. 1 , between the O-CSCF 2 and the I-CSCF 3, a further intermediate CSCF can be located.
  • the O-CSCF might also be located in another network than the network currently serving the originating party.
  • a CSCF with an ICGW functionality will be required on the network border between the serving network and O-CSCF.
  • this ICGW (on the network border) determines the CSCF serving the originating party.
  • NE network element
  • I-CSCF ICGW
  • O-CSCF O-CSCF
  • the network element is not limited to a CSCF.
  • the invention can also be applied to other network elements which can be switched between different modes.
  • CPS Call Processing Server
  • the invention can also the applied to a Home Subscriber Server (HSS).
  • HSS Home Subscriber Server
  • the HSS can be seen to contain the following modes: Registration functionality, Location Update functionality, Location Request functionality, and Retrieval of Subscriber Profile functionality.
  • This invention can directly be applied also to HSS to help it to switch to the correct mode when a message is received.
  • HSS HSS
  • the first embodiment has to be modified such that a message received by the HSS contains a flag that tells what has been done.
  • the HSS deduces what it has to do next. For example HSS receives a message with flag "Registration done” and switches to the mode "Location Update”.
  • the second embodiment has to be modified such that the message received by the HSS contains a flag that tells what has to be done next. For example HSS receives a message with flag "Do Location Update” and switches to the mode "Location Update”.
  • the third embodiment described above has to be modified in this case such that there is a special message for each functionality.
  • the subscriber profile has to be retrieved.
  • the HSS receives the corresponding message it switches to the "Retrieval of Subscriber Profile" mode.
  • the first example not forming part of the present invention described above has to be modified in this case such that there is a special HSS that only does Location Updates. When it receives a message it always switched to the mode "Location Update".
  • the second example not forming part of the present invention described above has to be modified in this case such that there is a special port for each mode. When certain functionality is needed the message is sent to the corresponding port.
  • the third example not forming part of the present invention in this case has to be modified such that there is a special IP address for each mode. When certain functionality is needed the message is sent to the corresponding IP address.
  • the fourth example not forming part of the present invention has to be modified in this case such that there is a special port for each mode. When certain functionality is needed the message is sent from the corresponding port.
  • the fifth example not forming part of the present invention in this case has to be modified such that there is (are) special IP address(es) for each mode. When certain functionality is needed the message is sent from the corresponding IP address.
  • the processes described in the sixth example not forming part of the present invention can be combined with the processes according to one or more of the first to third embodiments.
  • two of the first to third embodiments and the first to fifth second examples not forming part of the present invention can be combined, and when the two procedures lead to different results (due to some kind of failure), a procedure according to the sixth example not forming part of the present invention can be executed.
  • the invention can be applied to any problem where one or more network elements have at least two functionalities, functions, modes, states or alike.
  • the invention is not bound to the IP protocol and its address mechanism.
  • the invention can be applied to other communication protocols and their address mechanisms as well.
  • the IP address is replaced with the address of the new communication protocol.
  • the port which can be seen as subaddress of IP address, is replaced with the subaddress of the new protocol.
  • load sharing may be a problem.
  • the problem arises when there are more than one similar network elements available that can accomplish the same task.
  • the problem becomes more complicated when the tasks are not same in size and when many sources of tasks exist.
  • the load sharing is a method that simply divides each task between the network elements without concerning whether the total load is equally divided among the elements.
  • the load balancing is a method that tries to divide each task between the network elements so that the total load of each element will be equal.
  • the processing of the load sharing/balancing algorithm in order to choose the most optimal network element for the current task can be seen as one mode of the network element. To accomplish the task itself can be seen as another mode of the network element.
  • load sharing/balancing problem Two cases are considered: the first case is that only one or a few network elements can do load sharing/balancing, whereas the second case is that all network elements can do load sharing/balancing.
  • the third example not forming part of the invention describing the gateway method can be applied.
  • the element when receiving a message, the element does the load sharing/balancing and sends the message further to the chosen network element.
  • the element When receiving a special message, the element does the load sharing/balancing and sends a reply message that tells the address where the message has to be sent.
  • the method according to the first embodiment can be applied.
  • the network element when receiving a message the "load sharing/balancing has been done” flag is unset, the network element does load sharing/balancing, sets the “load sharing/balancing has been done” flag and sends further the message to the chosen element.
  • the what-has-to-be-done message solutions i.e. the second embodiment can be applied.
  • the network element When receiving a message, there is a "load sharing/balancing has to be done” flag.
  • the network element does load sharing/balancing, unsets the "load sharing/balancing has to be done” flag and sends further the message to the chosen element.
  • the first example not forming part of the present invention can be applied to the second case.
  • the network element when receiving a message to the default port the network element does load sharing/balancing and sends further the message to the special port of the chosen element.
  • the second example not forming part of the present invention can be applied to the second case.
  • the network element When receiving a message to the default IP address the network element does load sharing/balancing and sends further the message to the special IP address of the chosen element.
  • the third example not forming part of the present invention can be applied to the above-described second case. Then, when receiving a message from the default port the network element does load sharing/balancing and sends further the message from the special port to the chosen element.
  • the fourth example not forming part of the present invention can be applied to the second case.
  • the network element When receiving a message from certain IP addresses the network element does load sharing/balancing and sends further the message from the special IP address to the chosen element.
  • the invention can be applied as described above to the load sharing and load balancing problems in case where the load has to be shared/balanced among several HSS, in case where the load has to be shared/balanced among several I-CSCF, and in case where the load has to be shared/balanced among several CSCF at the registration.
  • HSS HSS case all received messages from I-CSCF and S-CSCF can be seen as load that has to be shared/balanced among HSS network elements.
  • One or more of the HSS network elements may do the sharing/balancing process or there may be a specialized network element for it.
  • Several embodiments can be applied depending on the structure of the solution.
  • call setup messages originating from another network or even from the own network to CSCF network elements capable of functioning in I-CSCF mode can be seen as load that has to be shared/balanced between the CSCF network elements in question.
  • the registrations to the network can be seen as load that has to be shared/balanced among CSCF network elements.
  • a specialized network element or so called proxy may exist to accomplish the sharing/balancing process.
  • the load sharing algorithm can simply be rotation.
  • the proxy chooses the first CSCF for the first registration, the second CSCF for the second registration, the third CSCF for the third registration, the first CSCF for the forth registration, the second CSCF for the fifth registration, and so on.
  • the load balancing can simply be done with the help of a table telling the load of each CSCF.
  • the load balancing algorithm tells the proxy to choose always the CSCF for the registration that has the lowest load at the moment.
  • Each CSCF updates the table of load according to its actual load.
  • the invention can be advantageously applied to the Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • the invention is not limited thereto but can be applied also to other suitable protocols.
  • the decision between the I-CSCF or S-CSCF functionality can be carried out in an alternative way.
  • the CSCF can analyse the SIP message via field and check whether it contains a known node name (i.e., certain gateway node names). Based on these node names it can be determined whether the SPD inquiry (i.e., the S-CSCF functionality) is needed or whether the HSS (UMS) could be inquired directly (i.e., the I-CSCF functionality should be selected).
  • a known node name i.e., certain gateway node names
  • UMS HSS
  • the CSCF 75 checks whether it knows the sending node, i.e., the I-CSCF 73. If this is the case, the CSCF 75 knows that it should act as an S-CSCF.
  • the node name in the set-up message VIA-header is an indicator indicating the status of the call (inquiry done or pending).
  • the SIP Invite message i.e. the call set-up message
  • VIA-header which lists logical names (i.e. domain names) or addresses of nodes that have participated in the routing of the call.
  • the VIA-header of the SIP Invite message can be inspected by a CSCF (I-CSCF or S-CSCF) to determine where the call is coming from and what kind of a call it is question of.
  • CSCF I-CSCF or S-CSCF
  • the kind of the call is meant whether the call is a roaming call i.e. the HSS enquiry has been performed.
  • the possible node types searched from the via header include:
  • the VIA-header can be inspected for existence of possible I-CSCF node names or addresses.
  • the presence of a name of a node acting as an I-CSCF in the via header indicates that the HSS enquiry has been performed.
  • the VIA-header contains node names or a node addresses referring to at least one proxy node between the first and the second network which is dedicated for handling of incoming calls where the subscription of the called party is in the second network.
  • the HSS enquiry has been performed in the first network and the called subscriber is roaming in the second network
  • the CSCF in the second network can determine by analysing the via header the types of proxies that have routed the call. Depending on the proxy names or addresses it can determine whether the HSS enquiry has been performed or not.
  • the seventh embodiment can be applied to the second case.
  • the network element When receiving a message from certain IP addresses the network element does load sharing/balancing and sends further the message from the special IP address to the chosen element.
  • the invention can be applied as described above to the load sharing and load balancing problems in case where the load has to be shared/balanced among several HSS, in case where the load has to be shared/balanced among several I-CSCF, and in case where the load has to be shared/balanced among several CSCF at the registration.
  • HSS HSS case all received messages from I-CSCF and S-CSCF can be seen as load that has to be shared/balanced among HSS network elements.
  • One or more of the HSS network elements may do the sharing/balancing process or there may be a specialized network element for it.
  • Several embodiments can be applied depending on the structure of the solution.
  • call setup messages originating from another network or even from the own network to CSCF network elements capable of functioning in I-CSCF mode can be seen as load that has to be shared/balanced between the CSCF network elements in question.
  • the registrations to the network can be seen as load that has to be shared/balanced among CSCF network elements.
  • a specialized network element or so called proxy may exist to accomplish the sharing/balancing process.
  • the load sharing algorithm can simply be rotation.
  • the proxy chooses the first CSCF for the first registration, the second CSCF for the second registration, the third CSCF for the third registration, the first CSCF for the forth registration, the second CSCF for the fifth registration, and so on.
  • the load balancing can simply be done with the help of a table telling the load of each CSCF.
  • the load balancing algorithm tells the proxy to choose always the CSCF for the registration that has the lowest load at the moment.
  • Each CSCF updates the table of load according to its actual load.
  • the invention can be advantageously applied to the Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • the invention is not limited thereto but can be applied also to other suitable protocols.
  • the decision between the I-CSCF or S-CSCF functionality can be carried out in an alternative way.
  • the CSCF can analyse the SIP message via field and check whether it contains a known node name (i.e., certain gateway node names). Based on these node names it can be determined whether the SPD inquiry (i.e., the S-CSCF functionality) is needed or whether the HSS (UMS) could be inquired directly (i.e., the I-CSCF functionality should be selected).
  • a known node name i.e., certain gateway node names
  • UMS HSS
  • the CSCF 75 checks whether it knows the sending node, i.e., the I-CSCF 73. If this is the case, the CSCF 75 knows that it should act as an S-CSCF.
  • the node name in the set-up message VIA-header is an indicator indicating the status of the call (inquiry done or pending).
  • the SIP Invite message i.e. the call set-up message
  • VIA-header which lists logical names (i.e. domain names) or addresses of nodes that have participated in the routing of the call.
  • the VIA-header of the SIP Invite message can be inspected by a CSCF (I-CSCF or S-CSCF) to determine where the call is coming from and what kind of a call it is question of.
  • CSCF I-CSCF or S-CSCF
  • the kind of the call is meant whether the call is a roaming call i.e. the HSS enquiry has been performed.
  • the possible node types searched from the via header include:
  • the VIA-header can be inspected for existence of possible I-CSCF node names or addresses.
  • the presence of a name of a node acting as an I-CSCF in the via header indicates that the HSS enquiry has been performed.
  • the VIA-header contains node names or a node addresses referring to at least one proxy node between the first and the second network which is dedicated for handling of incoming calls where the subscription of the called party is in the second network.
  • the HSS enquiry has been performed in the first network and the called subscriber is roaming in the second network
  • the CSCF in the second network can determine by analysing the via header the types of proxies that have routed the call. Depending on the proxy names or addresses it can determine whether the HSS enquiry has been performed or not.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Materials For Photolithography (AREA)
  • Transition And Organic Metals Composition Catalysts For Addition Polymerization (AREA)
  • Medicines Containing Plant Substances (AREA)
  • Burglar Alarm Systems (AREA)
  • Networks Using Active Elements (AREA)

Claims (18)

  1. Système de réseau comprenant :
    un réseau sans fil,
    un premier élément de réseau (2) et au moins
    un deuxième élément de réseau (3), les éléments de réseau étant des dispositifs effectuant des fonctions de contrôle d'état d'appel, le deuxième élément de réseau (3) étant apte à fonctionner dans au moins deux modes différents, dans lequel
    le premier élément de réseau (2) est apte à envoyer un message au deuxième élément de réseau,
    le deuxième élément de réseau (3) est apte à régler le mode en réponse à la question de savoir si des que les informations sont incluses ou pas dans le message, les informations indiquant si un traitement d'une demande de localisation doit être effectué ou a été effectué.
  2. Système de réseau selon la revendication 1, dans lequel le premier élément de réseau (2) est apte à envoyer le message sans les informations concernant la procédure, et
    le deuxième élément de réseau (3) est apte à se régler dans un premier mode et à effectuer la procédure en réponse à la réception du message sans les informations.
  3. Système de réseau selon la revendication 2, comprenant en outre un troisième élément de réseau (5), dans lequel
    le deuxième élément de réseau (3) est apte à envoyer un message au troisième élément de réseau (5) comprenant des informations selon lesquelles la procédure a été effectuée, et
    le troisième élément de réseau (5) est apte à se régler dans un deuxième mode en réponse à la réception du message comprenant les informations selon lesquelles la procédure a été effectuée.
  4. Système de réseau selon la revendication 1, dans lequel
    le premier élément de réseau (22) est apte à envoyer le message comprenant les informations selon lesquelles la procédure doit être effectuée, et
    le deuxième élément de réseau (23) est apte à se régler dans un premier mode et à effectuer la procédure en réponse à la réception du message comprenant les informations.
  5. Système de réseau selon la revendication 4, comprenant en outre un troisième élément de réseau (25), dans lequel
    le deuxième élément de réseau (23) est apte à envoyer un message au troisième élément de réseau (25) sans information concernant la procédure, et
    le troisième élément de réseau (25) est apte à se régler dans le deuxième mode en réponse à la réception du message sans information concernant la procédure.
  6. Système de réseau selon la revendication 4, dans lequel le deuxième élément de réseau (33) est apte à effectuer la procédure en réponse à la réception du message contenant les informations selon lesquelles la procédure doit être effectuée, et à envoyer un résultat de la procédure au premier élément de réseau (32).
  7. Système de réseau selon la revendication 6, comprenant en outre un troisième élément de réseau (35), dans lequel
    le premier élément de réseau (32) envoie un message sans information concernant la procédure au troisième élément de réseau, et
    le troisième élément de réseau (35) est apte à se régler dans un deuxième mode en réponse à la réception du message sans information concernant la procédure.
  8. Système de réseau selon la revendication 1, dans lequel le message est un message d'établissement d'appel.
  9. Système de réseau selon la revendication 1, dans lequel les informations concernant la procédure sont incluses dans un drapeau à l'intérieur du message.
  10. Système de réseau selon la revendication 1, dans lequel les informations concernant la procédure sont obtenues en inspectant l'en-tête VIA du message.
  11. Système de réseau selon la revendication 8, comprenant en outre des moyens pour effectuer un accès à une base de données (94 ; 104) pour obtenir des informations concernant un abonné auquel une configuration doit être envoyée et pour décider du mode du deuxième élément de réseau (83 ; 93) sur la base des informations obtenues.
  12. Procédé de commande d'un élément de réseau, dans lequel l'élément de réseau (3) est un dispositif effectuant des fonctions de commande d'état d'appel et est apte à fonctionner dans au moins deux modes différents dans un réseau sans fil, le procédé comprenant les étapes consistant à :
    recevoir un message ;
    extraire des informations du message concernant un traitement d'une demande de localisation qui doit être effectuée ou qui a été effectuée ; et
    décider du mode à régler pour l'élément de réseau sur la base des informations extraites.
  13. Procédé selon la revendication 12, dans lequel le message est un message de configuration.
  14. Procédé selon la revendication 12, dans lequel la procédure est obtenue en inspectant l'en-tête VIA du message.
  15. Procédé selon la revendication 14, comprenant en outre l'étape consistant à accéder à une base de données (94 ; 104) pour obtenir des informations concernant un abonné auquel une configuration doit être envoyée et pour décider du mode du deuxième élément de réseau (83 ; 93) sur la base des informations obtenues.
  16. Elément de réseau, dans lequel l'élément de réseau (3) est un dispositif effectuant des fonctions de contrôle d'état d'appel et est apte à fonctionner dans au moins deux modes différents dans un réseau sans fil, dans lequel l'élément de réseau (3) est apte à :
    recevoir un message ;
    extraire des informations du message concernant un traitement d'une demande de localisation qui doit être effectuée ou qui a été effectuée ; et
    décider du mode à régler pour l'élément de réseau sur la base des informations extraites.
  17. Elément de réseau selon la revendication 16, dans lequel le message est un message de configuration.
  18. Elément de réseau selon la revendication 16, dans lequel l'élément de réseau est apte à obtenir la procédure en inspectant l'en-tête VIA du message.
EP00956306A 2000-07-26 2000-07-26 Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf Expired - Lifetime EP1305913B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE60042861T DE60042861D1 (de) 2000-07-26 2000-07-26 Verfahren und Vorrichtung zur Bestimmung wenn eineen sollte
EP06118611A EP1718018B1 (fr) 2000-07-26 2000-07-26 Système et procédé pour déterminer si un CSCF doit agir comme I-CSCF ou comme S-CSCF

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2000/007203 WO2002009365A1 (fr) 2000-07-26 2000-07-26 Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf

Related Child Applications (1)

Application Number Title Priority Date Filing Date
EP06118611A Division EP1718018B1 (fr) 2000-07-26 2000-07-26 Système et procédé pour déterminer si un CSCF doit agir comme I-CSCF ou comme S-CSCF

Publications (2)

Publication Number Publication Date
EP1305913A1 EP1305913A1 (fr) 2003-05-02
EP1305913B1 true EP1305913B1 (fr) 2009-09-02

Family

ID=8164038

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00956306A Expired - Lifetime EP1305913B1 (fr) 2000-07-26 2000-07-26 Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf

Country Status (7)

Country Link
US (1) US7602762B1 (fr)
EP (1) EP1305913B1 (fr)
AT (2) ATE442025T1 (fr)
AU (1) AU2000268296A1 (fr)
DE (1) DE60042898D1 (fr)
ES (1) ES2329438T3 (fr)
WO (1) WO2002009365A1 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7769374B2 (en) 2001-03-12 2010-08-03 Son Phan-Anh Recovery techniques in mobile networks
US20040243711A1 (en) * 2001-09-11 2004-12-02 Jaakko Rajaniemi Method, system and network element for controlling data transmission in a network environment
WO2003058913A1 (fr) * 2002-01-10 2003-07-17 Nokia Corporation Procede et systeme de procuration d'un message
GB0205399D0 (en) * 2002-03-07 2002-04-24 Nokia Corp Allocation of an S-CSCF to a subscriber
EP2276218B1 (fr) 2003-02-19 2015-10-28 Nokia Technologies Oy Acheminement de messages via un système IMS
EP1597896A2 (fr) * 2003-02-19 2005-11-23 Nokia Corporation Acheminement de messages
GB0306863D0 (en) * 2003-03-25 2003-04-30 Nokia Corp Service provisioning in a communication system
KR100807863B1 (ko) * 2003-03-25 2008-02-27 노키아 코포레이션 통신 시스템에서의 서비스 제공
US8817772B2 (en) 2003-07-02 2014-08-26 Nokia Corporation Function mode routing
EP1654853B1 (fr) * 2003-07-02 2008-11-26 Nokia Corporation Routage en mode fonction
US8929360B2 (en) * 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
EP2380338B1 (fr) * 2008-12-23 2018-02-14 Telefonaktiebolaget LM Ericsson (publ) Établissement d'un appel d'un réseau non ims à un réseau ims, la passerelle s'interfaçant avec l'hss

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5109220A (en) 1989-03-15 1992-04-28 Motorola, Inc. Selective call controller
US5111451A (en) 1989-10-27 1992-05-05 Crystal Semiconductor Method and apparatus for synchronizing an optical transceiver over a full duplex data communication channel
US5612950A (en) 1993-05-27 1997-03-18 Rockwell International Corporation Managing communication on an unstable error-prone channel
FI108829B (fi) 1998-04-02 2002-03-28 Nokia Corp Menetelmä pakettiverkossa

Also Published As

Publication number Publication date
AU2000268296A1 (en) 2002-02-05
WO2002009365A1 (fr) 2002-01-31
EP1305913A1 (fr) 2003-05-02
US7602762B1 (en) 2009-10-13
ES2329438T3 (es) 2009-11-26
ATE442025T1 (de) 2009-09-15
ATE441307T1 (de) 2009-09-15
DE60042898D1 (de) 2009-10-15

Similar Documents

Publication Publication Date Title
US9210224B2 (en) Service provisioning in a communication system
CN101142833B (zh) 用于控制电路交换域用户终端接入ims通信网服务的设备
EP1700499B1 (fr) Procede et systeme de communication permettant de decouvrir automatiquement la capacite de service multimedia
RU2377731C2 (ru) Способ и система для поиска сетевых адресов в гибридных сетях связи
KR100796375B1 (ko) 통신 시스템 내의 제어기 엔티티에서 들어오는 요청들을 프로세싱하는 방법, 통신 시스템, 엔티티, 및 사용자 정보 저장부
EP1741277B1 (fr) Système de traitement d'evenements
US7925762B1 (en) Roaming support method and systems in UMTS
US11824903B2 (en) Voice service restoration after element failure
US20110222532A1 (en) Routing A Call Setup Request To A Destination Serving Node In An IMS Network
WO2006077587A2 (fr) Convergence de services dans plusieurs domaines de communication
EP1953973B1 (fr) Réseau de commutation de dispositif de service, procédé de commutation et routeur de service
EP1305913B1 (fr) Systeme et procede pour determiner si un cscf doit agir comme i-cscf ou comme s-cscf
US20220060521A1 (en) Automated IPv4-IPv6 Selection for Voice Network Elements
EP2759098B1 (fr) Procédé et dispositif pour configurer des paramètres de service relatifs à un abonné mobile
KR100807863B1 (ko) 통신 시스템에서의 서비스 제공
KR20030055417A (ko) Ｉｐ 멀티미디어 서비스 가입자의 이동성 관리를 위한가입자 데이터 관리 장치 및 방법
EP1718018B1 (fr) Système et procédé pour déterminer si un CSCF doit agir comme I-CSCF ou comme S-CSCF
EP1944945A1 (fr) Système de communication avec une mobilité d'abonné transparente basée sur l'enregistrement de groupe
JP2006521717A5 (fr)

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: 20030225

AK Designated contracting states

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20031120

17Q First examination report despatched

Effective date: 20031120

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 88/06 20090101AFI20090212BHEP

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 CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

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: 60042898

Country of ref document: DE

Date of ref document: 20091015

Kind code of ref document: P

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2329438

Country of ref document: ES

Kind code of ref document: T3

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

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: 20090902

Ref country code: FI

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: 20090902

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

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: 20090902

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

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: 20090902

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

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: 20100104

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: 20090902

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: 20090902

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: 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: 20090902

26N No opposition filed

Effective date: 20100603

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

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: 20091203

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

Ref country code: MC

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

Effective date: 20100731

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

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

Effective date: 20100726

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20110331

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

Ref country code: CH

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

Effective date: 20100731

Ref country code: LI

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

Effective date: 20100731

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: 20100802

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

Ref country code: DE

Payment date: 20110131

Year of fee payment: 11

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: 20100726

Ref country code: GB

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

Effective date: 20100726

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: 20120201

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60042898

Country of ref document: DE

Effective date: 20120201

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: 20100726

REG Reference to a national code

Ref country code: ES

Ref legal event code: PC2A

Owner name: NOKIA TECHNOLOGIES OY

Effective date: 20151124

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

Ref country code: ES

Payment date: 20190801

Year of fee payment: 20

Ref country code: IT

Payment date: 20190719

Year of fee payment: 20

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20201105

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 EXPIRATION OF PROTECTION

Effective date: 20200727