5 G Network Architecture and the Future Mobile

5 G Network Architecture and the Future Mobile Internet ACM Mobi. Arch 2016 Oct 3, 2016 D. Raychaudhuri WINLAB, Rutgers University ray@winlab. rutgers. edu

Introduction

Introduction: 5 G Vision n n 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 5 G Needs a New Network Architecture SGW LTE 5 G/NGMN/FIA PCRF TODAY PGW LTE w/FIA interface Internet MME 4 G Radio Access Network HSS Wi. Fi n n n Mobility-Centric Future Internet Architecture Standard FIA Router MSC WAG AAA Hybrid 3 GPP & IP arch Complex control interfaces! Technology specific IP tunneling in data path Gateways (. . bottlenecks, sub-optimum routing, . . ) FIA Distributed Control Plane Wi. Fi w/FIA interface n n n 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 n Historic shift from PC’s to mobile computing and embedded devices… ¨ Mobile data growing exponentially – 3. 6 Exabytes in 2014, >> wired Internet traffic Sensor/Io. T/V 2 V ~5 -10 B units by 2020 ¨ Internet in 2020 all about mobile platforms & services ¨ n 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! Wireless Technology Trend “ 5 G” Higher speeds/scale, “network of networks” ¨ Research Target of NSF Future Internet Architecture (FIA) Mobility. First Project Future “Mobile Internet” Internet Technology Trend “FIA” New wireless/mobile functions, enhanced security, services Same end users! WINLAB

Introduction: What a Converged Mobile Internet Protocol Would Look Like… n 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… ¨ 5 G 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, … ¨ 5 G/FIA/NGP TODAY BS/AP UE Router Server TP TP NGP IP+ x. G MAC DLC x. G PHY PHY NGP IP+ DLC PHY Radio access specific Next-Gen Internet Protocol with Integrated Mobility Support Internet Protocol Custom Access Protocols WINLAB

Next-Gen Network Requirements & Proposed Mobility. First Architecture

Next-Gen Network Requirements: Emerging Service Scenarios n Analysis of 5 G/Future Network Use Cases helps to identify requirements…. Embedded Io. T Devices In-Network Content Cache Context-Aware Multicast Cloud Service B Media & Content Server Cloud Migration Multi-Path, Multicast Edge Clouds Ad-Hoc Mode Mobile Network ) V 2 V Cluster Content Delivery Service anycast “nearest” cloud Cloud Service A Security & Privacy Cloud-Based Mobile Service Network Mobility Mobile Users Device Mobility Multi-Homed Device (e. g. Wi. Fi + LTE) Variable BW & Disconnections WINLAB

Next-Gen Network Requirements: Summary n n n Security related functions: authentication, data security, etc. Mobility related functions: end-point or 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

Named Objects: Key Concept for Next. Generation Mobile Internet Named services Named context Named mobile devices Named Content Named static entities Named network entities Named Io. T objects Named Objects can be used to support rich communication abstractions, both current and future Foundation of Mobility. First FIA architecture… WINLAB

Named Objects: Service Abstractions n Named Objects provide a flexible set of abstractions for building future communication services… Primary Abstraction in “Named Data Network: ” (NDN) ) Get (content_name) ) Send (ND, NS, data) Device Name Server Name Send (Net_Name, Device_Name, data) NAMED CONTENT SERVICE LATE BINDING VIRTUAL LINK (IP-LIKE) Service Name Get(Context_Group = Io. T Devices) Get(ND, Nservice) Service Name SERVICE ANYCAST Send (Context_Group = taxis in NB) CONTEXT MULTICAST OR IOT QUERY Send (ND, all_interfaces) Subscribe (application_service) MULTI-HOMED DEVICE PUB/SUB WINLAB

Mobility. First Architecture: Overview Named devices, content, and context Human-readable name Strong authentication, privacy 11001101011100100… 0011 Public Key Based Global Identifier (GUID) Heterogeneous Wireless Access End-Point mobility with multi-homing Data Plane Storage-aware Intra-domain routing Service API with unicast, multi-homing, mcast, anycast, content query, etc. Routers with Integrated Storage & Computing Edge-aware Inter-domain routing In-network content cache Hop-by-hop file transport Global Name Resolution Service (Control Plane) Network Mobility & Disconnected Mode Ad-hoc p 2 p mode WINLAB

MF Architecture: Protocol Stack Comparison n MF protocol is centered around the GUID service layer email, WWW, phone, … browser, chat, … Applications SMTP, HTTP, RTP, … File Stream, … End-to-End Transport TCP, UDP, … Security Computing Layer IP Content Name GUID Ethernet, PPP, … Strategy/Routing Control CSMA, async, sonet, … IP, UDP, PPP, … Hop-by-Hop Block Transfer copper, fiber, radio, … Link-layer protocol IP Network NDN Mobility. First 4/26/2016 Content Delivery in Mobility. First 13 WINLAB

MF Architecture: Protocol Stack App 1 App 2 App 3 App 4 E 2 E TP 3 E 2 E TP 4 Socket API Name Certification & Assignment Service NCS E 2 E TP 1 E 2 E TP 2 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) Control Plane Link Layer 2 (LTE) Narrow Waist Link Layer 3 (Ethernet) IP Switching Option Link Layer 4 (SONET) Link Layer 5 (etc. ) Data Plane WINLAB

Mobility. First Protocol Design

MF Design: GUIDs and Name Resolution n n Globally unique identifiers (GUID) used to define all network-attached objects Key design choice: flat identifier vs. hierarchical semantic identifier…. Mobility. First uses a flat public key as the GUID NDN uses domain name/hierarchical descriptor Sue’s phone John’s laptop Media file M Context C Host Naming Service Content Naming Service Context Naming Service Globally Unique Flat Identifiers Global Name Resolution Service Routers with integrated storage and computing Integrated storage and computing Hop-by-hop transport WINLAB

MF Design: Protocol Example for Mobility Service Based on GUID Name Resolution Service API capabilities: - send (GUID, options, data) Options = anycast, mcast, time, . . - get (content_GUID, options) Options = nearest, all, . . Register “John Smith 22’s devices” with NCS Name Certification Services (NCS) GUID assigned GUID lookup from directory NA 99 Mobility. First Network (Data Plane) Send (GUID = 11011. . 011, SID=01, data) GUID <-> NA lookup GNRS query Send (GUID = 11011. . 011, SID=01, NA 99, NA 32, data) GNRS update (after link-layer association) NA 32 GNRS GUID = 11011. . 011 Represents network object with 2 devices DATA GUID SID NAs Packet sent out by host WINLAB

MF Design: DHT-Based Global GNRS n 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 (95% ~100 ms); further reductions to ~20 ms achieved with hierarchy & caching ¨ Internet Scale Simulation Results Using DIMES database WINLAB

MF Design: Storage-Aware Routing Take advantage of cheap storage in the network (storage-aware routing) n ~10 GB, in-network storage ~1 TB, content caching Expands routing options Store and/or replicate as feasible routing options ¨ Enables “late binding” routing algorithms ¨ n ~100 MB, data in transit Hop-by-hop transport Large blocks reliably transferred at link layer ¨ Entire block can be stored or cached at each router ¨ Generalized Storage-Aware Routing • Actively monitor link qualities of network • Router store or forward decision based on: 1. Short and long term link qualities 2. Available storage along path 3. Connectivity to destination

MF Design: Edge-Aware Inter-Domain Routing (EIR) Protocol n EIR designed to better support new MF requirements such as late binding, multi-homing, edge peering, network mobility… Design based on a. Nodes and v. Links 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) WINLAB

MF Design: Mobility. First Router with Two. Level GUID/NA Forwarding n Hybrid name-address based routing in Mobility. First requires a new router design with in-network storage and two lookup tables: n n n “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 NA 99, 32 DATA To NA 11 Router Storage DATA SID GUID= 11001… 11 NA 99, NA 32 To NA 51 Store when: - Poor short-term path quality - Delivery failure, no NA entry - GNRS query failure - etc. NA Forwarding Table – stored physically at router Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry Dest NA Port #, Next Hop NA 99 Port 5, NA 11 NA 62 Port 5, NA 11 Port 7, NA 51 NA 32 Network Address Based Forwarding (fast path) DATA WINLAB

MF Protocol Example: Handling Disconnection Store-and-forward mobility service example DATA GUID NA 99 rebind to NA 75 Delivery failure at NA 99 due to device mobility Router stores & periodically checks GNRS binding Deliver to new network NA 75 when GNRS updates NA 99 Disconnection interval Data Plane Device mobility NA 75 DATA GUID NA 75 SID NA 99 DATA GUID Send data file to “John Smith 22’s laptop”, SID= 11 (unicast, mobile delivery) WINLAB

MF Service Example: Mobility Service Host mobility • • • Network mobility • • Vehicular mobility (50 mph) Opportunistic Wi-Fi + disconnection Web requests of size: U(10 KB-5 MB) Bus mobility modeled as a moving inter-domain entity Data delivery with late-binding 5 second improvement in median completion time 23 WINLAB

MF Protocol Example: Dual Homing Service Multihoming service example DATA Router bifurcates PDU to NA 99 & NA 32 (no GUID resolution needed) GUID Net. Addr= NA 99 Data Plane NA 32 DATA GUID Net. Addr= NA 32 SID GUID= 11001… 11 NA 99, NA 32 DATA GUID Send data file to “John Smith 22’s laptop”, SID= 129 (multihoming – all interfaces) WINLAB

MF Service Example: Dual-Homing Scenarios Het. Nets (Wi. Fi + LTE) Multi-Cellular Network WINLAB

MF Service Example: Named Object Multicast (NOMA) • Named-Object Multicast (NOMA) solution relies on separation of names and addresses obtained through a globally distributed Name Resolution Service • GNRS retains tree structure and via GUID indirection Source Gs GUID Mapping GMng Gd 1, Gd 2, . . . GMulti Gr 11 Gr 21, Gr 22 Gr 21 Gr 31, Gr 32 Gr 31 Gd 1, Gd 2 Gr 32 Gd 3, Gd 4 1 GNRS Plane used for management of tree information Previous Headers Src: Gs Dst: Gr 11 Gr 22 2 Gr 21 Gr 31 Gd 2 Destinati Src: Gs Dst: GM Payload 2 26 Packet tunneling used to traverse the tree Gr 32 Gd 4 Gd 3 ons Network A 1 3 Gr 11 GNRS Service Plane ons ti tina Des Previous Headers Src: Gr 11 Dst: Gr 21 Src: Gs Dst: GM Network B Payload WINLAB . . .

MF Service Example: Named Object Multicast (NOMA) – cont. • Service manager on the gateway node performs the tree computation and makes corresponding GNRS updates • No multicast specific control overhead need to be exchanged across networks avoiding explosion of control traffic with graph size 27 WINLAB

MF Service Example: Enabling Mobile CPS Applications via Service Anycast Name resolution layer Service Anycast & Dynamic Migration of Cloud Service: CPS slice • Application requirements support Name-based virtual network: VN Routing layer • Provides NFV services v. BS on the move • Virtualization of WIFI AP • SDN based backend • Goal: development and validation of advanced virtual networking techniques for scalable support of real-time/mobile CPS applications • Challenge: Low latency support requires fast access from mobile device to cloud service with bounded delay • Challenge: Optimal placement and dynamic migration of cloud services Joint project with K. Nakauchi, NICT, Japan under NSF’s US-Japan collaboration program (JUNO) WINLAB

MF Service Example: Virtual Network with Application Specific Routing (ASR) Decision Space / Threshold based DST_GUI D <App, Link, N_Hop> A 1 <0. 2, 5 x, VR 2> A 2 <0. 7, 5 x, VR 2> B 1 <0. 3, 3 x, VR 3> S <0, 1, S> Client requests are encapsulated in order to reach the first router belonging to the VN Distance Virtual Routing table @ VR 1 Region III <Distance Region IV <Compute Load Region I <Distance Region II <Compute Load Compute load Virtual Network to provide a framework to implement the abstract delivery service of anycasting not only based on network metrics. Threshold based algorithm currently implemented. End points participate in the control plane by providing metric updates. Native multicast delivery services are used to distribute the metric updates across the participating nodes. Service Y ORBIT Expt APP te Sta Network 19 VR 2 A 1 VR 6 VN A DAT S A 2 VR 1 VR 3 VR 5 Network 53 a WINLAB

MF Service Example: VN/ASR Response Time Experiments v. BS Mode: 802. 11 n/a Band: 5 GHz Tx Rate: 65 Mbps Rx Rate: 65 Mbps # of BS: 2 (Ch 36, 48) • Routing: ASR - Reporting interval: 2 s MF VN • Transport: hop-by-hop reliability APP-level Query & Response (mfping) Response Time - Retrans. limit: unlimited - Retrans. timeout: 200 ms response query T=t 1 T=t 0 Before After 90% CDF • • • MF-VN 90%ile Response Time v. BS&MF v. BS only w/o v. BS&MF Response Time (RTT) Goal: 90%ile Response Time under 100 ms Joint project with K. Nakauchi, NICT, Japan under NSF’s US-Japan collaboration program (JUNO) WINLAB

MF Service Example: VN/ASR Response Time Experiments (cont. ) 0. 94 0. 9 90 percentile response time at 80 ms. Up to 94% at less than 100 ms compared to 46% in the baseline scenario 0. 46 300 data units with 25 KB size are generated in this experiment 31 Joint project with K. Nakauchi, NICT, Japan under NSF’s US-Japan collaboration program (JUNO) WINLAB

Mobility. First Prototyping & Proof-of-Concept

MF Prototyping: 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 (Wi. Fi/Wi. MAX) - Native, user-level implementation on Android runtime Wi. Fi AP MF Router 33 12/1/2020 MF Router WINLAB, Rutgers University Wi. MAX BTS 33 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 I 2 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 started in 2016 Clemson, SC Mobility. First Routing and Name Resolution Service Sites Long-term (non. GENI) Short-term Mobility. First Access Net Proto. GENI Wide Area Proto. GENI WINLAB

Mobility. First Prototyping: Selected GENI demos n GENI has been an integral part of MF evaluation methodology since the project started in 2010 …. Content Delivery Scenario – GEC-12 Mobility with Dual-Homing – GEC-13 Video Delivery with In-Network Transcoding– GEC-21 Multi-Site Mobility Service Deployment – GEC-19 WINLAB

Concluding Remarks

Concluding Remarks: 5 G Architecture Concept based on SDN, Cloud, . . n 5 G architecture driven by innovations in network & cloud technologies: Fundamentally new approaches to both 5 G 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 ¨ Opportunity and challenge for standards processes to incorporate new capabilities such as name-based networking… “Cloud RAN” Servers ¨ Running 5 G Mobile Apps/NFV Future Internet Protocols with Integrated Mobility Support Open LTE (4 G) Or New 5 G Base Station Virtual Network “Slices” customized to operators/applications Open, Programmable Router Open Wi. Fi Access Point “Edge Cloud: computing Services integrated with access network CRAN radio heads 37 WINLAB

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