Title of Invention

A METHOD OF HANDLING SUPPLEMENTARY SERVICES IN AN IP MULTIMEDIA SUB-SYSTEM

Abstract

The proposed invention relates to novel method for providing supplementary services in IP Multimedia Sub-system and particularly it relates to procedures between CSCF, HSS and AS, wherein HSS shall not add the initial filter Criteria (containing AS name as CF-AS) for the user unless and until any one of the Call Forwarding services (CFU, CFB, CFNA) is active for the user. The system once activated, HSS shall not remove the intial Filter Criteria (containing AS name as CF-AS) for the user unless and until all the call Forwarding services (CFU, CFB, CFNA) are deactivated by the user.

Full Text

FORM 2 THE PATENTS ACT, 1970 [39 of 1970] & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION (Section 10; Rule 13) A METHOD FOR FEATURE CODE HANDLING BY HSS FOR SUPPLEMENTARY SERVICES IN AN IMS SAMSUNG INDIA SOFTWARE OPERATIONS PVT. LTD., BAGMANE LAKEVIEW, BLOCK ‘BNo. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE - 560093 A wholly owned subsidiary of Samsung Electronics Company Limited, Korea, an Indian Company The following Specification particularly describes the invention and the manner in which it is to be performed FIELD OF THE INVENTION This invention, in general, relates to electronic communication technology providing supplementary services in IP Multimedia Sub-system. Further, this invention relates to procedures between CSCF, HSS and AS. More particularly, this invention relates to a method for feature code handling by HSS for supplementary services in an IMS. DESCRIPTION OF RELATED ART The IP Multimedia Subsystem (IMS) is a standardised Next Generation Networking (NGN) architecture for telecom operators who want to provide mobile and fixed multimedia services. It uses a Voice-over-IP (VoIP) implementation based on a 3GPP standardised implementation of SIP, and runs over the standard Internet Protocol (IP). Existing phone systems (both packet-switched and circuit-switched) are supported. Several types of SIP servers, collectively known as CSCF (Call Session Control Function), are used to process SIP signaling messages in the IMS. Application servers (AS) host and execute services, and interfaces with the S-CSCF using SIP. This allows third party providers an easy integration and deployment of their value added services to the IMS infrastructure. An AS can query the HSS with the DIAMETER Sh interface. There are many ways in IMS to provide supplementary services like Call Forwarding, SMS, etc to the end users in IMS. These supplementary services are generally provided by the AS. According to 3GPP TS 23.218 v6.3.0, all the terminating calls for a user, lands on AS based on Initial Filter Criteria. Then it is the AS whose application logic identifies whether the user is entitled for a service or not. During service creation AS stores the information related to services as Repository Data in HSS and collects it back from the HSS using the Sh-interface PUR and UDR messages respectively. Accordingly it services the user’s request. HSS is the database of user profile for all users. But if any user has to update its service information, then it has to be done using Subsequent Filter Criteria (SFC). However according to the currently available technical specifications documents, it is nowhere mentioned clearly about the subsequent filter criteria and ISC interface between CSCF and AS. To implement supplementary services according to the already existing specifications all the calls have to be diverted to the AS which leads to an undue load on it. Instead if we have the real-time triggering logic at S-CSCF then if the user is not entitled for a service, it will not be forwarded to AS, hence decreasing the load on AS. In US patent, US 20050213606A1, titled ‘Method of triggering application service using response filter criteria and IP multimedia subsystem using the same1, it describes a method and a system for triggering SIP requests based on an rFC. The rFC is activated on the request of a user. The said rFC contains a set of SPT’s which routes a SIP request to a particular AS only if the SIP response message matches the Service Point Triggers (SPTs) of the rFC. This method not only improves the efficiency for call establishment but also improves the flexibility of the S-CSCF. In addition it has also been specified in the patent publication that, the rFC mechanism is compatible with the initial Filter Criteria (iFC) mechanism and this mechanism somewhat reduces the load on the AS. In yet another patent, WO2005027459A1, titled ‘ IMS subscriber access control’, it describes a method in which a user subscribed to a particular service is able to reach that particular AS after crossing a particular set of triggering criteria present at the S-CSCF. For users who are not subscribed for the particular service the HSS is unable to provide their profiles and hence the requests are directed to a default AS. However both the patents do not seem to have any mention of subsequent filter criteria. SUMMARY OF THE INVENTION The proposed invention relates to novel method for providing supplementary services in IP Multimedia Sub-system and particularly it relates to procedures between CSCF, HSS and AS. It is the principal object of the invention to invent a novel method for feature code handling by Home Subscriber Server (HSS) for Supplementary Services in an IP Multimedia Sub-system (IMS) such as Call Forwarding, Absence Service, etc., which is unique. It is another object of the invention to invent and design a novel method for drastic reduction in the load on AS by routing only those subscribers’ call (SIP INVITE message) to AS, who has subscribed for the service. It is another object of the invention to invent a novel method for providing supplementary services in IP Multimedia Sub-system wherein HSS does not add the Initial Filter Criteria (containing AS name as CF-AS) for the user unless and until any one of the Call Forwarding services (CFU, CFB, CFNA) is active for the user. It is yet another object of the invention to invent a novel method to provide supplementary services in IP Multimedia Sub-system wherein once activated, HSS does not remove the Initial Filter Criteria (containing AS name as CF-AS) for the user unless and until all the Call Forwarding services (CFU, CFB, CFNA) are deactivated by the user. Accordingly, this invention explains a method for feature code handling by HSS for supplementary services in an IMS comprising procedures between CSCF, HSS and AS, wherein HSS does not add the Initial Filter Criteria containing AS name as CF-AS for the user unless and until any one of the Call Forwarding services CFU, CFB, CFNA is active for the user and the system once activated, HSS does not remove the Initial Filter Criteria containing AS name as CF-A) for the user unless and until all the Call Forwarding services CFU, CFB, CFNA are deactivated by the user. If a user wants a CFU service the UE sends a SIP-INVITE message to the S-CSCF via P-CSCF. For the activation of the service S-CSCF sends the SIP-INVITE message to AS, where AS parses the To’ header and creates a PUR message and the AS sends the PUR to HSS. HSS will update this Repository data information in its database for the Public User Identity as specified by the User-Identity AVP in PUR message. HSS modifies the user-profile of the IMS Subscription by adding the Initial Filter Criteria (IFC) where the operator specified AS-name (CF-AS) is present in the IFC. The modified profile is sent as User-Data AVP in PPR message to S-CSCF. For the deactivation of the service UE sends SIP-INVITE message to the S-CSCF via P-CSCF. S-CSCF sends the SIP-INVITE message to AS, where AS parses the To1 header and creates a PUR message and the AS sends the PUR to HSS. HSS updates the repository data information in its database for the Public User Identity as specified by the User-Identity AVP in PUR message. HSS modifies the User-profile of the IMS Subscription by deleting the Initial Filter Criteria (IFC) if there is no other Call Forwarding service active for the user. The modified profile is sent as User-Data AVP in PPR message to S-CSCF. For the actual invocation, a user makes a call to another user by sending a SIP INVITE message. UE sends SIP-INVITE message to the S-CSCF of home 1 via the P-CSCF. Looking at the To1 header S-CSCF of home 1forwards this SIP-INVITE message towards the S-CSCF of home2 via the IP-Network. S-CSCF of home2 analyses the Initial Filter Criteria of the profile and sees whether there is any such IFC which is met and if there is any such IFC then the SIP INVITE message is forwarded to the Application Server whose name is written in the IFC. CF-AS fetches the Service Information of that user from HSS and takes the signaling to next steps where it fetches the Repository Data from the HSS using Sh-interface UDR message and HSS provides the FTN to the AS in UDA message. From UDA message, AS fetches the FTN for CFU and AS sends the SIP INVITE to CSCF of home2 by changing the “To” header of the SIP INVITE message. S-CSCF forwards the SIP INVITE to the S-CSCF of home 3 which is the home network for UE3 and S-CSCF of home3 sends SIP INVITE to UE3. These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS Figure 1 depicts the use of feature code to activate/deactivate a service in runtime. Figure 2 depicts the actual invocation of the service (e.g. Call Forwarding) DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. As in the related prior art, the concept of SFC is not defined we have found an alternative approach to implement supplementary services. There are two things in this invention. Firstly, the use of feature code by the user himself to activate/deactivate a service in runtime. Secondly, the actual invocation of the service which shows the message flows between users, CSCF, AS and HSS. For the first part of the invention (as shown in Figure 1), when a user sends a feature code to activate/deactivate a service, it goes to AS (via S-CSCF) where it constructs a PUR and sends it to HSS to update the service information. The change in service information (Repository data) may also change the user profile triggering a PPR to S-CSCF. So, in this way S-CSCF also comes to know about the service information. Let’s take an example. A user (say, sip:[email protected]) wants a “Call Forwarding - Unconditional (CFU)” service. Flow for the activation of the service can be described as below:- 1. UE (sip:[email protected]) sends SIP-INVITE message to the S-CSCF via P- CSCF. [To: tel:*88919448024328] 2. S-CSCF sends the SIP-INVITE message to AS, where AS parses the To’ header and creates a PUR message. 3. AS sends the PUR to HSS. The User-Data AVP of PUR will look like this:- CFU 1 tel:+919448024328 4. HSS will update this Repository data information in its database for the Public User Identity as specified by the User-Identity AVP in PUR message. HSS will modify the User-profile (defined in 3GPP TS 29.228) of the IMS Subscription by adding the Initial Filter Criteria (IFC). The operator specified AS-name (CF-AS) will be present in the IFC. HSS has also to attach a priority to this IFC which will be one more than the maximum value out of the priorities of other IFCs. The modified profile is sent as User-Data AVP in PPR message to S-CSCF. Flow for the deactivation of the service can be described as below: - 1. UE (sip:[email protected]) sends SIP-INVITE message to the S-CSCF via P- CSCF. [To: tel:#88*] 2. S-CSCF sends the SIP-INVITE message to AS, where AS parses the To1 header and creates a PUR message. 3. AS sends the PUR to HSS. The User-Data AVP of PUR will look like this:- CFU 2 DEACTIVATE 4. HSS will update this Repository data information in its database for the Public User Identity as specified by the User-Identity AVP in PUR message. HSS will modify the User-profile (defined in 3GPP TS 29.228) of the IMS Subscription by deleting the Initial Filter Criteria (IFC) if there is no other Call Forwarding service active for the user. The modified profile is sent as User-Data AVP in PPR message to S-CSCF. For the second part of the invention (as shown in Figure 2), the actual invocation, a user (say, sip:[email protected], calling party) makes a call to another user (say, sip:[email protected], called party), by sending a SIP INVITE message. The flow for the invocation of the service can be described as below: - 1. UE (sip:[email protected]) sends SIP-INVITE message to the S-CSCF of home1 via the P-CSCF. The ‘To’ header is sip:[email protected]. 2. Looking at the ‘To’ header S-CSCF of home1 forwards this SIP-INVITE message towards the S-CSCF of home2 via the IP-Network. Obviously, based on the normal procedures defined in RFC 3261 and 3GPP TS 24.228 there are many changes in the content of SIP-INVITE message. 3. S-CSCF of home2 analyses the Initial Filter Criteria of the bob’s profile and sees whether there is any such IFC which is met. If there is any such IFC then the SIP INVITE message is forwarded to the Application Server whose name is written in the IFC. Here, in figure 2, it is sent to the Call Forwarding Application Server (CF-AS). 4. CF-AS fetches the Service Information of that user from HSS and takes the signaling to next steps. It fetches the Repository Data (Service Information) from the HSS using Sh-interface UDR message (Servicelndication = CFU). HSS provides the FTN to the AS in UDA message. The User-Data AVP of UDA message will look like:- CFU 1 tel:+919448024328 From UDA message, AS fetches the FTN (tel:+919448024328) for CFU. AS sends the SIP INVITE to CSCF of home2 by changing the “To” header of the SIP INVITE message. Now the “To” header becomes “tel:+919448024328”. 5. Then S-CSCF forwards the SIP INVITE to the S-CSCF of home3 which is the home network for UE3 (tel:+919448024328). 6. S-CSCF of home 3 sends SIP INVITE to UE3. It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device. Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart there from. GLOSSARY OF TERMS AND DEFINITIONS THEREOF IMS - IP multimedia Subsystem S-CSCF - Serving-Call Session Control Function HSS - Home Subscriber Server AS - Application Server IFC - Initial Filter Criteria SFC - Subsequent Filter Criteria ISC - IP multimedia Subsystem Service Control Interface UE - User Equipment PUR - Profile Update Request PPR - Push Profile Request UDR - User Data Request UDA - User Data Answer FCH - Feature Code Handling FTN - Forward To Number References: [1] 3GPP TS 23.228: “IP Multimedia (IM) Subsystem - Stage 2”. [2] 3GPP TS 29.228: “IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents” [3] 3GPP TS 29.229: “Cx Interface based on Diameter - Protocol details” [4] 3GPP TS 23.218: “IP Multimedia (IM) Session Handling; IP Multimedia (IM) call model” [5] 3GPP TS 29.328 “IP Multimedia (IM) Subsystem Sh interface; signalling flows and message contents” [6] 3GPP TS 29.329: “Sh Interface based on Diameter - Protocol details” [7] IETF RFC 3588 “Diameter Base Protocol” [8] IETF RFC 3261 “SIP: Session Initiation Protocol”

Documents:

926-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 04-11-2013.pdf

926-CHE-2006 FORM-1 04-11-2013.pdf

926-CHE-2006 FORM-5 04-11-2013.pdf

926-CHE-2006 OTHER PATENT DOCUMENT 04-11-2013.pdf

926-CHE-2006 POWER OF ATTORNEY 04-11-2013.pdf

926-CHE-2006 AMENDED CLAIMS 04-11-2013.pdf

926-CHE-2006 AMENDED CLAIMS 11-07-2014.pdf

926-CHE-2006 AMENDED PAGES OF SPECIFICATION 04-11-2013.pdf

926-CHE-2006 AMENDED PAGES OF SPECIFICATION 11-07-2014.pdf

926-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 11-07-2014.pdf

926-CHE-2006 POWER OF ATTORNEY 11-07-2014.pdf

926-CHE-2006 FORM 18.pdf

926-CHE-2006 FORM-13 13-12-2013.pdf

926-CHE-2006 FORM-13 17-12-2013.pdf

926-che-2006-abstract.pdf

926-che-2006-claims.pdf

926-che-2006-complete description.pdf

926-che-2006-correspondance -others.pdf

926-che-2006-drawings.pdf

926-che-2006-form 1.pdf

926-che-2006-form 26.pdf