aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-09-15abis.c: Convert early return to assert()Pau Espin Pedrol1-2/+1
This should simply not happen. If other event is received, something is terribly wrong, so we should exit immediately instead of silently failing. Change-Id: I5f4953be735f526bb8b926979233b3c26ba67ce9
2021-09-15abis.c: Rearrange code to follow logic state orderPau Espin Pedrol1-55/+55
CONNECTING state comes first in logical order of states (as properly seen in enum of states), however, the FSM struct definition and state action functions are swapped. Let's put them in order. Change-Id: I0cae561926b460dc5882390db969b7c925903e5d
2021-09-15cosmetic: fix typo in commentPau Espin Pedrol1-1/+1
Change-Id: I0e4fdad66c0bad849a7b960cf78f9f45b56fcb95
2021-09-15abis.h: Drop unused statePau Espin Pedrol1-10/+0
Change-Id: I11173af3a543f6679ca9d43064bf071c214b1898
2021-09-15abis: Clear code and drop code not executedPau Espin Pedrol1-8/+2
abis_init() sets "g_bts = bts;", hence bts object is the same as g_bts (since we only have 1 BTS object in osmo-bts). As a result, dropping checking first bts->... and later g_bts->... makes no sense: the later condition will always be false. Change-Id: I5018199221fb3c3329a59d0b91e827f077cef85d
2021-09-15MS Power Control Loop: Fix sub vs full being passed to algoPau Espin Pedrol1-4/+4
Fixes: c80abd109b9fc218de047a25ecf4d0de49ca2cdc Change-Id: Ib66ac938e3e71409848927a2972f1f77b9bacde2
2021-09-14Support configuring TA loop SACCH block ratePau Espin Pedrol6-2/+36
Similar to what is already provided for power control loops. However, there's no existing way to communicate TA control parameters from the BSC to the BTS, so implement them locally in BTS vty. Related: SYS#5371 Change-Id: I9fa71f836bb9a79b0ef2567bfcfdf38ff217840b
2021-09-14Power Control Loop: Set P_CON_INTERVAL to 1 by defaultPau Espin Pedrol3-3/+14
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. Change-Id: If6cb8945645a2031f2b2ee65d9b9f51e75cd9af1 Related: SYS#5371
2021-09-14TA Control Loop: Change toa256 switch threshold to 75% of a symbolPau Espin Pedrol1-4/+5
As per 3GPP TS 45.010 sec 5.6.3 Delay assessment error: """ the delay shall be assessed in such a way that the assessment error (due to noise and interference) is less than 1/2 normal symbol periods for stationary MS. For MS moving at a speed up to 500 km/h the additional error shall be less than 1/4 normal symbol period. """ Hence, required TA loop calculation should take into account an error of up to 1/2 + 1/4 = 75% of a symbol. By changing the threshold variable to that percentage we make sure we take into account bigger deviations and update TA accordingly. Related: SYS#5371 Change-Id: I4c5825df4291d3851a113027abf7566de343a190
2021-09-13MS Power Control Loop: Feed UL C/I from correct measurement periodPau Espin Pedrol4-27/+51
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is the value used over previous measurement period. Hence, we need to feed the algo with the measurements taken over that same period. Related: SYS#4917 Change-Id: I13c0014fdd73f823ae5b1256c35bfa7d97cfa334
2021-09-13MS Power Control Loop: Feed UL RSSI from correct measurement periodPau Espin Pedrol1-1/+7
As per 3GPP TS 45.008 sec 4.2, the ms_pwr received in L1 SACCH Header is the value used over previous measurement period. Hence, we need to feed the algo with the measurements taken over that same period. Related: SYS#4917 Change-Id: I00852cb37a3613606e37476c169f5a32d6b5d75e
2021-09-13lchan: Move TA CTRL param to its own substructPau Espin Pedrol9-263/+269
Field is renamed to look similar to similar fields in power control loop. This is a preparation commit, next one will add functionality to skip SACCH blocksi (P_CON_INTERVAL). Related: SYS#5371 Change-Id: I169ce58ab827e38b64f4b15f935097a9118fa118
2021-09-13ta_control: Allow switching TA quickerPau Espin Pedrol2-232/+232
From TS 45.010 5.6.1 (delay tracking for circuit switched channels): """ Restricting the change in timing advance to 1 symbol period at a time gives the simplest implementation of the BTS. However the BTS may use a larger change than this but great care must then be used in the BTS design. """ In general 1 TA at a time (every 480ms of SACCH block) should be enough, since section 5.6.3 states: """ The control loop for the timing advance shall be implemented in such a way that it will cope with MSs moving at a speed up to 500 km/h """ Which is ~140 m/s, and 1 TA step around 500m, so most of the time we should be save and no steps of more than 1 TA should be required. However, unlikely changes from reflected to direct signal or vice versa could produce higher increments, so let's increase the maximum step size allowed to 2 in order to give more room. Change-Id: I9e48faabf3090588233e274b2b39065cf85fbec7
2021-09-13TA loop: Take into account UL SACCH 'Actual Timing advance' fieldPau Espin Pedrol5-28/+74
First step improving and reworking TA loop: Move trigger of the loop to similar place done by BS/MS Power Control Loop, that is, upon receivial of UL SACCH block, which contains information about the TA used to transmit the block encode in L1SACCH Header. Hence, from computed received TOA and TA used when transmitting from the MS, we can infer the desired TA to be used by the MS, which will send back to it later during DL SACCH block. The values taken are actually the ones calculated for the previous SACCH block and stored in lchan->meas.ms_toa256. That's because L1SACCH contains the TA used for the previous reporting period, similarly to what's specified for MS Power Control loop (TS 45.008 sec 4.2): """ The MS shall confirm the power control level that it is currently employing in the SACCH L1 header on each uplink channel. The indicated value shall be the power control level actually used by the mobile for the last burst of the previous SACCH period. """ (The reader may observe that currently this is not properly done for MS Power Control loop when calling lchan_ms_pwr_ctrl(): this is a bug.) This new method also permits changing TA quicker, since we have more confidence that the TA we request is aligned with the one used to transmit, and we don't simply increment/decrement based on the value we request to transmit. Related: SYS#5371 Change-Id: I2d0f128c8dcac93ee382283a1c91fca76623b8fc
2021-09-11early IA: change default X15 timer to 0 msNeels Hofmeyr2-6/+6
Tests have shown that even a delay of 0, i.e. a simple defer until the next select() loop, makes the difference from failing to working early IA. So set the default to 0, achieving such defer. Related: SYS#5559 Change-Id: I95365649edd51114bcf6028f0dc3bbe4186f96d2
2021-09-11early IMM ASS: add configurable delay for RR IMM ASSNeels Hofmeyr5-14/+64
During live testing, it has become apparent that some IMM ASS still fail when sending the RR IMM ASS directly upon the target channel becoming active. Add a bit of delay after activation, to give some time for the channel to light up for the MS. Default is 50ms. Related: OS#5559 Change-Id: Ia1e63b98944dc840cde212fc732e20277cdc5585
2021-09-06l1sap: Take L1SACCH MS_PWR from bitfield instead of manual parsingPau Espin Pedrol1-1/+1
Change-Id: Ib2918d5d6b8463c659896f6e535a0c6eaca4bd87
2021-09-06comsetic: measurement.c: fix typo in commentPau Espin Pedrol1-1/+1
Change-Id: I3ed3486bbc3d55088e3ebe27e4a76f932d6f7a59
2021-09-06Power Control Loop: Move skip loop logic to function helperPau Espin Pedrol1-18/+21
Let's move duplicate logic to function helper. Related: SYS#5371 Change-Id: Ic26c17564ec61cdadaab0184c4246b9bf863c69a
2021-09-03MS/BS Power Control Loop: Fix downscaling averaging bugPau Espin Pedrol4-9/+11
The bug showed up in previous commit and is fixed in this commit. It can be seen how rounding error is carried over time in the average measurement, and affects final values. Change-Id: I680d1c94bd4bae179b14b26662a819fa1462a5c8
2021-09-03MS/BS Power Control Loop: Do RxLEV meas avg & delta calculations directly on ↵Pau Espin Pedrol4-57/+49
RxLevels Before this comits, averaging and delta calculation was done in RSSI, but stored the averaging cached state in variables named "rxlev", which was really confusing. Let's keeping averaging and delta calculations based on RxLevels. Some of the tests change results due to test passing RSSI -45, which is an invalid Rxlev (only up to -47 is supported). Others fail due to an unrelated bug showing up now. Basically the averaging algo is doing rounding the wrong way when downscaling the values. It will be fixed in a follow-up commit. Change-Id: I4cff8394f22b5d47789163051364ff594b2bcd74
2021-09-03BS Power Control Loop: Increase attenuation if RxQual is better than upper ↵Pau Espin Pedrol1-0/+3
threshold If RxQual is considered good enough, attenuation can be increased in order to lower overall cross-channel noise among different MS. Change-Id: Ie97898980acd152de15f6b4b619d492048855ef4
2021-09-03BS Power Control Loop: Support EWMA average algo for RxQual measPau Espin Pedrol4-102/+105
params->rxqual_meas.upper_thresh is left unchecked in lchan_bs_pwr_ctrl() on this commit on purpose, to keep this commit with old behavior wrt to algo logic. Change-Id: If7e3987df89d680cfa443195ab2f225681d0e6cf
2021-09-03BS Power Control Loop: refactor lchan_bs_pwr_ctrl() to look similar to ↵Pau Espin Pedrol2-151/+140
lchan_ms_pwr_ctrl() This commit reworks the code in function lchan_bs_pwr_ctrl() and logging to look similar to that of lchan_ms_pwr_ctrl(), so that reader can easily spot similarities between both and add simillar features more easily. This commit is also a preparation to add EWMA avg support for RxQual measurements. Logging is also reworked now to look similar to that of MS Power Control Loop, because having several parameters driving the algo (RxLev and RxQual), it becomes more suitable to log all of them together instead of intermediate info only aplicable to one param such as "delta". Change-Id: Ida76b55f0da722135eb61ed06ea2b3a1862df600
2021-09-03MS Power Control Loop: Improve loggingPau Espin Pedrol2-70/+70
Change-Id: I8babd42566c41935079fd414d930ebf2d737892e
2021-09-03MS Power Control Loop: Support EWMA algorithm for C/I measurementsPau Espin Pedrol2-19/+29
Change-Id: I52eb0558fd7a215a6ee0b2aced189ae4a37d8a22 Related: SYS#4917
2021-09-03MS Power Control Loop: Take C/I into accountPau Espin Pedrol10-137/+504
This commit extends existing MS Power Control Loop algorithm to take into account computed C/I values on the UL, received from MS. The related C/I parameters used by the algorithm are configured at and provided by the BSC, which transmits them to the BTS similar to already existing 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: I5dfd8ff9ab6b499646498b507624758dcc160fb6
2021-09-02sched_lchan_tch_x: use ul_cmr and ul_ft when generating RTP bad framePhilipp Maier2-4/+4
All generated RTP that originates from the BTS relates to uplink. When generating AMR BAD frame RTP packets, we must use ul_cmr/ul_ft and not dl_cmr/dl_ft. Change-Id: Ifa009819791cf7df2dd8201f442b0dae06f622a4 Related: SYS#5549
2021-09-02sched_lchan_tch_x: use functions to determine AMR tranmssion phasePhilipp Maier9-11/+416
The AMR transmission phase directly depends on the frame number. The transmission phase is used to tell if a received AMR frame contains a CMI (frame type that is currently used) or CMR (frame type that the receiver should use) codec identifier. The formulas in the present implementation seem to be correct but they do not reflect the numbers in the spec very well, nor do they have unit-tests. Lets replace them with more readble functions and test those functions with unit-tests. Change-Id: I94a934a6b3b397b4cd0e9da3577325de58814335 Related: SYS#5549
2021-09-02sched_lchan_tch_x: do not use cmr as ftPhilipp Maier2-2/+2
CMR and FT are updated each time an AMR voice frame is received from the radio interface. The transmission phase decides whether the voice frame contains CMR or FT. The code follows the transmission phase and keeps ul_cmr and ul_ft up to date. In contrast to the AMR frames on the radio interface, an AMR RTP packet always contains the CMR and the FT value. When generating the RTP payloed, The present implementation uses the CMR in the position where the FT should be and the FT is ignored. This is not correct. Change-Id: I6bb10ff3c76f67b9830787497653b546cf27fe8e Related: SYS#5549
2021-09-01debian/control: remove dh-systemd build-dependOliver Smith1-1/+0
Related: OS#5223 Change-Id: Ieb8669a9a43ea1acc6b2d8d2e363f2466c51697a
2021-08-31rsl: Support parsing up to 3 RSL_IPAC_EIE_MEAS_AVG_CFG IEsPau Espin Pedrol1-1/+1
struct ipac_preproc_cfg seems to suggest that there may be up to 3 IEs in some cases: "struct ipac_preproc_ave_cfg ms_ave_cfg[3];" Change-Id: I02633713eb557ee52e790a239f7b13b8c5b2b3bd Fixes: 9238c3549d3a7ce536e55d687b53be584a7f2b67 Related: SYS#4918
2021-08-31l1sap/gsmtap: Don't log UI fill frames [zero information field]Harald Welte1-0/+4
When generating GSMTAP, we are already suppressing generation for fill frames on PCH and AGCH. Let's expand that also to dedicated channels SDCCH, TCH/F and TCH/H. The fill frames just clog up the logs without providing much benefit. SACCH is still being logged, as it contains SI or MEAS REP, so every active channel still sees GSMTAP traffic every 480ms (SACCH interval). Change-Id: I0dd37d8848eb0379f84d15f5f006142b16823c6a
2021-08-30rsl: Fix rx of multiple RSL_IPAC_EIE_MEAS_AVG_CFG IEsPau Espin Pedrol1-1/+1
So far only the first one was applied. Fixes: 9238c3549d3a7ce536e55d687b53be584a7f2b67 Related: SYS#4918 Change-Id: Ib4f3c165a988e77b61a8852b254fc0904aa12482
2021-08-29osmo-bts-trx: send dummy FACCH in the absense of RTP framesVadim Yanitskiy2-2/+16
If for whatever reason the transmit queue of a TCH/{F,H} contains neither speech frames nor signalling blocks, osmo-bts-trx would currently transmit garbage. Of course, this causes decoding errors at the MS side. Ideally, we should employ an ECU (Error Concealment Unit) for the given codec in use. However, a simpler solution is to transmit dummy LAPDm frames over FACCH. This is what e.g. nanoBTS does. Change-Id: I868afecbcb6890f40c8f146e3ce00e836b794dd3 Related: OS#4823
2021-08-18add osmo_tdef groups, exposing T timers on VTY configNeels Hofmeyr5-1/+54
We have two osmocom specific timers used in the BTS, X1 and X2. Expose those on the VTY configuration, as timer group 'bts'. This prepares for a subsequent patch, where I would like to add another configurable timer. This provides the basic infrastructure for that. Related: SYS#5559 Change-Id: I0f56f9425134679219884b0c3c2f29e77aff5e64
2021-08-18jenkins: enable new flag --enable-external-testsNeels Hofmeyr3-0/+3
Change-Id: Iac47ce865c833d892c84425b49e9420838e100ca
2021-08-18add VTY transcript testingNeels Hofmeyr4-1/+303
This is not as trivial as with OsmoBSC or OsmoMSC, because normally the osmo-bts process exits right away when there is no BSC. Hence add --vty-test option to main. Use 'osmo-bts-virtual --vty-test' for testing. The other BTS models require dependencies / configure switches to be built. Essentially copied from osmo-bsc.git: configure.ac: add --enable-external-tests tests/Makefile.am: add 'vty-test' target Add osmo-bts.vty, some trivial VTY node testing. This prepares for adding VTY tests for T timer configuration added in a subsequent patch. Related: SYS#5559 Change-Id: I730daf548a3a9bb116aa8b6d5772ca9af0ada08f
2021-08-18enable Early Immediate AssignmentNeels Hofmeyr3-0/+59
When an Immediate Assignment comes in targeting an lchan that is not yet active, then hold back the RR Immediate Assignment until the channel becomes active. This allows the BSC to send the Immediate Assignment before first waiting for the Channel Activation ACK, saving one Abis roundtrip, and helping avoid double allocation on high latency Abis links. Related: SYS#5559 Related: I56c25cde152040fb66bdba44399bd37671ae3df2 (osmo-bsc) Related: Ifb2c62431a91dafa6116b5d6b9410930f00a6e18 (osmo-ttcn3-hacks) Change-Id: Ie52765b238b01f22fb327fe12327fbf10abcad4c
2021-08-16remove unused LCHAN_S_INACTIVENeels Hofmeyr2-2/+0
Change-Id: Ia738eaa796264fe0a97a2c86d6bbd37eaffe0a59
2021-07-19allow to configure multiple oml remote-ip addressesPhilipp Maier7-80/+292
At the moment we can only configure a single BSC in the BTS configuration. This also means that if this single BSC fails for some reason the BTS has no alternate BSC to connect to. Lets extend the remote-ip parameter so that it can be used multiple times so that an operater can configure any number of BSCs that are tried one after another during BTS startup. Change-Id: I205f68a3a7f35fee4c38a7cfba2b014237df2727 Related: SYS#4971
2021-07-15Make gcc 11.1.0 false positivies happyPau Espin Pedrol1-3/+3
Make gcc 11.1.0 false positivies happy After my system's gcc was upgraded, I get false positivies in a couple places. Let's initialize those to make gcc happy. """ //git/osmo-bts/src/common/vty.c: In function ‘lchan_summary’: //git/osmo-bts/src/common/vty.c:1881:23: error: ‘ts’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1881 | lchan = &ts->lchan[lchan_nr]; | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~ //git/osmo-bts/src/common/vty.c:1869:20: error: ‘trx’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1869 | ts = &trx->ts[ts_nr]; | ~~~^~~~~~~~~~~~~~~~~ //git/osmo-bts/src/common/vty.c:1852:34: error: ‘bts’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1852 | if (trx_nr >= bts->num_trx) { """ Change-Id: I93477142a5a4b3f3829b7398d6e564c127263596
2021-07-06paging: prioritize CS related paging over PS related pagings.Philipp Maier5-3/+52
When the paging queue is filled up to a critical level, pagings from the PCU should be dropped as each immediate assignment paging from the PCU is worth 4 normal CS pagings. Also the PCU may still issue pagings if the paginging queue is already full and CS pagings are dropped. In a congestion situation it is more important to get the CS rather than PS pagings through. Change-Id: I30f97672d7a0c369c4a656e878ab8cbbd83e31ea Related: SYS#5306
2021-07-05gsm_lchan_interf_meas_calc_band(): also print number of AVG samplesVadim Yanitskiy1-2/+2
Change-Id: I4cebb0c5eef16f7e20fce85c506fc271127d7259
2021-07-05rsl: use tlvp_val16be() in rsl_rx_ipac_XXcx()Vadim Yanitskiy1-5/+4
Instead of using tlvp_val16_unal() and then doing ntohs() here and there, convert the remote port to the host byte order once. Change-Id: Id883a976a03fd3022ed9d66f703b01244df2d9db
2021-07-05manuals/abis/rsl.adoc: clarify RF Resource Indication conformanceVadim Yanitskiy1-5/+5
Change-Id: Ia582c55c3c20f1f91993b3113d77ef2f34ca2eda Related: SYS#5313, OS#1569
2021-07-05Support SDCCH8 in osmo dyn tsPau Espin Pedrol3-6/+19
Change-Id: Id541dee6c224d2b8d97c07b916085883354cecbc
2021-07-05Rename osmo dyn ts enums to contain SDCCH8Pau Espin Pedrol16-52/+52
They will gain support to be activated as SDCCH/8 soon too. Related: SYS#5309 Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68 Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
2021-07-01power_control: constrain BS power reduction on BCCH carrierVadim Yanitskiy1-2/+16
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. Change-Id: I3299b6cdd230d3767321c3d6c64d468b7f5e1d02 Related: SYS#4919, SYS#4918
2021-07-01osmo-bts-trx: implement BCCH carrier power reduction modeVadim Yanitskiy9-3/+148
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, in the recent 3GPP TS 45.008 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. The power reduction operation can be controlled by the BSC by sending BS POWER CONTROL on the A-bis/RSL with the Channel Number IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the transmission power on inactive timeslots of the BCCH carrier. This is a non-standard, Osmocom specific extension, so indicate support of this feature to the BSC in the feature vector. Also add a VTY command to allow enabling/disabling the power reduction locally. Add some signalling notes to the A-bis/RSL manual. For more details, see 3GPP TS 45.008, section 7.1. Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98 Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716 Related: SYS#4919
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-20 18:10:40 +0000