aboutsummaryrefslogtreecommitdiffstats
path: root/doc
AgeCommit message (Collapse)AuthorFilesLines
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
2021-01-29cosmetic: doc: wrap line too longPau Espin Pedrol1-1/+2
Change-Id: I2da6f58d84521289f86840b1da191a9faf76a1a8
2021-01-14hodec2: to balance congestion, use overload percentNeels Hofmeyr1-3/+5
For balancing load across congested cells and across congested TCH/* kinds, instead of comparing the number of lchans above the configured congestion threshold, compare the percent of lchans of overload. In short, using a percentage prevents cells with less min-free-slots to fill up 100% while neighbor cells still may have several free lchans available. An obvious example of why this is desirable is illustrated by test_balance_congestion_by_percentage.ho_vty: Cell A has min-free-slots 2, and has all slots occupied. Cell B has min-free-slots 4, and has 2 slots remaining free. If we count congested lchans as in current master: cell A has a congestion count of 2: two more lchans in use than "allowed". If we move one lchan over to cell B, it ends up with a congestion count of 3, which is worse than 2. So when counting lchans, we decide that cell A should remain full. Instead, when comparing percentage of remaining lchans, we would see that cell A is loaded 100% above congestion (2 of 2 remaining lchans in use), but when moving one lchan to cell B, that would only be 75% loaded above its treshold (3 of 4 remaining lchans in use). So a percentage comparison would cause a handover to cell B. Related: SYS#5259 Change-Id: I55234c6c99eb02ceee52be0d7388bea14304930f
2021-01-13Introduce Neighbor Resolution ServicePau Espin Pedrol1-1/+100
This new CTRL interface allows users of this BSC (such as attached PCU) to gather neighbor information. This interface is needed for PCU to translate ARFCN+BSIC keys provided by MS in the Um side into CGI + RAC keys used to identify target cells in RIM procedures against SGSNs on the Gb interface. This patch extends the already existing neighbor information storage in the VTY by allowing storage of CGI + RAC (RAC couldn't be stored beforehand). Related: SYS#4909 Depends: libosmocore.git Change-Id If48f412c32e8e5a3e604a78d12b74787a4786374 Change-Id: Ib07c9d23026332a207d4b7a0f7b4e76c0094e379
2021-01-13doc: handover: Fix malformed tablePau Espin Pedrol1-1/+6
Change-Id: I197598e8dba719ef7e0f5a1727aa3cc82b5b5c9a
2021-01-12power_control: add increase / reduce step size recommendationsVadim Yanitskiy1-0/+5
Change-Id: I82e762c0c2b5e0dd739850ee494ab0a798e353de Related: SYS#4918
2021-01-11power_control: cosmetic changes and fixes to the documentationVadim Yanitskiy1-11/+11
Change-Id: I744d09fb22d8b07ed433a34a958ef384fd3d62da Related: SYS#4918
2021-01-11manuals: fix a typo: s/DTS/DTX/Vadim Yanitskiy1-1/+1
Change-Id: I5bef0eca101859e4f757e17ce3e4e3cd56b0b5eb
2021-01-11manuals: fix a duplicate line in the description of DTXuVadim Yanitskiy1-2/+0
Change-Id: Iedb7c2b7cc1dc3833271eb94f7eafc79cea3fd06
2021-01-11power_control: add documentation on available configuration paramsVadim Yanitskiy2-0/+303
Change-Id: Ib65d33f0f1dd24d39e3be581e4e072a310bc906a Related: SYS#4918
2020-12-21osmobsc-usermanual: Add Chapter with AoIP message flow examplesHarald Welte4-0/+215
Change-Id: I001d5f85c95098269b5f129b0c53c3544b96ffb0
2020-11-20update aoip-mgw-options document with reality of 2020Harald Welte4-15/+33
This was started in 2017 before the NITB split. Let's align it with reality, mostly in terms of naming and making explicit what was implemented. Change-Id: Ib4e66b565a1edfc5ea8c1446f911011bfd4b1642
2020-10-28manual: describe LCS and Lb interfaceNeels Hofmeyr4-0/+136
Change-Id: I7ba432706759433987fabbc674bfc8cd55f2ce62
2020-10-10add doc/location_services_ta.mscNeels Hofmeyr2-0/+50
Change-Id: I9372c588bf8ee68a3995102b295198f35e32eec8
2020-09-18clean up timer definitions: introduce groups, move some T to XNeels Hofmeyr1-1/+1
Backwards compatibly, introduce timer groups in OsmoBSC, and move some non-specified T timers to new X timers: T993111 -> X3111 T993210 -> X3210 T999 -> X4 Why X4? because there already is an X3 used elsewhere in Osmocom, and I find it less confusing if X-numbers don't repeat across programs. See https://osmocom.org/projects/cellular-infrastructure/wiki/List_of_Timer_numbers Drop unused timers from g_mgw_tdefs. Only X2427 has an actual effect. (libosmo-mgcp-client recently moved T2427001 to X2427.) Put libosmo-mgcp-client related timers to the 'mgw' group, like in osmo-msc. This makes the MGCP timeout configurable for the first time. Keep previous timer commands as DEFUN_HIDDEN, and also translate the moved T timers to X timers on-the-fly. All previous VTY commands still work, and new 'timer [(net|mgw)] ...' commands are added. timer.vty shows this. Remove the "_OPTIONAL" from the legacy "timer" and "show timer" commands, so that they don't ambiguously overload the new "timer [(net|mgw)] ..." commands. Related: OS#4539 Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw) Change-Id: I4beec47502afa193dee343869c4be55dc6a4b536
2020-09-09lchan_rtp_fsm: Deferr IPACC MDCX after BTS side MGCP MDCXPau Espin Pedrol2-7/+10
This is needed to be able to force MGW to provide an IPv4 address during MDCX, since IPACC protocol on the BTS side only supports IPv4, but one may need IPv6 side at the same time on the core side. By moving the IPACC MDCX request to a later step, the BSC gains knowledge of the local address on each side (BTS, MGW), and if they don't match (ie. BTS uses IPv4 and MGW uses IPv6), it can then get MGW to offer an IPv4 address during MGCP MDCX containing the BTS IPv4 address. At that point, the MGW can see the mismatch and provide an IPv4 address in the MGCP MDCX ACK, which can then finally be communicated to the BTS during IPACC MDCX phase. Previous order: BSC -> MGW: CRCX BSC <- MGW: CRCX ACK (get MGW local IP addr) BSC -> BTS: IPACC CRCX BSC <- BTS: IPACC CRCX ACK (get BTS local IP addr) BSC -> BTS: IPACC MDCX (set MGW IP addr) BSC <- BTS: IPACC MDCX ACK BSC -> MGW: MDCX (set BTS IP addr) BSC <- MGW: MDCX ACK New order: BSC -> MGW: CRCX BSC <- MGW: CRCX ACK (get MGCP local IPv6 addr) BSC -> BTS: IPACC CRCX BSC <- BTS: IPACC CRCX ACK (get BTS local IPv4 addr) BSC -> MGW: MDCX (set BTS IPv4 addr) BSC <- MGW: MDCX ACK (here MGW changes its local addr to IPv4) BSC -> BTS: IPACC MDCX (set MGW IPv4 addr) BSC <- BTS: IPACC MDCX ACK Change-Id: I4de5ea5c94c1482c9cb0b6386997a942edc60e32
2020-09-03lchan_fsm: make rsl mode-modify working againPhilipp Maier4-0/+35
osmo-nitb supports the modification of an lchan if the lchan is compatible but in the wrong mode. This feature was dropped in the transition to AoIP/bsc-split. However, osmo-bsc still has code to generate and parse the messeages, but the FSMs do not support a mode modify yetm Lets add handling for mode-modify to the lchan_fsm and assignment_fsm in order to support mode modify again Change-Id: I2c5a283b1ee33745cc1fcfcc09a0f9382224e2eb Related: OS#4549
2020-09-03CBSP: adjust manual to reflect new 'cbc' VTY configNeels Hofmeyr1-20/+42
Related: OS#4702 Change-Id: I101144dc4ebf151fa23d05743398aeea4a26834b
2020-08-20Support setting rt-prio and cpu-affinity mask through VTYPau Espin Pedrol1-0/+2
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c Related: SYS#4986 Change-Id: Ie68883666657fc8faa76e2422335c0ceb98c5a88
2020-07-30Add example config files for Ericsson DUG20 based BTSHarald Welte3-0/+797
The files have been used successfully in the past weeks to bring up a variety of different combinations of Ericsson DUG20 + RUS. Change-Id: I046f786d68f7cd3fd21693142bd1315bf40696f5
2020-07-29Introduce support for ACC subset rotationPau Espin Pedrol1-11/+66
See updated documentation section in manuals/chapters/bts.adoc regarding an explanation on how the system works. Related: SYS#4911 Change-Id: I952c9eeae02809c7184078c655574ec817902e06
2020-07-20{bts,bsc}.adoc: Drop deprecated OsmoNITB referencesPau Espin Pedrol2-14/+8
dyn_ts_allow_tch_f is also deprecated and should not be used, so drop that too. Change-Id: Icc91dd41a237531cb512fa36d8b18d4d8d5ca8ed
2020-07-20doc: Copy {bsc,bts}.adoc from osmo-gsm-manualsPau Espin Pedrol3-2/+627
Those adoc files are only used by osmo-bsc.git and openbsc.git (osmo-nitb), and the later is deprecated and no longer maintained, which means new features are only added to BSC. Hence it makes no sense to keep the doc shared between both. Change-Id: I20aa60d2f4111d66e922f3e2a73a20352ec1f7e4
2020-07-17remove examples/osmo-bsc/ericsson/osmo-bsc.cfgHarald Welte1-101/+0
This was an accidential copy of osmo-bsc.rbs2308.cfg Change-Id: I89c6c0fc2b9ec0054e71827118ddaa85fe3e9318
2020-07-16Add example configuration files for E1 BTSHarald Welte4-0/+343
This adds osmo-bsc config files for Ericsson RBS2308, Siemens BS-11 and Nokia InSite which were working in July 2020 to get the BTS initialized, recognized by MS and up to signalling. Voice/TRAU support is still missing in OsmoBSC, but should be added relatively soon. Change-Id: I1fe15cc3654025e52fc1110ac3052fb1f7a009a0 Depends: osmo-python-tests I896b99032d94ba0cdd340a8eed7c7b625661ad69 Closes: OS4651
2020-07-15doc/examples: remove deprecated 'dyn_ts_allow_tch_f'Vadim Yanitskiy2-2/+0
This option has been deprecated back in 2018 [1], but for some reason we still have it in the configuration examples, so it prevents osmo-bsc to allocate TCH/F on dynamic timeslots. [1] Ib2335d02ea545aff837aadd49f15b2fdb418c46e Change-Id: Icc82f6178d18dccc7207485b25dc3bdad91a0052 Related: SYS#5014
2020-06-17mscpool: add user manual chapterNeels Hofmeyr2-0/+215
Change-Id: Ia60afc8a91189c9de0d8e8065781ed463bf18d7e
2020-06-16manuals: generate vty reference xml at build timeNeels Hofmeyr2-5095/+6
Move 'doc' subdir further down to "make sure" the osmo-bsc binary is built before the docs. Remove bsc_vty_reference.xml from the source tree. In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added to osmo-gsm-manuals, and add a build target to generate the XML using the new osmo-bsc --vty-ref-xml cmdline switch. Depends: I613d692328050a036d05b49a436ab495fc2087ba (osmo-gsm-manuals) Change-Id: I5dc872149154e1a949bb6a2b9bbc1461e0fc51f6
2020-05-31doc/manuals: regenerate the VTY reference fileVadim Yanitskiy1-130/+0
Change-Id: I4f7bf671b7948d8c3771d33d40ab5e8cf209e2b2
2020-05-29doc/examples: remove deprecated ussd text configNeels Hofmeyr1-4/+0
Change-Id: I7c0b615bbb0a5c50341968a748612448ad9d18e4
2020-05-29drop all BSC originated USSD notification featuresNeels Hofmeyr1-7/+0
The BSC is the wrong network component to originate USSD messaging, as can be seen in the hacks in the USSD code: for example, the BSC would send a CM Service Accept message as if an MSC had accepted the connection, dispatch a USSD and directly send some RR release message (without proper tear down messaging like the lchan_fsm does these days). This made sense in the osmo-nitb world, but by now we are aiming for solid 3GPP compliance. The BSC shall not originate USSD messages. Deprecate all VTY and CTRL commands related to USSD: VTY [no] bsc-welcome-text [no] bsc-msc-lost-text [no] bsc-grace-text [no] missing-msc-text (the commands with 'no' are ignored, without 'no' lead to an error) CTRL ussd-notify-v1 Drop (already unused) ussd.h. Drop gsm_04_80.h, gsm_04_80_utils.c, and all calling code. Drop "RF grace" notification, where osmo-bsc was able to notify active subscribers that the RF was being turned off. Change-Id: Iaef6f2e01b4dbf2bff0a0bb50d6851f50ae79f6a
2020-05-19deprecate 'msc' / 'ip.access rtp-base <port>'Neels Hofmeyr1-7/+0
The bsc_msc_data->rtp_base has been unused ever since we introduced the exernal MGW in osmo-bsc [1]. The vty command also still exists. Deprecate the vty command, remove the member. [1] "mgcp: use osmo-mgw to switch RTP streams" commit 39c609b7c924524172ad311bdf89f92b7ccf175a Change-Id Ia2882b7ca31a3219c676986e85045fa08a425d7a Change-Id: Id14fa3066ca5d472a817593074a6222f159168a8
2020-05-18manuals: update bsc_vty_reference.xmlNeels Hofmeyr1-1/+40
I notice that some merges seem to have missed updating the bsc_vty_reference.xml file. Re-generating it from current master yields these changes. Change-Id: I75269cbed8dd62be23293fd2c1470af6f61e6ad2
2020-05-13manual: fix config example typo 'msc-addr'Neels Hofmeyr1-1/+1
Change-Id: Ifb84d7ceddc772e3e1ae59c8d5859b6be6f1b4eb
2020-04-14vty: clarify EGPRS Packet Channel Request message supportVadim Yanitskiy1-4/+9
According to 3GPP TS 44.060, section 12.24, GPRS Cell Options IE contains two parameters related to 11 bit Access Burst support: - ACCESS_BURST_TYPE - whether the 8 or 11 bit format shall be used in the PACKET CHANNEL REQUEST message, the PTCCH/U block, PACKET CONTROL ACKNOWLEDGMENT and the PS HANDOVER ACCESS messages on the PRACH (if present). - EGPRS_PACKET_CHANNEL_REQUEST - whether EGPRS capable MSs shall use EGPRS PACKET CHANNEL REQUEST message for Uplink TBF establishment on the RACH or on the PRACH (if present). The VTY option 'gprs 11bit_rach_support_for_egprs' actually controls the second parameter - EGPRS_PACKET_CHANNEL_REQUEST, though it may be hard to understand this from its name and description. This patch is actually a group of tightly related changes: - deprecate 'gprs 11bit_rach_support_for_egprs (0|1)': - update its description to avoid any possible confusion, - print a warning if it's used in non-EGPRS mode, - print a warning if it's still used; - introduce '[no] gprs egprs-packet-channel-request': - ensure that it can only set / printed in the EGPRS mode; - take a chance to clean-up / rename the related struct members: - 'supports_egprs_11bit_rach' -> bool 'egprs_pkt_chan_request', - remove 'supports_egprs_11bit_rach' from 'gprs_cell_options' because we already have 'ext_info.use_egprs_p_ch_req' there. Change-Id: Ied5bd10a806aeeac65ef32339d4ab0e3700e5da9
2020-04-05doc/manuals: remove deprecated DNAT from the VTY referenceVadim Yanitskiy1-10/+5
Change-Id: Ib21c30041508a9ec9afda56bda95bddf4d665bc8
2020-03-30manual: add SCCPlite sectionNeels Hofmeyr1-1/+32
Change-Id: I8eddc47353d6afd756865321a9e97f6cee4ce2d7
2020-03-30manual: add SCCP/M3UA section from common chaptersNeels Hofmeyr2-1/+5
Link to the osmo-gsm-manuals/common/cs7-config.adoc chapter to fully explain the 'cs7' client configuration. Related: OS#2767 Depends: Ia2508d4c7b0fef9cdc57e7e122799a480e340bf7 (osmo-gsm-manuals) Change-Id: I5b4973901f02046322b852fd9862517982d21bd9