Change in osmo-gsm-manuals[master]: Drop common/chapters/{bts, bsc}.adoc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Mon Jul 27 09:50:41 UTC 2020


pespin has submitted this change. ( https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/19330 )

Change subject: Drop common/chapters/{bts,bsc}.adoc
......................................................................

Drop common/chapters/{bts,bsc}.adoc

Those files were only used by osmo-bsc.git and openbsc.git, the later
being depreacted and not maintained. Hence, new features are added to
the first one only, and documentation diverges over time, so it makes no
sense to keep it shared.

Files were copied over in:
openbsc.git Change-Id Ic3b4192238be3147f61779845521eae84511fb7e
osmo-bsc.git Change-Id I20aa60d2f4111d66e922f3e2a73a20352ec1f7e4

Change-Id: I4d98049f6b49871bf5aabe4392da7a608fbc1fe9
---
D common/chapters/bsc.adoc
D common/chapters/bts.adoc
2 files changed, 0 insertions(+), 625 deletions(-)

Approvals:
  Jenkins Builder: Verified
  Hoernchen: Looks good to me, but someone else must approve
  fixeria: Looks good to me, but someone else must approve
  pespin: Looks good to me, approved



diff --git a/common/chapters/bsc.adoc b/common/chapters/bsc.adoc
deleted file mode 100644
index 49d25e5..0000000
--- a/common/chapters/bsc.adoc
+++ /dev/null
@@ -1,120 +0,0 @@
-== BSC level configuration
-
-The BSC component is shared between OsmoBSC and OsmoNITB.  This chapter
-describes some of the configuration options related to this shared BSC
-component.
-
-=== Hand-over
-
-==== Hand-over in GSM
-
-Hand-over is the process of changing a MS with a currently active
-dedicated channel from one BTS to another BTS.  As opposed to idle mode,
-where the MS autonomously performs cell re-selection, in dedicated mode
-this happens under network control.
-
-In order to determine when to perform hand-over, and to which cells, the
-network requests the MS to perform measurements on a list of neighbor
-cell channels, which the MS then reports back to the network in the form
-of GSM RR 'Measurement Result' messages.  Those messages contain the
-downlink measurements as determined by the MS.
-
-Furthermore, the BTS also performs measurements on the uplink, and
-communicates those by means of RSL to the BSC.
-
-The hand-over decision is made by an algorithm that processes those
-measurement results and determines when to perform the hand-over.
-
-==== Configuration of hand-over in OsmoBSC/OsmoNITB
-
-OsmoBSC (like the internal BSC component of OsmoNITB) only support
-so-called intra-BSC hand-over, where the hand-over is performed between
-two BTSs within the same BSC.
-
-Hand-over is enabled and configured by the use of a set of `handover`
-commands.  Using those, you can tune the key parameters of the hand-over
-algorithm and adapt it to your specific environment.
-
-.Example handover configuration snippet
-----
- handover 1 <1>
- handover window rxlev averaging 10 <2>
- handover window rxqual averaging 1 <3>
- handover window rxlev neighbor averaging 10 <4>
- handover power budget interval 6 <5>
- handover power budget hysteresis 3 <6>
- handover maximum distance 9999 <7>
-----
-<1> Enable hand-over
-<2> Set the RxLev averaging window for the serving cell to 10 measurements
-<3> Set the RxQual averaging window for the serving cell to 1
-    measurement (no window)
-<4> Set the RxLev averaging for neighbor cells to 10 measurements
-<5> Check for the conditions of a power budget hand-over every 6 SACCH
-    frames
-<6> A neighbor cell must be at least 3 dB stronger than the serving cell
-    to be considered a candidate for hand-over
-<7> Perform a maximum distance hand-over if TA is larger 9999 (i.e.  never)
-
-//TODO: Move all to BSC node
-
-=== Timer Configuration
-
-The GSM specification specifies a variety of timers both on the network
-as well as on the mobile station side.
-
-Those timers can be configured using the `timer tXXXX` command.
-
-.Configurable Timers
-|===
-|node|timer|default|description
-|network|t3101|10|Timeout for 'Immediate Assignment' (sec)
-|network|t3103|?|Timeout for Handover (sec)
-|network|t3105|40|Repetition of 'Physical Information' (sec)
-|network|t3107|?|?
-|network|t3109|?|RSL SACCH deactivation timeout (sec)
-|network|t3111|?|RSL timeout to wait before releasing the RF channel (sec)
-|network|t3113|60|Time to try paging for a subscriber (sec)
-|network|t3115|?|?
-|network|t3117|?|?
-|network|t3119|?|?
-|network|t3122|10|Waiting time after 'Immediate Assignment Reject'
-|network|t3141|?|?
-|===
-
-//TODO: split between BSC and MSC timers
-
-=== Discontinuous Transmission (DTX)
-
-GSM provides a full-duplex voice call service.  However, in any
-civilized communication between human beings, only one of the
-participants is speaking at any given point in time.  This means that
-most of the time, one of the two directions of the radio link is
-transmitting so-called 'silence frames'.
-
-During such periods of quiescence in one of the two directions, it is
-possible to suppress transmission of most of the radio bursts, as there
-is no voice signal to transport.  GSM calls this feature 'Discontinuous
-Transmission'.  It exists separately for uplink (DTXu) and downlink
-(DTXd).
-
-Downlink DTX is only permitted on non-primary transceivers (!= TRX0), as
-TRX0 must always transmit at constant output power to ensure it is
-detected during cell selection.
-
-Uplink DTX is possible on any TRX, and serves primarily two uses:
-
-possible on any TRX, and serves primarily two uses:
-
-. reducing the MS battery consumption by transmitting at a lower duty cycle
-. reducing the uplink interference caused in surrounding cells that
-  re-use the same ARFCN.
-
-DTS for both uplink and downlink is implemented in the BTS.  Not all BTS
-models support it.
-
-The Osmocom BSC component can instruct the BTS to enable or disable
-uplink and/or downlink DTX by means of A-bis OML.
-
-//TODO: Test/implement, at least for uplink
-//TODO: Move to BSC
diff --git a/common/chapters/bts.adoc b/common/chapters/bts.adoc
deleted file mode 100644
index 223cec1..0000000
--- a/common/chapters/bts.adoc
+++ /dev/null
@@ -1,505 +0,0 @@
-[[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
-----
-
-=== Tuning Access to the BTS
-
-OsmoBSC offers several configuration options to fine-tune access to the BTS.
-It can allow only a portion of the subscribers access to the network.
-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
-BTS can be restricted to SIMs that are members of certain ACCs.
-
-Since the ACCs are distributed uniformly across all SIMs allowing only ACCs
-0-4 to connect to the BTS should reduce its load by 50%.
-
-The default is to allow all ACCs to connect.
-
-.Example: Restrict access to the BTS by ACC
-----
-network
- bts 0
-  rach access-control-class 1 barred <1>
-  rach access-control-class 9 allowed <2>
-----
-<1> Disallow SIMs with access-class 1 from connecting to the BTS
-<2> Permit SIMs with access-class 9 to connect to the BTS.
-
-
-Smaller cells with lots of subscribers can be overwhelmed with traffic after
-the network is turned on. This is especially true in areas with little to no
-reception from other networks. To manage the load OsmoBSC has an option to
-enable one Access Class at a time so initial access to the network is
-distributed across a longer time.
-
-.Example: Ramp up access to the BTS after startup
-----
-network
- bts 0
-  access-control-class-ramping <1>
-  access-control-class-ramping-step-interval 30 <2>
-  access-control-class-ramping-step-size 1 <3>
-----
-<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
-request.
-
-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. 3.3.1.1.2 and
-Table 3.3.1.1.2.1 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
-----
-network
- 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
-requests.
-<3> How often to retransmit the RACH request.

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/19330
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-gsm-manuals
Gerrit-Branch: master
Gerrit-Change-Id: I4d98049f6b49871bf5aabe4392da7a608fbc1fe9
Gerrit-Change-Number: 19330
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Hoernchen <ewild at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200727/ddf59727/attachment.htm>


More information about the gerrit-log mailing list