ICACT20260184 Slide.22
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Thank you
|
|
ICACT20260184 Slide.21
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
To conclude, HyPR is a scalable policy registry for 5G Core networks.
It removes policy redundancy, reduces UDR load, and keeps high performance.
Most importantly, it is fully compatible with existing 3GPP systems.
Thank you for your attention.
|
|
ICACT20260184 Slide.20
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Conclusion
|
|
ICACT20260184 Slide.19
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here is result
|
|
ICACT20260184 Slide.18
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Here is result
|
|
ICACT20260184 Slide.17
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
For the operational performance evaluation, we use the 50 million UE dataset to emulate large-scale policy provisioning.
We measure end-to-end latency, covering the entire process from the initial UDR query to the generation of a fully encoded URSP.
The testbed consists of PCF and UDR modules communicating over the standard N36 interface, with the UDR implemented using Redis and connected via a 20-gigabit network.
Within the PCF, templates and pre-encoded rules are cached in memory with varying cache coverage.
All experiments are conducted under a sustained load of 1,000 transactions per second, and we report the 99th-percentile latency as the key performance metric.
|
|
ICACT20260184 Slide.16
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
For the storage efficiency evaluation, we construct URSP rules using basic components such as OS App ID, S-NSSAI, and DNN, with one rule per application.
We then run large-scale simulations at three different scales: 10 million, 50 million, and 100 million UEs, while gradually increasing application diversity.
For each UE, the policy configuration follows GSMA guidelines, including rules for IMS traffic, general Internet access, a match-all rule, and between one and five application-specific rules, all within 3GPP constraints.
Application usage is modeled using a Zipf distribution, which reflects real-world application popularity and explains the high level of policy duplication observed across UEs
|
|
ICACT20260184 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In our evaluation, we focus on two critical aspects: storage efficiency and operational performance.
To ensure realism, we simulate a large-scale 5G eMBB deployment scenario that reflects both subscriber growth and application diversity in real networks.
|
|
ICACT20260184 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, Evaluate
|
|
ICACT20260184 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The Policy Management Engine is the central component that orchestrates all policy operations within HyPR.
The first component is the Policy Provisioning Controller, which handles policy retrieval when a UE attaches to the network. The key difference here is that the entire retrieval process is driven by the UE–template binding. This allows the system to fully leverage caching and achieve very low latency.
The second component is the On-demand Update Controller, which manages large-scale policy updates. Instead of rewriting policies for millions of UEs, as in conventional architectures, HyPR updates only the affected templates while preserving the existing UE bindings in the UDR.
This approach significantly reduces the operational load on the UDR while still ensuring policy consistency across UEs.
|
|
ICACT20260184 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
At the heart of HyPR is a dual-storage architecture designed to balance scalability and performance.
The Object Store is responsible for storing policy templates and components at the semantic level, fully aligned with 3GPP specifications. This allows policies to be managed and updated in a flexible and structured way.
In parallel, the Binary Cache keeps pre-encoded policies and components in memory, enabling the PCF to serve UEs with carrier-grade, sub-millisecond latency.
By combining these two layers, HyPR is able to significantly reduce data redundancy while still maintaining high performance in large-scale 5G systems.
|
|
ICACT20260184 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
At the core of HyPR is a simple but fundamental idea.
We separate policy definitions from UE-specific assignments by introducing reusable policy templates. Instead of storing complete policies for every UE, we centrally store shared policy components, while the UDR keeps only lightweight bindings between UE identifiers and templates.
This design removes large-scale data redundancy that naturally arises when many UEs share identical or very similar policies.
At the same time, we preserve full compatibility with existing 3GPP systems. Policies are still stored in binary format, and all standard interfaces, including N15 and N36, remain unchanged through direct integration within the PCF.
With intelligent caching, HyPR delivers carrier-grade performance, achieving sub-millisecond access latency. It also enables efficient large-scale policy updates without overloading the UDR.
|
|
ICACT20260184 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Next, I will walk you through the system design of HyPR.
|
|
ICACT20260184 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In this work, we make three main contributions.
First, we propose a dual-storage architecture that cleanly separates policy definitions from UE bindings. By doing so, we eliminate the massive redundancy caused by storing the same policies repeatedly for millions of UEs.
Second, we introduce an intelligent caching mechanism that allows us to reduce storage requirements by around 50 to 60 percent, while adding only sub-millisecond latency overhead.
Finally, our design is implemented as a drop-in replacement for the PCF. It remains fully compliant with the standard 3GPP N15 and N36 interfaces, which means it can be deployed seamlessly in existing 5G Core networks.
|
|
ICACT20260184 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
A novel storage architecture that solves scalability challenges while remaining fully compatible with existing 3GPP interfaces.
|
|
ICACT20260184 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We introduce HyPR
|
|
ICACT20260184 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In real networks, we have billions of 5G UEs, and many of them share identical or very similar policies. But according to the current 3GPP design, each UE still stores its own binary URSP independently. This design does not scale. It introduces massive storage redundancy, creates bottlenecks at the UDR, and makes policy updates extremely expensive. A single change can trigger cascading updates across millions of UE records.
|
|
ICACT20260184 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In real networks, we have billions of 5G UEs. Erricson told that they had 2.8 billions UE, so Scaling in URSP is very important and so important to ensuring Quality of Service (QoS) guarantees
|
|
ICACT20260184 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In 5G Core, network slicing allows operators to provide different QoS guarantees for different services. To make this work end-to-end, traffic from the UE must be steered to the correct slice.
This is exactly the role of URSP. URSP defines, at the UE level, how application traffic is mapped to slices and data networks. As a result, URSP is no longer just a minor configuration feature — it has become a critical component for B2B and enterprise services in large-scale 5G deployments.
|
|
ICACT20260184 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Now, Introduction
|
|
ICACT20260184 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
4 part: Introduction, Approach, Experiment, Conclusion
|
|
ICACT20260184 Slide.01
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Hi every one
|
