MEC-based Stable Topology Prediction for Vehicular Networks

Use Case Details:

Attributes	Description	Informational
Type	New	The use case is proposed under the ICN BP family
Industry sector	Area: SDN & NFV Company: ATTO Research University: Jeju National University Country: Republic of Korea	ATTO RESEARCH focuses on the problems related to networking and software technology for a better connection. It has created a technology that allows to build IT infrastructure, and aims to grow into a ‘Software Defined Infrastructure’ company.
Business driver	The stable vehicular network is essential to enable various applications such as autonomous driving through VANETs. Proposed MEC architecture tends to enable a promising infrastructure where a stable network topology can be predicted locally to improve the network performance by providing intensive calculation for vehicles in the adjacent roads. Thus, converging the two concepts of MEC and topology prediction can provide a strong use case for the vehicular networks such as proactive path stabilization.	The MEC-based Efficient Routing Algorithm 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 from being useful to provide a stable topology on the road tracks.
Business use case	Edge cloud deployable at RSUs to support applications such as ML-based location prediction, topology stabilization
Business cost - Initial build	Minimal configuration is three servers in total: Master/Database node (1^st server) Edge node 1 (2^nd server) Edge node 2 (3rd server)	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 name	MEC-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 One Orchestration node 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 Info	Time Zone	Committer Bio	Committer Picture	Self Nominate for PTL (Y/N)
MalikAsif	Jeju National University	malikasifmahmoodawan@gmail.com	Asia/Seoul (UTC+9)			Y

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
Proximity Services

Motivational Idea

Architecture Overview:

The architectural view of our system is as follows:

Use case Attributes:

Stable network topology in IoV
Road aware, predictive, and proactive connection

2. Road aware, predictive and proactive connection

Stable Path Scenarios:

Stable path connectivity scenarios are illustrated as shown below:

The below figure (shown left side) is a scenario where the devices are under same cell and in coverage, which want to communicate. The below figure (shown right side) is a scenario where the devices are under same cell and one oft them is out of coverage, which want to communicate.

The below figure explores the Device to Device communication where a device 1 wants to communicate device-4 and both of them reside under a different Cell node. In this case, the packet is forwarded from one edge vEPC to another. This way the connectivity is provided as follows:

The below scenario explains the same as immediate previous scenario but the only difference among them is that one of the device is out of coverage and proximity service plays the role of provisioning the location of such devices.

The below figure shows the direct communication between the devices which reside under different Cells. The below path was provided as a result of proactive approach that we propose in our system. The major difference between the below two scenarios is that in such cases, we don't require the involvement of Edge vEPC in order to forward the packet to another road segment, thus reducing the latency and improving the performance in terms of bandwidth and efficient resource usage of the cellular spectrum. Both the devices are in coverage.

The below figure also shows the direct communication between the devices which reside under different Cells. The below path was provided as a result of proactive approach that we propose in our system. The difference from previously mentioned scenario is that one of these devices are out of coverage. In this case also, the benefits to reduce the latency and efficient resource usage were achieved.

Help 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!