Architecture WINLAB Research Review Dec 4, 2015 D. Raychaudhuri - - PowerPoint PPT Presentation

Next-Generation Mobile Network Architecture WINLAB Research Review Dec 4, 2015

• D. Raychaudhuri

WINLAB, Rutgers University ray@winlab.rutgers.edu

Introduction

WINLAB

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:

Mobile Data (cellular, hetnet) Vehicular Networks Content Delivery Cloud Services Internet-of-Things Emergency Networks

WINLAB

Introduction: Why 5G Needs a New Network Architecture



Hybrid 3GPP & IP arch



Complex control interfaces!



Technology specific



IP tunneling in data path



Gateways (..bottlenecks, sub-

• ptimum routing,..)

SGW MME PGW MSC PCRF HSS

4G Radio Access Network Internet

WAG AAA LTE WiFi

Mobility-Centric Future Internet Architecture

LTE w/FIA interface WiFi w/FIA interface Standard FIA Router FIA Distributed Control Plane



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

TODAY 5G/NGMN/FIA

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

 Need to think beyond the “G”’s, associated with

linear progression in mobile systems

 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!

Research Target of NSF Future Internet Architecture (FIA) MobilityFirst Project

Wireless Technology Trend “5G” Internet Technology Trend “FIA” Future “Mobile Internet” New wireless/mobile functions, enhanced security, services Higher speeds/scale, “network of networks” Same end users!

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, …

TP FIA IP+ xG PHY xG MAC xG MAC xG PHY DLC PHY DLC TP PHY DLC FIA IP+ FIA IP+ FIA IP+ FIA IP+ PHY

UE BS/AP Router Router Server Internet Protocol Future Internet Protocol with Integrated Mobility Support Custom Access Protocols

Radio access specific

TODAY 5G/NGMN/FIA

Next-Gen Mobile Network Requirements

WINLAB

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

INTERNET

AS99 (LTE) AS2

User/Device Mobility

AS49 AS39 (WiFi )

Inter-AS Roaming Agreement  “Mobile Peering” 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

INTERNET

Wireless Access Net #3 Wireless Access Network #2

BS-1 AP-2

Mobile devices with varying BW due to SNR variation, Shared media access and heterogeneous technologies Time

Disconnection interval Bit Rate (Mbps) Dis- connect AP-2 BS-1

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

INTERNET

Session level Multicast Overlay (e.g. PIM-SIM)

Wireless Access Net #11

INTERNET

Access Network (Eithernet)

Radio Broadcast Medium

Packet-level Multicast at Routers/AP’s/BSs

RP

Wireless Access Net #32

Pkt Mcast at Routers

WINLAB

Wireless Access Net #3

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

INTERNET

Wireless Access Net #3 Wireless Access Network #2

LTE BS WiFi AP

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”

• r “deliver on all interfaces”

Mobile device With dual-radio NICs 60 Ghz BS (supplement to LTE) Multiple Potential Paths

WINLAB

Next-Gen Network Requirements: (5) Efficient Content Delivery

Content Owner’s Server

In-network cache

Get (“content_ID”) Send(“content_ID”, “user_ID”))

In-network cache Alternative paths for retrieval

• r 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, ..)

WINLAB

 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

Mobile Device trajectory

Context = geo-coordinates & first_responder Send (context, data)

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

Next-Gen Network Requirements: (6) Context-Aware Services

WINLAB

Next-Gen Network Requirements: (7) Edge Cloud Services

User Mobility

Edge Cloud Service A Edge Cloud Service B “Nearest” Cloud Service Low latency, dynamic migration

Mobile Internet

Access Network A Access Network B

 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

Get(“service_ID, data)

WINLAB

Access Network

)

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

INTERNET

Access Network

) V2V Network V2I

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

From today’s connection oriented IP services (“pipes”) … To more general set of service abstractions  named objects, data

Open (IP_address, data) Get (service) service Send (names, data)

From Vision to Proof-of- Concept Realization: MobilityFirst Architecture

WINLAB

MobilityFirst Design: Architecture Features

Routers with Integrated Storage & Computing Heterogeneous Wireless Access End-Point mobility with multi-homing In-network content cache Network Mobility & Disconnected Mode Hop-by-hop file transport

Edge-aware Inter-domain routing

Named devices, content, and context

11001101011100100…0011 Public Key Based Global Identifier (GUID)

Storage-aware Intra-domain routing Service API with unicast, multi-homing, mcast, anycast, content query, etc.

Strong authentication, privacy

Ad-hoc p2p mode

Human-readable name

Connectionless Packet Switched Network with hybrid name/address routing

WINLAB

MF Design: Protocol Stack

IP Hop-by-Hop Block Transfer

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

GSTAR Routing MF Inter-Domain E2E TP1 E2E TP2 E2E TP3 E2E TP4 App 1 App 2 App 3 App 4 GUID Service Layer

Narrow Waist

GNRS MF Routing Control Protocol NCS

Name Certification & Assignment Service Global Name Resolution Service

Data Plane Control Plane

Socket API

Switching Option

Optional Compute Layer Plug-In A

WINLAB

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

Globally Unique Flat Identifier (GUID)

John’s _laptop_1 Sue’s_mobile_2 Server_1234 Sensor@XYZ Media File_ABC Host Naming Service Network Sensor Naming Service Content Naming Service

Global Name Resolution Service

Network address Net1.local_ID Net2.local_ID Context Naming Service Taxis in NB

WINLAB

MF Design: Hybrid GUID/NA Storage Router in MobilityFirst

GUID-Address Mapping – virtual DHT table NA Forwarding Table – stored physically at router GUID NA 11001..11 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 Port 5, NA11

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

DATA DATA

 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

WINLAB

MF Protocol Example: Mobility Service via Name Resolution at Device End-Points

MobilityFirst Network (Data Plane) GNRS

Register “John Smith22’s devices” with NCS GUID lookup from directory GUID assigned GUID = 11011..011 Represents network

• bject with 2 devices

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

GUID <-> NA lookup NA99 NA32 GNRS update (after link-layer association)

DATA

SID NAs Packet sent out by host GNRS query GUID

Service API capabilities:

• send (GUID, options, data)

Options = anycast, mcast, time, ..

• get (content_GUID, options)

Options = nearest, all, ..

Name Certification Services (NCS)

WINLAB

MF Protocol Example: Handling Disconnection

Data Plane

Send data file to “John Smith22’s laptop”, SID= 11 (unicast, mobile delivery)

NA99 NA75 Delivery failure at NA99 due to device mobility Router stores & periodically checks GNRS binding Deliver to new network NA75 when GNRS updates

GUID NA75

DATA

GUID NA99  rebind to NA75

DATA DATA

GUID SID

DATA

SID GUID NA99

Device mobility Disconnection interval

Store-and-forward mobility service example

WINLAB

MF Protocol Example: Dual Homing Service

Data Plane

Send data file to “John Smith22’s laptop”, SID= 129 (multihoming – all interfaces)

NA99 NA32

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

DATA

GUID NetAddr= NA99

DATA DATA

GUID SID

DATA

SID GUID= 11001…11 NA99,NA32

DATA

Multihoming service example

WINLAB

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

Example Dual-Homing Result for MF: Cellular LTE + WiFi Performance

• 122.43
• 122.42
• 122.41
• 122.4
• 122.39
• 122.38
• 122.37

37.77 37.775 37.78 37.785 37.79 37.795 37.8 Longitude Latitide Free Wi-Fi hotspots (AT&T HotSpot Locator)

Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing 1 2 3 4 5 10 20 30 40 50 60 70 Average throughput per sec (in Mbps) Cab no. 1 2 3 4 5 10 20 30 40 50 60 70 Cab no. Maximum throughput per sec (in Mbps) Using only LTE Using the best available Wi-Fi Using all the available WiFis Using all the Wi-Fis and LTE Only Wi-Fi does not help

• n an average

Dual-Homed Mobile Device (WiFI + LTE)

WINLAB

MF Proof-of-Concept Prototype: Click Software Router and Android API

12/9/2015 WINLAB, Rutgers University 26

26

Click-based MF Router

• Storage-aware routing (GSTAR)
• Name resolution (GNRS)
• Reliable hop-by-hop link transport (Hop)

Android/Linux MF Protocol Stack

• Network API
• Hop transport
• Dual homing (WiFi/WiMAX)

WiMAX BTS WiFi AP

Native, user-level implementation

• n Android

runtime

MF Router

MF Router MF Router

WINLAB

MF Proof-of-Concept: Deployment on GENI

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 NL R

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

Concluding Remarks

WINLAB

Concluding Remarks: 5G and the Next-Gen Mobile Network Architecture

5G Radio

Wideband Cognitive Radio Programmable OpenFlow SDN Switch Multi-Radio Android Device

Next-Gen Network

60 Ghz 802.11ad

“5G” Enabling Technologies

 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 ….

Open LTE

??

Historic opportunity & risk for wireless and networking industries!

WINLAB

Concluding Remarks: 5G Architecture Concept based on SDN, Cloud, ..

 5G architecture driven by innovations in network & cloud technologies:

 Fundamentally new approaches to both 5G radio access and core network design

(clean slate Internet, SDN, CRAN, SDR, Open LTE, NFV, …)

 Open API, software realization makes it easier to introduce new radio access and core

network functionality

 Potential to preempt top-down ITU/IMT-2020 standards process for 5G….

Future Internet Protocols with Integrated Mobility Support Open LTE (4G) Or New 5G Base Station Open WiFi Access Point Open, Programmable Router “Cloud RAN” Servers Running 5G Mobile Apps/NFV CRAN radio heads Virtual Network “Slices” customized to

• perators/applications

“Edge Cloud: computing Services integrated with access network

30

WINLAB

Resources

 Project website: http://mobilityfirst.winlab.rutgers.edu  GENI website: www.geni.net  ORBIT website: www.orbit-lab.org