Cellular-Internet Convergence: Evolving the Internet Architecture to Support Mobility Services as the Norm Johannesburg Summit May 20-21, 2013

Size: px

Start display at page:

Download "Cellular-Internet Convergence: Evolving the Internet Architecture to Support Mobility Services as the Norm Johannesburg Summit May 20-21, 2013"

Alan Morgan
5 years ago
Views:

1 Cellular-Internet Convergence: Evolving the Internet Architecture to Support Mobility Services as the Norm Johannesburg Summit May 20-21, 2013 D. Raychaudhuri, Rutgers University

2 Introduction

Introduction: Mobility as the key driver for the future Internet Historic shift from PC s to mobile computing and embedded devices Cisco VNI report predicts smartphone traffic alone will grow by ~10x

3 Introduction: Mobility as the key driver for the future Internet Historic shift from PC s to mobile computing and embedded devices Cisco VNI report predicts smartphone traffic alone will grow by ~10x by 2017, accounting for 7.5 Exabytes/mo; M2M services also taking off Mobile devices as a whole will dominate Internet usage wired devices will contribute only 39% of traffic by 2016 Motivates efficient integration of cellular nets with IP in short term, and reevaluation of Internet architecture to support general mobility requirements in long-term

Introduction: Industry Approach Towards Flat IP Architecture for Mobile Networks Cellular network standards (3GPP, LTE) have steadily migrated towards tighter integration with IP From centralized

4 Introduction: Industry Approach Towards Flat IP Architecture for Mobile Networks Cellular network standards (3GPP, LTE) have steadily migrated towards tighter integration with IP From centralized controllers and gateways to flat architectures Separation of control and data planes all IP in LTE Still requires some gateways, e.g. MME and SGW Figure from: Cisco White Paper: Evolution of the Mobile Internet 2010

5 Introduction: Cellular and Internet Technology Evolution Trend Opportunity for greater convergence of Internet and cellular/mobile network standards Service-Level Cellular Technologies MMS Android Services Mobile Cloud Services 5G Arch?? Core Cellular Network Technologies GSM Mobile Netw ork 3GPP 3GPP2 (IP-based) Flat IP-based LTE SDR, Open BTS Core Internet Technologies ~1975 ~1990 ~2000 ~2010 Basic IP Addressing & Routing BGP/CIDR Inter-Domain Routing Mobile IP IPv6 HIP LISP Etc.. Mobility Ext SDN/ Virtual Net?? Future Internet Protocol ~2020 VOIP/SIP ICN, FIA Service-Level Internet Technologies Web Services CDN Open DNS Cloud Services

Introduction: Next-Steps Towards Cellular- Internet Convergence Truly flat future IP architecture under consideration No gateways mobility functionality distributed between routers/bss/aps running

requirements, not limited to simple device mobility e.g.

6 Introduction: Next-Steps Towards Cellular- Internet Convergence Truly flat future IP architecture under consideration No gateways mobility functionality distributed between routers/bss/aps running the same control and data protocols; standard mobility & service control API s Multiple radio access technologies simply plug-in to universal mobile Internet Generalized view of mobility service requirements, not limited to simple device mobility e.g. multicast, content addressability, context delivery, Enhanced Packet Core (Operator Network) MME SGW To/From Global Internet Standard IP Router futureip Inter-Domain Router Operator Network Running future IP Protocols Edge Networks with Mobility Services Future IP control plane w/ mobility support futureip Intra-Domain Router RAN B RAN C RAN A RAN A RAN Net B

7 Mobility Requirements: Supporting Device Migration as Basic Service 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 dynamic handoff/roaming in cellular networks Mobility service should be scalable (billions of devices) and fast ~ ms Wireless Access Net #3 INTERNET Wireless Access Netw ork #2 BS2 User/Device Mobility

8 Mobility Requirements: Handling BW Variation & Disconnection Wireless medium has inherent fluctuations in bit-rate (as much as 10:1 in 3G/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 Wireless Access Netw ork #2 Disconnection interval Time AP-2

9 Mobility Requirements: Multicast as a Basic Network 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 Netw ork (Eithernet) INTERNET Wireless Access Net #32 Radio Broadcast Medium

10 Mobility Requirements: Multi-Homing as a Standard Service Multiple/heterogeneous radio access technologies (e.g. 3G/4G and WiFi) increasingly the norm Implies the need for separating identity from locators (network addresses) Requires routing framework that supports packet level multicasting where needed for efficient delivery to multiple networks Support for alternative routing policies best path, all paths, etc. 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 LTE BS Wireless Access Net #3 INTERNET Wireless Access Netw ork #2 WiFi AP Mobile device With dual-radio NICs

11 Mobility Requirements : Multi-Network Access, Multipath 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 Wireless Access Net #1 BS-1 Wireless Access Network Wireless Access Net #3 BS-2 INTERNET Access Netw ork (Eithernet) Ethernet NiC INTERNET Wireless Edge Netw ork AP1 BS-3 Multiple Potential Paths Multi Radio NIC s

12 Mobility Requirements: Content Retrieval & Delivery Capabilities Delivery of content to/from mobile devices a key service requirement in future networks 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 )

Mobility Requirements: Supporting Context-Aware/M2M Services Context-aware delivery often associated with mobile services Examples of context are group membership, location, network state, Requires

13 Mobility Requirements: Supporting Context-Aware/M2M 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 Nam ing Service Context GUID Global Name Resolution service ba x NA1:P7, NA1:P9, NA2,P21,.. Context-based Multicast delivery Mobile Device trajectory

14 Mobility Requirements: Ad Hoc & Network Mobility 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 Access Network INTERNET Access Network ) )

setting of radio resource parameters across independent access networks WiFi AP locations in a 0.4x0.5 sq.

15 Mobility Requirements: Spectrum Coordination as a Network Service 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

16 MobilityFirst Protocol Design

17 Designing a Mobility-Centric Internet Emerging mobile applications, M2M devices, V2V networks etc. involve more than simple device mobility support from the network Some examples of services required are: Multi-homing, multi-path Efficient multicast Ad-hoc modes, DTN delivery Content mobility, caching Service mobility Context services, geo-location Enhanced authentication & trust In-network cloud services. Clients, Servers Embedded devices Network Transport Network Services Universal future IP protocols Mobility Service & Control API s (universal future IP standard) The MobilityFirst future Internet architecture (FIA) project is aimed at a clean-slate redesign of the IP stack & service/control API s to meet these and other anticipated requirements

MobilityFirst Design: Architecture Features Named devices, content, and context Human-readable name Strong authentication, privacy 11001101011100100 0011

In-network content cache Service API with unicast, multi-homing, mcast, anycast, content query, etc.

networks & network mobility - Multihoming, multipath, multicast - Content & context-aware services - Strong security/trust and privacy model

18 MobilityFirst Design: Architecture Features Named devices, content, and context Human-readable name Strong authentication, privacy 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. 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 Storage-aware Intra-domain routing Network Mobility & Disconnected Mode Edge-aware Inter-domain routing Hop-by-hop file transport Connectionless Packet Switched Network with hybrid name/address routing Ad-hoc p2p mode

19 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 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

20 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

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,

21 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 Netw ork address Net1.local_ID John s _laptop_1 Host Nam ing Service Server_1234 Sensor Nam ing Service Sensor@XYZ Media File_ABC Globally Unique Flat Identifier (GUID) Global Name Resolution Service Netw ork Content Nam ing Service Net2.local_ID Context Nam ing Service Taxis in NB

MF Design: Service Abstractions (1) MobilityFirst offers a named-object service API that supports mobility, disconnection, multi-homing, multicast in a natural way Replaces the point-to-point virtual

22 MF Design: Service Abstractions (1) MobilityFirst offers a named-object service API that supports mobility, disconnection, multi-homing, multicast in a natural way Replaces the point-to-point virtual link abstraction of IP Example: Sending to a mobile device with multiple interfaces IP Abstraction: Virtual Link MF Abstraction: Multi-homed Network Object Send(IP=X, data) Send(GUID=Y, data, options)..options for multi-homing & late binding NA=X1 NA=X2 NA=X3 Network IP Addr=X Interface Dest Device Name= MAC Static MAC=X binding Dynamic GUID NA bindings GUID=Y Network Attached Object e.g., Y may be a mobile device with 3 interfaces (WiFi & 2 cellular)

23 MF Design: Service Abstractions (2) Use of MF Service API for content retrieval and dynamic group multicast (..membership may be specified by context) MF Abstraction: Get Replicated Content Object MF Abstraction: Send to Group Object with Multicast reachability Get (Content_GUID=A, options)..option for shortest path Send (GUID=Z, data, options)..option for mcast delivery NA=X1 NA=X2 NA=X3 NA=X2 Broadcast Medium Content Object With GUID=A GUID=A GUID=A Group GUID = Z GUID1 GUID2 GUID3 e.g., A is a replicated content object at multiple network locations e.g., Z may be a context group of M2M devices or a cloud service

Building Mobile Networks with MF MobilityFirst enables

mobile networks Current Mobile Networks Planned

Centralized Mobility Support Homogeneous Topology

Network-of-Network s Ad-hoc Deployment Unlicensed

24 Building Mobile Networks with MF MobilityFirst enables both tightly and loosely coupled architectures for mobile networks Current Mobile Networks Planned Deployment Licensed Spectrum Fine-grained Managed QoS Centralized Mobility Support Homogeneous Topology Network-wide Authentication Loosely Coupled Network-of-Network s Ad-hoc Deployment Unlicensed Spectrum Coarse-grained Managed In-network Mobility Support Heterogeneous topology Authentication at APs

MF Protocol Example: Mobility Service via Name Resolution at Device End-Points Service API capabilities: - send (GUID, options, data) Options = anycast, mcast, time,.

25 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 = , SID=01, data) NA32 GUID <-> NA lookup GNRS query GNRS GUID = Send (GUID = , SID=01, NA99, NA32, data) Represents network object with 2 devices DATA GUID SID NAs Packet sent out by host

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

26 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) 1 Cumulative Distribution Function (CDF) K = 5, 95 th Percentile at 91 ms K = 1, 95 th Percentile at 202 ms K = 1 K = 2 K = 3 K = 4 K = ,000 Round Trip Query Latency in milliseconds (log scale) Internet Scale Simulation Results Using DIMES database

27 GNRS Scalability Results We did a trace driven simulation to assess scalability Question: How much load on GNRS if everyone driving in a given area uses MF for mobility management: Traces from Rutgers Intelligent Transportation Systems Lab: Captures peak time traffic of >16K vehicles in a ~8 sq.km urban area of Jersey CIty, NJ GNRS load not too high even for very frequent handovers and high density of vehicles 1 Cumulative Distribution Function (CDF) Cell Radius = 250 m 0.1 Cell Radius = 500 m Cell Radius = 750 m Number of Updates/second

BW/short disconnection) to DTN (longer disconnections) Storage has benefits for wired networks as well.

28 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 PDU Storage Router Re-routed path For delivery Mobile Device trajectory High BW WiFi link Sample CNF routing result

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:

29 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 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 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= SID NA99,NA32 NA Forwarding Table stored physically at router Dest NA Port #, Next Hop Look up NA-next hop table when: - pkt header includes NAs - valid NA to next hop entry NA99 NA62 NA32 Port 5, NA11 Port 5, NA11 Port 7, NA51 Network Address Based Forwarding (fast path) DATA

GNRS + Storage Routing Performance Result CDF Detailed NS3 Simulations to compare MF with TCP/IP Hotspot AP Deployment: Includes gaps and overlaps Cars move

4 between APs MF: d = 200 0.2 TCP/IP: d = 200 MF: Avg.

30 GNRS + Storage Routing Performance Result CDF 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) Empirical CDF of file transfer time d: Average distance 0.4 between APs MF: d = TCP/IP: d = 200 MF: Avg. d = 400 TCP/IP: d = File Transfer Time (sec) Total Data Received (MBits) Single Car: Aggregate Throughput vs.time TCP/IP-30miles/hr TCP/IP-50miles/hr TCP/IP-70miles/hr MF-30miles/hr MF-50miles/hr MF-70miles/hr Time (sec)

31 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 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)

32 LTE/WiFi HetNet Results: MF vs. TCP MF provides several benefits in a heterogeneous wireless environment: Seamless mobility across network domains via dynamic GUID-NA bindings Routers automatically store packets in transit during periods of disconnection Simultaneous use of multiple networks is also possible 1000 Aggregate Throughput with Time Aggregate Throughput (MBytes) Throughput boost due to transmission of stored packets TCP takes more time to re-start session (DHCP + Application reset) 100 MobilityFirst TCP/IP Time (sec)

33 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 NA99,NA32 DATA GUID NetAddr= NA32 GUID SID Send data file to John Smith22 s laptop, SID= 129 (multihoming all interfaces)

34 MF Multipath Performance Result Multipath service with data striping between LTE and WiFi Using backpressure propagation and path quality info

35 MobilityFirst Protocol Prototyping & Validation

MF Host Protocol Stack Socket API open send send_to recv recv_from close App-1 App-2 Network API App-3 Context API Context Services Linux PC/laptop with WiMAX & WiFi E2E Transport Network Layer GUID

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

multicast memberships Heuristic approaches to

buffering, and improve aggregate delivery

37 MF Click Software Router Lightweight, scalable multicast GNRS for maintenance of multicast memberships Heuristic approaches to reduce network load, limit duplicated buffering, and improve aggregate delivery delays Click prototype, with SID for multicast flows Evaluating hail a cab application as a example multipoint delivery scenario Multicast Inter-Domain (EIR) 37

GNRS lookup) Controllers interact with other controllers and network support services such as GNRS Flow

38 OpenFlow/SDN Implementation of MF Protocol stack embedded within controller Label switching, NA or GUID-based routing (incl. GNRS lookup) Controllers interact with other controllers and network support services such as GNRS Flow rule is set up for the remaining packets in the chunk based on Hop ID (which is inserted as a VLAN tag in all packets) E.g., SRC MAC = 04:5e:3f:76:84:4a, VLAN = 101 => OUT PORT = 16 MF Protocol Stack 38

evaluation of MobilityFirst delivery services on FLARE - 1Gbps, 10Gbps Augmented Click router elements compiled down

39 MF Router Prototype on FLARE SDN Platform from U Tokyo (Nakao) Objectives Multi-site deployment of MobilityFirst routing and name resolution services Impact of large RTTs on MobilityFirst network protocols High performance evaluation of MobilityFirst delivery services on FLARE - 1Gbps, 10Gbps Augmented Click router elements compiled down to FLARE native Evaluation of FLARE platform for design and evaluation of nextgeneration network protocols Demo at GEC-16, March 2013

experimentation with new network protocols Integrated with GENI control framework RF Module (

40 GENI 4G Access Deployment at Rutgers for Validation of 4G/WiFi Access Scenario Rt.1 campus deployment since 2009 Open Base Station with external SDN/VM controller enabling experimentation with new network protocols Integrated with GENI control framework RF Module ( sector) Open WiMAX in Phase 1 LTE in Phase 2 Base Module Omni-directional antenna (elev. < 6ft above roof!) Outdoor Unit (ODU) 40

41 MF Multi-Site GENI Deployment Demo at GEC-16, March 2013 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 MobilityFirst Routing and Name Resolution Service Sites MobilityFirst Access Net Long-term (non- GENI) Short-term Wide Area ProtoGENI ProtoGENI

42 Resources Project website: GENI website: ORBIT website:

Introduction. MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Euroview 2012 July 24,

Introduction. MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Euroview 2012 July 24, MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet Euroview 2012 July 24, 2012 D. Raychaudhuri, Rutgers University Technology Centre of NJ 671 Route 1, North