Convergent data center for future network
Xia zhen hua (Lawrence Hsia)Huawei Technologies
Abstract
In this article, we will analyze current issues and new challenges on user profile, and then propose a convergent data center for user profile management including its main features and key technologies, such as modeling. A case study in PES service with support of convergent data center is described here.
Issues and challenges on user profile
management
With the evolution of carrier’s networks, more and more networks and services (including fixed network, mobile network, value-added service, and OSS/BSS) will exist with their own separate database. These databases have duplicated data storage of the same data element without any consistence mechanism, which causes high OPEX and CAPEX. Each database has its own backup, which causes high cost.
Moreover, new personalized and convergent services require more user profiles to be provided. And future services will be more complex, which request data access operation more efficient.
Furthermore, in future network, the objective of ubiquitous network requests users have multiple subscriptions in multiple providers, but they have the same user profiles. The concept of context aware service needs more user-specific dynamic contexts to be included in user profiles, some new requirements such
as context correlation and context learning will be the must in future. Thus the upgrading of data model could be more frequent than current status. But great effect will take place if the upgrading of data model will interrupt service running, thus online data model upgrading will be very important.
In 3GPP GUP has been proposed trying to resolve all these issues, but its main advantage is to provide a unified data access point. Some important technical issues, such as duplicated data storage, low data access efficiency and low application execution efficiency, still haven’t been addressed by GUP. That’s why 3GPP has proposed another project CPS where the concept of end user ID and common profile storage has been provided. Therefore we proposed a logically convergent data center to store data elements from different technical domains (from network to service and then OSS/BSS), whose main characteristics are user-oriented, unified data model, distributed deployment, flexible modeling and zero upgrading, easy to deploy. It also provides a unified data access point, application specific view, access control, high redundancy, high reliability. Figure 1 shows the network scenarios with convergent data center. In this scenario, one administration domain of carrier will have a logically central data center which holds many kinds of data (e.g. user policy data, AAA data, service profile, user registration status, charging data). It will be presented as a unified function entity to other network elements though it could be implemented in distributed architecture. The other network elements, such as IMS and new service components, will access their relevant data from the convergent data center.
Convergent data center
AAA Data Application
Repository Data User Policy Data
Service Profile Data
Dynamic User Registration info Charging data … … IMS Service management Billing system
Non IMS service
PS
CS
2G CORE PSTN
Convergent data center
AAA Data Application
Repository Data User Policy Data
Service Profile Data
Dynamic User Registration info Charging data … … IMS Service management Billing system
Non IMS service
PS
CS
2G CORE PSTN
On the other hand, from technology development point of view, distributed-database technology, such as P2P, goes more mature, which makes the implementation of a logically convergent but physically distributed data center more realistic.
Main features of convergent data
center
Layered functional architecture
Convergent data center Data storage
Data Application layer HLR application HSS SDP OSS/BSS GW
Data process
Concurrency control
transform Access control presentation … … notify adapt
Transaction process Backup/restore modeling Data interface Data correlation Data learning
Application layer CS
… …
IMS SDP OSS/BSS…
Convergent data center Data storageData Application layer HLR application HSS SDP OSS/BSS GW
Data process
Concurrency control
transform Access control presentation … … notify adapt
Transaction process Backup/restore modeling Data interface Data correlation Data learning
Application layer CS
… …
IMS SDP OSS/BSS…
Figure2 Layered functional architecture Figure 2 shows the interface between data centre outer
application. The data application layer accesses data centre directly, from data centre point of view it’s just as application of data. While the application layer is true telecom application which will access data application layer or data centre layer depending on the type of applications. A possible logical framework of convergent data centre is depicted below:
The data storage layer is mainly for distributed storage of data components.
Data process layer is used for concurrency control (to control the concurrent access to the same data source), data transaction process (to handle multiple data access steps within one transaction), data backup and restore (to backup data and restore the same in case of exception), data integrity (to ensure the integrity of one certain data component), data modeling (to model the user-based profiles by the use of some modeling technologies, such as ontology WEB), data correlation (to process the relationship of several attributes belonging to one certain user or different user), etc. While data interface layer is for providing interface to application layer, such as HSS, AS. Transform is used to transfer data from one certain format to another format, such as from LDAP directory structure to XML object-based format. Access control is to authenticate access from application side which includes 3 levels, database level, user level, and attribute level.
Presentation is used to provide interface to application side. Notification is to notify user data change to applications. While adapt is used to accept data access from outside and adapt it to internal interface.
Main features of convergent data center
Except conventional database functions, the main additional functions and benefits of convergent data center are described in the following sections.
1. Common user profile model
Although the attributes of one specific user is from different places and used by different applications, in data center, there will be a common user profile model for a certain user. The concept of end user will be introduced, who has different subscription to different networks and even different providers. The benefit of common model in storage level is to abandon duplicated storage of the same attribute among multiple applications and additional work on data consistency, improve application execution efficiency by getting data within only one time, easy to provide data correlation through in the same place.
2. application specific view
Because different applications may want different attributes, it’s necessary to provide application specific view of a certain user profile model. Its benefic is to
provide applications the most needed attributes and help them to improve performance of execution by only getting the related data. On the other hand, from security point of view, applications can only get data attributes which are related to them, those attributes which are not concerned should not be exposed to them. 3. Application priority
The convergent data center will centrally manage user profile data, which provides interface to multiple kinds of applications. These applications have different requirements regarding data access performance, so data center should be able to support priority for different kind of applications. Those who have high performance requirement should have high priority, such as HSS/HLR, while those who don’t care much about performance, will be in the group with low priority. 4. multiple protocols support
The applications which access data center may belong to different domains, deployed in different time, so they have different protocols supported. Thus it’s quite necessary for data center to support popular data access protocols to meet different kind of applications, such as LDAP, XML/SOAP, SQL, etc.
5. online model upgrading
With the involvement of ubiquitous, convergent, customized and personalized service, more and more services will be deployed in carrier’s network, which can’t be predicted in advance. Also the user profiles stored in data center will also be upgraded frequently (at least once a month). Normally the upgrading of user profile model will interrupt service execution and lose some revenue from carriers or service providers. If the frequent upgrading of user profile model will interrupt service execution, this means lots of lose from providers. Consequently the requirement of online user profile modeling is quite required in future network scenarios. Carriers or service providers can upgrade their profile model without any software modification and service running interruption. Thus a software platform which supports any kind and online upgrading of user profile model is the base of data center.
6. access control
For the purpose of security, application client should only get their related data attributes; those which will never be used by them should not be visible. So an access control mechanism is quite necessary in data center, to authenticate whether an application client can access data center, access a specific user, or even access one specific attribute of a certain user.
A distributed data center: user profile network
Because the requirement for the capacity of data center should be very large, even in 100-million-subscribers level, it’s necessary to be based on multiple servers. Furthermore, from the reliability point of view, it’s quite flexible for nodes in different places to backup each
other and one of them can take over task of the other by bringing other advantages such as cost reduction. In this case, a user profile network common to multiple domain will exist.
User profile network
State 1
State 2
State 3 State 4
User profile network
State 1 State 1 State 2 State 2 State 3 State 3 State 4 State 4
Figure3 Distributed data center: user profile network
Moreover, the user profile network can help to optimize service execution procedure by the convergence of user data, as well as service provisioning and user subscription procedures.
The user profile network may also be shared among multiple administrative domains for one specific carrier, which can help carriers to optimize some service procedures such as roaming, number portability and reduce OPEX and CAPEX.
In this scenario, some technologies for distributed architecture, such as P2P and GRID, will be fully applied in data center.
Deployment recommendation for data center
The deployment recommendation of convergent data center is depicted in the following figure 4.
App with data stored in data center Local APP with
data internal
Data federate (GUP) Local APP 3rd part Data in 3rd part Data in terminal data center
Data access from app Data provided to federation Terminal
App
Figure4 Deployment recommendation for data center
Data common to multiple applications is recommended to be stored in data center. Data for specific application can also be in stored data center without correlation with others.
Different carrier or service provider has different network evolution policy and service provisioning policy. Provider A may prefer to provide service a in first but service b later, while provider B may prefer to
provide service b much earlier than service a. Based on their network situation and service planning policy, carrier or service provider can decide their user profile management system’s deployment policy without any software change, in other words, which user profile data should be shifted to data center and when should they happen totally depends on provider’s own decision. But generally speaking, newly deployed applications can split profile storage from application logic to data center, while already deployed App needs software upgrading if their data storage will be shifted to data center. This requires application developer and designer aware of supporting capabilities of separating data from
application logic. If newly deployed applications don’t support splitting data from application logic, they can’t shift their data to data center. In this case, if provider doesn’t want to upgrade software for the purpose of shifting their data to data center, they can use data federation to federate data in different places including applications, data center, terminals, and even 3rd part to provide a common user profile model.
Evolution scenario of data center
Figure 5 depicts evolution scenario of data center from deployment point of view.
carrier2
Service provider1 carrier1
User profile provider
Service provider2
Decentralized data center
Figure5 Evolution scenario of data center In the fist phase, for the objective of network
convergence, user profiles in network level, such as HSS, HLR, AAA, will first of all be convergent in data center. In this scenario, data is separate from application, but they may still be deployed in the same hardware platform. The interface between application logic and data could be proprietary but not standard. The already deployed application should be upgraded to support shifting data from application logic.
Then in the second phase, with the development of network technologies, user profiles will be more complex and service experience requirement from user will be more customized and ubiquitous, some new capabilities such as data correlation and data learning will be emergent in this phase, this needs more data be convergent into data center including user profile, service profile, OSS data related to end user. For those applications which are not capable to separate data from application logic, such as old application or new application without data splitting support, a data federation entity should be provided to federate multiple
data sources and provide unified common data model to other applications and 3rd part.
With the development of technologies such as P2P and GRID, and more ubiquitous service requirements come from customers, carriers will deploy an individual user profile network shared by different administrative domains as described in previous section, which is a logically central and single but physically distributed network specifically for user profiles, this is what the 3rd phase tells. Nodes in this network backup data for each other, thus a flexible and low cost reliability mechanism will come into reality. Furthermore this makes optimized service procedure possible, such as service roaming, inter-domain mobility management. The challenge in this phase is not only separating data from application, but also changing network architecture and service procedure to optimize service execution efficiency by use of the distributed data center if carriers want.
Finally in the end phase, a dedicated user profile provider could exist in the value chain. The reason is that some technologies for context capturing will be
mature, and more and more user profiles (context) will be used in telecom service to provide newly customized and intelligent service and gain new revenues. The investment for context capturing network is so high that we have to consider avoiding duplicated deployment for such kind of network. Thus a dedicated context provider could appear to capture context and provide context to other carriers or service providers. The functions of context provider may be of the following: management of user profile including user identity and user service profiles, authentication and authorization of user’s network and service access, accounting for user’s consuming on network and service. The individual user profile provider can have a layered and distributed user profile network.
Case study: PES with support of
convergent data center
PES, PSTN emulation service, is to provide services based on IMS which have the same user experience with PSTN service.
In PES, there are several types of data including: 1. Basic User Data: such as user type, user status, audio codec
supported, video codec supported, ringing type, charging policy, etc.
2. New Service data: such as call barring, call out restriction, Password of outgoing call, Abbreviated Dialing, Hotline Service, Alarming Service, CFU, CFB, CFNR,
Do-not-Disturb Service, Call Waiting, CLIR, COLR, Centrex group No, Short Number of Centrex User, etc. 3. Public Data (not for specific user): data of Charging Policy,
Data of Centrex Group.
Three kinds of loading method for all these mentioned data are described below.
1. Loading basic data when AS receive a user register request When receiving a user register request, PES AS loads user data from data center. PES AS subscribe to data center for any change of user data. When user data changed, data center informs PES AS about any change happening to user data. When user unregistered, PES AS deletes user data from memory.
2. Loading service data when AS receive a call request When receiving a call request, PES AS loads user data from data center. When PES AS modifies user data in memory, PES AS shall modify user data in data center simultaneously. When call is terminated, PES AS deletes user data from memory.
3. Loading public data when system power on
When system powers on, PES AS loads public data from data center. PES AS subscribe to data center for any change of public data. When public data in data center changed, data center informs PES AS about any change happening to public data.
Figure 6 depicts procedure for basic data loading when user registers to IMS.
UE AGCF S-CSCF PES AS centerData
Register
Register(PU-ID1,PU-ID2)
Register(PU-ID1,PU-ID2)
When PES AS receive the register request, PES AS download basic user data from data center, then PES AS subscribes to data center for any change of user data.
Query req(PU-ID1) Query rsp(basic data) 200 OK
S-CSCF handle the Register request. Based on the IFC, S-CSCF determine to send a third party SIP registration to PES AS.
ACK
200 OK ACK
200 OK
ACK
When basic data was changed, data center informs PES AS about any change happening to basic data. Subscribe req(PU-ID1)
Subscribe rsp
Notify rsp(basic data) Notufy req
When PES AS receives register request from user via IMS core, it downloads basic data of that user from data center by “query and response”. It then subscribes to data center for the user basic data change. When the basic data of that user changes in data center, data center notifies PES AS the concrete modified attributes.
User profile modeling
Modeling is one important key technology in data center. Figure 7 gives one example of user profile model including profiles of PES service.
-UID End User -IMSINumber IMSI -MSISDNNumber MSISDN CSSuMServiceProfile 0..1 1 -IMSSubID IMSSubscription 1 0..* 1 0..* -IMPINumber IMPI 1 0..* -IMPUNumber IMPU 1 0..* IMSSuMServiceProfile 1 0..* ImplicitlyRegisteredSet -TelphoneNumber TelNumber PESServiceProfile 0..* 1 0..* 1 0..* 1 1 0..* AuthenticationAndCiphering 1 0..* -MandatoryCapability -OptionalCapability -PreferedSCSCF SCSCF Selection -SCSCFName -DiameterClientAddressOfSCSCF Registration 1 1 1 1
PESApp Public Data 1
0..*
Figure7 Use profile modeling Here the concept of end user has been introduced, which
may have multiple subscriptions in different network domains. More specific identities (such as IMSI, IMPI etc) will be associated with a single End User (UID). By providing a common user profile model, redundancy of data has been reduced, consistency of data is ensured, data correlation can be described in user profile model description language, such as OWL.
Conclusion
A common convergent data center for central user profile management will be the trend for future network. It can reduce cost and help to improve service performance. Except traditional database function, main features of data center include common user model, application specific view, application priority, multiple protocols support, access control, online model upgrading, and distributed architecture. Some recommendations have been proposed regarding how to use data center and how to evolve the user profile management system to data center-based architecture. The involvement of data center needs some modification on application, such as PES AS, to separate data from application logic. Some key
technologies of data center, such as modeling and distributed architecture, are currently studied.
