May 26, 2015 - Mobile data growing exponentially â 3.6 Exabytes in 2014 ... Any network connected object or device sho
5G Network Architecture and the Future Mobile Internet IEEE 5G Workshop Princeton, May 26, 2015
D. Raychaudhuri WINLAB, Rutgers University
[email protected]
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:
Vehicular Networks
Content Delivery Cloud Services
Mobile Data (cellular, hetnet)
Emergency Networks
Internet-of-Things
WINLAB
Introduction: Why 5G Needs a New Network Architecture SGW
LTE
5G/NGMN/FIA
PCRF
TODAY
PGW
LTE w/FIA interface
Internet MME
4G Radio Access Network HSS
WiFi
Mobility-Centric Future Internet Architecture
Standard FIA Router
MSC
WAG AAA
Hybrid 3GPP & IP arch Complex control interfaces! Technology specific IP tunneling in data path Gateways (..bottlenecks, suboptimum routing,..)
FIA Distributed Control Plane
WiFi w/FIA interface
Unified Internet/Mobile Net arch with integrated support for naming, authentication, mobility, etc. Simplified distributed control! Technology neutral –BS or AP plug-in 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 PC’s 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 network and Internet industries
Wireless Technology Trend “5G”
Higher speeds/scale, “network of networks”
Need to think beyond the “G”’s, associated with linear progression in mobile systems
Future “Mobile Internet”
Era of vertically integrated protocol stacks built on radio standards coming to an end Single end-to-end protocol standard for the future mobile Internet!
Internet Technology Trend “FIA”
New wireless/mobile functions, enhanced security, services 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
BS/AP
UE
Router
Router
Server TP
TP FIA IP+
FIA IP+
xG MAC xG PHY
FIA IP+
FIA IP+
FIA IP+
xG MAC
DLC
DLC
DLC
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
AS99 (LTE)
AS39 (WiFi )
Inter-AS Roaming Agreement “Mobile Peering”
INTERNET 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 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
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/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
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
Wireless Access Net #3 Wireless Access Net #3
60 Ghz BS (supplement to LTE)
INTERNET
Wireless Access Network #2
WiFi AP
Multiple Potential 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 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
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 Service Context GUID
Global Name Resolution service
NA1:P7, NA1:P9, NA2,P21, .. ba123 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 Service A
Access Network B
Edge Cloud Service B
Access Network 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, innetwork 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, contextspecified dynamic multicast, in-network caching, … In-network processing (optional): media transcoding, cloud services, data aggregation, .. service
From today’s connection oriented IP services (“pipes”) …
To more general set of service abstractions named objects, data
Get (service)
Send (names, data) Open (IP_address, data)
WINLAB
From Vision to Proof-ofConcept Realization: MobilityFirst Architecture
MobilityFirst Design: Architecture Features Named devices, content, and context Human-readable name
Strong authentication, privacy 11001101011100100…0011 Public Key Based Global Identifier (GUID)
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
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
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
User name, device ID, content, context, AS name, and so on Multiple domain-specific naming services
Server_1234
John’s _laptop_1
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: 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
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 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
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
Example Dual-Homing Result for MF: Cellular LTE + WiFi Performance 37.8
70
37.795
Average throughput per sec (in Mbps)
60
37.79
Latitide
70 Using only LTE Using the best available Wi-Fi Using all the available WiFis Using all the Wi-Fis and LTE
37.785
37.78
37.775
37.77 -122.43
-122.42
-122.41
-122.4 Longitude
-122.39
-122.38
Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing
-122.37
50
40
30
20
Only Wi-Fi does not help on an average
10
Dual-Homed 0 Mobile Device (WiFI + LTE)
60
Maximum throughput per sec (in Mbps)
Free Wi-Fi hotspots (AT&T HotSpot Locator)
50
40
30
20
10
1
2
3 Cab no.
4
5
0
1
2
3 Cab no.
4
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
5
MF Proof-of-Concept Prototype: Click Software Router and Android API Click-based MF Router
Android/Linux MF Protocol Stack
Storage-aware routing (GSTAR) - Name resolution (GNRS) - Reliable hop-by-hop link transport (Hop)
- Network API - Hop transport - Dual homing (WiFi/WiMAX)
-
Native, user-level implementation on Android runtime
WiFi AP
MF Router MF Router
26 5/26/2015
MF Router WINLAB, Rutgers University
WiMAX BTS 26
WINLAB
MF Proof-of-Concept: Deployment on GENI 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
MF Services Demonstrated on GENI: Multi-Homing Mobile Named Content Delivery In-network Compute Service Context-Aware Message Delivery Edge-Aware Inter-Domain Routing Global Name Resolution … and others Early adopter trials starting in 2015
MobilityFirst Routing and Name Resolution Service Sites MobilityFirst Access Net
Clemson, SC
Long-term (nonGENI) Short-term Wide Area ProtoGENI ProtoGENI
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
“5G” Enabling Technologies
Programmable OpenFlow SDN Switch
Historic opportunity & risk for wireless and networking industries!
WINLAB
Resources
Project website: http://mobilityfirst.winlab.rutgers.edu
GENI website: www.geni.net
ORBIT website: www.orbit-lab.org
WINLAB
