part i: overview of fog computing and networking
TRANSCRIPT
Radio Access Network Design for 5G IoT: A Fog Computing
Approach
Hung‐Yu Wei
National Taiwan University
2
Part I: Overview of Fog Computing and Networking
Cloud V.S. Fog
3
Cloud
Fog
Why Cloud and Fog?
• Cloud• Centralized paradigm
• Pooling• Efficiency of resource utilization
• Scalability
• Fog• Closer to the edge
• Lower latency
4
Fog Networking
“ A network architecture that uses one or a collaborative multitude of end‐user clients or near‐user edge devices to carry out a substantial amount of storage (rather than stored primarily in cloud data centers), communication (rather than routed over backbone networks), and control, configuration, measurement, and management (rather than controlled primarily by network gateways such as those in LTE core) “
Mung Chiang, Princeton University
5
Two Paradigms
• Computing• Cloud Computing
• Fog Computing
• Networking• Cloud Networking
• Fog Networking
• RAN (Radio Access Network)• Cloud RAN
• Fog RAN
6
Part II: Serving Low‐Latency Applications with Fog RAN
Acknowledgement to Prof. Ai‐Chun Pang
7
“Fog Computing” and “Fog Network”• Fog Computing
• Cloud computing is extended to the edge of the network.• To create a highly virtualized platform that provides compute, storage, and networking services between end‐devices and traditional cloud data centers
• Fog Network• Use one or a collaborative multitude of end‐user clients or near‐user edge devices to carry out
• storage, communications, control, configuration, measurement and management
• F‐RAN (Fog Radio Access Network)• NGMN Taiwan Team proposed this idea to the Advisory Session in the NGMN Forum in Bonn, Germany on June 3‐4, 2014.
January 15, 2016 8
Birth of “F‐RAN”• Follow the same direction with “computing is extended to the edge of the network”
• Act as an aggregator connecting IoT end‐devices and cellular network
• Not only responsible for communication (protocol/signaling), but also application services (data processing)
• In 5G era, a new business model is rising. • Telecom. operator cooperates with application/service provider for better quality of IoT services.
January 15, 2016 9
F‐RAN
• A customized design for IoT applications for • Heterogeneous communication
• Real‐time computation
• Local storage
• Application specific functionalities
• Benefits• Reduce latency
• Increase throughput
• Leverage locality
• Relieve backhaul load
January 15, 2016 10
IoT devices
Core Network
eNodeB
F‐RAN
IoT/cloud Servers
IoT Generation
• Internet of Things (IoT) will grow fast from 2013 to 2018.
• Current cellular Infrastructureis hard to deal with incredibly increasing IoT traffics.
January 15, 2016 11
Categorization of IoT Applications
January 15, 2016 12
Massive Critical (large scale) (low latency)
Future Low‐latency IoT Applications
January 15, 2016 13
• Tactile Internet• “The latency of communication systems becomes lowenough to enable a round‐trip delay from terminals throughthe network back to terminals of approximately 1ms”
• Applications• Health care, education and sport, traffic, roboticsmanufacturing, augmented reality.
‐ G.P. Fettweis, “The Tactile Internet: Applications and Challenges, ” IEEE Vehicular Technology Magazine, vol.9, no.1, pp.64‐70, Mar. 2014
Ultra Low Latency Applications in Wireless 5G
January 15, 2016 14
• 5G vision for ultra low latency• “To support such latency‐critical applications, 5G should allowfor an application end‐to‐end latency of 1ms or less.” (Ericsson5G White Paper, 2015)
• “Zero latency gigabit experience” (Nokia 5G White Paper, 2014)
• “Provide consistent experience under diverse scenarios withultra high data rate, ultra low latency and massiveconnections” (ITU‐2020 5G Vision, 2014)
• F‐RAN in wireless 5G can achieve low latency via:• Do computing for latency‐critical IoT applications at the edgeof the network.
Augmented Reality (AR)
•Definition: • “A technology which allows virtual graphics imagery to exactly overlay physical object in real time”
• Mobile AR with Wireless 5G• Widespread availability, portability, and built‐in good quality cameras of smart phones
• Exciting AR applications (e.g., navigation, public security, real‐time translation)
• 10ms end‐to‐end latency is required.
January 15, 2016 15
‐ F. Zhou, H.B.‐L. Duh, M. Billinghurst, “Trends in Augmented Reality Tracking, Interaction and Display: A Review of Ten Years of ISMAR,” IEEE/ACM ISMAR, pp.193‐202, 2008.
‐ H. J. Einsiedler (T‐Mobile Europe), “5G AND MOBILE CLOUD,” ITG Fachtagung Mobilkommunikation, 2014
Examples of AR Applications
January 15, 2016 16
‐Microsoft HoloLens, 2015‐ Google Translate, 2015‐ IBM Research, 2013
3D DesignVisualization
Remote Instruction
Shopping Aid
Real‐Time Text Translation
Flowchart for a Typical AR Service
January 15, 2016 17
‐ S. Siltanen,, “Theory and applications of marker‐based augmented reality,” VTT TECHNICAL RESEARCH CENTRE Science, No.3, pp.1‐250, 2012.‐ D. Forte, A. Srivastava, "Adaptable architectures for distributed visual target tracking," IEEE ICCD, pp.339‐345. 2011
Tracking module calculates the relative pose of the camera in real time for the correct location and orientation of the virtual components.
“Typical CPU hardware on mobile devices is not able to handle the computational/memory demands of tracking algorithm”
‐> The tracking needs to be done outside mobile devices with low latency. ‐> F‐RAN can be a good solution.
AR Service with F‐RAN
• The computing capability of an F‐RAN node (FN) is approximate to that of a small/femto AP.
• Single FN is not enough for the computing‐intensive tracking algorithm.
• Multiple FNs need to do the application‐layer computing collaboratively.
January 15, 2016 18
‐ Intel., “LTE / Dual‐Mode Femtocell SoC,” Solution Brief Intel Transcede T2K Dual‐Mode Soc Family, 2014.
‐ Qualcomm, “Qualcomm Atheros FSM90xx SoCs for LTE Neighborhood & SMB Small Cells,” Qualcomm Small Cells Brochure, 2014
January 15, 2016 19
Distributed Computing
F‐RAN
ARDevice
RenderingModule
CapturingModule 1
5
3
Master FN (mFN)
4
23
3
Cooperating FNs (cFNs)
1. Receive Captured Images2. Assign Tracking Tasks3. Do Pose Tracking4. Summarize Results5. Send back for Rendering
Cost‐Performance Tradeoff
January 15, 2016 20
Communication(Cost)
Computing(Cost)
Accuracy(Performance)
• Computing resource of each FN is limited.
• Tracking data sent via wireless links among FNs• Distance among FNs affects transmission rate (i.e.,
latency)
• The result of pose tracking
• Low accuracy leads tovirtual‐object mis‐placement.
Factors Affecting the Tradeoff
• Number of cFN• More cFNs
• ► Highier comm. cost for mFN but lower computing cost for each cFN
• Amount of Assigned Tasks for each cFN
• More tasks for each cFN
• ► Higher accuracy with higher computing cost
• Attributes of cFNs
• Loading of cFNs ► Computing cost
• Distances between mFN and cFNs ► Comm. cost
• Amount of Information Sharing• Information (pose tracking data for AR service) shared from mFN to each cFN
• Especially complex for AR service
January 15, 2016 21
Communication
Computing
Accuracy
Technical Challenges
• How to decide which FNs to be the cFNs• Number of cFN
• Attributes of cFNs
• How to split the task for distributed computing• Amount of Assigned Tasks for each cFN
• Amount of Information Sharing
January 15, 2016 22
Summary
• In wireless 5G, many emerging IoT services and applications (e.g., augmented reality) require ultra‐low latency.
• We have proposed F‐RAN and tried to push application‐layer computing from cloud data centers to mobile edge for ultra‐low latency IoT applications.
• Properly handling performance‐cost tradeoff is the key.
• However, there will be diverse application requirements in wireless 5G.
• Low‐latency access co‐exists with non‐real‐time access
• Flexible operation + networking slicing
January 15, 2016 23
24
Part III: Radio Access Network Design for Low Latency 5G
Technical Opportunities in 5G
• Growth Opportunities• IoT, M2M, Internet of Everything …
• LTE have been adding MTC (Machine Type Communications) capability
• MTC in 5G • Native support for MTC
25
Design 5G to provide native support in MTC
5G Machine Type Communications for Internet of Everything
• Cellular wireless infrastructure for MTC• Long transmission range• Low cost equipment• Improve quality of life
• Trends in Wide‐Area IoT• Proprietary LPWA (Low‐Power, Wide‐Area) Networks
• LoRA, Sigfox, …
• 3GPP• Cellular IoT• Narrow‐band LTE
265G MTC could re-shape telecom economy
Narrow‐band IoT
Everyone Talks about MTC/IoT
• A diverse sets of applications and requirements
• Vertical markets• Growth opportunities• $
• Two major types• Mission critical MTC
• Low latency, high reliability
• Massive MTC• Low cost, power efficient
27
5G Usage Scenarios of IMT‐2020
28ITU‐R M.2083‐0, "IMT Vision – Framework and overall objectives of the future development of IMT for 2020 and beyond," September 2015
5G RAN Design for Low‐Latency Services• Mission‐critical and low latency services
29ITU‐R M.2370‐0 "IMT traffic estimates for the years 2020 to 2030“, July 2015
Design Principle #1 Embrace Fog Paradigm
for Low‐Latency
Two Paradigms
•Cloud computing and networking• Centralized pooling• Efficient resource utilization
• Fog computing and networking• Closer to the edge• Lower latency
31
Push Everything to Edge for Low Latency
Challenge: end‐to‐end latency
• Everything needs to be handled with low latency• Air interface
• Baseband processing
• Higher protocol layers
• Computing
32
Handle Each Delay Component Carefully
Design for Low Latency
• End‐to‐end latency is composed of several segments
• Latency in RAN network entry depends on traffic load
• Cross‐layer protocol design is needed to reduce the overall latency across all protocol layers
• Fog computing and mobile edge computing reduce the latency in computing
33ETSI GS MEC‐IEG 004, "Mobile‐Edge Computing (MEC); Service Scenarios," November 2015ETSI, "Mobile‐Edge Computing – Introductory Technical White Paper," 2014
Challenge: Mixed of Traffic
• Diverse application requirements• Low‐latency access co‐exists with non‐real‐time access
• Differentiate different types of accesses
• Flexible operation
34
Design Principle #2: Differentiate Low‐Latency Flow Early
Diverse IoT Traffic
• Low latency in every steps to achieve end‐to‐end low latency
• RACH procedures
• Initial access
• Computing
• Low latency service is costly
36
Differentiate Low Latency IoT Flows Early
Random Access Procedure in LTE
• In LTE systems, a device (UE) connect to the network by performing random access procedure
• Termed RACH procedure in LTE
• The first step：RACH preamble transmission
• To inform the eNB of UE’s connection request
• A UE randomly selects one preamble sequence from a sequence pool
• Preambles with different sequences can be successfully received simultaneously
37
RACH collision
• RACH collision• Two or more UEs selects the same sequence for preamble transmission
• The base station might be unable to decode the transmitted preamble
• It causes preamble transmission failure
• RACH contention resolution• Preambles from numerous IoT devices may cause severe RACH collision, and further affects normal H2H communications
• Some mechanisms should be applied to resolve RACH contention
38
M2M/H2H Co‐existence
39
M2M Shared H2HX
X
Flexible Configuration in Fog‐RAN
• Latency requirements• Ultra‐low latency• Low latency• Delay tolerant
• Two types of resources• Communications
• Fog processing• Cloud processing
• Computing• Fog computing• Cloud computing
40
41
Core Network
Network Packet Classifier
Radio Access Classifier
Ultra-low Latency
Cloud Computing
Fog Computing
Cloud BBU Pool
Fog BBU
42
Core Network
Network Packet Classifier
Radio Access Classifier
Low Latency
43
Core Network
Network Packet Classifier
Radio Access Classifier
Delay-tolerant
Design Principle #3 Be Cognitive, Be Flexible
Flexible RAN with Cognitive Operation• Cognitive design principles
• Observe
• Learn
• Decide
• Act
• Use context to support dynamic and diverse traffic
• Challenge to support massive M2M• Bursty load to control plane signaling
• Network entry
45
Understand the Context
• Traffic load as context information• Estimation of network entry load• The number of devices under contention
• Obtain context information with low cost• RACH: success, collision, empty
• Estimation technique
• Adaptation for load control• Also helpful for latency reduction• Collision and retransmission are harmful for latency
46Guan‐Yu Lin, Shi‐Rong Chang, and Hung‐Yu Wei, “Estimation and Adaptation for Bursty LTE Random Access,” IEEE Transactions on Vehicular Technology, 2015
Adaptive M2M Access: Network‐Assisted Context Info
47
M2M Shared H2HX
X NM2M NShared NH2H
Broadcast System Context Information
XXX
X
X
XX
X
XXXX
light
medium
heavy
Adaptive device configuration accordingly
Adaptive M2M Access: Distributed Decision at M2M Devices
48
M2M Shared H2H
(1) Use M2M‐only resource(2) Use shared resource
(3) Do not transmit
Utility (successful transmission) - Cost
(utility is application‐dependent)
0 1 2 3 4
x 104
0
5
10
15
20
25
time slots
succ
ess
rate
H2HM2Msum of both
Context‐Aware H2H/M2M Adaptation
49
0 1 2 3 4
x 104
0
5
10
15
20
25
30
35
40
45
time slots
arriv
al r
ate
H2HM2M
Traffic‐aware adaptation
H2H/M2M mixed traffic arrival
0 1 2 3 4
x 104
0
5
10
15
20
time slots
tran
smis
sion
rat
e
M2M resourcesHybrid resourcesH2H resources
Resource utilization
Ho‐Yuan Chen, Mei‐Ju Shih, and Hung‐Yu Wei, “Handover Mechanism for Device‐to‐Device Communication,” IEEE Conference on Standards for Communications and Networking (CSCN 2015), Oct. 2015
Flexible Fog RAN for Diverse Traffic• Low latency service is costly
• Great challenges and opportunities
• Not all services have low latency requirements• Flexibility in business and pricing models
• Joint design for computing and communications• Small cell v.s. C‐RAN• Mobile edge computing and Fog‐RAN
• RAN design issues• Integrated RAN architecture• Differentiate network access• Context‐aware adaptation
50
Summary: Flexible RAN for Low‐Latency and Diverse Applications• Hybrid architecture for C‐RAN and Fog RAN integration
• Heterogeneous evolution path for C‐RAN
• Push computing and communications processing to the edge
• Latency
• Flexible Fog RAN architecture to support diverse applications
• Context‐aware adaption
51
Part IV: Standard Activities
52
ETSI Mobile Edge Computing
53Source: ETSI
IT Service at the Edge of Network
54Source: ETSI
Use Case: Active Device Location Tracking
55Source: ETSI
Use Case: Augmented Reality Content Delivery
56Source: ETSI
Use Case: Video Analytics
57Source: ETSI
Use Case: RAN‐aware Content Optimization
58Source: ETSI
Use Case: Distributed Content and DNS Caching
59Source: ETSI
Use Case: Application‐aware Performance Optimization
60Source: ETSI
Use Case: Connected Vehicles
61
Vehicle‐to‐infrastructure
Source: ETSI
MEC Deployment Scenarios
62Source: ETSI
MEC API
63Source: ETSI
NGMN’s View on Edge Computing
64
InternetC‐RAN, vRAN
Core Network
Edge Server with cloud infrastructure: Cloudlet or MEC server: compute, store, network
SaaS, PaaS, IaaS
Latency
Code offloadCode provisioning
Code provisioning
Operator
Radio access networkinformation exposure
to application
Source: NGMN
