From 8c14a942d2c08cc59827b805105794eb576ff2d3 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Fri, 21 Sep 2018 14:00:08 +0200 Subject: bsc: document handover Add chapter "Handover", explaining: - intra- and - inter-BSC handover, - HO algorithm 1 and - algorithm 2 - new neighbor configuration Adjust copyright, add revision and add me as author. Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2 --- doc/manuals/Makefile | 2 +- doc/manuals/chapters/handover.adoc | 552 ++++++++++++++++++++++++++++ doc/manuals/chapters/handover_inter_bsc.dot | 35 ++ doc/manuals/chapters/handover_intra_bsc.dot | 31 ++ doc/manuals/osmobsc-usermanual-docinfo.xml | 22 +- doc/manuals/osmobsc-usermanual.adoc | 2 + 6 files changed, 642 insertions(+), 2 deletions(-) create mode 100644 doc/manuals/chapters/handover.adoc create mode 100644 doc/manuals/chapters/handover_inter_bsc.dot create mode 100644 doc/manuals/chapters/handover_intra_bsc.dot (limited to 'doc/manuals') diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 153348258..b9f50d0d9 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -2,7 +2,7 @@ TOPDIR = .. ASCIIDOC = osmobsc-usermanual.adoc osmux-reference.adoc aoip-mgw-options.adoc include $(TOPDIR)/build/Makefile.asciidoc.inc -osmobsc-usermanual.pdf: chapters/*.adoc +osmobsc-usermanual.pdf: chapters/*.adoc chapters/*.dot aoip-mgw-options.pdf: aoip-mgw-options.adoc mgw/*.msc VTY_REFERENCE = osmobsc-vty-reference.xml diff --git a/doc/manuals/chapters/handover.adoc b/doc/manuals/chapters/handover.adoc new file mode 100644 index 000000000..11206908b --- /dev/null +++ b/doc/manuals/chapters/handover.adoc @@ -0,0 +1,552 @@ +== 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 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 <>). 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 +|==== + +==== 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. + +=== 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 +(<>) 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 +<> 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. diff --git a/doc/manuals/chapters/handover_inter_bsc.dot b/doc/manuals/chapters/handover_inter_bsc.dot new file mode 100644 index 000000000..0cc655401 --- /dev/null +++ b/doc/manuals/chapters/handover_inter_bsc.dot @@ -0,0 +1,35 @@ +digraph G { +rankdir=LR + +subgraph cluster_bss_a { + label="BSS Alpha" + BTS_a0 [rank=min,label="bts 0\nARFCN=1 BSIC=1\nLAC=23 CI=5"] + BTS_a1 [rank=min,label="bts 1\nARFCN=2 BSIC=2\nLAC=23 CI=6"] + BSC_a [label="BSC Alpha"]; + {BTS_a0,BTS_a1} -> BSC_a [arrowhead=none,label=Abis] +} + +subgraph cluster_bss_b { + label="BSS Beta" + BTS_b0 [rank=min,label="bts 0\nARFCN=1 BSIC=3\nLAC=42 CI=3"] + BTS_b1 [rank=min,label="bts 1\nARFCN=2 BSIC=4\nLAC=42 CI=1"] + BSC_b [label="BSC Beta"] + {BTS_b0,BTS_b1} -> BSC_b [arrowhead=none,label=Abis] +} + +MS -> BTS_a1 [label="(3) Measurement:\nARFCN=1 BSIC=3 RXLEV"] +BTS_a1 -> MS [label="(1) my neighbors:\nARFCN=1 BSIC=1\nARFCN=1 BSIC=3"] +BTS_b0 -> MS [label="(2) good RXLEV",style=dotted] +MS -> {BTS_a0,BTS_b0,BTS_b1} [style=invisible,arrowhead=none] + +BTS_a1 -> BSC_a [label="(4) Measurement\nReport",style=dashed] +BTS_a1 -> BTS_b0 [label="(5) BSC decides to do\ninter-BSC Handover",style=dashed,constraint=false] + +{BSC_a,BSC_b} -> MSC [arrowhead=none,label=A] + +BSC_a -> MSC [label="(6) --> Handover Required\nto LAC=42 CI=6\n(10) <-- Handover Command",style=dashed,constraint=false,arrowhead=none] +MSC -> BSC_b [label="(7) <-- Handover Request\n(9) --> Handover Request ACK",style=dashed,constraint=false,arrowhead=none] + +BSC_b -> BTS_b0 [label="(8) activate new lchan",style=dashed,constraint=false] + +} diff --git a/doc/manuals/chapters/handover_intra_bsc.dot b/doc/manuals/chapters/handover_intra_bsc.dot new file mode 100644 index 000000000..2a4f6cf15 --- /dev/null +++ b/doc/manuals/chapters/handover_intra_bsc.dot @@ -0,0 +1,31 @@ +digraph G { +rankdir=LR + +subgraph cluster_bss_a { + label="BSS Alpha" + BTS_a0 [rank=min,label="bts 0\nARFCN=1 BSIC=1\nLAC=23 CI=5"] + BTS_a1 [rank=min,label="bts 1\nARFCN=2 BSIC=2\nLAC=23 CI=6"] + BSC_a [label="BSC Alpha"]; + {BTS_a0,BTS_a1} -> BSC_a [arrowhead=none,label=Abis] +} + +subgraph cluster_bss_b { + label="BSS Beta" + BTS_b0 [rank=min,label="bts 0\nARFCN=1 BSIC=3\nLAC=42 CI=3"] + BTS_b1 [rank=min,label="bts 1\nARFCN=2 BSIC=4\nLAC=42 CI=1"] + BSC_b [label="BSC Beta"] + {BTS_b0,BTS_b1} -> BSC_b [arrowhead=none,label=Abis] +} + +MS -> BTS_a1 [label="(3) Measurement:\nARFCN=1 BSIC=1 RXLEV"] +BTS_a1 -> MS [label="(1) my neighbors:\nARFCN=1 BSIC=1\nARFCN=1 BSIC=3"] +BTS_a0 -> MS [label="(2) good RXLEV",style=dotted] +MS -> {BTS_a0,BTS_b0,BTS_b1} [style=invisible,arrowhead=none] + +BTS_a1 -> BSC_a [label="(4) Measurement\nReport",style=dashed] +BTS_a1 -> BTS_a0 [label="(5) BSC decides to do\nintra-BSC Handover",style=dashed,constraint=false] +BSC_a -> BTS_a0 [label="(6) activate new lchan",style=dashed,constraint=false] + +{BSC_a,BSC_b} -> MSC [arrowhead=none,label=A] + +} diff --git a/doc/manuals/osmobsc-usermanual-docinfo.xml b/doc/manuals/osmobsc-usermanual-docinfo.xml index 5ac374201..6de53b2ac 100644 --- a/doc/manuals/osmobsc-usermanual-docinfo.xml +++ b/doc/manuals/osmobsc-usermanual-docinfo.xml @@ -7,6 +7,15 @@ Initial OsmoBSC manual, recycling OsmoNITB sections + + 2 + October 2018 + NH + + Add Handover chapter: document new neighbor configuration, HO algorithm 2 + and inter-BSC handover. + + @@ -32,10 +41,21 @@ Managing Director + + Neels + Hofmeyr + nhofmeyr@sysmocom.de + NH + + sysmocom + sysmocom - s.f.m.c. GmbH + Developer + + - 2012-2016 + 2012-2018 sysmocom - s.f.m.c. GmbH diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index e3eadafbb..0ec15e54b 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -15,6 +15,8 @@ include::chapters/control.adoc[] include::chapters/counters.adoc[] +include::chapters/handover.adoc[] + include::../common/chapters/vty.adoc[] include::../common/chapters/logging.adoc[] -- cgit v1.2.3