aboutsummaryrefslogtreecommitdiffstats
path: root/common/chapters/bts.adoc
blob: 6228310ac4959fa17af52a891fe44a9ac54aa149 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
[[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 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
----