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
|
[[bts-examples]]
== OsmoBSC example configuration files
The `osmo-bsc/doc/examples/osmo-bsc` directory in the OpenBSC source
tree contains a collection of example configuration files, sorted by BTS
type.
This chapter is illustrating some excerpts from those examples
[[bts_example_nbts]]
=== Example configuration for OsmoBSC with one single-TRX nanoBTS
.OsmoBSC with one single-TRX nanoBTS
====
----
e1_input
e1_line 0 driver ipa <1>
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type nanobts <2>
band DCS1800 <3>
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
ipa unit-id 1801 0 <4>
oml ipa stream-id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 871 <5>
nominal power 23
max_power_red 20 <6>
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
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 TCH/F
----
====
<1> You have to configure one virtual E1 line with the
IPA driver in order to use Abis/IP. One e1_line is
sufficient for any number of A-bis/IP BTSs, there is no
limit like in physical E1 lines.
<2> The BTS type must be set using `type nanobts`
<3> The GSM band must be set according to the BTS hardware.
<4> The IPA Unit ID parameter must be set to what has been configured on
the BTS side using the __BTS Manager__ or `ipaccess-config`.
<5> The ARFCN of the BTS.
<6> All known nanoBTS units have a nominal transmit power of 23 dBm. If
a `max_power_red` of 20 (dB) is configured, the resulting output
power at the BTS Tx port is 23 - 20 = 3 dBm.
[NOTE]
====
The `nominal_power` setting does __not__ influence the transmitted power
to the BTS! It is a setting by which the system administrator tells the
BSC about the nominal output power of the BTS. The BSC uses this as
basis for calculations.
====
[[bts_example_nbts_multi]]
=== Example configuration for OsmoBSC with multi-TRX nanoBTS
.OsmoBSC configured for dual-TRX (stacked) nanoBTS
====
----
e1_input
e1_line 0 driver ipa
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type nanobts
band DCS1800
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
ipa unit-id 1800 0 <1>
oml ipa stream-id 255 line 0
gprs mode none
trx 0
rf_locked 0
arfcn 871
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
timeslot 1
phys_chan_config SDCCH8
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 TCH/F
trx 1
rf_locked 0
arfcn 873
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config SDCCH8
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 TCH/F
----
====
<1> In this example, the IPA Unit ID is specified as `1800 0`. Thus, the
first nanoBTS unit (`trx 0`) needs to be configured to 1800/0/0 and
the second nanoBTS unit (`trx 1`) needs to be configured to 1800/0/1.
You can configure the BTS unit IDs using the `ipaccess-config`
utility included in OsmoBSC.
[NOTE]
====
For building a multi-TRX setup, you also need to connect the TIB cables
between the two nanoBTS units, as well as the coaxial/RF AUX cabling.
====
=== Example configuration for OsmoBSC with E1 BTS
The following configuration sample illustrates the usage of BTSs that are
connected via an E1/T1 backhaul.
.OsmoBSC configured for single-TRX E1 Ericsson DUG20
====
----
e1_input <1>
e1_line 0 driver dahdi
e1_line 0 port 3
network
network country code 1
mobile network code 1
encryption a5 0
neci 1
handover 0
bts 0
type rbs2000
band GSM900
om2000 version-limit oml gen 12 rev 10 <2>
cell_identity 0
location_area_code 1
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator mode set-all ascending
rach tx integer 9
rach max transmission 7
oml e1 line 0 timeslot 1 sub-slot full <3>
oml e1 tei 62 <4>
gprs mode none
is-connection-list add 4 512 12 <5>
is-connection-list add 16 524 12
is-connection-list add 28 536 12
is-connection-list add 40 548 12
trx 0
rf_locked 0
arfcn 123
nominal power 42
max_power_red 12
rsl e1 line 0 timeslot 1 sub-slot full <6>
rsl e1 tei 0 <7>
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
e1 line 0 timeslot 1 sub-slot full <8>
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 1 <9>
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 2
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 2 sub-slot 3
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 1
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 2
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
e1 line 0 timeslot 3 sub-slot 3
----
====
<1> In this example we use a dahdi E1 card. This card has 4 ports. Here we use port numer 3. It should be noted that the dahdi driver also requires additional configuration, which is not covered by this manual.
<2> In this example we use an E1 Ericsson DUG20, which uses an OML dialect, called "OM2000".
<3> The first usable timeslot on an E1 line is TS1. In this example we will assume that TS1-TS3 are connected to the BTS stright through. TS1 will handle all signaling traffic. Here we assign this timeslot to OML.
<4> OML always requires a TEI (Terminal Equipment Identifier) to set up. This number can be found in the manual of the BTS.
<5> This BTS has an built in “Interface Switch” (IS) that offers flexible way to reconfigure the interconnection between the internal components of the BTS and the external E1 line. This depends on the exact BTS type and configuration.
<6> Similar to OML we assign TS1 to RSL as well.
<7> Like with OML, RSL also requires a TEI to be configured. Usually each TRX will have a specific TEI assigned.
<8> CCCH+SDCCH4 will also be mapped on TS1. The traffic for those control channels will be multiplexed alongside the RSL and OML traffic.
<9> The bandwidth of one E1 timeslot matches the bandwidth of 4 GSM air interface timeslots. The E1 timeslot is split up into four sub-slots, which are then assigned to one GSM air interface timeslot each. Since the first timeslot on the first TRX is already used for signaling we begin the sub-slot counting with sub-slot 1 for alignment reasons.
=== E1 Line number and MGCP trunk number
The switching of the voice channels is done via OsmoMGW, which acts as a media
converter between E1 and VoIP (RTP). OsmoBSC will use the E1 line number to
address the trunk via MGCP.
When configuring OsmoMGW, one needs to make sure that the trunk number that is
set up on OsmoMGW, matches the line number that is set up on OsmoBSC. When those
numbers mismatch the trunk cannot be addressed correctly.
.OsmoMGW trunk configuration that matches the OsmoBSC configuration above
====
----
trunk 0
rtp keep-alive once
no rtp keep-alive
line 0
----
====
|
