Efficient Millimeter-Wave Infrastructure Placement for City-Scale ITS

TL;DR

This paper proposes a scalable, city-specific strategy for deploying millimeter-wave roadside nodes in urban environments to meet ITS QoS needs while reducing infrastructure costs by up to 50%.

Contribution

It introduces an agile, city-aware deployment method for mmWave infrastructure that outperforms existing solutions in efficiency and scalability.

Findings

Achieves up to 50% reduction in node count.

Ensures high throughput and low latency in urban scenarios.

Effective for both regular and irregular city layouts.

Abstract

Millimeter Waves (mmWaves) will play a pivotal role in the next-generation of Intelligent Transportation Systems (ITSs). However, in deep urban environments, sensitivity to blockages creates the need for more sophisticated network planning. In this paper, we present an agile strategy for deploying road-side nodes in a dense city scenario. In our system model, we consider strict Quality-of-Service (QoS) constraints (e.g. high throughput, low latency) that are typical of ITS applications. Our approach is scalable, insofar that takes into account the unique road and building shapes of each city, performing well for both regular and irregular city layouts. It allows us not only to achieve the required QoS constraints but it also provides up to $50\%$ reduction in the number of nodes required, compared to existing deployment solutions.

Figures

Tables

Table 1. Table I: List of Map Areas Used and Simulation Parameters.

Urban Area	Manhattan, NY, USA	Paris, FR
Centre	$-73.9841°W,40.75545°N$	$2.33235°W,48.875°N$
Number of Maps	$2\times 2$	$2\times 2$
Map Size $[{ℳ}_x,{ℳ}_y]$	$1\mathrm{km}$ $\times$ $1\mathrm{km}$	$1\mathrm{km}$ $\times$ $1\mathrm{km}$
Area of Interest	$900m$ $\times$ $900m$	$900m$ $\times$ $900m$
Grid-Tile Size	$4m\times 4m$	$4m\times 4m$

Equations

$${\gamma }_n(x,y)=\{\begin{array}{l}1,\text{leavevmode}\mathrm{if}\text{leavevmode}n\text{leavevmode}\mathrm{is}\text{leavevmode}\mathrm{covered}\text{leavevmode}\mathrm{by}\text{leavevmode}\mathrm{at}\text{leavevmode}\mathrm{least}\text{leavevmode}\mathrm{one}\text{leavevmode}\mathrm{RSU}\\ 0,\text{leavevmode}\mathrm{otherwise}\end{array}$$

$$\sum _{n=1}^{|\mathcal{N}|}{\gamma }_n(x,y)\ge \tau \left|\mathcal{N}\right|$$

$$\mathrm{RSS}(d)=P_{\mathrm{tx}}+G_{\mathrm{tx}}-L_{\mathrm{LOS}}(d)$$

$$\sum _{i=1}^{|\mathcal{D}|}\mathrm{RS}{\mathrm{S}}_{\mathrm{i},\mathrm{k}}^{\max }\ge {\mathrm{RSS}}_{th}$$

$$e_i=\{\begin{array}{l}1,\text{leavevmode}\mathrm{if}\text{leavevmode}i\text{leavevmode}\mathrm{is}\text{leavevmode}\mathrm{deployed}\\ 0,\text{leavevmode}\mathrm{if}\text{leavevmode}i\text{leavevmode}\mathrm{is}\text{leavevmode}\mathrm{not}\text{leavevmode}\mathrm{deployed}\end{array}$$

$$\underset{e_1,\dots ,e_{\mathcal{C}}}{\mathrm{Minimise}}$$

$$\sum _{n=1}^{|\mathcal{N}|}{\gamma }_n(x,y)\ge \tau \left|\mathcal{N}\right|$$

$$\sum _{i=1}^{|\mathcal{D}|}\mathrm{RS}{\mathrm{S}}_{\mathrm{i},\mathrm{k}}^{\max }\ge {\mathrm{RSS}}_{th}$$

$$e_i\in \left[0,1\right]$$

$$\mathrm{RS}{\mathrm{S}}_{\mathrm{i},\mathrm{k}}^{\max }\text{leavevmode}\mathrm{for}\text{leavevmode}k\text{leavevmode}\mathrm{in}\text{leavevmode}\mathrm{LOS}$$

Full text

I Introduction

Next-generation Intelligent Transportation Systems (ITSs) will require Vehicle-to-Infrastructure (V2I) wireless connectivity. These communication links offer the potential to enhance the road safety and efficiency in urban vehicular environments [1]. Introducing Millimeter-Waves (mmWaves) for dense urban environments will significantly improve the performance of small-cell access networks [2]. As shown, mmWave-V2I links have the potential of enabling gigabit-per-second data rates and ultra-low latency [3, 4].

The communication capabilities of the vehicles are highly dependent on the number of deployed Road-Side Units (RSUs) and their coverage range. RSUs, are costly to deploy and maintain. Therefore, compromises between the coverage provided and the deployment costs have to be made. MmWave RSUs especially, are bounded by their Line-of-Sight (LOS) requirements and their strict propagation characteristics [5]. However, they are a perfect candidate for small-cell vehicular deployments as they can meet the rigid bitrate and latency Quality-of-Service (QoS) constraints needed by next-generation vehicular applications [3].

It is crucial to deploy a number of RSUs in the most suitable locations, to improve the overall network performance. Given the variety of urban environments, it is necessary to find an agile method to obtain the best locations for each street layout and to deploy thousands of RSUs throughout a city. In this paper, we propose a strategy that can automate the RSU placement process for different urban scenarios. We will take into account the unique road and building layout of an urban environment as well as the strict QoS constraints of vehicular applications. Within a city, buildings may be away from a road or privately owned. Also, city blocks may be empty or covered with vegetation. On the other hand, traffic lights are usually placed at road intersections. Also, street furniture (e.g. lamp posts) are typically equally spread along the sides of a road. In this paper, we assume that our RSUs are deployed on top of lamp posts and traffic lights. Thus, by positioning the RSUs only on the road, easier access for deployment or maintenance is provided. Furthermore, the network efficiency could be improved, as the RSUs are more centrally located on the road, and thus avoiding the wall and rooftop blockages [6].

In [7] and [8], the authors presented an automated base station placement algorithm for mmWaves. However, they did not consider any QoS constraints for their optimization algorithm apart from the LOS coverage rate. In our approach, we consider two main Key Performance Indicators (KPIs). The first one is the LOS network coverage achieved after the deployment of all the chosen RSUs. The second one is the Received Signal Strength (RSS) averaged throughout the considered deployment area. A similar work can be found in [9], where the authors proposed a strategy for placing IEEE 802.11p RSUs. As their optimization variable, they considered the delay tolerance of the warning notifications and solved their optimization problem utilizing a Genetic Algorithm (GA) [10]. However, mmWave links behave differently compared to IEEE 802.11p ones. In this paper, we will address the problem through a novel approach to find the best RSU locations by taking into account the propagation characteristics in mmWaves environments. Similarly, authors in  [11, 12], only considered the distance or the propagation characteristics, but not the shape of the buildings and the roads. In our case, we will utilize tools from Computational Geometry (as in [8]), and consider all the above to find the desirable RSU locations. More specifically, we will investigate the performance of our algorithm under two urban environments, describing their unique characteristics. Our outcome will be compared with solutions obtained by GA and Greedy Construction (GC) [13] algorithms, to strengthen the enhanced performance provided by our approach.

The rest of the paper is organized as follows. In Sec. II we describe our system model. We introduce the tools utilized from Computational Geometry, and how we identify the candidate RSU positions. In Sec. III we formulate our optimization problem based on two QoS constraints. Later, we outline our proposed strategy, solving the above problem. Sec. IV presents our performance investigation where we compare our strategy against the GC and GA approaches described before. Finally, Sec. V summarizes our findings.

II System Model

We consider an urban city map $\mathcal{M}$ with dimensions $\left[\mathcal{M}_{x},\mathcal{M}_{y}\right]$, measured in meters. Let $\mathcal{C}\triangleq\left\{1,\ldots,C\right\}$ denote the candidate RSU positions, with all being within the boundaries of $\mathcal{M}$. For all the above positions we denote as $\mathcal{D}\triangleq\left\{1,\ldots,D\right\}$ the positions chosen to deploy an RSU, and $\mathcal{R}\triangleq\left\{1,\ldots,R\right\}$ the rejected ones. We have that $\mathcal{D}\subseteq\mathcal{C}$, $\mathcal{R}\subseteq\mathcal{C}$, $\mathcal{D}\cup\mathcal{R}=\mathcal{C}$, and $\mathcal{D}\cap\mathcal{R}=\emptyset$ hold.

Our RSU placement algorithm works in two steps:

At first, we identify all locations $\mathcal{C}$ to deploy an RSU employing tools from Computational Geometry. 2. 2.

Then, we choose a subset $\mathcal{D}\subseteq\mathcal{C}$ in order to maximize the outdoor coverage and the RSS for the entire map.

In our system model, we assume that all the RSUs are mounted at the height of a lamp post or a traffic light. We also assume that all vehicles’ antenna will be mounted on their rooftop. By that, we avoid most of the low-level obstacles (for e.g., kiosks, vehicles, trees, etc.). For simplicity, we consider a 2D network planning. Finally, we make use of OpenStreetMap [14] to obtain our city maps.

II-A Identifying Potential RSU Locations

The problem of identifying $\mathcal{C}$ can be approached by using tools from Computational Geometry. Similarly to [8], we introduce the notions of Simple Polygons (SPs) and Polygons With Holes (PWHs) in our system, describing the buildings and the roads, respectively.

A SP is considered a flat-shaped object consisting of straight, non-intersecting line segments, that, when joined pair-wise, they form a closed path. Given a city map, many SPs have adjacent sides, being part of the same city block. Therefore, they can be concatenated using the polygon union operation [15]. Furthemore, concatenating all the adjacent SPs, we may end up having a hole in the middle (e.g. a courtyard). These inner holes can be later removed forming a solid object (as in Fig. 1). By that, and based on the nature of mmWaves (the signal intersecting with an object will result in a blockage), we can decrease the complexity of our algorithm and, consequently, the execution time without any loss of accuracy. Furthermore, PWH is a polygon with an irregular shape that contains one or more holes or cutouts in it. Having access to the metadata from OpenStreetMap, we can accurately calculate the different polygons representing each road. Each polygon is later concatenated with the others, having finally a concave PWH that will be used for the RSU placement. The SPs introduced before, will be used to determine if a link is in LOS or not.

Given the generated SPs and PWHs, we can identify $\mathcal{C}$ for a particular map. Our algorithm searches along the sides of PWHs for sharp edges and long straight sections. The edges, being the corner of two roads, are usually the best positions for an RSU, as they can maximize the LOS coverage (as shown in [7]). We also consider the length of a road. A road qualifies as a “long road” when the distance between two intersections is greater than a given threshold $\mathrm{RSU}_{t}$. For any long road, we consider more potential positions, equally spaced between the two intersections. The number of these positions is given as the ceiling function from the division of the length $l_{i}$ of the road i, over the given threshold, i.e., $\lceil\nicefrac{{l_{i}}}{{\mathrm{RSU}_{t}}}\rceil$. Combining both lists, $\mathcal{C}$ is found.

III Problem Formulation and Solution

Given $\mathcal{C}$, the objective is to find $\mathcal{D}\subseteq\mathcal{C}$ to maximize the network coverage and achieve a minimum RSS throughout the network. The LOS coverage rate is modeled by equally spacing $\mathcal{Z}\triangleq\left\{1,\ldots,Z\right\}$ grid points on the map with equal weights. Each point represents a squared tile having the same RSS throughout its surface. Using a tile-like approach with relatively small tiles, we can decrease the processing power required without having a significant loss of accuracy.

We determine $\mathcal{D}$ by taking into account two different constraints. For a given $\mathcal{Z}$, we consider a set of $\mathcal{N}$ reference points, with $\mathcal{N}\subseteq\mathcal{Z}$, being the grid points on top of the road polygons. We define the binary variable $\gamma_{n}$, to denote the state of a reference point $n$ at location $(x,y)$ as follows:

[TABLE]

Our first constraint imposes that a number of tiles, subset of $\left|\mathcal{N}\right|$, are in LOS with at least one RSU, i.e.:

[TABLE]

where $\tau\in\left[0,1\right]$, is a tolerance factor.

We say that $P_{\mathrm{tx}}$ and $G_{\mathrm{tx}}$ are the transmission power and antenna gain of each RSU. Also, $L_{\mathrm{LOS}}(d)$ is regarded as the propagation loss at a distance $d$. Given the above, we can calculate the RSS for each tile as:

[TABLE]

where $L_{\mathrm{LOS}}(d)$ is the path-loss component and can be calculated as $L_{\mathrm{LOS}}(d)=10\,\alpha\,\log_{10}(d)+C_{\mathrm{att}}(d)$. $C_{\mathrm{att}}(d)$ is the channel attenuation with regard to the distance $d$. It is defined by the rain and atmospheric attenuation as well as the channel attenuation factor $H_{\mathrm{att}}$ for a given mmWave LOS link at $60\text{\,}\mathrm{GHz}$ in urban environments [16], i.e. $C_{\mathrm{att}}(d)=40d+H_{\mathrm{att}}$. Finally, $\alpha$ is the path loss exponent.

For all $\mathcal{D}$, there is a number of tiles $K_{i}$ that surrounds it. Each tile can be served by more than one RSU. We define as $\mathrm{max}_{i\in\left\{1,\ldots,\tau\,\left|\mathcal{N}\right|\right\}}\,\{K_{i}^{\mathrm{RSS}}\}$ the highest received RSS from all RSUs that serve this tile. The interference between the deployed RSUs, is not taken into account. For the entire covered area, we sort all tiles with respect to their received RSS value, we take the first $\tau\,\left|\mathcal{N}\right|$ and denote them as $\mathrm{RSS_{i,k}^{\mathrm{max}}}$. $\mathrm{RSS_{i,k}^{\mathrm{max}}}$ is the average for the best $\tau\,\left|\mathcal{N}\right|$ tiles and for a given $\mathcal{D}_{i}$ Our second constraint ensures that a target number of tiles has an average RSS that is greater than or equal to a threshold $\mathrm{RSS}_{th}$:

[TABLE]

III-A Problem Formulation

Let $e_{\mathcal{C}}$ be the vector that defines the state of each RSU $i$ in $\mathcal{C}$. We have:

[TABLE]

In order to find the best RSU locations, our problem is formulated as the minimization of (5):

[TABLE]

where the above are the constraints described before. Also, the RSS is calculated for all tiles being in LOS with an RSU, i.e. a SP does not block the link. An example solution for a small urban area can be seen in Fig. 2. In this particular example, we can observe the effect of the street geometry on the RSS.

III-B Proposed Algorithm

To solve (6a)-(6e), we propose a novel algorithm to calculate the list $\mathcal{D}$. A city-scale RSU placement problem can be computationally expensive. So, we designed our algorithm to operate in three phases. This can minimize the execution time required for our final solution. Our algorithm (Alg. 1) works are as follows:

III-B1 Phase 1

We start by calculating the number of tiles $k_{i}^{{}^{\prime}}$ required to achieve a mean RSS value greater than or equal to $\mathrm{RSS}_{th}$ for all $\mathcal{C}$. Later, we iteratively add to $\mathcal{D}$ the RSU with the most non-served tiles within $\mathrm{RSS}_{th}$ found before, until constraint (6b) is met. Thus, we ensure a sufficient amount of coverage in our system in a fast greedy-addition-like fashion. If (6c) is also fulfilled, we proceed to Phase 3. If not, we continue with Phase 2.

III-B2 Phase 2

We add more RSUs in the system until both constraints are met. We identify the non-covered areas of the map and prioritize our RSU placement towards them, as this can increase our system performance. Then, we find the areas that are not adequately served by the existing RSUs, and we add RSUs that can fulfill (6c). When both constraints are fulfilled, we have two admissible lists $\mathcal{D}$ and $\mathcal{R}$ and we proceed to the next phase.

III-B3 Phase 3

From the above two phases, we may not always achieve an ideal solution for $\mathcal{D}$. This happens especially when the requirements for a specific scenario are more relaxed (e.g. a low coverage rate is required). To improve the performance at this point, we search in $\mathcal{R}$, if it exists an RSU that can improve (6b) or (6c). If so, we replace these two. We iterate, until no other RSUs can be swapped, meaning that we have our final $\mathcal{D}$.

IV Simulation Results

Our strategy is compared against a GC and a GA approach. For GC, during each iteration, we choose an RSU to add in $\mathcal{C}$, finding the one that has the most LOS tiles from $\mathcal{N}$. We iterate until we meet (2). GC is scalable, but it cannot fulfill the required KPIs, as it does not take into account the RSS threshold. On the other hand, GA is notoriously computationally expensive but generates high-quality solutions. We test all the algorithms in two urban areas from Manhattan (New York, USA) and Paris (FR). An average road lane is $2.9\text{\,}\mathrm{m}4.6\text{\,}\mathrm{m}$ wide. Therefore, we considered a grid with side equal to $4\text{\,}\mathrm{m}$, so each tile covers roughly the width of a road lane. The considered areas and the simulation parameters are summarized in Table LABEL:tab:simParameters.

Each area is 4\text{\,}\mathrm{km}$^{2}$ and divided into four equal sections. Each section is considered as an independent map in our simulation with dimensions $\left[\mathcal{M}_{x},\mathcal{M}_{y}\right]$ and a surface of 1\text{,}\mathrm{km}$^{2}$. The centre coordinates given in Table LABEL:tab:simParameters present the point that the edges of all four sections meet. For each section, we consider an area of interest of $$810\text{,}\mathrm{m}$^{2}$, to avoid border effects. Four different tolerance parameters are employed, namely, $\tau\in\left\{0.85,0.90,0.95,0.99\right\}$), with 90% being an average coverage rate, while 99% being the extreme case. Also, four RSS thresholds are used, that is $\mathrm{RSS}_{th}\in\left\{\mathrm{Inf},-90,-84,-79\right\}$. The first value signifies the case where no RSS threshold is considered. The last one was chosen based on the sensitivity threshold of IEEE 802.11ad, i.e., the minimum RSS (without considering the RX antenna gain) to achieve one-gigabit-per-second data rate. This value is the amount of data estimated to be generated and transmitted from each Connected and Autonomous Vehicle (CAV) [18].

In Fig. 6, we present the RSS results per-tile for Manhattan and all the considered optimization strategies. Also, $\tau=0.99$ and three different thresholds were considered, i.e. $\mathrm{RSS}_{th}\in\left\{\mathrm{Inf},-84,-79\right\}$, to investigate the effect on each approach. We observe that GC always produces similar results, comparable with our scheme (when the RSS constraint is disregarded). That is because GC cannot take into account the RSS threshold. Obviously, as the $\mathrm{RSS}_{th}$ is taken into consideration, we observe that both our algorithm and GA perform better than GC. In particular, our strategy achieved a city-wide mean RSS of $-83.6\text{\,}\mathrm{dBm}$ and $-78.9\text{\,}\mathrm{dBm}$, while GA achieved $-84.3\text{\,}\mathrm{dBm}$ and $-79.2\text{\,}\mathrm{dBm}$ for $\mathrm{RSS}_{th}=$-84\text{,}\mathrm{dBm} and $\mathrm{RSS}_{th}=$-79\text{\,}\mathrm{dBm}, respectively.

Similarly, Fig. 6 presents the RSS results for Paris and $\tau=0.90$. Again, GC algorithm behaves as before, having similar performance for all thresholds and being comparable with our algorithm when $\mathrm{RSS}_{th}$ is not taken into account. However, the main difference compared to the Manhattan results is the performance dissimilarity between our algorithm and GA. We observed that, even with relaxed parameters GA always finds an extreme solution (mean RSS of $-78.8\text{\,}\mathrm{dBm}$ and $-78.5\text{\,}\mathrm{dBm}$ for $\mathrm{RSS}_{th}=$-84\text{,}\mathrm{dBm} and $\mathrm{RSS}_{th}=$-79\text{\,}\mathrm{dBm} respectively), while our algorithm behaves as before (mean RSS of $-86.2\text{\,}\mathrm{dBm}$ and $-80.8\text{\,}\mathrm{dBm}$). This is because of the highly irregular building shapes of Paris, compared to the grid-like shape of Manhattan, making it very difficult for GA to find the best RSU positions in the city and always getting stuck to a local maximum. For both cities, all the algorithms behave similarly to other tolerance parameters and will not be presented here due to the limited space.

In Figs. 6 and 6, we present the number of RSUs required to fulfill the QoS constraints required, for all $\tau$. Fig. 6 refers to the Manhattan scenario, for $\mathrm{RSS}_{th}=$-84\text{,}\mathrm{dBm}$$. Once more, GC utilizes fewer RSUs, but it does not take into account the $\mathrm{RSS}_{th}$. Comparing the number of RSUs obtained with the proposed approach and with GA, we observe that our scheme ensures a reduction of up to $50$% in the number of RSUs compared to GA. From Figs. 6 and 6, we observe that our algorithm achieves comparable results, fulfilling the QoS requirements with a smaller number of RSUs. Moving on to Fig. 6, the difference between the number of RSUs and the two algorithms is greater, having GA solving our optimization problem with almost eight times as many RSUs. Again, as before, this is because of the irregularity of the building and road shapes.

V Conclusions

In this paper, we proposed an agile and efficient strategy for city-wide mmWave-RSU placement. We presented a scalable algorithm, able to compute high-quality RSU deployment on a map. In doing so, the proposed strategy takes into account two KPIs for vehicular communications: the coverage rate and the RSS threshold. Our approach is compared against the GC and GA strategies. GC is fast and scalable, but it cannot satisfy the above mentioned KPIs, while GA is computationally expensive. We observed that our strategy meets the target coverage constraints utilizing a smaller number of RSUs. Also, our performance investigation showed that our approach is suitable for both regular and irregular city layouts when other strategies fail to handle non-uniform building shapes. All the above make it a suitable solution for large-scale experimentation and the next-generation ITSs.

Acknowledgment

This work was partially supported by the University of Bristol and the Engineering and Physical Sciences Research Council (EPSRC) (grant ref. EP/I028153/1). This work is also part of the FLOURISH Project, which is supported by Innovate UK, under Grant 102582.