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
Pau Espin
Harald Welte
Philipp Maier
Stefan Sperling