[[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'
  IPA Abis/IP 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 osmo-bts
  band DCS1800
  description The new BTS in Baikonur
  location_area_code 0x0926
  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).


[[config_gprs_pcu_pars]]
=== 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 BSSGP 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 timeslot that is used to serve GPRS data
(PDCH), but that can be switched to be used either for voice (TCH) or signalling
(SDCCH8) when all other static timeslots are already in use. This enhances GPRS
bandwidth while there is no CS load, and is dynamically scaled down as CS
services 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%"]
|===
|                    |`DYNAMIC/OSMOCOM` |`DYNAMIC/IPACCESS`
|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 (DYNAMIC/OSMOCOM)

`DYNAMIC/OSMOCOM` is an alias for `TCH/F_TCH/H_SDCCH8_PDCH`.

Timeslots of the `DYNAMIC/OSMOCOM` type dynamically switch between TCH/F,
TCH/H, SDCCH8 and PDCH, depending on the channel kind requested by the MSC. The RSL
messaging for these 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 (DYNAMIC/IPACCESS)

`DYNAMIC/IPACCESS` is an alias for `TCH/F_PDCH`.

Timeslots of the `DYNAMIC/IPACCESS` type dynamically switch between TCH/F and PDCH.
The RSL messaging for `DYNAMIC/IPACCESS` 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 DYNAMIC/OSMOCOM
   timeslot 3
    phys_chan_config DYNAMIC/OSMOCOM
   timeslot 4
    phys_chan_config DYNAMIC/OSMOCOM
   timeslot 5
    phys_chan_config DYNAMIC/OSMOCOM
   timeslot 6
    phys_chan_config DYNAMIC/OSMOCOM
   timeslot 7
    phys_chan_config PDCH
----

With the ip.access nanoBTS, only `DYNAMIC/IPACCESS` 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 DYNAMIC/IPACCESS
   timeslot 3
    phys_chan_config DYNAMIC/IPACCESS
   timeslot 4
    phys_chan_config DYNAMIC/IPACCESS
   timeslot 5
    phys_chan_config DYNAMIC/IPACCESS
   timeslot 6
    phys_chan_config DYNAMIC/IPACCESS
   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 broadcasting.
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 channel load into account.
The channel load will always be checked, even after the start up procedure, at
an interval specified by the `access-control-class-ramping-step-interval` VTY
command. It will either keep, increase or decrease the size of the current
rotating ACC subset based on certain thresholds configured by
the `access-control-class-ramping-chan-load` VTY command.
As a result, if ACC ramping is enabled (`access-control-class-ramping`), the
number of concurrent allowed ACCs will start with *1* and will fluctuate over
time based on channel load in the interval *[1, `access-control-rotate`]*. This
means at any time there will be at least *1* allowed ACC which, together with
ACC rotation, will prevent from subscriber being unable to use the network.

.Example: Ramp up access to the BTS after startup
----
network
 bts 0
  access-control-class-ramping <1>
  access-control-class-ramping-step-size 1 <2>
  access-control-class-ramping-step-interval 30 <3>
  access-control-class-ramping-chan-load 71 89 <4>
----
<1> Turn on access-control-class ramping
<2> At each step enable one more ACC
<3> Check whether to allow more/less ACCs every 30 seconds
<4> The rotate subset size is increased if channel load is < 71%, and decreased if channel load is > 89%.


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 30 <6>
  access-control-class-ramping-chan-load 71 89 <7>
----
<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> Ramping is enabled: during startup it will further restrict the rotate subset size parameter (start at len=1, end at len=3)
<5> The rotate subset size parameter will be increased or decreased one ACC slot at a time: len=1 -> len=2 -> len=3
<6> Check to further increase or decrease the rotate subset size based on current channel load is triggered every 30 seconds
<7> The rotate subset size is increased if channel load is < 71%, and decreased if channel load is > 89%.

=== Configuring FACCH/SACCH repetition

osmo-bts supports repetition of FACCH, uplink SACCH and downlink SACCH as
described in _3GPP TS 44.006_ <<3gpp-ts-44.006>>. When the feature is enabled
it is applied dynamically, depending on the rf signal quality and MS
capabilities. FACCH/SACCH repetition (or ACCH repetition) repeats the channel
block transmission two times. This allows the transceiver to combine the symbols
from two separate transmissions, which increases the probability that even a
weak signal can be decoded.

Enabling ACCH repetition is especially recommended when using the AMR speech
codec. AMR already provides a forward error correction that is superior to
the forward error correction used with FACCH or SACCH. ACCH repetition is a
good way to even out this imbalance.

The VTY configuration allows to enable repetition for all three channel types
separately. For FACCH the operator has the option to restrict the repetition
to LAPDM command frames only. Alternatively it is also possible to allow all
LAPDM frame types for repetition. The following example shows a typical
configuration where ACCH repetition is fully enabled.

.Example typical configuration of ACCH repetition parameters at VTY BTS node
----
OsmoBSC(config-net-bts)# repeat dl-facch all
OsmoBSC(config-net-bts)# repeat ul-sacch
OsmoBSC(config-net-bts)# repeat dl-sacch
OsmoBSC(config-net-bts)# repeat rxqual 4
----

It should be noted that unless the repetition is enabled explicitly, the
repetition is turned off by default. If no threshold (see <<acch_rep_thr>>) is
set, the default value 4 (BER >= 1.6%) will be used. The following example shows
a minimal configuration where the repetition is only activated for FACCH LAPDM
command frames.

.Example minimal configuration of ACCH repetition parameters at VTY BTS node
----
OsmoBSC(config-net-bts)# repeat dl-facch command
----

Since it is not worthwhile to apply any repetition when the signal conditions
are good enough to ensure a reliable transmission in one round, the operator
has the option to set a threshold based on RXQUAL/BER at which the repetition
is switched on. The threshold mechanism implements a hysteresis to prevent
bouncing between repetition on and repetition off. Only when the signal quality
is increased again by two rxqual levels, the repetition is turned off again. It
is even possible to permanently enable repetition, regardless of the signal
quality.

[[acch_rep_thr]]
.ACCH repetition thresholds
[options="header",cols="20%,40%,40%"]
|===
|rxqual              |enable threshold                |disable threshold
|0		     |(repetition always on)          |(repetition always on)
|1                   |asciimath:[BER >= 0.2%]         |asciimath:[BER = 0%]
|2                   |asciimath:[BER >= 0.4%]         |asciimath:[BER = 0%]
|3                   |asciimath:[BER >= 0.8%]         |asciimath:[BER <= 0.2%]
|4                   |asciimath:[BER >= 1.6%]         |asciimath:[BER <= 0.4%]
|5                   |asciimath:[BER >= 3.2%]         |asciimath:[BER <= 0.8%]
|6                   |asciimath:[BER >= 6.4%]         |asciimath:[BER <= 1.6%]
|7                   |asciimath:[BER >= 12.8%]        |asciimath:[BER <= 3.2%]
|===

NOTE: osmo-bsc only sets the ACCH repetition parameters via RSL. Whether ACCH
repetition can be used depends on the BTS model and osmo-bts version. To
find out if a BTS supports ACCH repetition (BTS_FEAT_ACCH_REP), the VTY
command `show bts` can be used.

==== 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.

[[cfg_ericsson_rbs_is]]
=== Configuring Ericsson RBS Interface Switch (IS)

Ericsson RBS2000/RBS6000 base stations feature a so called "Interface Switch" (IS),
which is a built-in switchboard that interconnects between internal components
of the BTS. It also connects to the external E1 connections. This allows to
adapt the BTS to specific E1 networking requirements that may differ from the
usual timeslot configuration.

The internals of an Ericsson RBS are quite complex. In the following we will
only explain how to connect transceiver units (TRU) to an E1 interface pointing
to the outside world.

==== Understanding the is-connection-list VTY option

The IS operates on 16kbps subslots (ICPs), which means that there are no fixed
borders between E1 timeslots. Any number of consecutive subslots may be
connected through. However, depending on the components that are connected it
may still be a requirement to align on E1 timeslot borders.

The configuration of the IS is done using the is-connection-list command. The
first two numbers are the ICP numbers that specify the first subslot on both
sides that shall be interconnected. The third number (contiguity index) specifies
how many of the following subslots shall be connected.

In the following example we connect 4 blocks with 12 subslot each. The numbers
on the left are the ICP numbers of the E1 connection pointing to the outside.
The numbers in the middle are the ICP numbers of the subslots occupied by the
transceivers (one TRX per block). The third number is the contiguity index that
spans over 12 subslots or 3 E1 timeslots.

.Example: 4 TRX BTS (4 x 12 subslots)
----
network
 bts 0
  is-connection-list add 4 512 12
  is-connection-list add 16 524 12
  is-connection-list add 28 536 12
  is-connection-list add 40 548 12
----

==== E1 port and TRU ICP numbers

On the outside connection, the ICP counting begins at E1 timeslot 0 (port A)
but since E1 TS 0 is reserved for framing and synchronization of the E1 line
itself the first usable subslot is subslot 4 (beginning of E1 TS 1). Depending
on the configuration the BTS may have multiple E1 ports. The counting scheme
will repeat itself. This means the next usable ICP can be found at an offset
of 128.

.External connections of a BTS with two E1 ports
[options="header",cols="50%,25%,25%"]
|===
|Function		|Subslot offset (ICP)	|ICP count
|E1 port A		|4	 		|124
|E1 port B              |132			|124
|===

Depending on the transceiver configuration, a RBS2000/RBS6000 base station
usually features two sets of ICPs for each TRX. The reason for this is that with
the introduction of EGPRS more bandwidth than a single 16kbps subslot could
deliver was required. The solution to this was to add an entirely new set of IS
ICPs where full 64kbps E1 timeslots instead of 16kbps subslots could be
used to serve a single air interface timeslot. The two sets of ICPs must not be
mixed. Only one set may be used at a time.

.ICPs to use TRU with 16kbps subslots per TRAU
[options="header",cols="50%,25%,25%"]
|===
|Function		|Subslot offset (ICP)	|ICP count
|TRU-0, RSL/OML		|512	 		|4
|TRU-0, TRAU TS0..TS7	|516			|8
|TRU-1, RSL/OML		|524			|4
|TRU-1, TRAU TS0..TS7	|528			|8
|TRU-2, RSL/OML		|536			|4
|TRU-2, TRAU TS0..TS7	|540			|8
|TRU-3, RSL/OML		|548			|4
|TRU-3, TRAU TS0..TS7	|552			|8
|TRU-4, RSL/OML		|560			|4
|TRU-4, TRAU TS0..TS7	|564			|8
|TRU-5, RSL/OML		|572			|4
|TRU-5, TRAU TS0..TS7	|576			|8
|TRU-6, RSL/OML		|640			|4
|TRU-6, TRAU TS0..TS7	|644			|8
|TRU-7, RSL/OML		|652			|4
|TRU-7, TRAU TS0..TS7	|656			|8
|TRU-8, RSL/OML		|664			|4
|TRU-8, TRAU TS0..TS7	|668			|8
|TRU-9, RSL/OML		|676			|4
|TRU-9, TRAU TS0..TS7	|680			|8
|TRU-10, RSL/OML	|688			|4
|TRU-10, TRAU TS0..TS7	|692			|8
|TRU-11, RSL/OML	|700			|4
|TRU-11, TRAU TS0..TS7	|704			|8
|===

NOTE: Each air interface timeslot is served by its individual TRAU, so it is
possible to route each subslot (ICP) dedicated to TRAU individually. The
connections on the other end may contain gaps and do not have to be
consecutive.

.ICPs to use TRU with 64kbps subslots per TRAU
[options="header",cols="50%,25%,25%"]
|===
|Function		|Subslot offset	(ICP)	|ICP count
|TRU-0, RSL/OML		|712	 		|4
|TRU-0, TRAU TS0..TS7	|716			|32
|TRU-1, RSL/OML		|748			|4
|TRU-1, TRAU TS0..TS7	|752			|32
|TRU-2, RSL/OML		|784			|4
|TRU-2, TRAU TS0..TS7	|788			|32
|TRU-3, RSL/OML		|820			|4
|TRU-3, TRAU TS0..TS7	|824			|32
|TRU-4, RSL/OML		|856			|4
|TRU-4, TRAU TS0..TS7	|860			|32
|TRU-5, RSL/OML		|928			|4
|TRU-5, TRAU TS0..TS7	|932			|32
|TRU-6, RSL/OML		|964			|4
|TRU-6, TRAU TS0..TS7	|968			|32
|TRU-7, RSL/OML		|1000			|4
|TRU-7, TRAU TS0..TS7	|1004			|32
|TRU-8, RSL/OML		|1036			|4
|TRU-8, TRAU TS0..TS7	|1040			|32
|TRU-9, RSL/OML		|1072			|4
|TRU-9, TRAU TS0..TS7	|1076			|32
|TRU-10, RSL/OML	|1108			|4
|TRU-10, TRAU TS0..TS7	|1112			|32
|TRU-11, RSL/OML	|1144			|4
|TRU-11, TRAU TS0..TS7	|1148			|32
|===

NOTE: In case voice TRAU frames are transferred, only the first of the four
16kbps subslots is used. When the timeslot is switched to GPRS/EGPRS, the
full 64kbps bandwidth will be used. This also means that the set of four
ICPs per TRAU must be connected consecutively. Also the connection
to the outside must be aligned to E1 timeslot borders.