5G Network Architecture and the Future Mobile Internet IEEE 5G Workshop Princeton, May 26, 2015 D. Raychaudhuri WINLAB, Rutgers University ray@winlab.rutgers.edu
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 TODAY PCRF 5G/NGMN/FIA LTE SGW PGW Internet LTE w/fia interface Mobility-Centric Future Internet Architecture 4G Radio Access Network HSS MME MSC Standard FIA Router WiFi WAG AAA Hybrid 3GPP & IP arch Complex control interfaces! Technology specific IP tunneling in data path Gateways (..bottlenecks, suboptimum routing,..) WiFi w/fia interface WINLAB 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
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! Wireless Technology Trend 5G Internet Technology Trend FIA Higher speeds/scale, network of networks New wireless/mobile functions, enhanced security, services Same end users! Future Mobile Internet 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, TODAY 5G/NGMN/FIA UE TP FIA IP+ xg MAC xg PHY BS/AP Router Router FIA IP+ FIA IP+ FIA IP+ xg MAC xg PHY DLC PHY DLC PHY Server TP FIA IP+ DLC PHY Custom Access Protocols Internet Protocol Radio access specific Future Internet Protocol with Integrated Mobility Support WINLAB
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 Inter-AS Roaming Agreement Mobile Peering AS39 (WiFi ) INTERNET AS99 (LTE) 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 BS-1 Bit Rate (Mbps) BS-1 Disconnect AP-2 Wireless Access Net #3 INTERNET Disconnection interval Time Wireless Access Network #2 AP-2
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 Session level Multicast Overlay (e.g. PIM-SIM) Packet-level Multicast at Routers/AP s/bss Pkt Mcast at Routers Wireless Access Net #11 INTERNET RP Access Network (Eithernet) INTERNET 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 INTERNET Wireless Wireless Access Net #3 Access Net #3 LTE BS 60 Ghz BS (supplement to LTE) Wireless Access Network #2 WiFi AP Mobile device With dual-radio NICs Multiple Potential Paths
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
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 ba123 341x NA1:P7, NA1:P9, NA2,P21,.. Context-based Multicast delivery Mobile Device trajectory
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 A Access Network B Edge Cloud Service B 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 INTERNET Access Network V2I ) ) V2V Network WINLAB
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,.. Open (IP_address, data) From today s connection oriented IP services ( pipes ) To more general set of service abstractions named objects, data Send (names, data) Get (service) service
From Vision to Proof-of- Concept 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) End-Point mobility with multi-homing Heterogeneous Wireless Access Routers with Integrated Storage & Computing In-network content cache Service API with unicast, multi-homing, mcast, anycast, content query, etc. 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 Name Certification & Assignment Service NCS Socket API 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 Hop-by-Hop Block Transfer MF Inter-Domain Switching Option IP 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 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 Sue s_mobile_2 Network address Net1.local_ID John s _laptop_1 Host Naming Service Server_1234 Sensor Naming Service Sensor@XYZ Media File_ABC Globally Unique Flat Identifier (GUID) Network Content Naming Service Global Name Resolution Service Net2.local_ID WINLAB Context Naming Service Taxis in NB
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) Look up GUID-NA table when: - no NAs in pkt header - encapsulated GUID - delivery failure or expired NA entry GUID-Address Mapping virtual DHT table GUID NA 11001..11 NA99,32 To NA11 DATA DATA To NA51 Router Storage Store when: - Poor short-term path quality - Delivery failure, no NA entry - GNRS query failure - etc. GUID= 11001 11 SID NA99,NA32 Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry NA Forwarding Table stored physically at router Dest NA NA99 NA62 NA32 Port #, Next Hop Port 5, NA11 Port 5, NA11 Port 7, NA51 Network Address Based Forwarding (fast path) DATA WINLAB
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,.. GUID lookup from directory Name Certification Services (NCS) Register John Smith22 s devices with NCS GUID assigned MobilityFirst Network (Data Plane) NA99 GNRS update (after link-layer association) Send (GUID = 11011..011, SID=01, data) NA32 GUID <-> NA lookup GNRS query GNRS GUID = 11011..011 Send (GUID = 11011..011, SID=01, NA99, NA32, data) 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 GUID DATA 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 Data Plane NA75 Disconnection interval Device mobility DATA DATA GUID SID NA99 DATA GUID NA75 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 Router bifurcates PDU to NA99 & NA32 (no GUID resolution needed) GUID DATA NetAddr= NA99 NA99 Data Plane NA32 DATA DATA GUID= SID 11001 11 NA99,NA32 DATA GUID NetAddr= NA32 GUID SID Send data file to John Smith22 s laptop, SID= 129 (multihoming all interfaces)
Latitide Average throughput per sec (in Mbps) Maximum throughput per sec (in Mbps) WINLAB 37.8 37.795 37.79 Example Dual-Homing Result for MF: Cellular LTE + WiFi Performance Free Wi-Fi hotspots (AT&T HotSpot Locator) 70 60 50 Using only LTE Using the best available Wi-Fi Using all the available WiFis Using all the Wi-Fis and LTE 70 60 50 37.785 40 40 37.78 37.775 30 30 37.77-122.43-122.42-122.41-122.4-122.39-122.38-122.37 Longitude 20 10 Only Wi-Fi does not help on an average 20 10 Simulation of San-Francisco cabs for Wi-Fi /LTE dual-homing Dual-Homed 0 Mobile Device (WiFI + LTE) 1 2 3 4 5 Cab no. 0 1 2 3 4 5 Cab no. 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
MF Proof-of-Concept Prototype: Click Software Router and Android API 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) Native, user-level implementation on Android runtime MF Router WiFi AP MF Router 26 MF Router WiMAX BTS 5/26/2015 WINLAB, Rutgers University 26 WINLAB
MF Proof-of-Concept: Deployment on GENI NL R Lincoln, NE Madison, WI Ann Arbor, MI Cambridge, MA Tokyo, Japan Palo Alto, CA Salt Lake, UT N. Brunswick, NJ Los Angeles, CA I2 Atlanta, GA Clemson, SC 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 Long-term (non- GENI) 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. Open LTE 5G Radio 60 Ghz 802.11ad?? Wideband Cognitive Radio Multi-Radio Android Device Next-Gen Network 5G Enabling Technologies Programmable OpenFlow SDN Switch Historic opportunity & risk for wireless and networking industries! WINLAB
WINLAB Resources Project website: http://mobilityfirst.winlab.rutgers.edu GENI website: www.geni.net ORBIT website: www.orbit-lab.org