Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Iff38934a108b6b1cd298669834263a7d5296c3f6
Related: OS#4102, OS#1545
Use instead the received MS Power currently in use by the MS matching
the measured signal. This way there's no need to wait for the MS to
reach the announced MS power level or add checks in case the MS doesn't
support that specific power level. Furthermore, more fine grained
announced power level value can be obtained faster due to more input
iterations not being dropped while waiting.
osmo-bts-trx specific algo was not following this approach and using
announced MS power instead because it's wowrking at a lower level and
henche was not using the transmitted MS Power level value by the MS as
input for the calculation.
The "if (diff < 2 && diff > -2))" condition is dropped since equal
signal strength may still result in a different MS power level announced
(the one currently used by the MS during tx of last SACCH block).
Related: OS#1851
Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
Add a new common L1 SAPI enum, to unify all the BTS specific SAPIs.
Translate to this enum, and set the context for uplink messages in
each BTS specific implementation.
Set the context for downlink messages in the common l1sap code, by
converting the osmo_phsap_prim back to the SAPI value (mostly looking at
chan_nr). The new functions for doing this conversion,
get_common_sapi_by_trx_prim() and get_common_sapi_ph_data(), are based
on the existing to_gsmtap() and gsmtap_ph_data() functions.
Note that we can't set the uplink SAPI context in the common code,
because then we can't set it as early as possible. In this patch, the
SAPI context is set for the PHYs where the SAPI is readily available.
With additional conversion from the RSL channel, the SAPI context could
be set for osmo-bts-trx in a follow up patch.
Related: OS#2356
Depends: (libosmocore) I814cb3328d99faca9220adb5a80ffb934f219d7d
Change-Id: I6b7bb2e1d61502b61214f854a4ec5cbb7267545b
We don't know whether a data block on PDCH belongs to PDTCH or PACCH
without parsing it, because the latter one is being allocated on
demand. Let's use GSMTAP_CHANNEL_PDTCH by default, rather than
GSMTAP_CHANNEL_PACCH.
Change-Id: I7639215ef936a8ac05ca417a91f4e12755f318d4
First of all, we also need to apply the same filtering to Access
Bursts on PDCH as for the normal ones on RACH, i.e. filter them
by ToA (Timing of Arrival) and BER (Bit Error Rate).
Secondly, we shall not interpret Access Bursts on PDTCH/U as
handover related ones. Instead, let's print a warning and
ignore them since they are not (yet) supported by OsmoBTS.
Finally, in gsmtap_pdch() we need to set a proper channel type
for Access Bursts received on PDCH (PDTCH/U or PTCCH/U).
Change-Id: I461fde9f4543c45c42b591cd3fd0ff3d98673cec
RACH stands for Random Access CHannel, while in rach_pass_filter()
we're dealing with Access Bursts, that may be received on other
logical channels too (e.g. PTCCH, PDTCH or any other).
Change-Id: I1e5ca9930ab491a6916c972865154d54530cbf51
QTA is a Timing Advance value in units of 1/4 of a symbol. Let's
use ToA256 (1/256 of a symbol) field of L1SAP RACH.ind as a base
for QTA calculation in order to achieve better precision.
Change-Id: I6e6fa7985c430a9bdbd12af2a8b2a5a66f11a41c
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - they have nothing to do with xCCH coding. Instead, we
need to use tx_pdtch_fn() for Downlink and rx_rach_fn() for Uplink.
In l1sap_ph_rach_ind() we need to check if an Access Burst was
received on PTCCH/U and forward it to OsmoPCU with proper SAPI
value (PCU_IF_SAPI_PTCCH). To be able to specify a SAPI, a new
parameter is introduced to pcu_tx_rach_ind().
Change-Id: I232e5f514fbad2c51daaa59ff516004aba97c8a3
Related: OS#4102
The radio link quality is defined by C/I (Carrier-to-Interference
ratio), which is computed from the training sequence of each
received burst, by comparing the "ideal" training sequence with
the actual (received) one.
Link quality measurements are used by L1SAP to filter out "ghost"
Access Bursts, and by the link quality adaptation algorithms. One
can define minimum link quality values using the VTY interface.
On the VTY interface we expect integer C/I values in centiBels
(cB, 10e-2 B), while the internal structures are using float
values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy,
oc2g, and litecell15) expose C/I measurements in deciBels,
while on the L1SAP interface we finally send then in centiBels.
Let's avoid this confusion and stick to a single format, that
will be used by the internal logic of OsmoBTS - integer values
(int16_t) in centiBels. This will give us the range of:
-32768 .. 32767 centiBels, or
-3276.8 .. 3276.7 deciBels,
which is certainly sufficient.
Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.
The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.
Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906
Example: The fact that the PCU has connected with a given version is not
a *failure* in the first place, particularly not a MAJOR one. Let's
allow callers of oml_tx_failure_event_rep() specify the serverity of the
event that they're reporting to the BSC.
Change-Id: I49af04212568892648e0e8704ba1cc6de8c8ae89
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots
depends on the frame number. So in case of lost/skipped frame numbers,
we cannot simply compute the value for the current fn and then multiply
it by the number of frame numbers expired. Rather, we have to 'replay'
all missed frame numbers and individually determine how many RACH
slots happened in that frame.
Related: OS#3750
Change-Id: If4f8d2ea55fc722c64c330cde09e833b67ee98fe
We used a bogus multiplication factor of four when computing the number
of expired RACH slots. While there are four RACH slots per block (i.e.
4 times more RACH received than normal MAC blocks), that multiplier
doesn't apply here: We are calling this function per *frame* and not
per *block*. So the maximum number of RACH slots per *frame* is (in
most suual cases with a single CCCH) at maximum 1. Only some obscure
configurations with multiple CCCHs in a single cell would render higher
values. In any case, *blocks* never even enter this equation.
This wrong multiplier resulted in rather weird RACH load reports to the
BSC.
Related: OS#3750
Change-Id: I6b14fd6e7819f9164fb4a09b432a9f419e3b6e5c
There's no point in open-coding what LOGPLCHAN was created to do:
Log some event while stating the name of the logical channel.
Change-Id: I6913ac8fb543811126b85a54118333155c03bc03
The function oml_tx_failure_event_rep() replaces oml_fail_rep(), so lets
use only oml_tx_failure_event_rep() and remove oml_fail_rep()
Change-Id: I83c4fa9ebd519299fd54b37b5d95d6d7c1da24f6
Related: OS#3843
The existing implementation used a simplistic macro, which was wrong
in many ways:
1) it returned a negative value for "fn % 51 < 5" conditions without
raising any error message or asserting
2) it returned a wrong block number for many different input frame
numbers, as it didn't account properly for the FCCH/SCH gaps between
the blocks
Let's replace the simplistic macro with a proper lookup table based on
TS 05.02, and let's OSMO_ASSERT() if this is ever called with non-CCCH
frame numbers.
Change-Id: I11fd6cc558bb61c40c2019e46f56c1fe78ef39f5
Closes: OS#3024
The CBCH (as per GSM specs) always maps on sub-slot 2 of either
the SDCCH/4 or SDCCH/8 that it replaces. However, the way how we
express it as RSL-style channel number (0xC8) doesn't allow room
for any sub-slots. The top 5 bits are used for expressing CBCH, while
the bottom 3 bits are used for the timeslot number (TN).
So when transforming from channel number to lchan, we must handle the
CBCH case specially by using a hard-coded sub-slot number of 2.
Change-Id: I44e2f763d5d25311167f435f2ca7e030b2a3f009
Related: OS#1617
It's very confusing if some log messages log chan_nr as decimal, while
most log it as hexadecimal. Let's standardize on hex everywhere.
Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
for some historical reason, CBCH handling was not using the normal
L1SAP boundary. Let's change that and traverse L1SAP just like for
e.g. BCCH which is quite similar to CBCH handling.
This also has the added benefit of logging CBCH via GSMTAP.
Change-Id: Ibdba4c5e808330f8406f441a97fe0e81170fce97
Closes: OS#3534
The parameter bs_ag_blks_res, which is loaded into the BTS via the SI3
setting, defines how many of the CCCH blocks shall be used for AGCH. The
remaining CCCH blocks will then be available as PCH for paging.
Unfortunately there is no unit-test yet that verifies that all of the 8
different settings for bs_ag_blks_res.
- Separate the the decision logic that checks if a given fn is part of
an AGCH into a function to have it available in the unit-test.
- Add a test that checks all possible bs_ag_blks_res settings.
Change-Id: Ib9652f4013a4da3766852f8f03ce9ec5590f6989
Related: OS#1575
Rewrite an if-statement to better match the description given
in GSM 05.08, and quote the relevant paragraph in a comment.
Since this entire block of code only runs for SDCCH and TCH,
this new condition should provide the same result expect that
in accordance with the standard we now stop sending fill-frames
on a signalling TCH if DTX is in use.
Also note that this code should already cover parts of the
patch proposed at https://gerrit.osmocom.org/c/osmo-bts/+/5753
The changes to osmo-bts-litecell15/l1_if.c proposed there
should be equivalent to the fill-frame logic in this
existing common BTS code which is handling RTS IND.
Change-Id: Ibaf3ecbd0bde4f37e799d5e2f5d00dc695e0139a
Related: OS#1950
In l1sap.c we call lchan_new_ul_meas() and lchan_meas_check_compute()
directly in sequence. Lets unify thos two steps inside measurement.c so
that we only need to call one function from l1sap.c.
Change-Id: If48bc7442dfaab8c36b93949f741de6e836e792a
Related: OS#2975
When we introduced the n_s verification in
2cc37035d7, the variable name n_s was
used for what is actually n_r N(R) read from the LAPDm frame
Change-Id: Iaef1648f35ceae9d7f4cd1d9d5409e05115d199a
This assumption used while sending the rx data to gsmtap in l1sap_up was
making osmo-bts-virtual crash, since that bts model is allocating the
l1sap in the stack rather than inside the msgb.
Instead, let's use the assumption that l2h is set correctly in msgb by
the bts model lower layer.
crash report:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
0 0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
1 0x00007ffff6dbf4c8 in gsmtap_makemsg_ex (type=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=ss@entry=0 '\000', fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:179
2 0x00007ffff6dbf6d8 in gsmtap_send_ex (gti=0x555555877f10, type=type@entry=1 '\001', arfcn=arfcn@entry=17255,
ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:311
3 0x00007ffff6dbf765 in gsmtap_send (gti=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
chan_type=<optimized out>, ss=<optimized out>, fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
data=0x5555557d5b50 "", len=4294967263) at libosmocore/src/gsmtap_util.c:330
4 0x0000555555573571 in to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:397
5 0x0000555555573b9c in l1sap_up (trx=0x7ffff7ef8070, l1sap=l1sap@entry=0x7fffffffde80)
at osmo-bts/src/common/l1sap.c:1285
6 0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>, msg=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/l1_if.c:170
7 0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30, what=<optimized out>)
at osmo-bts/src/osmo-bts-virtual/virtual_um.c:50
8 0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090, _wset=0x7fffffffe010, _rset=0x7fffffffdf90)
at libosmocore/src/select.c:216
9 osmo_select_main (polling=polling@entry=0) at libosmocore/src/select.c:256
10 0x0000555555576fbc in bts_main (argc=5, argv=0x7fffffffe288)
at osmo-bts/src/common/main.c:364
11 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6
12 0x000055555555c4ca in _start ()
In the old code when the sizeof(osmo_phsap_prim) was being substracted
it resulted on a negative len which later was casted to unsigned int and
became a really big number.
Fixes: OS#3092
Change-Id: I51a880328497673a06d153bfb76c428265b8cbb8
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
In general, RACH bursts should not arrive with negative offset.
Let's limit early signal arrival up to 2 symbols, otherwise it
is most likely noise, interference or a ghost.
TTCN-3 test case: Icccc88545ed3aabd6da28a40599a8a77d1de477d
Change-Id: I662294fe3136cf7a259be13816a3e63f7db9a948
For some reason, the noise / ghost filtering was performed for
normal RACH requests, but not for handover RACH requests. There
are also ghost RACH, interference and noise possible, so let's
extend the filtering coverage.
Change-Id: I94fc15835280d624780200dadc4418210bf565ff
It makes sense to combine both existing BER (Bit Error Rate) and
ToA (Timing of Arrival) checks into a separate funcition, so
this code may be also used for handover RACH.
Change-Id: I1ddda238d5212a88a3dd5c4fc5dfcfea018151bd
Previously, the number of RACH slots with valid non-handover RACH
burst was incremented between both BER (Bit Error Rate) and ToA
(Timing of Arrival) checks. So, if a RACH burst passed the BER
check, but was dropped by ToA check, the counter of valid RACH
requests could be increased anyway.
Change-Id: I31594a8c5dce1f42226ced5b2dc8778152b3d829
The BTS_CTR_RACH_DROP counter is being increased in case if a RACH
request is ignored due to exceeding ToA value, but remains untouched
in case of exceeding BER (Bit Error Rate). Let's fix this.
Change-Id: Ia02e781d6c47d9d8012a4c8846fe4b731aab74d7
Before this patch we had:
* osmo-bts-trx internally using 1/256th bit/symbol period
* osmo-bts-sysmo internally using 1/4 bit/smbol period
* PCU interface using 1/4
* L1SAP interface using 1/4
* measurement processing code on top of L1SAP using 1/256
So for sysmo/lc15/octphy we are not loosing resolution, but for
osmo-bts-trx we're arbitrarily reducing the resolution via L1SAP
only then to compute with higher resolution again.
Let's change L1SAP to use 1/256 bits and hence not loose any resolution.
This requires a corresponding change in libosmocore for l1sap.h, which
is found in Change-Id Ibb58113c2819fe2d6d23ecbcfb8b3fce4055025d
Change-Id: If9b0f617845ba6c4aa47969f521734388197c9a7
When decoding RACH bursts, we should use a BER threshold in order to
help distinguish 'ghost' RACH bursts from real RACH bursts.
The theoretical ideal threshold according to some papers is 7 out of 41
bits qhich aquals to Eb/N0 of 0 dB = 0.1707 (17.07%)
We add a new 'ber10k' parameter to the RACH indication l1sap primitive
(needs separate change for libosmocore), and then fill this value from
osmo-bts-{sysmo,lc15,trx,octphy}. The common part above L1SAP then
applies the threshold, which can be changed from vty using the
"max-ber10k-rach <0-10000>"
command available at the BTS node. The unit is BER in 1/10000, i.e. a
value of 100 equals 1% bit error rate.
Change-Id: Ic41c11f6312a36baa2738547e8dcec80829457f8
In the past, rach_busy counting was performed below L1SAP, while
reporting was handled above. This lead to subtle differences between
the BTS models, such as osmo-bts-trx missing to increment rach_busy.
Let's move the rach_busy counting above L1SAP to share more code.
This means we need libosmocore Change-Id
I9439810c3a3ad89ea0302753617b850749af887c for the additional required
parameters in ph_rach_ind_param, as well as libosmocore Change-id
I2b1926a37bde860dcfeb0d613eb55a71271928c5 for osmo-bts-trx to determine
the RACH bit error rate.
Change-Id: I3b989580cb38082e3fd8fc50a11fedda13991092
Closes: OS#3003
info_meas_ind on the L1SAP always allowed the lower layers to pass
in whether a given measurement is part of the "SUB", or not.
However, the existing l1sap code before this patch simply drops this
information, despite the measurement.c code also having "is_sub" state.
Let's make sure this state is passed from L1SAP into measurement
processing as intended.
Fact is, none of our current lower-layers actually set this is_sub flag
for their primitives passed up in L1SAP, but at least now *if* they
would set that flag, the measurement code would process it as intended.
Related: OS#2978
Change-Id: Ibed2e8d7563b471c6b5dd2214ac4765caf31ed2a
This is currently only used for logging, but will be needed for proper
RX{LEV,QUAL}-SUB reporting in upcoming patches.
Related: OS#2978
Change-Id: I07fd06e8a379cab7c0c2eb111c3f5600037d3c9e
Let's make sure whenever we do have a frame number, we print it as
context in the related log line
Change-Id: I751d5ddb3322fce489bc241459738cbcc55c890b
A recurrent kernel crash in sysmobts (several kernel versions)
corrupting kernel memory in random places has been investigated and
reproduced by placing a call against an MSC sending RTP
with bandwidth-efficient AMR payload to osmo-bts-sysmo.
The osmo-bts-sysmo in turn sends the payload to the femtobts related
kernel modules via a msgq, which most probably fail to handle correctly
this bw-efficient AMR payload and corrupt the kernel memory.
First approach was to drop the bw-efficient AMR payloads lower in the
stack in sysmo specific code (l1if_tch_encode), but as there's no bts
model in osmo-bts actually supporting bw-efficient AMR, let's drop it
early in the incoming path for all models to avoid further problems.
Related: SYS#4063
Change-Id: If0c9233c628c724de4ab74e58e3e2affac79e6d0
Previously we always printed error on startup:
l1sap.c:461 Invalid condition detected: Frame difference is 627202-0=627202 > 1!
This is expected and of little practical use. Let's suppress it
by checking that FN was actually initialized.
Change-Id: I4f7cf285e437db0e980e1a2a3ab48a7255945448
Problem:
lchan->tch.dtx.dl_amr_fsm struct failed to allocate in l1sap_chan_act routine
in l1sap.c due to illegal characters contained in lchan->name which are passed to
osmo_fsm_inst_alloc routine. As a result, lchan->tch.dtx.dl_amr_fsm is NULL
causing BTS crashed (SEG FAULT) when trying to access this struct.
Below is snapshot of crash log obtained by GDB:
...
Fri Nov 24 18:13:55 2017 <0000> rsl.c:1653 payload type: 98
Fri Nov 24 18:13:55 2017 <0000> rsl.c:1463 (bts=0,trx=0,ts=2,ss=0)
RSL Tx IPAC_MDCX_ACK (local 127.0.0.1:11538, remote 127.0.0.1:30012)
Program received signal SIGSEGV, Segmentation fault.
0x00031930 in dtx_dl_amr_fsm_step (lchan=lchan@entry=0xb69592a8,
rtp_pl=rtp_pl@entry=0x87ae8 " \024\351Y\363_\337\345\351f\177\373\300\210\201\200\210",
rtp_pl_len=17, fn=1728481, l1_payload=0x10dd25 "", marker=marker@entry=true,
len=len@entry=0x10ddc4 "\024", ft_out=0xbefff7d7 "\002",
ft_out@entry=0xbefff7cf "\276\341_\032") at msg_utils.c:233
233 msg_utils.c: No such file or directory.
...
Fix:
* Use different formatting for lchan name passed to osmo_fsm_inst_alloc routine
* Refuse channel activation if FSM could not be generated (as opposed to crash)
Related: OS#2606
Reported-by: Minh-Quang Nguyen <minh-quang.nguyen@nutaq.com>
Change-Id: I929ce3703dc57acf8db569ae0e346265644d0b3c
Recently while testing new osmo-mgw, big RTP packets (around 4K bytes,
see OS#2625 for more info), were being received on the BTS, which was
aborting with the following message:
"msgb(0xff208): Not enough tailroom msgb_put (348 < 1488)"
The crash can be reproduced in a sysmobts as well as on my PC locally
with osmo-bts-trx. I used osmo-bts-trx to test that the patch solved the
abort.
Fixes: OS#2624
Change-Id: Idfde1dacc3dc3d3d5e239cf1f7e39ade7fc25975
When determining if a frame is a fill frame or not, the case
statement only conditionally handled AGCH and PCH cases. In
case a non-fill-frame was observed, the return value was uninitialized,
resulting in some non-fill-frames to be missed from GMSTAP
Change-Id: I7b46c720e34cb8ef9a91ae5da28a050439a1937d
Closes: Coverity CID#174175
* explicitly set SAPI when sending data_ind to PCU
* drop unused receiving code for BCCH SAPI
* send SI13 when PCU is connected
* send SI13 when new SI is received
Change-Id: I9e83ef792585aa962f99897d9973cef12f186bcf
Related: OS#2400
There's very little point in sending fill frames (such as empty PAGING)
or dummy UI frames via GSMTAP all the time. They serve no purpose other
than to bloat the log files and make it more difficult for users to find
the interesting bits among all this noise.
Change-Id: Icd18dafb235933c9e6aa9d98ddd8fac1522cc9ac
So far, L1SAP code is hiding RSL_CHAN_OSMO_PDCH from the bts specific
code below L1SAP. This is some kind of a hack/workaround, making code
and debug output / logs more difficult to understand.
So let's teach the lower layer how to treat RSL_CHAN_OSMO_PDCH and
remove the "hiding" code from the common l1sap.c code.
Change-Id: Iaaa833febe45b82166d3901f10cc5466a7591c19
The RSL Channel ID is best read / interpreted as hex value, not as
decimal, primarily due to the fact that it is a bit-mask of various
fields.
Change-Id: I9b72a67407870b485e7f7e8a72fa1ad30fc8ed4d
Internal l1sap dump_gsmtime has been moved to libosmocore as osmo_dump_gsmtime.
Remove use of internal function and replace with the libosmocore version.
Depends on libosmocore Ib5452e2c20f53006c0f6d197fb055728947125d8
Change-Id: Ia2f89965d970ed5bbb8c0d4f591a043e58c4bd66
After latest changes, l2 expects to receive an event for every TCH
frame, that is, no TCH frame event should be lost on that layer. We
should now then be safe returning always GSM_RTP_DURATION.
The code which used to calculate the variable duration is left there to
assert that indeed we are not longer having this kind of issues.
Change-Id: I9d112c6db142be138e71393e77129e6d069d9973
We want to always call l1if_tch_rx and l1sap_up in order to avoid losing triggering
events on the upper layer.
With this change, the upper layer will increase correctly seq + ts for
RTP. It will then send an RTP packet with only the header and no payload, which is
not correct but at least we avoid drifting the RTP clock. Upcoming patch
in the series solves this issue.
This patch assumes that we are not lossing data events from the physical
layer and that we receive an event every 20ms, even if the MS is not
transmitting due to DTX.
Depends on libosmocore If4ae20c22b881e94585dad710f17b9e37f77bf82
Change-Id: If5df8940fab833eb4e3ed851880b66987d356031
When we're in loopback testing mode for PDTCH, we must make sure to
avoid adding PTCCH blocks to the queue. Only PDTCH blocks must be
enqueued. For the transmit (downlink) side, we already had the PTCCH
check in place.
Change-Id: I7ef40d9bdf74a99375bc6568ed9483499664bf6f
This add support for BTS-side lookback of PDTCH channels.
If lchan-loopback is enabled, We take the uplink frames as received in
PH-DATA.ind and put them into the dl_tch_queue for that lchan. When we
receive PH-RTS.ind, we dequeue frames from that queue and transmit them
in downlink. If no frame is found in queue, we transmit an empty
(all-zero) frame of 23 bytes (CS-1).
Change-Id: Idd07a3f4a88c38398d3e844333c0104e2de23864
When the lchan is in loopback mode, we loop back all uplink blocks into
downlink blocks. We do not processs any RTP frames for that lchan
anymore. Rather, we discard those RTP frames to avoid mixing
looped-back samples with those received from remote.
Change-Id: I29ef4963e9c491c94c413cbc10436a2388c04d9b
In some situations (e.g. when trying to do measurements/testing on the
BTS receiver / uplink) it is useful to have a way to disable the radio
link timeout and keep any channel open until deactivated, irrespective
of whether (valid) data is received or not.
This adds a related feature that can be activated by using an
osmocom-specific value of 0xff for the TS 12.21 Connection Failure
Criterion (9.4.14).
Change-Id: I736f21f6528db5c16fa80cdb905af20673797be5
Computing the measurement results on in l1sap_info_time_ind() all
at once may peak the host CPU. On smaller systems (arm based
sysmobts) this might cause a noticable delay of other important
tasks (e.g. passing l2 messages back and forth) It makes more
sense to compute the measurement results continously when
l1sap_info_meas_ind() is executed.
Change-Id: Iecb9a30c0d716bfc88221cd752b1ffdc74269e30
RTP jitter increases continuously because duration is not
updated when speech resumes in DTX mode.
Change-Id: Ib51ed95a449369222c957b3acebd9ce1f66c5435
Add optional MS timing offset (3GPP TS 45.010 § 1.2) to RSL MEASUREMENT
RESULT (3GPP TS 48.058 § 8.4.8). The value is calculated either directly
from corresponding BTS measurement or from 3GPP TS 48.058 § 9.3.17
Access Delay (for known TA) and is invalidated after RSL report is sent
until new measurement indication or RACH is received.
Change-Id: I4dfe5c48834a083e757d5de3236a02e15a238b28
Related: OS#1574
In some cases, when successive mobile originated calls are made, the LAPDm UA
message gets lost because the channel is relased to early. Too overcome the
problem we do not send relase indications immediately. Instead a flag will be
set and the message stored and sent on the next TCH-RTS-IND.
This commit adds the functionality to store the release indication msg, to
rsl.c. It also addes the mechanism to forward the release indication to l1sap.c
See also coresponding change in openbsc.git:
Change-Id I15fc1ef8e9e83f009bde96de9a8e95702cffbce6
This patch is is a slightly improved/reformatted version of:
95d1f15ad1
Change-Id: Ie4f70c75f0137b4bd72d579b3a32575bac2fca38
* make oml_tx_failure_event_rep() static and use osmo_signal_dispatch()
wrapped into oml_fail_rep() to trigger event reports outside of oml.c
instead of directly calling into OML layer
* remove unnecessary formatting from text messages
Related: OS#1615
Change-Id: I738555c547926e97b325ab53763c0076c42309bc
This bug was introduced in the recently merged
commit 1e399f888e
aka change-id I87f40f5f160a4f6750c4f3d06997fc4f24049303
Fixes: coverity-scan CID#160156 and CID#160155
Change-Id: I88ed1b3e59213acdf97f88eda097b8172b952a5e
The counting of the expired rach slots in l1sap.c is not correctly
implemented. This commit fixes the implementation. The expired
rach slots are now conted correctly according to the configured
channel combination. If a CCCH and SDCCH are combined, only the
frames related to rach slots are counted.
Change-Id: I87f40f5f160a4f6750c4f3d06997fc4f24049303
* Unlike in AMR FR, in AMR HR incoming ONSET have to be treated
differently depending on whether we've recently sent SID UPDATE or
EMPTY frame. Split ST_SID_U FSM state into 2 states to accommodate for
that and make sure that additional states specific to AMR HR are not
used for AMR FR.
* Avoid sending E_VOICE and E_SID_U in corresponding states
as those do not initiate FSM state transitions anyway. This decrease
extra load from FSM signalling which otherwise would be triggered on
per-frame basis.
* Introduce separate signal for SID First P1 -> P2 transition to avoid
confusion with E_COMPL and E_SID_U initiated transitions from P1
state.
* Don't init DTX FSM for SDCCH channels.
Change-Id: I229ba39a38a223fada4881fc9aca35d3639371f8
Related: OS#1801
Previously timestamp was always adjusted according to FN difference. In
case of ONSET event this causes unnecessary TS gap with subsequent
speech packet. Fix this by checking Marker bit before performing
adjustment.
Change-Id: I9bf4b45aa990dd4014334dd846f43f793366056c
Related: OS#1801
Having RTP metadata is useful for debugging - save Sequence Number and
Timestamp next to Marker bit from RTP header.
Change-Id: I359b3bcb74fbfc071547fe2f9d837829374fe997
Do not assume that 1 == BS_AG_BLKS_RES but take that information from
SI3. Note: due to current implementation quirks we activate channels
before SI3 obtained, than we deactivate channels upon receiving SI3 and
activate them again. This might not be necessary once we migrate to
proper OML state machines.
This affects lc15 and sysmo hw.
Change-Id: I11377b12680ac3b2f77f80e742b6f0af63fc9c1e
Related: OS#1575
By default l1sap_tch_ind() returns 0 which signals to its caller that message
has been processed and can be freed. In case of loopback we're forwarding
the message to dl_tch_queue who will free it later. Returning 1 from
l1sap_tch_ind() prevents caller from freeing message.
Change-Id: I1e065075baa51c88fa717f132e1f0a83df68be02
Having duplicated code to fill in fn & tn values makes it harder to read
and modify static gsmtap_p* functions. Fix this by removing the
duplication and moving the common code one level up.
Change-Id: I0e67bf7423424cc11435bc0a5a1110297eeee383
Introduce dtx_dl_amr_enabled() function which checks that DTX is enabled
and FSM is allocated and use it for all corresponding checks.
Change-Id: Ifa68b641265ed14f242765c85e40da2d1021a541
Vadim Yanitskiy
Pau Espin
Martin Hauke
Oliver Smith
Harald Welte
Philipp Maier