diff --git a/doc/manuals/chapters/bsc.adoc b/doc/manuals/chapters/bsc.adoc new file mode 100644 index 000000000..49d25e5a9 --- /dev/null +++ b/doc/manuals/chapters/bsc.adoc @@ -0,0 +1,120 @@ +== BSC level configuration + +The BSC component is shared between OsmoBSC and OsmoNITB. This chapter +describes some of the configuration options related to this shared BSC +component. + +=== Hand-over + +==== Hand-over in GSM + +Hand-over is the process of changing a MS with a currently active +dedicated channel from one BTS to another BTS. As opposed to idle mode, +where the MS autonomously performs cell re-selection, in dedicated mode +this happens under network control. + +In order to determine when to perform hand-over, and to which cells, the +network requests the MS to perform measurements on a list of neighbor +cell channels, which the MS then reports back to the network in the form +of GSM RR 'Measurement Result' messages. Those messages contain the +downlink measurements as determined by the MS. + +Furthermore, the BTS also performs measurements on the uplink, and +communicates those by means of RSL to the BSC. + +The hand-over decision is made by an algorithm that processes those +measurement results and determines when to perform the hand-over. + +==== Configuration of hand-over in OsmoBSC/OsmoNITB + +OsmoBSC (like the internal BSC component of OsmoNITB) only support +so-called intra-BSC hand-over, where the hand-over is performed between +two BTSs within the same BSC. + +Hand-over is enabled and configured by the use of a set of `handover` +commands. Using those, you can tune the key parameters of the hand-over +algorithm and adapt it to your specific environment. + +.Example handover configuration snippet +---- + handover 1 <1> + handover window rxlev averaging 10 <2> + handover window rxqual averaging 1 <3> + handover window rxlev neighbor averaging 10 <4> + handover power budget interval 6 <5> + handover power budget hysteresis 3 <6> + handover maximum distance 9999 <7> +---- +<1> Enable hand-over +<2> Set the RxLev averaging window for the serving cell to 10 measurements +<3> Set the RxQual averaging window for the serving cell to 1 + measurement (no window) +<4> Set the RxLev averaging for neighbor cells to 10 measurements +<5> Check for the conditions of a power budget hand-over every 6 SACCH + frames +<6> A neighbor cell must be at least 3 dB stronger than the serving cell + to be considered a candidate for hand-over +<7> Perform a maximum distance hand-over if TA is larger 9999 (i.e. never) + +//TODO: Move all to BSC node + +=== Timer Configuration + +The GSM specification specifies a variety of timers both on the network +as well as on the mobile station side. + +Those timers can be configured using the `timer tXXXX` command. + +.Configurable Timers +|=== +|node|timer|default|description +|network|t3101|10|Timeout for 'Immediate Assignment' (sec) +|network|t3103|?|Timeout for Handover (sec) +|network|t3105|40|Repetition of 'Physical Information' (sec) +|network|t3107|?|? +|network|t3109|?|RSL SACCH deactivation timeout (sec) +|network|t3111|?|RSL timeout to wait before releasing the RF channel (sec) +|network|t3113|60|Time to try paging for a subscriber (sec) +|network|t3115|?|? +|network|t3117|?|? +|network|t3119|?|? +|network|t3122|10|Waiting time after 'Immediate Assignment Reject' +|network|t3141|?|? +|=== + +//TODO: split between BSC and MSC timers + +=== Discontinuous Transmission (DTX) + +GSM provides a full-duplex voice call service. However, in any +civilized communication between human beings, only one of the +participants is speaking at any given point in time. This means that +most of the time, one of the two directions of the radio link is +transmitting so-called 'silence frames'. + +During such periods of quiescence in one of the two directions, it is +possible to suppress transmission of most of the radio bursts, as there +is no voice signal to transport. GSM calls this feature 'Discontinuous +Transmission'. It exists separately for uplink (DTXu) and downlink +(DTXd). + +Downlink DTX is only permitted on non-primary transceivers (!= TRX0), as +TRX0 must always transmit at constant output power to ensure it is +detected during cell selection. + +Uplink DTX is possible on any TRX, and serves primarily two uses: + +possible on any TRX, and serves primarily two uses: + +. reducing the MS battery consumption by transmitting at a lower duty cycle +. reducing the uplink interference caused in surrounding cells that + re-use the same ARFCN. + +DTS for both uplink and downlink is implemented in the BTS. Not all BTS +models support it. + +The Osmocom BSC component can instruct the BTS to enable or disable +uplink and/or downlink DTX by means of A-bis OML. + +//TODO: Test/implement, at least for uplink +//TODO: Move to BSC diff --git a/doc/manuals/chapters/bts.adoc b/doc/manuals/chapters/bts.adoc new file mode 100644 index 000000000..223cec169 --- /dev/null +++ b/doc/manuals/chapters/bts.adoc @@ -0,0 +1,505 @@ +[[bts]] +== Reviewing and Provisioning BTS configuration + +The main functionality of the BSC component is to manage BTSs. As such, +provisioning BTSs within the BSC is one of the most common tasks during +BSC operation. Just like about anything else in OsmoBSC, they are +configured using the VTY. + +BTSs are internally numbered with integer numbers starting from "0" for +the first BTS. BTS numbers have to be contiguous, so you cannot +configure 0,1,2 and then 5. + + +=== Reviewing current BTS status and configuration + +In order to view the status and properties of a BTS, you can issue the +`show bts` command. If used without any BTS number, it will display +information about all provisioned BTS numbers. + +---- +OsmoBSC> show bts 0 +BTS 0 is of nanobts type in band DCS1800, has CI 0 LAC 1, BSIC 63, TSC 7 and 1 TRX +Description: (null) +MS Max power: 15 dBm +Minimum Rx Level for Access: -110 dBm +Cell Reselection Hysteresis: 4 dBm +RACH TX-Integer: 9 +RACH Max transmissions: 7 +System Information present: 0x0000007e, static: 0x00000000 + Unit ID: 200/0/0, OML Stream ID 0xff + NM State: Oper 'Enabled', Admin 2, Avail 'OK' + Site Mgr NM State: Oper 'Enabled', Admin 0, Avail 'OK' + Paging: 0 pending requests, 0 free slots + OML Link state: connected. + Current Channel Load: + TCH/F: 0% (0/5) + SDCCH8: 0% (0/8) +---- + +You can also review the status of the TRXs configured within the BTSs of +this BSC by using `show trx`: + +---- +OsmoBSC> show trx 0 0 +TRX 0 of BTS 0 is on ARFCN 871 +Description: (null) + RF Nominal Power: 23 dBm, reduced by 0 dB, resulting BS power: 23 dBm + NM State: Oper 'Enabled', Admin 2, Avail 'OK' + Baseband Transceiver NM State: Oper 'Enabled', Admin 2, Avail 'OK' + ip.access stream ID: 0x00 +---- + +The output can be restricted to the TRXs of one specified BTS number +(`show trx 0`) or even that of a single specified TRX within a +specified BTS (`show trx 0 0`). + +Furthermore, information on the individual timeslots can be shown by +means of `show timeslot`. The output can be restricted to the +timeslots of a single BTS (`show timeslot 0`) or that of a single +TRX (`show timeslot 0 0`). Finally, you can restrict the output to +a single timeslot by specifying the BTS, TRX and TS numbers (`show +timeslot 0 0 4`). + +---- +OsmoBSC> show timeslot 0 0 0 +BTS 0, TRX 0, Timeslot 0, phys cfg CCCH, TSC 7 + NM State: Oper 'Enabled', Admin 2, Avail 'OK' +OsmoBSC> show timeslot 0 0 1 +BTS 0, TRX 0, Timeslot 1, phys cfg SDCCH8, TSC 7 + NM State: Oper 'Enabled', Admin 2, Avail 'OK' +---- + + +=== Provisioning a new BTS + +In order to provision BTSs, you have to enter the BTS config node of the +VTY. In order to configure BTS 0, you can issue the following sequence +of commands: + +---- +OsmoBSC> enable +OsmoBSC# configure terminal +OsmoBSC(config)# network +OsmoBSC(config-net)# bts 0 +OsmoBSC(config-net-bts)# +---- + +At this point, you have a plethora of commands, in fact an entire +hierarchy of commands to configure all aspects of the BTS, as well as +each of its TRX and each timeslot within each TRX. For a full +reference, please consult the telnet VTY integrated help or the respective +chapter in the VTY reference. + +BTS configuration depends quite a bit on the specific BTS vendor and +model. The section below provides just one possible example for the +case of a sysmoBTS. + +Note that from the `configure terminal` command onwards, the telnet VTY +commands above are identical to configuration file settings, for details see +<>. + +Starting with `network` as above, your complete sysmoBTS configuration may look +like this: + +---- +network + bts 0 + type sysmobts + band DCS1800 + description The new BTS in Baikonur + location_area_code 2342 + cell_identity 5 + base_station_id_code 63 + ip.access unit_id 8888 0 + ms max power 40 + trx 0 + arfcn 871 + nominal power 23 + max_power_red 0 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config TCH/F + timeslot 2 + phys_chan_config TCH/F + timeslot 3 + phys_chan_config TCH/F + timeslot 4 + phys_chan_config TCH/F + timeslot 5 + phys_chan_config TCH/F + timeslot 6 + phys_chan_config TCH/F + timeslot 7 + phys_chan_config PDCH +---- + + +=== System Information configuration + +A GSM BTS periodically transmits a series of 'SYSTEM INFORMATION' +messages to mobile stations, both via the BCCH in idle mode, was well as +via the SACCH in dedicated mode. There are many different types of such +messages. For their detailed contents and encoding, please see _3GPP TS +24.008_ <<3gpp-ts-24-008>>. + +For each of the 'SYSTEM INFORMATION' message types, you can configure to +have the BSC generate it automatically ('computed'), or you can specify +the respective binary message as a string of hexadecimal digits. + +The default configuration is to compute all (required) 'SYSTEM +INFORMATION' messages automatically. + +Please see the _OsmoBSC VTY Reference Manual_ <> for +further information, particularly on the following commands: + +* `system-information (1|2|3|4|5|6|7|8|9|10|13|16|17|18|19|20|2bis|2ter|2quater|5bis|5ter) mode (static|computed)` +* `system-information (1|2|3|4|5|6|7|8|9|10|13|16|17|18|19|20|2bis|2ter|2quater|5bis|5ter) static HEXSTRING` + + +=== Neighbor List configuration + +Every BTS sends a list of ARFCNs of neighbor cells +. within its 'SYSTEM INFORMATION 2' (and 2bis/2ter) messages on the BCCH +. within its 'SYSTEM INFORMATION 5' messages on SACCH in dedicated mode + +For every BTS config node in the VTY, you can specify the behavior of +the neighbor list using the `neighbor list mode` VTY command: + +automatic:: + Automatically generate a list of neighbor cells using all other + BTSs configured in the VTY +manual:: + Manually specify the neighbor list by means of `neighbor-list +(add|del) arfcn <0-1023>` commands, having identical neighbor lists on +BCCH (SI2) and SACCH (SI5) + +manual-si5:: + Manually specify the neighbor list by means of `neighbor-list +(add|del) arfcn <0-1023>` for BCCH (SI2) and a separate neighbor list by +means of `si5 neighbor-list (add|del) arfcn <0-1023>` for SACCH (SI5). + + +=== Configuring GPRS PCU parameters of a BTS + +In the case of BTS models using Abis/IP (IPA), the GPRS PCU is located +inside the BTS. The BTS then establishes a Gb connection to the SGSN. + +All the BTS-internal PCU configuration is performed via A-bis OML by +means of configuring the 'CELL', 'NSVC' (NS Virtual Connection and 'NSE' +(NS Entity). + +There is one 'CELL' node and one 'NSE' node, but there are two 'NSVC' +nodes. At the time of this writing, only the NSVC 0 is supported by +OsmoBTS, while both NSVC are supported by the ip.access nanoBTS. + +The respective VTY configuration parameters are described below. They +all exist beneath each BTS VTY config node. + +But let's first start with a small example + +.Example configuration of GPRS PCU parameters at VTY BTS node +---- +OsmoBSC(config-net-bts)# gprs mode gprs +OsmoBSC(config-net-bts)# gprs routing area 1 +OsmoBSC(config-net-bts)# gprs cell bvci 1234 +OsmoBSC(config-net-bts)# gprs nsei 1234 +OsmoBSC(config-net-bts)# gprs nsvc 0 nsvci 1234 +OsmoBSC(config-net-bts)# gprs nsvc 0 local udp port 23000 +OsmoBSC(config-net-bts)# gprs nsvc 0 remote udp port 23000 +OsmoBSC(config-net-bts)# gprs nsvc 0 remote ip 192.168.100.239 +---- + + +=== More explanation about the PCU config parameters + +//FIXME: should this go into VTY additions? + +==== `gprs mode (none|gprs|egprs)` + +This command determines if GPRS (or EGPRS) services are to be enabled in +this cell at all. + + +==== `gprs cell bvci <2-65535>` + +Configures the 'BSSGP Virtual Circuit Identifier'. It must be unique +between all BGSGP connections to one SGSN. + +NOTE: It is up to the system administrator to ensure all PCUs are +allocated an unique bvci. OsmoBSC will not ensure this policy. + + +==== `gprs nsei <0-65535>` + +Configures the 'NS Entity Identifier'. It must be unique between all NS +connections to one SGSN. + +NOTE: It is up to the system administrator to ensure all PCUs are +allocated an unique bvci. OsmoBSC will not ensure this policy. + + +==== `gprs nsvc <0-1> nsvci <0-65535>` + +Configures the 'NS Virtual Connection Identifier'. It must be unique +between all NS virtual connections to one SGSN. + +NOTE: It is up to the system administrator to ensure all PCUs are +allocated an unique nsvci. OsmoBSC will not ensure this policy. + + +==== `gprs nsvc <0-1> local udp port <0-65535>` + +Configures the local (PCU side) UDP port for the NS-over-UDP link. + + +==== `gprs nsvc <0-1> remote udp port <0-65535>` + +Configures the remote (SGSN side) UDP port for the NS-over-UDP link. + + +==== `gprs nsvc <0-1> remote ip A.B.C.D` + +Configures the remote (SGSN side) UDP port for the NS-over-UDP link. + + +==== `gprs ns timer (tns-block|tns-block-retries|tns-reset|tns-reset-retries|tns-test|tns-alive|tns-alive-retries)` <0-255> + +Configures the various GPRS NS related timers. Please check the GPRS NS +specification for the detailed meaning of those timers. + + +=== Dynamic Timeslot Configuration (TCH / PDCH) + +A dynamic timeslot is in principle a voice timeslot (TCH) that is used to serve +GPRS data (PDCH) when no voice call is active on it. This enhances GPRS +bandwidth while no voice calls are active, which is dynamically scaled down as +voice calls need to be served. This is a tremendous improvement in service over +statically assigning a fixed number of timeslots for voice and data. + +The causality is as follows: to establish a voice call, the +MSC requests a logical channel of a given TCH kind from the BSC. The BSC +assigns such a channel from a BTS' TRX's timeslot of its choice. The knowledge +that a given timeslot is dynamic exists only on the BSC level. When the MSC +asks for a logical channel, the BSC may switch off PDCH on a dynamic timeslot +and then assign a logical TCH channel on it. Hence, though compatibility with +the BTS needs to be ensured, any MSC is compatible with dynamic timeslots by +definition. + +OsmoBSC and OsmoNITB support two kinds of dynamic timeslot handling, configured +via the `network` / `bts` / `trx` / `timeslot` / `phys_chan_config` +configuration. Not all BTS models support dynamic channels. + +[[dyn_ts_compat]] +.Dynamic timeslot support by various BTS models +[cols="50%,25%,25%"] +|=== +| |`TCH/F_TCH/H_PDCH` |`TCH/F_PDCH` +|ip.access nanoBTS |- |supported +|Ericsson RBS |supported |- +|sysmoBTS using _osmo-bts-sysmo_ |supported |supported +|various SDR platforms using _osmo-bts-trx_ |supported |supported +|Nutaq Litecell 1.5 using _osmo-bts-litecell15_ |supported |supported +|Octasic OctBTS using _osmo-bts-octphy_ | supported | supported +|=== + +The _OsmoBTS Abis Protocol Specification_ <> describes the +non-standard RSL messages used for these timeslot kinds. + +NOTE: Same as for dedicated PDCH timeslots, you need to enable GPRS and operate +a PCU, SGSN and GGSN to provide the actual data service. + +==== Osmocom Style Dynamic Timeslots (TCH/F_TCH/H_PDCH) + +Timeslots of the `TCH/F_TCH/H_PDCH` type dynamically switch between TCH/F, +TCH/H and PDCH, depending on the channel kind requested by the MSC. The RSL +messaging for `TCH/F_TCH/H_PDCH` timeslots is compatible with Ericsson RBS. + +BTS models supporting this timeslot kind are shown in <>. + +In the lack of transcoding capabilities, this timeslot type may cause +mismatching codecs to be selected for two parties of the same call, which would +cause call routing to fail ("`Cannot patch through call with different channel +types: local = TCH_F, remote = TCH_H`"). A workaround is to disable TCH/F on +this timeslot type, i.e. to allow only TCH/H. To disable TCH/F on Osmocom +style dynamic timeslots, use a configuration of + +---- +network + dyn_ts_allow_tch_f 0 +---- + +In OsmoNITB, disabling TCH/F on Osmocom dynamic timeslots is the default. In +OsmoBSC, the default is to allow both. + +==== ip.access Style Dynamic Timeslots (TCH/F_PDCH) + +Timeslots of the `TCH/F_PDCH` type dynamically switch between TCH/F and PDCH. +The RSL messaging for `TCH/F_PDCH` timeslots is compatible with ip.access +nanoBTS. + +BTS models supporting this timeslot kind are shown in <>. + +==== Avoid PDCH Exhaustion + +To avoid disrupting GPRS, configure at least one timeslot as dedicated PDCH. +With only dynamic timeslots, a given number of voice calls would convert all +timeslots to TCH, and no PDCH timeslots would be left for GPRS service. + +==== Dynamic Timeslot Configuration Examples + +This is an extract of an `osmo-bsc` or `osmo-nitb` config file. A timeslot +configuration with five Osmocom style dynamic timeslots and one dedicated PDCH +may look like this: + +---- +network + bts 0 + trx 0 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config SDCCH8 + timeslot 2 + phys_chan_config TCH/F_TCH/H_PDCH + timeslot 3 + phys_chan_config TCH/F_TCH/H_PDCH + timeslot 4 + phys_chan_config TCH/F_TCH/H_PDCH + timeslot 5 + phys_chan_config TCH/F_TCH/H_PDCH + timeslot 6 + phys_chan_config TCH/F_TCH/H_PDCH + timeslot 7 + phys_chan_config PDCH +---- + +With the ip.access nanoBTS, only `TCH/F_PDCH` dynamic timeslots are supported, +and hence a nanoBTS configuration may look like this: + +---- +network + bts 0 + trx 0 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config SDCCH8 + timeslot 2 + phys_chan_config TCH/F_PDCH + timeslot 3 + phys_chan_config TCH/F_PDCH + timeslot 4 + phys_chan_config TCH/F_PDCH + timeslot 5 + phys_chan_config TCH/F_PDCH + timeslot 6 + phys_chan_config TCH/F_PDCH + timeslot 7 + phys_chan_config PDCH +---- + +=== Tuning Access to the BTS + +OsmoBSC offers several configuration options to fine-tune access to the BTS. +It can allow only a portion of the subscribers access to the network. +This can also be used to ramp up access to the network on startup by slowly +letting in more and more subscribers. This is especially useful for isolated +cells with a huge number of subscribers. + +Other options control the behaviour of the MS when it needs to access the +random access channel before a dedicated channel is established. + +If the BTS is connected to the BSC via a high-latency connection the MS should +wait longer for an answer to a RACH request. If it does not the network will +have to deal with an increased load due to duplicate RACH requests. However, +in order to minimize the delay when a RACH request or response gets lost the +MS should not wait too long before retransmitting. + +==== Load Management + +Every SIM card is member of one of the ten regular ACCs (0-9). Access to the +BTS can be restricted to SIMs that are members of certain ACCs. + +Since the ACCs are distributed uniformly across all SIMs allowing only ACCs +0-4 to connect to the BTS should reduce its load by 50%. + +The default is to allow all ACCs to connect. + +.Example: Restrict access to the BTS by ACC +---- +network + bts 0 + rach access-control-class 1 barred <1> + rach access-control-class 9 allowed <2> +---- +<1> Disallow SIMs with access-class 1 from connecting to the BTS +<2> Permit SIMs with access-class 9 to connect to the BTS. + + +Smaller cells with lots of subscribers can be overwhelmed with traffic after +the network is turned on. This is especially true in areas with little to no +reception from other networks. To manage the load OsmoBSC has an option to +enable one Access Class at a time so initial access to the network is +distributed across a longer time. + +.Example: Ramp up access to the BTS after startup +---- +network + bts 0 + access-control-class-ramping <1> + access-control-class-ramping-step-interval 30 <2> + access-control-class-ramping-step-size 1 <3> +---- +<1> Turn on access-control-class ramping +<2> Enable more ACCs every 30 seconds +<3> At each step enable one more ACC + + +==== RACH Parameter Configuration + +The following parameters allow control over how the MS can access the random +access channel (RACH). It is possible to set a minimum receive level under +which the MS will not even attempt to access the network. + +The RACH is a shared channel which means multiple MS can choose to send a +request at the same time. To minimize the risk of a collision each MS will +choose a random number of RACH slots to wait before trying to send a RACH +request. + +On very busy networks the range this number is chosen from should be +high to avoid collisions, but a lower range reduces the overall delay when +trying to establish a channel. + +The option `rach tx integer N` controls the range from which this number X +is chosen. It is `0 <= X < max(8,N)`. + +After sending a RACH request the MS will wait a random amount of slots before +retransmitting its RACH request. The range it will wait is also determined by +the option `rach tx integer N`, but calculating it is not so straightforward. +It is defined as `S <= X < S+N` where `S` is determined from a table. + +In particular `S` is lowest when `N` is one of 3, 8, 14 or 50 and highest when +`N` is 7, 12 or 32. + +For more information see _3GPP TA 44.018_ <<3gpp-ts-44-018>> Ch. 3.3.1.1.2 and +Table 3.3.1.1.2.1 in particular. + +The amount of times the MS attempts to retransmit RACH requests can also be +changed. A higher number means more load on the RACH while a lower number can +cause channel establishment to fail due to collisions or bad reception. + +.Example: Configure RACH Access Parameters +---- +network + bts 0 + rxlev access min 20 <1> + rach tx integer 50<2> + rach max transmission <3> +---- +<1> Allow access to the network if the MS receives the BCCH of the cell at +-90dBm or better (20dB above -110dBm). +<2> This number affects how long the MS waits before (re-)transmitting RACH +requests. +<3> How often to retransmit the RACH request. diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index 862c8f906..cb939cc90 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -18,11 +18,11 @@ include::./common/chapters/logging.adoc[] include::./common/chapters/cs7-config.adoc[] -include::./common/chapters/bts.adoc[] +include::{srcdir}/chapters/bts.adoc[] include::{srcdir}/chapters/bts-examples.adoc[] -include::./common/chapters/bsc.adoc[] +include::{srcdir}/chapters/bsc.adoc[] include::{srcdir}/chapters/handover.adoc[]