| JPS58114550 | LINE SWITCHING DEVICE |
| JP2637544 | [Title of Invention] Transmission end signal repair device |
| JPH07212277 | LINE SWITCHING SYSTEM |
SHEN JIADONG (DE)
WIEHE ULRICH (DE)
LEIS PETER (DE)
SHEN JIADONG (DE)
WIEHE ULRICH (DE)
HUAWEI: "Reassignment for S-CSCF during the terminated call procedure, Tdoc S2-060216", 3GPP TEMPORARY DOCUMENT, 16 January 2006 (2006-01-16) - 20 January 2006 (2006-01-20), pages 1 - 2, XP002430232, Retrieved from the Internet
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents (3GPP TS 29.228 version 7.3.0 Release 7); ETSI TS 129 228", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-CN4, no. V730, September 2006 (2006-09-01), pages 1 - 57, XP014035668, ISSN: 0000-0001
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Cx and Dx interfaces based on the Diameter protocol; Protocol details (3GPP TS 29.229 version 7.3.0 Release 7); ETSI TS 129 229", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-CN4, no. V730, September 2006 (2006-09-01), pages 1 - 27, XP014035670, ISSN: 0000-0001
Claims
1. A method for re-assigning Serving Call Session Control Function, S-CSCF, services to a user of a Home Subscriber Server, HSS (200, 300), in a Third Generation Partnership
Project , 3GPP, telecommunications network, comprising: i) assigning a first S-CSCF (203) to the user during a registration procedure; ii) uploading dynamic registration information (204) from the first S-CSCF (203) to the HSS (200, 300) during the registration procedure; iii) storing the dynamic registration information (204) in the HSS (200, 300) ; and iv) downloading the stored dynamic registration information (204) from HSS (200, 300) to a second S-CSCF (303) during a re-assignment procedure of the user.
2. The method of claim 1 further characterized in that, providing the re-assignment information to a Proxy Call Session Control Function, P-CSCF, which acts as an outbound proxy for an IMS terminal .
3. The method of claim 1 or 2, wherein the step of uploading dynamic registration information to the HSS (200, 300) is performed a via Cx-SAR/SAA, Server Assignment Request/ Server Assignment Answer, operation, which automatically includes the dynamic registration information (204) in the request.
4. The method of claim 3, wherein every new Cx-SAR request triggers the dynamic registration information stored at the
HSS (200, 300) to be updated.
5. The method of claim 4, wherein if no dynamic registration information is contained at a Cx-SAR request, the existing one stored at the HSS (200, 300) is deleted.
6. The method of any of claims 1 - 5, wherein S-CSCF reassignment for a registered IMS users via the extended Cx- SAR/SAA operation is further characterized in that, when the new S-CSCF (303) is selected and receives a non- REGISTER request (301) for an unknown IMS user, the new S- CSCF (303) treats the user as an unregistered user and downloads a user profile from the HSS (200, 300) via the Cx- SAR request (301) .
7. The method of claim 6, wherein the HSS (200, 300) shall check whether the registration status of the IMS user at the
HSS is "registered",
If it is the case that the user is registered, but in the Cx- SAR request the user is marked as "unregistered", the HSS recognizes the inconsistence between the HSS and the S-CSCF about the registration status of the IMS user.
8. The method of claim 7, the HSS (200, 300) checks whether dynamic registration information is stored at the HSS for this user, if it is the case that dynamic registration information is stored at the HSS for this user, the HSS shall further treat the IMS user as "registered" and provide the stored registration information to the S-CSCF (303) in the Cx-SAA response (302), together with the user profile.
9. The method of claim 8, if it is not the case that dynamic registration information is stored at the HSS for this user, the HSS shall treat the user as "unregistered" and only provides the user profile to the S-CSCF (303), and when the S-CSCF (303) receives the dynamic registration information from the HSS, it knows that the user was already registered in IMS, the S-CSCF (303) shall treat the IMS user as "registered" and build all necessary information for serving a registered IMS user from the received dynamic registration information.
10. The method of claim 2, wherein the step of providing the S-CSCF assignment information to the P-CSCF via the extended procedure for the subscription of a Reg Event package is further characterized in that, sending by the P-CSCF 400 a SIP SUBSCRIBE request (401) to the I-CSCF which then forwards the SIP SUBSCRIBE request to the newly selected S-CSCF (403), providing by the S-CSCF-2 the S-CSCF assignment information
(402) to the P-CSCF updating by he P-CSCF the stored S-CSCF assignment information, which the P-CSCF uses to connect the IMS user with the newly assigned S-CSCF-2.
11. The method of any of claims 1 - 10, wherein the dynamic registration information (204) comprises information created during the registration procedure.
12. The method of any of claims 1 - 11, wherein the dynamic registration information (204) comprises at least one of
- a binding address
- a binding duration - a path header value
- Contact header
- Expires header or parameter.
13. A Home Subscriber Server, HSS, (200, 300) in an Internet Protocol, IP, Multimedia subsystem, IMS, configured to:
- receive dynamic registration information from a first Serving Call Session Control Function, S-CSCF (203) , during a registration procedure of a user;
- store the dynamic registration information;
- receive a request from a second Serving Call Session Control Function, S-CSCF (303) requesting a user profile for the user - transmit, responsive to receiving the request, the dynamic registration information to the second Serving Call Session Control Function, S-CSCF (303) .
14. The Home Subscriber Server, HSS, (200, 300) of claim 13, configured to transmit the dynamic registration information to the second Serving Call Session Control Function, S-CSCF (303), only if following conditions are met:
- registration status of the user according to Home Subscriber Server, HSS, (200, 300) database indicates that the user is registered, and
- in the received request the user is marked as unregistered.
15. The Home Subscriber Server, HSS, (200, 300) of claim 13 or 14, configured to update the stored dynamic registration information if updated dynamic registration information is received from the first Serving Call Session Control Function, S-CSCF (203) , during the registration procedure of the user.
16. The Home Subscriber Server, HSS, (200, 300) of any of claims 13 - 15, configured to delete the stored dynamic registration information if no dynamic registration information is received from the first Serving Call Session Control Function, S-CSCF (203) , during the registration procedure of the user.
17. The Home Subscriber Server, HSS, (200, 300) of any of claims 13 - 16, wherein the dynamic registration information comprises at least one of:
- a binding address
- a binding duration
- a path header value - Contact header
- Expires header or parameter.
18. A Serving Call Session Control Function, S-CSCF (203) in an Internet Protocol, IP, Multimedia subsystem, IMS, configured to:
- send dynamic registration information to a Home Subscriber Server, HSS, (200, 300), during a registration procedure of a user;
19. A Serving Call Session Control Function, S-CSCF (203), of claim 18 configured to send the dynamic registration information to the Home Subscriber Server, HSS, (200, 300) in a request requesting a user profile of the user.
20. The Serving Call Session Control Function, S-CSCF (203), of any of claims 18 - 19, wherein the dynamic registration information comprises at least one of:
- a binding address
- a binding duration - a path header value
- Contact header
- Expires header or parameter.
21. The Serving Call Session Control Function, S-CSCF (203), of any of claims 18 - 20, further configured to provide reassignment information to a Proxy Call Session Control Function, P-CSCF, in response to a request from the Proxy Call Session Control Function, P-CSCF. |
Description
METHOD FOR RE-ASSIGNMENT OF S-CSCF SERVICES TO REGISTERED IMS USERS OF A HOME SUBSCRIBER SERVERS HSS
Within the IM CN subsystem IMS as defined by 3GPP the so called Serving Session Control Function S-CSCF is the central point to users that are hosted by this S-CSCF. According to 3GPP TS 23.228 the S-CSCF provides these services to registered and unregistered users when it is assigned to these users. This assignment is stored in the Home Subscriber Server HSS.
Though mechanisms at the network element layer, such as a cluster solution, could be used to improve the reliability of the S-CSCF, it is necessary to have a failover mechanism at the network layer to ensure the availability of the network. Thus, S-CSCF re-assignment is made possible.
The situation is shown in Figure 1. For registered users, the assignment of the S-CSCF normally occurs when an IMS user tries to register with the IMS via sending a SIP REGISTER request to the S-CSCF. First, a temporary assignment is created via Cx-MAR/MAA operation during the authentication procedure within the registration procedure.
After successful authentication, the S-CSCF 103 treats the IMS user as a registered user and confirms the S-CSCF assignment via a Cx-SAR/SAA operation 101, 102 to an HSS 104.
Otherwise in case of authentication failure, the temporary assignment is removed via a Cx-SAR/SAA operation.
Problematically, in 3GPP TS 23.228 an S-CSCF re-assignment for a registered user is only possible when the next registration procedure (via Cx-MAR/MAA operation) occurs. However, an S-CSCF re-assignment by a non-REGISTER request via Cx-SAR/SAA operation is not possible according to the standard.
As a result, when the currently assigned S-CSCF is not available for a registered user, temporarily or permanently, no service can be provided for this registered user until the next registration procedure.
It has been previously proposed to piecewise solve this problem. This problem could be limited, for example, to a certain scale if the registration timer for re-registration is set to a very small value. But this cannot solve the problem. After an S-CSCF failure, no service can be provided before the next re-registration. At any rate, having a very short re-registration timer would increase the traffic on the air interface, which is clearly disadvantageous.
Fig. 1 illustrates the prior art,
Fig. 2 illustrates inserting the dynamic information in the Cx-SAR Request according to the invention,
Fig. 3 illustrates the situation where the user is unregistered,
Fig. 4 illustrates illustrates the P-CSCF SIP subscribe request,
Figs. 5 and 6 illustrate an originating request for a registered user / unregistered user can be delivered when the previously assigned S-CSCF is not available, and
Fig. 7 and 8 illustrate a terminating request for a registered user / unregistered user can be delivered when the previously assigned S-CSCF is not available.
The idea of this proposal is i) to upload dynamic registration information from S-CSCF to HSS during registration procedure; ii) to download the stored dynamic registration information from HSS to S-CSCF during re-
assignment procedure; iii) provide the re-assignment information to the P-CSCF, which acts as the outbound proxy for a IMS terminal .
Dynamic registration information is the information created during the registration procedure. In normal practice, this includes basically the binding address, binding duration, path header value, etc. However, dynamic information can be extended in future, it is possible that depending on the recovery concept of the CSCF part or whole information created during the registration procedure are uploaded in HSS, e.g. binding address (contact header), binding duration (expires header/parameter), path header, etc.
The information is dynamic because they are not statically configured at CSCF. They are generated when a terminal registers with IMS. Lots of the values are provided by the clients or other IMS NEs like P-CSCF, e.g. binding address or Path header value.
The basic idea of the invention for registered users is to upload all necessary information in HSS, which are not statically configured in CSCF/HSS and needed for a proper recovery of CSCF. Since HSS is a database application, the HSS has non-volatile memory any way. With this invention, it is not necessary anymore to use non-volatile memory in CSCF to store such information for a possible recovery.
The following advantages are provided by the proposal described:
• an automatic mechanism of S-CSCF failover can be provided to registered IMS users. No involvement of service staff of operators is required. Therefore no additional OPEX will be generated.
• The failover procedure only takes place when a request for a registered IMS user arrives. This can avoid a possible
overload situation at the HSS caused by the administrative removal of the S-CSCF, where a flood of requests will be sent from the HSS to the previously assigned S-CSCF to remove the assignment .
the existing Cx-SAR/SAA and Cx-LIR/LIA operations and the procedure of the subscription for Reg Event package are re-used with extensions. This will only cause limited impact on the existing specification/implementations.
• The proposal is easily to be verified by checking the Cx-SAR/SAA and Cx-LIR/LIA message and SIP SUBSCRIBE/NOTIFY request/response for Reg Event package.
The specification shall make reference to the following abbreviations .
CSCF Call Session Control Function
S-CSCF Serving CSCF P-CSCF Proxy CSCF
I-CSCF Interrogating CSCF
HSS Home Subscriber Server
IMS IP Multimedia Subsystem
3GPP 3rd Generation Partnership Project LIR Location Information Request
LIA Location Information Answer
SAR Server Assignment Request
SAA Server Assignment Answer
RTR Registration Termination Request RTA Registration Termination Answer
PPR Push Profile Request
PPA Push Profile Answer
PSI Public Service Identity
AS Application Server
Now the present invention will be described in more detail with reference to Figure 2.
The first step is to Upload dynamic registration information to HSS via Cx-SAR/SAA operation. By requesting a user profile via a Cx-SAR request 201 to the HSS 200, the S-CSCF 203 shall also include the dynamic registration information 204 in the request..
This is different to the current procedures as described in 3GPP TS 23.228 where no dynamic registration information can be uploaded to HSS via the Cx-SAR request. In addition, every new Cx-SAR request will cause the dynamic registration information stored at the HSS to be updated. If no dynamic registration information is contained at a Cx-SAR request, the existing one stored at the HSS shall be deleted.
Next, the S-CSCF reassignment for registered IMS users via the extended Cx-SAR/SAA operation as shown in Figure 3.
When a new S-CSCF 303 is selected and receives a non-REGISTER request 301 for an unknown IMS user, the S-CSCF 303 will treat the user as an unregistered user and will try to download user profile from the HSS 300 via Cx-SAR request 301, according to current IMS specification.
The HSS shall check whether the registration status of the IMS user at the HSS is "registered". If it is the case, but in the Cx-SAR request the user is marked as "unregistered", the HSS can recognize the inconsistence between the HSS and the S-CSCF about the registration status of the IMS user. It shall then check whether dynamic registration information is stored at the HSS for this user. If it is the case, the HSS shall further treat the IMS user as "registered" and provide the stored registration information to the S-CSCF in the Cx- SAA response 302, together with the user profile.
If it is not the case, the HSS shall treat the user as
"unregistered" and only provide the user profile to the S- CSCF. And when the S-CSCF receives the dynamic registration information from the HSS, it knows that the user was already
registered in IMS. Hence, the S-CSCF shall treat the IMS user as "registered" and build all necessary information for serving a registered IMS user from the received dynamic registration information.
Providing the S-CSCF assignment information to the P-CSCF via the extended procedure for the subscription of a Reg Event package will now be described with reference to Figure 4.
A user registered with the IMS user always accesses the IMS via a P-CSCF 400, which acts as an outbound proxy. In order to be capable of providing IMS services for the IMS user the P-CSCF 400 must be aware of the S-CSCF re-assignment. This is because it needs to know the so called Service Route information which points to the next hop, i.e. the S-CSCF
403. 3GPP TS 23.228 that the P-CSCF 400 gets this information based on the SIP the registration procedure, i.e. via Service-Route header contained in the 200 OK to the SIP REGISTER request.
Therefore it is suggested in this proposal to define an additional procedure to inform the P-CSCF about the Service Route information. It is proposed to extend the existing procedure for the subscription to the Reg Event package to provide the S-CSCF re-assignment information (e.g. Service- Route header) to the P-CSCF.
When the P-CSCF recognizes that the previously assigned S- CSCF for an IMS user has been changed (e.g. a terminating request is sent by a different S-CSCF as the assigned one, or the previously assigned S-CSCF does not react to an originating request sent by the P-CSCF) , the P-CSCF shall subscribe to the Reg-Event Package or any other suitable event package for the IMS user again (Whether or not the Reg- Event Package is suitable for this procedure is out of scope of the patent) .
The P-CSCF 400 shall send a SIP SUBSCRIBE request 401 to the I-CSCF which then forwards the SIP SUBSCRIBE request to the newly selected S-CSCF 403 (e.g. S-CSCF-2) . The S-CSCF-2 shall then provide the S-CSCF assignment information 402 to the P- CSCF (whether the information shall be contained in the 200 response to the SUBSCRIBE request or the body of the following NOTIFY request sent from the S-CSCF-2 to the P-CSCF is out of scope of this patent) . The P-CSCF shall then update its stored S-CSCF assignment information. With this updated S-CSCF assignment information, the P-CSCF is able to connect the IMS user with the newly assigned S-CSCF.
The proposal suggested here may also be used together with the S-CSCF re-selection procedure for unregistered user.
In the following it is described how an originating request (see Figure 5&6) or a terminating request (see Figure 7&8) for a registered user can be delivered when the previously assigned S-CSCF is not available.
In Figure 5, a UE 514 sends an SIP Request 501 to the P-CSCF 515, which in turn sends an SIP request 502 to the S-CSCF-I. 503 indicates that an S-CSCF is unavailable and an unsubscribe Reg-Event package 504 is initiated to the S-CSCF- 1 518. A subscribe Re-Event package is forwarded between the P-CSCF 5125 and the I-CSCF 516, which in turn sends an Cx-LIR (UserID) 506 to the HSS 517. The HSS 517, in response, sends an Cx-LIA (S. CSCF-I) message 507 back to the I-CSCF 516, which in turn sends a subscribe reg-Event package (UserID) message 508 to the S-CSCF-I 518. 509 indicates that the S- CSCG-I is unavailable and a Cx-LIR (UserID, CapFlag) message
510 is sent to the HSS 517. The Hss 517 sends a Cx-LIA(Cap.)
511 to the I-CSCF 516. 512 indicates that the S-CSCF-2 is re-selected according to capabilities and the subscribe Reg- Event package (UserID) 508 is sent to the S-CSCF 519.
In Figure 6, after an initial SIP request 601, it is discovered that the exists an unknown User that is
unregistered 609. The S-CSF-2 619 sends Cx-SAR (UserID, Unregistered) message 610 to the HSS 617, which in turn sends an Cx-SAA (Profile, Reglnfo) message 611 to the S-CSCF-2 619. 612 indicates that the dynamic registration information is to be restored and an OK to Subscribe request (S-CSCF
Assignment) message 613 is sent to the I-CSCF 616, which in turn sends an OK (SUB) message 614 to the P-CSCF 618. 615 indicates that there is an update of an S-CSCF assignment and an SIP request 616 is sent to the S-CSCF-2. At which point originating services for IMS User are conducted as indicated by 617.
In Figure 7, an incoming SIP Request 701 is received by the I-CSCF 716 and the HSS 715 sends an Cx-LIR (UserID) message 702 to the I-CSCF 716. In return, a Cx-LIA message 703 is sent to the HSS 715 and an SIP Request 704 is sent to the S- CSCF-I 714. 705 indicates that the S-CSCF-I is unavailable and the HSS 715 sendsan Cx-LIR (UserID, CapFlag) 706 to the I-CSCF 716, which in turn sends a Cx-LIA (Cap.) message 707 to the HSS 715. 708 indicates that the S-CSCF-2 is reselected according to its capabilities and the I-CSCF 716 sends an SIP Request 709 to the S-CSCF-2 713. 710 indicates an unknown user is unregistered and the S-CSCF 2 713 sends an Cx-SAR (UserID, Unregistered) message 711 to the HSS 715, which in turn returns an Cx-SAA (Profile, Reglnfo) message 712 to the S-CSCF-2 713.
In Figure 8, 813a indicates that dynamic registration information is restored and 813b indicates terminating services for the IMS is conducted. The S-CSCF-2 806 sends an incoming SIP request 814 to the P-CSCF 802. 815 indicates the change of the S-CSCF is identified and an unsubscribe Reg-Event package 816 is initiated between the P-CSCF 802 and the S-CSCF-I 805. The P-CSCF 802 sends a subscribe Reg-Event package 817 to the I-CSCF 803, which in turn sends a Cx-
LIR(UserιD) message 818 to the HSS 804. The HSS 804 sends an Cx-LIA(S-CSCF-2) message 819 to the I-CSCF 803, which in turn sends a subscribe Reg-Event package (UserID) message 820 to
the S-CSCF 806. The S-CSCF-2 806 sends an OK to subscribe request message 821 to the I-CSCF 803, which in turn sends an OK (SUB) message 822 to the P-CSCF 802. Then the P-CSCF 802 sends the SIP request 823 to the UE.