FERRET: Fall-back to LTE Microservices for Low Latency Data Access

Muhammad Taqi Raza

University of Arizona

Fatima Muhammad Anwar

UMASS Amherst

Dongho Kim

AT&T Research Lab

Kyu-Han Kim

HP Enterprise Research Lab

ABSTRACT

Motivated from Software Deﬁned Networking (SDN),

LTE standard body (3GPP) has recently proposed split-

ting monolithic LTE Network Functions (NFs) into their

control-plane and data-plane modules for better perfor-

mance, ﬂexibility and agility. The data-plane logic

is pushed at the edge of the network, while retaining

control-plane functionality at the core. However, both

network edge and the core modules involve in execut-

ing LTE control-plane procedures (e.g. device registra-

tion/deregistration, and mobility etc.) as well as LTE data-

plane services (e.g. voice over LTE, and video stream-

ing, etc.). We discover that these decoupled modules, be-

ing part of the same LTE network function, interact fre-

quently and cause deadlocks and races. In this paper, we

argue that SDN style approach may not work for LTE

NFs due to their monolithic design. We reason to retain

LTE legacy design by not splitting its NFs. Our idea is

to keep all types of LTE control-plane procedures han-

dling at the core; while moving the execution of LTE data-

plane services to the edge as microservices. We propose

F ERRET that is inspired from the success of the Cir-

cuit Switch Fall Back (CSFB) procedure, and falls-back

to speciﬁc LTE microservice for the user requesting a par-

ticular LTE service. It ﬁrst records signaling messages

exchange as part of LTE service establishment phase at

the core and then replays these messages at dedicated mi-

croservice to enable that service handling. F ERRET

lets microservice to facilitate LTE service execution that

provides data forwarding at the edge.

1 Introduction

In Fourth Generation (4G) LTE network, packet process-

ing Network Functions (NFs) are implemented at the

backend of cellular network. These NFs being far away

from radio base station introduce latencies for both con-

trol and user planes (also referred as data-planes in the

paper) packets at both uplink and downlink directions.

All packets originated from the source ﬁrst traverse cel-

lular backend NFs before they are forwarded to the des-

tination. Such a cellular design choice was made to op-

timize backend NFs processing and management where

all these NFs are implemented over carrier grade boxes

that provide strong coupling between software and hard-

ware implementation [1]. Recently, Network Function

Virtualization (NFV) concept has emerged that breaks the

software dependency on underlying hardware. Although,

NFV idea was envisioned to reduce operators capital and

operation expenditures by implementing network packet

processing logic on commodity off-the-shelf boxes, it also

provides an opportunity to redesign cellular architecture.

The idea of redesigning LTE architecture is well received

by Fifth Generation Network (5G) project whose aim is

to reduce end-to-end latencies and increase throughput.

5G introduces Mobile Edge Computing (MEC) paradigm

in cellular space by bringing user-plane trafﬁc processing

and forwarding modules closer to mobile edge, whereas

keeping the control-plane operational modules at the core.

In this direction, LTE standardization body (3GPP), in-

spiring from software deﬁned networking (SDN) con-

cept, has recently proposed mechanisms to split control

and user planes NFs logic [2]. The user-plane functional

modules are brought together and implemented at the

edge (as shown in Figure 1). They communicate with

control-plane functional modules, which are implemented

at the backend, through newly introduced network inter-

faces by 3GPP [2]. In our preliminary study, we ﬁnd

that SDN like distributed implementation of these decom-

posed functional modules cause deadlock and introduce

race-conditions. We show these two issues happening in

LTE Tracking Area Update (TAU) procedure.

Deadlock condition arises when both control-plane and

user-plane functional modules of same NF lock their

respective local resources and want to acquire a lock

on each others locked local resource to complete their

task. To take an example, when TAU procedure starts,

user-plane trafﬁc path and charging rules are modiﬁed at

Charging Function’s control-plane module. These modiﬁ-

cations are required to be reﬂected at Charging Function’s

user-plane module. Assume, Charging Function’s user-

plane module has already processing changes required

by relocation of some other NF, and wants to update its

changes to Charging Function’s control-plane module as

well. As a result both Charging Function’s user-plane and

control-plane modules wait on each other to update their

changes.

Race condition occurs, when control-plane signaling mes-

sage arriving from two different NFs have timing con-

straint. The outcome depends in the arriving order of

signaling message from two different NFs. For exam-

ple, during TAU procedure, it is determined that user

has moved to a different location and its gateway NF

needs to be relocated. As a result, mobility management

NF sends relocation request message to that gateway’s

control-plane module. However, this relocation request

message has a race condition with another relocation re-

quest message coming from gateway’s user-plane module

that has reached its serving capacity. The order of these

signaling messages result into two different behavior. The

latest relocation request message will override changes

made by the former one, and results into anomalous be-

havior.

In this paper, we argue against SDN like approach that

splits LTE NFs into their control-plane and user-plane

operations. Instead, we are in favor of retaining legacy

LTE monolithic design for MEC implementation. Our

idea is to process LTE control-plane procedures (such as

registration/de-registration, mobility, and location update

etc.) at the core; while moving the execution of LTE

services (such as voice over LTE (VoLTE), multimedia,

streaming, web, and gaming etc.) to the edge. It means

user-plane trafﬁc bypasses LTE core and directly gets for-

warded to the Internet. This ultimately reduces the end-

to-end user-plane latencies. We propose of creating a

number of microservices where each microservice is tai-

lored to handle a speciﬁc LTE service. Such as VoLTE-

microservice and web-microservice handle VoLTE and

web data trafﬁc, respectively. To efﬁciently coordinate

between LTE core and microservice, we propose our de-

sign F ERRET . It is inspired from the concept of Cir-

cuit Switch Fallback (CSFB) in which LTE falls-back to

legacy radio network (such as 3G/2G) for circuit switch

voice call. Similarly, F ERRET falls back to speciﬁc mi-

croservice to facilitate particular user data service. When

the subscriber requests a particular LTE service, the ser-

vice is ﬁrst established at the core. F ERRET records

complete signaling messages (such as bearer setup, ﬁlter-

ing rule, etc.) execution information during service estab-

lishment phase as ﬁrst-in ﬁrst-out (FIFO) order queue. It

then re-establishes LTE service at edge microservice by

replaying the recorded messages. The edge microservice

reconﬁgures its interfaces with LTE base station and de-

vice and starts forwarding uplink and downlink data traf-

ﬁc. We prototype F ERRET over OpenEPC and con-

sider VoLTE application. F ERRET reduces voice traf-

ﬁc latency upto 10X by introducing one-time delay of 0.5

second.

2 Background

LTE network consists of three main components, which

are LTE device, LTE base-station, and Evolved Packet

Core (EPC). LTE base-station anchors as a radio inter-

face between device and EPC. EPC communicates with

packet data networks in the outside world such as the In-

ternet and facilitates user communication. LTE EPC com-

prises over a number of LTE NFs, that include Mobility

Management Entity (MME), Serving Gateway (SGW),

Edge

Backend

User-Plane

Control-Plane

Device

LTE base

station

PGW–C

PCRF–C

SGW–C

SGW–U

PCRF–U

PGW–U

MME

Internet

Figure 1: LTE MEC overview: User-plane functionalities (i.e. PGW-U,

PCRF-U and SGW-U functional modules) of LTE core network are imple-

mented at the edge (closer to the user); whereas, control-plane (i.e. PGW-C,

PCRF-C and SGW-C functional modules) of LTE core network still resides

at the back-end.

Packet Data Network Gateway (PGW), Policy and Charg-

ing Rules Function (PCRF), and few others. These NFs

handle control-plane and user-plane trafﬁc through sep-

arate network interfaces. Up till now, LTE NFs are im-

plemented over carrier grade boxes which provide strong

coupling between software and hardware as well as strong

association between different NFs. Such contemporary

LTE implementation brings user-plane latencies in which

data packets need to traverse backend of LTE infrastruc-

ture before they reach to device. Recently, LTE NFV con-

cept emerges that breaks software dependency on vendor

speciﬁc platforms and paves the way to reduce user-plane

latency at LTE network through MEC. In MEC, LTE NFs

are ﬁrst split into control-plane and user-plane functional

modules and then user-plane modules are implemented

closer to device, i.e. at mobile edge, as shown in Figure

1. Figure 1 shows PDN, SGW and PCRF NFs are split

between their control and user planes functional modules.

User-plane modules are moved at mobile edge, whereas

control-plane operational modules still reside at the back-

end.

Tracking Area Update Procedure The network keeps

track of device location by mapping it to a particular loca-

tion area (known as tracking area in LTE). Once the user

moves from one tracking area to the other, it must inform

MME for its new tracking area. Figure 2 explains TAU

procedure which is initiated by a device where it sends

tracking area update request message to LTE base station

(step 1). LTE base station then forwards this requests to

MME (step 2). Before processing TAU request message,

MME authenticates the device (step 3). Once the device

is authenticated, MME informs SGW about user location

change and asks SGW to modify its bearer with device

(step 4). SGW modiﬁes device bearer and forwards the

modify bearer request to PGW (step 5). PGW modiﬁes

device session at PCRF (step 6) and sends modify bearer

response back to SGW (step 7). SGW informs successful

bearer modiﬁcations to MME by sending modify bearer

response message (step 8). Once bearers are modiﬁed at

SGW and PGW, MME commits device new location at

LTE network’s database (known as Home Service Sub-

scriber (HSS)) (step 9). Thereafter, MME conﬁrms suc-

cessful execution of tracking area update procedure at net-

work by sending tracking area update accept message to

device (step 10). The device then acknowledges the mes-

sage by sending tracking area update complete message.

Device

LTE Base Station

MME SGW PGW

PCRF

1. TAU

Request

2. TAU

Request

3. Authentication and

Security

4. Modify Bearer

Request

5. Modify Bearer

Request

6. Session

Modification

7. Modify Bearer

Response

8. Modify Bearer

Response

9. Location Update

HSS

10. Tracking Area Accept

11. Tracking Area Complete

Figure 2: TAU procedure kicks-in when device

moves from one tracking area (location) to an

other. The LTE network updates device’s new

location in its database so that device remains

reachable even during device idle periods.

Design Considerations: Share Common Functions between CP and UP

1. Tracking Area Update Request

4. Overload Signal

2. Modify

Bearer Request

3. Session

Modification

5. Modify Bearer Request

6. Session

Modification

Device PGW-U PCRF-U PGW-C PCRF-CMME

8. Reflect update to PCRF-C

7. Reflect update to PCRF-U

Use blocking mode operations

MEC Design

Lock

Deadlock

Lock

Figure 3: Deadlock happens when PCRF-C and

PCRF-U have locked their respective processes

and want to reﬂect their update by requesting lock

on each other’s locked processes.

Design Considerations: Share Common Functions between CP and UP

MMEDevice SGW-U

3. Relocation Request

SGW-C

1. Tracking Area Update Procedure

3A. Relocation Request

Race

Condition

MEC Design

Let UP manage its own resources based on

policy provided by CP

2. Overload

Figure 4: Race condition happens when SGW-

C receives relocation request signaling message

from MME and SGW-U at the same time.

3 Issues Arising from LTE Functional Split

We use TAU procedure to discuss that implementation

complying LTE standard can cause deadlock and races

when its NFs are split between control and user planes

functional modules.

3.1 Deadlock

Figure 3 shows potential deadlock scenario in TAU pro-

cedure. TAU request being a control-plane procedure ﬁrst

arrives at MME (step 1). MME triggers TAU procedure

by sending modify bearer request to PGW-C (via SGW-

C) that forwards it to PCRF-C (steps 2 and 3). PCRF-C

locks the process handling session modiﬁcation request

and makes changes into Trafﬁc Handling Rules (THR)

that control how the user-plane treats a certain piece of

trafﬁc. The THR contains packet ﬂow description (IP ﬁl-

ters, Application ID) as well as parameters that describe

how that trafﬁc matching the packet ﬂow descriptor shall

be treated. The PCRF-C also generates triggering con-

ditions and thresholds based on which PCRF-U reports

trafﬁc usage information. Before such information is

passed-on to PCRF-U, MME receives an overload sig-

nal from PGW-U(step 4). This overload signal informs

MME that PGW-U is about to reach its capacity so load

balancing is required. MME being a central entity, pre-

pares new PGW-U resource and asks current PGW-U to

switch to newly prepared PGW-U instance by sending

modify bearer request message (step 5). PGW-U gen-

erates session modiﬁcation message towards PCRF-U so

that PCRF-U should account trafﬁc coming from/to new

PGW-U instance (step 6). On receiving session modiﬁ-

cation message, PCRF-U locks its process and session

level reporting entries per PDN connection and applies

THR rules. PCRF-U is required to update such changes

to its distributed control-plane counterpart (PCRF-C) to

complete session modiﬁcation request. At this point, both

PCRF-C and PCRF-U are required to reﬂect the changes

they made to each other (steps 7 and 8). To achieve this,

they seek a lock on session modiﬁcation process at dis-

tributed instance, while locally holding a lock on the same

process. This creates a deadlock scenario in which both

PCRF-U and PCRF-C keep waiting on each other, result-

ing not only TAU procedure failure but also making any

user trafﬁc unaccountable at PCRF-U.

3.2 Race Condition

Figure 4 shows potential race-condition scenario. The

TAU procedure is initiated by device when it moves

to a new location which is served by a different LTE

base-station and SGW. During TAU procedure execution,

MME determines that the user has moved to an area

served by a different SGW and the old SGW cannot con-

tinue to serve the user. MME decides to relocate the SGW

by sending relocation request message to SGW-C (step

3). Note that, during TAU procedure, the MME may also

decide to relocate the SGW if a new SGW is expected

to serve the UE longer and/or with a more optimal UE

to PGW path, or if a new SGW can be co-located with

the PGW. Meanwhile (while TAU procedure is on-going),

SGW-U ﬁnds itself overloaded and requires new instance

of SGW-U to be initiated. SGW-U does so by sending re-

location request message to SGW-C (step 3A) and SGW-

C prepares new SGW-U instance. However relocation

request message sent by MME and SGW-U have race-

condition in which the changes requested by earlier NF

(MME or SGW-U) are lost and causes anomalous behav-

ior.

4 Our Position

Caution over LTE functional split We argue that LTE

architecture which is monolithic by design should not

be split into its control-plane and data-plane operations.

LTE NFs are logically separated where they facilitate each

other in executing certain tasks. One such NF is PCRF

that takes subscribers charging rules and policy informa-

tion from MME and HSS NFs, and applies these rules

at uplink and downlink data trafﬁc by communicating

with SGW and PGW NFs. Other NFs, although, can be

split into their control and data planes functional mod-

ules, they may cause deadlocks and races (as discussed in

Section 3). Therefore, we call for caution over LTE func-

tional split and argue that LTE monolithic design should

be steered to achieve desired goals.

Fall-back as microservice To achieve our goal of re-

ducing LTE data-plane latencies, we do not call for radical

changes into LTE architectures. Rather, our position is let

all types of LTE control-plane procedures (such as regis-

tration, deregistration, mobility, and location update etc.)

be executed at the core, and only LTE services (such as

voice, data, multimedia, and gaming etc.) execution logic

is moved at the edge that reduces data-plane latencies. To

achieve this, a number of dedicated microservices should

be created to execute individual LTE services. For exam-

ple, VoLTE-microservice and web-microservice should

only handle voice calls and web services access, respec-

tively.

5 Ferret Design

Design overview We propose F ERRET that provides

fall-back to particular microservice instance in case of

LTE service access. First, it captures all signaling mes-

sages in FIFO order as they execute for establishing LTE

service at the core. Once the LTE service connection has

been established at EPC, F ERRET replays these mes-

sages at dedicated microservice for execution. Figure 5

shows that F ER RET captures messages (M

and M

)

as they execute between different NFs (NF

and NF

). Fi-

nally, it replays these messages at the edge. The microser-

vice NFs receive messages in-order and execute them ac-

cordingly. They also reconﬁgure their interfaces with LTE

base station and device to assume the role of legacy EPC.

Once LTE service connection falls back to microservice,

the data-plane trafﬁc can start. Now the data-plane pack-

ets are directly forwarded to the Internet from edge mir-

corservice without going to legacy EPC.

We next explain F ERRET design in detail.

Backend

NF1 NF2

NF1

NF2

Edge

IMS Application over MEC

Figure 5: FERRET design overview

Capturing signaling messages LTE NFs always ex-

change a number of signaling messages for every LTE

service request. For example, for VoLTE service request

from device, MME authenticates and authorizes the de-

vice, SGW and PGW establish dedicated voice bearer,

PCRF enables charging rule, and IP Multimedia Subsys-

tem (IMS) ﬁnally establishes the call. The call estab-

lishment procedure also involves signaling messages ex-

change between a number of IMS NFs (such as P-CSCF,

S-CSCF and Media Gateway). F ERRET deploys a

F ERRET agent at every NF that records complete mes-

sage execution information. Such information include,

the message name, message type, input and output pa-

rameters, number of state transitions, and name of two

NFs among which the message is exchanged. These mes-

sages are placed in the queue (to be later replayed at the

edge NFs) in exactly same order as they are executed at

ﬁrst place. F ERRET can achieve this by exploiting se-

quential execution of LTE messages, and POSIX message

queues implementation. LTE standard requires sequential

execution of LTE signaling messages, where the follow-

ing message shall not execute until former message is suc-

cessfully executed. To ensure this, LTE standard explic-

itly enables sequence number ﬁeld in different messages

(such as NAS sequence number indicating the sequential

number of the NAS protocol message) [3]. As a result,

F ERRET can safely assume that all LTE messages ar-

rive in-order. To ensure different F ERRET agents do

not interleave, it adopts POSIX message queues imple-

mentation approach. POSIX message queues allow for an

efﬁcient, priority-driven mechanism with multiple readers

and writers. Whenever a F ERRET agent sends a mes-

sage to a queue, a priority (ﬁrst-in ﬁrst-out) is speciﬁed

for that message. The queue remains sorted such that the

oldest message will always be at the front.

Replaying signaling messages at edge Once

F ERRET constructs signaling messages queue, it next

forwards these messages to particular LTE microservice

located at the edge. The edge microservice then executes

these signaling messages and re-establishes the service.

We explain this procedure through VoLTE call example.

Once VoLTE call has been established at the core,

F ERRET requests IMS to place call on hold (by send-

ing call

hold signal to IMS) while it is replaying recorded

control-plane messages at edge. F ERRET knows all

signaling messages are queued as ﬁrst-in ﬁrst-our order,

where it dequeues the front most message and sends it to

particular edge NF. The edge NF executes the message,

compare its produced output parameters with that of it

has received from F ERRET and forwards it to next NF

(if it needs to). For example, during VoLTE call setup the

ﬁrst two messages are create session request (M

) from

SGW → PGW, and create session response (M

) from

PGW → SGW. Both these messages are responsible for

establishing VoLTE dedicated bearer. F ERRET sends

and M

to SGW

edg e

and PGW

edg e

, respectively. The

SGW

edg e

forwards M

to PGW

edg e

that executes the

message. PGW

edg e

then ensures that it has generated

same output parameters as provided by F ERRET in

. These include, voice PDN IP address, transport

layer address, protocol ID, and quality of service class. It

should be noted that the exact parameter values (such as

value of IP address parameter) may differ from the ones

received in M

Reconﬁguring interfaces The LTE service session

which has already been setup between EPC, LTE base

station, and device needs to be updated with respect to

edge NFs. This is achieved by reconﬁguring EPC in-

terfaces with base station and device. The edge NFs

(MME

edg e

and SGW

edg e

) reconﬁgure their interfaces

with base station as soon as they receive ﬁrst message

from F ERRET . These NFs ask the base station to up-

date its interfaces towards MME and SGW by sending

S1 Application Protocol (S1-AP) request message. This

message indicates that the subscriber uplink and downlink

packets should be sent to new MME and SGW addresses.

Moreover, edge microservice asks device to update its

connection from EPC to micrservice. This is taken

Messages in Queue

Dequeue

ACK-Received Enqueue

M1M2M3M4

M2M3M4

M3M4

M1 - -

- ACK

M2 - -

- ACK

M3 - -

- Timeout -

- - M3

M4M3

M3 - -

- ACK

M4 -

- ACK

LIFO

(a) Transition between FIFO and

LIFO

Messages in Queue

Dequeue

ACK-Received

Enqueue

M1M2M3M4

M2M3M4

M3M4

M1 - -

- ACK

M2 - -

- ACK

M3 - -

- Timeout -

- - M3

M4M3

M3 - -

- ACK

M4 -

- ACK

LIFO

1. FIFO_Dequeu ()

2. if (message is never dequed)

3. message = Deque_message_FIFO ( Queue )

4. sendto_edgeNF (message)

5. wait_for_ACK () /*ACK or timeout*/

6. if (message is ACKed)

7. goto ( FIFO_Deque() )

8. else

9. Enqueu (message)

10. goto ( LIFO_Deque() )

11. LIFO_Dequeu ()

12. message = Deque_message_LIFO ( Queue )

13. sendto_edgeNF (message)

14. wait_for_ACK () /*ACK or timeout*/

15. if (message is ACKed)

16. goto ( FIFO_Deque() )

17. else

18. Enqueu (message)

19. goto ( LIFO_Deque() )

(b) FIFO and LIFO transition

algo

Figure 6: All queued messages are sent to respective edge NFs as ﬁrst-in ﬁrst-

out. Those messages which are not ACKed are enqueued again. F ERRET

dequeues unacked message(s) as last-in ﬁrst-out and re-sends them to respec-

tive edge NF. The Figure has been discussed in Discussion section (after con-

clusion)

care while edge NFs are executing the messages as re-

ceived from F ERRET . We make changes in the pro-

tocol implementation of the edge NFs where instead

of sending create-dedicated-bearer-request message (as

requested by F ERRET ), we send modify-dedicated-

bearer-request message to device (via MME). This mes-

sage asks the device to modify its dedicated bearer’s IP

address and access point network address. Thereafter, the

device is ready to carry out its data-plane communication

through edge mircoservice.

6 Prototyping and Evaluation

Implementation Our system implementation consists of

OpenEPC [4] LTE implementation and virtualization of

LTE EPC NFs. Our EPC network consists of MME, HSS,

PCRF for control plane and SGW and PGW for data plane

functions. In addition, the Internet gateway provides con-

nectivity to the Internet. We virtualize EPC NFs over

vMware vSphere, which is a server virtualization plat-

form with consistent management. We ﬁrst decompose

OpenEPC into a number of LTE NFs (i.e. MME, SGW,

PGW, HSS, and PCRF). Then we treat these NFs as VNFs

running as separate VMs. We implement virtualized in-

terfaces in order to relay packets to and from these VNFs.

IMS as microservice We consider IP Multimedia Sub-

system (IMS) as a microservice and supports VoLTE call.

For IMS implementation, we use OpenIMS that provides

basic implementation of IMS NFs (such as S-CSCF and

P-CSCF). We deploy these IMS NFs (S-CSCF and P-

CSCF) and LTE NFs (SGW, PGW and PCRF) as IMS

microservice.

Preliminary results

We provide VoLTE service control-pane and data-

plane latencies CDF. Figure 7a provides call setup delay

(control-plane) results for proposed Mobile Edge Com-

pute (MEC) design and baseline (without MEC). We

can see that our proposed MEC design takes on average

500ms more compared to baseline design. The reason

MEC incurs higher latency is that F ERRET is required

to replay all signaling messages (that were executed at the

core) again at the edge. Because baseline does not require

0.2

0.4

0.6

0.8

1030 1180 1330 1480 1630

CDF

Latency (ms)

Baseline

MEC

(a) Control plane latencies

0.2

0.4

0.6

0.8

10 40 70 100 130 160

CDF

Latency (ms)

Baseline

MEC

(b) Data plane latencies

Figure 7: (a) VoLTE call setup, and (b) voice packets delay: The base-

line (legacy without edge mircorservice) incurs less voice call setup signaling

(control-plane) latencies. In mobile edge compute (MEC) design, FERRET

needs to replay recorded packets and reconﬁgure interfaces and takes roughly

500 miliseconds more. The real gain in MEC comes in reduction of VoLTE

speech packets (data-plane) delay, where they are forwarded directly from the

edge – reducing latency upto 10X compared to baseline.

any extra overhead, therefore it incurs lower latency. The

real beneﬁt of our MEC design comes in terms of user-

plane trafﬁc. Figure 7b shows that MEC incurs lower la-

tency compared to baseline design for user plane trafﬁc.

In case of MEC, user-plane trafﬁc is directly forwarded to

the Internet without going to EPC; this reduces latency an

order of 10 times.

7 Related Work

Closest to our work are Rethinking LTE NFV [5], ACA-

CIA [6], DPCM [7], LTE-Xtend [8], Contain-ed [9],

OpenNF [10], and Scaling LTE control plane [11]. Re-

thinking LTE NFV work [5] argues in favor of logic based

decomposition of LTE NFs instead of their instance based

decomposition. The logical modules are implemented as

Fat-Proxy and reduces LTE critical procedures, such as

handover, service access, and paging. Our work does

not consider modifying LTE procedures execution. ACA-

CIA [6] proposes a framework that enables interactive ap-

plications on edge clouds of mobile networks. It leverages

SDN/NFV principles with LTE/EPC QoS mechanisms to

steer interactive application trafﬁc to closely located mo-

bile edge clouds. It also splits LTE NFs (as shown in Fig-

ure 5 [6]) to develop MEC. Contrary to ACACIA, we ar-

gue against SDN based approach for mobile edge comput-

ing and do not split NFs. DPCM [7] proposes low latency

LTE data access approach for service request, handover

and roaming scenarios. However, we do not try to reduce

latencies for LTE control-plane signaling, rather focus on

LTE services. Contain-ed [9] splits LTE user and control

plane and implements user plane functions at the edge.

However, it fails to point out any issue that may emerge

from SDN style functional split.

8 Conclusion

This paper calls for caution over LTE functional separa-

tion in next generation LTE network. It argues that SDN

approach for splitting monolthic LTE design is not right.

When a NF is split into its control and user planes oper-

ations, their distributed implementation may cause dead-

locks and race conditions. Instead, this paper advocates

for microservice-fall-back concept in which only LTE ser-

vices are executed at mobile edge, while keeping LTE

control-plane procedures at the core.

Discussion

This paper stimulates the discussion in mainly three as-

pects: (1) how F ERRET handles failures? (2) how

the device switches back from the microservice to its as-

sociated EPC?, and (3) what are existing limitations of

F ERRET and how we will extend this work?

(1) Recovering failures through FIFO and LIFO

transitions Unlike signaling messages exchange in

legacy EPC, F ERRET wants each of its messages to

be ACKed by edge microservice. In case of failure, we

argue that F ERRET can retransmit the message by sim-

ply switching the message dequeue order from ﬁrst-in

ﬁrst-out (FIFO) to last-in ﬁrst-out (LIFO). It implements

FIFO and LIFO transition algorithm (Figure 6b) to en-

sure in-order delivery of messages even during failures.

At the start, it dequeues the message as FIFO and sends

this to respective edge NF for execution. The edge NF

should send an ACK on receiving the message. In case

F ERRET does not receive the ACK, it puts back the

message into the queue. It then dequeues the message as

LIFO and retries. Figure 6a explains the process. It has

been show that F ERRET has received ACKs for M

and

messages. It dequeues next message (M

) as FIFO

and sends it to edge NF. M

was not ACKed by edge NF

and ACK receive timer has timed-out. On timeout event,

F ERRET ﬁrst enqueues M

and changes its dequeuing

order from FIFO to LIFO. This means on next round of

dequeuing, the failed message (M

) is dequeued and re-

sent to respective edge NF. This time F ERRET has re-

ceived an ACK for M

and switches back to FIFO for

dequeuing next message (M

). In short, by transitioning

between FIFO and LIFO, F ERRET ensures that mes-

sages are sent in-order even during transmission failures.

(2) Releasing connection Once LTE service concludes

at the subscriber (such as voice call hangs-up), the device

releases the radio connection. The base station sends this

release signal to in-service microservice that ﬁnally falls

the subscriber connection back to EPC core. Thereafter,

EPC re-conﬁgures its interfaces with base station and reg-

isters the device status as Idle.

(3) Limitations One key limitation of F ERRET is

that it can only handle one application at a time. This

is because, we are using standardized base station inter-

faces that can only extend to one EPC instance (i.e. core

or microservice). Once the base station is connected to

in-service microservice (say VoLTE microservice), it can-

not switch to any other microservice (say web microser-

vice). The other limitation is that our microservice can-

not function during handover procedure as we have not

implemented location update procedure at microservice

architecture for simplicity.

In future work, we aim to address both these issues by

placing network address translator like agent at LTE base

station that allows it to associate with multiple EPC in-

stances (i.e. legacy EPC and a number of microservices).

References

[1] Ericsson’s Integrated Site concept.

https://www.ericsson.com/ericsson/corp

info/publications/review/2005_01/files

/2005014.pdf.

[2] 3GPP. TR 23.714: Study on control and user plane sepa-

ration of EPC nodes, September, 2016.

[3] 3GPP. TS23.401: GPRS Enhancements for E-UTRAN

Access, 2011.

[4] Open EPC - open source LTE implementation.

http://www.openepc.net/.

[5] M. T. Raza and et al. Rethinking lte network function vir-

tualization. In IEEE ICNP, 2017.

[6] J. Cho and et al. Acacia: Context-aware edge computing

for continuous interactive applications over mobile net-

works. In ACM CoNeXT, 2016.

[7] Y. Li and et al. A control-plane perspective on reducing

data access latency in lte networks. In ACM MobiCom,

2017.

[8] V. Nagendra and et al. LTE-Xtend: scalable support of

M2M devices in cellular packet core. In ACM Workshop

on All Things Cellular, 2016.

[9] A. Sheoran and et al. Contain-ed: An NFV Micro-Service

System for Containing e2e Latency. In ACM workshop

HotConNet, 2017.

[10] A. Gember-Jacobson and et al. Opennf: Enabling inno-

vation in network function control. In ACM SIGCOMM,

2014.

[11] A. Banerjee and et al. Scaling the LTE control-plane for

future mobile access. In ACM CoNEXT, 2015.