Separating the control and user planes lets these functions be distributed across different nodes and scaled independently. But separation by itself does not make the service continuous — it only creates an architecture in which continuity can be provided.
For that, the data-forwarding node must become replaceable, and its replacement must be a managed operation that does not break active sessions. This architectural approach is called CUPS. Let’s look at why separating the planes does not by itself guarantee session continuity, in which situations continuity can break, how a managed session handover works, and where this approach has its limits.
What the service gateway consists of
Inside the service gateway there is a split into three entities: subscriber state data, traffic-processing logic, and the interface that connects them.
The control plane knows who the subscriber is and what they are entitled to. This is a layer where changes happen infrequently, but are critically important.
The user plane, by contrast, receives only certain per-session information, but knows what is happening with the packets. It classifies traffic by service, applies already-prepared rules, and keeps consumption counters for each service. This is a high-performance layer, optimized for throughput rather than for storing knowledge.
Between them there remains a narrow, explicit interface: the control plane sends commands down, and the user plane returns reports on state and consumption.
It is precisely because the interface is narrow that a user-plane node becomes replaceable. It stores nothing permanent — only what can be restored by a command from above. If this node goes down, burns out, is restarted, or is replaced with a new one, the control plane simply resends the same commands, and everything is restored.
Figure 1 — Entities of the control plane and the user plane
Where continuity can break
The ability to change nodes independently is not yet a guarantee that the subscriber won’t notice the replacement. A data-forwarding node has to be taken out of service not only on failure, but also on a planned basis: for maintenance or an upgrade.
The difference between these cases is fundamental. During maintenance work, the node is still operating, so there is time to prepare a replacement first and only then disconnect the source. During a failure there is no such time. The node stops responding before the network manages to prepare a session transfer. Part of the state is lost, and a break can no longer be fully ruled out.
This leads to a simple but key principle: while the node is still available, the session must be moved to the new one before the old one is disconnected. This is exactly the rule on which managed handover is built.
Managed handover: connect first, then disconnect
This principle is known in other fields as “make before break.” The new node is first prepared to serve the session, then traffic is switched to it, and only after that is the old node disconnected. This is where the meaning of separating the planes shows itself: the control plane fully manages the session handover, while the user-plane nodes only execute its commands.
Subscriber state is stored in the control plane. That is why it can recreate it on another node, passing over the profile, rules, and permitted services. The new node does not receive state directly from the old one — user-plane nodes do not interact with each other.
Importantly, the session is not simply “thrown” from one node to another. It is moved as a sequential, step-by-step operation with a point of no return. Until the sequence is complete, the system always retains a node ready to serve the session. That is why a planned replacement should not result in a dropped connection.
Figure 2 — Diagram of managed session handover
What about charging
Continuity of data transfer by itself does not mean continuity of accounting. A subscriber may not notice the node switch, but if a discrepancy then shows up in billing, the task is only half solved. That is why, during a handover, not only the state of service but also the consumption information must be preserved.
Here, reports from both nodes are used. The new node receives a threshold — the volume of traffic the subscriber is still allowed to consume. This threshold matches the remaining known quota. Before disconnecting, the old node sends the control plane a final report on the actually consumed volume. The control plane adds these values together and sets an already-absolute threshold on the new node.
Importantly, the volume is not reconstructed from the thresholds themselves. It is taken from the reports on actual consumption. This avoids two problems:
- losing part of the consumed volume;
- double-counting the same volume.
From this follows another consequence — an active charging session does not need to be closed just because a node was replaced. The subscriber kept using the service, and the consumed volume is known precisely. So there is no reason to send billing a message about a disconnection.
With 20 million subscribers and five data-forwarding nodes, this becomes especially noticeable. If one node were taken out of service by forcibly closing sessions, up to 16 million messages could be sent to billing. With managed handover, no such messages arise.
Where continuity ends
Every mechanism has limits to where it applies. An architecture must not only show what it can preserve, but also honestly state what cannot be preserved.
NAT address translation
Note that the User Plane PCEF has not only a DPI function, but also provides NAT (CG-NAT, NAT64, NAT 1:1).
CG-NAT address translation is a mechanism in which a subscriber’s device receives one private IP address inside the operator’s network, while going out to the internet under a different, public one. This solves the problem of address shortage and improves security. But the mapping between the internal and external address is stored in the memory of a specific node. If a session is moved to another node, the public address and port for already-established connections will change. For those connections, that is a break.
That is why such connections cannot be moved seamlessly. For them, the approach used is a natural interruption of current sessions along with the establishment of new traffic sessions: a planned node removal implies moving traffic from a private address to another User Plane with a different pool of public IP addresses.
There is also another approach — synchronizing connections between NAT instances. In this case, the NAT translation table is synchronized between several nodes. But this is already a separate architectural decision, one that also affects the addressing plan. So it cannot be treated simply as a setting that automatically removes the limitation.
Load balancing across multiple UPs
Session traffic is bidirectional — from the subscriber to the server and back. The forward and reverse directions are balanced by different mechanisms.
Outgoing traffic is balanced using an L3 load balancer based on IPsrc and IMSI. Incoming traffic is drawn in by the User Plane itself (DPI+NAT) via BGP announcements.
Node failure
On a User Plane failure, there is no managed handover — the DPI simply stops responding. In this case, part of the consumed volume may not make it into the final report. But even here, the size of the possible loss can be limited in advance. It is determined by the sum of the thresholds set on the node. The control plane can split the quotas it issues into smaller pieces, setting smaller reporting thresholds and collecting the intermediate data itself. Billing is still sent the original quota value, once the accumulated volume reaches the needed amount.
This creates a managed risk budget. The operator sets in advance how much volume it is acceptable to lose if one node fails. The frequency of reports from the nodes is determined by the budget, while the frequency of sending information to billing is determined by the size of the quota. The exchange with billing itself does not become more frequent as a result.
How to verify continuity
Service continuity cannot be proven by the fact that the system did not send an error message. It has to be measured during an actual handover.
The test must be run only if real traffic is flowing through the active session at the moment of the handover. If a gap appears in the flow, continuity was not provided, no matter how carefully the system logged the switch itself. So the acceptance test must check the actual data transfer, not the correctness of signaling messages.
What plane separation ultimately delivers
The value of CUPS is not limited to independent scaling of control and data transfer. Far more important is that the user plane becomes replaceable. And once a node can be replaced, its removal can be turned from an emergency event into a managed operation.
For planned work, this means a clear sequence: prepare the new node, move sessions to it, disconnect the old one, and reconcile the counters. For failures, a different mechanism remains: a pre-defined budget of acceptable losses.
This is exactly where service continuity arises. Separation makes it possible to manage session state during infrastructure changes. Then the promise of “planned maintenance with no impact on subscribers” stops being a general statement and becomes a specific procedure with a measurable result and clearly stated exceptions.
