Versions Compared

Old Version 25

changes.mady.by.user Asif Mehmood

Saved on

compared with

New Version Current

changes.mady.by.user Asif Mehmood

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Page Tree
expandCollapseAlltrue
rootMEC-based Stable Topology Prediction for Vehicular Networks

MEC-based Stable Topology Prediction for Vehicular Networks

Use Case Details:

Attributes

Description

Informational

TypeNewThe use case is proposed under the ICN BP family
Industry sector

Area: SDN & NFV

Company: ATTO Research

University:

Jeju National

Gachon University
Country: Republic of Korea

ATTO RESEARCH focuses
We focus on the problems related to networking and software technology for a better connection.
It has created a
The technology that allows to build IT infrastructure, and aims to grow into a ‘Software Defined Infrastructure’ company.
Business
driversIn order
driverThe stable vehicular network is essential to enable various applications such as autonomous driving through VANETs
, stable vehicular network is essential. Edge cloud proves to be
. Proposed MEC architecture tends to enable a promising infrastructure where a stable network topology can be predicted locally
in order
to improve the network performance by providing intensive calculation for vehicles in the adjacent roads. Thus, converging the two concepts of
edge computing
MEC and topology prediction can provide a strong use
-
case for the vehicular networks such as proactive path stabilization.The
position
MEC-based Efficient Routing Algorithm
is able to
can provide a stable path by using the predicted future position for the nearby vehicles. The information can also be made available to the adjacent road resulting
to be
from being useful to provide a stable topology on the road tracks.
Use cases

  • Stable network topology prediction in Internet of Vehicles (IoV) at the Edge cloud

  • QoS-based multi-channel support for different types of services

  • Real-time Computation for Autonomous and Self-driving cars

The topology prediction performed at the edge cloud will provide real-time network topology as well as a stable routing path in IoV.Business cost (initial build cost target objective)
Business use case
  • Edge cloud deployable at RSUs to support applications such as ML-based location prediction, topology stabilization

Business cost - Initial build

Minimal

The minimal

configuration is three servers in total:

  • Master/Database node (
1st
  • 1st server)
  • Edge node 1 (
2nd
  • 2nd server)
  • Edge node 2 (3rd server)
Scale & Type3 (x86 server)The physical machines are used for different purposes such as Master, Edge and Database nodes. 1st server will be used as a Master and Database node. The remaining two physical servers will be used as two different edge nodes for computing.Nodes (virtual)
  • 1 master node
  • 1 database node
  • 2 edge nodes
Our system has three basic nodes. Master node being the one to manage the other nodes helps out in scaling up the number of edge nodes and applications on them. Edge nodes have the prediction models which provide the network topology in IoV. Database node contains the information of each edge node accessible to the Master node via which Master node can also view the overall network topology in IoV for different purposes.ApplicationsApplications for autonomous vehicles such as topology and location prediction on edge clouds.These applications (being latency sensitive) can be extended to any type of business use-cases.Infrastructure orchestration
  • OSM (Orchestrator)
  • OpenStack (cloud provider)
  • ONOS (SDN controller)
  • OpenFlow (SDN southbound protocol)
  • Ubuntu 18.04.3 LTS (OS)
For orchestration purpose, we will use OSM (Open Source MANO). The infrastructure to be setup for the proposal is done by generating configurations in the OSM platform that will orchestrate resources via the OpenStack (cloud provider). We also integrate the an ONOS (SDN controller) for the purpose of networking among the VMs. These VMs will act as our edge servers. We will setup the edge locations on our local physical servers and provide with the performance test results.Workload typeVirtual-machines/ContainersWe will use virtual-machines at the initial stage of development.Additional detailsIntroduced intelligence at the edge. Reducing backhaul due to edge computing.PPT has been attached as a proposal statement.Summary/ Overview

Due to recent advancement in networks, IoV has a major role to play and is critical to performance. To this end, we introduce machine learning mechanisms integrated at the edge cloud as a proposal. As it is a known fact that the vehicles at the edge are directly connected to the Radio Station Units/Base Stations (RSU/BS) and placing such application/software packages at the edge can significantly enhance the performance in the IoV domain.

Further, the extended version of Kalman Filter is proposed to predict the network topological locations. The inference engine used for predicting the vehicular locations and further forming them into predicted topology proves to provide a stable path for the vehicles to communicate on the provided flow-based channels. Overall, the solution and architecture are flexible in nature which further allow the support of multiple use cases in 5G.

  • Abbas, Muhammad Tahir, Afaq Muhammad, and Wang-Cheol Song. "Road-aware estimation model for path duration in internet of vehicles (IoV)." Wireless Personal Communications 109.2 (2019): 715-738.
  • Abbas, Muhammad Tahir, et al. "An adaptive approach to vehicle trajectory prediction using multimodel Kalman filter." Transactions on Emerging Telecommunications Technologies (2019): e3734.
  • Abbas, Muhammad Tahir, Afaq Muhammad, and Wang-Cheol Song. "SD-IoV: SDN enabled routing for internet of vehicles in road-aware approach." Journal of Ambient Intelligence and Humanized Computing (2019): 1-16.

Motivation:

Motivational aspects are:

  • The topology in a vehicular network is updated and retrieved frequently
    • This causes path instability
  • Vehicular networks are wireless in nature
    • However, Software-defined networking (SDN) is originally designed for wired networks
  • Leads to the need for topology stability in vehicular networks

To this end, we introduce:

  • Computation at the Edge 
  • Topology prediction to proactively stabilize the paths in vehicular network

Motivational IdeaImage Removed

QoS-based multi-channel Scenario:

The architectural view of our system is as follows:

Architecture OverviewImage Removed

QoS-based multi-channel Scenario:

QoS-based multi-channel ScenarioImage Removed

Price factor depends on the cost of RSU quality, and should be only considered for physical deployment. i.e. wireless or wired.
Business cost - Operational

Virtual environment does not require cost.


Operational need

Using the frontend GUI to:

  • Orchestrate virtual resources
Manage the edge applications
Additional details
  • Support of path within a Single operator domain

PPT is attached as proposal statement.

Species Details:

Attributes

Description

Informational

Type

Integrated Cloud Native NFV/App stack (ICN)


Blueprint Family

Existing


Use case

Stable network topology in IoV


Blueprint proposed nameMEC-based Stable Topology Prediction for Vehicular Networks

Initial POD cost

Satellite POD


Scale & Type

System will be developed/deployed in VMs.


Applications
  • ML model
  • LTE network services
  • ProSe Functions

Open Air Interface (OAI) provided LTE network services will be used.

Infrastructure orchestration

  • OpenStack latest/stable release – VM orchestration
  • Kubernetes-based container orchestration
  • WeaveNet -based Container Networking
  • VNF Orchestration – ONAP
  • OS – Ubuntu 18.X LTS
  • CICD - Jenkins 2.249.1 LTS

SDN

ONOS will be used at the application layer


Workload type

VMs and Containers


Additional

  • 4 Virtual Machines
    1. One Orchestration node
    2. Three Edge nodes
  • Jenkins for Continuous Integration and Continuous Delivery
  • Personal servers will be integrated with the Linux Foundation servers

Committers and PTL (Project Technical Lead)

Please enter in all names of the committers for the project.

PTL is done off of self nomination process.  If you wish to be considered for the PTL, please indicate that by putting a Y in the self nomination column (use the slide to move the table left to right).  Per Akraino rules, if there is only one nominee, that person becomes PTL (when confirmed by the Akraino TSC).  If there is more than nominee, we will then have an election.
The election process is open and will go through 7 Oct. 2020 at Noon Pacific time. 

Committer

Committer Company

 Committer Contact InfoTime Zone

Committer Bio

Committer Picture

Self Nominate for PTL (Y/N)

Asif Mehmood

Gachon University

malikasifmahmoodawan@gmail.com

Asia/Seoul (UTC+9)

Image AddedGithub Logo - Free social media iconsImage AddedImage AddedImage AddedDocker Logos - DockerImage Added

Image Added

Y

First (1st)Second (2nd)

from:

to:

from:

to: Present


Faisal Mehmood 

Gachon University


Asia/Seoul (UTC+9)

from:  

to: Present

Contributor

CompanyEmail (Contact)ProfilesPictureAsif MehmoodJeju National Universitymalikasifmahmoodawan@gmail.com

Image Removed Image Removed Image Removed

Muhammad Ali Jibran---alijibran35@gmail.comAfaq MuhammadJeju National Universityafaq@jejunu.ac.krWang-Cheol SongJeju National Universityphilo@jejunu.ac.krTaekyung LeeATTO Researchtaekyung.lee@atto-research.com
























Info
titleHelp Us Improve the Wiki

This Wiki is owned by the Akraino Community. Contributions are always welcomed to help make it better!

In upper right, select Log In. You will need a Linux Foundation Account (can be created at https://identity.linuxfoundation.org/) to log-in. For a Wiki tutorial, please see Confluence Overview. Thank you!


Recent space activity

Recently Updated
typespage, comment, blogpost
max5
hideHeadingtrue
themesocial