| [[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 |
| <<vty>>. |
| |
| 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_ <<vty-ref-osmobsc>> 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 supports 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_ <<osmobts-abis-spec>> 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 <<dyn_ts_compat>>. |
| |
| 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 <<dyn_ts_compat>>. |
| |
| ==== 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`` 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. |
| |
| ==== Access Control Class 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. |
| |
| Furthermore, high priority users (such as PLMN staff, public or emergency |
| services, etc.) may be members of one or more ACCs from 11-15. |
| |
| Since the ACCs 0-9 are distributed uniformly across all SIMs, for instance |
| allowing only ACCs 0-4 to connect to the BTS should reduce its load by 50% at |
| the expense of not serving 50% of the subscribers. |
| |
| The default is to allow all ACCs to connect. |
| |
| OsmoBSC supports several levels of ACC management to allow or restrict access |
| either permanently or temporarily on each BTS. |
| |
| The first level of management consists of an access list to flag specific ACCs |
| as permanently barred (the list can be updated at any time through VTY as seen |
| below). As indicated above, the default is to allow all ACCs (0-15). |
| |
| .Example: Restrict permanent 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. |
| |
| On really crowded areas, a BTS may struggle to service all mobile stations |
| willing to use it, and which may end up in collapse. In this kind of scenarios |
| it is a good idea to temporarily further restrict the amount of allowed ACCs |
| (hence restrict the amount of subscribers allowed to reach the BTS). |
| However, doing so on a permanent basis would be unfair to subscribers from |
| barred ACCs. Hence, OsmoBSC can be configured to temporarily generate ACC |
| subsets of the permanent set presented above, and rotate them over time to allow |
| fair access to all subscribers. This feature is only aimed at ACCs 0-9, |
| since ACCs 11-15 are considered high priority and hence are always configured |
| based on permanent list policy. |
| |
| .Example: Configure rotative access to the BTS |
| ---- |
| network |
| bts 0 |
| access-control-rotate 3 <1> |
| access-control-rotate-quantum 20 <2> |
| ---- |
| <1> Only allow up to 3 concurrent allowed ACCs from the permanent list |
| <2> Rotate the generated permanent list subsets every 20 seconds in a fair fashion |
| |
| Furthermore, cells with large number of subscribers and limited overlapping |
| coverage may become overwhelmed with traffic after the cell starts brodacasting. |
| This is especially true in areas with little to no reception from other |
| networks. To manage the load, OsmoBSC has an option to further restrict the |
| rotating ACC subset during startup and slowly increment it over time and taking |
| current load into account. |
| |
| .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 |
| |
| |
| Here a full example of all the mechanisms combined can be found: |
| |
| .Example: Full ACC Load Management config setup |
| ---- |
| bts 0 |
| rach access-control-class 5 barred <1> |
| rach access-control-class 6 barred |
| rach access-control-class 7 barred |
| rach access-control-class 8 barred |
| rach access-control-class 9 barred |
| access-control-class-rotate 3 <2> |
| access-control-class-rotate-quantum 20 <3> |
| access-control-class-ramping <4> |
| access-control-class-ramping-step-size 1 <5> |
| access-control-class-ramping-step-interval dynamic <6> |
| ---- |
| <1> ACCs 5-9 are administratively barred, ie they will never be used until somebody manually enables them in VTY config |
| <2> Allow access through temporary subsets of len=3 from ACC set 0-4: (0,1,2) -> (1,2,3) -> (2,3,4) -> (3,4,0), etc. |
| <3> Each subset iteration will happen every 20 seconds |
| <4> During startup since ramping is enabled, it will further restrict the rotate subset size parameter (len=3) |
| <5> The rotate subset size parameter will be increased one ACC slot at a time: len=0 -> len=1 -> len=2 -> len=3 |
| <6> The time until the subset size is further increased will be calculated based on current channel load |
| |
| ==== 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. |