402 lines
13 KiB
Plaintext
402 lines
13 KiB
Plaintext
[[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 Osmocom, 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`:
|
|
|
|
----
|
|
OpenBSC> 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`).
|
|
|
|
----
|
|
OpenBSC> show timeslot 0 0 0
|
|
BTS 0, TRX 0, Timeslot 0, phys cfg CCCH, TSC 7
|
|
NM State: Oper 'Enabled', Admin 2, Avail 'OK'
|
|
OpenBSC> 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
|
|
----
|
|
OpenBSC(config-net-bts)# gprs mode gprs
|
|
OpenBSC(config-net-bts)# gprs routing area 1
|
|
OpenBSC(config-net-bts)# gprs cell bvci 1234
|
|
OpenBSC(config-net-bts)# gprs nsei 1234
|
|
OpenBSC(config-net-bts)# gprs nsvc 0 nsvci 1234
|
|
OpenBSC(config-net-bts)# gprs nsvc 0 local udp port 23000
|
|
OpenBSC(config-net-bts)# gprs nsvc 0 remote udp port 23000
|
|
OpenBSC(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_ <<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@ 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
|
|
----
|