Cellular-Internet Convergence - MobilityFirst

Cellular-Internet Convergence:
Evolving the Internet Architecture to
Support Mobility Services as the Norm
Johannesburg Summit
May 20-21, 2013
D. Raychaudhuri
WINLAB, Rutgers University
[email protected]
Introduction
Introduction: Mobility as the key driver for
the future Internet

Historic shift from PC’s to mobile computing and
embedded devices…

Cisco VNI report predicts smartphone traffic alone will grow by ~10x by
2017, accounting for 7.5 Exabytes/mo; M2M services also taking off …

Mobile devices as a whole will dominate Internet usage  wired devices
will contribute only 39% of traffic by 2016
Motivates efficient integration of cellular nets with IP in short term, and reevaluation of Internet architecture to support general mobility requirements
in long-term

WINLAB
Introduction: Industry Approach Towards Flat
IP Architecture for Mobile Networks

Cellular network standards (3GPP, LTE) have steadily
migrated towards tighter integration with IP
From centralized controllers and gateways to “flat” architectures
 Separation of control and data planes  all IP in LTE


Still requires some gateways, e.g. MME and SGW
Figure from:
Cisco White Paper:
“Evolution of the Mobile Internet”
2010
WINLAB
Introduction: Cellular and Internet Technology
Evolution Trend

Opportunity for greater convergence of Internet and
cellular/mobile network standards
Service-Level
Cellular
Technologies
Core Cellular
Network
Technologies
~1975…
GSM
Mobile
Network
3GPP
3GPP2
(IP-based)
~1990
~2000
Core
Internet
Technologies
Basic
IP Addressing
& Routing
Android
Services
MMS
“5G”
Arch
??
SDR, Open BTS
Flat
IP-based
LTE
Future
Internet
Protocol
~2010
HIP
LISP
Etc.
….
Mobile IP
BGP/CIDR
Inter-Domain
Routing
Mobile
Cloud
Services
SDN/
Virtual Net
??
Mobility
Ext
IPv6
ICN, FIA
VOIP/SIP
Service-Level
Internet
Technologies
Web
Services
CDN
Open
DNS
Cloud
Services
WINLAB
~2020
Introduction: Next-Steps Towards CellularInternet Convergence

Truly flat “future IP” architecture under consideration
No gateways – mobility functionality distributed between routers/BSs/APs running
the same control and data protocols; standard mobility & service control API’s
 Multiple radio access technologies simply plug-in to universal mobile Internet
 Generalized view of mobility service requirements, not limited to simple device
mobility – e.g. multicast, content addressability, context delivery, …

To/From Global
Internet
SGW
MME
futureIP
Inter-Domain
Router
Operator Network
Running future IP
Protocols
Edge Networks with
Mobility Services
Standard
IP Router
Enhanced Packet Core
(Operator Network)
Future IP control plane
w/ mobility support
RAN B
futureIP
Intra-Domain
Router
RAN C
RAN A
RAN A
RAN
Net B
WINLAB
Mobility Requirements:
Supporting Device Migration as Basic Service
 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

Requirements similar to mobile IP in the Internet today and dynamic
handoff/roaming in cellular networks

Mobility service should be scalable (billions of devices) and fast ~50-100 ms
Wireless
Access Net #3
INTERNET
Wireless
Access
Network
#2
BS2
User/Device
Mobility
WINLAB
Mobility Requirements:
Handling BW Variation & Disconnection

Wireless medium has inherent fluctuations in bit-rate (as much
as 10:1 in 3G/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
Bit
Rate
(Mbps)
Disconnect
BS-1
BS-1
Wireless
Access Net #3
Disconnection
interval
INTERNET
Time
Wireless
Access
Network #2
AP-2
WINLAB
AP-2
Mobility Requirements:
Multicast as a Basic Network 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/AP’s/BSs
Session level Multicast Overlay (e.g. PIM-SIM)
Pkt Mcast at Routers
Wireless
Access Net #11
Access
Network
(Eithernet)
INTERNET
INTERNET
RP
Wireless
Access
Net #32
Radio
Broadcast
Medium
WINLAB
Mobility Requirements:
Multi-Homing as a Standard Service

Multiple/heterogeneous radio access technologies (e.g.
3G/4G and WiFi) increasingly the norm
Implies the need for separating “identity” from “locators” (network addresses)
 Requires routing framework that supports packet level multicasting where
needed for efficient delivery to multiple networks
 Support for alternative routing policies – “best path”, “all paths”, etc.

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”
LTE BS
Wireless
Access Net #3
INTERNET
Wireless
Access
Network #2
WiFi
AP
Mobile device
With dual-radio NICs
WINLAB
Mobility Requirements :
Multi-Network Access, Multipath



Wired Internet devices typically have a single Ethernet interface
associated with a static network/AS
In contrast, mobile devices typically have ~2-3 radios and can
see ~5-10 distinct networks/AS’s at any given location
Basic property - multiple paths to a single destination  leads
to fundamentally different routing, both
intra and inter domain!
Mobile device with multi-path reachability
BS-1
Single “virtual link” in wired Internet
Wireless
Access Net #1
BS-2
Wireless
Access Network
Wireless
Access Net #3
Access
Network
(Eithernet)
INTERNET
BS-3
INTERNET
Ethernet
NiC
Wireless
Edge
Network
AP1
Multi
Radio
NIC’s
WINLAB
Multiple
Potential
Paths
Mobility Requirements:
Content Retrieval & Delivery Capabilities



Delivery of content to/from mobile devices a key service
requirement in future networks
This requirement currently served by overlay CDN’s
In-network support for content addressability and caching is
desirable  service primitives such as get(content-ID, ..)
In-network cache
In-network
cache
Content Owner’s
Server
Send(“content_ID”, “user_ID”))
Alternative paths
for retrieval
or delivery
Get (“content_ID”)
WINLAB
Mobility Requirements:
Supporting Context-Aware/M2M Services

Context-aware delivery often associated with mobile services
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
Service
Context
GUID
Global Name
Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory
WINLAB
Mobility Requirements:
Ad Hoc & Network Mobility



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 interdomain routing, trust model, etc.
Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility
Access
Network
Access
Network
)
INTERNET
)
WINLAB
Mobility Requirements:
Spectrum Coordination as a Network Service


As more and more data is carried by unlicensed wireless networks,
spectrum coordination should be offered as a network service
Management plane offers global visibility for cooperative setting of
radio resource parameters across independent access networks
WiFi AP locations in a 0.4x0.5 sq.mile area in Manhattan, NY
Network Management Plane
Interface for Radio Parameter Map
(e.g. Frequency, Power, Rate, ..)
Inter-network spectrum
coordination procedures
WINLAB
MobilityFirst Protocol
Design
Designing a Mobility-Centric Internet


Emerging mobile applications, M2M devices, V2V networks etc. involve
more than simple device mobility support from the network
Some examples of services required are: Clients,










Multi-homing, multi-path
Efficient multicast
Ad-hoc modes, DTN delivery
Content mobility, caching
Service mobility
Context services, geo-location
Enhanced authentication & trust
In-network cloud services
….
Servers
Embedded
devices
Mobility Service &
Control API’s
(universal future IP standard)
Network
Services
Network
Transport
Universal future IP
protocols
The “MobilityFirst” future Internet architecture (FIA) project is aimed at
a clean-slate redesign of the IP stack & service/control API’s to meet
these and other anticipated requirements
WINLAB
MobilityFirst Design: Architecture Features
Named devices, content,
and context
Strong authentication, privacy
11001101011100100…0011
Public Key Based
Global Identifier (GUID)
Human-readable
name
Heterogeneous
Wireless Access
Service API with
unicast, multi-homing,
mcast, anycast, content
query, etc.
Routers with Integrated
Storage & Computing
End-Point mobility
with multi-homing
In-network
content cache
Storage-aware
Intra-domain
routing
Edge-aware
Inter-domain
routing
Hop-by-hop
file transport
MobilityFirst Protocol Design Goals:
-
10B+ mobile/wireless devices
Mobility as a basic service
BW variation & disconnection tolerance
Ad-hoc edge networks & network mobility
Multihoming, multipath, multicast
Content & context-aware services
Strong security/trust and privacy model
Connectionless Packet Switched Network
with hybrid name/address routing
Network Mobility &
Disconnected Mode
Ad-hoc p2p
mode
WINLAB
MobilityFirst Design: Technology Solution
Name Certification
Service (NCS)
Flexible name-based network service layer
Global Name
Resolution Service
(GNRS)
Hybrid GUID/NA
Global Routing
(Edge-aware, mobile,
Late binding, etc.)
Name-Based
Services
(mobility, mcast,
content, context,
M2M)
Storage-Aware
& DTN Routing
(GSTAR)
in Edge Networks
Optional
Compute Layer
Plug-Ins
Meta-level
Network Services
(cache, privacy, etc.)
Hop-by-Hop
Transport
(w/bypass option)
Core Transport
Services
Pure connectionless packet switching with in-network storage
WINLAB
MF Design: Protocol Stack
App 1
App 2
App 3
App 4
E2E TP3
E2E TP4
Socket API
Name
Certification
& Assignment
Service
NCS
E2E TP1
E2E TP2
Optional Compute
Layer
Plug-In A
Global Name
Resolution
Service
GNRS
MF Routing
Control Protocol
GUID Service Layer
GSTAR Routing
MF Inter-Domain
Hop-by-Hop Block Transfer
Link Layer 1
(802.11)
Link Layer 2
(LTE)
Narrow Waist
Link Layer 3
(Ethernet)
IP
Switching
Option
Link Layer 4
(SONET)
Link Layer 5
(etc.)
Control Plane
Data Plane
WINLAB
MF Design: Name-Address Separation
 GUIDs

Separation of names (ID) from
network addresses (NA)
Globally unique name (GUID)
for network attached objects
Sue’s_mobile_2

Server_1234
John’s _laptop_1

User name, device ID, content, context,
AS name, and so on
 Multiple domain-specific naming
services


Host
Naming
Service
Media File_ABC
Sensor@XYZ
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
for GUID  NA mappings
Global Name Resolution Service
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
Taxis in NB
WINLAB
MF Design: Service Abstractions (1)



MobilityFirst offers a named-object service API that supports
mobility, disconnection, multi-homing, multicast in a natural way
Replaces the point-to-point virtual link abstraction of IP …
Example: Sending to a mobile device with multiple interfaces
IP Abstraction: Virtual Link
MF Abstraction: Multi-homed Network Object
Send(IP=X, data)
Send(GUID=Y, data, options)
..options for multi-homing & late binding
NA=X1
Network
IP Addr=X
Interface
Dest
Device
Name=
MAC
Static
MAC=X
binding
Dynamic
GUID – NA
bindings
NA=X2
GUID=Y
NA=X3
Network
Attached
Object
e.g., Y may be a mobile device with 3 interfaces (WiFi & 2 cellular)
WINLAB
MF Design: Service Abstractions (2)

Use of MF Service API for content retrieval and dynamic group
multicast (..membership may be specified by context)
MF Abstraction: Get Replicated Content Object
MF Abstraction: Send to Group Object with
Multicast reachability
Get (Content_GUID=A, options)
..option for shortest path
NA=X1
NA=X2
Send (GUID=Z, data, options)
..option for mcast delivery
NA=X3
NA=X2
Broadcast Medium
Content Object
With GUID=A
GUID=A
GUID=A
e.g., A is a replicated content object at multiple network locations
Group
GUID = Z
GUID1
GUID2
GUID3
e.g., Z may be a context group of M2M devices or a cloud service
WINLAB
Building Mobile Networks with MF

MobilityFirst enables both tightly and loosely coupled
architectures for mobile networks
Current Mobile Networks
•
•
•
•
•
•
AAA Server
GSM/CDMA/
LTE
Control Path Elements
Mobility Management
Entity (MME)
Data Path Elements
Make-before-break
Handover
Controlled QoS inside network
Wi-Fi
Internet
Gateway
Node
ISP 1
Loosely Coupled Network-of-Networks
Internet
GSM/CDMA/
LTE
ISP 2
Mobility Support
Through GNRS
ISP 3
Planned Deployment
Licensed Spectrum
Fine-grained Managed QoS
Centralized Mobility Support
Homogeneous Topology
Network-wide Authentication
Global Name
Resolution
Service
•
•
•
•
•
•
Ad-hoc Deployment
Unlicensed Spectrum
Coarse-grained Managed
In-network Mobility Support
Heterogeneous topology
Authentication at APs
Wireless Cooperation
through Geographic Routing
WINLAB
MF Protocol Example: Mobility Service via
Name Resolution at Device End-Points
Service API capabilities:
- send (GUID, options, data)
Options = anycast, mcast, time, ..
- get (content_GUID, options)
Options = nearest, all, ..
Register “John Smith22’s devices” with NCS
Name Certification
Services (NCS)
GUID assigned
GUID lookup
from directory
NA99
MobilityFirst Network
(Data Plane)
Send (GUID = 11011..011, SID=01, data)
GNRS update
(after link-layer association)
NA32
GNRS
GUID <-> NA lookup
GNRS query
Send (GUID = 11011..011, SID=01, NA99, NA32, data)
GUID = 11011..011
Represents network
object with 2 devices
DATA
GUID
SID
NAs
Packet sent out by host
WINLAB
MF Protocol Design: Realizing the GNRS
Fast GNRS implementation based on DHT between routers

GNRS entries (GUID <-> NA) stored at Router Addr = hash(GUID)
 Results in distributed in-network directory with fast access (~100 ms)
1
0.9
Cumulative Distribution Function (CDF)

0.8
0.7
K = 5,
95 th Percentile
at 91 ms
K = 1,
95 th Percentile
at 202 ms
0.6
0.5
0.4
0.3
K
K
K
K
K
0.2
0.1
0
10
20
50
100
Round Trip Query Latency in milliseconds (log scale)
Internet Scale Simulation Results
Using DIMES database
WINLAB
=
=
=
=
=
1
2
3
4
5
1,000
GNRS Scalability Results


We did a trace driven simulation to assess scalability
Question: How much load on GNRS if everyone driving in a
given area uses MF for mobility management:
Traces from Rutgers Intelligent Transportation Systems Lab:
Captures peak time traffic of >16K vehicles in a ~8 sq.km urban
area of Jersey CIty, NJ
GNRS load not too high even for very frequent
handovers and high density of vehicles
Cumulative Distribution Function (CDF)
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
Cell Radius = 250 m
Cell Radius = 500 m
Cell Radius = 750 m
0.1
0
0
10
20
30
40
50
60
70
Number of Updates/second
WINLAB
80
90
MF Protocol Design: Storage-Aware
Routing (GSTAR)



Storage aware (CNF, generalized DTN) routing exploits in-network
storage to deal with varying link quality and disconnection
Routing algorithm adapts seamlessly adapts from switching (good
path) to store-and-forward (poor link BW/short disconnection) to
DTN (longer disconnections)
Storage has benefits for wired networks as well..
Temporary
Storage at
Router
Initial Routing Path
Low BW
cellular link
Re-routed path
For delivery
Mobile
Device
trajectory
PDU
Storage
Router
High BW
WiFi link
Sample CNF routing result
WINLAB
MF Protocol 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
Look up GUID-NA table when:
- no NAs in pkt header
- encapsulated GUID
- delivery failure or expired NA entry
GUID
NA
11001..11
NA99,32
DATA
To NA11
Router
Storage
DATA
SID
GUID=
11001…11
NA99,NA32
To NA51
Store when:
- Poor short-term path quality
- Delivery failure, no NA entry
- GNRS query failure
- etc.
NA Forwarding Table – stored physically at router
Dest NA
Look up NA-next hop table when:
- pkt header includes NAs
- valid NA to next hop entry
Port #, Next Hop
NA99
Port 5, NA11
NA62
Port 5, NA11
Port 7, NA51
NA32
DATA
Network Address Based Forwarding
(fast path)
WINLAB
GNRS + Storage Routing Performance
Result



Detailed NS3 Simulations to
compare MF with TCP/IP
Hotspot AP Deployment:
Includes gaps and overlaps
Cars move according to realistic
traces & request browsing type
traffic (req. size: 10KB to 5MB)
Empirical CDF of file transfer time
Single Car: Aggregate Throughput vs.Time
100
Total Data Received (MBits)
1
0.8
CDF
0.6
d: Average distance
between APs
0.4
MF: d = 200
TCP/IP: d = 200
MF: Avg. d = 400
TCP/IP: d = 400
0.2
0
0
10
20
30
40
50
File Transfer Time (sec)
60
70
80
60
TCP/IP-30miles/hr
TCP/IP-50miles/hr
TCP/IP-70miles/hr
MF-30miles/hr
MF-50miles/hr
MF-70miles/hr
40
20
0
0
50
100
Time (sec)
150
WINLAB
200
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
Data Plane
Device
mobility
NA75
DATA
DATA
GUID
NA75
GUID
SID
NA99
DATA
GUID SID
Send data file to “John Smith22’s
laptop”, SID= 11 (unicast, mobile
delivery)
WINLAB
LTE/WiFi HetNet Results: MF vs. TCP
MF provides several benefits in a heterogeneous wireless
environment:

Seamless mobility across network domains via dynamic GUID-NA bindings
 Routers automatically store packets in transit during periods of disconnection
 Simultaneous use of multiple networks is also possible
Aggregate Throughput with Time
1000
900
Aggregate Throughput (MBytes)

Throughput boost
due to
transmission of
stored packets
800
700
TCP takes more time to
re-start session (DHCP
+ Application reset)
600
500
400
300
200
MobilityFirst
TCP/IP
100
0
0
20
40
60
Time (sec)
80
100
120
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
SID
GUID=
11001…11
NA99,NA32
DATA
GUID SID
Send data file to “John Smith22’s
laptop”, SID= 129 (multihoming –
all interfaces)
WINLAB
MF Multipath Performance Result


Multipath service with data striping between LTE and WiFi
Using backpressure propagation and path quality info
GNRS Server
GUIDY NA1
Query:
(GUIDY)
Data
Response:
(NA1,NA2,
Policy: Stripe)
GUIDY Data
Chunk
Chunk
Chunk
Ch u
nk
NA1
Sender: GUIDX
Backpressure
Ch
Net Addr Path Quality
NA1
4
NA2
36
Backpressure
un
k
Ch
Chunk
Chunk
un
NA2
k
Receiver:
GUIDY
Splitting
Logic
GUIDY NA2
Data
Aggregate Throughput (Mb)
1000
MobilityFirst Multihoming
Oracle Application
Using only LTE
Using only Wi-Fi
800
600
400
200
0
0
10
20
30
40
50
Time (sec)
60
70
80
WINLAB
90
100
MobilityFirst Protocol
Prototyping & Validation
MF Host Protocol Stack
‘Socket’ API
open
send
send_to
recv
recv_from
close
App-1
App-2
Linux PC/laptop with WiMAX & WiFi
App-3
Context API
Network API
Context
Services
E2E Transport
GUID Services
Network Layer
Security
Sensors
Android device with WiMAX & WiFi
Routing
User policies
Interface Manager
‘Hop’ Link Transport
Early Dev.
WiFi
Integrate
WiMAX
Device: HTC Evo 4G, Android v2.3 (rooted), NDK
(C++ dev)
WINLAB
36
MF Click Software Router
Lightweight, scalable multicast
• GNRS for maintenance of
multicast memberships
• Heuristic approaches to
reduce network load, limit
duplicated buffering, and
improve aggregate delivery
delays
• Click prototype, with SID for
multicast flows
• Evaluating hail a cab
application as a example
multipoint delivery scenario
37
Multicast
Inter-Domain
(EIR)
WINLAB
OpenFlow/SDN Implementation of MF
Protocol stack embedded within controller
Label switching, NA or GUID-based routing (incl. GNRS lookup)
Controllers interact with other controllers and network support
services such as GNRS
Flow rule is set up for the remaining packets in the chunk based on
Hop ID (which is inserted as a VLAN tag in all packets)
E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101
=> OUT PORT = 16




38
MF Protocol Stack
WINLAB
MF Router Prototype on FLARE SDN
Platform from U Tokyo (Nakao)

Objectives

Multi-site deployment of MobilityFirst
routing and name resolution services


Impact of large RTTs on MobilityFirst
network protocols
High performance evaluation of
MobilityFirst delivery services on
FLARE - 1Gbps, 10Gbps

Augmented Click router elements
compiled down to FLARE native

Evaluation of FLARE platform for
design and evaluation of nextgeneration network protocols
 Demo at GEC-16, March 2013
WINLAB
GENI 4G Access Deployment at Rutgers
for Validation of 4G/WiFi Access Scenario



Rt.1 campus deployment since 2009
“Open Base Station” with external SDN/VM
controller enabling experimentation with
new network protocols
Integrated with GENI control framework
RF Module
( sector)
Open
WiMAX in Phase 1 
LTE in Phase 2
Base
Module
Omni-directional antenna
(elev. < 6ft above roof!)
Outdoor Unit (ODU)
WINLAB
40
MF Multi-Site GENI Deployment –
Demo at GEC-16, March 2013
NL
R
Cambridge,
MA
Madison, WI Ann Arbor, MI
Lincoln, NE
Palo Alto, CA
N. Brunswick,
NJ
Salt Lake, UT
Tokyo, Japan
Los Angeles,
CA
I2
Atlanta, GA
MobilityFirst
Routing and Name
Resolution
Service Sites
MobilityFirst Access
Net
Clemson,
SC
Long-term (nonGENI)
Short-term
Wide Area ProtoGENI
ProtoGENI
WINLAB
Resources

Project website: http://mobilityfirst.winlab.rutgers.edu

GENI website: www.geni.net

ORBIT website: www.orbit-lab.org
WINLAB