After describing a panorama of the standards and technologies that can be used for user application data management and storage, here is a more subjective post.
User Data Distribution Can Be Managed!
Our industry has been struggling for years between two extremes:
- Distributing user data in application servers in order to optimize service delivery.
- Centralizing user data in order to simplify its management and ensure its integrity.
I think that with both the IMS service architecture and the Generic User Profile (GUP), we now have the tools to permit user data to reside where it is the most useful for service delivery, i.e. in the application servers hosting services.
As I tried to illustrate with the Automatic Service Discovery & Configuration example, and this is the same for presence, discovering the XCAP location of user data can be as easy as generating a SIP SUBSCRIBE addressed either to the identity of the user the data is associated to, or the identity of the service it applies to. The SIP/XCAP combo also permits to synchronize duplicates of user data with the master copy.
GUP is the exact equivalent in the web services sphere. GUP could be used to support centralized user data / subscription management, by hiding distribution details to the BSS system. See more below on GUP.
Exploiting Presence
Presence should be considered as one of the main sources of information related to the user, its devices and its applications.
This repository of user data will store both static and dynamic user-related data. This data will be populated/modified by the user, but also automatically by client and network based applications acting on behalf of the user, as well as network entities (e.g. IMS core, location server).
Presence data may be used by many applications, as an alternative to user application data specifically managed for them.
SIP and XCAP will be the natural protocols to access presence, according to 3GPP and IETF specifications.
Centralization for Common Application Data
User data that need to be shared between multiple applications can be stored in a centralized repository. Which one?
I do not like the idea of using the HSS as a user application data repository. Besides the potential impacts on HSS characteristics, another issue with this approach is that Diameter is not an optimal protocol for application data management. Moreover, the Sh reference point is very weak in terms of data management semantic, more especially compared to available alternatives. You have to realize that 3GPP specified the possibility to store application data in the HSS before GUP, XCAP, and CPS were defined.
I would like a centralized user repository to support SIP and XCAP in order to permit a smooth integration in the IMS service architecture. This means that the repository would be a SIP application server in the IMS architecture, and not a standalone XDMS as the OMA architecture seems to suggest.
This user repository could be based on the CPS architecture, which means that LDAP could also be an interface to it, and it would support GUP as well.
Therefore, overall, the user repository would be a SIP AS, using CPS as a backend data store, and supporting the GUP interface.
Generic User Profile & Liberty
I believe that Liberty and GUP would permit a strong integration of the future telecommunications network into a Service Oriented Architecture and into Web 2.0.
GUP is the optimal architecture and set of protocols to support Liberty in the operator's network.
I also think it should be used for subscription and user data management by the operator. Do you know that 3GPP specified the whole HSS data model using a GUP-compliant XML schema? This means that GUP could be imposed on suppliers right now as an open interface for HSS provisioning.
On the other hand, SIP/XCAP is a more lightweight approach to support access and management of user application data by IMS clients and IMS application servers.
It should be noted that at the moment the plans of most Network Equipment Providers to support GUP seem to be quite fuzzy, to say the least. There is therefore a risk that GUP remains a good idea on paper. At least as long as operators do not exert more pressure on their favorite vendors.
Common Profile Store to Break Silo Databases and for Coherent Data Modeling
In terms of actual database implementation, I think that the CPS approach is rolling and nothing will stop it. Some major suppliers have already embraced the concept and are offering HLRs and HSS's implemented on it. Others still resist, but will have to surrender sooner or later.
In the mid-term, all network databases (e.g. HLR, HSS, AAA) as well as some of the application servers will be implemented according to the CPS approach. All open service platforms (whether based on J2EE or JAIN SLEE) should integrate with a CPS.
Moreover, the CPS approach provides a unique opportunity to define a coherent model for user profile data across multiple network databases and application servers, while permitting application-specific extensions as required for a dynamic and differentiated service network.
Christophe
Subscribe to:
Post Comments (Atom)
Stumble It!
8 comments:
What do you think about type of profile data? I think GUP's definition for profile data is very generic. What is the intersection of presence (SIP/XCAP model) data related to subscriber (location, PIM, device etc.) with CPS?
Hi Ashish,
You are right about GUP. The intention is not to define any specific data model. It is to define an architecture and a framework that can accomodate any data, either standardized (e.g. HSS data) or not standardized (data specific to a non standardized service).
XCAP also relies on a generic protocol, with the idea to standardize a specific schema when needed, for e.g. group management, or something else.
For CPS, there might be different visions as the concept is not standardized and may leave room for different interpretations. For me, CPS is first an architecture which clearly separates between an application tier and a data storage tier and permits the same storage tier to be shared between different applications. From this derives the opportunity to define a common access framework to all user data (e.g. using different user identities as aliases) as well as, to a certain degree, permit a coherent modelling of user data across multiple applications. However I am not sure it is feasible and desirable to go too far in this direction (in some cases to have several applications have their own representation and even a duplication of the same data than trying to harmonize everything).
I could see a presence server being implemented using a CPS architecture, and supporting SIP/SIMPLE, XCAP and GUP interfaces towards different clients and sometimes to access different data (e.g. presence information, presence access control information, presence application preferences). There could be an overlap between the interfaces, like presence information being accessed through a GUP (i.e. SOAP) interface instead of SIP.
Christophe
Hi
Why do we have XCAP and GUP in parallel? In legacy networks a differentiation is made between realtime data updates a user initiates (e.g. activate his call forward) and a non-realtime data update the operator initiates (subscriber provisioning).
First I thought: XCAP is for the realtime aspect and GUP is the non-realtime provisioning aspect.
But after a while I thought: is it really worth to have such a differentiation? Wouldn't it be worth thinking to skip one in favour of the other? e.g. let Ut use GUP?
GUP is in my view THE concept and protocol architecture (Rp and Rg) to follow, when we want to access and manipulate the user's data with all its attributes, presence info and suppl services scattered over different network elements.
What do you think?
Hi Joerg,
Here are some elements of answer to your question.
XCAP was specified by the IETF while GUP was specified by 3GPP. This means that XCAP is aimed at being used in all kinds of SIP networks while GUP is specific to the telco world.
XCAP specification went much much faster than the GUP one.
XCAP is a very lightweight protocol based on HTTP while GUP protocols are more complex and based on SOAP.
XCAP comes with virtually no architecture (clients connect to a centralized server whose URI they have to get). GUP comes with a sophisticated architecture including a GUP server. It is true that you could use the protocols before the architecture is put in place or even without it, but this is a fact that some equipment suppliers do not support this view.
XCAP is supported by many suppliers while to my knowledge there is still very little buy in for GUP, even from big equipment suppliers that standardized it in the specs.
Overall, I agree with you. I would also prefer to have GUP as THE way to access user data in the network. If I remember well, this was proposed by one equipment supplier when Ut was initially discussed.
However, you also have to consider the reality of things, which do not seem to favor GUP at the moment.
Christophe
Hello Christophe,
Why do you think GUP is not in favor? Is it the market not asking for it or is it the suppliers who are not ready yet? It would make life easier for OSS/BSS in IMS domain to have GUP. What do you think?
It is possible that the situation will change, or has already changed.
Concerning the lack of favor for GUP until now, I have several potential explanations.
The first one is that the specification of GUP did not originate from an operator requirement. GUP started has something very fuzzy, pushed by one supplier and one operator, and ended up as something else, essentially pushed by another supplier. Such an erratic process, and the fact that operators did not ask for it, did not help for its recognition in the community.
Another aspect is that GUP can be seen as a redundant approach to some interfaces that were specified prior to it or in parallel, like the Diameter-based Sh interface to the HSS, or XCAP for terminal-oriented user data management. It can also be seen as an alternative approach to the Common Profile Store one, even if I personally do not subscribe to this view.
A third one is that GUP is opening up to web services network nodes that are normally accessed through complex or proprietary protocols, both for service delivery and provisioning, and this openness can be seen as a threat for some equipment providers, which prefer to keep complex or proprietary interfaces, as they reinforce the predominance of classical telco suppliers or tie together several of their products.
This is particularly true for provisioning. Provisioning tools are the most visible part of the telco iceberg for operators. If your workers are used to a provisioning tool, they might be reluctant to changing it. If this tool uses a proprietary protocol towards network equipments, you might be inclined to keep the same supplier for other equipments, just because you prefer not to change the provisioning tools.
Until know, I have seen little awareness of operators about GUP, and only one supplier actively promoting it for provisioning. This said, I do not have a global view on this.
Christophe
This topic is simply matchless :), it is pleasant to me.
I think it is something all companies should taking into account, I mean getting the most perfect optimization and delivery, and reducing the issues, because I'm sure that most of you have had those problems.m10m
Post a Comment