Platoon Formation and Stability with Multi-access Edge Computing in LTE-Advanced networks

(1)

Department of Information Engineering

Computer Engineering

Master Degree Thesis

Platoon Formation and Stability

using Multi-access Edge Computing in

LTE-Advanced networks

Speakers:

Ing. Giovanni Stea

PhD. Giovanni Nardini

PhD. Antonio Virdis

Presented by:

Angelo Buono

Academic Year 2017/2018

September 16, 2018

(2)

(3)

Acknowledgements

First of all I’ve to thank my mother, who always

encouraged me on keeping studying, and my father, who

taught me to take life as it comes. Thank you Filomena and Luigi!

I’ve to thank my grandmother Giuseppina for all the love she gives me.

A very big thanks is for Alfonso, Carmine, Jonas and Vittorio

for making my days more cheerful and fun.

Thank you, Alessia, for believing in me and bringing a sunshine in my life.

An huge thanks is for my speakers that gave me this chance.

Thank you so much, Giovanni, for supporting me during all these months.

Thank you Corrado, Mariano, Maria and Martina

for all the funny moments spent doing projects and studying together.

Last but not least thanks so much to all my relatives and friends

that I can’t list one by one. Please forgive me!

(4)

(5)

Nowdays intelligent transportation systems are a fervent topic and the most promising one is platoon-based driving. Vehicles traveling at a small and nearly constant distance can signifi-cantly improve road capacity and energy efficiency. Moreover, with the emerging vehicular ad hoc network (VANET), the performance of a platoon in terms of road capacity, safety and en-ergy efficiency can be further improved. On the other hand low latencies and flexible service deliveries have to be guaranteed. The most suitable technology providing these requirements is Multi-access Edge computing that allows the deployment of cloud servers within the radio access network (RAN), i.e. LTE networks, to deliver vehicular services at low latencies.

In this thesis we extend the SimuLTE framework, that enables simulations of LTE/LTE-Advanced networkswithin OMNeT++, to support Multi-access Edge computing and provide a centralized platoon formation service. The Platoon formation service designed performs vehicle clustering and vehicle mobility control. The experiments performed verify the correctness of the service in performing the formation of platoons and in stabilizing it. Moreover the network per-formances confirm the expected behaviour in the allocation of radio resources: the average amound of served blocks in DownLink increases proportionally with decrease of the service period or with the increase of the number of vehicles using the service. Finally the results regarding the average latencies are very promising: in DownLink the values are below 10 milli-seconds, while in UpLink, when considering a worst case with all simultaneous trans-missions, they are below 35 milli-seconds. These low latencies are compliant with the service requirements fro V2X services defined by ETSI [8]. At the end of the day we can claim an MEC-enhanced eNodeBnode capable of providing Multi-access Edge Computing Services with latencies below 10 milli-seconds. On the other hand we have also a Platooning Service that, when running with an appropriate period, manages correctly platoons traveling in a collision free way. The proposed service can be extended or modified by implementing different stabil-ity controllers or formation algorithms in order to simulate different platoon configurations.

(8)

Chapter 1 Introduction

Nowdays, with the development of automobile industry and urbanization, more and more ve-hicles are on the highway linking adjacent cities. It is estimated that currently there are more than 1 billion registered motor vehicles worldwide, and that the number will be doubled within the next 10 years. As a result, a series of critical issues are becoming more serious in modern transportation systems, such as traffic congestion, traffic accidents, energy waste, and pollu-tion. To deal with these issues, an effective approach is to change the driving pattern from individual driving to a platoon-based driving. In general, the platoon-based driving pattern is a cooperative driving pattern for a group of vehicles with common interests, in which a ve-hicle follows another one and maintains a small and nearly constant distance to the preceding vehicle, forming platoons as shown in figure 1.1. In the literature [11], [15], it has been shown that the platoon based driving pattern can bring many benefits. First, since vehicles in the same platoon are much closer to each other, the road capacity can be increased and the traffic congestion may be decreased accordingly. Second, the platoon pattern can reduce the energy consumption [12] and exhaust emissions considerably because the streamlining of vehicles in a platoon can minimize air drag. Third, with the help of advanced technologies, driving in a platoon can be safer and more comfortable. Last but not the least, platoon-base driving pattern

Figure 1.1: Example of a Vehicle Platoon scenario

facilitates the potential cooperative communication applications (e.g., data sharing or dissem-ination) due to the relatively fixed position for the vehicles within the same platoon, which may significantly improve the performance of vehicular networking. However platoon is a

(9)

complex physical system and requires that drivers act cooperatively to control and manage it. Over the past decade, many new technologies have been developed to help drivers. For instance, the adaptive cruise control (ACC) system can use sensors to detect the distance be-tween adjacent vehicles and autonomously maintain the speed and/or distance. In addition to technologies applied individually, platoon can be facilitated by utilizing modern wireless com-munication technologies, which have greatly promoted the development of intelligent trans-portation system (ITS). Particularly, by integrating the wireless communication interface on board, known as on-board unit (OBU), a running vehicle can collect information from its neigh-bors or the roadside infrastructure, known as road-side unit (RSU), which facilitates a safer and more comfortable driving experience. In practice, vehicles with communication capability can dynamically form a mobile wireless network on a road, called vehicular ad hoc network (VANET), which as a promising technology can offer two types of wireless communications: vehicle to vehicle (V2V) communicationand vehicle to infrastructure (V2I) communication. Such a complex system integrates computing, communication, and control technologies. Therefore, it can be considered as a platoon-based vehicular cyber-physical system (VCPS), in which all vehicles communicate via vehicular networking and are driven in a platoon-based pattern, with a closed feedback loop between the cyber process and physical process.

Unfortunately the existing "one size fits all" cellular system with only centric-deployed servers is inefficient to enable these future vehicular networks, in which latency, reliability and availability are crucial parameters. Moreover offloading workloads of vehicular clients (VCs)to remote Cloud Centers poses long network transmission latency, and is difficult to en-able real-time data dissemination and content delivery. Thus, with the purpose of meeting

Figure 1.2: Example of Multi-access Edge Computing deployment in a vehicular scenario the QoS requirements of future Vehicular Internet applications, a part of computing can be transferred at the edge of the mobile network to allow service delivery in close proximity to end-users. To address the problem, the concept of Fog Computing is proposed to formulate a

(10)

distributed computing paradigm that extends the cloud services to the edge of the network. Therefore a new technology, namely Multi-access Edge Computing, is being developed. The Multi-access Edge Computing provides cloud and IT services within the close proximity of mobile subscribers. A typical Multi-access Edge Computing scenario, envisioned by [20] and showed in figure 1.2, is deploying the MEC server at the LTE macro base station (eNB) site, and the MEC server is just treated as an application host, with storage and computing resources, to enrich the service capability of the base station.

The purpose of this thesis is to develop a Multi-access Edge computing service for the forma-tion and stability of vehicles platoons, provided by Multi-access Edge Computing Serves deployed at eNodeB sistes [20]. The service combines a clustering algorithm, to identify platoons, and a longitudinal controller, taken from literature [9], to control the platoons stabilities. Then comes a brief proof of correctness for the clustering algorithm and the tuning of parameters regard-ing the longitudinal controller. Finally the analysis of the achieved results about the stability performance. The simulations are carried using the OmNET++ simulator and extending the SimuLTE framework[2], that enables simulations of LTE/LTE-Advanced networks, with Multi-access Edge computingcapabilities: a general-purpose ME Host and an ad-hoc ME Service for platoon management, i.e. platoon formation, platoon stability control and intra-platoon data dissemination.

The rest of thesis is organized by introducing Vehicle Platooning and Platoon-based Vehic-ular Cyber-Physical System (VCPS) in chapter 2; then in chapter 3 is given an overview of the Multi-access Edge Computing Standard and is described the Multi-access Edge Computing Servicefor Platoon Formation and Stability. Chapters 4 and 5 present the OmNET++ simula-tor and the SimuLTE framework. In chapter 6 is described the enhancement of SimuLTE to support Multi-access Edge Computing capabilities: the modeling of a ME Host module and its behaviour; the interaction flow between User Equipment Applications, Multi-access Edge Ap-plications and Multi-access Edge Services. The ME Platoon-Formation Service implementation is described in chapter 7, while in chapter 8 is given the proof of correctness for the cluster-ing algorithm and are carried simulations for 1) tuncluster-ing service parameters and analyze the stability performaces, and 2) analyzing the network performances when running the service with heavy loads. Finally chapter 9 concludes the thesis by describing the achieved results and speculating future works to improve the MEC-enhanced SimuLTE framework.

(11)

Chapter 2 Vehicle Platooning

In this chapter we present, in section 2.1, one of the most active fields in the automotive reser-ach about Intelligent Transportation Systems, the Vehicle Platooning, and its application fields. While, in section 2.2, we introduce the system architecture enabling vehicular applications based on platoons, the Platoon-based Vehicular Cyber-Physic System, and its technical issues.

2.1 What is Vehicle Platooning

Vehicle platooningis part of a suite of features that self-driving cars might employ. A platoon is a group of vehicles that can travel very closely together, safely at high speed and communi-cating with each other. There is a lead vehicle, the Platoon Leader, that controls the speed and direction, and all following vehicles (which have precisely matched braking and acceleration) respond to the lead vehicle’s movement [5] [4].

Figure 2.1: Truck Platooning scenario

2.1.1 Platoon-based applications

Platoon-based applicationsconsist of three categories: 1) traffic flow optimization, 2) traffic green and economicsand 3) infotainment service [14]. The primary objective for vehicle platooning is to reduce traffic congestion and improve traffic flow throughput. To this end,

(12)

many platoon related projects have been implemented in the past decades. The most famous one is the California Partners for Advanced Transit and Highways (PATH) project which aimed to improve traffic throughput by deploying platoons in highway. The E.U.-sponsored SARTRE program deployed a platoon on highway with a lead vehicle (typically truck) followed by a series of cars, driven autonomously, in close formation. Another critical issue for is to improve traffic efficiency and promote greener traffic environments, such as saving traveling time, cut-ting down fuel consumption and reducing exhaust emissions. The representative project called Energy ITS, in Japan, aimed at the CO2 emission reduction from automobiles. While, regarding the fuel consumption reduction, experimental results show that trucks platooning traveling at 80km/h, experience a 21% fuel reduction when the inter-vehicle distance is lower than 10 me-ters, while the fuel reduction is 16% for a distance of 16 meters [12]. The fuel reductions for the same vehicles and distances traveling at 60 km/h are approximately 16% and 10%, respec-tively. The last category is about wireless communications that boost various infotainment applications in vehicular networking, such as platoon-aware data delivery among vehicles, cooperative local service, etc.

2.2 Platoon-based Vehicular Cyber-Physical System

The platoon-based Vehicular Cyber-Physical System (VCPS) is an orchestration of computers and physical systems for vehicular applications based on platoons. VCPSs are characterized

Figure 2.2: Architecture for platoon-based VCPSs

by the tight coupling between vehicles’ physical dynamics (mobility) and the behaviors of vehicular networks. The physical plane describes the platoon mobility under the constraints of traffic environment, while the cyber plane describes the behaviors of vehicular networks formed by adjacent vehicles. Due to the tight interactions between the physical plane and the cyber planean integration of computing, communication, and control technologies is required to achieve stability, performance, reliability, robustness, and efficiency of the platoon-based VCPS. There are in general two types of VCPS: intra-vehicle CPS and inter-vehicle CPS.

(13)

For an intra-vehicle CPS, the main concern is to improve the kinetic performance of a single ve-hicle by combining and coordinating all of its components (sensors, actuators and field buses). For inter-vehicle CPS, the main objective is to optimize traffic performance or vehicular net-working from a CPS design standpoint. A general platoon-based VCPS architecture, as showed in figure 2.2, is composed of two parts: the platoon-based mobility/control model which regulates the vehicle dynamics under a platoon-based driving pattern, and the networking/-communication modelthat generalizes the networking request of vehicle applications, such as the communication topology, networking layer specification, etc. The two main processes are the networking/communication process and the platoon mobility process [14]. Platoon mobililty process

The platoon mobility process can be presented as platoon driving actions regulated by cer-tain mobility/control model with the help of vehicular communication. Some typical actions include platoon forming, maintenance, merging and splitting. Platoon parameters as the reference input of the control model describe the expected platoon profile, such as pla-toon size, intra-plapla-toon spacing and inter-plapla-toon spacing. For example, in the case of CACC system for the platoon mobility process, the control objective of CACC is to maintain a de-sired inter-vehicle or inter-platoon distance (i.e., expected platoon profile). With the help of inter-vehicle communication, the CACC system can be modeled as a networked control sys-tem wherein feedback loop couples both VANET and platoon mobility. Some uncertainties of practical VANET, such as packet loss and probabilistic transmission delay, have negative impact on the control performance.

Networking/communication process

The networking process mainly supports data dissemination on the request of platoon-based VCPS application, which may exhibit different VANET performance under various platoon-based traffic flow scenarios. In a collision risk warning application, for example, each vehicle is supposed to periodically broadcast its kinematic status to neighbors. Clearly, if the platoon size is small and the inter-platoon spacing is large, packet delay and loss seldom happen within a single platoon even at high rate of message generation; in case of large platoon size and small inter-platoon distance, packet delay and loss would be significantly larger given the same message generation frequency. Networking parameters as the reference input of the networking/communication model such as the message generating rate, transmission power, etc., can be adaptively adjusted according to the current traffic dynamics.

2.2.1 Technical issues for Platoon-based VCPS

The performance of a platoon-based VCPS is jointly determined by both networking process and control process, which closely combines communication, computation and control together. The fundamental technical issues in platoon-based VCPSs can be generalized into two sys-tem optimization objectives: 1) Optimizing the traffic flow with the help of vehicular networking, the corresponding technical issues mainly include platoon management, platoon-based cooperative driving and the stability of platooning system; 2) Analyzing and optimizing

(14)

vehicular networking performanceby the aid of platoon-based traffic flow: platoon-based V2V communications and platoon-based V2I communications.

Platoon management

The Platoon management is a fundamental function, which involves platoon formation, merging and splitting. The platoon management protocol enables vehicles to manage platoon with common interests, while the platoon management strategy determines the structure of a platoon based on various design objectives. It is still challenging to form the stable cluster or platoon especially in heterogeneous and drastic changing traffic scenarios. A comprehensive description of traffic mobility and local networks (the neighborhood lists of vehicles) is crucial for better platooning or clustering algorithm.

Platoon stability

The Platoon stability exhibits the essential feature of intraplatoon dynamics from the con-trol theory perspective. Platoon stability is defined as the spacing error between the desired and actual inter-vehicle spacing. In the literature, it has been shown that many factors may influence platoon stability: 1) Vehicle parameters that physically reflect the inherent charac-teristics of the vehicle stemming from manufactory, such as the parasitic time delays and lags in the engine and actuators; 2) Spacing policy that, in general, specifies the constant spacing and variable spacing. The former one indicates the separating distance being independent of the speed of the controlled vehicle, while the latter one denotes that the intra-platoon spacing is related to the vehicle’s speed; 3) Communication structure that describes the topology and information that connects and exchanges among vehicles; 4) Control law that defines control algorithms on the vehicle.

Platoon-Based V2V Communication

The Platoon-Based V2V Communication is a must in platoon-based VCPS to facilitate var-ious platoon-based applications, such as vehicle platooning and infotainment service. For a typical platoon-based traffic scenario, some basic issues regarding vehicular communication are: 1) how to efficiently disseminate message within the intra-platoon and interplatoons; 2) how to improve communication performance between the platoon/vehicle and RSU. It is very challenging to design effective beacon dissemination scheme for vehicle platooning, which requires not only stable beacon reception ratio but also quick response to the changing traffic conditions. While inter-platoon communications mainly involve the issue of VANET connectivity, which is a fundamental measurement to the linking quality of vehicular com-munication.

Platoon-Based V2I Communications

The Platoon-Based V2I communication, also called Drive-thru Internet access, is a primary application for platoon-based VCPSs, where all vehicles have opportunities to access Internet service from a RSU when they enter into the transmission coverage of the RSU. Traffic dynam-ics have significant impact on drive-thru Internet system. To improve the system performance,

(15)

an efficient solution is to cooperatively access to RSU among vehicles by exploiting the char-acteristic of traffic dynamics, for example, the platoon-based driving pattern or controllable vehicle position distribution.

(16)

Chapter 3 Multi-access Edge Computing

In this chapter we deal with the Multi-access Edge Computing technology and its application in the Intelligent Transportation System by means of a Vehicle Platooning Formation and Stabil-ity ME Service. In section 3.1, we introduce the concepts of Fog Computing and Multi-access Edge Computing; then, in section 3.2, we take an overview upon the MEC Application Domains that makes this techonology so promising. The section 3.3 shows off the main characteristics required by a Multi-access Edge Computing System, and, in section 3.4, we describe the archi-tecture and frameworkstandardized by ETSI. Finally in section 3.5 we propose a ME Service for the Formation of Vehicle Platoons and their Stability Control.

3.1 Definitions

There are lots definitions when speaking about Fog and Multi-access Edge Computing, but sum-ming up the concepts we found in [18], [16] and [10], we get the following findings:

"Fog Computing is a scenario where heterogeneous devices communicate and po-tentially cooperate, both with and without the help of virtualised platforms located ad the edge of the network."

"Multi-access Edge Computing can be seen as a cloud server running at the Ra-dio Access Network and providing context-aware and delay-sensitive applications." (figure 3.1)

When Multi-access Edge Computing and Fog Computing are combined together we get a depolyment where cloud-servers, inside the Radio Access Network, provide context-aware services to mobile devices that communicate and cooperate to improve these services.

3.2 Application Domains

The Multi-access Edge Computing is a promising technology because of its possible application domains; according to the ETSI standard [6] and other research articles [10] [13] the most suitable domains are:

(17)

Figure 3.1: Multi-access Edge Computing Servers inside the RAN

• Dynamic Content Optimization

Content optimizers, hosted at the ME Server, can optimize the contents based on user’s context-aware informations and RAN informations; thus network performances and Quality of Experience are enhanced, and new services can be added.

• Computational Offload in IoT

IoT applications can be splitted into small tasks to be executed at the ME Server instead of executing them at the Cloud Server; latency will be reduced.

• Mobile Big Data Analytics

Big data analytic can be performed at the ME Server and the results can be sent to the Core Network; bandwidth consumption and network latency will be reduced.

• Smart Transportation

Smart transportation is to overcome issues such as poor traffic network, poor road con-ditions, inadequate places for parking, inadequate capacity of public transportation and road safety. For example, a ME Server can control the traffic automatically by using real-time data provided by road side cameras and sensors.

These application domains involve numerous use cases that can be organized in three cate-gories: Consumer-oriented services, Operator and third party services and Network performance and QoE improvements. Consumer-oriented services include innovative services that benefit directly the end-user: gaming, remote desktop applications, cognitive assistance, augmented and assisted reality. Operator and third party services provide innovative services that take advantage of computing and storage facilities close to the edge of the operator’s net-work; these services does not directly benefit the end-user, but can operate in conjunction

(18)

with third-party services: active device location tracking, big data, security. Network per-formance and QoE improvementsare services aimed at improving network performances: content/DNS caching, application computation off-loading, traffic decuplication, mobile back-haul optimization, video optimization.

3.3 Principle, Requirements and Features

The ETSI GS MEC 002 standard [6] defines the technical requirements recommended to de-velop a consistent Multi-access Edge Computing Systems. The documentation specifies three main characteristics: principles, requirements and features. The principles are important to understand the context of a MEC System; the requirements are concrete functionalities ex-pected by the system, sometimes derived from the principles; while the features are groups of related requirements ,identified by an unique name, and used to represent a specific service.

3.3.1 Principles

A Multi-access Edge Computing should be developed taking into account the following princi-ples:

• NFV alignment • Mobility support

• Smart application location • Deployment independence • Security on communications

Network Functions Virtualisation alignmentis the recommended technology to perform virualised network operations, required for running applications at the mobile network edge. In order to support UE mobility, and the smart application location, the system has to handle both the mobility of applications and the mobility of application-specific user-related in-formations. The smart application location principle regards the ME Application life-cycle and says that "the application has to run at the right place at the right moment": the Multi-access Edge System needs to move the application location when requirements are not anymore sup-ported. Another important principle is the deployment independence, that is needed for reasons of performance, costs and scalability; the system has to be able to be deployed any-where in the network: i.e. at radio node or at the edge of core network. Last, but not least important, there is the security on communications, between Multi-access Edge Services and Radio Nodes, that is required to avoid illegal accesses: authentication and secure tunnel communications must be considered.

(19)

3.3.2 Requirements

Generic Requirements

Generic Requirements are derived from principles and they specify the functionalities that a MEC system has to support to correctly handle the lifecycle of Multi-access Edge Applications and Multi-access Edge Services. These requirements affect the framework and the management system.

The Framework has to be developed in a way that assures NFV alignment and deployment independence: reusing the NFV Virtualisation Infrastructure and its management function-alities, and providing a Multi-access Edge Platform deployable on Multi-access Edge Hosts in various locations, like radio nodes, gateways and distributed data centers in the Core Network. The access Edge Management System has to manage the lifecycle of Multi-access Edge Applications:the instantiation, by verifying the application authenticity and the integrity, and by taking into account the required resources; the termination when required by the operator; and, when supported the relocation. Furthermore, the management system has to assure the mobility support and smart application location priciples in order to main-tain connectivity between a UE and an application instance when the UE performs handover to another cell associated, or also not associated, with the same ME Host . For example the Multi-access Edge Platformmay use available radio network information to optimize the mobil-ity procedure required to support service continumobil-ity: i.e. Smart Relocation feature (subsection 3.3.3).

Services Requirements

Services Requirementsare functionalities required by the Multi-access Edge Platform to deliver Multi-access Edge Services and to support Multi-access Edge Applications running on the ME Host. Another important requirement is the need of accurate timing, because of application requiring synchronization for executing their tasks (i.e. analytics information collection and pre-processing, time tagging of the location information, etc.).

The Multi-access Edge Platform has to provide Multi-access Edge Services that can be consumed by authorized ME Application , by the Platform and by Multi-access Edge Applica-tions running within the ME Host , and has to provide functionalities for communicaApplica-tions between authorized Multi-access Edge Applications, Multi-access Edge Services (also located on different Multi-access Edge Hosts) and third-party server. The platform has to provide functionalities to allow the discovery of available services and their informations, and has to allow the authentication and authorization of providers and consumers of these ser-vices. There is also the need to route user-plane traffic between authorized Multi-access Edge Applications and UEs, or between network and authorized Multi-access Edge Appli-cations or between two authorized Multi-access Edge AppliAppli-cations. In the end, to support applications with synchronization requirements, The ME Platformhas to have a means to ac-quire accurate Time of Day informationand make this information available to the hosted applications.

(20)

3.3.3 Features

The concept of features is introduced in order to cater for the different needs of different deployments. A feature is defined as a group of related requirements, identified by an unique name, and can be mandatory, optional or conditional. The standardized features are:

• UserApps • SmartRelocation • RadioNetworkInformation • LocationService • BandwidthManager • UEIdentity

UserAppsis an optional feature that implies the support to: 1) the instantiation of a ME Appli-cation on multiple Multi-access Edge Hosts following a single instantiation request, or when required by the operator in response to a request by the user; 2) the establishment of the connec-tivity between the UE and an instance of a specific ME Application fulfilling the UE require-ments, and, if no instance of the application fulfilling these requirements is currently running, the Multi-access Edge System Management shall create a new instance and then shall connect the UE and the new application instance; 3) the termination of a ME Application instance when no UE is anymore connected to it or when following a single termination request.

SmartRelocationis a conditional feature, that requires the support to the UserApps fea-ture. The SmartRelocation provides the support to: 1) the relocation of a ME Application instance from one ME Host to a different host within the system; 2) the move of a ME Application in-stances between Multi-access Edge Hostsin order to continue to satisfy the requirements of the ME Application .

RadioNetworkInformationis an optional feature that: 1) exposes up-to-date radio network informationregarding the current radio network conditions at the relevant granularity (e.g. per User Equipment or per cell, per period of time); 2) provides information related to UEs connected to the radio node(s) associated with the ME Host, their UE context and the related radio access bearers.

LocationServiceis an optional feature that provides: 1) the information about the location of specific UEs currently served by the radio node(s) associated with the ME Host ; 2) the infor-mation about the location of all UEs currently served by the radio node(s) associated with the ME Host ; 3) the information about the location of a certain category of UEs currently served by the radio node(s) associated with the ME Host ; 4) the list of UEs in a particular location; 5) the information about the location of all radio nodes currently associated with the ME Host.

BandwidthManageris an optional feature that: 1) enables an authorized ME Application to register statically and/or dynamically its bandwidth requirements and/or priority; 2) allocates bandwidth and/or assign priority to any session or to any application.

UEIdentity is an optional feature that: 1) provides functionality for a ME Application to register a token (representing a UE) or a list of tokens; 2) allows the setting of packet filters for routing traffic based on a token representing the UE; 3) allows the routing of user-plane traffic

(21)

of authorized UEs to a local network (e.g. enterprise network) connected to the ME Host without having to route the traffic via a ME Application; 4) supports the connectivity between authorized Multi-access Edge Applications and local networks connected to the host.

3.4 Framework and Architecture

The ETSI MEC 003 [7] defines the framework and the architecture of a Multi-access Edge Com-puting System, and describes it as an entity that enables the implementation of Multi-access Edge Applicationsas software-only entities that run on top of a Virtualisation Infrastructure, which is located in or close to the network edge.

3.4.1 Framework

The Multi-access Edge Computing framework, illustrated in figure 3.2, shows the general en-tities involved. These enen-tities can be grouped into network level, host level and system level entities:

1. The Network level is the Network Infrastructure, independent from the ME Hosts 2. The ME Host level is the physical node with virtualized resources, services and all the

local management logic

3. The Multi-access Edge System level is the external users and all the global manage-ment logic to link the requestes from UE Applications to the most suitable ME Host

3.4.2 Architecture

The Multi-access Edge Computing architecture, illustrated in figure 3.3, shows the functional elements that comprise the Multi-access Edge System and the reference points (dependencies) between them: 1) Mp are reference points regarding the ME Platformfunctionalities; 2) Mm are reference points regarding the management functionalities; 3) Mx are reference points connecting to external entities.

Multi-access Edge System

The Multi-access Edge System consists of the Multi-access Edge Hosts and the Multi-access Edge Managementnecessary to run Multi-access Edge Applications within an operator network or a subset of an operator network.

ME Host

The ME Host is an entity that contains a Multi-access Edge Platform and a Virtualisation Infrastructurewhich provides compute, storage, and network resources, for the purpose of running Multi-access Edge Applications. The Virtualisation Infrastructure includes a data plane that executes the traffic rules received by the Multi-access Edge Platform, and routes the traffic

(22)

Figure 3.2: Multi-access Edge Computing Framework

among applications, services, DNS server/proxy, 3GPP network, local networks and external networks.

Multi-access Edge Platform

The Multi-access Edge Platform is the collection of essential functionalities required to run Multi-access Edge Applicationson a particular Virtualisation Infrastructure. The platform, fur-thermore, enables the Multi-access Edge Applications to provide and consume Multi-access Edge Services. The Multi-access Edge Platform can also provide services and it is responsible for: 1) offering an environment where the Multi-access Edge Applications can discover, adver-tise, consume and offer Multi-access Edge Services; 2) hosting Multi-access Edge Services, possi-bly including General Services: i.e. RadioNetworkInformation, Location, BandwidthManager; 3) providing access to persistent storage and time of day information; 4) receiving traffic rules from the ME PlatformManager, applications, or services, and instructing the data plane ac-cordingly. When supported, this includes the translation of tokens, representing UEs in the

(23)

Figure 3.3: Multi-access Edge Computing Architecture

traffic rules, into specific IP addresses; 5) receiving DNS records from the ME PlatformManager and configuring a DNS proxy/server accordingly;

Multi-access Edge Applications

The Multi-access Edge Applications are applications provided by Multi-access Edge Hosts and instantiated based on configuration or requests validated by the Multi-access Edge Manage-ment. A Multi-access Edge Applications instance, called User Application, runs as virtual machines (VM)on top of the Virtualisation Infrastructure provided by the ME Host , and can interact with the Multi-access Edge Platform to consume and provide Multi-access Edge Ser-vices. In certain cases, they can also interact with the Multi-access Edge Platform to perform support procedures related to the application lifecycle, such as indicating resource availability or preparing relocation of user state. Multi-access Edge Applications can have a certain number of rules and requirements associated to them, such as required resources, maximum latency, required or useful services, etc. These requirements are validated by the Multi-access Edge System Level Management, and can be assigned to default values if missing.

Multi-access Edge Management

The Multi-access Edge Management comprises the Multi-access Edge System Level Man-agement, responsible to handle requestes from external entities and instructing the ME Host

(24)

Level Managementto fulfill the requestes validated.

The Multi-access Edge System Level Management includes the Multi-access Edge Or-chestrator, the Operations Support System (OSS) and the User Application Lifecycle Management Proxy.

The Multi-access Edge orchestrator is the core functionality in Multi-access Edge System Level Managementand it is responsible for: 1) maintaining an overall view of the Multi-access Edge Systembased on deployed access Edge Hosts, available resources, available Multi-access Edge Services, and topology; 2) performing on-boarding of application packages, includ-ing checkinclud-ing the integrity and authenticity of the packages, validatinclud-ing application rules and requirements, and ,if necessary, adjusting them to comply with operator policies; 3) keeping a record of on-boarded packages and preparing the Virtualisation Infrastructure Manager(s) to handle the applications; 4) selecting appropriate ME Host (s) for application instantiation, based on constraints such as latency, available resources, and available services; 5) triggering application instantiation and termination; 6) triggering, when supported, application reloca-tion.

The Operations Support System (OSS) receives requests via the CFS portal and from UE Applicationsfor instantiation or termination of applications, and decides on the granting of these requests. Granted requests are forwarded to the Multi-access Edge Orchestrator for further processing. When supported, the OSS also receives requests from UE Applications for relocating applications between external clouds and the Multi-access Edge System.

The User Application Lifecycle Management Proxy allows UE Applications to request on-boarding, instantiation, termination of User Applications and, when supported, their reloca-tion in and out the Multi-access Edge System. It also allows informing the UE Applicareloca-tions about the state of the User Applications. The User Application Lifecycle Management Proxy authorizes requests from UE Applications and interacts with the OSS and the Multi-access Edge Orchestra-torfor further processing of these requests. The User Application Lifecycle Management Proxy is available only when supported by the Multi-access Edge System and it is accessible only from within the mobile network.

The ME Host Level Management comprises the ME PlatformManager and the Virtu-alisation Infrastructure Manager, and handles the management of the Multi-access Edge specific functionalities of a particular ME Host and the applications running on it.

The ME PlatformManager is responsible for: 1) managing the lifecycle of applications including informing the Multi-access Edge Orchestrator of relevant application-related events; 2) providing management functions to the Multi-access Edge Platform; 3) managing the appli-cation rules and requirements including service authorizations, traffic rules, DNS configura-tion and resolving conflicts; 4) receiving virtualised resources fault reports and performance measurements from the Virtualisation Infrastructure Manager for further processing.

The Virtualisation Infrastructure Manager is responsible for: 1) allocating, manag-ing and releasmanag-ing virtualised resources (compute, storage and networkmanag-ing) of the Virtualisa-tion Infrastructure; 2) preparing the VirtualisaVirtualisa-tion Infrastructure to run a software image. The preparation includes configuring the infrastructure, receiving and storing the software im-age; 3) when supported, rapid provisioning of applications, as described in "Openstack++ for Cloudlet Deployments"; 4) collecting and reporting performance and fault information about

(25)

the virtualised resources; 5) when supported, performing application relocation. For applica-tion relocaapplica-tion from/to external cloud environments, the Virtualisaapplica-tion Infrastructure Manager interacts with the external cloud manager to perform the application relocation.

3.5 Platoon Formation and Stability with MEC

In section 2.2.1 we have seen that some technical issues in Vehicle Platooning regard Platoon Formation and Stability. In this section we propose an approach to cope with Platoon Forma-tion, by means of a centralized Multi-access Edge Computing Service, combined with a Longitu-dinal Controller, that assures Platoon Stability at safe and speed-dependent distancies, proposed by Scheuer, Simonin and Charpillet. This approach leverages on Multi-access Edge Computing technology deployed in a Long Term Evolution network: MEC technology provides context-aware services able to use real-time traffic updates, road-maps and other vehicular-related informations, while LTE network guarantees low latencies and high reliability for vehicular application communications.

Figure 3.4: Example of network scenario combining LTE, MEC and VANETs.

3.5.1 ME Platoon-Formation Service

The ME Platoon-Formation Service proposed consists of a clustering algorithm to identify vehi-cles elegible to form a platoon along the roads and a cruise controller to regulate their acceler-ations in such a way to converge in the desired formation.

Generic Platoon-based Clustering Algorithm

The Clustering Algorithm deals with Platoon Formation by building up chains of vehicles able to form a platoon. The algorithm comprises three phases:

1. For each vehicle identify its vehicle adjacency list: other vehicles with similar charac-teristics (i.e. road-line, traveling direction, traveling velocity, travel destination, etc.)

(26)

2. For each vehicle select its follower vehicle among its vehicle adjacency list by following a given policy (i.e. spacial-closest adjacency)

3. For each leader vehicle, that is the vehicle following none, piece togheter the vehicle-chain, forming the platoon, by crossing all the follower vehicles

Implemented Platoon-based Clustering Algorithm

In chapter 7 we implement a simplified version of the above clustering algorithm that works on a simplified scenario in which vehicles are placed alongside straight roads and have a simple mobility dynamic. It takes into account positions and directions of all the vehicles within the MEC System covered areato identify possible platoons.

1. The vehicle adjacency list is computed by selecting as adjacent vehicles the ones with the same traveling direction and within a specific geometric area (i.e. rectangle, tri-angle) among all vehicles within the MEC System covered area running the related ME Application. The geometric area is specified by parameters defining the shape.

Figure 3.5: Platoon-based Clustering Algorithm with rectangle areas

Figure 3.5 shows an example of vehicle adjacency list computation: for example car1 vehicle adjacency list comprires only car2, while car2 vehicle adjacency list comprises car3and car4. Meanwhile car6, car7 and car8 have an empty vehicle adjacency list. 2. The follower vehicle is choosed among a vehicle adjacency list considering the closest

one given their positions. Considering figure 3.5 the car1 follower is car2, while car2 follower is car3 because it is closer to car2 respect to car4.

3. The platoon is pieced togheter from the leader vehicle, moving through its follower vehicles. Taking in consideration figure 3.5, car1 is the platoon leader of a platoon formed by: car1, car2, car3, car4 and car5; while car6, car7 and car8 are vehicles not platooned, that can be considered as platoon with only a single vehicle: the platoon leader.

(27)

Safe Longitudinal Controller

The Longitudinal Platoon Stability problem can be formulated as the control in acceleration of a vehicle with respect to a previous one which it tries to follow as close as possible. In normal driving conditions, the state of each vehicle can be characterized by its location and orientation in the plane (three degrees of freedom constrained) and its longitudinal and angular speeds (linked through its front wheel angle). We adopt the Scheuer, Simonin and Charpillet controller that assures collision avoidance by maintaing safe inter-vehicle distancies.

Figure 3.7: Scheme for Longitudinal Controller

Considering figure 3.7 the vehicle n can avoid collision with vehicle n − 1 after time i ∗ δt, whatever the behavior of the previous one. Thus the worst case is considered: when vehicle n − 1brakes at maximum capacity the collision-free behavior exists if and only if maximum braking of vehicle n allows to avoid collision. This is true when:

di_n >= dcrit+ max(0, v_ni2− vi n−1 2 −2amin ) (3.1)

where aminis the minimum acceleration (or maximum deceleration) for all vehicles.

Let be δdi n= din− dcrit+ min(0, vi n 2_−vi n−1 2

−2amin ), then inequality 3.1 can be written simply as δd

i n>

0. Analytical developments show this inequality is verified when acceleration ai

n remains

lower than or equal to alim(din, vni, vn−1i ).

alim(din, v i n, v i n−1) = min(amin+ 2 ˜ di n− dcrit+ ( ˜vin−1,n− ˜vin)¯t 3δt2 , q (˜vi

n− aminδt₂)2− 2aminδd˜in− ( ˜vin− 3₂aminδt)

δt ,

q ( ˜vi

n+ (amax−amin₂ )δt)2− 2 ∗ aminD˜in− ( ˜vin+ (amax− 3₂amin)δt)

δt ) (3.2) where: • ˜di n= din+ (vn−1i − vni)δt + (amin− amax)δt 2 2 • ˜vi n−1,n = vin−1+ aminδt • ˜vi n= vni + amaxδt

(28)

• ˜δdi n = ˜din− dcrit+ ( ˜vi2 n− ˜vi 2 n−1,n) 2amin • ˜Di n= max(0, ˜δdin−

(amax−amin)( ˜vin+amaxδt₂ )δt

−amin ) + (amax− amin)δt

2.

This controller can be simply combined with other controllers, like Daviet and Parent Longi-tudinal Controller[17], by taking the minimum value between the computed accelerations.

(29)

Chapter 4 OMNeT++ Simulator

In this chapter we describe OMNeT++, the tool used for the implementation of the MEC ex-tension for the SimulLTE simulator. The section 4.1 introduces the framework, the modeling strcuture and the cionfiguration of a simulation scenario; while in section 4.2 is described the modeling of the classical Tic-toc example [3].

4.1 What is OMNeT++

OMNeT++ [19], [1] is a simulation framework that provides infrastructure and tools to build simulations. This framework has the following characteristics:

• Modular: network models are built assembling together several modules.

• Discrete-event driven: operations are represented as chronological sequence of events. Each event happens at a given instant, modifies the system state and, eventually, gener-ate successive events.

• Object-oriented: programming languages are C++ and NED. • Open source: OMNeT++ is free for academic use.

OMNeT++ has a generic architecture, so it can be used for modeling and simulation of any sys-tem where discrete-event approach is suitable, and can be conveniently mapped into entities communicating by exchanging messages. For example:

• Modeling of wired and wireless communication networks. • Protocol modeling.

• Modeling of queueing networks.

• Modeling of multi-processors and distributed hardware systems. • Evaluation of complex software systems.

(30)

4.1.1 Modeling Concepts

Hierarchy

A network model, in OMNeT++, consists of modules that communicate with message passing. A module can be either:

• Simple: it is the active components of the model, i.e. implement the operations executed by the module.

• Compound: it is a container of simple/compound modules. Its behavior is defined by the interactions between inner modules.

The whole model, called Network, is itself a compound module.

Figure 4.1: OMNeT++, simple and compound modules

Communication

Messages exchanged between modules may carry arbitrary data structures. Messages can be sent in two ways:

• Directly from the sender module to the receiver module. • Via gates.

Gates are the input/output interfaces of modules and are linked together by connections. Con-nections are created within a single level of module hierarchy: within a compound module, corresponding gates of two submodules or a gate of one submodule and a gate of the com-pound module can be connected. Comcom-pound modules transparently relay messages from the inside world to the outside world. To facilitate the modeling of communication networks, con-nections can be used to model physical links. Concon-nections support the following parameters:

• Data rate.

• Propagation delay. • Bit error rate. • Packet error rate.

(31)

Customization

Modules can have parameters, which can be used to customize simple module behavior and to parameterize the model topology. Parameters can take string, numeric, boolean values or can contain XML data trees. Within a compound module, parameters can define the number of submodules, number of gates and the way the internal connections are made.

4.1.2 Building a Simulation

An OMNeT++ model consists of the following parts:

• NED language topology descriptions (.ned files) that describe the model structure with parameters, gates, etc.

• Message definitions (.msg files). OMNeT++ will translate message definitions into C++ classes.

• Simple module sources (.h/.cc files).

In addition to the above components, the simulation system provides the following:

• Simulation kernel, which contains the code that manages the simulation and the simu-lation class library.

• User interfaces, used in simulation execution.

Furthermore, a configuration file (.ini) has to be provided. The configuration file can also prescribe several simulation runs.

4.2 Example of Simulation

Let us consider a simple example of a network, called “Tictoc” [3]. There are two nodes, “tic” and “toc”, linked together by a connection with propagation delay T. The “tic” node creates the first packet and the two nodes will keep passing the same packet back and forth. In order to realize the above network, the following steps are needed:

• Network description in NED language. The two nodes have the same NED type, but the implementation is different.

1 // Simple module for tic or toc

2 simple Txc {

3 gates:

4 input in;

5 output out;

6 }

7 // Two instances (tic and toc) of Txc1 connected both ways.

8 network Tictoc {

9 submodules:

10 tic: Txc;

(32)

12 connections:

13 tic.out --> { delay = T } --> toc.in;

14 tic.in <-- { delay = T } <-- toc.out;

15 }

16

• Implementation of the C++ simple module.

– The initialize() is called at the network initialization once for each module. – The handleMessage() is called whenever a module receive a message.

1 #include "string.h" 2 #include "omnetpp.h"

3 class Txc : public cSimpleModule {

4 protected:

5 // The redefined virtual function holds the algorithm

6 virtual void initialize();

7 virtual void handleMessage(cMessage *msg);

8 };

9 // The module class needs to be registered with OMNeT++

10 Define_Module(Txc);

11 void Txc::initialize() {

12 // Initialize bootstaps the tic-toc-.. process

13 // Am I Tic or Toc?

14 if (strcmp("tic", getName()) == 0) {

15 // "tic" creates and send first message on gate "out".

16 cMessage *msg = new cMessage("tictocMsg");

17 send(msg, "out");

18 }

19 }

20 void Txc::handleMessage(cMessage *msg) {

21 // The handleMessage() called whenever a message arrives.

22 // Both modules bounce the message back to its counterpart.

23 send(msg, "out");

24 }

25

• Definition of messages (not needed in this example). • Network configuration, i.e. writing the .ini file.

1 # omnetpp.ini 2 [General]

3 network = Tictoc

4

(33)

Chapter 5 SimuLTE Framework

In this chapter we take an overview of the SimuLTE Framework. The section 5.1 describes the framework and the modeling of the UE and eNodeB nodes; in section 5.2 are described all the submodules of the LTE Network Interface Card (NIC)[2] and finally in section 5.3 is described the modeling of the GPRS Tunneling Protocol.

5.1 Overview of SimuLTE

SimuLTEsimulates the data plane of the LTE/LTE-A Radio Access Network and Evolved Packet Core. SimuLTE allows simulation of LTE/LTE-A in Frequency Division Duplexing (FDD) mode, with heterogeneous eNBs (macro, micro, pico, etc.), using omnidirectional and anisotropic antennas, possibly communicating via the X2 interface. Realistic channel models, MAC, and resource scheduling in both directions are supported. The Radio Resource Control (RRC) is not modeled. The general structure of the three main nodes is shown in Fig. 5.1. SimuLTE im-plements eNBs and UEs as compound modules. These can be connected with each other and with other nodes (e.g., routers, applications, etc.) in order to compose networks. The binder

(34)

module is instead visible by every other node in the system and stores information about them, such as references to nodes. It is used, for instance, to locate the interfering eNBs in order to compute the intercell interference perceived by a UE in its serving cell. UE and eNB are fur-ther composed of modules. Every module has an associated description file (.ned) defining its structure, and may have a class definition file (.cpp,.h) which implements the module function-alities. The UDP and TCP modules, taken from the INET package, implement the respective transport layer protocols, and connect the LTE stack to TCP/UDP applications. As figure 5.1 shows, TCP and UDP applications (TCP App and UDP App) are implemented as vectors of N modules, thus enabling multiple applications per UE. Each TCP/UDP App represents one end of a connection, the other end of which may be located within another UE or anywhere else in the topology. SimuLTE comes with models of real-life applications (e.g., VoIP and Video on Demand), but any other TCP/UDP-based OMNeT++ application can also be used. The IP module is taken from the INET package as well. In the UE it connects the Network Interface Card (NIC)to applications that use TCP or UDP; in the eNB it connects the eNB itself to other IP peers (e.g., a web server), via PPP (Point-To-Point Protocol). The NIC module, whose struc-ture is shown in figure 5.2, implements the LTE stack. It has two connections: one between

Figure 5.2: NIC module architecture on UE

the UE and the eNB and one with the LTE IP module. It is built as an extension of the IWire-lessNic interfacedefined in the INET library, so as to be easily plugged into standard scenarios. This allows one—among other things—to build hybrid connectivity scenarios, e.g., with nodes equipped withboth Wi-Fi and LTE interfaces. With reference to figure 5.2, each of the NIC submodules on the left side represents one or more parts of the LTE protocol stack, which is common to the eNB as well. The only module in the UE that has no counterpart in the eNB is the Feeback Generator, which creates channel feedbacks that are then managed by the PHY module. The communication between modules takes place only via message exchange, thus each action starts from a message handler. Cross-module calls are used only in the form of getter/setter functions. This allows to maintain a strong control over the interactions between modules, thus limiting possible buggy behaviors.

(35)

5.2 LTE NIC module

In the following is described each submodule composing the LTE NIC module with their related functionalities. Downstream and upstream are used, respectively, to identify the flow of traffic from an upper to a lower layer within the same module and vice versa, and downlink and uplink for the traffic flow from the eNB to the UE and vice versa.

5.2.1 PDCP-RRC Module

The PDCP-RRC module is the connection point between the NIC and LTE IP modules. The PDCP-RRCmodule receives data from upper layers in the downstream direction and from the RLC layer in the upstream. In the first case it performs RObust Header Compression (ROHC) and assigns/creates the Connection Identifier (CID) that uniquely identifies, together with the UE ID, a connection in the whole network. A Logical Connection Identifier (LCID) is kept for each 4-tuple in the form <sourceAddr, destAddr, sourcePort, destPort>. When a bpacket arrives at the PDCP-RRC module, the correct LCID is attached to it (if there exists one), otherwise a new one is created storing the new 4-tuple. Then, the packet is encapsulated in a PDCP PDU and forwarded to the proper RLC port, depending on the selected RLC mode, as described in subsection 5.2.2. In the upstream, a packet coming from the RLC is decapsulated, its header is decompressed and the resulting PDCP PDU is sent to the upper layer.

5.2.2 RLC Module

The RLC module performs multiplexing and demultiplexing of MAC SDUs to/from the MAC layer, implements the three RLC modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM), and forwards packets from/to the PDCP-RRC to/from the proper RLC mode entity. RLC operation is the same on both the eNB and the UE. The structure of the RLC module is shown in figure 5.3. There are three different gates connected with the PDCP-RRC module, one for each RLC mode. The TM submodule has no buffer, as it forwards packets transparently, while AM and UM have their own set of transmission/reception buffers, one for each CID associated to that RLC mode.

(36)

5.2.3 MAC Module

The textbfMAC module is where most of the intelligence of each node resides. Its main tasks are buffering packets from upper (RLC) and lower layers (PHY), encapsulating MAC SDUs into MAC PDUsand vice versa, managing channel feedback, adaptive modulation and coding (AMC), and scheduling. Those operations are the same at the UE and the eNB, with scheduling and channel-feedback management being the only exceptions. The high-level structure of the MAC is shown in figure 5.4.

Figure 5.4: MAC packet flows

In the downstream, MAC SDUs coming from the RLC layer are stored in MAC Buffers, one for each CID. On each TTI some connections are scheduled for transmission, according to the schedule list composed by the scheduler. MAC SDUs from the scheduled connections are then encapsulated into MAC PDUs, which are then stored in the H-ARQ buffers and forwarded to the physical layer. The detailed structure of H-ARQ buffers will be explained later on. In the upstream, MAC PDUs coming from the physical layer are stored into H-ARQ buffers. They are then checked for correctness, decapsulated and forwarded to the RLC. The entities involved in eNB scheduling are shown in figure 5.5. Resource scheduling is performed at the eNB for both the uplink and the downlink. For the uplink, decisions are notified to the UEs via grant messages, i.e., in the current release the Physical Downlink Control Channel (PDCCH) is not directly simulated. Each UE reads the grants and decides which local connection will be able to use the granted resources, if any. UEs in turn request uplink resources via the Random Ac-cess (RAC) Procedure, which is again implemented through messages generated by the MAC module. The Physical Random Access Channel (PRACH) is not directly simulated. In order to properly make scheduling decisions, both downlink and uplink schedulers need the status of user connections and the channel quality perceived by each UE. The downlink connection status is inferred directly from MAC buffers, while in the uplink the status is inferred from virtual uplink buffers. The latter are kept synchronized with the real MAC buffers on the UE side via Buffer Status Reports (BSR), which are control elements attached to uplink transmis-sions. The Adaptive Modulation and Coding (AMC) entity stores channel status information from the UE reports, deciding (Pilot entity) and storing (User Tx Params entity) transmission parameters such as modulation and coderate, andcomputing the amount of bytes per resource

(37)

Figure 5.5: MAC scheduling operations

block for each user based on those parameters. As far as H-ARQ is concerned, Transmission and Reception H-ARQ Buffers (from now on TxHbuff and RxHbuff) store MAC PDU that are being sent andreceived, respectively. This means that a MAC PDU is stored therein until it is received correctly or the maximum number of retransmissions is reached. Reception is noti-fied via H-ARQ feedback messages. H-ARQ buffers on the eNB maintainMAC PDU information for each connected UE in both downlink and uplink, for each H-ARQ process and for each codeword (hence, these modules require no modification to support Single-User MIMO). The general structure shown in figure 5.6 is valid for both Tx- and Rx-Hbuffs, hence the neutral Hbuff to denote both. A Hbuff contains K buffers, one for each active connection to another node. Hence an eNB has as many buffers as connected UEs in each direction, whereas a UE has up to one per direction, as it communicates directly only with its serving eNB. Each buffer contains N processes (N = 8, usually), one per H-ARQ process. Finally, each process contains two units, to support SU-MIMO. A unit contains the information related to a transmitting/re-ceiving MAC PDU. The status of the unit is stored in a different manner on TX- and RX-buffs as it depends on the feedback management procedure. The finite state automata for trans-mission is represented in Fig. 8 (the one for reception is similar, mutatis mutandis). ACK and NACK are the reception of the corresponding H-ARQ feedback. TxCount is the transmission counter, increased in the SELECTED state and reset in the EMPTY one. MAX_TX is the max-imum number of transmissions before discarding a PDU. The hierarchy of eNB schedulers is shown in the left part of figure 5.8. The eNB Scheduler base class implements operations that are common to the DL and UL, such as data structures initialization, allocation management via the allocator, andstatistics collection. The two classes eNB Scheduler UL and DL extend the base class by implementing the rtxSchedule() method, which manages retransmissions. In addition the eNB Scheduler UL manages RAC requests. At the beginning of each TTI the eNB prepares a schedule list in each direction, which shares available resources among the active connections, according to a given policy. This is performed by a member of the eNB Scheduler called Scheduling Policy. Its main function, schedule(), consists of two steps: first, the schedul-ing policy is applied on a set of virtual connections, without modifyschedul-ing MAC buffers; then the decisions are stored and passed to the MAC, which enforces them by fetching the data from

(38)

Figure 5.6: Common Hbuff structure

Figure 5.7: Finite state automata for unit status in TX

its buffers and constructing the PDUs (see again figure 5.5). The scheduling policy builds the schedule lists by repeatedly polling the allocator for given amounts of bytes transmitted at the CQI of the connection being examined. This allows one to envisage general schedulers, that decide both the priority order of connections and the amount of data to be scheduled from each: for instance, schedulers that only serve urgent data from each connection (instead of attempting to empty each queue sequentially), or set fixed quanta. The fact that scheduling occurs in two steps allows a user to run multipleschedulers in parallel, choosing which sched-ule list to commit among a set of alternatives. The scheduling policy hierarchy is shown in the right part of figure 5.8. To implement a new scheduling policy, a developer only needs to implement the two steps of the schedule() function. Three well-known scheduling poli-cies are included in the current release, namely Maximum Carrier over Interference (Max C/I), Proportional Fair (PF), Deficit Round Robin (DRR). Finally scheduling policies may redefine the rtxSchedule() function. Retransmissions can be scheduled either at a higher/lower priority than first transmissions, or jointly with them.

(39)

Figure 5.8: eNB schedulers and Scheduling Policy hierarchy

5.2.4 PHY Module

The PHY module implements functions related to the physical layer, such as channel-feedback computation and reporting, data transmission and reception, air channel emulation and control messages handling. It stores the physical parameters of the node, such as the transmission power and antenna profile (i.e., omnidirectional or anisotropic). This allows one to define macro-, micro-, pico-eNBs, with different radiation profiles. Each physical module on the eNB and the UE has an associated channel model C++ class that represents the physical channel as perceived by the node itself. The channel model is an interface that defines two main functions: getSINR(), which returns the Signal to Interference plus Noise Ratio (SINR), and error(), which checks if a packet has been corrupted. The current implementation of the channel model is described later on, but one can easily implement its own model by implementing the channel model interface. On the UE side, some tasks related to physical layer procedures are performed by an independent Feedback Generator module. This module generates channel feedback (i.e., CQIs), which can be configured to be periodic or aperiodic. Furthermore, CQIs can be either wideband or per-sub-band: in the latter case, the user can configure the number of sub-bands and of reported CQIs. The feedback generation process exploits the function provided by the channel model interface. Note that the physical LTE channels, such as the Physical Downlink Control Channel (PDCCH), Physical Uplink Control Channel (PUCCH), and Physical Random Access Channel (PRACH)are not modeled down to the level of OFDM symbols, to keep both memory and CPU usage limited. Their functionalities are instead implemented via control messages sent between the eNB and UE nodes. Any limitation of those channels, (e.g., on the maximum number of UEs that can be scheduled simultaneously on the PDCCH), can never-theless be emulated by imposing constraints on the messages themselves. In the downstream, MAC PDUs are received from the MAC layer and encapsulated in an Air Frame packet. Pack-ets are marked with a Type, i.e., data or control, then they are directly sent to their destination module, selected according to the control information attached to the packet. In the upstream, a received Air Frame packet is selectively processed depending on its type: control packets are directly forwarded to the upper layer (assuming correct reception), whereas data packets are tested against the error() function of the channel model before being marked and sent to the upper layer. The provided implementation of the channel model interface is called Realistic Channel Model. The SINR is computed as SINR = PeN B

RX /(ΣiPRXi + N ), where PRXeN Bis the

power received from the serving eNB, Pi

RX is the power received from the interfering eNBi,

N is the Gaussian noise. Furthermore,PRX is computed as PRX = PT X − Ploss − F − S,

where PT Xis the transmission power, Plossis the path loss due to the eNB-UE distance (which

Platoon Formation and Stability with Multi-access Edge Computing in LTE-Advanced networks

Department of Information Engineering

Computer Engineering

Master Degree Thesis

Platoon Formation and Stability

using Multi-access Edge Computing in

LTE-Advanced networks

Speakers:

Ing. Giovanni Stea

PhD. Giovanni Nardini

PhD. Antonio Virdis

Presented by:

Angelo Buono

Academic Year 2017/2018

September 16, 2018

Acknowledgements

First of all I’ve to thank my mother, who always

encouraged me on keeping studying, and my father, who

taught me to take life as it comes. Thank you Filomena and Luigi!

I’ve to thank my grandmother Giuseppina for all the love she gives me.

A very big thanks is for Alfonso, Carmine, Jonas and Vittorio

for making my days more cheerful and fun.

Thank you, Alessia, for believing in me and bringing a sunshine in my life.

An huge thanks is for my speakers that gave me this chance.

Thank you so much, Giovanni, for supporting me during all these months.

Thank you Corrado, Mariano, Maria and Martina

for all the funny moments spent doing projects and studying together.

Last but not least thanks so much to all my relatives and friends

that I can’t list one by one. Please forgive me!

Contents

Chapter 1

Introduction

Chapter 2

Vehicle Platooning

2.1

What is Vehicle Platooning

2.1.1

Platoon-based applications

2.2

Platoon-based Vehicular Cyber-Physical System

2.2.1

Technical issues for Platoon-based VCPS

Chapter 3

Multi-access Edge Computing

3.1

Definitions

3.2

Application Domains

3.3

Principle, Requirements and Features

3.3.1

Principles

3.3.2

Requirements

3.3.3

Features

3.4

Framework and Architecture

3.4.1

Framework

3.4.2

Architecture

3.5

Platoon Formation and Stability with MEC

3.5.1

ME Platoon-Formation Service

Chapter 4

OMNeT++ Simulator

4.1

What is OMNeT++

4.1.1

Modeling Concepts

4.1.2

Building a Simulation

4.2

Example of Simulation

Chapter 5

SimuLTE Framework

5.1

Overview of SimuLTE