diff options
Diffstat (limited to 'OsmoBSC/chapters/handover.adoc')
| -rw-r--r-- | OsmoBSC/chapters/handover.adoc | 577 |
1 files changed, 0 insertions, 577 deletions
diff --git a/OsmoBSC/chapters/handover.adoc b/OsmoBSC/chapters/handover.adoc deleted file mode 100644 index 297eafc..0000000 --- a/OsmoBSC/chapters/handover.adoc +++ /dev/null @@ -1,577 +0,0 @@ -== Handover - -Handover is the process of moving a continuously used channel (lchan) from one -cell to another. Usually, that is an ongoing call, so that phones are able to -move across cell coverage areas without interrupting the voice transmission. - -A handover can - -- stay within one given cell (intra-cell, i.e. simply a new RR Assignment Command); -- occur between two cells that belong to the same BSS (intra-BSC, via RR Handover Command); -- cross BSS boundaries (inter-BSC, via BSSMAP handover procedures); -- move to another MSC (inter-MSC, inter-PLMN); -- move to another RAN type, e.g. from 2G to 3G (inter-RAT, inter-Radio-Access-Technology). - -The physical distance is by definition always very near, but handover -negotiation may range from being invisible to the MSC all the way to -orchestrating completely separate RAN stacks. - -OsmoBSC currently supports handover within one BSS and between separate BSS. -Whether inter-MSC is supported depends on the MSC implementation (to the BSC, -inter-MSC handover looks identical to inter-BSC handover). Inter-RAT handover -is currently not implemented. - -At the time of writing, OsmoMSC's inter-BSC handover support is not complete -yet, so OsmoBSC can perform handover between separate BSS only in conjunction -with a 3rd party MSC implementation. - -.Handover support in Osmocom at the time of writing -[cols="^,^,^,^,^"] -|==== -| | intra-BSC HO (local BSS) | inter-BSC HO (remote BSS) | inter-MSC HO | inter-RAT HO -| OsmoBSC | rxlev, load-based | rxlev | (planned) | - -| OsmoMSC | (not involved, except for codec changes) | (planned) | (planned) | - -|==== - - -=== How Handover Works - -This chapter generally explains handover operations between 2G cells. - -==== Internal / Intra-BSC Handover - -The BSS is configured to know which cell is physically adjacent to which other -cells, its "neighbors". On the MS/BTS/BSS level, individual cells are -identified by ARFCN+BSIC (frequency + 6-bit identification code). - -Each BTS is told by the BSC which cells identified by ARFCN+BSIC are its -adjacent cells. Via System Information, each MS receives a list of these -ARFCN+BSIC, and the MS then return measurements of reception levels. - -The BSC is the point of decision whether to do handover or not. This can be a -hugely complex combination of heuristics, knowledge of cell load and codec -capabilites. The most important indicator for handover though is: does an MS -report a neighbor with a better signal than the current cell? See -<<intra_bsc_ho_dot>>. - -[[intra_bsc_ho_dot]] -.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, ...) -[graphviz] ----- -include::handover_intra_bsc.dot[] ----- - -If the BSC sees the need for handover, it will: - -- activate a new lchan (with a handover reference ID), -- send an RR Handover Command to the current lchan, and -- wait for the MS to send a Handover RACH to the new lchan ("Handover Detect"). -- The RTP stream then is switched over to the new lchan, -- an RSL Establish Indication is expected on the new lchan, -- and the old lchan is released. - -Should handover fail at any point, e.g. the new lchan never receives a RACH, or -the MS reports a Handover Failure, then the new lchan is simply released again, -and the old lchan remains in use. If the RTP stream has already been switched -over to the new lchan, it may actually be switched back to the old lchan. - -This is simple enough if the new cell is managed by the same BSC: the OsmoMGW -is simply instructed to relay the BTS-side of the RTP stream to another IP -address and port, and the BSC continues to forward DTAP to the MSC -transparently. The operation happens completely within the BSS. If the voice -codec has remained unchanged, the MSC/MNCC may not even be notified that -anything has happened at all. - -==== External / Inter-BSC Handover - -If the adjacent target cell belongs to a different BSS, the RR procedure for -handover remains the same, but we need to tell the _remote_ BSC to allocate the -new lchan. - -The only way to reach the remote BSC is via the MSC, so the MSC must be able -to: - -- identify which other BSC we want to talk to, -- forward various BSSMAP Handover messages between old and new BSC, -- redirect the core-side RTP stream to the new BSS at the appropriate time, -- and must finally BSSMAP Clear the connection to the old BSS to conclude the - inter-BSC handover. - -[[inter_bsc_ho_dot]] -.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, ...) -[graphviz] ----- -include::handover_inter_bsc.dot[] ----- - -The first part, identifying the remote BSC, is not as trivial as it sounds: as -mentioned above, on the level of cell information seen by BTS and MS, the -neighbor cells are identified by ARFCN+BSIC. However, on the A-interface and in -the MSC, there is no knowledge of ARFCN+BSIC configurations, and instead each -cell is identified by a LAC and CI (Location Area Code and Cell Identifier). - -NOTE: There are several different cell identification types on the A-interface: -from Cell Global Identifier (MCC+MNC+LAC+CI) down to only LAC. OsmoBSC supports -most of these (see <<neighbor_conf_list>>). For simplicity, this description -focuses on LAC+CI identification. - -The most obvious reason for using LAC+CI is that identical ARFCN+BSIC are -typically re-used across many cells of the same network operator: an operator -will have only very few ARFCNs available, and the 6bit BSIC opens only a very -limited range of distinction between cells. As long as each cell has no more -than one neighbor per given ARFCN+BSIC, these values can be re-used any number -of times across a network, and even between cells managed by one and the same -BSC. - -The consequence of this is that - -- the BSC needs to know which remote-BSS cells' ARFCN+BSIC correspond to - exactly which global LAC+CI, and -- the MSC needs to know which LAC+CI are managed by which BSC. - -In other words, each BSC requires prior knowledge about the cell configuration -of its remote-BSS neighbor cells, and the MSC requires prior knowledge about -each BSC's cell identifiers; i.e. these config items are spread reduntantly. - -=== Configuring Neighbors - -The most important step to enable handover in OsmoBSC is to configure each cell -with the ARFCN+BSIC identities of its adjacent neighbors -- both local-BSS and -remote-BSS. - -For a long time, OsmoBSC has offered configuration to manually enter the -ARFCN+BSIC sent out as neighbors on various System Information messages (all -`neighbor-list` related commands). This is still possible, however, -particularly for re-using ARFCN+BSIC within one BSS, this method will not work -well. - -With the addition of inter-BSC handover support, the new `neighbor` config item -has been added to the `bts` config, to maintain explicit cell-to-cell neighbor -relations, with the possibility to re-use ARFCN+BSIC in each cell. - -It is recommended to completely replace `neighbor-list` configurations with the -new `neighbor` configuration described below. - -[[neighbor_conf_list]] -.Overview of neighbor configuration on the `bts` config node -[frame="none",grid="none",cols="^10%,^10%,80%"] -|==== -| Local | Remote BSS | -| ✓ | | neighbor bts 5 -| ✓ | | neighbor lac 200 -| ✓ | | neighbor lac-ci 200 3 -| ✓ | | neighbor cgi 001 01 200 3 -| ✓ | ✓ | neighbor lac 200 arfcn 123 bsic 1 -| ✓ | ✓ | neighbor lac-ci 200 3 arfcn 123 bsic 1 -| ✓ | ✓ | neighbor cgi 001 01 200 3 arfcn 123 bsic 1 -|==== - -==== Default: All Local Cells are Neighbors - -For historical reasons, the default behavior of OsmoBSC is to add all local-BSS cells as neighbors. To -maintain a backwards compatible configuration file format, this is still the case: as soon as no explicit -neighbor cell is configured with a `neighbor` command (either none was configured, or all configured -neighbors have been removed again), a cell automatically lists all of the local-BSS cells as neighbors. -These are implicit mappings in terms of the legacy neighbor configuration scheme, and re-using ARFCN+BSIC -combinations within a BSS will not work well this way. - -As soon as the first explicit neighbor relation is added to a cell, the legacy behavior is switched off, -and only explicit neighbors are in effect. - -NOTE: If a cell is required to not have any neighbors, it is recommended to rather switch off handover -for that cell with `handover 0`. An alternative solution is to set `neighbor-list mode manual` and not -configure any `neighbor-list` entries. - -==== Local-BSS Neighbors - -Local neighbors can be configured by just the local BTS number, or by LAC+CI, -or any other supported A-interface type cell identification; also including the -ARFCN+BSIC is optional, it will be derived from the local configuration if -omitted. - -OsmoBSC will log errors in case the configuration includes ambiguous ARFCN+BSIC -relations (when one given cell has more than one neighbor for any one -ARFCN+BSIC). - -Neighbor relations must be configured explicitly in both directions, i.e. each -cell has to name all of its neighbors, even if the other cell already has an -identical neighbor relation in the reverse direction. - -.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by local BTS number ----- -network - bts 0 - neighbor bts 1 - bts 1 - neighbor bts 0 ----- - -.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by LAC+CI ----- -network - - bts 0 - # this cell's LAC=23 CI=5 - location_area_code 23 - cell_identity 5 - # reference bts 1 - neighbor lac-ci 23 6 - - bts 1 - # this cell's LAC=23 CI=6 - location_area_code 23 - cell_identity 6 - # reference bts 0 - neighbor lac-ci 23 5 ----- - -It is allowed to include the ARFCN and BSIC of local neighbor cells, even -though that is redundant with the already known local configuration of the -other cell. The idea is to ease generating the neighbor configuration -automatically, since local-BSS and remote-BSS neighbors then share identical -configuration formatting. For human readability and maintainability, it may -instead be desirable to use the `neighbor bts <0-255>` format. - -.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, redundantly identified by LAC+CI as well as ARFCN+BSIC ----- -network - - bts 0 - # this cell's LAC=23 CI=5 - location_area_code 23 - cell_identity 5 - # this cell's ARFCN=1 BSIC=1 - trx 0 - arfcn 1 - base_station_id_code 1 - # reference bts 1 - neighbor lac-ci 23 6 arfcn 2 bsic 2 - - bts 1 - # LAC=23 CI=6 - location_area_code 23 - cell_identity 6 - # this cell's ARFCN=2 BSIC=2 - trx 0 - arfcn 2 - base_station_id_code 2 - # reference bts 0 - neighbor lac-ci 23 5 arfcn 1 bsic 1 ----- - -If the cell identification matches a local cell, OsmoBSC will report errors if -the provided ARFCN+BSIC do not match. - -==== Remote-BSS Neighbors - -Remote-BSS neighbors _always_ need to be configured with full A-interface -identification _and_ ARFCN+BSIC, to allow mapping a cell's neighbor ARFCN+BSIC -to a _BSSMAP Cell Identifier_ (see 3GPP TS 48.008 3.1.5.1 Handover Required -Indication and 3.2.1.9 HANDOVER REQUIRED). - -.Example: configuring remote-BSS neighbors in osmo-bsc.cfg, identified by LAC+CI (showing both BSCs' configurations) ----- -# BSC Alpha's osmo-bsc.cfg -network - bts 0 - # this cell's LAC=23 CI=6 - location_area_code 23 - cell_identity 6 - # this cell's ARFCN=2 BSIC=2 - trx 0 - arfcn 2 - base_station_id_code 2 - # fully describe the remote cell by LAC+CI and ARFCN+BSIC - neighbor lac-ci 42 3 arfcn 1 bsic 3 - -# BSC Beta's osmo-bsc.cfg -network - bts 0 - # this cell's LAC=42 CI=3 - location_area_code 42 - cell_identity 3 - # this cell's ARFCN=1 BSIC=3 - trx 0 - arfcn 1 - base_station_id_code 3 - # fully describe the remote cell by LAC+CI and ARFCN+BSIC - neighbor lac-ci 23 6 arfcn 2 bsic 2 ----- - -NOTE: It is strongly recommended to stick to a single format for remote-BSS -neighbors' cell identifiers all across an OsmoBSC configuration; i.e. decide -once to use `lac`, `lac-ci` or `cgi` and then stick to that within a given -osmo-bsc.cfg. The reason is that the _Cell Identifier List_ sent in the _BSSMAP -Handover Required_ message must have one single cell identifier type for all -list items. Hence, to be able to send several alternative remote neighbors to -the MSC, the configured cell identifiers must be of the same type. If in doubt, -use the full CGI identifier everywhere. - -==== Reconfiguring Neighbors in a Running OsmoBSC - -When modifying a cell's neighbor configuration in a telnet VTY session while a cell is already active, -the neighbor configuration will merely be cached in the BSC's local config. To take actual effect, it is -necessary to - -- either, re-connect the cell to the BSC (e.g. via `drop bts connection <0-255> oml`) -- or, re-send the System Information using `bts <0-255> resend-system-information`. - -=== Configuring Handover Decisions - -For a long time, OsmoBSC has supported handover based on reception level -hysteresis (RXLEV) and distance (TA, Timing Advance), known has `algorithm 1`. - -Since 2018, OsmoBSC also supports a load-based handover decision algorithm, -known as `algorithm 2`, which also takes cell load, available codecs and -oscillation into consideration. Algorithm 2 had actually been implemented for -the legacy OsmoNITB program many years before the OsmoMSC split, but remained -on a branch, until it was forward-ported to OsmoBSC in 2018. - -.What handover decision algorithms take into account -[frame="none",grid="none",cols="^10%,^10%,80%"] -|==== -| algorithm 1 | algorithm 2 | -| ✓ | ✓| RXLEV -| ✓ | ✓| RXQUAL -| ✓ | ✓| TA (distance) -| ✓ | ✓| interference (good RXLEV, bad RXQUAL) -| | ✓| load (nr of free lchans, minimum RXLEV and RXQUAL) -| | ✓| penalty time to avoid oscillation -| | ✓| voice rate / codec bias -| ✓ | | inter-BSC: RXLEV hysteresis -| | ✓| inter-BSC: only below minimum RXLEV, RXQUAL -|==== - -==== Common Configuration - -Handover is disabled by default; to disable/enable handover, use `handover -(0|1)`. - -Once enabled, algorithm 1 is used by default; choose a handover algorithm with -`handover algorithm (1|2)`: - ----- -network - # Enable handover - handover 1 - - # Choose algorithm - handover algorithm 2 - - # Tweak parameters for algorithm 2 (optional) - handover2 min-free-slots tch/f 4 - handover2 penalty-time failed-ho 30 - handover2 retries 1 ----- - -All handover algorithms share a common configuration scheme, with an overlay of -three levels: - -* immutable compile-time default values, -* configuration on the `network` level for all cells, -* individual cells' configuration on each `bts` node. - -Configuration settings relevant for algorithm 1 start with `handover1`, for -algorithm 2 with `handover2`. - -The following example overrides the compile-time default for all cells, and -furthermore sets one particular cell on its own individual setting, for the -`min-free-slots tch/f` value: - ----- -network - handover2 min-free-slots tch/f 4 - bts 23 - handover2 min-free-slots tch/f 2 ----- - -The order in which these settings are issued makes no difference for the -overlay; i.e., this configuration is perfectly identical to the above, and the -individual cell's value remains in force: - ----- -network - bts 23 - handover2 min-free-slots tch/f 2 - handover2 min-free-slots tch/f 4 ----- - -Each setting can be reset to a default value with the `default` keyword. When -resetting an individual cell's value, the globally configured value is used. -When resetting the global value, the compile-time default is used (unless -individual cells still have explicit values configured). For example, this -telnet VTY session removes above configuration first from the cell, then from -the global level: - ----- -OsmoBSC(config)# network -OsmoBSC(config-net)# bts 23 -OsmoBSC(config-net-bts)# handover2 min-free-slots tch/f default -% 'handover2 min-free-slots tch/f' setting removed, now is 4 -OsmoBSC(config-net-bts)# exit -OsmoBSC(config-net)# handover2 min-free-slots tch/f default -% 'handover2 min-free-slots tch/f' setting removed, now is 0 ----- - -==== Handover Algorithm 1 - -Algorithm 1 takes action only when RR Measurement Reports are received from a -BTS. As soon as a neighbor's average RXLEV is higher than the current cell's -average RXLEV plus a hysteresis distance, handover is triggered. - -If a handover fails, algorithm 1 will again attempt handover to the same cell -with the next Measurement Report received. - -Configuration settings relevant for algorithm 1 start with `handover1`. For -further details, please refer to the OsmoBSC VTY Reference -(<<vty-ref-osmobsc>>) or the telnet VTY online documentation. - -==== Handover Algorithm 2 - -Algorithm 2 is specifically designed to distribute load across cells. A -subscriber will not necessarily remain attached to the cell that has the best -RXLEV average, if that cell is heavily loaded and a less loaded neighbor is -above the minimum allowed RXLEV. - -Algorithm 2 also features penalty timers to avoid oscillation: for each -subscriber, if handover to a specific neighbor failed (for a configurable -number of retries), a holdoff timer prevents repeated attempts to handover to -that same neighbor. Several hold-off timeouts following specific situations are -configurable (see `handover2 penalty-time` configuration items). - -Configuration settings relevant for algorithm 2 start with `handover2`. For -further details, please refer to the OsmoBSC VTY Reference -<<vty-ref-osmobsc>> or the telnet VTY online documentation. - -===== Load Distribution - -Load distribution is only supported by algorithm 2. - -Load distribution occurs: - -- explicitly: every N seconds, OsmoBSC considers all local cells and actively - triggers handover operations to reduce congestion, if any. See - `min-free-slots` below, and the `congestion-check` setting. - -- implicitly: when choosing the best neighbor candidate for a handover - triggered otherwise, a congested cell (in terms of `min-free-slots`) is only - used as handover target if there is no alternative that causes less cell - load. - -In either case, load distribution will only occur towards neighbor cells that -adhere to minimum reception levels and distance, see `min rxlev` and `max -distance`. - -Load distribution will take effect only for already established voice channels. -An MS will always first establish a voice call with its current cell choice; in -load situations, it might be moved to another cell shortly after that. -Considering the best neighbor _before_ starting a new voice call might be -desirable, but is currently not implemented. Consider that RXLEV/RXQUAL ratings -are averaged over a given number of measurement reports, so that the neighbor -ratings may not be valid/reliable yet during early call establishment. In -consequence, it is recommended to ensure a sufficient number of unused logical -channels at all times, though there is no single correct configuration for all -situations. - -Most important for load distribution are the `min-free-slots tch/f` and -`min-free-slots tch/h` settings. The default is zero, meaning _no_ load -distribution. To enable, set `min-free-slots` >= 1 for `tch/f` and/or `tch/h` -as appropriate. This setting refers to the minimum number of voice channels -that should ideally remain unused in each individual BTS at all times. - -NOTE: it is not harmful to configure `min-free-slots` for a TCH kind that is -not actually present. Such settings will simply be ignored. - -NOTE: the number of TCH/F timeslots corresponds 1:1 to the number indicated by -`min-free-slots tch/f`, because each TCH/F physical channel has exactly one -logical channel. In contrast, for each TCH/H timeslot, there are two logical -channels, hence `min-free-slots tch/h` corresponds to twice the number of TCH/H -timeslots configured per cell. In fact, a more accurate naming would have been -"min-free-lchans". - -Think of the `min-free-slots` setting as the threshold at which load -distribution is considered. If as many logical channels as required by this -setting are available in a given cell, only changes in RXLEV/RXQUAL/TA trigger -handover away from that cell. As soon as less logical channels remain free, the -periodical congestion check attempts to distribute MS to less loaded neighbor -cells. Every time, the one MS that will suffer the least RXLEV loss while still -reducing congestion will be instructed to move first. - -If a cell and its neighbors are all loaded past their `min-free-slots` -settings, the algorithmic aim is equal load: a load-based handover will never -cause the target cell to be more congested than the source cell. - -The min-free-slots setting is a tradeoff between immediate voice service -availability and optimal reception levels. A sane choice could be: - -- Start off with `min-free-slots` set to half the available logical channels. -- Increase `min-free-slots` if you see MS being rejected too often even though - close neighbors had unused logical channels. -- Decrease `min-free-slots` if you see too many handovers happening for no - apparent reason. - -Choosing the optimal setting is not trivial, consider these examples: - -- Configure `min-free-slots` = 1: load distribution to other cells will occur - exactly when the last available logical channel has become occupied. The next - time the congestion check runs, at most one handover will occur, so that one - channel is available again. In the intermediate time, all channels will be - occupied, and some MS might be denied immediate voice service because of - that, even though, possibly, other neighbor cells would have provided - excellent reception levels and were completely unloaded. For those MS that - are already in an ongoing voice call and are not physically moving, though, - this almost guarantees service by the closest/best cell. - -- Set `min-free-slots` = 2: up to two MS can successfully request voice service - simultaneously (e.g. one MS is establishing a new voice call while another MS - is travelling into this cell). Ideally, two slots have been kept open and are - immediately available. But if a third MS is also traveling into this cell at - the same time, it will not be able to handover into this cell until load - distribution has again taken action to make logical channels available. The - same scenario applies to any arbitrary number of MS asking for voice channels - simultaneously. The operator needs to choose where to draw the line. - -- Set `min-free-slots` >= the number of available channels: as soon as any - neighbor is less loaded than a given cell, handover will be attempted. But - imagine there are only two active voice calls on this cell with plenty of - logical channels still unused, and the closest neighbor rates only just above - `min rxlev`; then moving one of the MS _for no good reason_ causes all of: - increased power consumption, reduced reception stability and channel - management overhead. - -NOTE: In the presence of dynamic timeslots to provide GPRS service, the number -of voice timeslots left unused also determines the amount of bandwidth -available for GPRS. - -==== External / Inter-BSC Handover Considerations - -There currently is a profound difference for inter-BSC handover between -algorithm 1 and 2: - -For algorithm 1, inter-BSC handover is triggered as soon as the Measurement -Reports and hysteresis indicate a better neighbor than the current cell, -period. - -For algorithm 2, a subscriber is "sticky" to the current BSS, and inter-BSC -handover is only even considered when RXLEV/TA drop below minimum requirements. - -- If your network topology is such that each OsmoBSC instance manages a single - BTS, and you would like to encourage handover between these, choose handover - algorithm 1. Load balancing will not be available, but RXLEV hysteresis will. - -- If your network topology has many cells per BSS, and/or if your BSS - boundaries in tendency correspond to physical/semantic boundaries that favor - handover to remain within a BSS, then choose handover algorithm 2. - -The reason for the difference between algorithm 1 and 2 for remote-BSS -handovers is, in summary, the young age of the inter-BSC handover feature in -OsmoBSC: - -- So far the mechanisms to communicate cell load to remote-BSS available in the - BSSMAP Handover messages are not implemented, so, a handover due to cell load - across BSS boundaries would be likely to cause handover oscillation between - the two BSS (continuous handover of the same MS back and forth between the - same two cells). -- Algorithm 1 has no `min rxlev` setting. -- Algorithm 1 does not actually use any information besides the Measurement - Reports, and hence can trivially treat all neighbor cells identically. |