Toward Software-Defined Cellular Networks
Li Erran Li Z. Morley Mao Jennifer Rexford
Bell Labs University of Michigan Princeton University
erranlli@research.bell-labs.com zmao@umich.edu jrex@cs.princeton.edu
Abstract—Existing cellular networks suffer from inflexible
and expensive equipment, complex control-plane protocols, and
vendor-specific configuration interfaces. In this position paper,
we argue that software defined networking (SDN) can simplify
the design and management of cellular data networks, while
enabling new services. However, supporting many subscribers,
frequent mobility, fine-grained measurement and control, and
real-time adaptation introduces new scalability challenges that
future SDN architectures should address. As a first step, we
propose extensions to controller platforms, switches, and base
stations to enable controller applications to (i) express high-level
policies based on subscriber attributes, rather than addresses and
locations, (ii) apply real-time, fine-grained control through local
agents on the switches, (iii) perform deep packet inspection and
header compression on packets, and (iv) remotely manage shares
of base-station resources.
I. INTRODUCTION
The growing popularity of smart phones and tablet com-
puters places an increasing strain on cellular networks. Yet,
despite tremendous innovation in mobile applications, the
cellular network infrastructure is remarkably brittle. Software
defined networking (SDN) can simplify network management,
while enabling new services. However, supporting many sub-
scribers, frequent mobility, fine-grained measurement and con-
trol, and real-time adaptation introduces scalability challenges
that future SDN architectures should address.
A. Today’s LTE Cellular Data Networks
Long Term Evolution (LTE) cellular networks [1] connect
base stations (eNodeB) to the Internet using IP networking
equipment, as shown in Figure 1. The user equipment (UE)
connects to a base station, which directs traffic through a
serving gateway (S-GW) over a GPRS Tunneling Protocol
(GTP) tunnel. The S-GW serves as a local mobility anchor
that enables seamless communication when the user moves
from one base station to another. The S-GW must handle
frequent changes in a user’s location, and store a large amount
of state since users retain their IP addresses when they move.
The S-GW tunnels traffic to the packet data network gateway
(P-GW). The P-GW enforces quality-of-service policies and
monitors traffic to perform billing. The P-GW also connects
to the Internet and other cellular data networks, and acts as
a firewall that blocks unwanted traffic. The policies at the P-
GW can be very fine-grained, based on whether the user is
roaming, properties of the user equipment, usage caps in the
service contract, parental controls, and so on.
Besides data-plane functionalities, the base stations, serving
gateways, and packet gateways also participate in several
Fig. 1. LTE data plane
control-plane protocols, as illustrated in Figure 2. In coor-
dination with the Mobility Management Entity (MME), they
perform hop-by-hop signaling to handle session setup, tear-
down, and reconfiguration, as well as mobility, e.g., location
update, paging, and handoff. For example, in response to a
UE’s request for dedicated session setup (e.g., for VoIP call),
the P-GW sends QoS and other session information (e.g., the
TCP/IP 5-tuple) to the S-GW. The S-GW in turn forwards the
information to the MME. The MME then asks the base station
to allocate radio resources and establish the connection to the
UE. During handoff of a UE, the source base station sends
the handoff request to the target base station. After receiving
an acknowledgement, the source base station transfers the
UE state (e.g., buffered packets) to the target base station.
The target base station also informs the MME that the UE
has changed cells, and the previous base station to release
resources (e.g., remove the GTP tunnel).
The S-GW and P-GW are also involved in routing, running
protocols such as OSPF. The Policy Control and Charging
Function (PCRF) manages flow-based charging in the P-GW.
The PCRF also provides the QoS authorization (QoS class
identifier and bit rates) that decides how to treat each traffic
flow, based on the user’s subscription profile. QoS policies can
be dynamic, e.g., based on time of day. This must be enforced
at the P-GW. The Home Subscriber Server (HSS) contains
subscription information for each user, such as the QoS profile,
any access restrictions for roaming, and the associated MME.
In times of cell congestion, a base station reduces the max
rate allowed for subscribers according to their profiles, in
coordination with the P-GW.
Today’s cellular network architectures have several major
limitations. Centralizing data-plane functions such as moni-
toring, access control, and quality-of-service functionality at
the packet gateway introduces scalability challenges. This
2
Fig. 2. Simplified LTE network architecture
makes the equipment very expensive (e.g., more than 6 million
dollars for a Cisco packet gateway). Centralizing data-plane
functions at the cellular-Internet boundary forces all traffic
through the P-GW, including traffic between users on the same
cellular network, making it difficult to host popular content
inside the cellular network. In addition, the network equipment
has vendor-specific configuration interfaces, and communicate
through complex control-plane protocols, with a large and
growing number of tunable parameters (e.g., several thousand
parameters for base stations). As such, carriers have (at best)
indirect control over the operation of their networks, with little
ability to create innovative services.
B. SDN for Cellular Data Networks
Cellular data networks are ripe for the introduction of Soft-
ware Defined Networking (SDN), where the network equip-
ment performs basic packet-processing functions at the behest
of applications running on a logically-centralized controller.
In the next section, we discuss how SDN could give cellular
operators greater control over their equipment, simplify net-
work management, and introduce value-added services. SDN
can enable carriers to distribute data-plane rules over multiple,
cheaper network switches, reducing the scalability pressure on
the packet gateway and enabling flexible handling of traffic
that stays within the cellular network.
Supporting real-time updates to many fine-grained packet-
handling rules raises significant scalability challenges. Fre-
quent user mobility can require forwarding state at the level
of individual subscribers, and the state must change quickly to
avoid service disruptions. To detect when subscribers exceed
their usage caps, the switches must perform fine-grain mon-
itoring of traffic volumes. The network must adapt quickly
to the measurement data to adapt QoS policies, or transcode
content to offer good service during times of congestion. To
address these challenges, we propose four main extensions to
controllers, switches, and base stations:
Flexible policies on subscriber attributes: Many controller
applications need to apply policy based on the properties of
cellular subscribers, including the network provider, device
type, subscriber type, and recent usage. The controller should
automatically translate policies based on subscriber attributes
to packet-processing rules based on IP addresses and network
locations.
Scalability through local switch agents: The need for fast
and frequent updates to a large amount of data-plane state
would put tremendous pressure on a central controller. Instead,
switches should run software agents that perform simple local
actions (such as polling traffic counters and comparing against
thresholds), at the behest of the controller.
Flexible switch patterns and actions: Today’s OpenFlow
already supports flexible packet classification and actions. That
said, cellular networks would benefit from support for deep-
packet inspection, header compression, and message-based
control protocols like SCTP [2].
Remote control of virtualized base-station resources:
Virtualizing the base station by time slot and subcarriers can
give different applications, traffic classes, or virtual operators
the illusion of a dedicated base station. An open API between
the controller and base station can enable remote control
of radio resource allocation, admission control, handoff, and
paging.
For prototyping our architecture, we are encouraged by the
availability of the open source LTE base station code provided
by openairinterface.org and the open source LTE packet core
code provided by openepc.net.
II. CONTROLLER APPLICATIONS
In this section, we identify several major challenges in
cellular data networks, and how Software Defined Networking
can enable better solutions.
A. Directing Traffic Through Middleboxes
Cellular network operators offer many fine-grained services
implemented in network appliances, or middleboxes. In a
dynamic environment, cellular providers need to adapt video
quality in real time based on cell tower congestion, device
type, and the subscriber’s service plan [3]. To improve security
for enterprise customers, providers direct traffic through intru-
sion detection and prevention systems. Certain legacy devices
need in-network support for echo cancellation for VoIP calls.
However, today’s cellular carriers do not have fine-grained
control over routing, forcing them to either direct excess traffic
through unnecessary middleboxes or manage an unwieldy set
of tunnels.
SDN provides fine-grained packet classifier and flexible
routing, which can easily direct a chosen subset of traffic
through a set of middleboxes. As a result, middleboxes will
handle much less traffic, making them much cheaper. In addi-
tion, with support for deep-packet inspection, SDN switches
could support some middlebox functionality directly, reducing
the number of extra devices in the network.
B. Monitoring for Network Control & Billing
Due to frequent user mobility, and changing channel condi-
tions, cellular networks are subject to rapid changes in traffic
demands, and frequent signaling messages to migrate connec-
tions. Real-time traffic monitoring is crucial for triggering fast
3
adaptation. This includes load balancing data traffic from base
stations to a different S-GW, and from a different S-GW to a
different P-GW, load balancing control traffic from the base
station and S-GW to a different MME. Real-time monitoring
also enables rapid per-application content adaptation (e.g.,
video conferencing, or streaming from Netflix) to meet per-
subscriber QoS. Existing traffic-monitoring solutions [4] re-
quire additional equipment that captures every packet at every
interface of a S-GW, and provides a summary to a backend
SQL server every few minutes. These measurements provide
no real-time visibility into the eNodeB, S-GW, and MME.
The packet-handling rules in SDN switches include byte
and packet counters. By adjusting these rules over time, the
cellular provider can efficiently monitor traffic at different
levels of granularity to drive real-time control loops on the
SDN controller. In addition, associating packet classifiers
with traffic counters is useful to drive billing decisions and
determine whether a subscriber has reached a usage cap. The
recent interest in allowing content providers to cover usage
charges for mobile users will put even more pressure on
cellular providers to collect fine-grained measurements.
C. Seamless Subscriber Mobility
Cellular networks must respond quickly to subscriber mo-
bility to avoid disruptions in service. Yet, today’s cellular
providers do not have direct control over routing, or common
protocols for controlling forwarding across different cellular
technologies (e.g., 3G, LTE, WiMax, and WiFi). As a result,
handoff across technologies involves complex procedures that
lead to longer delays and higher packet loss rates.
SDN would provide a common control protocol (e.g., Open-
Flow) that works across different cellular technologies, making
mobility management much easier. In addition, rather than
performing hop-by-hop signaling to create a new session, the
controller can push new forwarding rules to multiple switches
at the same time for a lower set-up delay.
D. QoS and Access Control Policies
In today’s networks, the packet gateway is the central point
for fine-grained policy enforcement and charging based on the
subscriber profile, application, and usage. The P-GW classifies
packets based on the 5-tuple of the TCP/IP header and either
drops packets (if they violate a firewall policy) or map them
into QoS classes. These QoS classes further map into the
Diff-Serve Code Points (DSCP) when the packets traverses
IP networks en route to the base station. At the base station,
only simple policies such as a maximum rate are enforced.
This leads to scalability problems at the P-GW, and missed
opportunities to optimize the use of bandwidth inside the
cellular network.
SDN would enable the distributed enforcement of QoS and
firewall policies based on a network-wide view. Distributed
enforcement is especially important for handling any traffic
that stays within the cellular network. A controller application
running on the controller can spread access-control rules over
multiple switches, and manage the scheduling of traffic by
QoS classes across multiple hops in the network.
E. Virtual Cellular Operators
Today’s cellular networks have relatively limited support
for virtualization. LTE can isolate different enterprise cus-
tomers’ traffic into virtual private networks using traditional
BGP/MPLS VPN technologies. However, LTE does not allow
different carriers to share the infrastructure to offer a complete
virtual LTE network to their customers. Virtual operators
may want to innovate in mobility management, policy, and
charging, without investing the substantial resources necessary
to build and manage a wireless network. For example, content
providers like Akamai could leverage a virtual infrastructure
to better deliver content to mobile users.
Virtualization would also be useful to provide isolation and
separate control for different classes of traffic. For example, a
carrier may want to carry traffic for roaming subscribers on a
different virtual network from its own customers, for security
reasons.
SDN makes it relatively easy to support network virtu-
alization by partitioning the “flow space” of packet head-
ers. Different controller applications can manage rules acting
on each portion of flow space, enabling customized control
while ensuring isolation [5]. Virtualizing the cellular network
requires virtualizing the base stations [6], [7], by slicing
resources at the physical layer (physical channels), link layer
(scheduling), or network layer (traffic shaping).
F. Inter-Cell Interference Management
In LTE, every base station can use all subcarriers. However,
base stations need to coordinate their subcarrier allocations to
avoid harmful interference among users. Currently, inter-cell
interference management is done in a distributed fashion. A
base station tells its neighboring base stations if it needs to
use a higher power to transmit to a UE using a subset of
subcarriers. Alternatively, upon perceiving high interference on
certain subcarriers, the base station can notify its neighboring
base stations to lower their transmission power. Inter-cell
interference management algorithm is related to graph coloring
algorithm. Due to the lack of a global view, distributed graph
coloring algorithms with a limited number of rounds are highly
suboptimal [8].
SDN enables centralized control of base stations. A SDN
controller will have a global view of the current power and
subcarrier allocation profile of base stations. In addition, a
SDN controller running on a commodity server would have
much more computing resources than most base stations. As
a result, a SDN controller can make a more efficient allocation
of radio resources to handle new users.
III. CELLULAR SDN ARCHITECTURE
Cellular networks need an SDN architecture that offers fine-
grain, real-time control without sacrificing scalability. Working
our way down from the controller platforms to the base
stations, we propose four main extensions to enable SDN
in cellular networks. The cellular SDN architecture is shown
in Figure 3. First, controller applications should be able to
express policy in terms of subscriber attributes, rather than
IP addresses or physical locations, as captured in a subscriber
4
information base. Second, to improve control-plane scalability,
each switch should run a local control agent that performs
simple actions (such as polling traffic counters and comparing
against a threshold), at the behest of the controller. Third,
switches should support more flexible data-plane functional-
ity, such as deep packet inspection and header compression.
Fourth, base stations should support remote control of virtu-
alized wireless resources to enable flexible cell management.
Fig. 3. Cellular SDN architecture
A. Controller: Policies on Subscriber Attributes
The SDN controller consists of a Network Operating System
(NOS) running a collection of application modules, such
as radio resource management, mobility management, and
routing. The handling of individual packets often depends on
multiple modules. For example, the flow of traffic through
the network depends on the subscriber’s location (determined
by the mobility manager) and the paths between pairs of
network elements (determined by infrastructure routing), and
traffic monitoring and packet scheduling depend on the policy
and charging rule function. As such, the NOS should support
composition to combine the results of multiple modules into
a single set of packet-handling rules in each switch [9].
Many of the controller application modules need to apply
policy based on the properties of cellular subscribers, including
the cellular network provider (e.g., whether the user is roaming
or not), device type (e.g., whether the user has a legacy phone
that requires echo cancellation), subscriber type (e.g., usage
cap, parental controls, etc.), and recent usage (e.g., whether the
user is near exceeding the usage cap). Yet, the switches match
packets and perform actions based on packet header fields,
based on ephemeral identifiers such as a subscriber’s current
IP address and location. To bridge the gap, the controller can
maintain a Subscriber Information Base (SIB) that stores and
maintains subscriber information, including relatively static
subscriber attributes as well as dynamic data like the user’s
current IP address, location, and total traffic consumption.
The NOS can translate policies expressed in terms of
subscriber attributes into switch rules that match on packet
headers. Similarly, the NOS can translate network measure-
ments (such as traffic counters) to the appropriate (sets of)
subscribers, to allow the application modules to focus on
subscribers and their attributes rather than ephemeral network
identifiers
1
. The controller can also dynamically divide the
network into “slices” that handle all traffic matching some
predicate on the subscriber attributes. This allows the cellular
provider to isolate roaming traffic, isolate dumb phone traffic
or phone traffic using legacy protocols. To enable scalable
slicing of semantic space, the controller can instruct ingress
switches to mark incoming packets (e.g., using an MPLS label
or VLAN tag) sent to or from subscribers with particular
attributes.
B. Switch Software: Local Control Agents
Cellular data networks face significant scalability chal-
lenges, in terms of the number of subscribers, frequent changes
in user location, fine-grain access-control and quality-of-
service policies, and real-time adaptation to network condi-
tions. For example, the switches may need to direct a video
stream through a transcoding proxy if the network becomes
congested, or give certain traffic lower priority if the user
exceeds his usage cap. These measurement and control func-
tions could easily overwhelm a logically-centralized controller.
In addition, the controller may not be able to respond as
quickly to local events as the underlying switches themselves.
This argues for having some control-plane functionality on the
underlying switches, though arguably not the same complex
software that runs on the switches in today’s cellular networks.
In particular, each switch can run an agent that performs
simple local actions, under the command of the controller.
For example, the controller could offload simple measurement
tasks to the local agents, such as periodically polling the traffic
counters and notifying the controller if a counter exceeds a
threshold. The local agent could also perform simple control
operations, such as automatically changing the weight or
priority of a queue when traffic counts exceed a threshold,
or pushing a tag on a packet to direct the traffic through
an intermediate middlebox. Performing these operations on
the local agents would reduce the load on the controller, and
enable faster responses to critical events.
Supporting local agents on the switches raises many inter-
esting research problems. Partitioning functionality between
the controller and the agents requires ways for application
modules to expose the inherent parallelism across agents and
the necessary aggregation of information at the controller. In
addition, the partitioning of functionality must work in the
presence of multiple modules that form a single application.
Network updates must be kept consistent amid the partitioning
of functionality and user equipment mobility. We plan to
explore the design of the local agent and techniques for
partitioning functionality in our future work.
1
This is similar to the way Ethane [10] supports access-control policies
based on named principals, rather than IP addresses and network locations,
though cellular networks must support a much wider range of attributes and
control actions.
5
C. Switch Hardware: Flexible Packet Processing
Today’s OpenFlow [11] switches already support many fea-
tures needed in cellular networks. Flexible packet classification
based on Ethernet, IP, and TCP and UDP header fields enables
fine-grain quality-of-service, access control, and monitoring.
The forwarding actions in today’s OpenFlow switches would
enable carriers to direct selective traffic through middleboxes,
change the paths to and from a mobile user, and mark and
schedule traffic according to QoS policies. The byte and
packet counters associated with each rule would support traffic
measurement, real-time adaptation based on congestion or
exceeding a subscriber’s usage cap, and usage-based billing.
Still, these switches may need larger rule tables, or more
stages of tables, than today’s commodity switches to efficiently
support fine-grained policies.
That said, software-defined cellular networks would benefit
from new switch capabilities. TCP/UDP port numbers are
no longer a sufficiently reliable way to identify applications.
Instead, support for deep packet inspection (DPI) would enable
finer-grain classification based on the application, such as
Web, peer-to-peer, video, and VoIP traffic. This is important to
divide traffic into separate traffic classes for different packet-
scheduling and routing policies, as commonly done in today’s
cellular networks [12]. DPI would also help support intrusion
detection and prevention systems that analyze packet contents
to identify malicious traffic.
To support DPI, the OpenFlow protocol must be extended to
add and remove rules where the pattern is a regular expression.
To avoid having the DPI module inspect every packet, SDN
controller can jointly manage the flow table and the DPI rule
table. For example, the switch could first match a packet with
a flow-table rule, which includes a flag indicating whether
the packet should proceed directly to the output port(s) or go
through the DPI table. To contain cost, we do not envision that
every switch would support DPI. Instead, the controller must
place packet-classification rules in the appropriate locations in
the underlying network.
In addition to DPI, switches could also support techniques
like header compression and decompression to reduce the
overhead for applications with small packet payloads. For
example, VoIP packets are typically small, making the headers
a relatively high fraction of the traffic. Compressing these
packets before transmission on low-bandwidth links substan-
tially lowers the overhead. VoIP packet sizes range from 20 to
150 bytes, and the combined overhead of the RTP, UDP, and
IP headers is 40 bytes. Robust header compression (ROHC)
reduces the 40-byte overhead to 1 byte. As with DPI, this
functionality may not be available on every switch, but instead
mainly on switches with links to and from low-bandwidth
regions of the network.
D. Base Station: Remote Control and Virtualization
Remote control: In LTE, base stations participate in dis-
tributed control protocols to manage radio resource allocation,
session setup/reconfiguration/teardown, handoff, and paging.
Radio resources are inherently shared among base stations.
The lack of central control makes it difficult to optimize tasks
related to radio access. We decouple the control plane from the
radio hardware. We envision that that the SDN radio hardware
exposes a well-defined API which can be controlled by the
control plane. Running Radio Resource Management Module
(RRM) on top of a logically-centralized controller makes it
much easier to innovate in admission control, radio resource
allocation, and interference management. For example, the
RRM can redirect a UE to a nearby lightly loaded base
station or increase the transmission power of a congested
base station. If the base station has multiple antennas, the
control plane can decide whether the antennas should be used
for boosting signals (combining diversity to boost signals
for delay-sensitive applications) or for spatial multiplexing
(multiple parallel transmissions). Although 3G base stations
are controlled by a central entity, the radio network controller
(RNC) couples control-plane and data-plane functionality,
including fine-grained tasks like packet scheduling. In contrast,
the RRM module should only perform control-plane functions,
and instruct the base station to perform any data-plane opera-
tions.
Virtualization: Today’s SDN virtualization solutions like
FlowVisor [5] can share a single switch data plane among mul-
tiple virtual networks. Much as a hypervisor resides between
software and hardware on a PC, FlowVisor uses OpenFlow as
a hardware abstraction layer to sit logically between control
and forwarding paths on a network device. FlowVisor is
transparent to both the network hardware and the controller
managing the virtual networks. FlowVisor defines a slice
as a set of flows running on a topology of switches. The
virtualization layer enforces strong isolation between slices.
Resources that can be sliced are bandwidth, topology, traffic,
device CPU, and forwarding tables.
Technologies like FlowVisor can be extended to slice base
station resources, e.g., to create virtual base stations. A virtual
base station’s resource can be a combination of time slots, sub-
carriers, and power. For example, a virtual base station can be
allocated a subset of time slots, and transmission in each time
slot can use maximum transmission power allowed or a subset
of subcarriers across all time slots and transmission in each
time slot uses a fraction of the maximum transmission power.
A slice can ask for base stations with a specific MAC protocol.
To support base station virtualization, without modifying the
physical-layer protocols, the controller can convey high-level
information like the identity of the virtual provider through the
control plane. This would allow the UE software to display
the virtual provider (rather than the physically broadcasted
provider information) without requiring explicit broadcasting
of the provider information and cell ID.
IV. RELATED WORK
Our work is heavily inspired and follows the high-level
vision of OpenRoads (OpenFlow wireless) [7], which is a
platform for innovation and realistic deployment of services
for wireless networks. OpenRoads is the first software-defined
wireless network. It is mainly based on WiFi and offers no
special support for cellular networks. In contrast, our work
addresses specific cellular network requirements such as real-
time session management which runs on top of SCTP instead
