How to Read and Use a 5G Core Network Diagram

Most diagrams you find online are textbook exercises that look clean on paper but fall apart the moment you try to actually deploy anything they show. I spent three years working on 5G core deployments across two continents, and the diagrams that actually helped me were the ugly ones with version numbers and change logs scribbled in the margins. A proper

5G Core Network Diagram

needs to show you which network functions talk to each other and through what interfaces. It is not enough to draw boxes for AMF, SMF, and UDM without indicating the N11 interface between the two or the N4 between SMF and UPF. Those details matter when you are troubleshooting a session setup failure at 2am. I once spent two weeks chasing a roaming issue where packets were not reaching the UPF on a partner network. The diagram everyone had shared showed a clean N6 exit from the UPF, but it was missing the N9 interface entirely. It turned out the partner had split their UPFs into home-routed and visited-routed variants that required separate N9 links between them. The standard reference architecture diagram from 3GPP does not call this out clearly, and most vendors implement it differently. I ended up drawing my own overlay on top of the vendor's topology map just to visualize the actual packet flow, and that is what finally revealed the misrouted path. The key network functions you should see on any reasonable diagram are AMF, SMF, UPF, UDM, AUSF, UDR, and PCF. The AMF handles registration and mobility. The SMF manages sessions and controls the UPF. The UPF is where actual user plane traffic goes through. The UDM stores subscriber data. The AUSF does authentication. The UDR is the data repository the UDM reads from. The PCF controls policy. That basic set covers most deployments. What beginners usually miss is that these functions can be deployed together or separate depending on scale. A small private 5G network might run AMF, SMF, and AUSF on a single server. A tier-1 carrier will have dozens of instances of each, load-balanced across regions. The diagram changes completely depending on whether you are looking at a reference architecture or an actual vendor implementation. NGEON and Cisco have very different ways of collapsing functions onto physical hardware, and both are correct within their own ecosystems. Another thing nobody puts on the diagram is the control plane versus user plane separation. CUPS is supposed to be a core principle of 5G, but in practice the split point moves around a lot. Some vendors keep the SMF tightly coupled with the AMF for faster signaling. Others push the UPF to the edge and keep the SMF centralized. Your diagram needs to show where that boundary actually sits in your deployment, not just where the standard says it should sit. I also had a situation where the diagram showed a single UDM serving all subscribers, but the real deployment had UDM separated by homestead for different roaming partners. Each homestead had its own UDR backend with different schemas. When a visitor from Partner A tried to register, the SMF was querying the wrong UDM instance because the diagram did not show the SBI service-based interfaces with their routing groups. This took me about four hours to diagnose because every tool assumed a flat UDM topology. Downloadable diagrams you find on the internet are usually generated from vendor SDKs or drawn by consultants who have never touched a live system. They look professional but contain errors like showing N11 between AMF and SMF when it is actually N11 between AMF and SMSF, or mixing up N1 and N2 labels. Always cross-reference against the 3GPP TS 23.501 specification before using any diagram for actual work. The real value of a good 5G core diagram is not in showing every box and arrow. It is in showing which boxes and arrows change when you add a new feature like URSP rules, network slicing, or multi-homed PDU sessions. Those features add new interfaces and new decision points that most static diagrams completely ignore. If your diagram does not account for how the SMF makes per-session routing decisions through the PCF, it is not useful for anyone doing actual engineering work.