README.mgw.org

Mobile Gateway (MGW)

The mobile gateway pipeline (name: mgw) represents a simplified 5G gateway that connects a set of mobile user equipments (UEs), located behind base stations (BSTs), to a set of public servers available on the Internet.

Static pipeline

In the uplink direction (UE/BST -> server) the MGW receives GTP-encapsulated packets from the base stations, identified by the source IP address in the GTP header, and forwards the decapsulated packets to public servers in the Internet. After decapsulation, the source IP address identifies the user and the GTP TEID identifies the bearer, the the destination IP designates the public server to forward the packet to. The uplink pipeline performs various checks, decapsulates the UE’s packet from the GTP tunnel, identifies the user and polices the UE (rate limiting), and then routes the decapculated packet to the Internet.

In the downlink direction (server -> user/bst) the MGW receives normal packets from the Internet and the pipeline is basically the reverse of the uplink one: identify the UE/bearer based on the packet destination IP address (we now assume there is only one bearer per user), rate limit the UE flow, and encapsulate and send the packet to the BST behind which the UE is currently located.

In particular, the MGW performs the following processing steps per uplink/downlink packet:

Uplink:

• L2, L3 and L4 check (gateway MAC/IP and UDP port destination 2152)
• GTP decap, save TEID
• rate limit per bearer (TEID)
• L3 routing towards the Internet + L2 fwd

Downlink:

• L2 and L3 check (check if destination IP is in the UE range)
• per user rate limiting
• GTP encap (set bearer in TEID)
• set destination IP of the base station of the UE
• L3 routing towards BSTs + L2 fwd

This roughly maps to the below modules:

• Ingress:
  • l2_fwd: identify local packets
  • ether_type: identify ARP/IP packets
  • dir_selector: distinguish uplink/downlink packets
• Egress:
  • rate_limiter: per user traffic policing
  • l3_lookup: route to servers (uplink) and BSTs (downlink)
  • group_table: next-hop setting per server and BST
• Uplink: Ingress -> GTP decap -> Egress
• Downlink: Ingress -> UE selector -> GTP encap -> Egress
  • ue_selector: find the GTP TEID for the user’s IP address

Dynamic scenarios

TIPSY defines the below update scenarios for the MGW pipeline.

• user-update: model the arrival/departure of a user; a UE arrives/departs to/from a BST, involving the following updates to the pipeline:
  • an entry is added/removed to/from the ue_selector module
  • the queue for the user in the rate_limiter is updated
• handover: models user mobility (handover); a user’s attachment point (i.e., BST) changes, with the below changes to the pipeline:
  • the ue_selector table is updated
• server-update: addition/removal of a server: a destination in the public Internet changes
  • the l3_lookup and the group_table are modified accordingly

Pipeline configuration

A sample TIPSY configuration for the MGW pipeline is shown below:

{
    "pipeline": {
         "name": "mgw",
         "user": [1, 2, 3],
         "bst": [9, 4, 10],
         "server": 1,
         "rate-limit": 10000,
         "nhop": 4,
         "fakedrop": false,
         "fluct-user": [17, 200],
         "handover": 0,
         "fluct-server": 4,
    }
}

The parameters specific to the MGW pipeline are as follows:

• name: name of the pipeline, must be set to mgw for the MGW pipeline
• user: number of UEs
• bst: number of BSTs
• server: number of public servers
• rate-limit: rate limit threshold [byte/sec]
• nhop: number of next-hops in the L3 table towards the public Internet
• fakedrop: whether to actually drop unmatched packets (false) or send them immediately to the output port (true) for correct rate measurements
• fluct-user: number of user arrival/departure events (user-update) per sec
• handover: number of handover events (handover) per sec
• fluct-server: number of server update events (server-update) per sec
• fakedrop: whether to actually drop unmatched packets (false) or send them immediately to the output port (false) for correct rate measurements

OVS Implementation: Caveats and considerations

BESS Implementation: Caveats and considerations