Interference Minimization
After site selection is complete and finalized, the next step selects the links and sectors in order to minimize interference in the network. At this stage, P2MP, deployment, and interference constraints are incorporated into optimization.
Note: the exact implementation of the objective function and/or constraints in the code might slightly differ from what is written here, but they should be equivalent.
Objective Function
The objective is to minimize the shortage in the network just as in Coverage Maximization.
or
However, we also want as many additional links to be included as possible in order to ensure as much redundancy in the network as possible. Otherwise, the optimizer has no incentive to include links that do not serve to minimize the shortage. Thus, we also include the term
where the weight is a decreasing function of the link's length. Thus, the total objective function becomes
or
where is some large value (i.e., some relative weighting between the two components of the objective function).
Constraints
Most of the constraints are similar to those before (Flow Balance and Flow Capacity are unchanged) but with some slight modifications due to the addition of the link selection decision variable .
Time Division Multiplexing
In addition to the Time Division Multiplexing constraint from before, time division multiplexing on a link is forced to 0 if the link is not selected.
Due to Flow Capacity, this automatically ensures that
Polarity
The polarity of connected sites must be opposite.
This ensures that if , then .
Sector
A sector can only be selected if the site is also selected.
In this case, is no longer a decision variable but simply a value based on the site selection decisions of the previous optimization steps.
When a node contains multiple sectors, if one sector in the node is selected, all sectors in that node are selected. We define to be the node that contains sector k, then
A link can only be selected if the sectors it is connected to are also selected.
Symmetric Link
Backhaul links are bi-directional but are modeled with two separate directed links. If a link is selected, its reverse must also be selected.
Point-to-Multipoint
A DN sector can connect to a limited number of other sectors. The number of DN-DN connections, , and the number of total connections, , are each limited (both are user-specified configurations).
Generally, and .
CN Link
CNs can only have a single incoming link
Deployment Guidelines
We enforce two deployment guidelines/constraints: for any two links leaving different sectors on the same site,
- The angle between them must be at least
- The angle between them must be at least if the ratio of their link distances (larger distance over smaller) is greater than .
Typical values are , and (all are user-specified configurations).
We identify all link pairs and that violate these conditions. Define to be the set of all such link pairs.
Interference
In order to incorporate interference into the model, we use the SINR of a link to determine its MCS class which is then used to modify its capacity. The SINR is determined based on how much time interference-causing links are transmitting and how much interference they cause while the interfered-on link is simultaneously transmitting. All of this is expressed using a linear function of various decisions variables.
The SINR (in dBm) on link is calculated as
where is the received signal level for the link in mW, is the interference caused by the link on the link in mW, and is the noise power in mW. In order for the link to cause interference on link :
- There must be LOS from site to site
- The receiving sector for link must be the same as the receiving sector for the LOS
- The transmitting sector for link must be the same as the transmitting sector for the LOS
- Sites and must have opposite polarity.
Time division multiplexing is incorporated into this equation in order to scale the amount of interference based on how much time the interference-causing link is actually transmitting. While not precise, for planning purposes, this hopefully provides a reasonable approximation. For example, it is useful for removing redundant links from interference considerations.
is pre-computed prior to the optimization. An issue with this is that through transmit power modulation, the links do not necessarily transmit at full power. However, incorporating this as a decision variable would greatly complicate this model. Thus, for planning purposes, the worst-case-scenario of maximum transmit power is assumed.
Unfortunately, as written, the expression for SINR is not linear in the decision variables. However, define (converting SINR from dBm to mW), then
which is a linear function of the decision variables .
Hidden in this is that the polarity decisions are also part of this equation. Namely, we require that . Because polarity decisions are not made for CNs, it is easier to require that , which is equivalent (if then the link cannot be selected). We add a decision variable which is 1 if sites and have the same polarity and 0 otherwise. Then this expression is really
This is no longer a linear function of decision variables, but it can be linearized by introducing a different decision variable which is if sites and have the same polarity and 0 otherwise. Then this expression becomes
In order to ensure that has the desired properties, we have the following constraints
Thus, if , then these constraints become , , , and . This is only satisfied if . If , then these constraints become , ,, . This is only satisfied if .
Now that is a linear function of decision variables, it has to be mapped to the modified link capacity based on the MCS class. Using a sample MCS table, we add an extra column which is .
MCS | SINR (dBm) | Throughput (Mbps) | SINR Inverse (1/mW) |
---|---|---|---|
3 | 3 | 0 | 0.501 |
4 | 4.5 | 67.5 | 0.355 |
5 | 5 | 115 | 0.316 |
6 | 5.5 | 260 | 0.282 |
7 | 7.5 | 452.5 | 0.178 |
8 | 9 | 645 | 0.126 |
9 | 12 | 741.25 | 0.063 |
10 | 14 | 1030 | 0.040 |
11 | 16 | 1415 | 0.025 |
12 | 18 | 1800 | 0.016 |
Create a decision variable for each MCS class for each link, which 1 if link is in MCS class . Assume there are such MCS classes (here, the classes are even if the MCS class itself has a different number, e.g., refers to MCS class 3). A link can only belong to one MCS class.
Denote and to be the throughput and SINR Inverse corresponding to MCS class . If , then . If , then . Continuing to the end, if , then and finally, where M is some appropriately large value, . For this final constraint, we use instead of because links with still belong to class 1. In the example above, this is equivalent to saying that links with SINR less than 3 dBm are in MCS class 3. As a single constraint, this is
Although is not bounded on both sides, we know that the optimization will try to maximize the throughput so at optimum it will not choose an MCS class lower than necessary provided it does not violate the SINR Inverse constraint. In the example above, this is equivalent to saying that a link with, e.g., SINR of 15 dBm can be of MCS class up to 10. If 1030 Mbps of throughput is needed for that link, the optimizer will select MCS 10. If only 400 Mbps of throughput is needed, the optimizer will select MCS 7-10, but between those options, the actual decision is irrelevant.
Finally, the flow is bounded by the appropriate throughput
Technically the bound on the flow should also be scaled by , but this would make the constraint quadratic and linearizing it would make the size of the optimization problem significantly larger, so it is omitted here. The scaling is still done in the Flow Capacity constraints but omitting it means the flow on the link can be larger than it technically should be. While this is not ideal, by minimizing interference, the optimizer can limit the severity of this omission. The judgement being made here is that the scaling would hopefully not impact the overall network plan significantly enough to warrant its inclusion.
Multi-Channel Constraints
For networks that can support it, enabling multi-channel can reduce the amount of interference and improve overall network performance. The assumption is that links on different channels do not interfere with each other. Thus if link is causing a lot of interference on link , the optimizer can put those links on different channels to remove the interference.
Critically, we do not currently model link capacity differences between the channels. We use a single driving frequency and derive the link capacities and interference from that. A future improvement would be to address this shortcoming. However, because of this, the channel selected by the optimizer has an arbitrary association with the actual channel number. Some post-processing might involve assigning the most commonly selected channel to the one with the best real-world performance.
There are two constraints that are impacted by multi-channel planning. The first is Deployment Guidelines and the second is Interference. That is, links on different channels do not violate deployment guidelines and do not cause interference on each other.
Formally, the channel decision is associated with each sector. However, instead of having several channel decisions for each sector, the sector decisions themselves are slightly modified. Whereas before we had decision variables, we now have for . That is, there are now sector decisions for each physical sector, with each one corresponding to a sector on a particular channel. This is not the case for CN sectors which automatically take on the channel of the serving DN and therefore do not need additional decision variables.
Multi-Channel Sector
Sectors can only have one channel.
Some of the other sector constraints are also modified. A sector can only be selected if the site is also selected
When a node contains multiple sectors, if one sector in the node is selected, all sectors in that node are selected.
A link can only be selected if the sectors it is connected to are also selected.
For multi-channel, an additional constraint requires that the two sectors connecting the link must have the same channel. This additional constraint is not required if the receiving site is a CN.
Thus, if and are on the same channel, then these constraints become . If they are on different channels, then for some channel, the one of the constraints becomes .
Multi-Channel Deployment Guidelines
The deployment guidelines/constraints only apply if the two sectors that the links are leaving from are on the same channel. If they are on different channels, then the constraint does not apply. To model this, we introduce binary decision variables, we will call them deployment links, for all the links in which is 1 if link is on channel . is the "flattened" version of containing each link of all link pairs separately and it should be much smaller than , so we do not need to do this for all links.
A deployment link can only be selected if its corresponding link is selected.
Furthermore, the deployment link is connected to a sector of the same channel.
If the receiving site is a CN, the last constraint is slightly modified because there are no channel decisions on CNs.
However, the deployment link must be selected if the link is selected and both sectors on a particular channel are selected.
Finally, the deployment guidelines constraint becomes
Multi-Channel Time Division Multiplexing
In order to model multi-channel interference, we need to modify the time division multiplexing decision variable to incorporate channels. Whereas before we had decision variables, we now have for .
Before dissecting the interference constraints, we first see how it modifies some of the other time division multiplexing constraints.
The sum of the time division multiplexing decision on each sector does not change much.
This also ensures that the time division multiplexing decision is 0 on channels that are not selected.
Flow capacity has to be updated
as does the constraint that time division multiplexing is 0 if the link is not selected
Multi-Channel Interference
Due to the change in the time division multiplexing decision variable, becomes for . Then, we have
Critically, this is done for each channel separately. Thus, if all links are communicating on a different channel than , because the time division multiplexing decision variable will be 0.
The remaining MCS class decision variable, becomes for . Then we have
and
Additionally, we have to enforce that the chosen MCS class has positive capacity for only one of the channels.
With this, the flow is bounded by the appropriate throughput
Like before, technically the bound on the flow should also be scaled by , but for the same reason, it is omitted here.
Here, we must also ensure that the time division multiplexing decision corresponds to the channel that has positive capacity. Without this, say channel 0 has positive capacity and channel 1 has zero capacity: the flow is bounded by the capacity of the positive capacity channel independent of the time division multiplexing (and channel) decision itself. Thus, the optimizer could choose sector/link channel 1 but still have positive flow across the link.