Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 1 | == Handover |
| 2 | |
| 3 | Handover is the process of moving a continuously used channel (lchan) from one |
| 4 | cell to another. Usually, that is an ongoing call, so that phones are able to |
| 5 | move across cell coverage areas without interrupting the voice transmission. |
| 6 | |
| 7 | A handover can |
| 8 | |
| 9 | - stay within one given cell (intra-cell, i.e. simply a new RR Assignment Command); |
| 10 | - occur between two cells that belong to the same BSS (intra-BSC, via RR Handover Command); |
| 11 | - cross BSS boundaries (inter-BSC, via BSSMAP handover procedures); |
| 12 | - move to another MSC (inter-MSC, inter-PLMN); |
| 13 | - move to another RAN type, e.g. from 2G to 3G (inter-RAT, inter-Radio-Access-Technology). |
| 14 | |
| 15 | The physical distance is by definition always very near, but handover |
| 16 | negotiation may range from being invisible to the MSC all the way to |
| 17 | orchestrating completely separate RAN stacks. |
| 18 | |
| 19 | OsmoBSC currently supports handover within one BSS and between separate BSS. |
| 20 | Whether inter-MSC is supported depends on the MSC implementation (to the BSC, |
| 21 | inter-MSC handover looks identical to inter-BSC handover). Inter-RAT handover |
Harald Welte | 9e437a7 | 2019-02-04 22:52:31 +0100 | [diff] [blame] | 22 | is currently not implemented. However, you may still advertise 3G and 4G neighbor cells |
| 23 | in order to facilitate cell/RAT re-selection to those neighbors. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 24 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 25 | Since 2019, OsmoMSC fully supports both inter-BSC and inter-MSC handover. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 26 | |
| 27 | .Handover support in Osmocom at the time of writing |
| 28 | [cols="^,^,^,^,^"] |
| 29 | |==== |
| 30 | | | intra-BSC HO (local BSS) | inter-BSC HO (remote BSS) | inter-MSC HO | inter-RAT HO |
| 31 | | OsmoBSC | rxlev, load-based | rxlev | (planned) | - |
| 32 | | OsmoMSC | (not involved, except for codec changes) | (planned) | (planned) | - |
| 33 | |==== |
| 34 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 35 | Most handover related procedures are explained in 3GPP TS 48.008. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 36 | |
| 37 | === How Handover Works |
| 38 | |
| 39 | This chapter generally explains handover operations between 2G cells. |
| 40 | |
| 41 | ==== Internal / Intra-BSC Handover |
| 42 | |
| 43 | The BSS is configured to know which cell is physically adjacent to which other |
| 44 | cells, its "neighbors". On the MS/BTS/BSS level, individual cells are |
| 45 | identified by ARFCN+BSIC (frequency + 6-bit identification code). |
| 46 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 47 | The BSC instructs each BTS with a list of ARFCNs (i.e. GSM frequency bands) |
| 48 | that qualify as neighbor cells, as part of the System Information Type 2. Each |
| 49 | MS served by a BTS receives the System Information Type 2 and thus knows which |
| 50 | ARFCNs to measure for potential handover. Each MS with an active channel then |
| 51 | returns up to 6 measurements of reception levels (RXLEV) to the BTS, to be |
| 52 | forwarded to the BSC in RSL Measurement Report messages. |
| 53 | |
| 54 | Note that the BTS and MS are told only the ARFCNs, not the BSICs, of neighbor |
| 55 | cells; the BSICs are however included in the measurements that an MS returns to |
| 56 | BTS and BSC. Commonly, each ARFCN is owned by one specific operator, so, an MS |
| 57 | considers all visible cells on a given ARFCN as possible neighbors. However, as |
| 58 | soon as an MS reports RXLEV of a specific neighbor cell, the BSC needs to know |
| 59 | which exact cell to possibly handover to, which is why the MS pinpoints the |
| 60 | specific BSIC that it reported measurements for. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 61 | |
| 62 | The BSC is the point of decision whether to do handover or not. This can be a |
| 63 | hugely complex combination of heuristics, knowledge of cell load and codec |
Martin Hauke | a29affd | 2019-11-13 22:10:41 +0100 | [diff] [blame] | 64 | capabilities. The most important indicator for handover though is: does an MS |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 65 | report a neighbor with a better signal than the current cell? See |
| 66 | <<intra_bsc_ho_dot>>. |
| 67 | |
| 68 | [[intra_bsc_ho_dot]] |
| 69 | .Intra-BSC Handover stays within the BSS (shows steps only up to activation of the new lchan -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...) |
| 70 | [graphviz] |
| 71 | ---- |
| 72 | include::handover_intra_bsc.dot[] |
| 73 | ---- |
| 74 | |
| 75 | If the BSC sees the need for handover, it will: |
| 76 | |
| 77 | - activate a new lchan (with a handover reference ID), |
| 78 | - send an RR Handover Command to the current lchan, and |
| 79 | - wait for the MS to send a Handover RACH to the new lchan ("Handover Detect"). |
| 80 | - The RTP stream then is switched over to the new lchan, |
| 81 | - an RSL Establish Indication is expected on the new lchan, |
| 82 | - and the old lchan is released. |
| 83 | |
| 84 | Should handover fail at any point, e.g. the new lchan never receives a RACH, or |
| 85 | the MS reports a Handover Failure, then the new lchan is simply released again, |
| 86 | and the old lchan remains in use. If the RTP stream has already been switched |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 87 | over to the new lchan, it is switched back to the old lchan. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 88 | |
| 89 | This is simple enough if the new cell is managed by the same BSC: the OsmoMGW |
| 90 | is simply instructed to relay the BTS-side of the RTP stream to another IP |
| 91 | address and port, and the BSC continues to forward DTAP to the MSC |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 92 | transparently. The operation happens completely within the BSS, except for the |
| 93 | BSSMAP Handover Performed message sent to the MSC once the handover is |
| 94 | completed (see 3GPP TS 48.008). |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 95 | |
| 96 | ==== External / Inter-BSC Handover |
| 97 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 98 | If the handover target cell belongs to a different BSS, the RR procedure for |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 99 | handover remains the same, but we need to tell the _remote_ BSC to allocate the |
| 100 | new lchan. |
| 101 | |
| 102 | The only way to reach the remote BSC is via the MSC, so the MSC must be able |
| 103 | to: |
| 104 | |
| 105 | - identify which other BSC we want to talk to, |
| 106 | - forward various BSSMAP Handover messages between old and new BSC, |
| 107 | - redirect the core-side RTP stream to the new BSS at the appropriate time, |
| 108 | - and must finally BSSMAP Clear the connection to the old BSS to conclude the |
| 109 | inter-BSC handover. |
| 110 | |
| 111 | [[inter_bsc_ho_dot]] |
| 112 | .Inter-BSC Handover requires the MSC to relay between two BSCs (shows steps only up to the BSSMAP Handover Command -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...) |
| 113 | [graphviz] |
| 114 | ---- |
| 115 | include::handover_inter_bsc.dot[] |
| 116 | ---- |
| 117 | |
| 118 | The first part, identifying the remote BSC, is not as trivial as it sounds: as |
| 119 | mentioned above, on the level of cell information seen by BTS and MS, the |
| 120 | neighbor cells are identified by ARFCN+BSIC. However, on the A-interface and in |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 121 | the MSC, there is no knowledge of ARFCN+BSIC configurations. Instead, each |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 122 | cell is identified by a LAC and CI (Location Area Code and Cell Identifier). |
| 123 | |
| 124 | NOTE: There are several different cell identification types on the A-interface: |
| 125 | from Cell Global Identifier (MCC+MNC+LAC+CI) down to only LAC. OsmoBSC supports |
| 126 | most of these (see <<neighbor_conf_list>>). For simplicity, this description |
| 127 | focuses on LAC+CI identification. |
| 128 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 129 | Hence: |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 130 | |
| 131 | - the BSC needs to know which remote-BSS cells' ARFCN+BSIC correspond to |
| 132 | exactly which global LAC+CI, and |
| 133 | - the MSC needs to know which LAC+CI are managed by which BSC. |
| 134 | |
| 135 | In other words, each BSC requires prior knowledge about the cell configuration |
| 136 | of its remote-BSS neighbor cells, and the MSC requires prior knowledge about |
| 137 | each BSC's cell identifiers; i.e. these config items are spread reduntantly. |
| 138 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 139 | The most obvious reason for using LAC+CI in BSSMAP is that identical ARFCN+BSIC |
| 140 | are typically re-used across many cells of the same network operator: an |
| 141 | operator will have only very few ARFCNs available, and the 6bit BSIC opens only |
| 142 | a very limited range of distinction between cells. As long as each cell has no |
| 143 | more than one neighbor per given ARFCN+BSIC, these values can be re-used any |
| 144 | number of times across a network, and even between cells managed by one and the |
| 145 | same BSC. |
| 146 | |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 147 | === Configuring Neighbors |
| 148 | |
| 149 | The most important step to enable handover in OsmoBSC is to configure each cell |
| 150 | with the ARFCN+BSIC identities of its adjacent neighbors -- both local-BSS and |
| 151 | remote-BSS. |
| 152 | |
| 153 | For a long time, OsmoBSC has offered configuration to manually enter the |
| 154 | ARFCN+BSIC sent out as neighbors on various System Information messages (all |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 155 | `neighbor-list` related commands). This is still possible; however, |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 156 | particularly for re-using ARFCN+BSIC within one BSS, this method will not work |
| 157 | well. |
| 158 | |
| 159 | With the addition of inter-BSC handover support, the new `neighbor` config item |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 160 | has been added to the `bts` config node, to maintain explicit cell-to-cell neighbor |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 161 | relations, with the possibility to re-use ARFCN+BSIC in each cell. |
| 162 | |
| 163 | It is recommended to completely replace `neighbor-list` configurations with the |
| 164 | new `neighbor` configuration described below. |
| 165 | |
| 166 | [[neighbor_conf_list]] |
| 167 | .Overview of neighbor configuration on the `bts` config node |
| 168 | [frame="none",grid="none",cols="^10%,^10%,80%"] |
| 169 | |==== |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 170 | | Local | Remote BSS | type of `neighbor` config line, by example |
| 171 | | ✓ | | `neighbor bts 5` |
| 172 | | ✓ | | `neighbor lac 200` |
| 173 | | ✓ | | `neighbor lac-ci 200 3` |
| 174 | | ✓ | | `neighbor cgi 001 01 200 3` |
| 175 | | ✓ | ✓ | `neighbor lac 200 arfcn 123 bsic 1` |
| 176 | | ✓ | ✓ | `neighbor lac-ci 200 3 arfcn 123 bsic 1` |
| 177 | | ✓ | ✓ | `neighbor cgi 001 01 200 3 arfcn 123 bsic 1` |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 178 | |==== |
| 179 | |
Neels Hofmeyr | 4875848 | 2018-10-31 02:18:39 +0100 | [diff] [blame] | 180 | ==== Default: All Local Cells are Neighbors |
| 181 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 182 | For historical reasons, the default behavior of OsmoBSC is to add all local-BSS cells as neighbors for every other cell. To |
| 183 | maintain a backwards compatible configuration file format, this is still the case: as long as no explicit |
Neels Hofmeyr | 4875848 | 2018-10-31 02:18:39 +0100 | [diff] [blame] | 184 | neighbor cell is configured with a `neighbor` command (either none was configured, or all configured |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 185 | `neighbor` lines have been removed again), a cell automatically lists all of the local-BSS cells as neighbors. |
Neels Hofmeyr | 4875848 | 2018-10-31 02:18:39 +0100 | [diff] [blame] | 186 | These are implicit mappings in terms of the legacy neighbor configuration scheme, and re-using ARFCN+BSIC |
| 187 | combinations within a BSS will not work well this way. |
| 188 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 189 | As soon as the first explicit `neighbor` relation is added to a cell, the legacy behavior is switched off, |
Neels Hofmeyr | 4875848 | 2018-10-31 02:18:39 +0100 | [diff] [blame] | 190 | and only explicit neighbors are in effect. |
| 191 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 192 | NOTE: If a cell is required to not have any neighbors, it is recommended to switch off handover |
| 193 | for that cell with `handover 0`. |
Neels Hofmeyr | 4875848 | 2018-10-31 02:18:39 +0100 | [diff] [blame] | 194 | |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 195 | ==== Local-BSS Neighbors |
| 196 | |
| 197 | Local neighbors can be configured by just the local BTS number, or by LAC+CI, |
| 198 | or any other supported A-interface type cell identification; also including the |
| 199 | ARFCN+BSIC is optional, it will be derived from the local configuration if |
| 200 | omitted. |
| 201 | |
| 202 | OsmoBSC will log errors in case the configuration includes ambiguous ARFCN+BSIC |
| 203 | relations (when one given cell has more than one neighbor for any one |
| 204 | ARFCN+BSIC). |
| 205 | |
| 206 | Neighbor relations must be configured explicitly in both directions, i.e. each |
| 207 | cell has to name all of its neighbors, even if the other cell already has an |
| 208 | identical neighbor relation in the reverse direction. |
| 209 | |
| 210 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by local BTS number |
| 211 | ---- |
| 212 | network |
| 213 | bts 0 |
| 214 | neighbor bts 1 |
| 215 | bts 1 |
| 216 | neighbor bts 0 |
| 217 | ---- |
| 218 | |
| 219 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by LAC+CI |
| 220 | ---- |
| 221 | network |
| 222 | |
| 223 | bts 0 |
| 224 | # this cell's LAC=23 CI=5 |
| 225 | location_area_code 23 |
| 226 | cell_identity 5 |
| 227 | # reference bts 1 |
| 228 | neighbor lac-ci 23 6 |
| 229 | |
| 230 | bts 1 |
| 231 | # this cell's LAC=23 CI=6 |
| 232 | location_area_code 23 |
| 233 | cell_identity 6 |
| 234 | # reference bts 0 |
| 235 | neighbor lac-ci 23 5 |
| 236 | ---- |
| 237 | |
| 238 | It is allowed to include the ARFCN and BSIC of local neighbor cells, even |
| 239 | though that is redundant with the already known local configuration of the |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 240 | target cell. The idea is to ease generating the neighbor configuration |
| 241 | automatically, in that local-BSS and remote-BSS neighbors can have identical |
| 242 | configuration formatting. If the cell identification (LAC+CI) matches a local |
| 243 | cell but a mismatching ARFCN+BSIC follows on the same config line, OsmoBSC will |
| 244 | report errors. For human readability and maintainability, it may instead be |
| 245 | desirable to use the `neighbor bts <0-255>` format, or omit the redundant |
| 246 | `arfcn` and `bsic`. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 247 | |
| 248 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, redundantly identified by LAC+CI as well as ARFCN+BSIC |
| 249 | ---- |
| 250 | network |
| 251 | |
| 252 | bts 0 |
| 253 | # this cell's LAC=23 CI=5 |
| 254 | location_area_code 23 |
| 255 | cell_identity 5 |
| 256 | # this cell's ARFCN=1 BSIC=1 |
| 257 | trx 0 |
| 258 | arfcn 1 |
| 259 | base_station_id_code 1 |
| 260 | # reference bts 1 |
| 261 | neighbor lac-ci 23 6 arfcn 2 bsic 2 |
| 262 | |
| 263 | bts 1 |
| 264 | # LAC=23 CI=6 |
| 265 | location_area_code 23 |
| 266 | cell_identity 6 |
| 267 | # this cell's ARFCN=2 BSIC=2 |
| 268 | trx 0 |
| 269 | arfcn 2 |
| 270 | base_station_id_code 2 |
| 271 | # reference bts 0 |
| 272 | neighbor lac-ci 23 5 arfcn 1 bsic 1 |
| 273 | ---- |
| 274 | |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 275 | ==== Remote-BSS Neighbors |
| 276 | |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 277 | Remote-BSS neighbors always need to be configured with full A-interface |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 278 | identification _and_ ARFCN+BSIC, to allow mapping a cell's neighbor ARFCN+BSIC |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 279 | to a BSSMAP Cell Identifier (see 3GPP TS 48.008 3.1.5.1 Handover Required |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 280 | Indication and 3.2.1.9 HANDOVER REQUIRED). |
| 281 | |
| 282 | .Example: configuring remote-BSS neighbors in osmo-bsc.cfg, identified by LAC+CI (showing both BSCs' configurations) |
| 283 | ---- |
| 284 | # BSC Alpha's osmo-bsc.cfg |
| 285 | network |
| 286 | bts 0 |
| 287 | # this cell's LAC=23 CI=6 |
| 288 | location_area_code 23 |
| 289 | cell_identity 6 |
| 290 | # this cell's ARFCN=2 BSIC=2 |
| 291 | trx 0 |
| 292 | arfcn 2 |
| 293 | base_station_id_code 2 |
| 294 | # fully describe the remote cell by LAC+CI and ARFCN+BSIC |
| 295 | neighbor lac-ci 42 3 arfcn 1 bsic 3 |
| 296 | |
| 297 | # BSC Beta's osmo-bsc.cfg |
| 298 | network |
| 299 | bts 0 |
| 300 | # this cell's LAC=42 CI=3 |
| 301 | location_area_code 42 |
| 302 | cell_identity 3 |
| 303 | # this cell's ARFCN=1 BSIC=3 |
| 304 | trx 0 |
| 305 | arfcn 1 |
| 306 | base_station_id_code 3 |
| 307 | # fully describe the remote cell by LAC+CI and ARFCN+BSIC |
| 308 | neighbor lac-ci 23 6 arfcn 2 bsic 2 |
| 309 | ---- |
| 310 | |
| 311 | NOTE: It is strongly recommended to stick to a single format for remote-BSS |
| 312 | neighbors' cell identifiers all across an OsmoBSC configuration; i.e. decide |
| 313 | once to use `lac`, `lac-ci` or `cgi` and then stick to that within a given |
| 314 | osmo-bsc.cfg. The reason is that the _Cell Identifier List_ sent in the _BSSMAP |
| 315 | Handover Required_ message must have one single cell identifier type for all |
| 316 | list items. Hence, to be able to send several alternative remote neighbors to |
| 317 | the MSC, the configured cell identifiers must be of the same type. If in doubt, |
| 318 | use the full CGI identifier everywhere. |
| 319 | |
Neels Hofmeyr | aa4a3e7 | 2018-10-31 02:27:28 +0100 | [diff] [blame] | 320 | ==== Reconfiguring Neighbors in a Running OsmoBSC |
| 321 | |
| 322 | When modifying a cell's neighbor configuration in a telnet VTY session while a cell is already active, |
| 323 | the neighbor configuration will merely be cached in the BSC's local config. To take actual effect, it is |
| 324 | necessary to |
| 325 | |
| 326 | - either, re-connect the cell to the BSC (e.g. via `drop bts connection <0-255> oml`) |
| 327 | - or, re-send the System Information using `bts <0-255> resend-system-information`. |
| 328 | |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 329 | === Configuring Handover Decisions |
| 330 | |
| 331 | For a long time, OsmoBSC has supported handover based on reception level |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 332 | hysteresis (RXLEV) and distance (TA, Timing Advance), known as `algorithm 1`. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 333 | |
| 334 | Since 2018, OsmoBSC also supports a load-based handover decision algorithm, |
| 335 | known as `algorithm 2`, which also takes cell load, available codecs and |
| 336 | oscillation into consideration. Algorithm 2 had actually been implemented for |
| 337 | the legacy OsmoNITB program many years before the OsmoMSC split, but remained |
| 338 | on a branch, until it was forward-ported to OsmoBSC in 2018. |
| 339 | |
| 340 | .What handover decision algorithms take into account |
| 341 | [frame="none",grid="none",cols="^10%,^10%,80%"] |
| 342 | |==== |
| 343 | | algorithm 1 | algorithm 2 | |
| 344 | | ✓ | ✓| RXLEV |
| 345 | | ✓ | ✓| RXQUAL |
| 346 | | ✓ | ✓| TA (distance) |
| 347 | | ✓ | ✓| interference (good RXLEV, bad RXQUAL) |
| 348 | | | ✓| load (nr of free lchans, minimum RXLEV and RXQUAL) |
| 349 | | | ✓| penalty time to avoid oscillation |
| 350 | | | ✓| voice rate / codec bias |
| 351 | | ✓ | | inter-BSC: RXLEV hysteresis |
| 352 | | | ✓| inter-BSC: only below minimum RXLEV, RXQUAL |
| 353 | |==== |
| 354 | |
| 355 | ==== Common Configuration |
| 356 | |
| 357 | Handover is disabled by default; to disable/enable handover, use `handover |
| 358 | (0|1)`. |
| 359 | |
| 360 | Once enabled, algorithm 1 is used by default; choose a handover algorithm with |
| 361 | `handover algorithm (1|2)`: |
| 362 | |
| 363 | ---- |
| 364 | network |
| 365 | # Enable handover |
| 366 | handover 1 |
| 367 | |
| 368 | # Choose algorithm |
| 369 | handover algorithm 2 |
| 370 | |
| 371 | # Tweak parameters for algorithm 2 (optional) |
| 372 | handover2 min-free-slots tch/f 4 |
| 373 | handover2 penalty-time failed-ho 30 |
| 374 | handover2 retries 1 |
| 375 | ---- |
| 376 | |
| 377 | All handover algorithms share a common configuration scheme, with an overlay of |
| 378 | three levels: |
| 379 | |
| 380 | * immutable compile-time default values, |
| 381 | * configuration on the `network` level for all cells, |
| 382 | * individual cells' configuration on each `bts` node. |
| 383 | |
| 384 | Configuration settings relevant for algorithm 1 start with `handover1`, for |
| 385 | algorithm 2 with `handover2`. |
| 386 | |
| 387 | The following example overrides the compile-time default for all cells, and |
| 388 | furthermore sets one particular cell on its own individual setting, for the |
| 389 | `min-free-slots tch/f` value: |
| 390 | |
| 391 | ---- |
| 392 | network |
| 393 | handover2 min-free-slots tch/f 4 |
| 394 | bts 23 |
| 395 | handover2 min-free-slots tch/f 2 |
| 396 | ---- |
| 397 | |
| 398 | The order in which these settings are issued makes no difference for the |
Neels Hofmeyr | ad5b8ce | 2019-06-12 05:47:43 +0200 | [diff] [blame] | 399 | overlay; i.e., the following configuration is perfectly identical to the above, and the |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 400 | individual cell's value remains in force: |
| 401 | |
| 402 | ---- |
| 403 | network |
| 404 | bts 23 |
| 405 | handover2 min-free-slots tch/f 2 |
| 406 | handover2 min-free-slots tch/f 4 |
| 407 | ---- |
| 408 | |
| 409 | Each setting can be reset to a default value with the `default` keyword. When |
| 410 | resetting an individual cell's value, the globally configured value is used. |
| 411 | When resetting the global value, the compile-time default is used (unless |
| 412 | individual cells still have explicit values configured). For example, this |
| 413 | telnet VTY session removes above configuration first from the cell, then from |
| 414 | the global level: |
| 415 | |
| 416 | ---- |
| 417 | OsmoBSC(config)# network |
| 418 | OsmoBSC(config-net)# bts 23 |
| 419 | OsmoBSC(config-net-bts)# handover2 min-free-slots tch/f default |
| 420 | % 'handover2 min-free-slots tch/f' setting removed, now is 4 |
| 421 | OsmoBSC(config-net-bts)# exit |
| 422 | OsmoBSC(config-net)# handover2 min-free-slots tch/f default |
| 423 | % 'handover2 min-free-slots tch/f' setting removed, now is 0 |
| 424 | ---- |
| 425 | |
| 426 | ==== Handover Algorithm 1 |
| 427 | |
| 428 | Algorithm 1 takes action only when RR Measurement Reports are received from a |
| 429 | BTS. As soon as a neighbor's average RXLEV is higher than the current cell's |
| 430 | average RXLEV plus a hysteresis distance, handover is triggered. |
| 431 | |
| 432 | If a handover fails, algorithm 1 will again attempt handover to the same cell |
| 433 | with the next Measurement Report received. |
| 434 | |
| 435 | Configuration settings relevant for algorithm 1 start with `handover1`. For |
| 436 | further details, please refer to the OsmoBSC VTY Reference |
Neels Hofmeyr | 08371ec | 2019-06-24 13:43:06 +0200 | [diff] [blame] | 437 | (<<vty-ref-osmobsc>>) or the telnet VTY online documentation. See the |
| 438 | `handover1` settings on the `config-net` and `config-net-bts` nodes. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 439 | |
| 440 | ==== Handover Algorithm 2 |
| 441 | |
| 442 | Algorithm 2 is specifically designed to distribute load across cells. A |
| 443 | subscriber will not necessarily remain attached to the cell that has the best |
| 444 | RXLEV average, if that cell is heavily loaded and a less loaded neighbor is |
| 445 | above the minimum allowed RXLEV. |
| 446 | |
| 447 | Algorithm 2 also features penalty timers to avoid oscillation: for each |
| 448 | subscriber, if handover to a specific neighbor failed (for a configurable |
| 449 | number of retries), a holdoff timer prevents repeated attempts to handover to |
| 450 | that same neighbor. Several hold-off timeouts following specific situations are |
| 451 | configurable (see `handover2 penalty-time` configuration items). |
| 452 | |
| 453 | Configuration settings relevant for algorithm 2 start with `handover2`. For |
| 454 | further details, please refer to the OsmoBSC VTY Reference |
Neels Hofmeyr | 08371ec | 2019-06-24 13:43:06 +0200 | [diff] [blame] | 455 | <<vty-ref-osmobsc>> or the telnet VTY online documentation. See the `handover2` |
| 456 | settings on the `config-net` and `config-net-bts` nodes. |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 457 | |
| 458 | ===== Load Distribution |
| 459 | |
| 460 | Load distribution is only supported by algorithm 2. |
| 461 | |
| 462 | Load distribution occurs: |
| 463 | |
| 464 | - explicitly: every N seconds, OsmoBSC considers all local cells and actively |
| 465 | triggers handover operations to reduce congestion, if any. See |
| 466 | `min-free-slots` below, and the `congestion-check` setting. |
| 467 | |
| 468 | - implicitly: when choosing the best neighbor candidate for a handover |
| 469 | triggered otherwise, a congested cell (in terms of `min-free-slots`) is only |
| 470 | used as handover target if there is no alternative that causes less cell |
| 471 | load. |
| 472 | |
| 473 | In either case, load distribution will only occur towards neighbor cells that |
| 474 | adhere to minimum reception levels and distance, see `min rxlev` and `max |
| 475 | distance`. |
| 476 | |
Neels Hofmeyr | 08371ec | 2019-06-24 13:43:06 +0200 | [diff] [blame] | 477 | Load distribution will take effect only for already established channels. |
| 478 | For example, an MS will always first establish a voice call with its current cell choice; in |
Neels Hofmeyr | 8c14a94 | 2018-09-21 14:00:08 +0200 | [diff] [blame] | 479 | load situations, it might be moved to another cell shortly after that. |
| 480 | Considering the best neighbor _before_ starting a new voice call might be |
| 481 | desirable, but is currently not implemented. Consider that RXLEV/RXQUAL ratings |
| 482 | are averaged over a given number of measurement reports, so that the neighbor |
| 483 | ratings may not be valid/reliable yet during early call establishment. In |
| 484 | consequence, it is recommended to ensure a sufficient number of unused logical |
| 485 | channels at all times, though there is no single correct configuration for all |
| 486 | situations. |
| 487 | |
| 488 | Most important for load distribution are the `min-free-slots tch/f` and |
| 489 | `min-free-slots tch/h` settings. The default is zero, meaning _no_ load |
| 490 | distribution. To enable, set `min-free-slots` >= 1 for `tch/f` and/or `tch/h` |
| 491 | as appropriate. This setting refers to the minimum number of voice channels |
| 492 | that should ideally remain unused in each individual BTS at all times. |
| 493 | |
| 494 | NOTE: it is not harmful to configure `min-free-slots` for a TCH kind that is |
| 495 | not actually present. Such settings will simply be ignored. |
| 496 | |
| 497 | NOTE: the number of TCH/F timeslots corresponds 1:1 to the number indicated by |
| 498 | `min-free-slots tch/f`, because each TCH/F physical channel has exactly one |
| 499 | logical channel. In contrast, for each TCH/H timeslot, there are two logical |
| 500 | channels, hence `min-free-slots tch/h` corresponds to twice the number of TCH/H |
| 501 | timeslots configured per cell. In fact, a more accurate naming would have been |
| 502 | "min-free-lchans". |
| 503 | |
| 504 | Think of the `min-free-slots` setting as the threshold at which load |
| 505 | distribution is considered. If as many logical channels as required by this |
| 506 | setting are available in a given cell, only changes in RXLEV/RXQUAL/TA trigger |
| 507 | handover away from that cell. As soon as less logical channels remain free, the |
| 508 | periodical congestion check attempts to distribute MS to less loaded neighbor |
| 509 | cells. Every time, the one MS that will suffer the least RXLEV loss while still |
| 510 | reducing congestion will be instructed to move first. |
| 511 | |
| 512 | If a cell and its neighbors are all loaded past their `min-free-slots` |
| 513 | settings, the algorithmic aim is equal load: a load-based handover will never |
| 514 | cause the target cell to be more congested than the source cell. |
| 515 | |
| 516 | The min-free-slots setting is a tradeoff between immediate voice service |
| 517 | availability and optimal reception levels. A sane choice could be: |
| 518 | |
| 519 | - Start off with `min-free-slots` set to half the available logical channels. |
| 520 | - Increase `min-free-slots` if you see MS being rejected too often even though |
| 521 | close neighbors had unused logical channels. |
| 522 | - Decrease `min-free-slots` if you see too many handovers happening for no |
| 523 | apparent reason. |
| 524 | |
| 525 | Choosing the optimal setting is not trivial, consider these examples: |
| 526 | |
| 527 | - Configure `min-free-slots` = 1: load distribution to other cells will occur |
| 528 | exactly when the last available logical channel has become occupied. The next |
| 529 | time the congestion check runs, at most one handover will occur, so that one |
| 530 | channel is available again. In the intermediate time, all channels will be |
| 531 | occupied, and some MS might be denied immediate voice service because of |
| 532 | that, even though, possibly, other neighbor cells would have provided |
| 533 | excellent reception levels and were completely unloaded. For those MS that |
| 534 | are already in an ongoing voice call and are not physically moving, though, |
| 535 | this almost guarantees service by the closest/best cell. |
| 536 | |
| 537 | - Set `min-free-slots` = 2: up to two MS can successfully request voice service |
| 538 | simultaneously (e.g. one MS is establishing a new voice call while another MS |
| 539 | is travelling into this cell). Ideally, two slots have been kept open and are |
| 540 | immediately available. But if a third MS is also traveling into this cell at |
| 541 | the same time, it will not be able to handover into this cell until load |
| 542 | distribution has again taken action to make logical channels available. The |
| 543 | same scenario applies to any arbitrary number of MS asking for voice channels |
| 544 | simultaneously. The operator needs to choose where to draw the line. |
| 545 | |
| 546 | - Set `min-free-slots` >= the number of available channels: as soon as any |
| 547 | neighbor is less loaded than a given cell, handover will be attempted. But |
| 548 | imagine there are only two active voice calls on this cell with plenty of |
| 549 | logical channels still unused, and the closest neighbor rates only just above |
| 550 | `min rxlev`; then moving one of the MS _for no good reason_ causes all of: |
| 551 | increased power consumption, reduced reception stability and channel |
| 552 | management overhead. |
| 553 | |
| 554 | NOTE: In the presence of dynamic timeslots to provide GPRS service, the number |
| 555 | of voice timeslots left unused also determines the amount of bandwidth |
| 556 | available for GPRS. |
| 557 | |
| 558 | ==== External / Inter-BSC Handover Considerations |
| 559 | |
| 560 | There currently is a profound difference for inter-BSC handover between |
| 561 | algorithm 1 and 2: |
| 562 | |
| 563 | For algorithm 1, inter-BSC handover is triggered as soon as the Measurement |
| 564 | Reports and hysteresis indicate a better neighbor than the current cell, |
| 565 | period. |
| 566 | |
| 567 | For algorithm 2, a subscriber is "sticky" to the current BSS, and inter-BSC |
| 568 | handover is only even considered when RXLEV/TA drop below minimum requirements. |
| 569 | |
| 570 | - If your network topology is such that each OsmoBSC instance manages a single |
| 571 | BTS, and you would like to encourage handover between these, choose handover |
| 572 | algorithm 1. Load balancing will not be available, but RXLEV hysteresis will. |
| 573 | |
| 574 | - If your network topology has many cells per BSS, and/or if your BSS |
| 575 | boundaries in tendency correspond to physical/semantic boundaries that favor |
| 576 | handover to remain within a BSS, then choose handover algorithm 2. |
| 577 | |
| 578 | The reason for the difference between algorithm 1 and 2 for remote-BSS |
| 579 | handovers is, in summary, the young age of the inter-BSC handover feature in |
| 580 | OsmoBSC: |
| 581 | |
| 582 | - So far the mechanisms to communicate cell load to remote-BSS available in the |
| 583 | BSSMAP Handover messages are not implemented, so, a handover due to cell load |
| 584 | across BSS boundaries would be likely to cause handover oscillation between |
| 585 | the two BSS (continuous handover of the same MS back and forth between the |
| 586 | same two cells). |
| 587 | - Algorithm 1 has no `min rxlev` setting. |
| 588 | - Algorithm 1 does not actually use any information besides the Measurement |
| 589 | Reports, and hence can trivially treat all neighbor cells identically. |
Harald Welte | 9e437a7 | 2019-02-04 22:52:31 +0100 | [diff] [blame] | 590 | |
| 591 | === Advertising 3G/4G neighbors |
| 592 | |
| 593 | Despite osmo-bsc not supporting inter-RAT hand-over at this point, it |
| 594 | still makes sense to advertise neighbor cells of other network |
| 595 | technologies like UMTS/UTRAN (3G) and LTE/EUTRAN (4G). This will help |
| 596 | phones with idle-mode re-selection of the best available radio access |
| 597 | technology (RAT). |
| 598 | |
| 599 | For more information on the inter-RAT cell re-selection algorithm and its |
| 600 | parameters, see 3GPP TS 45.008 - particularly Section 6.6.4 describing |
| 601 | measurements on cells of other (non-GSM) RATs. |
| 602 | |
| 603 | Such neighbors are advertised as part of the SI2quater (System |
| 604 | Information Type 2quater). |
| 605 | |
| 606 | ==== UMTS/UTRAN/3G neighbors |
| 607 | |
| 608 | In order to advertise a 3G neighbor cell you have to specify the |
| 609 | following properties: |
| 610 | |
| 611 | * the UARFCN (UTRAN Absolute Radio Channel Number) on which the cell |
| 612 | broadcasts |
| 613 | * the Scrambling Code of the cell |
| 614 | * whether or not the cell uses diversity |
| 615 | |
| 616 | |
| 617 | In the following example, we're configuring a 3G neighbor cell on UARFCN |
| 618 | 1234 using the scrambling code 511 with no diversity: |
| 619 | |
| 620 | ---- |
| 621 | network |
| 622 | bts 0 |
| 623 | si2quater neighbor-list add uarfcn 1234 511 0 |
| 624 | ---- |
| 625 | |
| 626 | 3G neighbor cells can be removed using the same command, just replacing |
| 627 | `add` with `del`. |
| 628 | |
| 629 | ==== LTE/EUTRAN/4G neighbors |
| 630 | |
| 631 | In order to advertise a 4G neighbor cell you have to specify the |
| 632 | following properties: |
| 633 | |
| 634 | * EARFCN (EUTRAN Absolute Radio Channel Number) on which the cell |
| 635 | broadcasts |
| 636 | * Reselection thresholds towards E-UTRAN cells: |
| 637 | [width="30%"] |
| 638 | |==== |
| 639 | | 0 | 0 dB |
| 640 | | 1 | 2 dB |
| 641 | | 2 | 4 dB |
| 642 | | 3 | 6 dB |
| 643 | | ... | ... |
| 644 | | 31 | 62 dB |
| 645 | |===== |
| 646 | * Priority of E-UTRAN frequency: 0 = lowest priority, ..., 7 = highest priority |
| 647 | * QRXLEVMIN parameter: Minimum required RX level in the UTRAN FDD cell |
| 648 | (dBm), see 3GPP TS 25.304. |
| 649 | [width="30%"] |
| 650 | |==== |
| 651 | | 0 | -140 dBm |
| 652 | | 1 | -138 dBm |
| 653 | | 2 | -136 dBm |
| 654 | | ... | ... |
| 655 | | 31 | -78 dBm |
| 656 | |==== |
| 657 | * Measurement bandwidth in MHz, see 3GPP TS 44.018 and 3GPP TS 44.060. |
| 658 | This field specifies the minimum value of the channel bandwidth of all |
| 659 | valid E-UTRAN cells on the specified EARFCN. It is defined by the |
| 660 | parameter Transmission Bandwidth Configuration, N RB (see 3GPP TS |
| 661 | 36.104). The values indicate the number of resource blocks over which |
| 662 | the mobile station could measure if the mobile station does not |
| 663 | support wideband RSRQ measurements (see 3GPP TS 24.008). A mobile |
| 664 | station supporting wideband RSRQ measurements shall measure over the |
| 665 | indicated number of resource blocks. The field is coded according to |
| 666 | the following table: |
| 667 | [width="30%"] |
| 668 | |==== |
| 669 | | 0 | N_RB = 6 |
| 670 | | 1 | N_RB = 15 |
| 671 | | 2 | N_RB = 25 |
| 672 | | 3 | N_RB = 50 |
| 673 | | 4 | N_RB = 75 |
| 674 | | 5 | N_RB = 100 |
| 675 | |==== |
| 676 | |
| 677 | In the following example we're configuring a 4G neighbor on EARFCN 2342 |
| 678 | with a higher reselection threshold of 40dB, a lower reselection |
| 679 | threshold of 20dB, priority 5, QRXLEVMIN of -140 dBm and a measurement |
| 680 | bandwidth of 100 resource blocks: |
| 681 | |
| 682 | ---- |
| 683 | network |
| 684 | bts 0 |
| 685 | si2quater neighbor-list add earfcn 2342 thresh-hi 20 thresh-lo 10 prio 5 qrxlv 0 meas 5 |
| 686 | ---- |
| 687 | |
| 688 | 4G neighbor cells can be removed using the same command, just replacing |
| 689 | `add` with `del`. |