| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: I7cbf868df3ba5d390cea3d529eef26d18dbe55ab
Related: OS#1572
|
|
The E1/E2/E3 bits are set based on out-of-band knowledge of the
current user data rate. The actual bit values are defined in
3GPP TS 44.021, Figure 4 "Coding of data rates".
TODO: this is only valid for transparent services,
for non-transparent services see 3GPP TS 48.020.
TODO: lchan->csd_mode is never set to the actual CSD mode...
Change-Id: I1a14597dff746cf975140b294400a2cc05badccd
Related: OS#1572
|
|
Since 95407f3f osmo-bts-trx supports scheduling all CSD specific
channel rates, however the rate adaptation was missing.
On the radio interface we deal with CSD-modified V.110 frames, which
need to be converted to normal 80-bit V.110 frames (RA1'/RA1), which
in turn need to be batched and sent in RFC4040 "clearmode" 160 octet
RTP payloads (RA1/RA2 as per I.460).
Note that this patch comments out TCH/F14.4 in bts_supports_cm_data(),
so that all channel allocations for this mode would be NACKed. The
reason for this is that the rate adaptation functions for TCH/F14.4
are different than the RA1'/RA1 and the RA1/RA2.
For more information, see:
* 3GPP TS 44.021, section 8 (functions RA1'/RA1)
* ITU-T I.460, section 1.1 "Rate adaption of 8, 16 and 32 kbit/s streams"
Change-Id: I5e3701ad52d5d428fd02caff037881045f2d0a02
Related: OS#1572
|
|
The abstract representation of the rest octets are moved to the header
file, so that the test case can include it. append_p*_rest_octets()
function become externally available for test.
Change-Id: Ifa5be8998b671160e38af1be707e040b00d407b8
Related: OS#5781
|
|
The location of the NCH is defined by the rest octet of System
Information 1. If NCH is defined, the given CCCH blocks are used for NCH
instead of AGCH/PCH.
The current list of VGCS/VBS call notifications is transmitted on the
NCH. If there is no notification, an empty notification is transmitted
on the NCH.
The Notification List Number (NLN) is used to indicated new
notificaitons. Only the last notification (or empty notification)
indicates NLN. This way the MS can determine after two equal NLN that
the complete list has been recevied.
Change-Id: I82fdaba3faaced76267a99ae14a5458a1b41fdaa
Related: OS#5781
|
|
When BCCH INFO is received via RSL message, the rest octet of the System
Information 1 message is parsed to get the position of the NCH. The
position is stored in the gsm_bts structure. If the position is not
present int the rest octet, the stored value is set to negative.
Change-Id: I799a27179d478d4ff577d8bc47ae524834851e85
Related: OS#5781
|
|
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
|
|
Change-Id: I72e30fe852ab69a162b117a534071ebddd4b16ba
|
|
Current osmo-bts-trx includes a provision for invoking ECUs from
libosmocodec in the UL path from the channel decoder to the RTP
output. This pre-existing implementation is counter to the spirit
of 3GPP specs (a BTS should merely mark BFI conditions in its UL
output, as opposed to actively modifying the frame stream with an ECU),
inconsistent between different osmo-bts models (only in -trx and no
others), and inconsistent even within osmo-bts-trx itself, where
the link quality check in l1sap will sometimes suppress the output
of the ECU - a quirk which the designers of the current mechanism
most certainly did not intend.
The solution decided upon in OsmoDevCall on 2023-06-21 is to make
this ECU optional per vty config, and move it from the trx model
to the common layer to resolve the inconsistencies. Implement the
first part: make the ECU application optional per vty config.
For backward compatibility with existing deployments, the new
"rtp internal-uplink-ecu" setting is enabled by default on osmo-bts-trx
but not on any other models.
Related: OS#6040
Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
|
|
The new vty option "rtp hr-format (rfc5993|ts101318)" selects the
RTP output format to be used for HR1 codec, consistently across
all models. The default is set to match legacy behavior: ts101318
on osmo-bts-{lc15,oc2g,sysmo} and rfc5993 on osmo-bts-trx.
On models where no legacy behavior is applicable, the default is
set to rfc5993 as a forward-looking measure - see OS#6036.
Closes: OS#5688
Change-Id: I168191874a062429a57904511a1e89e3f588732e
|
|
Change-Id: Ib0bed7a4196305e2b413ca657f4fa8fb6f0d39f6
|
|
This way the data model in TS 12.21 (Figure 1) is followed, where
there's a BTS Site Manager containing one or more BTS. In our case we
only support 1 BTS (cell) so far.
Change-Id: Ideb0d458ec631008223f861cf8b46d09524a1a21
Related: OS#5994
|
|
The param is usually called obj_class, but here it is called kind.
In any case, change the param to pass the related struct gsm_abis_mo
(which still contains mo->obj_class), similar to what's done in other
bts_model functions such as bts_model_opstart().
Change-Id: Ife2e98a791455d5f7e7052356d559af2f1d4d185
|
|
This way we simplify the common lower level interface. It can be added
in the future again if it is really required at any point to pass/use
specific TLV values in the device-specific code.
Change-Id: I64c6c6834e277b1d75a97d6f408e7e1b7ca85832
|
|
Simply return error codes from lower layer implementations, and do
the OML handling in the common NM TS 12.21 FSMs.
As a result, we simplify the logic in the lower layers.
Change-Id: I281c07bb5ad88ee03542f092141cebe036d10aee
|
|
Change-Id: I4ace06e115a2689bde9afd9f99ecee99d796360b
|
|
Our linter would complain about this these days:
__func__ should be used instead of gcc specific __FUNCTION__
Change-Id: I80bf6d0a89ce6454ae063759d6088a28b04670c0
|
|
In some environments it is highly desirable for the RTP stream
coming from each GSM call UL on a BTS to be fully continuous,
without any gaps, with _some_ RTP packet emitted every 20 ms,
even if there is no speech or SID frame to be sent in that frame
time window. The present change adds an rtp continuous-streaming
vty option which, when enabled, causes the BTS to emit RTP packets
with a zero-length payload, instead of producing gaps in the RTP
stream, when it has nothing else to send.
Related: OS#5975
Change-Id: Ic0e2edf2ed90ba0ac6bee5e7d9629bf0255e256d
|
|
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I06d3d5ab1dd21400a72f76eecc508886617ef4c6
|
|
Change-Id: If047cbaf95b343ee115690bf7a724a8edc5df735
|
|
The scheduler is now using the lookup tables instead of these
functions. The only part using them is the AMR unit test.
Change-Id: I1a9c80dd12252e7befe9c9bc8e8f7ee8648b5465
|
|
Related: SYS#5987
Requires: libosmo-netif.git Change-Id I632654221826340423e1e97b0f8ed9a2baf6c6c3
Change-Id: Ib80be434c06d07b3611bd18ae25dff8b14a7aad9
|
|
Change-Id: I7a2a846c2d68a4d6d77c4be62969238069d6cf95
|
|
Change-Id: I29d52bdacdebc0495d11425399e796fa7aef3ac4
|
|
This library will be used soon when adding Osmux support to osmo-bts.
Furthermore, it nice to have it available to make use of other general
interfaces to create connections, primitives, RTP and AMR related
functionalities, etc.
Related: SYS#5987
Change-Id: I49db4de715065c083e1249cbeae6298d6868e229
|
|
Make them more easy to read and edit by splitting to one element per
line when several elements are present.
Change-Id: I24ecfa1167b806dcb3a5a0c00343299df842a78b
|
|
3GPP TS 45.008, section 8.3 defines active TDMA frame subsets for
TCH channels, which shall always be transmitted even during the
silence periods in DTX mode of operation. Each frame number
listed in this section corresponds to a single burst.
The Uplink measurements always contain TDMA FN of the *first* burst
of a block, so it does not make sense to match the given FN against
all FNs in the respective subset. Instead, we should match only
specific FNs in accordance with the block mapping rules defined in
3GPP TS 45.002, section 7, table 1.
In the active subset for TCH/F there is only one *complete* block
starting at FN=52. Incomplete blocks {52, 53, 54, 55} and {56, 57,
58, 59} contain only 50% of the useful bits (partial SID) and thus
~50% BER, so we don't treat them as SUB.
In the active subsets for TCH/H there are two *complete* blocks
for each sub-slot. Their respective first FNs can be efficiently
defined in a lookup table (see ts45008_dtx_tchh_fn_map[]). Note
that we can use a single lookup table for both sub-slots of TCH/H
because their TDMA FNs do not overlap.
This patch fixes unexpected SUB-RxQual values > 0 on TCH channels
with DTXu enabled and other than AMR (HR, FR, EFR) codec in use.
Change-Id: I8cc3a755a8ad4dc564439aab2298c1e97ac0592d
Related: SYS#5853
|
|
SACCH detection can be simplified by checking the RSL Link ID in
process_l1sap_meas_data(). This eliminates the need to lookup
the multiframe position by calling trx_sched_is_sacch_fn(), which
definitely takes more CPU time than just L1SAP_IS_LINK_SACCH().
Calling trx_sched_is_sacch_fn() is still required for BTS models
reporting the measurements via PRIM_MPH_INFO (legacy way),
separately from the related Uplink blocks.
This patch can be summarized as follows:
* detect SACCH and set .is_sub=1 in process_l1sap_meas_data();
** for PRIM_MPH_INFO use trx_sched_is_sacch_fn();
** for PRIM_PH_DATA use L1SAP_IS_LINK_SACCH();
* do not call trx_sched_is_sacch_fn() from ts45008_83_is_sub();
* modify the unit test - test_ts45008_83_is_sub_single();
** remove test_ts45008_83_is_sub_is_sacch().
Change-Id: I507e96ee34ac0f8b7a2a6f16a8c7f92bc467df60
Related: SYS#5853
|
|
This function should also take lchan type into account.
Change-Id: I6920a04e0a6c846647fa1b6b3a3c80bbd6617b99
Related: SYS#5853
|
|
* Print unexpected TDMA FNs, each on a separate new line.
* Do not abort() on mismatch, keep running.
Change-Id: I32c104b139f32a39c8347de19de6ad7caec811de
Related: SYS#5853
|
|
Change-Id: If07f7f2a3ea996cbfc6a9087fa34402e38a7fd9f
Related: SYS#5853
|
|
Looks like this structure was copied from openbsc/osmo-bsc as-is.
The ms_mode[] makes no sense in the context of BTS, so remove it
and rename bts_mode[] to mode[] for the sake of brevity.
Change-Id: I7442360ed857554440a0b9854f2d2bbab9dc5a71
Related: SYS#5917, OS#4984
|
|
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I18ebb7395024a490da743c0bcb20959e6e9c7017
|
|
Change-Id: I8febb60b0ad91903c7869871f41d1c123dbe5ce3
Related: SYS#5917, OS#4984
|
|
This unit test demonstrates a problem in amr_parse_mr_conf(): the
threshold and hysteresis values are parsed incorrectly. They are
expected to match what we have in amr_fr_bts_mode_def[]:
Mode[0] = 0/13/4
Mode[1] = 2/25/4
Mode[2] = 5/37/4
This will be fixed in a follow-up patch.
Change-Id: Iab7e8878e62f598959e80fcb7e729b7f496962a2
Related: SYS#5917, OS#4984
|
|
Both misc_test_{SOURCES,LDADD} were simply ignored because
binary 'misc_test' is not listed in noinst_PROGRAMS...
Change-Id: Ia1739bab76261ff6d50824462b8ed2e0b34fb464
Related: SYS#5917, OS#4984
|
|
Change-Id: I2030f05b55fc9370e71ff12b26ffe1142f4acfc8
|
|
Most of the BTS specific VTY commands restrict BTS number to '<0-0>',
while bts_c0_power_red_cmd has '<0-255>'. This confuses libosmovty:
OsmoBTS# bts ?
<0-0> BTS number
<0-255> BTS Number
OsmoBTS# bts 0 ?
% Ambiguous command.
OsmoBTS# bts 0 c0-power-red 0
% Ambiguous command.
Let's stick to '<0-0>', we don't support multiple BTS anyway.
Change-Id: I937ac421143678b97627c1bc4fe573831ce097f6
|
|
As a side effect, we have to sacrifice a unit test (TC_inval_dummy)
because it becomes impossible to pass a dummy or invalid SACCH block
to lchan_bs_pwr_ctrl().
Change-Id: I937117cf26fb718d57920382f6972390ad498c51
Related: SYS#4918
|
|
Related: SYS#4917
Change-Id: Ib33a94eba92004f9327c91e020a506dfa9a957c3
|
|
This test showcases the current issue where the loop keeps bouncing
between 2 good MS Power Level values due to the loop "accepting" and
"reporting back" the previously considered good MS Power Level
announced/used by the MS. Hence, upon report back from the network, the
MS will switch to this new MS Power Level, and same thing will ocurr
over and over.
Related: SYS#4917
Change-Id: I16ed7fe8a123b99008e0c041d2f3e4232057d55c
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
