As subscriber bases grow and technology changes, networks can be expanded easily and cost-effectively with a stand-alone HLR. When a provider migrates to a stand-alone HLR, taking it off the MSC and putting it on an IN network node, the MSC can be dedicated to efficient call processing (see Figure 2). The complexity of the network is then significantly reduced.

Figure 2. A Stand-Alone HLR

There are two reasons for making the HLR a network element:

• MSCs are switches containing a certain amount of processing power. An HLR performs computation, not switching. When the HLR is taken out of the MSC to be a network entity, more processing power is freed up in the MSC for telephone calls—its primary function.
• To provision an MSC with subscribers (if each one has its own built-in HLR), it is necessary to put the data in each one, and each one has a different look and feel. With a unified HLR platform, there is only one provisioning mechanism for the HLR database with a standard protocol.

Moving to a stand-alone HLR is the first step in a WIN services strategy. Implementing an IN strategy today makes sense, even if roaming standards are not ubiquitous. When IN architecture is implemented, the network is automatically set up for interoperability with other services and other networks as the WIN standards come into play.

There are several other advantages of IN–based centralized service control, including the following:

• reduced delivery time for services
• reduced costs for service deployment
• flexibility that makes elements such as fraud control and specialized services more easily deployed
• reduced network component costs

As the HLR becomes a separate element in the network, it starts to look more like an SCP. The SCP and HLR functions merge, and an SCP/HLR in the network is the next logical step (see Figure 3).

Figure 3. An SCP/HLR