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 |
| 22 | is currently not implemented. |
| 23 | |
| 24 | At the time of writing, OsmoMSC's inter-BSC handover support is not complete |
| 25 | yet, so OsmoBSC can perform handover between separate BSS only in conjunction |
| 26 | with a 3rd party MSC implementation. |
| 27 | |
| 28 | .Handover support in Osmocom at the time of writing |
| 29 | [cols="^,^,^,^,^"] |
| 30 | |==== |
| 31 | | | intra-BSC HO (local BSS) | inter-BSC HO (remote BSS) | inter-MSC HO | inter-RAT HO |
| 32 | | OsmoBSC | rxlev, load-based | rxlev | (planned) | - |
| 33 | | OsmoMSC | (not involved, except for codec changes) | (planned) | (planned) | - |
| 34 | |==== |
| 35 | |
| 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 | |
| 47 | Each BTS is told by the BSC which cells identified by ARFCN+BSIC are its |
| 48 | adjacent cells. Via System Information, each MS receives a list of these |
| 49 | ARFCN+BSIC, and the MS then return measurements of reception levels. |
| 50 | |
| 51 | The BSC is the point of decision whether to do handover or not. This can be a |
| 52 | hugely complex combination of heuristics, knowledge of cell load and codec |
| 53 | capabilites. The most important indicator for handover though is: does an MS |
| 54 | report a neighbor with a better signal than the current cell? See |
| 55 | <<intra_bsc_ho_dot>>. |
| 56 | |
| 57 | [[intra_bsc_ho_dot]] |
| 58 | .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, ...) |
| 59 | [graphviz] |
| 60 | ---- |
| 61 | include::handover_intra_bsc.dot[] |
| 62 | ---- |
| 63 | |
| 64 | If the BSC sees the need for handover, it will: |
| 65 | |
| 66 | - activate a new lchan (with a handover reference ID), |
| 67 | - send an RR Handover Command to the current lchan, and |
| 68 | - wait for the MS to send a Handover RACH to the new lchan ("Handover Detect"). |
| 69 | - The RTP stream then is switched over to the new lchan, |
| 70 | - an RSL Establish Indication is expected on the new lchan, |
| 71 | - and the old lchan is released. |
| 72 | |
| 73 | Should handover fail at any point, e.g. the new lchan never receives a RACH, or |
| 74 | the MS reports a Handover Failure, then the new lchan is simply released again, |
| 75 | and the old lchan remains in use. If the RTP stream has already been switched |
| 76 | over to the new lchan, it may actually be switched back to the old lchan. |
| 77 | |
| 78 | This is simple enough if the new cell is managed by the same BSC: the OsmoMGW |
| 79 | is simply instructed to relay the BTS-side of the RTP stream to another IP |
| 80 | address and port, and the BSC continues to forward DTAP to the MSC |
| 81 | transparently. The operation happens completely within the BSS. If the voice |
| 82 | codec has remained unchanged, the MSC/MNCC may not even be notified that |
| 83 | anything has happened at all. |
| 84 | |
| 85 | ==== External / Inter-BSC Handover |
| 86 | |
| 87 | If the adjacent target cell belongs to a different BSS, the RR procedure for |
| 88 | handover remains the same, but we need to tell the _remote_ BSC to allocate the |
| 89 | new lchan. |
| 90 | |
| 91 | The only way to reach the remote BSC is via the MSC, so the MSC must be able |
| 92 | to: |
| 93 | |
| 94 | - identify which other BSC we want to talk to, |
| 95 | - forward various BSSMAP Handover messages between old and new BSC, |
| 96 | - redirect the core-side RTP stream to the new BSS at the appropriate time, |
| 97 | - and must finally BSSMAP Clear the connection to the old BSS to conclude the |
| 98 | inter-BSC handover. |
| 99 | |
| 100 | [[inter_bsc_ho_dot]] |
| 101 | .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, ...) |
| 102 | [graphviz] |
| 103 | ---- |
| 104 | include::handover_inter_bsc.dot[] |
| 105 | ---- |
| 106 | |
| 107 | The first part, identifying the remote BSC, is not as trivial as it sounds: as |
| 108 | mentioned above, on the level of cell information seen by BTS and MS, the |
| 109 | neighbor cells are identified by ARFCN+BSIC. However, on the A-interface and in |
| 110 | the MSC, there is no knowledge of ARFCN+BSIC configurations, and instead each |
| 111 | cell is identified by a LAC and CI (Location Area Code and Cell Identifier). |
| 112 | |
| 113 | NOTE: There are several different cell identification types on the A-interface: |
| 114 | from Cell Global Identifier (MCC+MNC+LAC+CI) down to only LAC. OsmoBSC supports |
| 115 | most of these (see <<neighbor_conf_list>>). For simplicity, this description |
| 116 | focuses on LAC+CI identification. |
| 117 | |
| 118 | The most obvious reason for using LAC+CI is that identical ARFCN+BSIC are |
| 119 | typically re-used across many cells of the same network operator: an operator |
| 120 | will have only very few ARFCNs available, and the 6bit BSIC opens only a very |
| 121 | limited range of distinction between cells. As long as each cell has no more |
| 122 | than one neighbor per given ARFCN+BSIC, these values can be re-used any number |
| 123 | of times across a network, and even between cells managed by one and the same |
| 124 | BSC. |
| 125 | |
| 126 | The consequence of this is that |
| 127 | |
| 128 | - the BSC needs to know which remote-BSS cells' ARFCN+BSIC correspond to |
| 129 | exactly which global LAC+CI, and |
| 130 | - the MSC needs to know which LAC+CI are managed by which BSC. |
| 131 | |
| 132 | In other words, each BSC requires prior knowledge about the cell configuration |
| 133 | of its remote-BSS neighbor cells, and the MSC requires prior knowledge about |
| 134 | each BSC's cell identifiers; i.e. these config items are spread reduntantly. |
| 135 | |
| 136 | === Configuring Neighbors |
| 137 | |
| 138 | The most important step to enable handover in OsmoBSC is to configure each cell |
| 139 | with the ARFCN+BSIC identities of its adjacent neighbors -- both local-BSS and |
| 140 | remote-BSS. |
| 141 | |
| 142 | For a long time, OsmoBSC has offered configuration to manually enter the |
| 143 | ARFCN+BSIC sent out as neighbors on various System Information messages (all |
| 144 | `neighbor-list` related commands). This is still possible, however, |
| 145 | particularly for re-using ARFCN+BSIC within one BSS, this method will not work |
| 146 | well. |
| 147 | |
| 148 | With the addition of inter-BSC handover support, the new `neighbor` config item |
| 149 | has been added to the `bts` config, to maintain explicit cell-to-cell neighbor |
| 150 | relations, with the possibility to re-use ARFCN+BSIC in each cell. |
| 151 | |
| 152 | It is recommended to completely replace `neighbor-list` configurations with the |
| 153 | new `neighbor` configuration described below. |
| 154 | |
| 155 | [[neighbor_conf_list]] |
| 156 | .Overview of neighbor configuration on the `bts` config node |
| 157 | [frame="none",grid="none",cols="^10%,^10%,80%"] |
| 158 | |==== |
| 159 | | Local | Remote BSS | |
| 160 | | ✓ | | neighbor bts 5 |
| 161 | | ✓ | | neighbor lac 200 |
| 162 | | ✓ | | neighbor lac-ci 200 3 |
| 163 | | ✓ | | neighbor cgi 001 01 200 3 |
| 164 | | ✓ | ✓ | neighbor lac 200 arfcn 123 bsic 1 |
| 165 | | ✓ | ✓ | neighbor lac-ci 200 3 arfcn 123 bsic 1 |
| 166 | | ✓ | ✓ | neighbor cgi 001 01 200 3 arfcn 123 bsic 1 |
| 167 | |==== |
| 168 | |
| 169 | ==== Local-BSS Neighbors |
| 170 | |
| 171 | Local neighbors can be configured by just the local BTS number, or by LAC+CI, |
| 172 | or any other supported A-interface type cell identification; also including the |
| 173 | ARFCN+BSIC is optional, it will be derived from the local configuration if |
| 174 | omitted. |
| 175 | |
| 176 | OsmoBSC will log errors in case the configuration includes ambiguous ARFCN+BSIC |
| 177 | relations (when one given cell has more than one neighbor for any one |
| 178 | ARFCN+BSIC). |
| 179 | |
| 180 | Neighbor relations must be configured explicitly in both directions, i.e. each |
| 181 | cell has to name all of its neighbors, even if the other cell already has an |
| 182 | identical neighbor relation in the reverse direction. |
| 183 | |
| 184 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by local BTS number |
| 185 | ---- |
| 186 | network |
| 187 | bts 0 |
| 188 | neighbor bts 1 |
| 189 | bts 1 |
| 190 | neighbor bts 0 |
| 191 | ---- |
| 192 | |
| 193 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by LAC+CI |
| 194 | ---- |
| 195 | network |
| 196 | |
| 197 | bts 0 |
| 198 | # this cell's LAC=23 CI=5 |
| 199 | location_area_code 23 |
| 200 | cell_identity 5 |
| 201 | # reference bts 1 |
| 202 | neighbor lac-ci 23 6 |
| 203 | |
| 204 | bts 1 |
| 205 | # this cell's LAC=23 CI=6 |
| 206 | location_area_code 23 |
| 207 | cell_identity 6 |
| 208 | # reference bts 0 |
| 209 | neighbor lac-ci 23 5 |
| 210 | ---- |
| 211 | |
| 212 | It is allowed to include the ARFCN and BSIC of local neighbor cells, even |
| 213 | though that is redundant with the already known local configuration of the |
| 214 | other cell. The idea is to ease generating the neighbor configuration |
| 215 | automatically, since local-BSS and remote-BSS neighbors then share identical |
| 216 | configuration formatting. For human readability and maintainability, it may |
| 217 | instead be desirable to use the `neighbor bts <0-255>` format. |
| 218 | |
| 219 | .Example: configuring neighbors within the local BSS in osmo-bsc.cfg, redundantly identified by LAC+CI as well as ARFCN+BSIC |
| 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 | # this cell's ARFCN=1 BSIC=1 |
| 228 | trx 0 |
| 229 | arfcn 1 |
| 230 | base_station_id_code 1 |
| 231 | # reference bts 1 |
| 232 | neighbor lac-ci 23 6 arfcn 2 bsic 2 |
| 233 | |
| 234 | bts 1 |
| 235 | # LAC=23 CI=6 |
| 236 | location_area_code 23 |
| 237 | cell_identity 6 |
| 238 | # this cell's ARFCN=2 BSIC=2 |
| 239 | trx 0 |
| 240 | arfcn 2 |
| 241 | base_station_id_code 2 |
| 242 | # reference bts 0 |
| 243 | neighbor lac-ci 23 5 arfcn 1 bsic 1 |
| 244 | ---- |
| 245 | |
| 246 | If the cell identification matches a local cell, OsmoBSC will report errors if |
| 247 | the provided ARFCN+BSIC do not match. |
| 248 | |
| 249 | ==== Remote-BSS Neighbors |
| 250 | |
| 251 | Remote-BSS neighbors _always_ need to be configured with full A-interface |
| 252 | identification _and_ ARFCN+BSIC, to allow mapping a cell's neighbor ARFCN+BSIC |
| 253 | to a _BSSMAP Cell Identifier_ (see 3GPP TS 48.008 3.1.5.1 Handover Required |
| 254 | Indication and 3.2.1.9 HANDOVER REQUIRED). |
| 255 | |
| 256 | .Example: configuring remote-BSS neighbors in osmo-bsc.cfg, identified by LAC+CI (showing both BSCs' configurations) |
| 257 | ---- |
| 258 | # BSC Alpha's osmo-bsc.cfg |
| 259 | network |
| 260 | bts 0 |
| 261 | # this cell's LAC=23 CI=6 |
| 262 | location_area_code 23 |
| 263 | cell_identity 6 |
| 264 | # this cell's ARFCN=2 BSIC=2 |
| 265 | trx 0 |
| 266 | arfcn 2 |
| 267 | base_station_id_code 2 |
| 268 | # fully describe the remote cell by LAC+CI and ARFCN+BSIC |
| 269 | neighbor lac-ci 42 3 arfcn 1 bsic 3 |
| 270 | |
| 271 | # BSC Beta's osmo-bsc.cfg |
| 272 | network |
| 273 | bts 0 |
| 274 | # this cell's LAC=42 CI=3 |
| 275 | location_area_code 42 |
| 276 | cell_identity 3 |
| 277 | # this cell's ARFCN=1 BSIC=3 |
| 278 | trx 0 |
| 279 | arfcn 1 |
| 280 | base_station_id_code 3 |
| 281 | # fully describe the remote cell by LAC+CI and ARFCN+BSIC |
| 282 | neighbor lac-ci 23 6 arfcn 2 bsic 2 |
| 283 | ---- |
| 284 | |
| 285 | NOTE: It is strongly recommended to stick to a single format for remote-BSS |
| 286 | neighbors' cell identifiers all across an OsmoBSC configuration; i.e. decide |
| 287 | once to use `lac`, `lac-ci` or `cgi` and then stick to that within a given |
| 288 | osmo-bsc.cfg. The reason is that the _Cell Identifier List_ sent in the _BSSMAP |
| 289 | Handover Required_ message must have one single cell identifier type for all |
| 290 | list items. Hence, to be able to send several alternative remote neighbors to |
| 291 | the MSC, the configured cell identifiers must be of the same type. If in doubt, |
| 292 | use the full CGI identifier everywhere. |
| 293 | |
| 294 | === Configuring Handover Decisions |
| 295 | |
| 296 | For a long time, OsmoBSC has supported handover based on reception level |
| 297 | hysteresis (RXLEV) and distance (TA, Timing Advance), known has `algorithm 1`. |
| 298 | |
| 299 | Since 2018, OsmoBSC also supports a load-based handover decision algorithm, |
| 300 | known as `algorithm 2`, which also takes cell load, available codecs and |
| 301 | oscillation into consideration. Algorithm 2 had actually been implemented for |
| 302 | the legacy OsmoNITB program many years before the OsmoMSC split, but remained |
| 303 | on a branch, until it was forward-ported to OsmoBSC in 2018. |
| 304 | |
| 305 | .What handover decision algorithms take into account |
| 306 | [frame="none",grid="none",cols="^10%,^10%,80%"] |
| 307 | |==== |
| 308 | | algorithm 1 | algorithm 2 | |
| 309 | | ✓ | ✓| RXLEV |
| 310 | | ✓ | ✓| RXQUAL |
| 311 | | ✓ | ✓| TA (distance) |
| 312 | | ✓ | ✓| interference (good RXLEV, bad RXQUAL) |
| 313 | | | ✓| load (nr of free lchans, minimum RXLEV and RXQUAL) |
| 314 | | | ✓| penalty time to avoid oscillation |
| 315 | | | ✓| voice rate / codec bias |
| 316 | | ✓ | | inter-BSC: RXLEV hysteresis |
| 317 | | | ✓| inter-BSC: only below minimum RXLEV, RXQUAL |
| 318 | |==== |
| 319 | |
| 320 | ==== Common Configuration |
| 321 | |
| 322 | Handover is disabled by default; to disable/enable handover, use `handover |
| 323 | (0|1)`. |
| 324 | |
| 325 | Once enabled, algorithm 1 is used by default; choose a handover algorithm with |
| 326 | `handover algorithm (1|2)`: |
| 327 | |
| 328 | ---- |
| 329 | network |
| 330 | # Enable handover |
| 331 | handover 1 |
| 332 | |
| 333 | # Choose algorithm |
| 334 | handover algorithm 2 |
| 335 | |
| 336 | # Tweak parameters for algorithm 2 (optional) |
| 337 | handover2 min-free-slots tch/f 4 |
| 338 | handover2 penalty-time failed-ho 30 |
| 339 | handover2 retries 1 |
| 340 | ---- |
| 341 | |
| 342 | All handover algorithms share a common configuration scheme, with an overlay of |
| 343 | three levels: |
| 344 | |
| 345 | * immutable compile-time default values, |
| 346 | * configuration on the `network` level for all cells, |
| 347 | * individual cells' configuration on each `bts` node. |
| 348 | |
| 349 | Configuration settings relevant for algorithm 1 start with `handover1`, for |
| 350 | algorithm 2 with `handover2`. |
| 351 | |
| 352 | The following example overrides the compile-time default for all cells, and |
| 353 | furthermore sets one particular cell on its own individual setting, for the |
| 354 | `min-free-slots tch/f` value: |
| 355 | |
| 356 | ---- |
| 357 | network |
| 358 | handover2 min-free-slots tch/f 4 |
| 359 | bts 23 |
| 360 | handover2 min-free-slots tch/f 2 |
| 361 | ---- |
| 362 | |
| 363 | The order in which these settings are issued makes no difference for the |
| 364 | overlay; i.e., this configuration is perfectly identical to the above, and the |
| 365 | individual cell's value remains in force: |
| 366 | |
| 367 | ---- |
| 368 | network |
| 369 | bts 23 |
| 370 | handover2 min-free-slots tch/f 2 |
| 371 | handover2 min-free-slots tch/f 4 |
| 372 | ---- |
| 373 | |
| 374 | Each setting can be reset to a default value with the `default` keyword. When |
| 375 | resetting an individual cell's value, the globally configured value is used. |
| 376 | When resetting the global value, the compile-time default is used (unless |
| 377 | individual cells still have explicit values configured). For example, this |
| 378 | telnet VTY session removes above configuration first from the cell, then from |
| 379 | the global level: |
| 380 | |
| 381 | ---- |
| 382 | OsmoBSC(config)# network |
| 383 | OsmoBSC(config-net)# bts 23 |
| 384 | OsmoBSC(config-net-bts)# handover2 min-free-slots tch/f default |
| 385 | % 'handover2 min-free-slots tch/f' setting removed, now is 4 |
| 386 | OsmoBSC(config-net-bts)# exit |
| 387 | OsmoBSC(config-net)# handover2 min-free-slots tch/f default |
| 388 | % 'handover2 min-free-slots tch/f' setting removed, now is 0 |
| 389 | ---- |
| 390 | |
| 391 | ==== Handover Algorithm 1 |
| 392 | |
| 393 | Algorithm 1 takes action only when RR Measurement Reports are received from a |
| 394 | BTS. As soon as a neighbor's average RXLEV is higher than the current cell's |
| 395 | average RXLEV plus a hysteresis distance, handover is triggered. |
| 396 | |
| 397 | If a handover fails, algorithm 1 will again attempt handover to the same cell |
| 398 | with the next Measurement Report received. |
| 399 | |
| 400 | Configuration settings relevant for algorithm 1 start with `handover1`. For |
| 401 | further details, please refer to the OsmoBSC VTY Reference |
| 402 | (<<vty-ref-osmobsc>>) or the telnet VTY online documentation. |
| 403 | |
| 404 | ==== Handover Algorithm 2 |
| 405 | |
| 406 | Algorithm 2 is specifically designed to distribute load across cells. A |
| 407 | subscriber will not necessarily remain attached to the cell that has the best |
| 408 | RXLEV average, if that cell is heavily loaded and a less loaded neighbor is |
| 409 | above the minimum allowed RXLEV. |
| 410 | |
| 411 | Algorithm 2 also features penalty timers to avoid oscillation: for each |
| 412 | subscriber, if handover to a specific neighbor failed (for a configurable |
| 413 | number of retries), a holdoff timer prevents repeated attempts to handover to |
| 414 | that same neighbor. Several hold-off timeouts following specific situations are |
| 415 | configurable (see `handover2 penalty-time` configuration items). |
| 416 | |
| 417 | Configuration settings relevant for algorithm 2 start with `handover2`. For |
| 418 | further details, please refer to the OsmoBSC VTY Reference |
| 419 | <<vty-ref-osmobsc>> or the telnet VTY online documentation. |
| 420 | |
| 421 | ===== Load Distribution |
| 422 | |
| 423 | Load distribution is only supported by algorithm 2. |
| 424 | |
| 425 | Load distribution occurs: |
| 426 | |
| 427 | - explicitly: every N seconds, OsmoBSC considers all local cells and actively |
| 428 | triggers handover operations to reduce congestion, if any. See |
| 429 | `min-free-slots` below, and the `congestion-check` setting. |
| 430 | |
| 431 | - implicitly: when choosing the best neighbor candidate for a handover |
| 432 | triggered otherwise, a congested cell (in terms of `min-free-slots`) is only |
| 433 | used as handover target if there is no alternative that causes less cell |
| 434 | load. |
| 435 | |
| 436 | In either case, load distribution will only occur towards neighbor cells that |
| 437 | adhere to minimum reception levels and distance, see `min rxlev` and `max |
| 438 | distance`. |
| 439 | |
| 440 | Load distribution will take effect only for already established voice channels. |
| 441 | An MS will always first establish a voice call with its current cell choice; in |
| 442 | load situations, it might be moved to another cell shortly after that. |
| 443 | Considering the best neighbor _before_ starting a new voice call might be |
| 444 | desirable, but is currently not implemented. Consider that RXLEV/RXQUAL ratings |
| 445 | are averaged over a given number of measurement reports, so that the neighbor |
| 446 | ratings may not be valid/reliable yet during early call establishment. In |
| 447 | consequence, it is recommended to ensure a sufficient number of unused logical |
| 448 | channels at all times, though there is no single correct configuration for all |
| 449 | situations. |
| 450 | |
| 451 | Most important for load distribution are the `min-free-slots tch/f` and |
| 452 | `min-free-slots tch/h` settings. The default is zero, meaning _no_ load |
| 453 | distribution. To enable, set `min-free-slots` >= 1 for `tch/f` and/or `tch/h` |
| 454 | as appropriate. This setting refers to the minimum number of voice channels |
| 455 | that should ideally remain unused in each individual BTS at all times. |
| 456 | |
| 457 | NOTE: it is not harmful to configure `min-free-slots` for a TCH kind that is |
| 458 | not actually present. Such settings will simply be ignored. |
| 459 | |
| 460 | NOTE: the number of TCH/F timeslots corresponds 1:1 to the number indicated by |
| 461 | `min-free-slots tch/f`, because each TCH/F physical channel has exactly one |
| 462 | logical channel. In contrast, for each TCH/H timeslot, there are two logical |
| 463 | channels, hence `min-free-slots tch/h` corresponds to twice the number of TCH/H |
| 464 | timeslots configured per cell. In fact, a more accurate naming would have been |
| 465 | "min-free-lchans". |
| 466 | |
| 467 | Think of the `min-free-slots` setting as the threshold at which load |
| 468 | distribution is considered. If as many logical channels as required by this |
| 469 | setting are available in a given cell, only changes in RXLEV/RXQUAL/TA trigger |
| 470 | handover away from that cell. As soon as less logical channels remain free, the |
| 471 | periodical congestion check attempts to distribute MS to less loaded neighbor |
| 472 | cells. Every time, the one MS that will suffer the least RXLEV loss while still |
| 473 | reducing congestion will be instructed to move first. |
| 474 | |
| 475 | If a cell and its neighbors are all loaded past their `min-free-slots` |
| 476 | settings, the algorithmic aim is equal load: a load-based handover will never |
| 477 | cause the target cell to be more congested than the source cell. |
| 478 | |
| 479 | The min-free-slots setting is a tradeoff between immediate voice service |
| 480 | availability and optimal reception levels. A sane choice could be: |
| 481 | |
| 482 | - Start off with `min-free-slots` set to half the available logical channels. |
| 483 | - Increase `min-free-slots` if you see MS being rejected too often even though |
| 484 | close neighbors had unused logical channels. |
| 485 | - Decrease `min-free-slots` if you see too many handovers happening for no |
| 486 | apparent reason. |
| 487 | |
| 488 | Choosing the optimal setting is not trivial, consider these examples: |
| 489 | |
| 490 | - Configure `min-free-slots` = 1: load distribution to other cells will occur |
| 491 | exactly when the last available logical channel has become occupied. The next |
| 492 | time the congestion check runs, at most one handover will occur, so that one |
| 493 | channel is available again. In the intermediate time, all channels will be |
| 494 | occupied, and some MS might be denied immediate voice service because of |
| 495 | that, even though, possibly, other neighbor cells would have provided |
| 496 | excellent reception levels and were completely unloaded. For those MS that |
| 497 | are already in an ongoing voice call and are not physically moving, though, |
| 498 | this almost guarantees service by the closest/best cell. |
| 499 | |
| 500 | - Set `min-free-slots` = 2: up to two MS can successfully request voice service |
| 501 | simultaneously (e.g. one MS is establishing a new voice call while another MS |
| 502 | is travelling into this cell). Ideally, two slots have been kept open and are |
| 503 | immediately available. But if a third MS is also traveling into this cell at |
| 504 | the same time, it will not be able to handover into this cell until load |
| 505 | distribution has again taken action to make logical channels available. The |
| 506 | same scenario applies to any arbitrary number of MS asking for voice channels |
| 507 | simultaneously. The operator needs to choose where to draw the line. |
| 508 | |
| 509 | - Set `min-free-slots` >= the number of available channels: as soon as any |
| 510 | neighbor is less loaded than a given cell, handover will be attempted. But |
| 511 | imagine there are only two active voice calls on this cell with plenty of |
| 512 | logical channels still unused, and the closest neighbor rates only just above |
| 513 | `min rxlev`; then moving one of the MS _for no good reason_ causes all of: |
| 514 | increased power consumption, reduced reception stability and channel |
| 515 | management overhead. |
| 516 | |
| 517 | NOTE: In the presence of dynamic timeslots to provide GPRS service, the number |
| 518 | of voice timeslots left unused also determines the amount of bandwidth |
| 519 | available for GPRS. |
| 520 | |
| 521 | ==== External / Inter-BSC Handover Considerations |
| 522 | |
| 523 | There currently is a profound difference for inter-BSC handover between |
| 524 | algorithm 1 and 2: |
| 525 | |
| 526 | For algorithm 1, inter-BSC handover is triggered as soon as the Measurement |
| 527 | Reports and hysteresis indicate a better neighbor than the current cell, |
| 528 | period. |
| 529 | |
| 530 | For algorithm 2, a subscriber is "sticky" to the current BSS, and inter-BSC |
| 531 | handover is only even considered when RXLEV/TA drop below minimum requirements. |
| 532 | |
| 533 | - If your network topology is such that each OsmoBSC instance manages a single |
| 534 | BTS, and you would like to encourage handover between these, choose handover |
| 535 | algorithm 1. Load balancing will not be available, but RXLEV hysteresis will. |
| 536 | |
| 537 | - If your network topology has many cells per BSS, and/or if your BSS |
| 538 | boundaries in tendency correspond to physical/semantic boundaries that favor |
| 539 | handover to remain within a BSS, then choose handover algorithm 2. |
| 540 | |
| 541 | The reason for the difference between algorithm 1 and 2 for remote-BSS |
| 542 | handovers is, in summary, the young age of the inter-BSC handover feature in |
| 543 | OsmoBSC: |
| 544 | |
| 545 | - So far the mechanisms to communicate cell load to remote-BSS available in the |
| 546 | BSSMAP Handover messages are not implemented, so, a handover due to cell load |
| 547 | across BSS boundaries would be likely to cause handover oscillation between |
| 548 | the two BSS (continuous handover of the same MS back and forth between the |
| 549 | same two cells). |
| 550 | - Algorithm 1 has no `min rxlev` setting. |
| 551 | - Algorithm 1 does not actually use any information besides the Measurement |
| 552 | Reports, and hence can trivially treat all neighbor cells identically. |