Tag Archives: PGW

Packet Gateway (P-GW) used in LTE EPC Networks

LTE EPC: Packet Gateway (P-GW) Basic Function

The Packet Gateway connects users of an LTE network to external networks like the Internet, by encapsulating IP packets inside GTP and forwarding them on to reach our subscriber wherever in the network they are.

To understand the P-GW, first it’s a good idea to first get a grasp on what GTP is and why we use GTP to transport subscriber’s data through the LTE Evolved Packet Core.

So we use GTP to encapsulate user’s traffic, making it easy to carry it transparently from outside networks (Like the Internet) to the eNodeB and onto our UE / mobile phones, and more importantly redirect where the user’s traffic it’s going while keeping the same IP address.

But we need a network element to take plain old IP from external networks / Internet, and encapsulate the traffic into the GTP packets we’ll send to the subscriber.

This network element will have to do the same in reverse and decapsulate traffic coming from the subscriber to put it back onto the external networks / Internet.

That’s the role of the Packet Gateway (P-GW). The P-GW sits on the border between the outside network (An interface / reference point known as the SGi Interface) and the rest of the packet core (Serving-Gateway then onto eNodeB & UE) via the S5 Interface.

Let’s look at how the P-GW handles an incoming packet:

  1. An IP packet comes in from the Internet destined for IP and routed to the P-GW.
  2. The P-GW looks up in it’s internal database what Tunnel Endpoint Identifier (TEID) IP Address is associated with.
  3. The P-GW encapsulates the IP packet (Layer 3 & up) into a GTP packet, adding the Tunnel Endpoint Identifier (TEID) to the GTP header.
  4. The P-GW looks up in it’s internal database which Serving Gateway is handling traffic for that TEID.
  5. The P-GW then sends this GTP packet containing our IP packet to the Serving Gateway.

In order to start relaying traffic to/from the S5 & SGi interfaces, the P-GW needs a set of procedures for setting up these sessions, (IP Address allocation and TEID allocation) known as bearers. This is managed using GTPv2 (aka GTPv2-Control Plane / GTPv2-C).

GTPv2-C has a set of procedures for creating these sessions, the key ones used by the P-GW are:

  • Create Session Request / Response – Sets up GTP sessions / bearers
  • Delete Session Request / Response – Removes GTP session / bearers

The Create Session Request is sent by the S-GW to the P-GW and contains the APN of the network to be setup, the IP Address to be assigned (if static) and information regarding the maximum throughput the user will be permitted to achieve.

If the P-GW was able to setup the connection as requested, a Create Session Response is sent back to the P-GW, with the IP Address for the UE to use, and the TEID (Tunnel Endpoint Identifier).

At this stage the tunnel is up and ready to go, traffic to the P-GW to the IP of the UE will be encapsulated in GTP-U packets with the TEID for this bearer, and forwarded on to the S-GW serving the user.

Open5GS EPC: Static IP Addresses for UEs / APNs / Subscribers

A question that seems to come up often, is how to provide a static IPs to UEs on Open5GS EPC.

By default all UEs are allocated an internal IP that the server the P-GW is running on NATs out, but many users want to avoid NAT, for obvious reasons.

Open5GS has the ability to set a Static IP for each APN a subscriber has, but let’s get one thing out of the way first;

LTE is not Ethernet. No broadcast, no multicast. Each IP Address is best thought of as a single /32 network.
This means you can’t have the UEs in your LTE network in the same 192.168.1.x subnet as your home network along with your laptop and printer, it’s not how it works.

So with that out of the way, let’s talk about how to do static IP address allocation in Open5GS EPC.

Assigning a Subscriber a Static IP Address

From the HSS edit the Subscriber and in the UE IPv4 or UE IPv6 address, set the static address you want to use.

You can set any UE IP Address here and it’ll get allocated to that UE.

But – there’s an issue.

The problem is not so much on the Open5GS P-GW implementation, but just how TCP/IP routing works in general.

Let’s say I assign the UE IPv4 address to my UE. From the UE it sends a packet with the IPv4 Source address of to anywhere on the internet, the eNB puts the packet in GTP and eventually the it gets to the P-GW which sends it out onto the internet from the source address

The problem is that the response will never get back to me, as is not allocated to me and will never make it back to my P-GW, so never relayed back to the UE.

For TCP traffic this means I can send the SYN with the source address of, but the SYN/ACK will be routed back to the real, and not to me, so the TCP socket will never get opened.

So while we can set a static IPs to be allocated to UEs in Open5GS, unless the traffic can be routed back to these IPs it’s not much use.


So let’s say we have assigned IP to the UE, we’d need to put a static route on our routers to route traffic to the IP of the PGW. In my case the PGW is, so I’ll need to add a static route to get traffic destined to

In a more common case we’d assign internal IP subnets for the UE pool, and then add routes for the entire subnet to the IP of the PGW.

List of Open Source Evolved Packet Core (EPC) Implementations


Formerly NextEPC.

OpenAI Core Network

Related to / branched from OMEC.


Based on OMEC, with a focus on Fixed Wireless more than mobile.

Not fair to consider it just an EPC, Magma is highly scaleable and designed with a focus on Fixed Wireless offerings.

Supported by the Facebook Telecom Infra Project.

OMEC – Open Evolved Mobile Core

Supported by Open Networking Foundation, Sprint and several other large players.

OMEC has each Network Element in it’s own repo in GitHub and each is managed by a different team.


In use by at least one commercial operator (in some capacity).

Next Generation Infrastructure Core (S-GW & P-GW)

Seems to only compile on 16.04 and not really

c3po – HSS / CDR / CTF



(from the guys who produced srsLTE / srsENB / srsUE)