Definition
Core Network Evolution describes the architectural changes of mobile communication core networks from the 2G circuit domain, 3G packet domain to 4G EPC, and 5G 5GC. Each generation of core network has significant improvements in service capabilities, network architecture, and degree of cloudification. 4G EPC adopts a network element-based architecture (MME, SGW, PGW, etc.); 5G 5GC adopts a service-based architecture (SBA), where network elements are split into microservices that interact through HTTP/2 interfaces, supporting network slicing, edge computing, and more.
Evolution Path
- 2G: MSC/VLR circuit switching, mainly voice
- 3G: SGSN/GGSN packet domain, data services emerging
- 4G: EPC fully IP-based and flattened, separation of control plane and user plane, supporting VoLTE
- 5G: 5GC cloud-native, service-based (AMF, SMF, UPF, etc.), supports slicing and MEC
Evolution trends
Virtualization (NFV), service-based architecture (SBA), slicing (network slicing), and edge deployment (MEC/UPF offloading) are the core network evolution directions. IoT devices complete authentication, session establishment, and data forwarding via 4G EPC or 5G 5GC; 5G slices can provide dedicated logical networks for IoT.
Typical Use Cases
SimtoLink's IoT SIM cards access via EPC/5GC, and core network evolution directly affects private networks, slicing, and edge capabilities. SimtoLink connects with operators' core networks to provide customers with differentiated connectivity capabilities.
The core network is the data processing hub for IoT devices connecting to operator networks. SimtoLink's IoT SIM cards complete authentication, billing, and data forwarding through the 4G EPC or 5G 5GC core network. Deep integration with operators' core networks allows SimtoLink to provide dedicated APNs, network slicing, and other differentiated connectivity capabilities, meeting the customized requirements of enterprise-level IoT.
After the user plane is split off, which box the charging point lands on
The early packet core put control and forwarding in the same class of gateway, so session setup and traffic accounting were almost finished in one place. 4G leaves the control plane on mobility management and the packet gateway, and the user plane can scale on its own. 5G splits session management from the user-plane function further, and the user-plane function can even move down into a room near the base station. If charging and policy still ask the control plane “what is the rate now,” they receive session parameters, not live bytes. Live usage has to be collected at the point the user plane passes through. After that function moves to the edge, the collection point moves with it.
Disputes over IoT SIM traffic often come from inconsistent collection points. The module counts bytes sent on the air interface. The core network counts IP bytes that passed the user-plane function. The difference is header overhead and retransmission. A reconciliation should name the measurement point, rather than assuming that a network-element name still means the same counter before and after the evolution.
Service-based interfaces turn a network-function call into a request transaction
Network functions in the 5G core call each other through service interfaces. The style is close to a request and a response on the web, not the paired dedicated signaling links of the previous generation. One session setup crosses access management, user data, policy, and session management. If any one of those calls times out, the device still sees an attach failure, and the cause may be only that one service did not respond. Troubleshooting cannot stop at the words “the core network rejected it.” It has to see which service call never returned.
A service can scale out horizontally, but the state still has to be found on the copy that holds the session. If a load balancer sends a later request to an instance that has no session, the first hop succeeds and the second hop says the user does not exist. That looks a lot like bad card data. The difference is that changing the card still reproduces it, and it appears only on one group of network functions. The condition is that the failure tracks a particular service instance, not the device location in a simple way.
A slice identifier has to cross several hops from the device to the user plane
A slice uses a set of identifiers to place the device in a logical network. The identifier has to stay the same in the device request, in access-network selection, in access and session management, and finally on the user-plane function. If any hop maps the identifier to the default slice, later quality of service follows the default slice, and the service layer does not get a clear “slice lost” error. Check the identifier in three records: the device request, what the access network passed through, and session setup. They should be the same.
A SimtoLink IoT SIM card can attach to a 4G core or a 5G core, depending on which generation the card, the module, and the local network have opened. If the card has a 5G subscription and the module only does 4G, the session still lands on the 4G core, and neither slicing nor a sunken user plane appears. The platform has to distinguish the radio standard before it can explain why the same card gets different network capabilities on different devices. A private-network access-point name is still the usual way to bring traffic into the enterprise side. It does not depend on the core already being service-based.
After the user plane moves down, round-trip time no longer points at the central room
Once the user-plane function sits in a room near the base station, the round trip from the device to the user plane gets shorter. The round trip to the enterprise central server does not necessarily get shorter, because the server may still be far away. Using one average round-trip time to judge “whether core evolution took effect” mixes the two stretches. Split the path: device to user plane, and user plane to application. If the first stretch gets shorter, the move-down happened. If the second stays long, shorten it in application placement or on the private line, rather than changing the core architecture again.
The control plane is often still in the center. Delay for session setup and policy lookup does not fall together with a sunken user plane. Attach at power-on can still be slow while the data plane is fast. That combination is normal after the evolution, not a fault. Which core generation a SimtoLink card lands on decides whether these functions exist. The module decides whether it can join that generation of radio network. If the platform draws attach delay and data delay as one line, it will misread the move-down as having no effect. Collect the two delays separately, then decide whether to optimize session setup or the user-plane exit.