Pau Espin Pedrol | 1db53c8 | 2020-07-20 13:06:38 +0200 | [diff] [blame] | 1 | [[bts]] |
| 2 | == Reviewing and Provisioning BTS configuration |
| 3 | |
| 4 | The main functionality of the BSC component is to manage BTSs. As such, |
| 5 | provisioning BTSs within the BSC is one of the most common tasks during |
| 6 | BSC operation. Just like about anything else in OsmoBSC, they are |
| 7 | configured using the VTY. |
| 8 | |
| 9 | BTSs are internally numbered with integer numbers starting from "0" for |
| 10 | the first BTS. BTS numbers have to be contiguous, so you cannot |
| 11 | configure 0,1,2 and then 5. |
| 12 | |
| 13 | |
| 14 | === Reviewing current BTS status and configuration |
| 15 | |
| 16 | In order to view the status and properties of a BTS, you can issue the |
| 17 | `show bts` command. If used without any BTS number, it will display |
| 18 | information about all provisioned BTS numbers. |
| 19 | |
| 20 | ---- |
| 21 | OsmoBSC> show bts 0 |
| 22 | BTS 0 is of nanobts type in band DCS1800, has CI 0 LAC 1, BSIC 63, TSC 7 and 1 TRX |
| 23 | Description: (null) |
| 24 | MS Max power: 15 dBm |
| 25 | Minimum Rx Level for Access: -110 dBm |
| 26 | Cell Reselection Hysteresis: 4 dBm |
| 27 | RACH TX-Integer: 9 |
| 28 | RACH Max transmissions: 7 |
| 29 | System Information present: 0x0000007e, static: 0x00000000 |
| 30 | Unit ID: 200/0/0, OML Stream ID 0xff |
| 31 | NM State: Oper 'Enabled', Admin 2, Avail 'OK' |
| 32 | Site Mgr NM State: Oper 'Enabled', Admin 0, Avail 'OK' |
| 33 | Paging: 0 pending requests, 0 free slots |
| 34 | OML Link state: connected. |
| 35 | Current Channel Load: |
| 36 | TCH/F: 0% (0/5) |
| 37 | SDCCH8: 0% (0/8) |
| 38 | ---- |
| 39 | |
| 40 | You can also review the status of the TRXs configured within the BTSs of |
| 41 | this BSC by using `show trx`: |
| 42 | |
| 43 | ---- |
| 44 | OsmoBSC> show trx 0 0 |
| 45 | TRX 0 of BTS 0 is on ARFCN 871 |
| 46 | Description: (null) |
| 47 | RF Nominal Power: 23 dBm, reduced by 0 dB, resulting BS power: 23 dBm |
| 48 | NM State: Oper 'Enabled', Admin 2, Avail 'OK' |
| 49 | Baseband Transceiver NM State: Oper 'Enabled', Admin 2, Avail 'OK' |
| 50 | ip.access stream ID: 0x00 |
| 51 | ---- |
| 52 | |
| 53 | The output can be restricted to the TRXs of one specified BTS number |
| 54 | (`show trx 0`) or even that of a single specified TRX within a |
| 55 | specified BTS (`show trx 0 0`). |
| 56 | |
| 57 | Furthermore, information on the individual timeslots can be shown by |
| 58 | means of `show timeslot`. The output can be restricted to the |
| 59 | timeslots of a single BTS (`show timeslot 0`) or that of a single |
| 60 | TRX (`show timeslot 0 0`). Finally, you can restrict the output to |
| 61 | a single timeslot by specifying the BTS, TRX and TS numbers (`show |
| 62 | timeslot 0 0 4`). |
| 63 | |
| 64 | ---- |
| 65 | OsmoBSC> show timeslot 0 0 0 |
| 66 | BTS 0, TRX 0, Timeslot 0, phys cfg CCCH, TSC 7 |
| 67 | NM State: Oper 'Enabled', Admin 2, Avail 'OK' |
| 68 | OsmoBSC> show timeslot 0 0 1 |
| 69 | BTS 0, TRX 0, Timeslot 1, phys cfg SDCCH8, TSC 7 |
| 70 | NM State: Oper 'Enabled', Admin 2, Avail 'OK' |
| 71 | ---- |
| 72 | |
| 73 | |
| 74 | === Provisioning a new BTS |
| 75 | |
| 76 | In order to provision BTSs, you have to enter the BTS config node of the |
| 77 | VTY. In order to configure BTS 0, you can issue the following sequence |
| 78 | of commands: |
| 79 | |
| 80 | ---- |
| 81 | OsmoBSC> enable |
| 82 | OsmoBSC# configure terminal |
| 83 | OsmoBSC(config)# network |
| 84 | OsmoBSC(config-net)# bts 0 |
| 85 | OsmoBSC(config-net-bts)# |
| 86 | ---- |
| 87 | |
| 88 | At this point, you have a plethora of commands, in fact an entire |
| 89 | hierarchy of commands to configure all aspects of the BTS, as well as |
| 90 | each of its TRX and each timeslot within each TRX. For a full |
| 91 | reference, please consult the telnet VTY integrated help or the respective |
| 92 | chapter in the VTY reference. |
| 93 | |
| 94 | BTS configuration depends quite a bit on the specific BTS vendor and |
| 95 | model. The section below provides just one possible example for the |
| 96 | case of a sysmoBTS. |
| 97 | |
| 98 | Note that from the `configure terminal` command onwards, the telnet VTY |
| 99 | commands above are identical to configuration file settings, for details see |
| 100 | <<vty>>. |
| 101 | |
| 102 | Starting with `network` as above, your complete sysmoBTS configuration may look |
| 103 | like this: |
| 104 | |
| 105 | ---- |
| 106 | network |
| 107 | bts 0 |
| 108 | type sysmobts |
| 109 | band DCS1800 |
| 110 | description The new BTS in Baikonur |
| 111 | location_area_code 2342 |
| 112 | cell_identity 5 |
| 113 | base_station_id_code 63 |
| 114 | ip.access unit_id 8888 0 |
| 115 | ms max power 40 |
| 116 | trx 0 |
| 117 | arfcn 871 |
| 118 | nominal power 23 |
| 119 | max_power_red 0 |
| 120 | timeslot 0 |
| 121 | phys_chan_config CCCH+SDCCH4 |
| 122 | timeslot 1 |
| 123 | phys_chan_config TCH/F |
| 124 | timeslot 2 |
| 125 | phys_chan_config TCH/F |
| 126 | timeslot 3 |
| 127 | phys_chan_config TCH/F |
| 128 | timeslot 4 |
| 129 | phys_chan_config TCH/F |
| 130 | timeslot 5 |
| 131 | phys_chan_config TCH/F |
| 132 | timeslot 6 |
| 133 | phys_chan_config TCH/F |
| 134 | timeslot 7 |
| 135 | phys_chan_config PDCH |
| 136 | ---- |
| 137 | |
| 138 | |
| 139 | === System Information configuration |
| 140 | |
| 141 | A GSM BTS periodically transmits a series of 'SYSTEM INFORMATION' |
| 142 | messages to mobile stations, both via the BCCH in idle mode, was well as |
| 143 | via the SACCH in dedicated mode. There are many different types of such |
| 144 | messages. For their detailed contents and encoding, please see _3GPP TS |
| 145 | 24.008_ <<3gpp-ts-24-008>>. |
| 146 | |
| 147 | For each of the 'SYSTEM INFORMATION' message types, you can configure to |
| 148 | have the BSC generate it automatically ('computed'), or you can specify |
| 149 | the respective binary message as a string of hexadecimal digits. |
| 150 | |
| 151 | The default configuration is to compute all (required) 'SYSTEM |
| 152 | INFORMATION' messages automatically. |
| 153 | |
| 154 | Please see the _OsmoBSC VTY Reference Manual_ <<vty-ref-osmobsc>> for |
| 155 | further information, particularly on the following commands: |
| 156 | |
| 157 | * `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)` |
| 158 | * `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` |
| 159 | |
| 160 | |
| 161 | === Neighbor List configuration |
| 162 | |
| 163 | Every BTS sends a list of ARFCNs of neighbor cells |
| 164 | . within its 'SYSTEM INFORMATION 2' (and 2bis/2ter) messages on the BCCH |
| 165 | . within its 'SYSTEM INFORMATION 5' messages on SACCH in dedicated mode |
| 166 | |
| 167 | For every BTS config node in the VTY, you can specify the behavior of |
| 168 | the neighbor list using the `neighbor list mode` VTY command: |
| 169 | |
| 170 | automatic:: |
| 171 | Automatically generate a list of neighbor cells using all other |
| 172 | BTSs configured in the VTY |
| 173 | manual:: |
| 174 | Manually specify the neighbor list by means of `neighbor-list |
| 175 | (add|del) arfcn <0-1023>` commands, having identical neighbor lists on |
| 176 | BCCH (SI2) and SACCH (SI5) |
| 177 | |
| 178 | manual-si5:: |
| 179 | Manually specify the neighbor list by means of `neighbor-list |
| 180 | (add|del) arfcn <0-1023>` for BCCH (SI2) and a separate neighbor list by |
| 181 | means of `si5 neighbor-list (add|del) arfcn <0-1023>` for SACCH (SI5). |
| 182 | |
| 183 | |
| 184 | === Configuring GPRS PCU parameters of a BTS |
| 185 | |
| 186 | In the case of BTS models using Abis/IP (IPA), the GPRS PCU is located |
| 187 | inside the BTS. The BTS then establishes a Gb connection to the SGSN. |
| 188 | |
| 189 | All the BTS-internal PCU configuration is performed via A-bis OML by |
| 190 | means of configuring the 'CELL', 'NSVC' (NS Virtual Connection and 'NSE' |
| 191 | (NS Entity). |
| 192 | |
| 193 | There is one 'CELL' node and one 'NSE' node, but there are two 'NSVC' |
| 194 | nodes. At the time of this writing, only the NSVC 0 is supported by |
| 195 | OsmoBTS, while both NSVC are supported by the ip.access nanoBTS. |
| 196 | |
| 197 | The respective VTY configuration parameters are described below. They |
| 198 | all exist beneath each BTS VTY config node. |
| 199 | |
| 200 | But let's first start with a small example |
| 201 | |
| 202 | .Example configuration of GPRS PCU parameters at VTY BTS node |
| 203 | ---- |
| 204 | OsmoBSC(config-net-bts)# gprs mode gprs |
| 205 | OsmoBSC(config-net-bts)# gprs routing area 1 |
| 206 | OsmoBSC(config-net-bts)# gprs cell bvci 1234 |
| 207 | OsmoBSC(config-net-bts)# gprs nsei 1234 |
| 208 | OsmoBSC(config-net-bts)# gprs nsvc 0 nsvci 1234 |
| 209 | OsmoBSC(config-net-bts)# gprs nsvc 0 local udp port 23000 |
| 210 | OsmoBSC(config-net-bts)# gprs nsvc 0 remote udp port 23000 |
| 211 | OsmoBSC(config-net-bts)# gprs nsvc 0 remote ip 192.168.100.239 |
| 212 | ---- |
| 213 | |
| 214 | |
| 215 | === More explanation about the PCU config parameters |
| 216 | |
| 217 | //FIXME: should this go into VTY additions? |
| 218 | |
| 219 | ==== `gprs mode (none|gprs|egprs)` |
| 220 | |
| 221 | This command determines if GPRS (or EGPRS) services are to be enabled in |
| 222 | this cell at all. |
| 223 | |
| 224 | |
| 225 | ==== `gprs cell bvci <2-65535>` |
| 226 | |
| 227 | Configures the 'BSSGP Virtual Circuit Identifier'. It must be unique |
| 228 | between all BGSGP connections to one SGSN. |
| 229 | |
| 230 | NOTE: It is up to the system administrator to ensure all PCUs are |
| 231 | allocated an unique bvci. OsmoBSC will not ensure this policy. |
| 232 | |
| 233 | |
| 234 | ==== `gprs nsei <0-65535>` |
| 235 | |
| 236 | Configures the 'NS Entity Identifier'. It must be unique between all NS |
| 237 | connections to one SGSN. |
| 238 | |
| 239 | NOTE: It is up to the system administrator to ensure all PCUs are |
| 240 | allocated an unique bvci. OsmoBSC will not ensure this policy. |
| 241 | |
| 242 | |
| 243 | ==== `gprs nsvc <0-1> nsvci <0-65535>` |
| 244 | |
| 245 | Configures the 'NS Virtual Connection Identifier'. It must be unique |
| 246 | between all NS virtual connections to one SGSN. |
| 247 | |
| 248 | NOTE: It is up to the system administrator to ensure all PCUs are |
| 249 | allocated an unique nsvci. OsmoBSC will not ensure this policy. |
| 250 | |
| 251 | |
| 252 | ==== `gprs nsvc <0-1> local udp port <0-65535>` |
| 253 | |
| 254 | Configures the local (PCU side) UDP port for the NS-over-UDP link. |
| 255 | |
| 256 | |
| 257 | ==== `gprs nsvc <0-1> remote udp port <0-65535>` |
| 258 | |
| 259 | Configures the remote (SGSN side) UDP port for the NS-over-UDP link. |
| 260 | |
| 261 | |
| 262 | ==== `gprs nsvc <0-1> remote ip A.B.C.D` |
| 263 | |
| 264 | Configures the remote (SGSN side) UDP port for the NS-over-UDP link. |
| 265 | |
| 266 | |
| 267 | ==== `gprs ns timer (tns-block|tns-block-retries|tns-reset|tns-reset-retries|tns-test|tns-alive|tns-alive-retries)` <0-255> |
| 268 | |
| 269 | Configures the various GPRS NS related timers. Please check the GPRS NS |
| 270 | specification for the detailed meaning of those timers. |
| 271 | |
| 272 | |
| 273 | === Dynamic Timeslot Configuration (TCH / PDCH) |
| 274 | |
| 275 | A dynamic timeslot is in principle a voice timeslot (TCH) that is used to serve |
| 276 | GPRS data (PDCH) when no voice call is active on it. This enhances GPRS |
| 277 | bandwidth while no voice calls are active, which is dynamically scaled down as |
| 278 | voice calls need to be served. This is a tremendous improvement in service over |
| 279 | statically assigning a fixed number of timeslots for voice and data. |
| 280 | |
| 281 | The causality is as follows: to establish a voice call, the |
| 282 | MSC requests a logical channel of a given TCH kind from the BSC. The BSC |
| 283 | assigns such a channel from a BTS' TRX's timeslot of its choice. The knowledge |
| 284 | that a given timeslot is dynamic exists only on the BSC level. When the MSC |
| 285 | asks for a logical channel, the BSC may switch off PDCH on a dynamic timeslot |
| 286 | and then assign a logical TCH channel on it. Hence, though compatibility with |
| 287 | the BTS needs to be ensured, any MSC is compatible with dynamic timeslots by |
| 288 | definition. |
| 289 | |
Pau Espin Pedrol | 5487387 | 2020-07-20 13:11:04 +0200 | [diff] [blame^] | 290 | OsmoBSC supports two kinds of dynamic timeslot handling, configured via the |
| 291 | `network` / `bts` / `trx` / `timeslot` / `phys_chan_config` configuration. Not |
| 292 | all BTS models support dynamic channels. |
Pau Espin Pedrol | 1db53c8 | 2020-07-20 13:06:38 +0200 | [diff] [blame] | 293 | |
| 294 | [[dyn_ts_compat]] |
| 295 | .Dynamic timeslot support by various BTS models |
| 296 | [cols="50%,25%,25%"] |
| 297 | |=== |
| 298 | | |`TCH/F_TCH/H_PDCH` |`TCH/F_PDCH` |
| 299 | |ip.access nanoBTS |- |supported |
| 300 | |Ericsson RBS |supported |- |
| 301 | |sysmoBTS using _osmo-bts-sysmo_ |supported |supported |
| 302 | |various SDR platforms using _osmo-bts-trx_ |supported |supported |
| 303 | |Nutaq Litecell 1.5 using _osmo-bts-litecell15_ |supported |supported |
| 304 | |Octasic OctBTS using _osmo-bts-octphy_ | supported | supported |
| 305 | |=== |
| 306 | |
| 307 | The _OsmoBTS Abis Protocol Specification_ <<osmobts-abis-spec>> describes the |
| 308 | non-standard RSL messages used for these timeslot kinds. |
| 309 | |
| 310 | NOTE: Same as for dedicated PDCH timeslots, you need to enable GPRS and operate |
| 311 | a PCU, SGSN and GGSN to provide the actual data service. |
| 312 | |
| 313 | ==== Osmocom Style Dynamic Timeslots (TCH/F_TCH/H_PDCH) |
| 314 | |
| 315 | Timeslots of the `TCH/F_TCH/H_PDCH` type dynamically switch between TCH/F, |
| 316 | TCH/H and PDCH, depending on the channel kind requested by the MSC. The RSL |
| 317 | messaging for `TCH/F_TCH/H_PDCH` timeslots is compatible with Ericsson RBS. |
| 318 | |
| 319 | BTS models supporting this timeslot kind are shown in <<dyn_ts_compat>>. |
| 320 | |
| 321 | In the lack of transcoding capabilities, this timeslot type may cause |
| 322 | mismatching codecs to be selected for two parties of the same call, which would |
| 323 | cause call routing to fail ("`Cannot patch through call with different channel |
| 324 | types: local = TCH_F, remote = TCH_H`"). A workaround is to disable TCH/F on |
| 325 | this timeslot type, i.e. to allow only TCH/H. To disable TCH/F on Osmocom |
| 326 | style dynamic timeslots, use a configuration of |
| 327 | |
| 328 | ---- |
| 329 | network |
| 330 | dyn_ts_allow_tch_f 0 |
| 331 | ---- |
| 332 | |
| 333 | In OsmoNITB, disabling TCH/F on Osmocom dynamic timeslots is the default. In |
| 334 | OsmoBSC, the default is to allow both. |
| 335 | |
| 336 | ==== ip.access Style Dynamic Timeslots (TCH/F_PDCH) |
| 337 | |
| 338 | Timeslots of the `TCH/F_PDCH` type dynamically switch between TCH/F and PDCH. |
| 339 | The RSL messaging for `TCH/F_PDCH` timeslots is compatible with ip.access |
| 340 | nanoBTS. |
| 341 | |
| 342 | BTS models supporting this timeslot kind are shown in <<dyn_ts_compat>>. |
| 343 | |
| 344 | ==== Avoid PDCH Exhaustion |
| 345 | |
| 346 | To avoid disrupting GPRS, configure at least one timeslot as dedicated PDCH. |
| 347 | With only dynamic timeslots, a given number of voice calls would convert all |
| 348 | timeslots to TCH, and no PDCH timeslots would be left for GPRS service. |
| 349 | |
| 350 | ==== Dynamic Timeslot Configuration Examples |
| 351 | |
Pau Espin Pedrol | 5487387 | 2020-07-20 13:11:04 +0200 | [diff] [blame^] | 352 | This is an extract of an `osmo-bsc`` config file. A timeslot configuration with |
| 353 | five Osmocom style dynamic timeslots and one dedicated PDCH may look like this: |
Pau Espin Pedrol | 1db53c8 | 2020-07-20 13:06:38 +0200 | [diff] [blame] | 354 | |
| 355 | ---- |
| 356 | network |
| 357 | bts 0 |
| 358 | trx 0 |
| 359 | timeslot 0 |
| 360 | phys_chan_config CCCH+SDCCH4 |
| 361 | timeslot 1 |
| 362 | phys_chan_config SDCCH8 |
| 363 | timeslot 2 |
| 364 | phys_chan_config TCH/F_TCH/H_PDCH |
| 365 | timeslot 3 |
| 366 | phys_chan_config TCH/F_TCH/H_PDCH |
| 367 | timeslot 4 |
| 368 | phys_chan_config TCH/F_TCH/H_PDCH |
| 369 | timeslot 5 |
| 370 | phys_chan_config TCH/F_TCH/H_PDCH |
| 371 | timeslot 6 |
| 372 | phys_chan_config TCH/F_TCH/H_PDCH |
| 373 | timeslot 7 |
| 374 | phys_chan_config PDCH |
| 375 | ---- |
| 376 | |
| 377 | With the ip.access nanoBTS, only `TCH/F_PDCH` dynamic timeslots are supported, |
| 378 | and hence a nanoBTS configuration may look like this: |
| 379 | |
| 380 | ---- |
| 381 | network |
| 382 | bts 0 |
| 383 | trx 0 |
| 384 | timeslot 0 |
| 385 | phys_chan_config CCCH+SDCCH4 |
| 386 | timeslot 1 |
| 387 | phys_chan_config SDCCH8 |
| 388 | timeslot 2 |
| 389 | phys_chan_config TCH/F_PDCH |
| 390 | timeslot 3 |
| 391 | phys_chan_config TCH/F_PDCH |
| 392 | timeslot 4 |
| 393 | phys_chan_config TCH/F_PDCH |
| 394 | timeslot 5 |
| 395 | phys_chan_config TCH/F_PDCH |
| 396 | timeslot 6 |
| 397 | phys_chan_config TCH/F_PDCH |
| 398 | timeslot 7 |
| 399 | phys_chan_config PDCH |
| 400 | ---- |
| 401 | |
| 402 | === Tuning Access to the BTS |
| 403 | |
| 404 | OsmoBSC offers several configuration options to fine-tune access to the BTS. |
| 405 | It can allow only a portion of the subscribers access to the network. |
| 406 | This can also be used to ramp up access to the network on startup by slowly |
| 407 | letting in more and more subscribers. This is especially useful for isolated |
| 408 | cells with a huge number of subscribers. |
| 409 | |
| 410 | Other options control the behaviour of the MS when it needs to access the |
| 411 | random access channel before a dedicated channel is established. |
| 412 | |
| 413 | If the BTS is connected to the BSC via a high-latency connection the MS should |
| 414 | wait longer for an answer to a RACH request. If it does not the network will |
| 415 | have to deal with an increased load due to duplicate RACH requests. However, |
| 416 | in order to minimize the delay when a RACH request or response gets lost the |
| 417 | MS should not wait too long before retransmitting. |
| 418 | |
| 419 | ==== Load Management |
| 420 | |
| 421 | Every SIM card is member of one of the ten regular ACCs (0-9). Access to the |
| 422 | BTS can be restricted to SIMs that are members of certain ACCs. |
| 423 | |
| 424 | Since the ACCs are distributed uniformly across all SIMs allowing only ACCs |
| 425 | 0-4 to connect to the BTS should reduce its load by 50%. |
| 426 | |
| 427 | The default is to allow all ACCs to connect. |
| 428 | |
| 429 | .Example: Restrict access to the BTS by ACC |
| 430 | ---- |
| 431 | network |
| 432 | bts 0 |
| 433 | rach access-control-class 1 barred <1> |
| 434 | rach access-control-class 9 allowed <2> |
| 435 | ---- |
| 436 | <1> Disallow SIMs with access-class 1 from connecting to the BTS |
| 437 | <2> Permit SIMs with access-class 9 to connect to the BTS. |
| 438 | |
| 439 | |
| 440 | Smaller cells with lots of subscribers can be overwhelmed with traffic after |
| 441 | the network is turned on. This is especially true in areas with little to no |
| 442 | reception from other networks. To manage the load OsmoBSC has an option to |
| 443 | enable one Access Class at a time so initial access to the network is |
| 444 | distributed across a longer time. |
| 445 | |
| 446 | .Example: Ramp up access to the BTS after startup |
| 447 | ---- |
| 448 | network |
| 449 | bts 0 |
| 450 | access-control-class-ramping <1> |
| 451 | access-control-class-ramping-step-interval 30 <2> |
| 452 | access-control-class-ramping-step-size 1 <3> |
| 453 | ---- |
| 454 | <1> Turn on access-control-class ramping |
| 455 | <2> Enable more ACCs every 30 seconds |
| 456 | <3> At each step enable one more ACC |
| 457 | |
| 458 | |
| 459 | ==== RACH Parameter Configuration |
| 460 | |
| 461 | The following parameters allow control over how the MS can access the random |
| 462 | access channel (RACH). It is possible to set a minimum receive level under |
| 463 | which the MS will not even attempt to access the network. |
| 464 | |
| 465 | The RACH is a shared channel which means multiple MS can choose to send a |
| 466 | request at the same time. To minimize the risk of a collision each MS will |
| 467 | choose a random number of RACH slots to wait before trying to send a RACH |
| 468 | request. |
| 469 | |
| 470 | On very busy networks the range this number is chosen from should be |
| 471 | high to avoid collisions, but a lower range reduces the overall delay when |
| 472 | trying to establish a channel. |
| 473 | |
| 474 | The option `rach tx integer N` controls the range from which this number X |
| 475 | is chosen. It is `0 <= X < max(8,N)`. |
| 476 | |
| 477 | After sending a RACH request the MS will wait a random amount of slots before |
| 478 | retransmitting its RACH request. The range it will wait is also determined by |
| 479 | the option `rach tx integer N`, but calculating it is not so straightforward. |
| 480 | It is defined as `S <= X < S+N` where `S` is determined from a table. |
| 481 | |
| 482 | In particular `S` is lowest when `N` is one of 3, 8, 14 or 50 and highest when |
| 483 | `N` is 7, 12 or 32. |
| 484 | |
| 485 | For more information see _3GPP TA 44.018_ <<3gpp-ts-44-018>> Ch. 3.3.1.1.2 and |
| 486 | Table 3.3.1.1.2.1 in particular. |
| 487 | |
| 488 | The amount of times the MS attempts to retransmit RACH requests can also be |
| 489 | changed. A higher number means more load on the RACH while a lower number can |
| 490 | cause channel establishment to fail due to collisions or bad reception. |
| 491 | |
| 492 | .Example: Configure RACH Access Parameters |
| 493 | ---- |
| 494 | network |
| 495 | bts 0 |
| 496 | rxlev access min 20 <1> |
| 497 | rach tx integer 50<2> |
| 498 | rach max transmission <3> |
| 499 | ---- |
| 500 | <1> Allow access to the network if the MS receives the BCCH of the cell at |
| 501 | -90dBm or better (20dB above -110dBm). |
| 502 | <2> This number affects how long the MS waits before (re-)transmitting RACH |
| 503 | requests. |
| 504 | <3> How often to retransmit the RACH request. |