HSS and UDM Interworking
It is evident that 5G will dominate the mobile landscape in the future. However, that does not mean that 4G is going away anytime soon. Due to the coverage problem, the coexistence of 4G and 5G will continue for a long time to come even after 5G launches. This coexistence will require interworking between the two systems to provide all types of subscribers with the services required including data management services.
According to 3GPP standardization, the existing 4G subscriber data management system (HSS: Home Subscriber Server) will be replaced by a new cloud native solution Unified Data Management (UDM). This change will require interworking between HSS and UDM, and especially for operators who choose to keep their HSS separated from UDM. So, how can operators choose the best data management strategy to ensure interworking with 4G while introducing new 5G services?
Before answering this question, let us briefly discuss why UDM and HSS need to interact?
Why UDM interacts with HSS?
Most operators today have to deal with different technologies in their networks, 2G, 3G, 4G or 5G networks. They need to manage subscribers’ data and subscriber access management in a flexible way across all these technologies, while also reducing the impact on nodes on live networks and protecting existing investments. Therefore, at the initial phase of 5G, carriers may have a preference to reuse the existing HLR/HSS infrastructure to provide 2G/3G/4G services. Carriers’ choice to retain the legacy HSS/HLR; in the early stages of 5G; is also driven by the demand for avoiding subscriber data migration and the complexity that brings, especially for subscribers who want to benefit from 5G services without changing their USIM card. This reusing of existing HSS will result, in storing separately the user data of 2G/3G/4G and 5G in different repositories (convergent HSS storing user data for 4G/3G/2G and IMS domains and 5G UDM/UDR storing user data for 5G domain).
As legacy 2G/3G/4G networks will run alongside 5G for the foreseeable future, interworking is essential for reliable access to subscriber data for user authentication/registration, mobility management, and service authorization. For example, when a 4G subscriber is updated to 5G subscriber, the 4G subscription profile keeps stored in HSS while the new 5G subscription data is provisioned in 5G UDM. The authentication data is only stored in HSS and is reused by UDM for 5G authentication. In this case, the UDM needs to interact with HSS to retrieve the authentication vectors.
So, to answer the question how can operators choose the best data management strategy to ensure interworking with 4G while introducing new 5G services? 3GPP outlined a number of options for UDM-HSS interworking in their technical reports (TR 23.973; TR 23.732). Essentially, there are three main approaches that can be taken for efficient interworking to ensure that a 5G UDM can coexist with legacy subscriber data management systems. The three options assume that:
- UDM and HSS are separately deployed and the user data of 5G and 4G/3G/2G are also stored separately in different repositories (convergent HSS storing user data for 4G/3G/2G and IMS domains and 5G UDM/UDR storing user data for 5G domain).
- HSS is deployed using the UDC architecture: Most telecom operators have a SDM (subscriber data management) solution that acts as a convergent HSS/HLR.
Option #1: UDM-HSS Interworking via SBA interface
The first option that we will discuss is direct SBA UDM-HSS Interworking. A 3GPP standardized solution (3GPP TS 23.632) that ensures interworking via a new SBA (service-based architecture) interface. As shown in Figure 1, a new service based interface (SBI) will be added between HSS and UDM, to handle all interworking cases. Therefore, the existing HSS must be evolved to support the new SBA interface (upgrade of the HSS).
By specifying a new SBI interface, this first option supports all the procedures that have been defined on EPS and 5GS. It enables seamless interworking between 3G, 4G and 5G environments but requires changes to the legacy HSS.
Option #2: UDM-HSS Interworking reusing legacy protocol
To avoid the impact on legacy systems, 3GPP proposes a second option that uses Diameter interfaces already available in the HSS (Figure 2). In this approach, UDM is the only access point to 5GC, EPC and IMS and acts as a fake MME/CSCF/AS. All the interactions for retrieving or updating user data are initiated by UDM through reusing existing HSS supported protocol and procedures.
This solution enables interworking without requiring any changes to the existing HSS. UDM acting as a gateway and sole access point to subscriber’s data, offers a smooth evolution towards shutting down the HSS. Because of the separation of the storage, this approach may causes the inconsistency between 5G service profile and 2G/3G/4G service profile of the same user.
Option #3: UDM-HSS coexistence without Interworking
This scenario proposes an alternative for coexistence between UDM and HSS by avoiding interworking between the two nodes. It ensures that the 2G/3G/4G/5G profiles of a user exist in the same UDR database through migrating the existing 2G/3G/4G data of 5G-enabled subscribers, thus avoiding interactions between “existing HSS” and “UDM”. To do so, 3GPP recommends deploying a combined HSS/UDM (Figure 3), supporting all interfaces and procedures specified for 5GC, EPC and IMS. The Combined network entity stores 2G/3G/4G/IMS/5G subscription data for 5G enabled users, so that the interactions between HSS and UDM within the Combined entity are performed internally and therefore it is not required to define such interworking.
This solution avoids any impact on existing nodes, services, protocols and interfaces; but require migration of subscriber data for existing users that enable 5G. It also needs to add route information for 5G users (in the STP/DRA) to send requests to either the Combined HSS/UDM for 5G enabled users or the existing HSS for 2G/3G/4G only users.
What’s the best option?
When evaluating options for interworking between UDM and HSS, it’s important to consider a few key points that are very important to operators; like data migration, impact on network, TTM and investments,… etc. The table below gives a brief comparison between the three options:
The evolution of user data from 4G to 5G has multiple paths, and each solution has its own Pros and Cons. As you can see from the table above, option 1 has the lowest score because of the impact on the existing HSS, and also not the best Investment direction for an operator. To avoid touching the legacy HSS, option 2 is a good fit for operators that want the benefits of a new 5G core without changing the existing HSS and investing in it. In this approach, the UDM acts as a gateway and sole access point, offering a smooth evolution towards shutting down the HSS. It offers the fast 5G launch with a focus on pure 5G SA subscribers. The only negative point in my opinion is the separation of data storage for the same user, and the complexity that may bring (provisioning and data consistency). Compared with other solutions, option 3 is an excellent one. The combined UDM-HSS avoid interworking, thus keeping the existing HSS untouched. This scenario ensures data consistency by using a unified user profile, thus facilitating provisioning. This approach require migrating legacy subscription data and needs more investments at the start compared to option 2, but in terms of architecture/design it offers the opportunity to implement the target solution from day one.
3GPP has specified multiple flexible interworking options to support the transition to UDM systems but does not cover all possible solutions. The operator may select more flexible and optimized transition solutions out of TS 23.973 based on its actual conditions. The best strategy for subscriber data management needs to reconcile different systems and standards that have been applied to achieve a smooth migration to 5G. And operators need to select proper evolution solutions in accordance with their own network conditions and policies.
