P4EC: Enabling Terabit Edge Computing in Enterprise 4G LTE

Max Hollingsworth Jinsung Lee Zhang Liu Jihoon Lee Sangtae Ha

Dirk Grunwald
Department of Computer Science, University of Colorado Boulder

Abstract particularly useful for enterprise, campus, and municipality

scale LTE deployments.
Traditional LTE networks route Internet traffic through
With this increase in the number of small-scale LTE opera-
a packet gateway. Enterprise LTE networks with a cloud-
tors comes an opportunity for cloud providers, like Amazon,
based core use a similarly faraway gateway. To provide low-
to offer a cloud-EPC [8]. A cloud-EPC model would mean
latency services, such as accessing nearby mobile devices, fog
purchasing physical eNBs (similar in size to a WiFi router)
services, or localized information, a “local-exit” to the Internet
and deploying them over a property (e.g., a warehouse or
is needed to avoid traveling through the LTE core. To create a
campus) with an Internet backhaul to connect to a cloud-EPC
local-exit, we build P4EC, a terabit capable mobile edge cloud
service. The cloud-EPC simplifies the deployment for the
using a programmable switch to distinguish and reroute traffic.
enterprise CBRS LTE operator. But, it also binds them to the
P4EC is placed physically near the cellular deployment and
latency created by having a PGW in a distant cloud datacenter.
reroutes specifically identified traffic to and from the mobile
There are many latency sensitive applications that rely on
device. The P4EC implements packet redirection using the
LTE (e.g., augmented reality, wearable cognitive assistants,
P4 programmable switching hardware that supports terabit
and IoT sensors). Latency is most crucial in public safety
throughput in inexpensive equipment. P4EC operates without
applications. Command and control applications used by fire
any modification to the LTE core. This work describes a
departments are a good example of a localized, time-sensitive
working proof-of-concept operating in an actual LTE network.
service that cannot rely on a distant cloud datacenter. These
applications provide firefighters with critical information such
1 Introduction as orders, location, and movement. Our results show large
delay reductions (≥100ms) in video streaming applications
LTE networks have three major components: mobile devices similar to those deployed by public safety. CBRS operators
(UEs), the radio access network composed of base stations would be challenged to provide public safety members with
(eNBs) and the core network (EPC). The EPC serves a variety low-latency services, such as these, simply because of the
of functions including subscriber authorization, managing distance of the cloud-EPC.
UE movement, and provides a packet gateway (PGW) to the Our solution to the latency issues caused by the cloud-EPC
Internet. A large mobile network operator (MNO), such as is the P4EC. When deployed, the P4EC acts as a middle-
AT&T, typically uses one EPC to serve a very large physical box, monitoring all traffic between the eNB and EPC. P4EC,
region, sometimes many states. All cellular traffic in that shown in Figure 1, is a programmable P4 switch using the
region passes through the PGW on its way to the Internet. Barefoot Tofino chipset with multiple 100 GbE ports. The
Currently, there are only a handful of MNOs operating in Tofino switch provides line-rate packet processing with an
the United States. The number of MNOs is likely to grow aggregate 2.0 Tbps throughput.
rapidly due to recent changes in spectrum policy. In 2012, the At this throughput the P4EC switch can handle the com-
FCC allocated 150 MHz of spectrum in the 3.5 GHz band bined traffic from over 7,300 eNBs1 [5]. Each eNB can serve
for use by private LTE operators using the Citizens Broad- hundreds of active UEs. The switch costs slightly more than
band Radio Service (CBRS) [12]. In September of 2019, the $9,000 making the price per active UE roughly a penny.
FCC approved the first commercial deployments of the CBRS Using custom P4 programs, traffic deemed latency sensitive
access system [13]. When coupled with License Assisted Ac- is redirected to the “local-exit”. The P4EC serves two roles
cess (LAA) operation in 5 GHz band, there will likely be 1 An eNB is assumed to support a single-sector, 20 MHz FDD, 2x2 MIMO,

many small-scale network operators. CBRS and LAA are 256-QAM downlink, and 64-QAM uplink.
Figure 1: Our end-to-end LTE testbed consists of UEs, an eNB, a P4 programmable switch (P4EC), and a cloud-EPC. The switch
reroutes traffic meant for low-latency services out the local-exit.

in an LTE deployment; first, it provides a quick access to fog- identifies the UE through source IP address; c) provides a
computing resources physically near the eNB, thus offering local-exit; and d) performs transport-layer redirection. The
faster round-trip communication than the cloud. Second, the local-exit means that the UE can access fog services, nearby
P4EC acts as a “bump-in-the-wire” for non-fog-bound traffic UEs on different providers, and the Internet. Because our solu-
and control information passing between the eNB and the tion is programmable, it can be extended to include different
EPC. As a result, the P4EC can function without any modifi- access control policies, encapsulation methods, and transport
cation to the EPC. Thus P4EC is an easily added, inexpensive options.
system ready for large-scale LTE deployments. MEC in 4G LTE: Traffic offloading in 4G LTE has been
used for reducing backhaul traffic [1, 2]. LIPA (Local IP Ac-
cess) considers a limited network architecture where a small
2 Related Work cell eNB has a local gateway functionality and enables the
Providing edge computing in mobile networks (Mobile Edge UE to access other IP capable devices in the same IP network
Computing, or MEC) has been a popular topic in recent years. without traversing the core network. This feature only sup-
The following explains research and standardization efforts ports local connection between devices in physical proximity.
for enabling MEC in 4G/5G networks. SIPTO (Selective IP Traffic Offload) assumes a similar net-
work architecture and enables the UE connected via the eNB
Architecture proposals: Several works have studied the ar-
to access a defined IP network (e.g., Internet) directly with-
chitectural design for MEC deployments over cellular net-
out traversing the PGW. SIPTO is a network-driven solution
works. Chang et al. [10] proposed a standard-compliant modu-
and cannot be controlled by the UE. More importantly, these
lar MEC architecture and described the functional mapping to
proposals have not been specified in the 3GPP standards and
LTE systems. Huang et al. [16] presented an OpenFlow-based
also not deployed in the field.
MEC framework that can provide the required data-plane
flexibility and programmability. Huang et al. [17] presented 5G standard efforts: Apart from 4G EPC architecture, 5G
a prototype implementation of a MEC platform by develop- network standards have included several features to facilitate
ing an application-aware traffic redirection mechanism at the MEC deployment for operators and 3rd party services [3, 4].
edge network. However, all these solutions require modifica- Specifically, 5G core allows distributed deployment of multi-
tions on the eNB and the existing core network, so large-scale ple gateways, so that it can select a proper gateway close to the
deployment can be challenging. UE’s point of attachment, based on which various advanced
features for edge computing can be realized. For example,
A middlebox approach [20] simplifies deployment of a
5G core can accommodate the concept of a local area data
MEC platform in 4G LTE networks. Their work is standard-
network that provides an isolated data service to UEs within a
compliant and transparent to existing network components
certain geographic area [19]. In addition, there is an ongoing
for deployment in the field. We recognized the value of the
effort to integrate such MEC standards within the 5G network
proposed transparent middlebox but have identified a few lim-
for efficient management and orchestration of edge computing
itations: a) packet-filtering and forwarding, performed on a
applications [11].
PC with Python and iptables, is not a commercial solution;
b) there is no mechanism to distinguish privileged UEs that
should have access to edge services; c) access is provided 3 System
only to an edge machine; and, d) redirection will not work
with DNS over HTTPS, which is being rapidly deployed. To There are a number of design decisions needed to create the
address these limitations, this work a) implements a P4 switch P4EC. Here, we describe two of the more significant deci-
solution capable of handling terabits of traffic at line-rate; b) sions: content redirection and transparency to the EPC. As a
note, other design decisions, such as how to identify UEs and
routing rules, are described in the implementation section.
Content Redirection: The first design decision is how to
identify content (e.g., a TCP session, or real time streaming)
to reroute via the local exit. This practice, called content redi-
rection, is commonly used by CDNs and comes in three gen-
eral techniques: DNS redirection, transport-layer redirection,
and application-layer redirection [7]. Based on the following
analysis of these three techniques, we implemented transport-
layer redirection in P4EC. Figure 2: A network diagram of our LTE entities: UE, eNB,
P4EC, and cloud-EPC. The on-site equipment is located
DNS redirection, as used by CDNs, employs a name server
within our research center. And the EPC is hosted in the
to respond to the client with an A (address) record of a surro-
cloud in the nearest Google data center.
gate server rather than the content originator. DNS redirection
has been proposed for use in other LTE MEC designs, and
if deployed in the P4EC would intercept all DNS queries Transparency: The P4EC can either operate with or without
and respond only to domains that it recognizes and forward EPC coordination. There are three different levels of trans-
the rest. Using DNS redirection can ensure an entire session parency we considered. The first, non-transparent method,
is rerouted and that the content goes to the appropriate fog involves modifying the EPC to notify the P4EC when eligible
server, given network load, content availability, and proximity. UEs attach to the network. This method simplifies the P4EC’s
The drawbacks include: a) DNS only allows for resolution responsibilities but could only be deployed with modified-
at the domain level, where a redirect at the per object level EPCs. The second method is to monitor the control messages
might be desired, and b) secured DNS techniques like DNS- (S1AP) that pass between the eNB and EPC. When the P4EC
over-HTTPS and DNSSEC make DNS redirection impossible sees a UE attach message it records the UE’s identifier, MME-
in middleboxes. UE-S1AP-ID, and will serve that UE until the detach message
Transport-layer redirection deploys an in-path element to is seen. The attach request message contains the UE’s unique
examine a packet’s IP addresses, ports, and protocol to decide identifier called IMSI (International Mobile Subscriber Iden-
whether to reroute. When a packet is flagged, it is rerouted to tity). The network operator must specify the IMSIs of the
a virtual surrogate that acts as the end point, this is labeled as UE’s permitted to use local exits. This method is transpar-
NAT in Figure 2. The virtual surrogate, who has knowledge ent and involves no modification of the EPC, but will not
of the edge network’s topology and load, forwards to another work with temporary identifiers called Temporary Mobile
surrogate or group of surrogates to handle the actual service. Subscriber Identity (TMSI). The third method involves no
The benefits of transport-layer redirection are that the P4EC modification to the EPC and no operator interaction with the
does not need to know about the edge network’s status, i.e., P4EC after installation. This method relies on the UE to self-
surrogate load, availability, proximity, and bandwidth. The identify to the P4EC with out-of-band signals (authorization
P4EC is only aware of the virtual surrogate, and the edge packets). These packets would contain credentials that notify
service provider that exists past the NAT has control of load the P4EC that the UE is an approved user. The drawback to
balancing across the edge. NAT services can either be imple- this method is that each application that wants a local-exit
mented in a separate system or implemented at terabit speeds access must self-identify to the P4EC. We believe this will
using P4; our prototype uses a separate NAT middlebox. be our ultimate solution though we currently have the second
There are multiple methods to implement application- method implemented.
level redirection which uses an in-path element that parses
application-layer headers for fields such as URL, cookies,
language, and user-agent in order to select an appropriate sur- 4 Implementation
rogate. This provides the benefit of fine-grained redirection
control of an individual object. Unfortunately, without appli- Testbed setup: The UE is a Galaxy S8. The eNB, a Juni LTE
cation level coordination, TLS encryption obscures most of Small Cell [18], is physically located in our lab. When pow-
the application-layer information of interest. ered on, it establishes a connection with the EPC; we use the
For P4EC, we chose transport-layer redirection because open-source NextEPC [22] that we deploy on Google Cloud
an edge service provider can define the exact behavior based Platform (GCP) [14]. The P4EC runs on a Stordis BF2556x-
on their knowledge of surrogate load, surrogate availability, 1T [25] located in a server rack in the same facilities as our lab.
proximity, bandwidth, and content availability. This changes Figure 2 shows the network diagram of the four LTE entities:
the P4EC’s primary role to classifying traffic and incorporat- UE, eNB, P4EC, and EPC. The eNBs and the EPC typically
ing edge information to effect load balancing. We see this exist on a private IP network. To create a private network
simplification of the P4EC’s role as an advantage. between the eNB and cloud-EPC we use OpenVPN [23]; al-
though IPSEC can be implemented in P4, we have not taken packets coming from the EPC, and the GTP tunnel identifiers
that step. are tracked by monitoring S1AP packets.
Cloud-EPC setup: There are two concerns when setting up a
cloud-EPC. The first is security and the second is successfully
routing packets from the eNB to the EPC and back. Many 5 Evaluation
installations use a VPN or IPSEC for security and the GPRS
To inspect the latency of the separate stages of the LTE net-
Tunnel Protocol (GTP) is used to tunnel a UE’s data between
work we use the ping tool. As shown in Figure 3, we perform
the eNB and EPC, as specified in [6]. Assuming the EPC
separate latency tests from the UE to the two Internet gate-
has a public IP address and the eNB is on a private network
ways at its disposal: PGW and NAT. The test on the left shows
behind a NAT, outgoing UE traffic will reach the EPC but
the UE to cloud-PGW round-trip time (RTT), which is sep-
the return traffic cannot reach the UE because of the private
arated into time spent in the radio access network (RAN)
network and tunnel. We use a VPN to give the EPC access to
and passing between the eNB and PGW (network core). The
the eNB’s private network.
test on the right shows the UE to NAT RTT, which is also
The cloud VPN server and EPC are implemented using an
separated into time spent in the RAN and network core.
Ubuntu 16.04 server with four virtual CPUs and 16 GB of
The measurements were taken with 300 pings to the PGW
memory. This is sufficient to handle the traffic generated by
and NAT each. We use the same RAN in both tests. We find
the UEs in our latency tests. The cloud-EPC can easily scale
that the RAN introduces much more latency variance than the
by deploying larger VM instances.
network core even with single packet pings. Waiting time may
P4 switch: The P4EC is a P4 programmable switch that per-
vary depending on when a packet becomes ready, which has
forms routing to and from the local-exit. P4 [9] is a high
to be scheduled in the next uplink transmission period [24].
level programming language for packet processing, which al-
Note that our latency measurements on the RAN side are
lows protocol independent, deep programmability for the data
consistent with recent 4G/5G measurements [21].
plane using Match-Action tables. The P4 Tofino packet pro-
The local-exit’s success in decreasing overall latency is
cessing pipeline contains the following components: Parsers,
shown by the "Network Core" columns. The "Network Core"
Deparsers, Ingress processing, Packet Replication Engine
columns are highlighted in Figure 4. As the PGW is physically
(PRE) and Egress processing. Match-Action tables are lo-
located at a distance (about 550 miles away in this case), it
cated inside Ingress/Egress Processing. PRE is located be-
is expected that there is some latency in RTT. For this test
tween Ingress/Egress processing and is used for advanced
we chose the GCP region nearest to our facilities. The added
functions such as Packet Mirroring, Multi-Cast, etc. Parsers
RTT is about 13ms. Traffic that passes through the PGW does
and Deparsers are used to parse and reconstruct packet head-
not only suffer from added latency, but is also exposed to
ers before and after Ingress/Egress processing. Once the data
increased variance of the public Internet (indicated by the
plane logic is described using P4 language, a special compiler
heavy tail in the “eNB - PGW” column).
is then used to compile P4 into Tofino Native Architecture
From Figure 5 we show the advantage that the local-exit has
binary that can be run on our switch.
over the nearest datacenter and other datacenters increasingly
The P4EC monitors traffic between the eNB and the EPC.
far away. This highlights that the local-exit’s efficacy can be
This includes all of the control signalling (S1AP) and the
amplified in situations when the cloud-EPC becomes farther
data (GTP) traveling to and from the UEs. By monitoring the
from the eNB. The local-exit offers flexibility to the network
S1AP packets for Attach-Request and Detach messages the
operator who may decide to deploy the cloud-EPC in a sub-
P4EC maintains a table of the active UEs. Actions for specific
optimal location for cost, convenience, etc.
packets (e.g., a flow from a UE) are specified in tables and
perform matching at wire speed. A controller processor on
5.1 Application Performance
the P4 switch populates the re-routing tables using either an
out-of-band API or by reacting to authorization packets from Web browsing: We use web browsing as a simple but real-
the UE. Unmatched packets are routed to the EPC. world application to test the performance of the P4EC. On
In order to reroute packets to an edge server, the P4EC the UE we run curl to repeatedly measure the total time to
matches on the UE’s IP and the destination IP address. Then download a webpage. The download is 100KBs in size and
the decapsulation stage removes the outer IPv4, outer UDP, the UE and server exchange about 150 TCP packets. The
and GTP headers. The P4EC modifies the out-going MAC webpage is hosted geographically near our facilities and was
and optionally the source address if performing NAT. specifically chosen to show off the advantage of having a
For a return packet from the edge to the UE, the P4EC must local-exit near the eNB. It is important to note that P4EC
inject the packet back into a GTP tunnel. First, a match occurs allows us to enable the local-exit for a specific UE and a
on the destination IP, which should be the UE’s IP. Then the specific set of destination addresses – we match on the 5-
packet is encapsulated with appropriate IPv4, UDP, and GTP tuple (protocol, src address and port, dst address and port) and
headers and is sent to the eNB. These headers mimic the other UEs using the same network are not redirected.
Figure 3: Ping RTT from UE to the cloud- Figure 4: Ping RTT from the eNB to Figure 5: Ping RTT from the UE to the
PGW vs. from UE to the local-exit. Also, the cloud-PGW vs. from the eNB to the local-exit vs. from the UE to the PGW of
separated into time within RAN and core. local-exit. increasingly distant datacenters.

Figure 6: Webpage download time using Figure 7: WebRTC RTT for 4 minute Figure 8: WebRTC streaming delay for 4
local-exit vs. the nearest cloud exit. streaming video call. minute streaming video call.

Figure 6 shows that the median latency fell nearly 300ms end-to-end streaming delay, shown in Figure 8, also com-
and the variance greatly narrows. By using the local-exit, we pares the local-exit to the cloud-EPC. The local-exit causes a
avoid the 13ms round-trip to the PGW and back, twice. But large reduction in delay, more than 100ms. WebRTC video
26ms falls short of explaining the 300ms of savings. The streaming is a good analog for applications that benefit from
cause is likely the compounding effects of buffering at routers a local-exit. Already, there are scenarios when low-latency
and other middleboxes in the Internet, with the impact of streaming between two physically near parties is essential
waiting for TCP ACKs to travel and the extra 26ms before such as public-safety members responding to an emergency.
continued transmission. The latency will be further reduced
when the P4EC performs network translation.
6 Conclusion and Future Work
Live video streaming: We use the WebRTC [15] application
to evaluate live video streaming. The video calls are estab- In this paper we presented P4EC, a mechanism for terabit
lished between a Galaxy S8 connected to our LTE testbed and capable mobile edge cloud in enterprize-scale LTE networks.
a high-end laptop (running Ubuntu 18.04) connected to the We use a P4 programmable switch to distinguish and reroute
Internet via campus Ethernet. traffic. The Tofino platform is malleable enough to cover
WebRTC is configured with the resolution of 1280x720 many applications and the hardware is powerful enough for
(HD) at 30fps and the max video encoding rate of 2.5 Mbps. commercial use.
For the evaluation, we measure RTT at the transport layer and We measure P4EC against web browsing and live video
end-to-end streaming delay, defined as the time lag from when calling. In both cases we saw significant decreases in latency.
a video frame is generated on the sender until it is displayed Our proof-of-concept implementation showed that the P4
on the receiver’s screen. Thus, it consists of video capturing, switch is a viable, inexpensive candidate for P4EC, and that
encoding, transmission, decoding, and rendering delays. We the P4EC can function without any modification to the net-
follow the measurement methodology of a previous measure- work core.
ment study [26]. As our future work, we would like to answer the following
Figure 7 shows the transport layer RTT for WebRTC. We questions: (i) How can we maintain edge services as a UE
compare the video call through the cloud-EPC to the video moves from one eNB to another? (ii) How do we identify
call through the local-exit. The local-exit call has a median the UE as a subscriber (when TMSI changes regularly)? (iii)
RTT 27ms faster than the cloud-EPC. This is explained by Can the UE self-identify as P4EC-eligible? (iv) Is P4EC
the 26ms reduction in travel by avoiding the cloud-EPC. The interoperable with other open-source EPCs?
7 Discussion Topics [8] Monica Alleven. Federated launches new CBRS
services with AWS, Microsoft Azure, Feb 2020.
There are two sets of problems in this paper. One set of prob- http://www.fiercewireless.com/wireless/
lems is deciding what LTE model makes sense for CBRS federated-launches-new-cbrs-services-aws-
deployments (i.e., a cloud-EPC vs. local-EPC vs. a hybrid microsoft-azure.
solution). The other set of problems is given a specific CBRS
model, how do we deliver high-performance edge computing [9] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick
to those deployments. McKeown, Jennifer Rexford, Cole Schlesinger, Dan
We are interested in the audience’s feedback on what CBRS Talayco, Amin Vahdat, George Varghese, et al. P4:
LTE (and 5G) deployments will look like. We have assumed Programming protocol-independent packet processors.
CBRS operator will subscribe to a cloud-EPC service and ACM SIGCOMM Computer Communication Review,
deploy eNBs (and SIM cards) around their facilities. But 44(3):87–95, 2014.
other ideas include a cloud-EPC with the MME on-site to
manage the eNBs and the movement of UEs amongst them. [10] Chia-Yu Chang, Konstantinos Alexandris, Navid
We would also like to address the implementation specific Nikaein, Kostas Katsalis, and Thrasyvoulos Spyropou-
problems of our system, of which there are a few: is it re- los. MEC Architectural Implications for LTE/LTE-A
alistic to avoid EPC modification to have a working MEC Networks. In Proceedings of ACM MobiArch, 2016.
switch? How does one passively identify a UE when their
TMSI changes regularly? How do you deter users from abus- [11] Sami Kekki et al. MEC in 5G networks.
ing the local-exit system? How do we maintain edge services White Paper 28, ETSI, June 2018. https:
while the user is moving from one eNB to another? What are //www.etsi.org/images/files/ETSIWhitePapers/
some specific latency requirements of various edge-dependent etsi_wp28_mec_in_5G_FINAL.pdf.
applications?
[12] FCC. Amendment of the Commission’s Rules with
Regard to Commercial Operations in the 3550-3650
References MHz Band, 2012. http://transition.fcc.gov/
Daily_Releases/Daily_Business/2012/db1212/
[1] 3GPP. Local IP Access and Selected IP Traffic Of- FCC-12-148A1.pdf.
fload (LIPA-SIPTO) (Release 10), 2011. http://
www.3gpp.org/dynareport/23829.htm. [13] FCC. WTB and OET Approve Initial Commer-
cial Deployments in 3.5 GHz Band, 2019. https:
[2] 3GPP. Local IP access (LIPA) mobility and Selected
//www.fcc.gov/document/wtb-oet-approve-
IP Traffic Offload (SIPTO) at the local network (Re-
initial-commercial-deployments-35-ghz-band.
lease 12), 2013. http://www.3gpp.org/dynareport/
23859.htm.
[14] Google. Cloud Computing Services. https://
[3] 3GPP. 5G; Procedures for the 5G System (5GS) (3GPP cloud.google.com, 2020.
TS 23.502 version 15.8.0 Release 15), 2020. http:
//www.3gpp.org/dynareport/23502.htm. [15] Google. WebRTC. https://webrtc.org, 2020.

[4] 3GPP. 5G; System architecture for the 5G System (5GS) [16] A. Huang, N. Nikaein, T. Stenbock, A. Ksentini, and
(3GPP TS 23.501 version 15.8.0 Release 15), 2020. C. Bonnet. Low latency MEC framework for SDN-
http://www.3gpp.org/dynareport/23501.htm. based LTE/LTE-A networks. In Proceedings of IEEE
ICC, 2017.
[5] 3GPP. Evolved Universal Terrestrial Radio Ac-
cess (E-UTRA); Physical layer procedures (3GPP TS [17] S. Huang, Y. Luo, B. Chen, Y. Chung, and J. Chou.
36.213 version 16.1.0 Release 16), 2020. http:// Application-Aware Traffic Redirection: A Mobile Edge
www.3gpp.org/dynareport/36213.htm. Computing Implementation Toward Future 5G Net-
[6] 3GPP. LTE; General Packet Radio Service (GPRS) works. In Proceedings of IEEE International Sympo-
enhancements for Evolved Universal Terrestrial Ra- sium on Cloud and Service Computing (SC2), 2017.
dio Access Network (E-UTRAN) access (3GPP TS
23.401 version 15.10.0 Release 15), 2020. http:// [18] Juni. Enterprise Small Cell JL620. http://
www.3gpp.org/dynareport/23401.htm. vidatele.com/smallcellsolutions.html, 2017.

[7] R. Nair O. Spatscheck A. Barbir, B. Cain. Known con- [19] J. Lee, S. Moon, B. Bae, and J. Lee. Local Area Data
tent network (cn) request-routing mechanisms. RFC Network for 5G System Architecture. In Proceedings
3568, 7 2003. of IEEE 5G World Forum (5GWF), 2018.
[20] Chi-Yu Li, Hsueh-Yang Liu, Po-Hao Huang, Hsu-Tung [24] Shinik Park, Jinsung Lee, Junseon Kim, Jihoon Lee,
Chien, Guan-Hua Tu, Pei-Yuan Hong, and Ying-Dar Lin. Sangtae Ha, and Kyunghan Lee. ExLL: An Extremely
Mobile edge computing platform deployment in 4g LTE Low-latency Congestion Control for Mobile Cellular
networks: A middlebox approach. In Proceedings of Networks. In Proceedings of ACM CoNEXT, 2018.
USENIX HotEdge 18, 2018.

[21] Arvind Narayanan, Jason Carpenter, Eman Ramadan,

Qingxu Liu, Yu Liu, Feng Qian, and Zhi-Li Zhang. A [25] Stordis. STORDIS BF2556X-1T. https:
First Measurement Study of Commercial mmWave 5G //www.stordis.com/products/stordis-bf2556x-
Performance on Smartphones, 2019. 1t/, 2019.

[22] NextEPC Inc. Open source implementation of LTE EPC.

https://nextepc.org, 2019.
[26] C. Yu, Y. Xu, B. Liu, and Y. Liu. “Can you SEE me
[23] OpenVPN. VPN Software Solutions and Services. now?” A measurement study of mobile video calls. In
https://openvpn.net, 2020. Proceedings of IEEE Infocom, 2014.