aboutsummaryrefslogtreecommitdiffstats
path: root/doc
AgeCommit message (Collapse)AuthorFilesLines
2022-06-23doc/manuals: document channel allocation parametersVadim Yanitskiy3-0/+82
Change-Id: Ib77eb3d4ad896f1e37b52e549ca3c24f4980240b Related: SYS#5460
2022-05-15Add new Manual "OsmoBSC CBSP Protocol Specification"Harald Welte5-1/+266
This document decribes the level of CBSP support in the codebase. Related: SYS#5945 Change-Id: I2e18e167281fac3abaf380089ff883738ebaa0a0
2022-05-02Check VTY config against features reported by BTSOliver Smith1-0/+42
* Don't copy features for osmo-bts and nanobts initially, wait until BTS reported its features * Checks for BTS features in VTY cmds: pass if features are not known (not yet reported by the BTS), fail if the feature is missing * Once BTS reports its features, check relevant VTY config parts again Related: SYS#5922, OS#5538 Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
2022-04-01doc/examples: add a confmerge file with example hopping parametersVadim Yanitskiy2-1/+217
This file was taken from docker-playground.git, and this is basically what we use when running the ttcn3-bts-test with hopping enabled. Change-Id: I205eb53901e06ee52dc64e050cfe2374cb9c771e
2022-04-01doc/examples: add a multi-trx config config exampleVadim Yanitskiy1-0/+161
So far we had no multi-trx config examples at all. Let's add one. Use unique 'RSL TEI' for each TRX, as this simplifies analyzing the Abis protocol traces. Also use the new 'TCH/F_TCH/H_SDCCH8_PDCH'. Change-Id: I20f86fa74dc4bd71538627ec59c5d2cd3678a089 Fixes: OS#4748
2022-04-01doc/examples: avoid using deprecated configuration commandsVadim Yanitskiy2-4/+4
Change-Id: Id29fae10ec17eb3d0ac8534d8aebd7251a17577d
2022-03-02doc: bsc.adoc: Update timer info from code (gsm_network_T_defs)Pau Espin Pedrol1-11/+11
Change-Id: I1652e6d53f568f606b692b16d4198d5209df2d9c
2021-12-06bts-examples: add example for E1 connected BTSPhilipp Maier1-0/+117
The manual lacks an example on how to set up an E1 connected BTS. Especially the relation between trunk number and E1 line number is not obvious. Change-Id: I02f5d4fe059e5cc9c3ffc2e3636d812532c09239 Related: OS#5308
2021-11-15[overpower] By default, permit only for speech channels using AMRVadim Yanitskiy1-4/+11
Change-Id: I087025f9db59348f2f70d4a291f8d887644d6b17 Related: SYS#5319
2021-11-15[overpower] Allow configuring specific channel mode(s)Vadim Yanitskiy1-0/+2
Change-Id: I34d29d7d0f66c629367f3d6e8a660e199ecbe080 Related: SYS#5319
2021-11-14doc/manuals: fix wrong CI in the inter-BSC handover diagramVadim Yanitskiy1-1/+1
The 'bts0' in BSS 'Beta' has LAC=42/CI=3. There is no LAC=42/CI=6. Change-Id: I0f2e351e802311d4601579c2e755ca13a9056348
2021-11-12doc/manuals: add documentation for Temporary ACCH OverpowerVadim Yanitskiy1-0/+58
Change-Id: Ie995dac6c7083a2b0b4d582f71f55b3736381edb Related: SYS#5319
2021-11-10gsm_data: use ascending order for interference boundariesVadim Yanitskiy1-7/+7
It's more logical to have the boundaries sorted in ascending order: * band 1 represents lowest interference levels, * band 5 represents highest interference levels. Change-Id: Ie9bf4bf0c89418685b8ea5096332d22cfba7c521 Related: SYS#5313
2021-11-10doc/manuals: add documentation for interference reportingVadim Yanitskiy2-0/+74
Change-Id: I3c15b11bbcba0811e3a15fe64365067bf8ad0dae Related: SYS#5313
2021-11-03control.adoc: comment out fixme notePhilipp Maier1-1/+1
The fixme note: "FIXME: add variables defined in src/ctrl/control_if.c?" is not directed at the reader of the manual. It should stay in the source, but it should not be visible in the pdf. Lets comment it out. Change-Id: Id68f53d18f0873af3c07a0ae52cd12bc94bc0b96
2021-11-03bsc_ctrl_commands: change neighbor-list mode/arfcn via control interfacePhilipp Maier1-0/+3
It is possible to change the neighbor-list mode via the VTY from automatic mode to manual neighbor-list configuration. In the manual mode, the user can add ARFCN values manually. This command can be found under the bts node. Lets add pendant of this command on the control interface as well. Change-Id: Id97bc0d31a358db6221c385761773fb48670c921 Related: SYS#5641
2021-11-03heighbor_ident: add/del neighbor cells via ctrl interfacePhilipp Maier1-0/+25
The VTY allows flexible control over the neighbor cell information via the neighbor command, which can be found in the configure terminal under the bts node. Lets add pendant of this command on the control interface as well. Change-Id: I343a40e18fa9b91e6c381912c0426a002841e079 Related: SYS#5641
2021-11-02control.adoc: improve description of command bts.N.send-new-system-informationsPhilipp Maier1-1/+1
Change-Id: I48bdb7fd991dac2d5112440c879d0ded5b726715 Related: SYS#5641
2021-10-07MS Power Control Loop: Use P_CON_INTERVAL=2 by defaultPau Espin Pedrol1-22/+50
Increase the reaction time at the expense of more stable loop with less temporary oscillations. See updated user manual documentation in this commit for a larger description. Related: SYS#5371 Change-Id: I46be244a5e01a74086e3a977ec3ea139742a0074
2021-09-29MS Power Control Loop: Allow Turn off/on C/I independent from value settingPau Espin Pedrol1-7/+11
Improve the current VTY support to allow enabling/disabling C/I logic independent from value setting. This way C/I support can be quickly disabled & enabled. Reminder: changing power parameters still require VTY Command "bts NR resend-power-control-defaults" to be excuted prior to new parameters being applied on the BTS. Related: SYS#4917 Change-Id: Id1224c2d9a52db2ed805c49e048d3086ed0167f5
2021-09-21MS Power Control Loop: Support turn off C/I based logicPau Espin Pedrol1-0/+8
Setting LOWER_CMP_N and UPPER_CMP_N for all channel types can be quite cumbersome and end up in lengthy config files. Let's instead add a placeholder command to apply it to all channel types of a BTS at once. This is useful specially since a user disabling C/I capabilities probably does so because it may require a fair amount of fine-tuning parameters to have it working perfectly. Hence, a user not willing to spend time configuring those parameters correctly (and for which default ones doesn't work properly) will require quick way to get rid of C/I based MS Power Control Loop. By disabling C/I comparison, osmo-bts will rely on RxLev only when applying the MS Power Control Loop, which is fine for non noisy environments. Related: SYS#4917 Change-Id: I0e1a1a9228a15e9ec9c41b7952b03e1d25309706
2021-09-15doc/mgwpool: update documentationPhilipp Maier1-14/+23
The mgw-pool now allows to set a decription for each MGW /MGCP client instance. Update the documentation so that it reflects the current state. Change-Id: I3026e027bba1a9a12ceca64e96df993b5957cb1d Related: SYS#5091
2021-09-13Power Control Loop: Set P_CON_INTERVAL to 1 by defaultPau Espin Pedrol1-9/+35
TS 45.008 section 4.7.1: """ Upon receipt of a command from an SACCH to change its power level on the corresponding uplink channel, the MS shall change to the new level at a rate of one nominal 2 dB power control step every 60 ms (13 TDMA frames), i.e. a range change of 15 steps should take about 900 ms. The change shall commence at the first TDMA frame belonging to the next reporting period (as specified in subclause 8.4). The MS shall change the power one nominal 2 dB step at a time, at a rate of one step every 60 ms following the initial change, irrespective of whether actual transmission takes place or not. """ Since the reported MS_PWR in L1 SACCH Header is, according to specs, the one used for the last block of the previous SACCH period, it becomes clear the first SACCH block after a requested MS Power Level change by the network may contain mismatches between the announced MS_PWR by the MS and the measured Rxlev/RxQual. Hence, let's better use a P_CON_INTERVAL of 1 which retriggers the MS Power Control Loop every second SACCH block. Related: SYS#5371 Change-Id: Iade5b597e0e56b07c6d78995fcec7c641e4e643f
2021-09-13Support Neighbor Address Resolution over PCUIF IPA multiplexPau Espin Pedrol1-6/+28
While NACC was initially developed, it became clear there was need for a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS for later RIM usage. Hence, this resolution was first (until today) implemented using an out of bands RPC system using the CTRL interface, which required specific config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port of the CTRL interface to use). However, this has several shortcomings: * As explained above, specific configuration is required * Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS may switch to a BSC other than first one. If that happened, that'd mean the CTRL interface would still point to the initially configured one, which may not be the same currently serving the PCU. During recent development of ANR related features, a similar need for PCU<->BSC was required, but this time it was decided to extend the IPA multiplex of the Abis OML connection to pass PCUIF messages, transparently forwarded to each side by the BTS. This has the advantage that connection PCU<->BTS is handled by BTS and both sides send messages transparently. Let's switch by default to using this new interface, while still maintaing the old way for a while (announcing them as deprecated) to avoid breaking existing deployments until they are upgraded to new versions of osmo-pcu and osmo-bsc. Change-Id: I9073a121564503f483c84263ac72476041e47c03 Related: SYS#4971
2021-09-06doc: power_control.adoc: Add small time graph showcasing P_CON_INTERVALPau Espin Pedrol1-1/+16
Original graph made by Vadim Yanitskiy. Change-Id: I9b76088b2d46973b477deb555214d64fcc746754 Related: SYS#5371
2021-09-06MS Power Control Loop: Support set up of C/I parameters for osmo-btsPau Espin Pedrol1-4/+54
This commit extends existing VTY and RSL infrastructure to configure and manage MS Power Parameters used in MS Power Control loop, by adding support to set up Carrier-to-Interference (CI) parameters. Using C/I instead of existing RxQual is preferred due to extended granularity of C/I (bigger range than RxQual's 0-7). Furthermore, existing literature (such as "GSM/EDGE: Evolution and Performance" Table 10.3) provides detailed information about expected target values, even different values for different channel types. Hence, it was decided to support setting different MS Power Parameters for different channel types. These MS Power Parameters are Osmocom specific, ie. supported only by newish versions of osmo-bts. Older versions of osmo-bts should ignore the new IEs added just fine. The new IEs containing the MS POwer Parameters are not send for non osmo-bts BTSs, hence this commit is secure with regards to running osmo-bsc against an ip.access BTS such as nanoBTS. Related: SYS#4917 Depends: libosmocore.git Change-Id Iffef0611430ad6c90606149c398d80158633bbca Change-Id: I7e76ec47b323d469f777624b74b08752d1f5584f
2021-09-06doc: power_control.adoc: Improve VTY snippet foot notesPau Espin Pedrol1-8/+10
Change-Id: Ie5f129c418c187d4f331d6e92884f4f507fb018f
2021-09-03osmo_bsc_main: integrate MGW pooling into osmo-bscPhilipp Maier3-0/+248
Since the libosmo-mgcp-client now supports MGW pooling, lets use this feature in osmo-bsc. Large RAN installations may benefit from distributing the RTP voice stream load on multiple media gateways. Depends: osmo-mgw Icaaba0e470e916eefddfee750b83f5f65291a6b0 Change-Id: I8f33ab2cea04b545c403a6fe479aa963a0fc0d0d Related: SYS#5091
2021-08-26doc: manual: Fix typo in textPau Espin Pedrol1-1/+1
Change-Id: I1dfe298ad9a416ea15976527463a55873db56f22
2021-08-19doc: Improve ACC ramp documentationPau Espin Pedrol1-10/+24
Commit below added support for ACC ramping based on channel load, but documentation was not updated with it. Fixes: 1e5e7004dc7987b23f5791366efdf374675e346b Change-Id: I8701386b35ccdebfc843fd00535091648e52f739
2021-08-03osmo_bsc_main: remove unused commandline option -lPhilipp Maier1-2/+0
The option -l ("The local address of the MGCP") is still present in the commandline help and the manual, but it is used nowhere and osmo-bsc exists when it is used. Lets remove it. Change-Id: Ia295f4414e0d6e78b388c0c72f1a5b8df8bc3d7e
2021-08-03running.adoc: explain mgw reset-endpoint VTY settingPhilipp Maier1-0/+5
When OsmoBSC is restarted, it does not automatically clear the calls on the MGW. However, this is an important part of the configuration to avoid trouble with resource leakage on the MGW, so lets make (especially novice) users aware of that option. Change-Id: I19c499c6ac83d7f9437b18b372977f6f2d518adf Depends: osmo-mgw I47e7ff858d5067b46d52329be5f362ff61c0dff8 Related: SYS#5535
2021-07-19handover_ctrl: add control interface for handover settingsPhilipp Maier1-0/+28
The VTY handover_vtc.c offers a large number of handover specific settings. Those settings are (with one exception) auto generated using macros. Lets add an equivalent for the control interface that uses the same auto generation mechanisms. Change-Id: I12f143906818fd6b16e8783157cbb1eb51e49ffc Depends: libosmocore I53fc207677f52b1dc748b01d58424839cdba807c Related: SYS#5369
2021-07-09doc: bts.adoc: Update dyn ts section to include SDCCH8 supportPau Espin Pedrol1-5/+6
Related: SYS#5309 Change-Id: I40f4b19e7df83351c9c9e65d71880ac6aaa4ee88
2021-07-06Rename osmo dyn ts enums to contain SDCCH8Pau Espin Pedrol1-9/+9
They will gain support to be activated as SDCCH/8 soon too. Related: OS#5309 Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68 Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
2021-07-05power_control: constrain BS power reduction on BCCH carrierVadim Yanitskiy1-0/+24
BS Power Control is not allowed on the BCCH/CCCH carrier, unless the BTS is operating in the BCCH carrier power reduction mode. Allow constrained BS power reduction (up to 6 dB) on active logical channels iff BCCH carrier power reduction mode is enabled. Take into account that the maximum power difference between a timeslot used for BCCH/CCCH and the timeslot preceding it shall not exceed 3 dB. Change-Id: I2cc6a86731984f586ef35b43a8d3de631f7d8a2f Related: SYS#4919, SYS#4918
2021-07-05power_control: implement BCCH carrier power reduction operationVadim Yanitskiy1-0/+81
The BCCH carrier (sometimes called C0) of a BTS shall maintain discontinuous Downlink transmission at full power in order to stay 'visible' to the mobile stations. Because of that, early versions of 3GPP TS 45.008 prohibited BS power reduction on C0. However, starting from version 13.0.0 (2015-11) there is a feature called 'BCCH carrier power reduction operation'. This is a special mode of operation, where the variation of RF level for some timeslots is relaxed for the purpose of energy saving. In BCCH carrier power reduction operation, for timeslots on the C0 carrier, except timeslots carrying BCCH/CCCH, the output power may be lower than the output power used for timeslots carrying BCCH/CCCH. In this case the maximum allowed difference in output power actually transmitted by the BTS is 6 dB. Introduce a VTY command to turn on and off the BCCH carrier power reduction operation. Also introduce a CTRL command. On the A-bis/RSL, abuse the BS POWER CONTROL message by setting the Channel Number IE to 0x80 (RSL_CHAN_BCCH). Currently, only osmo-bts-trx is supported. A value greater than zero makes it reduce the power on *inactive* timeslots of the BCCH carrier. Sending zero disables the BCCH power reduction mode completely. For more details, see 3GPP TS 45.008, section 7.1, and 3GPP TR 45.926. Change-Id: I047fce33d4d3e4c569dd006ba17858467a2f4783 Related: SYS#4919
2021-06-24control.adoc: add doc for apply-config-filePhilipp Maier1-0/+1
apply-config-file is not documented in the manual. Change-Id: I469e3925c1079e45eea246e599bcd50ba3fc9dd3 Related: SYS#5369
2021-06-24bsc_ctrl_commands: add command to write vty configPhilipp Maier1-0/+1
we recently added control commands to apply vty config files during runtime using the control interface. However, there is no command that allows us to store the config file modifications. Change-Id: If17095bb86f82dd8feb86eb72c4133ea3aa1c3b3 Related: SYS#5369
2021-05-27handover dot charts: fix wrong transitions regarding MGWNeels Hofmeyr2-6/+5
Related: SYS#5315 OS#4940 OS#3277 Change-Id: I2ed9b3ca7fe145a930ca509e6b3943f5abf3aa62
2021-05-21lchan and assignment FSMs: make Channel Mode Modify more saneNeels Hofmeyr1-2/+8
The Channel Mode Modify procedure is currently implemented for changing a TCH lchan from signalling to voice mode. For that, however, it is re-using (abusing) the channel activation structs and state transitions, and thus always implies activating a voice stream when the mode modification is done. I will add a Channel Mode Modify to enable VAMOS mode soon, so I require separate structs and state transitions which also work on an lchan that already has a voice stream established: a struct lchan_modify_info and LCHAN_EV_REQUEST_MODE_MODIFY, and dedicated assignment FSM state ASSIGNMENT_ST_WAIT_LCHAN_MODIFIED. For the part where a Channel Mode Modify enables a voice stream after switching from signalling to speech mode, still use the channel activation code path, but only once the mode modification is done. General improvements: - To ask for a mode modification, emit an FSM event that ensures a mode modify only happens when the lchan state allows it. - The new lchan_modify_info struct reflects only those parts that have an effect during a mode modification (before the lchan_activate_info was fully populated, many values not having an effect). - More accurate logging, indicating "Mode Modify" instead of "Channel Activation" A TTCN3 test for the Channel Mode Modify procedure is added in Idf4efaed986de0bbd2b663313e837352cc139f0f, and the test passes both before and after this patch is applied. Related: SYS#4895 Change-Id: I4986844f839b1c9672c61d916eb3d33d0042d747
2021-05-21cosmetic: rename FOR_* to ACTIVATE_FOR_*Neels Hofmeyr5-16/+16
Soon, there will also be enums with ASSIGNMENT_FOR_* and MODIFY_FOR_* naming. Add the ACTIVATE_ prefix to the existing enum to clarify. Change-Id: I12190d4d154a1da6a9ebc9a755ccc2fe382ff188
2021-05-21bts.adoc: fix typo BGSGP -> BSSGPPhilipp Maier1-1/+1
Change-Id: I4387b516c5c116cd7179611dc34a90b0a744cb6c
2021-05-01manual: Include QoS chapter and add osmo-bsc specific exampleHarald Welte2-0/+48
Change-Id: I3b1d44fc545725172142b903190a3ff5094805dd Requires: osmo-gsm-manuals.git Id344c29eda2a9b3e36376302b425e9db1f6c0f28 Requires: libosmo-abis.git I8991dd6eb406a5b9a70498974fc1ad339452f871
2021-04-27manual: Location Services: clarify BSC side addressNeels Hofmeyr1-2/+19
A clarification that I promised a while back but forgot to submit. Related: SYS#4876 Change-Id: I9b06ac7a2f2cb34cabfcec10af761322b8e962fb
2021-04-12vty: deprecate BTS type 'sysmobts' in favor of 'osmo-bts'Vadim Yanitskiy4-4/+4
Change-Id: I60d5ff887a7c830180088904c2458f7e73ce3893
2021-02-22CBSP: document rate counters and their mapping to basic/extended CBCHHarald Welte1-0/+26
Change-Id: Id298d547a90bb5d8e40f2cd300b7e1303bb43fdc
2021-02-11bts.adoc: describe ACCH repetition settingsPhilipp Maier1-0/+69
The manual currently does not mention ACCH repetition yet. Lets add some info on how to set up ACCH repetition correctly. Change-Id: I1e27ac955882497bbeefac0c830708dd18ad46b3 Related: SYS#5114
2021-02-07power_control: make P_CON_INTERVAL parameter configurableVadim Yanitskiy1-1/+22
Change-Id: I6e0fae81cc60f708e49d5eb8dfc0bbcad926b18f Related: SYS#4918
2021-02-07power_control: enable Uplink DPC by default if format is knownVadim Yanitskiy1-2/+4
So far osmo-bsc would enable Uplink DPC (Dynamic Power Control) only for osmo-bts, and the 'static' mode for all other BTS models. This decision dates back to the time when ip.access specific encoding for dynamic power control parameters was not implemented, and the MS Power Parameters IE was sent empty in the RSL messages. Let's make a step forward by enabling Uplink DPC by default for all BTS models which declare the API for vendor-specific encoding of the power control parameters. Currently this includes osmo-bts and nanoBTS, both supporting ip.access specific format. Change-Id: If86d27d4332af3d82f862737340d061e42e34eba Related: SYS#4918
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-24 09:47:56 +0000