diff --git a/common/chapters/bsc.adoc b/common/chapters/bsc.adoc deleted file mode 100644 index 49d25e5..0000000 --- a/common/chapters/bsc.adoc +++ /dev/null @@ -1,120 +0,0 @@ -== 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/common/chapters/bts.adoc b/common/chapters/bts.adoc deleted file mode 100644 index 223cec1..0000000 --- a/common/chapters/bts.adoc +++ /dev/null @@ -1,505 +0,0 @@ -[[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.