5G Network Architecture and the

Future Mobile Internet

IEEE 5G Workshop
Princeton, May 26, 2015

D. Raychaudhuri
WINLAB, Rutgers University
ray@winlab.rutgers.edu
Introduction
 Introduction: 5G Vision
Faster radio ~Gbps
Low-latency wireless access ~ms
Dynamic spectrum, multiple radio access technologies
Next-gen network with improved support for emerging
mobility services:

Content Delivery
Vehicular Networks
Cloud Services

Mobile Data
(cellular, hetnet)

Emergency Networks Internet-of-Things WINLAB

 Introduction: Why 5G Needs a New
Network Architecture
5G/NGMN/FIA
TODAY PCRF

LTE SGW PGW

LTE
w/FIA
interface Mobility-Centric
Future Internet
Internet Architecture

4G Radio MME
Access
Network Standard FIA
MSC Router
HSS

WAG FIA Distributed

WiFi AAA Control Plane
WiFi
w/FIA
interface

Hybrid 3GPP & IP arch Unified Internet/Mobile Net arch with

Complex control interfaces! integrated support for naming,
Technology specific authentication, mobility, etc.
IP tunneling in data path Simplified distributed control!
Gateways (..bottlenecks, sub- Technology neutral BS or AP plug-in
optimum routing,..) Flat! No gateways or tunnels!
Mobile devices as first class citizens
WINLAB
 Introduction: Why the Internet needs a new
mobility-centric protocol architecture
Historic shift from PCs to
mobile computing and
embedded devices
Mobile data growing exponentially 3.6 Exabytes
in 2014, >> wired Internet traffic
Sensor/IoT/V2V ~5-10B units by 2020
Internet in 2020 all about mobile platforms &
services

Inevitable convergence of mobile

Wireless Technology
network and Internet industries Trend 5G Higher speeds/scale,
network of networks
Need to think beyond the Gs, associated with
linear progression in mobile systems Future
Mobile Internet
Era of vertically integrated protocol stacks built on
radio standards coming to an end New wireless/mobile
functions, enhanced
Single end-to-end protocol standard for the future Internet Technology security, services
mobile Internet! Trend FIA
Same end users!

Research Target of NSF Future Internet

Architecture (FIA) MobilityFirst Project

WINLAB
 Introduction: What a Converged Mobile
Internet Protocol Would Look Like
Mobility was added to IP after the fact due to historical
reasons, but single unified solution remains feasible
Previous attempts at convergence such as mobile IP proved to be insufficient
5G is an opportunity for the industry to address this need with a single unified protocol stack for all
services on the Internet, given that mobile is now the dominant use case
Can provide significant improvements: radio technology neutral, improved scalability and security, flat
network structure, enhanced mobility functions,

5G/NGMN/FIA
TODAY

UE BS/AP Server
Router Router
TP
TP

FIA IP+ FIA IP+ FIA IP+

FIA IP+ FIA IP+
xG MAC xG MAC DLC DLC
DLC

xG PHY xG PHY PHY PHY PHY

Radio access specific

Future Internet Protocol with Integrated Mobility Support
Internet Protocol
Custom Access Protocols

WINLAB
Next-Gen Mobile Network
Requirements
 Next-Gen Network Requirements: (1) Mobility
End-point mobility as a basic service of the future Internet
Any network connected object or device should be reachable on an efficiently
routed path as it migrates from one network to another
Eliminate service gateways (bottleneck points), IP tunnels, etc. (flat)
Fast authentication, dynamic handoff (vertical), and global roaming
Mobility service should be scalable (billions of devices) and fast ~50-100 ms
Implications for core naming/routing/security architecture of Internet

AS39 AS99
(WiFi (LTE)
)

Inter-AS Roaming INTERNET

Agreement
Mobile Peering

AS49

AS2

User/Device
Mobility
Measured Inter-Network Mobility Traces
(Prof. J. Kurose, UMass, 2013)

WINLAB
 Next-Gen Network Requirements :
(2) Handling Disconnection & BW Variation
Wireless medium has inherent fluctuations in bit-rate (as much
as 10:1 in 4G access), heterogeneity and disconnection
Poses a fundamental protocol design challenge
New requirements include in-network storage/delay tolerant delivery, dynamic
rerouting (late binding), etc.
Transport layer implications end-to-end TCP vs. hop-by-hop
Mobile devices with varying BW due to SNR variation,
Shared media access and heterogeneous technologies Dis- AP-2
Bit connect
Rate BS-1
(Mbps)
BS-1

Wireless
Access Net #3

Disconnection Time
INTERNET interval
Wireless
Access
Network #2

AP-2

WINLAB
 Next-Gen Network Requirements:
(3) Multicast as a Basic Service
Many mobility services (content, context) involve multicast
The wireless medium is inherently multicast, making it possible
to reach multiple end-user devices with a single transmission
Fine-grain packet level multicast desirable at network routers
Packet-level Multicast at Routers/APs/BSs
Session level Multicast Overlay (e.g. PIM-SIM)

Pkt Mcast at Routers

Wireless
Access Net #11

Access
Network
(Eithernet) INTERNET
INTERNET Radio
Wireless Broadcast
Access Medium
Net #32
RP

WINLAB
 Next-Gen Network Requirements :
(4) Multi-Homing as a Standard Feature
Multiple/heterogeneous radio access technologies (e.g.
4G/5G and WiFi) increasingly the norm
Improved service quality/capacity via opportunistic high BW access
Improved throughput in hetnet (WiFi/small cell + cellular) scenarios
Can also be used to realize ultra-high bit-rate services using multiple
technologies, e.g. 60 Ghz supplement to LTE
Implications for naming and routing in the Internet
Multihomed devices may utilize two or more interfaces to improve communications
quality/cost, with policies such as deliver on best interface or deliver only on WiFi
or deliver on all interfaces
LTE BS
60 Ghz BS
Wireless (supplement to LTE)
Access Net #3
Wireless
Access Net #3

INTERNET

WiFi
Wireless
AP Multiple
Access
Network Potential
#2 Paths
Mobile device
With dual-radio NICs

WINLAB
Next-Gen Network Requirements:
(5) Efficient Content Delivery
Delivery of content to/from mobile devices a key service
requirement in future networks (ICN, etc.)
This requirement currently served by overlay CDNs
In-network support for content addressability and caching is
desirable service primitives such as get(content-ID, ..)

In-network cache

In-network
cache

Alternative paths
for retrieval
or delivery
Content Owners
Server

Send(content_ID, user_ID)) Get (content_ID)

WINLAB
 Next-Gen Network Requirements:
(6) Context-Aware Services
Context-aware delivery associated with mobile services, M2M
Examples of context are group membership, location, network state,
Requires framework for defining and addressing context (e.g. taxis in New
Brunswick)
Anycast and multicast services for message delivery to dynamic group

Context = geo-coordinates & first_responder

Send (context, data)

Context
Naming Global Name
Service Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
Context ba123
GUID
341x Context-based
Multicast delivery

Mobile
Device
trajectory

WINLAB
Next-Gen Network Requirements: (7) Edge
Cloud Services
Efficient, low-latency cloud services important for emerging
mobile data and cyber physical applications
Tight integration of cloud service with access network
Service anycast primitive get(service_ID,..)
Low latency, dynamic migration of state
Option for in-network processing in data plane

Mobile Internet
Edge Cloud
Access Network B Service
Edge Cloud B
Service Access Network A
A

Nearest Cloud Service

Low latency, dynamic migration

Get(service_ID, data)

User Mobility

WINLAB
Next-Gen Network Requirements:
(8) Edge Peering and Ad Hoc Networks
Wireless devices can form ad hoc networks with or without
connectivity to the core Internet
These ad hoc networks may also be mobile and may be
capable of peering along the edge
Requires rethinking of inter-domain routing, trust model, etc.
Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility

Access
Network
Access
Network
INTERNET

V2I

)
)

V2V Network

WINLAB
Next-Gen Network Requirements: Summary

Security related functions: authentication, data security, etc.

Mobility related functions: end-point migration, network mobility, in-
network storage/delay tolerance, edge awareness, ad-hoc modes,
Multiple interface related functions: separation of object names from
network addresses, multi-homing, multi-path,
Content & context support: named content retrieval, context-
specified dynamic multicast, in-network caching,
In-network processing (optional): media transcoding, cloud services,
data aggregation, ..
service
To more general
From todays set of service
connection oriented abstractions
Get (service)
IP services named objects, data
(pipes)
Send (names, data)
Open (IP_address, data)

WINLAB
From Vision to Proof-of-
Concept Realization:
MobilityFirst Architecture
MobilityFirst Design: Architecture Features
Named devices, content, Strong authentication, privacy
and context
Human-readable 110011010111001000011
name Public Key Based
Global Identifier (GUID)

Routers with Integrated Service API with

Heterogeneous unicast, multi-homing,
Storage & Computing
mcast, anycast, content
Wireless Access
query, etc.
End-Point mobility
with multi-homing In-network
content cache

Storage-aware
Intra-domain Hop-by-hop
Edge-aware
routing file transport
Inter-domain
routing

Connectionless Packet Switched Network

with hybrid name/address routing

Network Mobility &

Disconnected Mode

Ad-hoc p2p
mode
WINLAB
MF Design: Protocol Stack

App 1 App 2 App 3 App 4

Socket API
Name
Certification NCS
& Assignment
Service E2E TP1 E2E TP2 E2E TP3 E2E TP4

Optional Compute
Layer
Plug-In A
Global Name
Resolution GNRS GUID Service Layer
Service Narrow Waist

MF Routing GSTAR Routing MF Inter-Domain IP

Control Protocol
Switching
Hop-by-Hop Block Transfer Option

Link Layer 1 Link Layer 2 Link Layer 3 Link Layer 4 Link Layer 5
(802.11) (LTE) (Ethernet) (SONET) (etc.)

Control Plane
Data Plane

WINLAB
MF Design: Name-Address Separation
GUIDs
Separation of names (ID) from
Sues_mobile_2

network addresses (NA) Server_1234

Media File_ABC Taxis in NB

Globally unique name (GUID) Johns _laptop_1 Sensor@XYZ

for network attached objects

User name, device ID, content, context, Host Sensor Context
Content
Naming
AS name, and so on Service
Naming
Service
Naming
Service
Naming
Service

Multiple domain-specific naming

Globally Unique Flat Identifier (GUID)
services Global Name Resolution Service

Global Name Resolution Service

for GUID NA mappings
Network

Hybrid GUID/NA approach

Both name/address headers in PDU
Fast path when NA is available
GUID resolution, late binding option Net2.local_ID
Network address
Net1.local_ID
WINLAB
MF Design: Hybrid GUID/NA Storage
Router in MobilityFirst
Hybrid name-address based routing in MobilityFirst requires a new
router design with in-network storage and two lookup tables:
Virtual DHT table for GUID-to-NA lookup as needed
Conventional NA-to-port # forwarding table for fast path
Also, enhanced routing algorithm for store/forward decisions
GUID based forwarding
(slow path)

GUID-Address Mapping virtual DHT table

DATA
Look up GUID-NA table when: GUID NA
- no NAs in pkt header 11001..11 NA99,32
- encapsulated GUID To NA11
- delivery failure or expired NA entry

Store when:
- Poor short-term path quality
Router - Delivery failure, no NA entry
Storage - GNRS query failure
DATA - etc.
To NA51

GUID= SID
NA99,NA32 NA Forwarding Table stored physically at router
1100111
Dest NA Port #, Next Hop
NA99 Port 5, NA11
Look up NA-next hop table when: NA62 Port 5, NA11
- pkt header includes NAs NA32 Port 7, NA51 DATA
- valid NA to next hop entry
Network Address Based Forwarding
(fast path)
WINLAB
 MF Protocol Example: Mobility Service via
Name Resolution at Device End-Points
Service API capabilities: Register John Smith22s devices with NCS
- send (GUID, options, data) Name Certification
Options = anycast, mcast, time, .. Services (NCS)
- get (content_GUID, options) GUID assigned
Options = nearest, all, ..
GUID lookup
from directory

NA99 GNRS update

(after link-layer association)
MobilityFirst Network
(Data Plane)

Send (GUID = 11011..011, SID=01, data) NA32

GUID <-> NA lookup GNRS

GNRS query GUID = 11011..011

Represents network
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
object with 2 devices

DATA

GUID SID
NAs

Packet sent out by host

WINLAB
MF Protocol Example: Handling Disconnection
Store-and-forward mobility service example DATA

GUID NA99 rebind to NA75

Delivery failure at NA99 due to device mobility

Router stores & periodically checks GNRS binding
Deliver to new network NA75 when GNRS updates

NA99

Disconnection
interval Device
mobility
Data Plane NA75

DATA

DATA GUID
NA75
GUID SID
NA99
DATA

GUID SID
Send data file to John Smith22s
laptop, SID= 11 (unicast, mobile
delivery)

WINLAB
 MF Protocol Example: Dual Homing Service
Multihoming service example
DATA

DATA
Router bifurcates PDU to NA99 & NA32
(no GUID resolution needed) GUID
NetAddr= NA99

NA99

Data Plane NA32

DATA
DATA GUID
NetAddr= NA32
GUID= SID
1100111 NA99,NA32
DATA

GUID SID
Send data file to John Smith22s
laptop, SID= 129 (multihoming
all interfaces)

WINLAB
 Example Dual-Homing Result for MF:
Cellular LTE + WiFi Performance
37.8 70 70
Free Wi-Fi hotspots Using only LTE
(AT&T HotSpot Locator)
Using the best available Wi-Fi
37.795
60 Using all the available WiFis 60

Maximum throughput per sec (in Mbps)

Using all the Wi-Fis and LTE

Average throughput per sec (in Mbps)

37.79
50 50
Latitide

37.785

40 40
37.78

30 30
37.775

20 Only Wi-Fi 20
37.77
does not help
on an average
-122.43 -122.42 -122.41 -122.4 -122.39 -122.38 -122.37
Longitude 10 10

Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing

Dual-Homed 0 0
Mobile Device 1 2 3 4 5 1 2 3 4 5
(WiFI + LTE) Cab no. Cab no.

MobilityFirst network evaluation for dual-homing

Parametric analysis of best interface vs. dual homing
Link delay, data rate and download size varied
Soft threshold to stripe across both interfaces or use best

WINLAB
 MF Proof-of-Concept Prototype: Click
Software Router and Android API
Click-based MF Router Android/Linux MF Protocol Stack

-Storage-aware routing (GSTAR) - Network API

- Name resolution (GNRS) - Hop transport
- Reliable hop-by-hop link transport (Hop) - Dual homing (WiFi/WiMAX)

Native,
user-level
implementation
on Android
runtime

MF Router WiFi AP
MF Router

26 MF Router
5/26/2015 WINLAB, Rutgers University WiMAX BTS
26

WINLAB
MF Proof-of-Concept: Deployment on
GENI
NL
R
Madison, WI Ann Arbor, MI Cambridge,
MA
Lincoln, NE
Palo Alto, CA
N. Brunswick,
Salt Lake, UT
NJ
Tokyo, Japan

I2
Los Angeles,
CA Clemson,
Atlanta, GA SC

MF Services Demonstrated on GENI:

Multi-Homing Mobile
Named Content Delivery Long-term (non-
MobilityFirst GENI)
In-network Compute Service
Context-Aware Message Delivery Routing and Name Short-term
Edge-Aware Inter-Domain Routing Resolution Wide Area ProtoGENI
Global Name Resolution
and others
Service Sites
MobilityFirst Access ProtoGENI
Early adopter trials starting in 2015 Net WINLAB
Concluding Remarks
 Concluding Remarks: 5G and the Next-Gen
Mobile Network Architecture
Many new enabling technologies, but the key to 5G will be the
network architecture
Inevitable convergence of wireless access networks with the Internet
Highly functional new protocol design needed to support advanced mobility services
From connection-oriented pipes to flexible connectionless service abstractions
NSF FIA MobilityFirst architecture serves as proof-of-concept .
5G Radio

Open LTE

60 Ghz 802.11ad
??

Multi-Radio Android Device

Next-Gen Network
Wideband Cognitive Radio

Historic opportunity & risk for wireless and

5G Enabling Programmable OpenFlow SDN Switch networking industries!

Technologies
WINLAB
 Resources

Project website: http://mobilityfirst.winlab.rutgers.edu

GENI website: www.geni.net

ORBIT website: www.orbit-lab.org

WINLAB