Mobile Edge Cloud Services in 5G Yanyong Zhang WINLAB, Rutgers - - PowerPoint PPT Presentation

Mobile Edge Cloud Services in 5G

Yanyong Zhang

WINLAB, Rutgers University yyzhang@winlab.rutgers.edu

MOTIVATION

Edge clouds, edge applications

WINLAB

Mobile Edge Clouds

WINLAB

Edge Applications

 Field machine control  Emergency stop

Smart Factory Emergency Service

 AR navigation  Automatic translation  Automatic driving  Real-time alert

Safety

Mobile Edge Cloud Services Scalability for devices and objects Real-time response

WINLAB

Object GUID Valu e 1 X1 2 X2 … … 10^12 Object GUID Valu e 1 X1 2 X2 … … 10^12

Challenges

Cloud (1) Sensing (2) Computation (2) Computation (3) Actuation

Response

Object ID Valu e 1 X1 2 X2 … … 10^12

Query

• Device/Object ID
• Sensed data
• Actuation command

Distributed, Parallel, and Pipelined Computation Multi-sensory fusion

Network domain

. . .

Large # of NW domains Data- Intensive

<100msec response time in application <100msec response time in application Trillion-order edge devices & objects are properly handled Trillion-order edge devices & objects are properly handled

 Scale  Real-time  Terminal Mobility

Service Directories

 Complexity

SMART-EDGE

Network virtualization, ASR, task mapping, spatial and temporal scheduling

WINLAB

SmartEdge Vision

WINLAB

Global Name Resolution

 Globally unique name

(GUID) for network attached

• bjects

 device, content, context, AS name,

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

Mobility Service via Name Resolution

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)

Overview of Virtual Mobile Cloud Network (vMCN)

ID

Query Packet

(2) VN & vBS on the move (3) Service Anycast & Dynamic Migration VN Routing layer Name resolution layer Virtual base station (vBS) smartEdge slice (1) Name-based virtual network

(3) GNRS Service Plane

GUID Locator VN Type A1 19 No VNID_1 VR1, VR2, … Yes VR1 1a Yes VR2 1b Yes

Network 19 Network 53a

A1 A2 B1 S VR1 VR2 VR3 VR5 VR6  (1) Virtual GUID as an identifier of a VN  (2) Ingress router identifies VNs  (3) GNRS is exploited to capture VN membership and access control  (1) Virtual GUID as an identifier of a VN  (2) Ingress router identifies VNs  (3) GNRS is exploited to capture VN membership and access control Central Coordinator (2) Ingress Router (1)

MF Extended to Support VN

vBS: A Technique of Building a Service-specific VN in WiFi



Isolated BS resources assigned to a target service



Network-driven association and handover



Cooperative NW virtualization in backhaul



Isolated BS resources assigned to a target service



Network-driven association and handover



Cooperative NW virtualization in backhaul

Virtual BS (vBS)

Physical BS vBS 1 vBS 2 vBS 3

• K. Nakauchi and Y. Shoji, “WiFi Network Virtualization to Control the Connectivity of a

Target Service,” IEEE Transactions on Network and Service Management, June, 2015

Elastic QoS Unified Policy Controllability BS Resource Pool

The other services

Application-Specific Routing

Network 19 Network 53a

A1 A2 B1 S

Service Y

DST_ GUID

<App, Link, N_Hop>

A1 <0.2, 5x, VR2> A2 <0.7, 5x, VR2> B1 <0.3, 3x, VR3> S <0, 1, S>

Virtual Routing table @ VR1

VR1 VR2 VR3 VR5 VR6  Service GUID is assigned to a group of replicated servers  Application-level metric is used for routing decision  Application state is periodically announced  computation load, waiting time, etc.  Service GUID is assigned to a group of replicated servers  Application-level metric is used for routing decision  Application state is periodically announced  computation load, waiting time, etc.

WINLAB

Edge Cloud Assignment – Spatial Scheduling



An edge application consists of a sequence of requests



each having a deadline and demanding a certain amount of resource



Each edge cloud periodically exposes its available resources



CPU utilization, data set, pending workload,



Then we pick one that can satisfy the real-time constraint; if no server is qualified, we consider migrating existing requests (without violating their deadlines)



Delayed scheduling



Migration may be needed due to user mobility



Mobility prediction

WINLAB

Parallel, Distributed, and Pipelined Execution

WINLAB

Efficient Runtime Management



Data shipping or computation shipping?



Approximate computing to hide network latency



Co-scheduling across multiple sites

PROTOTYPING & EVALUATION

WINLAB

Initial Prototype

Service GUID 1331 VNCS & OFS & MM MF Central Coordinator vBS

172.21.0.254

NA: 172.21/16 Locator: XX NA: 172.25/16 Locator: YY NA: 172.27/16 Locator: ZZ

VR1 VR2 Non-CPS/CPS Traffic Generator

vBS Prototype vBS Prototype MF-VN Prototype MF-VN Prototype

VR3 CPS Terminal (MF-enabled)

Python script GUID 21

Cloud Server1 Cloud Server2

GUID 22

vBS vBS MobilityFirst MobilityFirst

 vBS remote control software is implemented in the MF stack  Common C-plane for MF and vBS  Written in Python  vBS remote control software is implemented in the MF stack  Common C-plane for MF and vBS  Written in Python

WINLAB

90%ile Response Time Measured

CDF Response Time (RTT)

Before After

vBS only vBS&MF w/o vBS&MF

MF VN MF VN

APP-level Query & Response (mfping)

Response Time

T=t0 T=t1 90%

90%ile Response Time

query response

• Mode:

802.11n/a

• Band:

5GHz

• Tx Rate: 65Mbps
• Rx Rate: 65Mbps
• # of BS: 2 (Ch 36,48)

vBS vBS

• Routing: ASR
• Reporting interval: 2s
• Transport: hop-by-hop

reliability

• Retrans. limit:

unlimited

• Retrans. timeout: 200ms

MF-VN MF-VN

WINLAB

WiFi Congestion &Dynamic Server Load

20

MF VN MF VN

Server#1 Non-CPS terminals CPS Terminals BS#1 Server#2

Isolated for a specific CPS app Isolated for a specific CPS app Forwarded to the closest server even if the load is high Forwarded to the closest server even if the load is high Shared and competed b/w CPS and Non- CPS apps Shared and competed b/w CPS and Non- CPS apps Forwarded to less-loaded server Forwarded to less-loaded server

With vBS Without vBS With ASR Without ASR

MF VN MF VN

Server#1 BS#1 Server#2 Non-CPS terminals CPS Terminals

1.

T

Server Load

0. 2

T

Server Load

1.

T

Server Load

0. 2

T

Server Load

Before After

WINLAB

Reduction of 90%ile Response Time from 1900ms to 210ms

Emulated cloud app with 50KB Data, w/ Server Load and WiFi Cross Traffic

w/ vBS & ASR w/o vBS & w/o ASR 90%ile

0.24 0.64

214ms 1932ms 100

Due protocol Due to retransmission s and the potential bogus state in the MF transport protocol

vBS&ASR

WINLAB

Questions & Answers