Getting to IMS: Migrating the HLR to the HSS

Authors: James Radley, Pavitra Krishnaswamy and Karl Medina

Since early 2004, IP Multimedia Subsystem (IMS) has been one of the hottest topics of the telecom industry. As reams of enthusiastic press releases earnestly proclaim, IMS promises the bliss of sophisticated telecom services delivered over an elegant, uncomplicated network. If the hype is to be believed, IMS enables the convergence of wireless and wireline offerings that comprise the revered quadruple play — voice, video, data and mobility — while also leading the way to network simplification and operating expense reduction.

What’s more, many see IMS as a way to not just deliver existing services in more efficient and convenient ways, but to provide new and enhanced features that were previously unavailable due to irksome technical or economic barriers. Catalyzed by a clean separation of the call control plane (used to route calls) and the application space (used to provide service features and to differentiate network operators), IMS beckons us to pursue the telecom network we always wanted but could never quite attain — until now.

Alas, it seems like just a few years ago that the Next-Generation Network (NGN) — a technology / architecture that enabled one to complete voice calls over packet networks — was the hot topic. Being a more mature version of the NGN, IMS addresses many of NGN’s shortcomings by merging the architecture with wireless standards from 3GPP, 3GPP2, ETSI, ITU, etc. However, unlike the NGN, IMS is expected to be less of a forklift upgrade and more of an intrinsic infrastructure model that evolves with the transition from circuit switched to packet switched networks. In other words, IMS will be with us for quite some time — and it is in our collective best interests to make sure it really works.

Much has been written regarding the vision of IMS and the benefits of converged architecture. In order to get there, however, we in the telecom networking industry must stay clearly focused on the immediate steps that need to take place. The purpose of this paper, therefore, is to identify and help clarify the key issues likely to be faced in the process of deploying one of the most critical nodes in the IMS network — the HSS.

The Home Subscriber Server

A key component of IMS is the Home Subscriber Server (HSS), which harks back to the Home Location Register (HLR) of the pure wireless world. In a wireless network, the HLR is the central location where user information is stored, such as account numbers, features, preferences, permissions, etc. The HSS is in fact an evolved version of the HLR that provides a much wider range of features and is meant to act as a master repository of all subscriber and service-specific information. It combines the HLR / AuC (Authentication Center) functionality of GSM networks and also provides information specifically required by the IMS network.

In the wireless network, the HLR is essential to providing access. In conjunction with the Visitor Location Register (VLR) and the Mobile Switching Center (MSC), the HLR enables End Users to send and receive calls within the home network and to travel (“roam”) within other networks while still maintaining access to familiar and desired services.

There is much more!

To read it all, click HERE!

In the IMS world, the HSS takes on many of the same roles as the HLR, and more. Not only does the HSS fulfill the user database function, but it also provides routing information; maintains data about a subscriber’s real-time location; keeps track of the capability of available communication devices; and so on.

In today’s pre-IMS wireless networks, each application or service module uses its own repository for storing End User data pertinent to the specific service provided. Although the HLR does provide a collection of the majority of such data, it is not a comprehensive superset of all information related to an End User. In essence, this means that carriers have to spend a lot of time coordinating information changes across multiple databases and trying to eliminate inconsistencies in the records. As a result, when the standards for IMS were created, there was widespread agreement that there needed to be a single repository for all End User information, which is precisely the role of the HSS.

Transitioning existent HLRs to become HSS network elements is one of the most strategic and essential steps that carriers have to take when moving to IMS. Because of the tactical challenges associated with such a critical network node, it is important to identify and understand the key issues likely to be faced in the process of HSS deployment.

HLR-to-HSS Migration Steps

One may ask: How will HSS network elements within the IMS architecture actually be deployed? The answer is easy: incrementally, and with extreme caution. After all, the HSS contains sensitive subscriber information, and carriers are very careful to prevent unintended interruptions of End User services. The initial deployments of HSS nodes will likely be enhancements on existing HLR nodes already in the network. The assumed scenario is that HLR vendors will modify their designs to incorporate HSS functionality for supporting the additional End User information and interface requirements of the new IMS network elements. And, since the HSS is to be a much more extensive database than the HLR, the HSS node may need to be deployed in smaller, geographically-distributed elements rather than in a single monolithic location. Although each individual node will be physically separate and more compact than current deployments, the HSS aggregate will be seen by the network as one logical network element.

The new IMS network architecture creates several important technical challenges when migrating to HSS solutions. In particular, the following steps need to take place:

1. Integrate new functionality into network equipment
2. Extend the database to accommodate new subscriber information
3. Simplify management of a highly distributed network
4. Develop a robust high availability framework for HSS databases and clusters

Each one is addressed in turn.

1. Integrate new functionality into network equipmentThe logical functionality of an HSS node is shown below:
2. Whether telecom equipment manufacturers convert an HLR to support HSS functionality, or build a standalone HSS network element, carriers will in turn need to do the following:
   • Add new software functionality.
     The HSS calls for the addition of new software modules and interfaces to support IMS-specific network elements. For example, the HSS communicates with the Serving Call Session Control Function (S-CSCF) and Application Servers (SIP AS, OSA SCS and IM-SSF) in the IMS architecture. The key protocol required to support these HSS interfaces (Sh, Si) is Diameter, and so Diameter software will need to be added.
   • Maintain support for existing interfaces and software.
     The HSS is a superset of HLR functionality and thus it is still required to support interfaces supported by the HLR in order to service packet-switched and circuit-switched wireless network interfaces. So, for instance, the HSS will still need to maintain existing interfaces (Gc, Gr, etc.) that use the Mobile Application Part (MAP) signaling protocol.
   • Verify interoperability between the new and existing nodes.
3. Extend the database to accommodate new subscriber informationOne of the most important advantages of the HSS is that it is meant to be one consolidated repository of End User information. In current networks, each application service module maintains its own version of the subscriber database in addition to the data maintained by the HLR. Thus carriers have been required to execute well-defined and often very complex mechanisms to maintain consistency over these many repositories.Considering these facts, the amount of data that will be stored in an HSS is expected to be much greater than what is stored in HLRs today. In addition to large storage size, the database must also be highly available and immune to failures so that there is minimal or no service disruption. And, to allow for future feature expansion and the addition of more subscribers as time progresses, equipment vendors need to also plan for an HSS database that can easily scale, such as in a “rolling upgrade” fashion where service is not interrupted.
4. Simplify management of a highly distributed networkOne practical consideration that may limit the scaling of HSS databases will be the cost associated with increasing the capacity of database storage elements. In fact, it may not be economical for carriers or equipment manufacturers to increase the size of an existing database beyond a certain limit. The long-term solution to the scalability issue may be to add HSS network elements in a highly distributed manner whereby multiple interconnected computing and storage nodes are used to store the information — but are viewed by the network as a single logical node. Building and maintaining such a robust distributed system will require an integrated mix of hardware, software, and management infrastructure.The efficiency of managing systems built from disparate compute resources will be important to operational success. The platform management challenges in this environment will be different than those faced in a network that is more concentrated. Fortunately, recent telecom industry equipment standards, such as AdvancedTCA (described below), offer greatly improved platform management functionality and should be considered seriously.
5. Develop a robust high availability framework for HSS databases and clustersIt’s clear: high availability and service reliability — 99.999% uptime — are of critical importance to the HSS. Since this is the primary repository of subscriber data, an End User call or session will not be able to take place without reference to it. For the highly distributed architecture of IMS, telecom equipment manufacturers will be required to design the proper clustering mechanism to ensure that traffic is routed to the appropriate compute and storage elements quickly and successfully.The PCI Industrial Computer Manufacturers Group (PICMG) has defined a family of standards for building carrier-class service platform hardware known as the Advanced Telecom Computing Architecture. AdvancedTCA defines a rugged compute blade architecture that allows for the economic deployment of highly scalable systems in the telecom arena. Scalability is achieved through a bladed architecture which allows for compute blades to be added to a live system when increased capacity is required.High Availability is achieved through rugged design by specifying “N+1″ redundancy in critical modules and through extensive hardware monitoring and control over the chassis’ redundant platform management bus. This internal platform management bus is based upon a widely adopted industry standard called Intelligent Platform Management Interface (IPMI). Hot swappable blades, switches and shelf management controllers allow for quick repairs to be conducted in the field without necessitating any system downtime, ensuring that 99.999% availability can be achieved by applications that are designed to run in a high availability environment.

Practical Deployment Considerations

From a carrier’s point of view, the issues above need to be addressed as quickly and seamlessly as possible to avoid any possible service disruptions while upgrading to IMS. As a result, telecom equipment manufacturers that provide these services feel extreme pressure to resolve these issues — now!

In the past, network elements like HLRs and MSCs were developed and sold as single entities by major equipment suppliers. The telecom industry was much more vertically-aligned then, and carriers were relatively dependent on individual vendors for nearly all of their expansion and upgrade plans unless the carrier chose to replace the entire system and endure massive expense and disruption.

Now, however, the telecom industry is more horizontally-aligned and the standardized nature of IMS architecture provides carriers more flexibility for enhancing and upgrading their systems by purchasing the “best” versions of each module available and then integrating them with their existing networks. With flexibility comes complexity, though, and such a mix-and-match approach invites potential problems in terms of hardware and software interoperability. As above, the key is to work with an integration partner that is proven to understand the intricacies of interoperability issues.

Final Remarks

The IMS opportunity is universally acknowledged, and the long-term positive outcome of moving toward a converged architecture is widely embraced. At the same time, the near-term issues of moving quickly to deploy key IMS network elements — like the HSS — should not be underestimated.

So the challenge is clear: telecom equipment manufacturers looking to build full-fledged HSS modules need to develop and integrate their products into carrier networks as soon as possible. The market opportunity is now, and time is of the essence. But, creating, testing, and deploying all of the protocol software and high availability hardware from scratch is a time- and resource-intensive project.

To minimize the development timeline and get to market quickly, telecom equipment manufacturers can partner with companies that specialize in the underlying infrastructure of network elements so that they themselves can concentrate on their core competency of developing the upper-level HSS software application. Whether upgrading from an existing HLR or building an HSS from scratch, vendors have a significant challenge ahead of them and will need all the help they that can get. Having the right integration partner with the requisite hardware and software skills is essential to the successful rollout of IMS.

No related posts.