US20150006572A1

US20150006572A1 - Sharing of Repository Data for Non-Alias Identities

Info

Publication number: US20150006572A1
Application number: US14/487,055
Authority: US
Inventors: Sourabh Anpat; Ricky Kaura; Matteo Candaten
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2009-03-31
Filing date: 2014-09-15
Publication date: 2015-01-01
Also published as: EP2415238B1; JP2015027090A; RU2015124195A; CN102379116A; CA2751082C; BRPI1013372A2; RU2011141194A; RU2015124195A3; JP2012522301A; KR20120003873A; CN102379116B; JP5613226B2; JP2016167865A; US8868686B1; EP2415238A1; RU2558614C2; WO2010112918A1; JP5934311B2; KR101665153B1; JP6266039B2

Abstract

A method for storing data in an IP multimedia subsystem (IMS) is disclosed, the method comprising selecting a first user and a second user, which are not aliases; analysing first and second data sets associated with the first and second users respectively to identify common data elements in each of the first and second data sets, the first and second data sets being useable by a first application server within the IMS to satisfy service requests on behalf of the first and second users; creating a data structure containing a single instance of the identified common data elements; and storing the data structure in a home subscriber server (HSS) within the IMS.

Description

RELATED APPLICATION

This application is a continuation of and claims priority to U.S. patent application Ser. No. 12/415,341 filed Mar. 31, 2009 entitled “SHARING OF REPOSITORY DATA FOR NON-ALIAS IDENTITIES”, the disclosure of which is incorporated by reference herein in its entirety.
One or more embodiments relate to the storage of data, and specifically data associated with users to enable an application server to dispatch service requests to those users, in an IP multimedia subsystem (IMS).
The IMS is a service overlay architecture capable of providing internet protocol (IP) based services on a 3G network, thereby allowing mobile users to access the rich variety of services available on an IP network. IMS can also provide services typically associated with circuit switched networks, such as call forwarding.
The IMS architecture and functionality is defined by a set of standards provided by the 3′ Generation Partnership Project (3GPP).
Three key elements of the IMS architecture are a Serving-Call Session Control Function (S-CSCF), a Home Subscriber Server (HSS) and an application server. The S-CSCF handles the routing of signals to and from users via one or more application servers according to service profile information held for each user in the HSS.
The HSS holds service profile information for each user. It acts as a centralised database that contains a variety of data related to the users including the service to which the user has subscribed and may participate in.
The data stored by the HSS may be transparent data, meaning that the HSS understands the syntax but not the semantics of the data, or non-transparent data, meaning that the HSS understands both the syntax and semantics of the data.
The data related to users (i.e. describing their service profile and specific configuration of the service for the users) is transparent data. It is stored in a container (in this case a data structure known as a BLOB, or binary large object) which is sent to the HSS by the application server for storage in the HSS database. Thus, the container effectively represents a database within a database and the HSS does not know the meaning of the data, it merely knows how to access the container and return it to the application server on request when the application server needs to service a request on behalf of a user.
The application server provides a Service Indication in accordance with the 3GPP standards, and this Service Indication is used as a key by the HSS to retrieve one of the containers from the database.
The 3GPP standards also define an Alias Repository data element that contains transparent data associated with a group of user identities, each of which is an alias of the others. To be considered as an alias each user identity in a group must satisfy three conditions:
1) they must be part of the same service profile (i.e. all the users subscribe to the same services);
2) they must be part of the same implicit registration set; and
3) they must have the same service configuration for each and every service.
A set of Public User Identities belonging to a user form an implicit registration set when all of the identities in the set is implicitly registered for a service via a single IMS registration of one of the Public User Identities in that set. No single public identity shall be considered as a master to the other Public User Identities. When one of the Public User Identities within the set is registered, all Public user identities associated with the implicit registration set are registered at the same time. This association is maintained by the HSS.
It can be seen as a restriction that each user identity in a group must have the same service configuration for each and every service to be considered an alias. For example, each user would have to have the same call forwarding number for a call forwarding service, which could easily defeat the purpose of the service.
The existence of the Alias Repository data element does prevent the HSS from having to store redundant copies of the same data for each of the aliases. However, redundant transparent data still has to be stored for a group of user identities that are not aliases (i.e. they do not satisfy each of the above three conditions).
In accordance with at least one embodiment, there is provided a method for storing data in an IP multimedia subsystem (IMS), the method comprising: selecting a first user and a second user, which are not aliases; analysing first and second data sets associated with the first and second users respectively to identify common data elements in each of the first and second data sets, the first and second data sets being useable by a first application server within the IMS to satisfy service requests on behalf of the first and second users; creating a data structure containing a single instance of the identified common data elements; and storing the data structure in a home subscriber server (HSS) within the IMS.
Thus, at least some embodiments overcome the problems associated with the existing IMS by allowing data related to non-alias users to be reduced to a set of data that excludes redundant data elements. This provides a variety of benefits, namely memory optimisation at the HSS by storing data associated with groups of non-alias user identities once only rather than having multiple instances of same data; improving notification efficiency between the HSS and the application server by reducing the need for multiple data-read/profile update operations due to the grouped nature of data; easier management of subscription data at the HSS due to single location and storage of information; and improved flexibility for the application server by allowing service interactions to be designed based on grouping of data not restricted to alias identities.
Typically, the common data elements are stored in the HSS as a transparent data set.
The common data elements are normally stored in a container within a database maintained by the HSS. A suitable container is a BLOB (binary large object).
Typically, the container is returned to the first application server in response to a request for access to the common data elements.
In at least one embodiment, the first application server subscribes to receive notification of changes to the common data elements.
In at least one embodiment, the HSS detects a change to the common data elements and sends a notification message to the first application server.
This notification message can, in some cases, contain details of the change made to the common data elements. Alternatively, the application server may explicitly query the HSS to determine the details of the change.
the common data elements are accessible by a second application server implementing the same service as the first application server.
In accordance with one or more embodiments, there is provided a system comprising a processor adapted to cause each of the steps of the method of the first aspect to be performed.
In accordance with one or more embodiments, there is provided a computer-readable medium comprising instructions executable on a processor to cause the processor to implement the method of the first aspect.
In accordance with one or more embodiments, there is provided a computer program comprising instructions executable on a processor to cause the processor to implement the method of the first aspect.

Various embodiments will now be described with reference to the accompanying drawings, in which:

FIG. 1 shows part of an IP Multimedia Subsystem (IMS) in accordance with one or more embodiments;

FIG. 2 shows schematically the association of grouped repository data within the HSS with a set of users; and

FIG. 3 shows steps performed at the application server and HSS in accordance with one or more embodiments.

FIG. 1 shows an application server 1 coupled to a HSS 2 and a S-CSCF 3. The application server 1 is coupled to the HSS 2 using a Sh interface and to the S-CSCF 3 using an ISC interface. The HSS 2 and S-CSCF 3 are coupled using a Cx interface. The Sh and Cx interfaces are defined as part of the DIAMETER protocol which is a networking protocol for use in authentication, authorisation and accounting. The ISC interface is defined as part of the Session Initiation Protocol (SIP).
As already mentioned, the S-CSCF 3 handles the routing of signals to and from users via the application server 1 according to service profile information held for each user in the HSS 2.
The HSS 2 holds service profile information for each user of the system. It acts as a centralised database that contains a variety of data related to the users including the service to which the user has subscribed and may participate in.
The application server 1 is configured to respond to service requests by perform the steps required to process the service request and return a suitable response and/or take appropriate actions based on the request. The processing and appropriate actions will depend on the service provided by the application server 1. The application server 1 may provide more than one service.
Examples of the types of service that the application server 1 may provide are a call screening service, a call forwarding service or a communication barring service.
The implementation of the Sh interface in the application server 1 can operate in two modes: Data handling and Subscriptions/Notification.
Data handling mode uses Sh Pull for retrieving data from the HSS 2 and Sh Update for storing data into the HSS 2. Data is retrieved from the HSS 2 by creating an Sh Pull request, and data is stored in the HSS 2 by making an Sh Update request.
The Subscriptions/Notifications mode allows the application server 1 to get a notification when particular data for a specific user is updated in the HSS 2 by other network entities.
The list below summarises the type of data that can be requested using an Sh application:

- Repository data: contains transparent data related to the service.
- Public identifiers: contains a list of Public User Identity (IMPU) associated with the user.
- IMS User State: contains the information about IMS User State of the public identifiers; the possible values are REGISTERED, NOT_REGISTERED, AUTHENTICATION_PENDING, REGISTERED_UNREG_SERVICES.
- S-CSCF Name: contains the address of the S-CSCF allocated to the user.
- Initial Filter Criteria: contains the triggering information for the service; an AS can only get the initial filter criteria related to the service provided.
- Location Information: contains the location information related to the user that could be located in Circuit-Switched (CS) or Packet-Switched (PS) domain.
- User State: contains the state of the user in the CS/PS domain.
- Charging information: contains the address of charging function.
- MSISDN: contains the MSISDN (which is a number uniquely identifying a subscription in a GSM or UMTS mobile network) associated with the Public User Identity.

FIG. 2 shows a set of IMS public indentities (IMPU) IMPU 1 to IMPU 4, each of which may wish to access the HSS 2 to retrieve repository data related to them. In the situation shown in FIG. 2, IMPU 1, IMPU 2 and IMPU 3 are aliases. IMPU 1 and IMPU 2 are able to access grouped repository data S2 on the HSS 2 and IMPU 2 and IMPU 3 are able to access grouped repository data S3 on the HSS 2. As previously mentioned, the IMPUs 1 to 4 use the Service Indication as a key into the grouped repository BLOBs (binary large objects). IMPU 3 and IMPU 4 are not aliases. However, the application server 1 is able to create group repository data for these two identities using a profile-update operation which will then be shared by IMPU 3 and IMPU 4.
The way that this is done will be explained by reference to FIG. 3, which shows the interactions between the application server 1 and the HSS 2 in generating and storing grouped repository data for the two non-alias identities IMPU 3 (referred to as User A in FIG. 4) and IMPU 4 (referred to as User B in FIG. 4).
Firstly, the application server 1 selects a pair of users which are not aliases of each other, in this case Users A and B. It then analyses the repository data associated with each user to identify common data elements in each of the repository data sets.
For example, User A may subscribe to call screening and call forwarding services and User B may subscribe to Call Screening, Call Forwarding and Communication Barring services.
Due to the difference in subscribed services (i.e. the different service profiles of Users A and B) User A and User B are not-aliases. However, the repository data related to the Call Forwarding Service for User A and B can nevertheless be grouped together and stored as a single instance of data.
A typical set of repository data that might be kept as configuration data for each of User A and User B includes information elements indicating that the user is authorised to use the service, that the service is activated for that user, a call forwarding destination (a uniform resource identifier (URI) such as a telephone number or e-mail address) and other subscription options. In this case, all these information elements with the exception of the call forwarding destination may be the same for User A and User B. For example, both users A and B may be authorised, the service may be activated for both users and the other subscription options may be identical.
Thus, the application server 1 can analyse the repository data for each of Users A and B to identify the common data elements, i.e. the indications that the user is authorised to use the service, that the service is activated for that user and the other subscription options, for both User A and User B and create a container (such as a BLOB) for storing in the HSS 2.
Then, the application server 1 sends the container with the grouped repository data for Users A and B to HSS 2 and issues a PUR command to cause the HSS 2 to store the grouped repository data in its database. Thus, the grouped repository data stored in the HSS 2 is transparent data grouped across two non-alias users A and B. These actions are shown as steps 1 and 2 in FIG. 3.
Steps 3 to 5 show optional steps which may be performed to interact with the grouped repository data after it has been created and stored.
In step 3, the application server 1 issues a UDR command to HSS 2 to retrieve the grouped repository data for users A and B, which it may need to do to respond to service requests for either user. The UDR command will be accompanied by the Service Indication (i.e. Call Forwarding) and the user identity (i.e. IMPU 3 or 4) which the HSS 2 will use as a key to retrieve the grouped repository data which can then be returned to the application server 1.
In step 4, the application server 1 subscribes to be notified of changes to the grouped repository data for users A and B. It does this by issuing a SNR command to HSS 2. The SNR command will be accompanied by the Service Indication (i.e. Call Forwarding) and the user identity (i.e. IMPU 3 or 4) which the HSS 2 will use to identify the data which the application server 1 needs to be notified of in the event of a change to that data.
In step 5, the HSS 2 has detected a change to the data (as may be made, for example, by another network entity which handles the call forwarding service). The HSS 2 responds to this by issuing a notification message (known as a PNR notification) to application server 1. The application server 1 can then use the UDR command as already described to retrieve and inspect the altered data if necessary or to perform any required processing in response to the change.
The steps performed in analysing the repository data for non-alias users and identifying common data elements and constructing a grouped set of repository data have been described as being performed by the application server 1. It is important to realise that these steps may instead be performed by an alternative network entity, possibly as its only purpose, without departing from the scope of the claimed subject matter.

Claims

1. A computer-implemented method comprising:

analyzing a first set of repository data associated with a first user profile and a second set of repository data associated with a second user profile, the first user profile and the second user profile being non-aliased with one another;

identifying at least one common configuration data between the first set of repository data and the second set of repository data;

creating a new data structure containing a single instance of the at least one common configuration data;

storing the new data structure at a home subscriber server (HSS);

receiving a service request associated with the first user profile or the second user profile; and

retrieving the stored new data structure from the HSS effective to respond to the service request.

2. The computer-implemented method of claim 1, wherein the service request is associated with a call.

3. The computer-implemented method of claim 1, wherein the at least one common configuration data comprises an indication associated with authorization to use a service.

4. The computer-implemented method of claim 1, wherein the new data structure comprises a binary large object (BLOB).

5. The computer-implemented method of claim 1, wherein retrieving the stored new data structure from the HSS further comprises issuing a UDR command to the HSS.

6. The computer-implemented method of claim 1 further comprising:

subscribing to be notified when at least some data of the at least one common configuration data in the stored new data structure changes.

7. The computer-implemented method of claim 6 further comprising:

receiving a notification message that indicates at least some data of the at least one common configuration data in the stored new data structure has changed.

8. One or more computer-readable storage memories comprising processor-executable instructions which, responsive to execution by at least one processor, are configured to perform operations comprising:

storing the new data structure at a home subscriber server (HSS);

9. The one or more computer-readable storage memories of claim 8, wherein the service request is associated with a call.

10. The one or more computer-readable storage memories of claim 8, wherein the at least one common configuration data comprises at least one of:

a notification of whether a user associated with the first user profile or a user associated with the second user profile is subscribed to a service;

a notification of whether the service is activated for the user associated with the first user profile or the user associated with the second user profile; or

a call forwarding destination.

11. The one or more computer-readable storage memories of claim 8, wherein the processor-executable instructions are further configured to perform operations comprising:

subscribing, via the HSS, to be notified when at least some data of the at least one common configuration data in the stored new data structure changes; and

receiving, from the HSS, a notification message that indicates at least some data of the at least one common configuration data in the stored new data structure has changed.

12. The one or more computer-readable storage memories of claim 11, wherein the notification message includes at least one detail of a change to the at least some data of the at least one common configuration data.

13. The one or more computer-readable storage memories of claim 8, wherein storing the new data structure at the HSS further comprises storing the new data structure at the HSS effective to make the new data structure transparent.

14. The one or more computer-readable storage memories of claim 8, wherein retrieving the stored new data structure further comprises sending a UDR command to the HSS, the UDR command accompanied by at least one of:

a service indication; or

a user identity associated with the first user profile or the second user profile.

15. A system comprising:

at least one processor; and

one or more computer-readable storage memories comprising processor-executable instructions which, responsive to execution by the at least one processor, are configured to perform operations comprising:

storing the new data structure at a home subscriber server (HSS);

16. The system of claim 15, wherein the processor-executable instructions are further configured to perform operations comprising:

subscribing to receive a notification when at least some data of the at least one common configuration data in the stored new data structure changes.

17. The system of claim 16, wherein the subscribing further comprises:

issuing a SNR command to the HSS, wherein the SNR command is accompanied by at least one of:

a service indication; or

18. The system of claim 16, wherein the processor-executable instructions are further configured to perform operations comprising:

receiving, from the HSS, a notification that at least some data associated with the subscribing has changed.

19. The system of claim 15, wherein the service request is associated with a call.

20. The system of claim 15, wherein the at least one common configuration data comprises at least one of:

a notification of a whether a user associated with the first user profile or a user associated with the second user profile is subscribed to a service;

a call forwarding destination.