diff options
authorDaniel Willmann <>2020-01-08 16:34:15 +0100
committerDaniel Willmann <>2020-01-09 10:55:49 +0100
commit2dc172cff64f242723b16a9a6c733e93253dd781 (patch)
parentc2fb0370174f762a455f51ea28a90c3f37c0bda1 (diff)
bts.adoc: Add information about RACH tuning parameters
2 files changed, 60 insertions, 0 deletions
diff --git a/common/chapters/bibliography.adoc b/common/chapters/bibliography.adoc
index 96a8555..623f648 100644
--- a/common/chapters/bibliography.adoc
+++ b/common/chapters/bibliography.adoc
@@ -69,6 +69,9 @@
- [[[3gpp-ts-44-006]]] 3GPP TS 44.006: Mobile Station - Base Station
System (MS - BSS) interface; Data Link (DL) layer specification
+- [[[3gpp-ts-44-018]]] 3GPP TS 44.018: Mobile radio interface layer 3
+ specification; Radio Resource Control (RRC) protocol
- [[[3gpp-ts-44-064]]] 3GPP TS 44.064: Mobile Station - Serving GPRS
Support Node (MS-SGSN); Logical Link Control (LLC) Layer Specification
diff --git a/common/chapters/bts.adoc b/common/chapters/bts.adoc
index 2a8c83a..223cec1 100644
--- a/common/chapters/bts.adoc
+++ b/common/chapters/bts.adoc
@@ -408,6 +408,15 @@ 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.
==== Load Management
Every SIM card is member of one of the ten regular ACCs (0-9). Access to the
@@ -446,3 +455,51 @@ network
<1> Turn on access-control-class ramping
<2> Enable more ACCs every 30 seconds
<3> At each step enable one more ACC
+==== 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
+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. and
+Table 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
+ 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
+<3> How often to retransmit the RACH request.