If you test a probe, a DPI engine, a firewall, a packet broker or your own parser, sooner or later you need mobile-core signaling: GTPv2-C on S11/S5, PFCP on N4/Sxb, and GTP-U carrying the user plane. The obvious source is a real network, but most engineers do not have one at hand. Production captures contain subscriber data and cannot leave the operator. A lab core needs installation, configuration, SIM cards and often radio hardware.

This article walks through the realistic options for getting usable GTPv2-C and PFCP traffic without a live core, and where each one fits.

What "realistic" traffic actually means

A single well-formed Create Session Request is easy to produce. A useful test capture is harder, because the messages have to belong together:

  • Request and response pairing. Sequence numbers must match, and the response must refer to the correct TEID.
  • Correlated control and user plane. The F-TEIDs negotiated in GTPv2-C and PFCP must be the TEIDs that later appear in GTP-U packets. In 5G, the QFI matters too.
  • Procedures, not packets. Attach, modify, handover and release are sequences. A tracker or analytics engine expects a session to start, change and end.
  • Negative cases. Malformed IEs, rejected requests and unexpected messages are often what you really need to test.

Keep these four points in mind while comparing the approaches below.

Option 1: Run an open-source core

Projects such as Open5GS and free5GC implement core network functions and, combined with a RAN simulator, produce genuine signaling.

Good for: end-to-end behavior, interoperability work, learning how a core is deployed.

Trade-offs: it is a deployment project in itself. You configure several network functions, subscriber databases and networking, and you get the traffic that the core implementation happens to produce. Generating thousands of subscribers, specific mobility events or deliberately broken messages usually means extra tooling.

Option 2: Craft packets with Scapy

Scapy has contributed layers for GTP and PFCP, so you can build messages in Python and write them to a pcap.

Good for: precise control over a single message, fuzzing individual fields, quick scripts in an existing Python test framework.

Trade-offs: you write the state yourself. Pairing requests with responses, allocating TEIDs and SEIDs consistently, keeping GTP-U aligned with the negotiated F-TEIDs and modeling a handover are all your code. That is fine for ten messages and becomes a maintenance burden for full scenarios.

Option 3: Reuse and edit existing captures

Sample captures from public repositories or earlier projects can be replayed or edited. This is fast when a capture with exactly the right procedure exists. It rarely does, and editing IDs consistently across GTP-C, PFCP and GTP-U by hand is error-prone. (Our second article covers editing captures without breaking lengths and checksums.)

Option 4: Use a scenario generator

A dedicated generator builds whole procedures with correlation already handled. This is the gap Mobile Core Generator from Loosha Soft is built for. According to its product page, it:

  • generates 4G/5G control- and user-plane traffic without a live network, SIM cards or radio hardware;
  • builds GTPv2-C, PFCP, GTP-U and RADIUS scenarios, with attach, modify, handover and release procedures;
  • keeps generated GTP-U correlated with the control plane through TEID and QFI, so the capture behaves like one coherent subscriber scenario;
  • models reselection, intra- and inter-TA handovers and inter-MME mobility;
  • produces positive, malformed and negative cases;
  • works from the GUI for exploration and the CLI for automation.

Once you have a capture, the same tool helps you read and use it:

  • Explain Packets shows each generated message decoded in context, with the relevant 3GPP references alongside.
  • GTP Sessions groups GTPv2-C dialogs, GTPv1-C PDP contexts and PFCP sessions by TEID, F-TEID, SEID and IMSI, links GTP-C to PFCP, and reports state-machine violations, retransmissions, unmatched responses, TEID collisions, hanging sessions and per-procedure latency as text, JSON or CSV. This works on any capture, not only generated ones.
  • Send to network replays a pcap with target IP/MAC rewrite and live TX counters. It uses loopback by default and real interfaces only when you explicitly allow them.
  • An optional MCP server lets Claude Desktop, Cursor and other assistants query the session results locally.

A practical workflow

  1. Define the scenario. Decide which procedures and how many subscribers you need, and whether you need mobility or negative cases.
  2. Generate the capture in the GUI first, check it, then repeat it from the CLI in your test pipeline.
  3. Validate it. Open it in Explain Packets, or in Wireshark/tshark if you prefer. tshark is optional but supported for richer validation.
  4. Check the sessions with GTP Sessions to confirm that every request has a response and no TEIDs collide, unless you created that collision on purpose.
  5. Feed the device under test by replaying the capture to a lab interface, or by loading the file directly into the system you are testing.

Which option should you pick?

Need Best fit
True end-to-end core behavior Open-source core + RAN simulator
One message, fully hand-controlled Scapy
Full correlated procedures, mobility, negative cases, quickly Scenario generator
Analysing sessions in an existing capture GTP Sessions, or the GTP Session Tracker Wireshark plugin

These approaches are not exclusive. Many teams use Scapy for single-field fuzzing and a generator for scenario-level coverage.

Editions

Mobile Core Generator has a Community Edition, free for non-commercial evaluation, learning and compact lab scenarios (up to 100 subscribers/sessions, with send-to-network capped at 1000 packets/s). The Full Edition is a one-time $89 license. It removes those limits and adds response matching (probe) and a conformance suite with HTML/JSON reports. The current release runs on Windows 10/11 64-bit, and a Linux build is available on request.

Explore Mobile Core Generator →

FAQ

Do I need SIM cards or radio hardware? No. The traffic is generated directly; no live network, SIM or radio is involved.

Is the user plane linked to the control plane? Yes. Generated GTP-U stays correlated with the control plane through TEID and QFI.

Can I generate broken messages? Yes. Positive, malformed and negative cases are supported.

Can I analyse captures I did not generate? Yes. GTP Sessions works on any capture containing GTPv2-C, GTPv1-C or PFCP.

Will it send traffic onto my network by accident? Send to network uses loopback by default. Real interfaces are used only when you explicitly allow it.