1. D. Raychaudhuri WINLAB, Rutgers University ray@winlab.rutgers.edu
MobilityFirst Future Internet Architecture ECE544 Lec 10 April 24, 2015
D. Raychaudhuri
WINLAB, Rutgers University

2. Next-Gen Network Requirements

3. MobilityFirst Project: Background
MobilityFirst project started in 2010 under NSF FIA, continuing under FIA-NP
Project team: Rutgers, UMass, Michigan, Wisconsin, Duke, MIT, Nebraska
Clean-slate architecture motivated by fundamental shift of Internet services to mobile platforms  ~10B in 2020!
Use cases:
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
Content Delivery
Vehicular Networks
Cloud Services
Mobile Data
(cellular, hetnet)
Emergency Networks
Internet-of-Things

4. Next-Generation Wireless Network Requirements
Fast growth in mobile data accelerating cellular-Internet convergence …..
100B+ Wireless
Devices
Cloud Services
Heterogeneous
Technologies
Seamless
Integration
multi-
homing
Key requirements:
Scale/Capacity (100B+)
Speed (Gbps+)
Latency (<10ms)
Integrated mobility
Multipath, multicast,
multihoming ..
Robustness/DTN
Context-aware
Energy aware
..others
Wide-Area Internet
Dynamic spectrum
Access
Network
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
High-Speed
~Gbps
radio
Local
cache/
cloud
Low end-to-end
latency
Content
Services
Global
Mobility
Strong
Security/Privacy

5. 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
Requirements similar to mobile IP in the Internet today and authentication, handoff/roaming in cellular networks
Mobility service should be scalable (billions of devices) and fast ~ ms
INTERNET
Wireless
Access Net #3
Access Network #2
BS2
User/Device
Mobility
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.

6. 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-
connect
AP-2
Bit
Rate
(Mbps)
BS-1
BS-1
Wireless
Access Net #3
INTERNET
Time
Disconnection interval
Wireless
Access Network #2
AP-2

7. 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
INTERNET
Session level Multicast Overlay (e.g. PIM-SIM)
Wireless
Access Net #11
Access Network
(Eithernet)
Radio
Broadcast
Medium
Packet-level Multicast at Routers/AP’s/BSs RP
Access Net #32
Pkt Mcast at Routers

8. 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 via path diversity
Supports improved throughput in hetnet (WiFi/small cell + cellular) scenarios
Can also be used to realize ultra-high bit-rate services using multiple networks
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
(supplement to LTE)
Wireless
Access Net #3
INTERNET
Wireless
Access Network #2
WiFi AP
Mobile device
With dual-radio NICs

9. Next-Gen Network Requirements: Multi-Network Access
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
Single “virtual link” in wired Internet
BS-1
Wireless Access Net #1
Wireless
Access Network
BS-2
Wireless
Access Net #3
INTERNET
INTERNET
Access Network
(Eithernet)
BS-3
Multiple
Potential
Paths
Wireless
Edge Network
Ethernet
NiC
AP1
Multi
Radio
NIC’s

10. Next-Gen Network Requirements: – (5) Efficient Content Retrieval
Delivery of content to/from mobile devices a key service requirement in future networks (…”ICN”, etc.)
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
Alternative paths
for retrieval
or delivery
Content Owner’s
Server
Send(“content_ID”, “user_ID”))
Get (“content_ID”)

11. Next-Gen Network Requirements: – (6) Context-Aware 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
Global Name
Resolution service
NA1:P7, NA1:P9, NA2,P21, ..
Context
GUID
ba123
341x
Context-based
Multicast delivery
Mobile
Device
trajectory

12. Next-Gen Network Requirements: – (7) 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 interdomain routing, trust model, etc.
Ad Hoc Network Formation, Intermittent Connection to Wired Internet & Network Mobility
INTERNET
Access Network
Access Network ) )

13. Next-Gen Network Requirements: – (8) Spectrum Management
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

14. MobilityFirst Protocol Design

15. MobilityFirst Design: Architecture Features
Named devices, content,
and context
Strong authentication, privacy
Human-readable
name
…0011
Public Key Based
Global Identifier (GUID)
Routers with Integrated
Storage & Computing
Service API with
unicast, multi-homing,
mcast, anycast, content query, etc.
Heterogeneous
Wireless Access
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
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
Connectionless Packet Switched Network
with hybrid name/address routing
Network Mobility &
Disconnected Mode
Ad-hoc p2p
mode

16. MobilityFirst Design: Technology Solution
Name Certification
Service (NCS)
Flexible name-based network service layer
Global Name
Resolution Service
(GNRS)
Name-Based
Services
(mobility, mcast, content, context, M2M)
Optional
Compute Layer
Plug-Ins
(cache, privacy, etc.)
Meta-level
Network Services
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
Hybrid GUID/NA
Global Routing
(Edge-aware, mobile,
Late binding, etc.)
Storage-Aware
& DTN Routing (GSTAR)
in Edge Networks
Hop-by-Hop
Transport
(w/bypass option)
Core Transport
Services
Pure connectionless packet switching with in-network storage

17. MF Design: Protocol Stack
App 1
App 2
App 3
App 4
Socket API
Name
Certification
& Assignment
Service
NCS
E2E TP1
E2E TP2
E2E TP3
E2E TP4
Optional Compute
Layer
Plug-In A
Global Name
Resolution
Service
GNRS
GUID Service Layer
Narrow Waist
MF Routing
Control Protocol
GSTAR Routing
MF Inter-Domain IP
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
Hop-by-Hop Block Transfer
Switching
Option
Link Layer 1
(802.11)
Link Layer 2
(LTE)
Link Layer 3
(Ethernet)
Link Layer 4
(SONET)
Link Layer 5
(etc.)
Control Plane
Data Plane

18. MF Design: Name-Address Separation  GUIDs
Separation of names (ID) from network addresses (NA)
Globally unique name (GUID) for network attached objects
User name, device ID, content, context, AS name, and so on
Multiple domain-specific naming services
Global Name Resolution Service for GUID  NA mappings
Hybrid GUID/NA approach
Both name/address headers in PDU
“Fast path” when NA is available
GUID resolution, late binding option
Sue’s_mobile_2
Server_1234
Media File_ABC
Taxis in NB
John’s _laptop_1
Host
Naming
Service
Sensor
Naming
Service
Content
Naming
Service
Context
Naming
Service
Globally Unique Flat Identifier (GUID)
Global Name Resolution Service
Network
Net2.local_ID
Network address
Net1.local_ID

19. MobilityFirst Network
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
GNRS update
(after link-layer association)
MobilityFirst Network
(Data Plane)
Send (GUID = , SID=01, data)
NA32
GNRS
GUID <-> NA lookup
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
GNRS query
GUID =
Represents network
object with 2 devices
Send (GUID = , SID=01, NA99, NA32, data)
DATA
GUID
SID
NAs
Packet sent out by host

20. 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)
Internet Scale Simulation Results
Using DIMES database

21. 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

22. MF Protocol Design: Edge-Aware Inter-Domain Routing (EIR)
EIR designed to better support new MF requirements such as late binding, multi-homing, edge peering, network mobility…
Design based on aNodes and vLinks which allow AS owners considerable flexibility in aggregating and exposing network resources and transit paths
Routing protocol uses telescopic NSP (network state packet) forwarding to provide full graph information while maintaining low control overhead
NSP contains aggregated link properties such as BW, availability, variability, ..
Label-based cut-through routing of transit traffic and enforcement of local policy
Network State Packet (NSP)

23. 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-Address Mapping – virtual DHT table
NA Forwarding Table – stored physically at router
GUID NA
NA99,32
Dest NA
Port #, Next Hop
NA99
Port 5, NA11
GUID –based forwarding
(slow path)
Network Address Based Forwarding
(fast path)
Router
Storage
Store when:
Poor short-term path quality
Delivery failure, no NA entry
GNRS query failure
etc.
NA32
Port 7, NA51
DATA
SID
GUID=
11001…11
NA99,NA32
NA62
To NA11
To NA51
Look up GUID-NA table when:
- no NAs in pkt header
- encapsulated GUID
- delivery failure or expired NA entry
Look up NA-next hop table when:
- pkt header includes NAs
- valid NA to next hop entry

24. 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
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
DATA
DATA
GUID
NA75
GUID
SID
NA99
DATA
GUID
SID
Send data file to “John Smith22’s laptop”, SID= 11 (unicast, mobile delivery)

25. GNRS + Storage Routing Performance Result for WiFi Scenario
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)

26. 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
Not sure if this figure helps or what will help as the opening Architecture slide. But I was imagining you would begin by flashing a comprehensive architecture and then going into: How did we come up with this architecture, which would lead to the next Design Goals slide.
DATA
DATA
GUID
NetAddr= NA32
GUID=
11001…11
SID
NA99,NA32
DATA
GUID
SID
Send data file to “John Smith22’s laptop”, SID= 129 (multihoming – all interfaces)

27. Example Dual-Homing Result for MF: Cellular LTE + WiFi Performance
Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing
Dual-Homed
Mobile Device
(WiFI + LTE)
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

28. MF Protocol Example: Enhanced CDN Service Using Compute Layer Feature
Enhanced service example – content delivery with in-network caching & transcoding
Content cache at mobile
Operator’s network – NA99
MF Compute Layer
with Content Cache
Service plug-in
GUID=
NA43
NA31
GUID=
Filter on
SID=128
GUID=
NA99
GNRS query
Returns list:
NA99,31,22,43
GNRS
Query
NA29
Data fetch from
NA99
GUID=
Content file
NA22
Mobile’s GUID
Data fetch from
NA43
Content Owner’s
Server
Get (content_GUID,
SID=128 - cache service)
Get (content_GUID)
Query
User mobility
GUID=
SID=128 (enhanced service)

29. MF Context Example: Geo-Tag Messaging Application (GEC18, Oct 2013)
Context: Location L; messages dropped at L; phones that dropped message at L
Location L is a geo fence, and captured by a context GUID: GL
GNRS mappings for GL enable advanced messaging operations
Example 1 : ‘Send message to Location L’ : received by all phones bound to location L
Example 2 : ‘Get messages dropped for Location L’ : requested received by all phones that dropped a message at L
Not an overlay or hosted service
Devices: HTC Evo 4G, Samsung 4G (GSII/Epic Touch), with WiFi and WiMAX radios
Software: Android 2.3.x/4.x, MobilityFirst Protocol Stack and Network Service API
Drop
Pickup

30. MobilityFirst Protocol Prototyping & Validation

31. MobilityFirst Router Implementation
Early Dev.
Inter-Domain
Integrate R3
Locality-Aware DNS
GSTAR
DMap – DiHT
PacketCloud Framework
User-level Processes
Routing
Name Resolution
Compute Services
Content Cache Service
Mgmt.
Click Forwarding Engine
Host Rx Q
Host Tx Q
Wired and wireless i/f
To/From Host
To Next-hop Lookup
Rsrc Control
Wired and wireless i/f
Forwarding Table
Packet Classifier
Block
Aggregator
Service
Classifier
Block Segmentor
Rx Q
Tx Q
Next-hop Look up
Hold buffer
x86 hardware and runtime

32. MobilityFirst Host Protocol Stack
‘Socket’ API open
send
send_to
recv
recv_from
close
App-1
App-2
Context API
App-3
Context Services
Sensors
Linux PC/laptop with WiMAX & WiFi
Network API
E2E Transport
GUID Services
Network Layer
Android device with WiMAX & WiFi
Security
Routing
User policies
Interface Manager
‘Hop’ Link Transport
Early Dev.
WiFi
WiMAX
Integrate
Device: HTC Evo 4G, Android v2.3 (rooted), NDK (C++ dev)

33. Evaluation Strategy for MobilityFirst Architecture
WINLAB ORBIT Radio Grid Emulator
GENI Open Cellular
Campus Testbeds
Opnet or ns Simulator
GENI Core
Network
Network Science
Wide Area
MF Network 3
Scale
Routing & GNRS
Validation 4
Early Adopter
Trials (MF-NP)
Service demos &
Real World Users
OpenFlow MF
Controller 3 2
MF Evaluation Stages 1
Math models
SDN/SDR Sandbox in ORBIT
USRP/GNU Radio
3rd Gen CR Platforms
USRP2
Degree of Realism

34. MobilityFirst Deployment on GENI
Long running MF “slice” in GENI to validate routing and name resolution and to run real-world applications on mobile devices (in wireless coverage areas)
Salt Lake, UT
Cambridge, MA
N. Brunswick, NJ
Ann Arbor, MI
Madison, WI
Tokyo, Japan
Lincoln, NE
Los Angeles, CA
Clemson, SC
Long-term (non-GENI)
MobilityFirst Access Net
Short-term
Wide Area ProtoGENI
Palo Alto, CA
ProtoGENI
MobilityFirst Routing and Name Resolution Service Sites I2
NLR
Atlanta, GA

35. GEC-12 Demo: Named Content Delivery in MF
DATA
Content Publisher
Content Subscriber
GUID=3
GUID=5
WiFi AP
WiFi AP
Bridge
GUID=6
GUID=1
GUID & SID
DATA
GUID=7
GUID=2
GUID=4
GUID=201
WiMAX BTS
GUID=101
WiMAX BTS
BBN Wireless Edge
ProtoGENI Backbone
Rutgers Wireless Edge
NLR path using VLANs 3716, 3799 (Clemson)
I2 path using VLANs 3715, 3745(BBN), 3798 (Clemson)
ProtoGENI host running MF Router, GNRS Server

36. GEC-13 Demo: Mobility & Multi-Homing in MF
Mobile, Multi-homed device (WiMAX + WiFi)
WiFi AP
WiMAX BTS
GENI Mesoscale
MobilityFirst Router hosted on Protogeni node
Rutgers Wireless Edge
WiFi coverage
WiMAX coverage

37. GENI 18 Demo: Wide-Area Deployment of MF
MF Routing and Naming Services deployed at 5 GENI rack sites with Internet2’s AL2S providing cross-site layer-2 connectivity
Rutgers and NYU Poly (with rack at NYU) routers connected to WiFi and WiMAX access networks
Android phones with WiFi/WiMAX connectivity ran MF stack and demo application (Drop It)
Wisconsin GENI rack
Utah GENI rack
BBN GENI rack
GENI Internet2 Core
GENI Edge
WiMAX BTS
WiMAX BTS
MobilityFirst Software Router with GNRS instance
Dual interface Android phone with WiFi/WiMAX with MF protocol stack
ORBIT radio node with WiFi as MF Access point
11/24/2018
WINLAB, Rutgers University

38. GEC-21 Demo: In-Network Computing Feature in MF
Sample “mobile cloud” service scenario:
Adaptive media transcoding via MF compute layer
Name-based anycast service via MF routing
Low Res HD
User1
Internet
Mid
Mid
User2
Original source
Media transcoding
via MF compute layer

39. Resources Project website: http://mobilityfirst.winlab.rutgers.edu
GENI website:
ORBIT website: