FMC HSS - The IMS Brain

Rebecca Copeland Huawei Technologies Ltd Rebecca.copeland@coreviewpoint.com

HSS is the IMS Brain

Most of us regard the Session Controller (CSCF) as the centre point of IMS. It receives session requests and pumps out control commands to all other IMS network elements. It is the heart of the core network, but the brain, where knowledge is stored to guide its activities and where accumulated experience can alter decisions - is brain the IMS HSS. Most networks contain large number of fragmented data stores with overlapping information. Each system regards its data as its own. This means not only that common data items are duplicated, but also that useful data is trapped within each silo and is inaccessible to other applications. The IMS principles call for opening the data, making it available and sharable between network elements, and most important between convergent applications.

It is not just a question of access to data. In fact, the same idea of moving away from silos towards a layered model holds true for Data Management as much as it does for session control. A Data Store layer can be seen as an intelligent link layer between the services layer and the session controllers, in both CS and PS networks. This layer is also a crucial link between the Telco world and the IT support systems, OSS/BSS, providing valuable information. As the vision for the ALL-IP network evolves, the Data Layer becomes another step towards full convergence. Where there are doubts about the extent of the convergence, the arguments usually focus on having different sets of data, e.g. DSL network attachment compared with GPRS. Therefore, showing benefits from amalgamated data store is also enhancing the Convergence story.

Shared AS

Web AS Shared AS NGN AS

Mobile AS

Session Control Session Control

HLR HLR

NPDB NPDB HSS UPS HSS UPS CLF CLF

SLF SLF

AS data AS data

DNS ENUM DNS ENUM

Data Layer

GPRS GPRS WiFi/ WiMax WiFi/ WiMax xDSL xDSL

Cable Cable

Figure 1 Introducing a Data Layer

In the spirit of IMS, network data has to be open and available network-wide and beyond. This does not mandate a single, huge database, but efficient retrieval architecture based on standard interfaces. This architecture requires a brain that works with a nerve system that is distributed around the body, combining the central memory (user profiles) with local knowledge gathered in the limbs (e.g. addressing and location), to deliver coherent information to the rest of the body.

- Service Profiles (with iFCs, preferences) - Policy and QoS profiles (QoS class, SLA) - Charging profiles (fee bands, limits) and accumulators (promotions, bonus, discount). Note that this list does not include many other aspects of communications: It does not include nonuser specific, i.e. network wide data for services and routing or server information, and it does not include service-dependent data. What constitute servicedependent is not always agreed upon. For example the following items may or may not be part of an FMC central data repository: Number portability database DNS/ENUM and routing tables Directories Aggregated Presence.

The Scope for FMC Data Integration

a) Service-Independent Data Elements

Data is generated and maintained in numerous points. The amount of data is constantly growing, both in terms of volume of information and in terms of the number of data elements and their complexity. This makes data integration difficult, since the schemas and relationships keep evolving. For this reasons, the convergence of data must be applied only to relatively stable and well-defined network-wide data items: - User Profiles (Identifiers, ID associations, accounting ID) - Authentication and authorisation (credentials, auth/ciphering methods, keys) - Locations, Network (serving servers, IP address) and Physical (routing path, geographic mapping)
Parallel Model
IMS IMS
AS CSCF AS

b) Converging NGN and 3G Mobile data stores NGN TISPAN and 3GPP have already defined the service-independent data elements listed above, as shown in Figure 2.

Integrated Model
IMS IMS
AS CSCF AS

Service Profiles Service Profiles HSS iFC HSS iFC Policy/QoS Profiles Policy/QoS Profiles PCRF PCRF User Profiles User Profiles HSS HSS Authentication Authentication HSS AuC HSS AuC GPRS access GPRS access HSS HLR //VLR HSS HLR VLR GPRS GPRS

Service Profiles Service Profiles HSS iFC HSS iFC Policy/QoS Profiles Policy/QoS Profiles SPDF SPDF User Profiles User Profiles UPSF UPSF Authentication Authentication UAAF/ PDBF UAAF/ PDBF NGN access NGN access PDBF+CLF PDBF+CLF NGN NGN

Service Profiles Service Profiles Policy/QoS Policy/QoS User ID User ID Auth data Auth data Access data Access data WiFi/ WiMax WiFi/ WiMax Access data Access data NGN NGN

Access data Access data 3G Mobile 3G Mobile

Figure 2 Mapping data storage between 3G and TISPAN

c) Justifying Common Storage

On the face of it, there is a desire to combine equivalent data stores, and include data for the same functions operating for different access realms. However, is the evolution to an Integrated Model (Figure 2 right) achievable, desirable or justifiable if the data is utilised separately? If we take the case of 2G and 3G - the HSS contains AuC and HLR functionality for IMS, which is very similar to existing functionality for 2G Mobile, therefore combining full HLR in the HSS seems an organic development. This simplifies access to such data that is required, for example, for Voice Call Continuity (VCC) application. By contrast, PSTN /ISDN data is very different from IMS NGN. Nevertheless, providing an integrated view to such applications is increasing efficiency and usability. For VCC fixed location is as important as the mobile handset positioning. Either way, all such data may benefit from unified central/ distributed, secure and managed data storage facility.

unlawful intrusion and a security breach. The GUP also authorises access to data that may have various privacy levels. The GUP allows each Network Element to store and maintain its own data, but profides standard interfaces to Data requestors. This is often preferable to operational managers who resist surrendering ownership of essential data.
b) CPS Common Profile Storage

The newly defined CPS provides a framework for streamlining service-independent user data and storing it under a single structure, to avoid duplications and data conflicts. CPS considers data requirements from a wide range of facilities (including Presence, Charging etc.) and from many Standards organisations (3GPP/2, TISPAN, IETF, ITU, OMA etc.). CPS is logically centralised data storage but could be physically distributed. It enables network elements to have access to the part of the user data they require, in a standard format. CPS supports data federation among different data suppliers. CPS defines concepts of End-User, as well as Contract (including contract period, policy etc.) and Subscriber (who may have several End-Users). CPS framework specifies data management procedures, including:
- Resource Management for storage and retrieval - Transformation & presentation, Adapting Entities

Techniques for Convergence Data

To enable data management across a wide range of data stores - within each domain, let alone across different access domains - require new tools and techniques. These tools provide means of creating a user-centric view from associated pieces of information. These tools are a mixture of data modelling, standard data definitions, storage and distribution mechanisms, together with data management functions e.g. transformation, backups and update notifications.
a) The GUP Generic User Profile

management changes)

- Post-update trigger handling (notifications of - Security and integrity services - Transaction processing and concurrency control

The 3GPP recently updated version of the GUP (Generic User Profile) system is a tool to retrieve data elements from a distributed set of sources, providing a single point of access and a unified view of the data, regardless of the disparate sources. The GUP is designed as many-to-many interface, with many data requestors and many data sources. Requestors (network control servers or application servers) may subscribe to data changes to get notified by the GUP when they occur. Such requestors need to be authenticated to avoid

(rollback).

c) Modelling Data Relationships

The success of the CPS is highly dependent on the level of flexibility achieved by the way data relationships are reflected in the data model, allowing for further evolution, adding more access networks and data elements. Figure 3 shows a generic model for a contract, subscriber and user data, relating to logical and physical location.

Contract Data Contract Data

Subscriber Data Subscriber Data

Subscription Data Subscription Data

User Data User Data

Credentials Credentials

Subscribed Subscribed Services Services

Subscribed Subscribed Network Access Network Access

Network Access Network Access Profile Profile

Service Profile Service Profile

Logical Access Logical Access

Physical Access Physical Access

User Service User Service Data Data

Location Location

Figure 3 Data relationship model The example model shown in Figure 3 begins with the contract, which encompasses the users relationship with the service provider and may include several subscriptions. The model allows for a list of subscribed network access domains, each with its own logical and physical locations. handsets and soft clients, in multiple IP Access Networks. Structured tree of ID forms association between IMS Private ID (IMPI), which is used like an account number for internal use, and a Public ID (IMPU), which is a published contact URI or a telephone number. IMPUs can be Mobile, 2G or 3G, NGN, WiFi or any IMS user. In fact, one Public ID may be associated to multiple Private IDs and vice versa, for greater flexibility. A very powerful feature is the ability to group together IDs in an Implicit Set that can be registered in a single request. The effect of this is, for example, to enable registration of Public IDs without revealing them in the request message, when roaming. Such associated IDs may belong to different access networks, e.g. WiFi /WiMax or DSL. Figure 4 shows the relationships between Private and Public IDs with Implicit Sets.
b) Service Profiles

Converging Function by Function

Sharing data is not the same as converging data. Applications utilising shared data can perform enhanced services based on wider view of the users status and activities. However, integrated data means that certain functions allow building data trees that consist of data from different domains. This may be possible for some functions, but not others.
a) User Profiles and Structured ID

User Identity Management is at the heart of true convergence. The HSS and its counterpart in NGN (UPSF) both contain user profiles and Identity structures that allow for multi-access-domain users. Private ID and Public ID trees could include both 3G and NGN identities in a single structure, together with the associated service profiles, where the service profiles take care of access-specific features. This capability makes it easy to deploy access-agnostic applications for a range of

Many services operate in the same way, whether in Mobile or Fixed networks, but some services are not entirely Access agnostic. To enable more services to be shared, regardless of the type of terminal, data presentation and adaptation procedures are standardised within the CPS.

IMS IMS Subscription Subscription

IMPI Private User Private User Identity-1 Identity-1

IMPI Private User Private User Identity-2 Identity-2

IMPU Public Public User User Identity-1 Identity-1

IMPU Public Public User User Identity-2 Identity-2

IMPU Public Public User User Identity-3 Identity-3

IMPU Public Public User User Identity-4 Identity-4

IMPU Public Public User User Identity-5 Identity-5

IMPU Public Public User User Identity-6 Identity-6

IMPU Public Public User User Identity-7 Identity-7

Implicit Set of Identities A

Implicit Set of Identities B

Service Profile-1 Service Profile-1 AS-1 AS-1 AS-2 AS-2 AS-3 AS-3

Service Profile-2 Service Profile-2 AS-2 AS-2

Service Profile-3 Service Profile-3 AS-1 AS-1 AS-4 AS-4

Service Profile-4 Service Profile-4 AS-3 AS-3 AS-5 AS-5 AS-6 AS-6

Figure 4 ID tree structure with Implicit Sets and Service Profiles Service Profiles contain a group of matched services, with their lists of Filter Criteria (conditions for invocation), trigger points and prioritisation. Such packaged service bundles must be appropriate to the associated public IDs, which relate to the terminal types and access domains. Therefore, as shown in Figure 4, an Implicit Set may register several Public IDs, but each ID is assigned it own Service Profile. The same Service Profile can be assigned to multiple Public IDs, which may not be members of the same Implicit Set.
c) Authentication and authorisation

may use existing MSISDN, IMSI and IMEI numbers to generate an IMS Public ID. By contrast, NGN IMS access (accept for IMS-based PES via an AGCF) does not rely on the hardware and allows authentication based on username, password and access domain name. However, there are suggestions to enable digital devices to follow the example of mobile phones and introduce a SIM Card to NGN devices, (laptops, PDAs, fixed SIP phones). Various methods of authentication are likely to be supported in the converged network at any one time, including USIM/ISIM based, IMS AKA and HTTP Digest. As the Fixed and Mobile authentication methods are so different, perhaps there is no argument for incorporating them within the converged data storage. Indeed, Early IMS allows utilising existing mechanisms for IMS. However, as more access networks are added, the same range of authentication methods may be reutilised, as it is, for example, in the i-WLAN 3GPP based authentication.

Mobile authentication utilises terminal specific identifiers, the USIM /ISIM in the firmware, while NGN adopts the IT model of authentication that allows mobility between terminals, where binding user ID and assigned IP address occurs at registration time. Authentication for Mobile and NGN users differ fundamentally, due to the basic assumption that the handset has firmware (UICC) with a tamper-proof and unique ID. The identifier

Another compelling reason for converging authentication is the trend towards Single-Sign-On and Federated Authentication, as described by the Liberty Alliance. Sharing users credentials is then applied for all participating services, and the Requestors of the users credential are authenticated.
d) Network and Physical Locations

This is often the reason for intense resistance to centralising the data. Therefore, such common store must have strict privilege mechanism to audit and control data changes and secure data integrity.
3. Implementing new standard interfaces

Location is sought after data not only for Mobiles but also for many services for nomadic users on WiFi/WiMax or NGN DSL. Network location identifies the serving Network Entity that handles registrations and sessions. Physical location associates the IP address with a port, Access Point Name (APN), access device or cellular cell and can be mapped to a geographic location. Both play a role in Location Based Services (LBS), Proximity Context features and call routing decisions. While Network Location is always known at core Network Entities, the physical location and routing paths are access dependent belonging to the local network. Typically Visited Networks and Home Networks share as little as possible information when vying for the users service revenues. Hence, precise location data is retained within each network, except for regulatory based services, such as Emergency Calls. This raises the spectre of sharing essential data across business borders. While the integrated data store facilities simplify it, commercial reasons may prevent it.

Many application server vendors have been slow to implement the IMS standards for data access, namely the Diameter interface. Carriers should now urge their suppliers to update their products.
4. Operation versus OSS/BSS data

There is often conflict of interest between Operations and OSS/BSS. Data may be dynamic (e.g. user session status, location) or static in nature (e.g. user ID, User Credentials) and is retrieved in either real-time (e.g. session routing) or non-realtime (e.g. marketing statistics). The same data is often required in both modes. To protect real-time performance and accuracy, data is habitually replicated for off-line use. Such practices may continue even when an integrated data repository is implemented, as long as there is one master copy and synchronisation procedures in place.
5. Data Migration Consequences

Implementations issues
1. Real-time Data Sharing

Many operators shy away from disturbing established user data stores, for fear of disrupting live operations. However, data corruption, duplication and integrity conflicts are very costly, especially when they occur on numerous, fragmented data stores. Merging common data items can alleviate these database maintenance issues, but will need a data transformation to take place.

Operational data is crucial for response time and traffic shaping in real time. Frequent data dips may put pressure on the database and disrupt normal call handling. For example, LBS and VCC applications increase the demand for timely location information that may swamp the HLR/HSS. To overcome these operational issues, some operators deploy a special gateway platform that contains mirrored data. An HSS that includes a built-in HLR will assist in this respect too.
2. Ownership of Data

Conclusions
There is much to be gained by converging the network data stores, despite migration risks and operational worries. The benefits are considerable, as new user-centric services are becoming available and as cost savings are realised through streamlined database handling. Rather than considering this as a necessary evil, integrated converged Data Management should be implemented early, to bring about faster service introduction.

Data is usually considered to be owned by certain operations groups within carriers organisations.