oml.c:461:20: error: returning 'HANDLE' {aka 'void *'} from a function with return type 'uint32_t' {aka 'unsigned int'} makes integer from pointer without a cast [-Wint-conversion]
Change-Id: I0831e448692713c488c0590a86bdc99b37160f47
OsmoBTS supports TW-TS-001 enhanced RTP format for FR and EFR codecs
since 2024, providing functional equivalent of GSM 08.60 TRAU-UL
output over IP physical transport. Now do the same with TW-TS-002,
IP equivalent of GSM 08.61 for HRv1 codec.
Only TCH UL path is affected; no changes are needed to TCH DL path
because existing RTP Rx handling for RFC 5993 also covers TW-TS-002.
Related: OS#6036
Change-Id: Icf11e43d4ce9df990d0e0a856d62d9ea11cb837c
As a result of how FR/HR/EFR DTX interacts with block diagonal
interleaving, at the beginning and end of each DTX pause a
correctly functioning TCH receiver will always pick up an
artifact consisting of 4 received bursts (2 for TCH/HS)
and same number of omitted bursts. Standard channel decoding
of this Rx artifact will produce a "half-block" in which half
of the bits prior to convolutional decoding will come from
a SID repetition whose Tx was notionally suppressed, while
the other half will be garbage. As a result of convolutional
decoding, the result will often appear as valid SID per
classification rules - but passing it as such to the Rx DTX
handler is wrong. Classic E1 BTS and GSM MS implementations
include a kind of SID filter at this point, setting BFI on
these received half-blocks, so that the Rx DTX handler will
see an invalid SID condition. Invalid SID means that comfort
noise generation is to be continued, but no updated CN
parameters are available - which is the truth in half-block
Rx situations. Implement the same filter.
Additional background info can be found here:
https://osmocom.org/projects/retro-gsm/wiki/DTXu_half-blocks
Change-Id: I46c62312316b04567bcadf6050597673f071247d
In any environment where GSM MS may exercise DTXu on TCH/FS, TCH/HS or
TCH/EFS, the BTS receiving this TCH UL has to classify each received
traffic frame as valid SID, invalid SID or non-SID speech. For E1 BTS
this SID classification requirement is explicit as there are dedicated
bits in TRAU-UL frames carrying the SID code. For an IP BTS the need
for this classification is less obvious as most RTP payload formats
omit SID indicator bits - however:
* For HR codec, RTP output in RFC 5993 and TW-TS-002 formats does
include explicit SID classification;
* Also for HR output in both TS 101 318 and RFC 5993 formats
(but not TW-TS-002), SID classification must be considered in order
to turn valid SID with some bit errors into perfect SID codeword;
* OsmoBTS already had logic for all 3 of FR/HR/EFR whereby if a frame
is received that is an accepted SID frame in GSM 06.31/06.41/06.81
definition, a flag is set so that the next good speech frame will
be emitted in RTP with marker bit set. This logic implies SID
classification in TCH UL path.
Prior to this patch, OsmoBTS performed limited, non-consolidated
SID classification:
* For FR and EFR, the only SID classification in TCH UL path was done
for RTP marker purposes by way of osmo_{fr,efr}_is_any_sid() Boolean
result fed to lchan_set_marker();
* For the same RTP marker logic with HR codec, only perfect, error-free
SID frames were detected;
* The same limitation applied to SID classification for RFC 5993 output.
Centralize this SID classification by moving it from BTS model to common
l1sap code and unifying it across all 3 codecs. Immediate functional
effects from this change are:
* On TCH/HS we now detect imperfect (partially corrupted) SID frames
and classify them as valid or invalid SID as intended by ETSI,
like we already did for TCH/FS and TCH/EFS;
* When emitting TS 101 318 or RFC 5993, we apply the inherent limitations
of those RTP formats to valid and invalid SID;
* With all 3 codecs, the check for a good speech frame as exit criterion
from DTXu state now happens after the link quality check in l1sap,
rather than before.
AMR speech mode is not affected at all by these changes: AMR DTX model
is completely different from that of FR/HR/EFR.
Related: OS#6036
Change-Id: Id6c8c146962de2f173760889eb232693bb4229d3
In original OsmoBTS architecture prior to Themyscira patches,
BFI (Bad Frame Indication) condition was signaled internally by
zero-length payload passed from BTS model to l1sap, and externally
by absence of RTP output (intentional gap) or a zero-length RTP
payload emitted in 'rtp continuous-streaming' mode. However, this
paradigm is contrary to classic GSM BSS architecture in which BFI
is an out-of-band metadata flag that travels alongside with frame
payload bits, whether the latter are valid or invalid.
Since 2024 OsmoBTS supports the option of TW-TS-001 output for
FR and EFR codecs, which allows the possibility of BFI-with-data
in RTP. OsmoBTS can already emit such BFI-with-data packets when
the BTS model delivered a deemed-good traffic frame, but that frame
was subsequently deemed bad by the link quality check in l1sap -
but there is still no explicit out-of-band BFI flag inside OsmoBTS
TCH UL path.
By introducing an out-of-band BFI flag, we make it possible for BTS
model PHYs to deliver marked-bad traffic frames: when CRC fails
in GSM 05.03 channel decoding step, a PHY that permits modification
(libosmocoding or future FOSS DSP PHY) can be enhanced to preserve
channel-decoded bits while conveying BFI.
The link quality check in l1sap is reworked to use the new OOB BFI
flag. Follow-on patches will introduce further logic that can also
assert BFI at high level, above BTS model PHYs.
While reworking the link quality check in l1sap, restrict it to
speech modes only: per GSM specs, BFI does not exist in CSD.
Change-Id: I8097946429e83eae90f89e49d17ffb8eb0636fcb
If osmo-bts-trx exit()s due to the PC clock issues, e.g. if the
process stalls, it produces rather confusing logging messages:
DL1C ERROR PC clock skew: elapsed_us=387574, error_us=382959
DOML NOTICE ... Shutting down BTS, exit 1, reason: No clock from osmo-trx
The second message suggests that the transceiver (osmo-trx) is the
culprit, but the first one reflects the actual reason (PC clock skew).
Let's pass proper shutdown reason to avoid confusion.
Change-Id: Ibbbbc4e919e6eb812882fc60de4be13fa77934b7
The purpose of the power control interval (P_CON_INTERVAL) is to
temporarily suspend the decision-making process of the MS/BS power
control algorithm, allowing time to observe the effects of a
previous adjustment.
However, input value (RxLev/RxQual) averaging must continue
uninterrupted, regardless of the power control interval.
Otherwise we're simply loosing measurement samples.
Change-Id: I2ccad1cb0ebbfcce64a93bc81b66db37b1399769
We receive a TXT indication that contains the PCU_VERSION from the PCU when the
connection to the PCU is established. This message contains a BTS number, which
is always 0. This is a hard coded value that does not refer to a specific BTS
object. Also it is not logical to inform a specific BTS object about the PCU
version. This information should be directed to the connecting process as a
whole. However, we use this TXT indication to trigger certain initialization
processes on the BTS object we manage inside the BTS process (currently this
is only 1 bts, but this may change in the future). So instead of using the
BTS in the TXT indication, we should iterate of over all BTS objects and
trigger the initializations for each of the BTS objects.
This change does not have any dependencies, nor does it change the current
behavior of osmo-bts. It just cleans up the logic, so that it works by
intension and not just by chance.
Related: OS#6507
Change-Id: I1bb8d0ec5e8d4b9f822f94249a75d8dc477144a3
That header is only really used to provide an old hack for
ipaccess-proxy tool in openbsc.h/osmo-bsc.h, and will be deprecated
soon.
Take the chance to organize a bit better the includes based on dependency
chain.
Change-Id: Ie4540eb6f535375a1e4ddf3849602aecb6260914
Call to e1inp_sign_link_destroy() may trigger a sign_down() callback,
which if happening synchronously, could end up reentring the same code
path we are in before bts->*_link was set to NULL.
Avoid it by marking the pointer as NULL immediatelly before calling
e1inp_sign_link_destroy().
Change-Id: Ibc06cdc2d2cd2028b7676fa0c3211ae251cca587
Add cmdline args to control logging, as already present in other more
usual bts models.
This is extremely important here since there's no VTY at all to
configure them.
Change-Id: I0b33919d71bacefe60be192810518fd927625127
Thanks to the work done by Mychaela (see the related Change-IDs), we
can finally implement handling of TCH/F14.4 (both T and NT modes) for
osmo-bts-trx and osmo-bts-virtual.
This channel mode is special in a way that it employs a different
rate adaptation function RAA' (defined in 3GPP TS 48.020 chapter 11),
which converts between between 290-bit blocks used on Um and Abis-E1
interfaces (E-TRAU frames on the latter) and A-TRAU frames spoken
over the A interface.
The result of function RAA' in the Uplink direction is 320 bits,
which is equal to 4 x 80-bit V.110 frames, but actually carrying
8 x 36-bit packed frames. These 320 bits are then fed to the RA2
function, like we do for other CSD channel modes.
Change-Id: I3c3bef0bd2f72b8381597b5699e2060165b702a0
Depends: libosmo-abis.git I11fc1529f5be88fa778c7e05cb11eef58a389d40
Depends: libosmo-abis.git I1347a25ce97d5022502ee9112caded66315b09a4
Related: OS#6167
According to 3GPP TS 44.021, section 10.3.2, a radio-interface data
block for a TCH/F14.4 channel consists of eight 36-bit data frames
and two M-bits (290 bits total). Let's fix our definition.
Change-Id: I4f11eda98420587efa339484b62f46bf19f78809
Related: OS#6167
A radio-interface block in GSM carries several modified 36-bit or
60-bit V.110 frames. Let's rename the fields to avoid confusion.
Change-Id: If97787a64e30ff9b39c26749ba32aed09d3d7983
The 'resp_msg' will be NULL if msgb_dequeue_count() returns NULL,
i.e. in the case of Downlink queue underrun. We need to handle
this gracefully and check 'resp_msg' before dereferencing it.
Change-Id: I4e1ea1d1ded2ffb3a07cc06f8b9b5dd922d32ec6
Fixes: 0a34af153 ("CSD NT modes: transmit properly aligned RLP frames on DL")
The mapping sched_tchh_dl_csd_map[] is valid for DL TCH/H4.8 and
TCH/H2.4, but not for DL FACCH/H. We already use a separate
lookup table sched_tchh_dl_facch_map[] when sending RTS.ind for
DL FACCH/H, so no additional checks are added in this commit.
Change-Id: Idb753fa5c87dc79e9ad19e550680de6f462eed69
Fixes: 95407f3f6 ("osmo-bts-trx: implement CSD scheduling support")
Related: OS#1572, OS#6618
lchan->abis_ip.rtp_socket is NULL before the BSC indicates the RTP
parameters using the CRCX/MDCX procedures. send_ul_rtp_packet()
does check lchan->abis_ip.rtp_socket against NULL before calling
osmo_rtp_send_frame_ext(), so should send_ul_rtp_packet_hrdata().
Take a chance to make send_ul_rtp_packet_hrdata() more consistent
with the send_ul_rtp_packet() by reordering code a bit.
Change-Id: I05d88a739dc54ca68e50d20b2d0d0b097ae8ca4a
Fixes: 59686cd27 ("CSD: implement half-rate modes correctly")
Related: OS#6618
There are two levels of alignment inside clearmode RTP packets
carrying CSData per TS 48.103 section 5.6:
1) Alignment of 2 or 4 V.110 (T) or pseudo-V.110 (NT) frames within
one RTP packet of 160 octets of an imaginary ISDN B channel;
2) For NT modes only, alignment of 4 pseudo-V.110 frames to form
a single 240-bit RLP frame.
Per previous patch, alignment 1 is to be treated as mandatory for
RTP transport inside an Osmocom network. Alignment 2 _could_ be
made mandatory for TCH/F9.6 NT, but the same is not possible for
TCH/[FH]4.8 NT: in the best case of half-alignment, alternating
RTP packets will carry alternating halves of RLP frames.
Implemented solution: allow arbitrary state of alignment 2
(aligned or misaligned) in the incoming RTP stream for all CSD NT
modes, and perform the necessary alignment internally.
This approach is consistent with the world of E1 BTS: a TRAU in
data mode is responsible for alignment 1 (with 20 ms TRAU frames
taking the place of our clearmode RTP packets), but only the BTS can
perform alignment 2, as the TRAU is agnostic to T vs NT distinction.
Related: OS#6579
Change-Id: Idaebfce6da13b23ba265a197502712d83991873e
The next patch in the series will add code for alignment of downlink
RLP frames in CSD NT modes; that code will go into new file csd_rlp.c.
RLP GSMTAP code logically belongs in the same place - hence move it
there in preparation.
Change-Id: I824ce6614c8591cccc5f6bcdde767fe49d551378
The code in this function used else-after-return constructs, which
are now rejected by the linter for newly committed code. This
function needs to be moved to a new source file, which will cause
it to be treated as new code by the linter - hence fix this code
style issue first.
Change-Id: Ide00e819222bb0173eca42ee3714db7f7e1a6d1e
Modify CSD RTP input path code so incoming bits E2 & E3 from V.110
frames reach the TCH-RTS.ind handler in l1sap. These bits will be
used in the next patch to ensure proper alignment of DL RLP frames
in non-transparent CSD modes.
Related: OS#6579
Change-Id: I43b97caa6030b9401779998ca5dddc4cfe636e2f
Since the beginning of CSD implementation, OsmoBTS has operated
with an implicit (unstated) policy that V.110 frames must be
perfectly aligned within received clearmode RTP packets - a requirement
which is NOT set anywhere in TS 48.103 or any of the other specs
it references. This design policy is sensible from the standpoint
of implementation complexity (both OsmoBTS and osmo_trau2rtp emit
such perfectly aligned packets; if someone is building a gateway
between an Osmocom GSM network and ISDN-style external networks,
that gateway can act as the aligner), but it should be explicit
rather than implicit.
Check V.110 frame alignment in received clearmode RTP packets,
and reject packets that fail this alignment check.
Change-Id: Icd704dc7fa02e60074efc8a29ad7e42ebdf63783
In all classic NT modes below 14.5 kbit/s, V.110 frame bits E2 and E3
are repurposed to indicate the alignment whereby a single 240-bit RLP
frame is composed of 4 pseudo-V.110 frames in switching transport.
(TS 48.020 section 15.1.) In the case of TCH/F9.6, setting both E2
and E3 is easy because all 4 pseudo-V.110 frames go out in the same
clearmode RTP packet as a result of a single channel decoding
operation. However, in the case of TCH/F4.8 there are two separate
channel decoding operations producing two separate RTP packets
20 ms apart. Furthermore, GSM 05.03 section 3.4.1 specifies which
TDMA frame positions hold which half of the RLP frame - therefore,
the correct emission of bit E2 needs to be based on the TDMA frame
number at which the block was received.
A similar situation occurs with TCH/H4.8 NT: we receive a single
block from the 05.03 decoder every 40 ms, containing a full RLP frame,
but we emit it as two separate RTP packets, each carrying 20 ms worth
of bits. These RTP packets also require correct setting of E2 bit.
Related: OS#6579
Change-Id: I485af5e01ea87c1721a298a486cd344a17884200
TCH/H4.8 and TCH/H2.4 modes are different from all other TCH in that
the channel coder runs (statistically) every 40 ms instead of the usual
20 ms. However, the standard RTP interface of TS 48.103 still requires
20 ms packets for all CSD modes; furtherfore, this requirement is not
just a matter of 3GPP spec being obstinent, but is highly useful for
interoperability, both between FR and HR and between OsmoBTS and E1 BTS.
The handling of CSD HR was totally broken in this regard: wrong RA2
packing mode, RTP clock model was violated, and even an internal
mismatch with l1sap sending TCH.req prims at twice the rate
at which the PHY expects them.
With this patch CSD HR handling becomes correct for TCH/H2.4 and for
TCH/H4.8 transparent; fully correct handling for TCH/H4.8 NT will
appear in a follow-up patch.
The packet/frame rate mismatch (40 ms Rx/Tx times while each RTP packet
carries 20 ms worth of data) is reconciled by emitting two RTP packets
directly back-to-back for UL, and pulling two RTP packets at a time
from the Rx jitter buffer at the needed times for DL.
Note: due to bug OS#6604, TTCN3 tests for CSD half-rate transparent modes
will start failing once this patch is merged; to make them pass again,
TTCN3 test code will need to be reworked to fix that bug.
Related: OS#6577
Change-Id: Ib35e910df263743cd243f51fb0bd6551ddfcf4c5
In commit 66eae187, I skipped assigning LCHAN_CSD_M_NT (0) to
lchan->csd_mode for non-transparent channel modes. I assumed that
the entire gsm_lchan struct was zero-initialized during activation
or release procedures, but this assumption was incorrect.
In fact, some lchan fields are initialized during activation, while
others are initialized during release. Specifically, lchan->csd_mode
is zero-initialized when the process starts, and then updated only
for transparent mode requests. For non-transparent mode requests,
this field is not updated, meaning it retains its previous value.
This bug caused incorrect E1/E2/E3 bit settings and missing GSMTAP
RLP output for channels that were previously used for transparent
CSD calls. This patch is fixing it.
Change-Id: I793ab4dc25fa852eade6f7a3b67ae961ceb7a093
Fixes: 66eae187 "rsl: rsl_handle_chan_mod_ie(): set lchan->csd_mode"
Related: OS#1572, OS#6579
The existing tests are all for T (transparent mode).
Add NT (non-transparent mode) variants.
Change-Id: Ie335bc0623dd7e887a0b3b1c40d61153b84924b2
Related: OS#1572
When sysmoBTS PHY decodes TCH UL Rx as FACCH, it sends only one
PH-DATA.ind for the FACCH, but none for TCH. This case was handled
correctly for TCH/F in 2023-03, but FACCH/H has not been handled
correctly until now.
Change-Id: Id6d966348fb2be084485279e75480f98f46e464b
In a typical lab setup the BSC is co-located on the same host with
the BTS process. Using the localhost address instead of random
addresses makes life easier for those using example configs.
Change-Id: I41b8de14c19088ef614ce751c738e4fc5969f0da
These lines yield nothing without the 'gsmtap-remote-host' parameter
actually enabling GSMTAP Um logging. Remove them to avoid confusion.
Change-Id: Icde668b5829a56663c258e54957e2f639a8e82a9
Ensure that the 'ipa unit-id' in all config examples is set to
value 6969, matching the value used in the osmo-bsc config examples.
Change-Id: I2b5ed8eaa5c2cbfe20091dcfea0dd1a70f148f7c
The access burst detection must be enabled on channel activation, if the
handover is activated or if the channel is used for group / broadcast
call.
Related: OS#6467
Change-Id: I467a11662a580e33932ae142dcf605f4c0672daf
Themyscira Wireless Technical Specification TW-TS-001 defines
an enhanced RTP transport format for FR and EFR codecs within
an IP-based GSM RAN, restoring the full functionality and semantics
of GSM 08.60 TRAU-UL format that were lost in the industry transition
to RTP with payload formats standardized by TIPHON and IETF.
Given that this new enhanced RTP transport format runs counter
to commonly accepted standards, it is strictly optional. OsmoBTS
always accepts both basic and extended RTP formats, but it sends
the extended RTP format of TW-TS-001 only when commanded to do so
by the BSC via an RSL extension IE; OsmoBSC will in turn direct
the BTS to use this extension only when the CN asks for it via
the BSSMAP extension defined in TW-TS-003.
Spec references:
https://www.freecalypso.org/specs/tw-ts-001-v010100.txthttps://www.freecalypso.org/specs/tw-ts-003-v010002.txt
Related: OS#6448
Depends: I0eccfe5ddcf44f8f20440acb01e2d4870ec0cd91 (libosmocore)
Change-Id: Id997e8666bc19e60936aaa83b43a968d30320bd7
This IE has TLV format, even though the only valid form is a single
value octet. To guard against pathological input with L=0 in this IE,
we have to check the length explicitly with TLVP_PRES_LEN before
accepting TLVP_VAL as if it was TV.
Change-Id: I15fa75b6c30d7fa0bf50424d25fc47a088dada0a
I have verified that with AmbientCapabilities=CAP_SYS_NICE, setting
scheduling policy as described in the manual still works as expected.
Related: OS#4107
Change-Id: I37be0dd4df012047a495235195912bd06ad2423d
A new command was recently added to libosmovty:
show fsm-state-graph NAME
This is now the longest command, affecting spacing in the output
of 'show ?' command. Align spacing to make the test pass again.
Change-Id: I80f896e45a88550909c5767169286fc321a36e56
Related: libosmocore.git I09ee0a8c3fc4b1aa991ab5c93c0b654fccd7ea4c
RSL_IE_OSMO_TEMP_OVP_ACCH_CAP and RSL_IE_OSMO_OSMUX_CID have been
defined for a while now, but are still not documented. Until someone
who knows them can document them properly, we need to at least
acknowledge their existence, and show the IEI code points that
have been allocated to them, so it is clear from the documentation
what IEI code points have already been allocated and where new
extensions are to be added.
Change-Id: I55d7eef946c24cd0e224157d95fdac3243a374ef
Let's add some rate counters to add visibility to the BTS on what is
happening in terms of received and/or transmitted RTP packets.
This should help during debugging any RTP related issues.
Change-Id: Ide674bde10b0e4b501d6a48947b983090342dfec
osmo_io permits us to use the io_uring backend, which should
significantly speed up the many small read/writes we're doing
on virt-um.
Change-Id: Icfe42da00fd446c38090055e2baa5d5e0ae5b70c
ctrl_cmd_send() is now a deprecated API function.
Change-Id: I663669a1bcf7b58d6a6175cbb51c333f5cfaedd7
Depends: libosmocore.git Change-Id Ic81af56e7ea6921ba39168727ef64c308e9c6754
We have licensed the code under GNU Afffero Public License,
and state that in the first paragraph as well as in the link
to the license. However, a paragraph in the middle stated
"see the GNU General Public License", which is somewhat misleading.
Let's fix that.
Change-Id: I37e503b195fe43e1da42c080900504ca8e682e76
All config file examples must be listed in EXTRA_DIST unconditionally.
Adding them conditionally results in incomplete release tarballs,
containing only 'osmo-bts-virtual.cfg' and failing to build.
Change-Id: I167027afde3cee40a3b52adfaec7bde91ba896da
Related: OS#6349
In early-Immediate-Assignment, the BSC sends the IMM ASS message
directly after it sent the Channel Activation message, and osmo-bts
should cache it until the Channel Activation is complete.
So far the code had a bug: it assumed that the lchan was on the same TRX
where the IMM ASS is transmitted -- but actually, 'trx' refers to the
BCCH channel's TRX, i.e. always c0.
Instead, look up the correct TRX by the ARFCN in the IMM ASS message.
Now, when frequency hopping is enabled, there will be no ARFCN in the
IMM ASS message, hence this fix does not work with frequency hopping.
Related osmo-bsc patch disallows this combination.
(To also support frequency hopping, osmo-bsc would need to modify the
RSL protocol: send the IMM ASS message as a custom IE directly as part
of the Channel Activation. Then it is always possible to correllate the
IMM ASS with a specific trx and lchan, no matter what information it
contains. However, early-IA is a "bad" feature in itself as it
"promotes" having high latency on Abis. It seems unnecessary to do extra
work to also support this odd use case for frequency hopping.)
Related: osmo-bsc I8d375e5155be7b53034d5c0be5566d2f33af5db0
Related: SYS#6655
Change-Id: Id9a930e5c67122812b229dc27ea2bfe246b67611
Current code evaluates as follows:
(trx->arfcn | is_uplink) ? GSMTAP_ARFCN_F_UPLINK : 0
while we want it to be evaluated as follows:
trx->arfcn | (is_uplink ? GSMTAP_ARFCN_F_UPLINK : 0)
Change-Id: Ida3d684968a3e4a45531d4b6d7b6af170e3e39f4
Fixes: CID#338165
If there's nothing to transmit over a CSD NT channel, both ends generate
NULL frames. Let's add an option to suppress GSMTAP output for those,
creating pcap files with less noise.
Change-Id: I85a2159cfaa01bfb4205c1462e3a9dbda68e4bad
Depends: libosmocore.git I2d9bd8eb4f0cd0f72c436996767b199429596917
In CSD (Circuit Switched Data) NT (Non-Transparent) mode, there
are RLP (Radio Link Protocol) frames inside the modified V.110.
wireshark alrady has a dissector for this, and we've introduced
a GSMTAP type for RLP some time ago. So with this patch, we now
generate such GSMTAP RLP frames.
Change-Id: I6a258458822bcb3fe7290a9b9b3d104beecda219
Get Attributes of Channel Object class that osmo-bts supports are added:
* ARFCN List
* Channel Combinations
* TSC
* HSN
* MAIO
Related: OS#6172
Change-Id: I56e067be9e5c17625c7da4e982b90927802f57b4
Two Get Attributes of Radio Carrier Object class that osmo-bts supports
are added:
* RF Max Power Reduction
* ARFCN List
Note: Only one ARFCN is reported, because synthesizer hopping is not
supported. The NM_ATT_ARFCN_LIST in the Set Radio Carrier
Attributes message currently allowes one ARFCN only.
Related: OS#6172
Change-Id: I49ab516c38a986520f1d3f6e26ddd20ee16688ac
Most Get Attributes of BTS Object class that osmo-bts supports are
added. Not supported attributes are:
* T200
* Starting Time
* HW Configuration
Related: OS#6172
Change-Id: I067c6bdea3c44d5a731bcfdcfe304c14629eb3db
Osmo-bts uses the new polling based LAPDm implementation.
The OML message NM_ATT_T200 is ignored, because T200 timeouts are set to
the minimal response time. Longer timeouts would cause lower throughput
in case of lost frames. Shorter timeouts would cause LAPDm to fail.
Related: OS#4074
Depends: libosmocore.git I6ebe83f829d7751ea9de1d90eb478c7a628db64c
Change-Id: Ic6d7902b13cf491daaa8752db78f9875387aeffd
An empty PDCH block contains no payload, sysmo-bts and similar BTS
models crash, because they expect the msg->l2h to be set. The function
l1sap_pdch_req() will not set msg->l2h for empty PDCH blocks, so these
models crash.
The current osmo-pcu does not send empty PDCH blocks to these BTS
models. But there shouldn't be a crash, if we receive empty PDCH blocks
over the PCU socket interface.
Change-Id: Icb52c896766425fcf453c65530c4c0b8d06b8821
If the channel is activated for immediate assignment, the initial data
link establishment on main signaling link with SAPI 0 must have L3
infomation included in the SABM message. If this is not the case,
release the data link without notifying BSC.
Related: OS#5971
Change-Id: I6819b51a876b8743c2d4a04165b7900723a1631c
Every BTS needs to have some graceful handling for the scenario
where it is time to send out a speech frame on TCH DL, but there is
no frame to be sent. One possible solution is to transmit dummy
FACCH, but this option is unattractive for TCH/AHS where FACCH
displaces two speech frames rather than one. A more elegant solution
is to emit a speech frame that is bad, causing the MS receiver to
declare a BFI condition to trigger substitution and muting procedure.
A bad frame is generated by gsm0503_tch_{afs,ahs}_encode() by setting
the payload length to 0.
Depends: libosmocore.git I82ce2adf995a4b42d1f378c5819f88d773b9104a
Related: OS#6049
Change-Id: I056f379715c91ad968f198e112d363a9009dc1c3
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: Ib51238a0e09d4484a539a7f822864189872698b6
When adding support for Circuit Switched Data calls, we had to enlarge
the burst buffer size to accommodate bits for a maximum of 24 bursts.
Let's take advantage of this by utilizing the currently unused part of
the Uplink burst buffer for storing bits of previously decoded blocks.
This eliminates the need to allocate additional memory for SACCH.
Change-Id: I15047cd1df4476054b36f05616e41f5297d9bfe5
Related: SYS#5114, OS#4794, OS#4795, OS#4796
In accordance with 3GPP TS 44.021, sections 8.1.6 and 10.2.3, the
transmission of idle frames to the DTE is mandated when no data is
received from the radio interface. An idle frame has all data,
status, and E-bits to binary '1' (excluding the alignment pattern).
This requirement is currently implemented for the Uplink, see
function csd_v110_rtp_encode().
However, 3GPP TS 44.021 does not explicitly specify whether the same
rule is applicable to the Downlink, perhaps assuming a continuous
stream of bits on the CSD-over-TDM link. Currently, we transmit
a sequence of binary '0' on the Downlink instead of idle frames.
* In non-transparent (RLP) mode, whether all bits in a block are
set to binary '0' or '1' has no impact, as both scenarios lead
to an incorrect FCS.
* In transparent sync mode, any filling be it binary '0' or '1'
is perceived as incorrect or unexpected.
* In transparent async mode, it is more logical to transmit a
sequence of binary '1,' which will be interpreted as
a sequence of stop bits.
Let's align the Downlink with the Uplink for consistency and transmit
idle frames when no data is available for transmission. The modified
60-bit V.110 frames exclude the alignment pattern, so sending a
sequence of binary '1' is enough to achieve the intended goal.
Change-Id: I0b25cfac41b6d8dcf3bfd9d46d51a9665f1b047a
Related: OS#1572
Even though it might have a somewhat higher performance impact,
opting for the common code path for FACCH by allocating a msgb
on heap is more favorable for both readability and maintainability.
This choice is preferred over directly calling
gsm0503_tch_fr_encode() and then using a 'goto' statement.
A similar strategy will be adopted in an follow up patch for CSD.
Change-Id: I67cb5c6f4d15149996e17c78a59d66db396da8ff
Related: OS#1572
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. Whenever the uplink on a voice group channel is free, the uplink
access burst detection is turned on. When the uplink access is granted
to a talker or when the calling subscriber has been assigned to the
channel, the uplink access burst detection is turned off until the
uplink becomes free again.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I92d6773a3a463eb747143c85aa149e54c1fda122
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. This is required for voice group/broadcast channels.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I61f232aa91191dae08404c1f08cad91964d74568
An MPH-INFO message is used to turn detection of uplink access bursts on
or off. This is required for voice group/broadcast channels.
Related: OS#4851
Depends: libosmocore.git Ibd6a1d468a70126a8f67e944fcb916969cc3c36b
Change-Id: I9045437d52984b7abe00fbc815d7f83c62c0fb5a
- If the llist is flushed during rx rsp callback, when the flow is
returned to trx_ctrl_read_cb() it would access tcm which was in the
llist and end up in use-after-free.
- We need to store state on whether code path is inside the read_cb in
order to:
-- Delay transmission of new message if callback calls trx_if_flush()
followed by trx_ctrl_send(), since the trx_ctrl_send() at the end of
trx_ctrl_read_cb would retransmit it again immediatelly.
-- Avoid accessing tcm pointer if the callback called trx_if_flush(),
since it has been freed.
Related: OS#6020
Change-Id: Ibdffa4644aa3a7d219452644d3e74b411734f1df
This reverts commit 4444262a6a.
This commit introduced several side effects:
- tcm is left out of the l1h->trx_ctrl_list and hence won't be ever
retransmitted.
- Since tcm is removed before rsp callback, the llist may become empty
and if somehwere in the rsp callback a new message is enqueud it will
be sent immediatelly, and will be retransmitted again when
trx_ctrl_read_cb() calls trx_ctrl_send() at the end.
Change-Id: Ideb2d08ac8a2902bceeabfb055c59c9a13dbe3c0
Related: OS#6020
There are still some remains that are related to the old PCUIF v10
protocol version. Let's clean those up.
Related: OS#5927
Depends: osmo-pcu.git I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8
Change-Id: I04f7108c94c99c9920192177087748e8b89b3106
If frames are not deliverd fast enough to the DSP, bursts will get
dropped. The osmo-bts-sysmo process must have priority over other
processes, so it can deliver frames fast enough.
Related: OS#6199
Change-Id: I2394e6bbc00a1d47987dbe7b70f4b5cbedf69b10
While compiling:
vty.c:169:3: warning: 'is_config_node' is deprecated: Implicit parent
node tracking has replaced the use of this callback. This callback is
no longer called, ever, and can be left NULL. [-Wdeprecated-declarations]
.is_config_node = bts_vty_is_config_node,
^
Change-Id: I54c5aa5911611b181f80e76556b150f25dd5b60c
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo
to signal to the PCU that the direct PHY access for the sysmo-bts DSP
should be enabled. With time, support for other BTS models was added and
the flag became a synonym for "direct PHY access", so it makes sense to
rename it to "PCU_IF_FLAG_DIRECT_PHY"
Related: OS#6191
Depends: osmo-pcu.git I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Change-Id: Ib556a93f7d7d7dbe1e96c4a0802bc802241b2b2d
DTX is not allowed for TCH/H in signalling mode, but *is* allowed
for TCH/F in signalling mode.
Change-Id: I91cfd8f561eb47a5fc48c0682d56331a1d69aded
Related: OS#6168
The current implementation does substitute all missing meas samples
with dummy -SUB measurements and then complain about exceeding
amount of -SUB samples.
Change-Id: Iab84f4b64b645486e2f115b0f82ee2f27eb992bc
Related: OS#6168
3GPP TS 45.008, section 8.3 defines TDMA Fn subsets, which shall
always be transmitted when DTX is employed, only for:
* TCH/F in signalling mode (but not for TCH/H),
* TCH/H and TCH/F in data mode (CSD) [*],
* TCH/FS, TCH/EFS, and TCH/HS.
For channel modes employing AMR codec, in particular:
* TCH/AFS, TCH/WFS, O-TCH/WFS,
* TCH/AHS, O-TCH/AHS, O-TCH/WHS,
there exist no fixed TDMA Fn subsets, but DTX is still permitted.
For those we expect at least one SACCH frame, plus a variable
number of speech frames (0 or more).
[*] Handling of data modes is fixed in a follow-up patch.
Change-Id: Ied477528d77871dd7e3b5b7b433a4e33bca40011
Related: OS#6168
It was reported that osmo-bts-sysmo is crashing due to a TCH.ind
primitive being received by l1sap_tch_ind() for an lchan, which
is operating neither in speech nor data, but in signalling mode.
It's not clear which scenario is causing this situation. My best
guess is that one or more TCH.ind primitive(s) remain waiting in
the lower layers and bob up right after the channel mode change.
This can happen, for instance, when a dynamic timeslot gets
switched from TCH/F or TCH/H to PDCH or SDCCH/8.
Change-Id: I2d270ab654fdd9d19d1708ff6c4b4e902bd5d0a3
Fixes: d1f8f3429 "l1sap: proper rate adaptation for CSD"
Closes: OS#6180
Fix OsmoBTS not restarting if e.g. an external gsmtap IP is configured
that is currently not available. Also make the service files more
consistent with other Osmocom projects.
Partial revert of ae2473c2 ("systemd: Do not restart with a broken
config file or such").
Related: SYS#6581
Change-Id: Ieeed858c159839ebaa27b2be35a597fb86874c4b
System Information Type 10 uses short L2 header that is transmitted as
Bter UI frame. The complete frame is sent by BSC, including short L2
header. Only the SACCH layer 1 header is added by the BTS.
A switch() statement is used, so other System Information with short L2
header can be added in the future.
Change-Id: Ifede42bfd84ea5914b559a20ae68f594d2ee1a5c
Do not forward any message that is received on the uplink to LAPD while
the uplink is not active. If the MS did not recognize (fast enough) that
the uplink is free, it may continue to transmit LAPD messages. A
response by LAPD to these messages is not desired and not required. If
LAPD would respond, it would cause stopping transmission of UPLINK FREE
messages. No MS could access the uplink anymore.
Note: UPLINK FREE messages are repeated automatically until a different
message is transmitted.
Related: OS#5781
Change-Id: I5075115123055b2997481f56ddf473430a1dc9e3
The RSL link is configured/set up by the BBTRANSC NM object, hence move
it to the appropiate substruct.
Related: OS#5253
Change-Id: I62937cbd81c27274b9f5f70d454d5319a6898c7b
This is a preparation commit towards delaying connection of RSL tcp
socket until the BBTRANSC object is OPSTARTed, as it is the case already
in nanoBTS.
Related: OS#5253
Change-Id: Ia571ec19e9e8f8a6d7c2554642aab0afe1b4b917
These attributes are listed in 3GPP TS 52.021, Table 2/GSM 12.21.
Many attributes are still unhandled, but at least something.
Change-Id: I94702c503fea5b42d84673ccd7065c9323b733b8
Related: OS#4505
The previous logic was wrong, since it was only reactivating the channel
if the provided BS_AG_BLKS_RES was != 1.
Example previously broken scenario:
1- osmo-bsc user sets "channel-descrption bs-ag-blks-res 2" during
osmo-bsc startup in osmo-bsc.cfg
2- osmo-bsc user uses VTY to change it to "channel-descrption
bs-ag-blks-res 1"
3- osmo-bsc user uses VTY to deploy the new config: "bts <0-255>
resend-system-information"
Step 3 would fail beforehand, ending up in a NO-OP.
Change-Id: Ibc118e11c64f04de55cb7b94d8bf2c84b431774d
Other bts models like sysmo,lc15,oc2g properly handled
rel_act_kind=LCHAN_REL_ACT_REACT under the bts_model_lchan_deactivate()
implementation, but bts-trx didn't.
As a result, when BCCH_INFO(SYSINFO_TYPE_3) coming from BSC (RSL)
containing a different BS_AG_BLKS_RES triggers CCCH re-activation,
it would only deactivate it but not re-activate it.
That means no SIs were being scheduled if bts was configured with
"channel-descrption bs-ag-blks-res 2" in osmo-bsc.cfg, and phones would
not see the cell.
Related: OS#1575
Change-Id: I61e1681fbaa2c993b529d58b581c99166b62bda3
At the moment we do not print the SAPI, nor the msg_id when we send a
confirmation back to the PCU
Change-Id: Ibd5b4225e597b69eaabaeee437fb637943a55602
elated: OS#5927
In PCUIF v.11 we use PCU_IF_SAPI_AGCH_2 exclusively. We use this SAPI
to transfer IMMEDIATE ASSIGNMENT messages for uplink and downlink. In
both cases we send a confirmation back to the PCU. For details see
coresponding patch in osmo-pcu.git (see Depends)
CAUTION: This patch breaks compatibility to current master osmo-pcu (See
also "Depends")
Related: OS#5927
Depends: osmo-pcu.git I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
Depends: osmo-ttcn3-hacks.git Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458
Change-Id: I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
The PCU now sets a confirm flag in struct gsm_pcu_if_pch in case the MAC
block (data) requires a confirmation when sent. Use this confirm flag
instead of making the decision locally based on the MAC block contents.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I3364d2268bdef9c4d2feeb8e3d51a64e34bca68c
The function bts_agch_dequeue() is not used outside of bts.c, so it can
be a static function.
Change-Id: If86293ebbd99d6550022aeb8721d40bca5fc04fc
Related: OS#5927
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Change-Id: Icf85f60ae86fbe1f3b98e1457c0598bb09cb08c5
Related: OS#5927
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Related: OS#5927
Change-Id: I779605858648e2a1c202c37e197a6e32e6ea3786
The function pcu_tx_pch_data_cnf() gets a parameter fn (frame number).
This parameter is then used to populate the member fn in
gsm_pcu_if_data_cnf_dt of the PCUIF protocol. However, the PCU only uses
this parameter for logging and nothing else. Hence it it is not needed
and we can remove it.
Related: OS#5927
Depends: osmo-pcu.git I35bc99eaec5d0287ae3916bc668f0babaddfd6ce
Change-Id: Id1c8fa77725129ec2ea7e92e1df493f35a277659
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: Ie6b34d5df64f4bed6b14581c7957dcba6af44136
The rate adaptation algorithm is the same for both transparent and
non-transparent channel modes. The only difference is that the
E-bits in the modified CSD frames carry data, like the D-bits.
Change-Id: Ib0d9346d7a8e30b8a8e4b08ee04846ba7d12b3fb
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
UPLINK ACCESS (RACH on TCH) was enabled for osmo-bts-sysmo only. Now it
is also enabled for:
* osmo-bts-lc15
* osmo-bts-oc2g
* osmo-bts-trx
* osmo-bts-virtual
Change-Id: Iae0db6bfcf6629c114436a79648e832c82835abe
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
According to TS 44.018 the UPLINK FREE message must be repeated when the
uplink is marked as free. The BSC sends the UPLINK FREE message once and
the BTS repeats it until UPLINK BUSY (uplink blocked by BSC) or
VGCS UPLINK GRANT (talker accesses the uplink) is sent.
It is important to stop sending UPLINK FREE message when a talker
accesses the uplink and before the VGCS UPLINK GRANT message is sent, so
that stopping must be controlled by the BTS.
Related: OS#5781
Change-Id: Ia23c59f5e9a73bbc384fbc317a2cfcf707e3c28f
When a VGCS/VBS call is established in a cell, NCH is used to notify
about ongoing calls to idle subscribers. Additionally Notification/FACCH
is used to notify subscribers in dedicated mode. This is performed by
broadcasting this messages to all active dedicated channels. The mobile
station can then indicate the call, so the user can join the call.
More importaint is the notification of the calling subscriber's MS,
which initiated the call. This is done on the early assigned channel.
The MS must know on which channel the call is placed. After leaving the
uplink, it must know where to access the uplink the next time.
Change-Id: I3ed14fa54a907891e492a7ada8e745a2c56cd46d
Related: OS#4851, OS#5781
Do not send notifications here. The notifications are sent on the NCH.
The NLN is used to indicate a change on the NCH, so that the MS will
read the NCH then.
If NLN is not sent towards MS, it will not read NCH to get an updated
list of ongoing calls. Also, it will not allow making VGCS/VBS calls and
might indicate that ASCI is not supported in this call. (Tested with
GPH-610R.)
Change-Id: I22e584b70fd14d8bdabb28cf5de3d4647f37425a
Related: OS#5781
Currently the rest octets contain Notification List Number (NLN) and
NLN status and the "Channel Needed" (CN3 / CN4) fields for mobile
identities.
The existing encoding of CN3 / CN4 in Paging request type 3 has been
replaced.
The missing encoding of CN3 in Paging request type 2 has been added.
Change-Id: I6e33a6d38d4c7b124de35b53d219b64bb881ba66
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
It may happen that only FACCH is available for transmission, so msg_tch
would be NULL in this case. Check it before dereferencing.
Change-Id: I0e7d5634b5223bc246badbb8e94b620c967ab121
Related: OS#1572
This tells our TTCN3 BSC tests to perform VBS/VGCS related procedures on
RSL.
Change-Id: I9ed1b20985d2ce3be31942d3e9df5cad513a0bfd
Related: OS#5778, OS#5779
Reactivation will modify parameters on an already activated channel. On
a VGCS/VBS channel it can be used to prepare channel for assignment of
the mobile station to it.
During assignment the channel is reactivated. The timing advance of the
mobile station is given. The uplink is activated and is waiting for the
mobile station to establish, to complete the assignment.
For reference see patent EP 1 858 275 A1.
Change-Id: I77f413cf70c2f5f8e8f525686eee40548521c71b
Related: OS#4851
Random access is allowed on VGCS / VBS channels to access the uplink or
to detect listeners. Uplink Access from a listener is only reported once
after activating the channel. Uplink Access from a talker is reported
each time the uplink becomes occupied. RSL TALKER/LISTENER DETECT
messages are sent to the bsc.
The VGCS UPLINK GRANT message is sent by the BTS itself. Timer T3115 is
used to repeat the message up to NY2 times until one valid frame is
received from the MS (CM service request). The UPLINK BUSY / UPLINK FREE
message must be sent by the BSC.
The uplink is released by UPLINK RELEASE message from the MS or from the
BSC. Afterwards the UPLINK FREE message causes the MS to leave the
uplink without any acknowlege. An RSL REL-REQ must be used to terminate
the link locally. (Without layer 2 DISC procedure.)
Change-Id: I1bd07ab6802341b09a06e89df356665ffaf6d2bf
Related: OS#4851
When an IMMEDIATE ASSIGNMENT MAC block (from PCUIF) is added to the
paging queue, then also an IMSI is required. The paging queue uses the
last three digits of the IMSI to calculate the paging group. In case no
IMSI is given, the MAC block is rejected. This was handeled differently
before. Even an IMSI of length 0 would still be interpreted as "000" and
not rejected. See also:
I9f3799916e8102bf1ce0f21891f2d24f43091f01
Let's restore the behaviour we had before and accept short IMSI
strings again.
Change-Id: Iab1c3f1c39dd59bb53aa74b2c9e9e135e3985e0b
Related: OS#6099
In f2c902c2 I accidentally bumped the logging level for PDCH decoding
errors to LOGL_NOTICE, making osmo-bts-trx spam the logging with
hundreds of 'Received bad data' messsages. Revert this.
Change-Id: Idb963f1a779dfa172825f6d481740cb0c4165485
Fixes: f2c902c2 "osmo-bts-trx: unify and enrich 'Received bad data' logging"
The FACCH/[FH] coding rules are specified in 3GPP TS 45.003, sections
4.2 and 4.3. The key difference is that unlike with speech channels,
FACCH does not replace data frames completely, but disturb a fixed
amount of bits fom them. This is why we need to use separate
gsm0503_tch_[fh]r_facch_{en,de}code() API for data channels.
Change-Id: I4c6736e84c271240d457998de688c0baf59fe578
Depends: libosmocore.git I0c7a9c180dcafe64e6aebe53518d3d11e1f29886
Related: OS#1572
* enlarge the maximum burst buffer size to 24 * (2 * 58) bytes;
* enlarge per-l1cs Uplink burst mask to hold up to 32 bits;
* enlarge per-l1cs Uplink meas ring buffer to 24 entries;
* add new meas modes: SCHED_MEAS_AVG_M_{S22N22,S24N22};
Change-Id: I08ffbf8e79ce76a586d61f5463890c6e72a6d9b9
Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Related: OS#1572
The goal is to unify encoding functions in tx_tch[fh]_fn(), so that
in a follow-up change adding CSD we could use a switch statement.
Change-Id: I15318e497b236128f779769e4fa99f307ea431ea
Related: OS#1572
Title refers to the maximum length of the osmo_wqueue used for
the PCU socket connection.
Related: OS#5774
Change-Id: Id6ba6e4eadce9ce82ef2407f4e28346e7fe4abfa
cm->spd_ind can take only three values defined in enum rsl_cmod_spd:
0000 0001 RSL_CMOD_SPD_SPEECH
0000 0010 RSL_CMOD_SPD_DATA
0000 0011 RSL_CMOD_SPD_SIGN
According to 3GPP TS 48.058, section 9.3.6, all other values are
reserved, so expecting RSL_CMOD_CRT_TCH_{GROUP,BCAST}_{Lm,Bm} there
is wrong. These values are part of enum rsl_cmod_crt, so the right
field would be not cm->spd_ind, but cm->chan_rt.
Let's check these channel types in a separate stage, before checking
the requested codec. Group them with VAMOS specific types for the
sake of consistency.
Change-Id: I914c84be04da819df9e60e2f5ecc5bac9b61b2e5
Fixes: 44c94fdea "validate RSL "channel rate and type" against VGCS/VBS flags"
Related: OS#4851
The RSL "Channel rate and type" field from the RSL Channel Mode IE
in RSL_CHAN_ACTIV and RSL_MODE_MODIFY_REQ messages is the only place
where the BSC differentiates between a normal TCH and the special
TCH modes used in VGCS or VBS. Let's copy this field from the RSL
message into the lchan state, so that BTS models can actually (in
subsequent patches) reflect it when activating the L1.
Change-Id: I6d531bf528bcb81f44d91336471a46ef790d7646
Related: OS#4851
We already have specfied (but not yet implemented BTS_FEAT_{VBS,VGCS}).
Let's add code to validate "channel rate and type" compatibility
in bts_supports_cm() once a BTS model would actually exhibit those
feature flags.
Change-Id: I5e7f65b44cef6e2f7ad4f152f80a1686a4f511e3
Related: OS#4851
This adds very minimalistic support for notification of VBS/VGCS calls.
Minimalistic in that we
* only notify via PCH (not via NCH or FACCH)
* only include notification in otherwise empty PAGING TYPE 1
This means that notification will cease to work once the PCH becomes too
loaded and we never would send otherwise empty PAGING TYPE 1 anymore.
Change-Id: I6f6f72d9a0123cb519b341d72a124aaa2117370e
Requires: libosmocore.git I9586b5cb8514010d9358fcfc97c3d34741294522
Related: OS#5781
As we subsequently add ASCI related features to the code, it makes
sense to have a specific log sub-system for it.
Change-Id: I8ea3e61df35175bd74110b2f41994c99da3e2858
Related: OS#4851
The NLN + NLN-Status are optional parts of P1 rest octets; they can
be used to support the "Reduced NCH monitoring mechanism" as described
in Section 3.3.3.3 of TS 48.018.
The patch just adds encoder capability but doesn't yet make use of it.
Change-Id: I961842c3fec151e149f72a4f36279ce4b979795e
Related: OS#5781
OsmoBTS still uses the deprecated version 10 of the PCUIF protocol.
OsmoPCU is still compatible to version 10, but to maintain a clean
interface it is planned to drop the support for version 10 in the near
future.
Moving to PCUIF v.11 essentially means using the "Direct TLLI" method to
convey IMMEDIATE ASSIGNMENT and also PAGING COMMAND messages through the
PCU socket. This means in particular that we use a TLLI as an identifier
to confirm IMMEDIATE ASSIGNMENT messages towards the PCU (PAGING COMMAND
is not confirmed at all). Also we now use struct gsm_pcu_if_pch_dt to
parse the incoming PCU_IF_SAPI_PCH_DT, which is much cleaner than using
offsets in a buffer.
Change-Id: I25816ac12e63cc6b641eb414e6bc7eaa9c85fc25
Depends: osmo-ttcn3-hacks.git I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
Depends: docker-playground.git Ia28bc0d6d3cbfe63be19443db86631fb67bb80fb
Related: OS#5927
The payload size for some CSD channel types is bigger than what an
uint8_t can represent, for instance 290 bytes for TCH/F14.4.
Change-Id: Id75c55509a017d14dfab2a7b4c67e0742125a113
Related: OS#1572
This commit aims to make the argument naming/ordering more consistent:
* rename l2/l2_len and tch/tch_len to data/data_len;
* common arguments first (consistent ordering), specific last.
Change-Id: I3d8c90b82f2a55b0c5c2d6b4efb8fd962508534d
Related: OS#1572
The default of 10 messages introduced recently is too small, specially
when using osmo-bts-trx, where clock drifting and CPU scheduling can
cause skewing and hence generation of 2-3 FNs (* up to 8 TS) at once,
hence filling the PCUIF queue with more than 10 messages in a given
moment.
Fixes: c938a95e25
Change-Id: I7ababfc6cdf20196889fb542a8040128b3c118b5
Fixes memleak in case of connected PCU process being suspended without proper close on socket
Related: OS#5774
Change-Id: Ia6e61dda4b3cd4bba76e6acb7771d70335062fe1
With this change the application of ECU in the uplink path becomes
consistent across all OsmoBTS models, enabled or disabled per vty
config setting "rtp internal-uplink-ecu". An additional behavioral
change from the previous trx-model-only implementation is that ECU
insertion is now done after the link quality check in l1sap, thereby
fixing the bug where this quality check would sometimes suppress
ECU output and replace it with BFI markers in RTP.
In the new implementation when the internal ECU is enabled and
available for the selected codec (currently FRv1 only), the RTP output
will gap (standard representation of BFI in RTP) only during DTXu
pauses as indicated by a received SID frame (either valid or invalid),
and the SID frame that triggers the switch from ECU mode into pause
mode is reliably emitted in RTP.
Related: OS#6040
Depends: I3857be84bba12aaca0c2cca91458b7e13c5a642a (libosmocore)
Change-Id: Iac577975c9ab50cb8ebbc035c661c1880e7cecec
In preparation for moving the now-optional application of ECU in UL
path from osmo-bts-trx model-specific code to the common layer,
move ECU state allocation and freeing from trx model to l1sap.
Related: OS#6040
Change-Id: Ic98a2eb26b5a99bc4a89ad07ae87c9a86b921418
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
Connecting to OML and PHY is done in parallel. The PHY connection will
always be done first, mute PHY until OML is also ready.
As Pau suggested, move dispatch of NM_EV_SW_ACT to a callback of
trx_rf_lock to have the events serialized and therefore deterministic.
Fixes: SYS#6496
Change-Id: Ia1769f952fa787202a442a33db5ed4a1f7cbe9c3
Do not dispatch NM_EV_SW_ACT to trx->mo.fi and trx->bb_transc.mo.fi when
RF-ACT.conf was not successful. Running this code path anyway looks like
a leftover from when bts_shutdown used to exit osmo-bts.
Change-Id: I342187604f4c72303e393ce6925b94d610bfa8fa
Keep the l1sap specific wrapper because we still want to assert().
Change-Id: I7097ba87f42689d2336014da9173cadbdaa9fdab
Depends: libosmocore.git I8cbd31226754e95887358ed83a928e2f567f4cf3
Run bts_update_status in trx_mute_on_init_cb like in the default
callback mute_rf_compl_cb.
Related: SYS#6496
Change-Id: Ib73a33a82fbb86ead3569a6bb22fb001c55354d4
The function signature of rtppayload_is_octet_aligned has a parameter
rtp_pl for the payload and a parameter payload_len for the length of the
payload, while other functions use rtp_pl and rtp_pl_len.
Change-Id: I8a0e0357aab2a78e25811f66b1b870e8c6ebffe9
when osmo-bts receives a MAC block from osmo-pcu through the PCUIF it
puts it in the review queue without further interpreting it. This also
means that it will send confirmations to the PCU for IMMEDIATE
ASSIGNMENT and PAGING COMMAND. This is not entirely correct because only
IMMEDIATE ASSIGNMENT messages should be confirmed. osmo-pcu has no
problem with this since it silently drops the confirmations for PAGING
COMMAND messages. This peculiarity of the PCUIF implementation makes the
confirmation logic hard to understand, so let's add some logic to
osmo-bts that makes sure that only IMMEDIATE ASSIGNMENT messages are
confirmed.
Related: OS#5927
Change-Id: I8b8264d28b1b1deb08774cdba58dd4c6dafe115d
The function paging_add_macblock takes a data and length parameter. The
first three byte of that string are the last three digits of the IMSI
from which the paging group is calculated.
As the layout of this data buffer is a property of the PCUIF interface
API, we should do this separation outside of paging.c. Also we should
supply the IMSI as a valid null terminated string since PCUIF v.11 also
uses this format.
Change-Id: I9f3799916e8102bf1ce0f21891f2d24f43091f01
Related: OS#5927
In all Uplink lchan handlers we do memset() the Rx burst buffer on
bid=0 and there is no need to do that again for NOPE.ind.
Change-Id: Ia6803b8606d86bd2d011fe21f7a540d2115aa654
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
In speech TCH operation, there will always be times when a speech frame
needs to be transmitted on the downlink, but there is no frame available
to transmit (gap in the incoming RTP stream), or the logic of DTXd says
that no frame shall be transmitted at this FN, but we are not doing
physical DTXd. Previous osmo-bts-trx code sent dummy FACCH during such
conditions, but this approach is bad for TCH/HS where we would like to
transmit good speech frames or speech frame gaps one 20 ms frame at a
time, rather than take out pairs of frames for dummy FACCH/H. Other
BTS models (sysmoBTS PHY) send out invalid speech blocks with inverted
CRC3 under the conditions in question - do the same in osmo-bts-trx.
The present change modifies osmo-bts-trx TCH DL frame gap behavior
only for TCH/FS, TCH/HS and TCH/EFS; for all other channel modes,
including AMR speech, the previous behavior of sending dummy FACCH
is left unchanged.
Depends: Iade3310e16b906efb6892d28f474a0d15204e861 (libosmocore)
Change-Id: I78106802a0aa4af39859c75d29fe0e77037899fe
Suppose we receive RTP from the uplink of another BTS, and the
UL-handling BTS has channel-decoded an HR1 frame which it deems
(per GSM 06.41 section 6.1.1) to be a valid SID, even though it is
not a perfect, error-free SID. How will this SID frame be
represented in RFC 5993 transport? My reading of the RFC tells me
that the UL-handling BTS will need to apply an operation like our
osmo_hr_sid_reset() to the payload before sending it out in RTP -
but because the text of the RFC does not explicitly address this
scenario, others may have interpreted it differently.
If we receive an RFC 5993 RTP payload in which FT is set to 2,
indicating good SID, but the actual HR payload is not a perfect SID
(the SID field is not all 1s), the only reasonable interpretation
of such occurrence is that the sender of this payload was another
BTS whose implementors interpreted the RFC as not requiring them
to rejuvenate the SID codeword prior to RTP output. Therefore, let's
treat such payloads as valid SID for our DTXd logic, and rejuvenate
the SID codeword ourselves.
Change-Id: Ife00de6220a8ca7cc180a61734497f1acb7f5b83
osmo-bts-trx always accepted (and previously required) HR1 codec RTP
input in RFC 5993 format; currently we accept this RTP format as
input for all BTS models, but no longer require it. However, we
have never applied any checks to this format's ToC header, even
when we previously required it in osmo-bts-trx. Check this header
and reject invalid payloads that just happen to have the same octet
length as valid ones.
Change-Id: If16d38641913bb46bcd7cc11685407ed17136bfe
GSM 06.31, 06.41 and 06.81 are the respective DTX specs for FR, HR
and EFR. In each of these specs, section 5.1.2 specifies the
expected shape of radio downlink in the presence of SIDs: one SID
frame after each talkspurt (after speech frames), and one SID frame
in every SACCH-aligned position every 480 ms (every 240 ms for HR),
or if the actual SACCH-aligned position is taken up by FACCH,
then just one SID frame as soon as possible after that FACCH -
and no transmitted SID frames in other positions.
This just-referenced spec section was written with the assumption
that it will only be applied when DTXd is enabled - however, if
the RTP stream for call leg B DL comes from call leg A UL (TrFO),
then we are going to receive SID frames in the stream intended for
our DL even when DTXd is disabled or not supported altogether.
The easiest solution is to apply FR/HR/EFR DTXd logic whenever
the incoming RTP stream contains SID frames, irrespective of physical
DTXd enable/disable state. If we apply such "logical DTXd" when
physical DTXd is disabled, the BTS model PHY will end up transmitting
induced BFIs (dummy FACCH or inverted CRC3) in those frame positions
where the "logical DTXd" function says "please transmit nothing".
The point remains, however, that the prescribed SID shape on the
radio downlink (expected positions of SID frames) won't happen on its
own: in the case of TrFO, whichever SID frames are present will be
in wrong positions for leg B DL, and even in the case of transcoded
calls the responsibility for DL SID shaping cannot be placed on the
RTP stream source because that source won't know where SACCH alignment
will lie. Therefore, the necessary DL SID reshaping has to be done
in the RTP stream receiver in OsmoBTS.
Related: OS#5996
Change-Id: I924ab21952dcf8bb03ba7ccef790474bf66fc9e5
There is no more need to access the UL/DL buffers via pointer to pointer
thanks to the previous patch [1] moving the memory management routines
out of the logical channel specific Rx/Tx handlers.
Change-Id: Ib1e8e86ac60a7ac9b0415ef66b609eaa33443c19
Related: [1] c45e03726af8a2b46b7166b3c47bc666ba933a69
It's a lot cleaner if the Rx/Tx burst buffers are allocated and free()d
in one place rather than in each lchan handler individually. Allocate
the buffer(s) during the lchan activation, free() on deactivation.
Regardless of lchan type, allocate the maximim size of 4 * (3 * 2 * 58)
bytes, which is sufficient to store 4 8PSK modulated bursts. This way
we reduce the load on the memory allocator at the cost of memory
consumption, what should not be a big problem.
Change-Id: I6a5f76023fc492786076a63016f81285b3576c33
Depends: libosmocore.git I1c38ccc2b64ba9046bb3b1221d99cc55ec493802
Related: OS#1572
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
As a preliminary step before making the RTP output format from
OsmoBTS configurable with a vty option, we need to make the internal
format consistent across all models. The "natural" output from a
"pure" GSM 05.03 channel decoder is TS 101 318, which is also the
output format of all currently supported proprietary PHYs - adopt
it as our internal format.
Related: OS#5688
Depends: I6e75ca95409b5c368e8e04d0e0aba41e0331d9e6 (libosmocore)
Change-Id: I41bce6226964975cb85aea89e4c0f9e11e4929b8
As of commit 1160cabefb, the common layer of osmo-bts accepts both
TS 101 318 and RFC 5993 formats for HR1 codec, and always passes
the more basic TS 101 318 format to the BTS model. Unfortunately,
osmo-bts-trx has model-specific code checking the payload length
that was overlooked in that patch, causing breakage. Fix that bug.
(The actual channel encoding function in libosmocoding already
accepts 14-byte payloads.)
Related: OS#5688
Fixes: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Change-Id: I0e251faeffb76d2604a4100c848141d239d1d86f
There exist two different RTP encoding formats for HR1 codec: one
"simple" format defined in ETSI TS 101 318, and an extended format
(adding a ToC octet) defined in IETF RFC 5993. Following the
liberal-accept clause of Postel's law, we would like to accept
both formats. Implement this feature by first converting all HR1
RTP inputs to the more basic TS 101 318 format at the point of
input preening, and then consistently using this basic format
internally.
Related: OS#5688
Depends: I13eaad366f9f68615b9e9e4a5f87396a0e9dea0f (libosmocore)
Change-Id: I702e26c3ad5b9d8347e73c6cd23efa38a3a3407e
Up until now, our approach to validating incoming RTP payloads and
dropping invalid ones has been to apply the preening function inside
l1sap_tch_rts_ind(), at the point of dequeueing from the DL input queue.
However, there are some RTP formats where we need to strip one byte
of header from the payload before passing the rest to our innards:
there is RFC 5993 for HR codec, and there also exists a non-standard
extension (rtp_traulike) that does a similar deal for FR and EFR.
Because of alignment issues, it will be more efficient (avoids memmove)
if we can do this header octet stripping before we copy the payload
into msgb - but doing so requires that we move this preening logic
to the point of RTP input before enqueueing. Make this change.
Related: OS#5688
Change-Id: I7fc99aeecba8303b56d397b8952de5eea82b301e
As detailed in OS#6033, osmo-bts-trx was emitting its own invented
packet formats to signal BFIs (bad frame indications), different
from the vty-configured ("rtp continuous-streaming" or not) BFI
signaling method implemented in l1sap and used by all other BTS models.
In the case of EFR codec, the made-up BFI format previously used by
osmo-bts-trx caused EFR operation to be broken: a spec-compliant EFR
decoder on the receiving end of the RTP stream (a network transcoder
or the MS on the other GSM call leg) would receive and decode garbage
EFR frames of 244 zero bits instead of invoking the spec-defined bad
frame handler, causing bad audio artifacts for the user. The same
situation would also happen for FR1 codec, but the application of
ECU masked this bug: with the ECU invoked in the UL output path,
the BFI emitting code for FR1 never executed.
In the case of AMR and HR1 codecs, the model-specific BFI packet
format of osmo-bts-trx is currently harmless, but:
* The extra code adds unnecessary complexity;
* BFI packet formats are inconsistent between osmo-bts-trx and
other OsmoBTS models;
* BFI format is even inconsistent within osmo-bts-trx itself, as
under certain conditions the common code in l1sap will override
the UL payload from the BTS model and emit its own form of BFI
instead.
Fix all of the above by removing trx model-specific BFI formats
for all codecs, and let l1sap handle all BFIs.
Related: OS#6033
Change-Id: I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
The paging interface towards the PCU has a confusing API. In fact what
the PCU does when it wants to page or do an immediate assignment is
sending a ready formatted MAC block to the BTS. The BTS then puts this
MAC block in the paging queue and then eventually it justs sends it
without looking at the contents. For the code in paging.c it is not
imortant if the MAC block is an immediate assignment, it only cares if
the paging record contains a MAC block or paging parameters.
Related: OS#5927
Change-Id: Ifab37fdedaba98b160718113767e4ef6ee7d16ad
In all OsmoBTS models in FR and EFR speech modes, as the UL traffic
frame stream is passed from the PHY to l1sap and ultimately to RTP
output, all passed frames are checked for SID. The Boolean result
of this SID check is used in two ways:
* RFC 3551 instructs that the Marker bit in the RTP header SHOULD be
set in the first packet of a talkspurt after a period of silence
suppression. OsmoBTS implements this recommendation by setting
the Marker bit in the first RTP-transmitted non-SID UL packet
that was preceded by SID.
* In osmo-bts-trx only, this same SID check serves a second purpose:
handling of BFI conditions depends on whether or not the last received
good traffic frame was a SID. If a BFI condition is received after
a non-SID traffic frame, the ECU is invoked, and if this ECU fails
or when libosmocodec does not provide an ECU for the codec in use,
a special FR (EFR) BFI frame of 260 (244) zero bits is emitted.
Both the ECU call and the peculiar form of BFI are skipped when the
last received good traffic frame was a SID.
For both of the above purposes, in all BTS models, change the SID check
from osmo_{fr,efr}_check_sid() to osmo_{fr,efr}_is_any_sid(). The
effect of this change is that "what counts as a SID" for the just-listed
purposes changes from recognizing only perfectly uncorrupted SID frames
without any bit errors to recognizing all frames which the rules of
GSM 06.31 (FR) or 06.81 (EFR) classify as either valid or invalid SID.
Change-Id: I5c24b379deda8ae551f9924d10770da50e6acbbd
Commit 32682c63f6 fixed EFR SID handling in osmo-bts-sysmo,
but that fix was never propagated into osmo-bts-{lc15,oc2g} versions,
which are essentially copies of osmo-bts-sysmo. Fix that oversight.
Change-Id: I509c1ea374e640d819952d58592b12fa884ad9d8
Those network elements which receive a stream of codec frames that
may come from the uplink of GSM call A and which are responsible
for preparing the frame stream for the downlink of GSM call B
(such as OsmoBTS receiving RTP and feeding DL to its PHY) must be
prepared for the possibility that their incoming frame stream may
contain corrupted SID frames, presumably from bit errors on radio
link A. Per the rules of section 6.1.1 of GSM 06.31 for FR and
GSM 06.81 for EFR, SID frames with just one errored bit are still
to be accepted as valid, whereas frames with more corrupted bits
which are still recognizable as SID are classified as invalid SID.
In the case of a TrFO call, the entity switching from leg A UL to
leg B DL is responsible for *not* transmitting invalid SID frames
on the destination leg (they should be treated like BFIs), and any
deemed-valid SID frames that are forwarded should be preened,
correcting that one bit error they may exhibit. Implement this
functionality in OsmoBTS.
Change-Id: I89df2f12c49dd5378667cf149d19bde654f80134
When the NM_EV_RX_OPSTART event is received, it will call bts model
specific function bts_model_opstart(), which is responisble for
answering back with NM_EV_OPSTART_ACK or NM_EV_OPSTART_NACK.
Since that answer could be done sequentially in same callback code path,
we could end up twice at the end of the st_op_disabled_offline()
function checking for statechg (due to reentring that function).
As a result, one can see the following message appear during OML
bring up:
nm_bb_transc_fsm.c:185 NM_BBTRANSC_OP(bts0-trx0){ENABLED}: transition to state ENABLED not permitted!
Fix the issue by avoiding ending up at the end of the function in code
paths which should not be triggering any change.
The case of bbtransc is a bit different than that of rcarrier for
NM_EV_RX_SETATTR, since the former really doesn't receive any such
message from the BSC yet, so if we checked for that one before
continuing, it would never go on.
Change-Id: I5184a33dd8da9244e8aacf3ab8bb8930f732a136
The info indication on pcu_sock cann only support a limited but
sufficient number of TRXs, when we detect that we overflow the maxiumum
number of TRXs, then break and do not continue.
(this is more or less a cosmetic problem)
Change-Id: If4d7eecaded22f86750283f7aa13072064724537
The function rtppayload_is_valid() is called from the receiving RTP code
path. Lets use the word "forwarding" instead of "sending" to avoid the
impression something is sent (like sending RTP packets to the outside
world)
Change-Id: Ie7fcc53dea462b0d575b0c9ca73ba7507289eefe
This code has been there since first octphy support was added.
New gcc 13.1.1 is catching this and reporting compilation errors:
"""
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘ts_connect_as’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1518:60: note: ‘oc’ was declared here
1518 | tOCTVC1_GSM_MSG_TRX_ACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c: In function ‘bts_model_ts_disconnect’:
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: error: ‘oc’ is used uninitialized [-Werror=uninitialized]
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
/osmo-bts/src/osmo-bts-octphy/l1_oml.c:1803:62: note: ‘oc’ was declared here
1803 | tOCTVC1_GSM_MSG_TRX_DEACTIVATE_PHYSICAL_CHANNEL_CMD *oc =
| ^~
"""
Change-Id: I0da7d3a94e9eba15b8d3d3d995bba532170d9df7
osmo-bts-trx uses the RFC5993 RTP payload format, so when handling the
RTP payload use GSM_HR_BYTES_RTP_RFC5993, instead of GSM_HR_BYTES + 1
Depends: libosmocore.git I125ef9cdab98c073971841c175b1a7dcd927f9c2
Related: OS#5688
Change-Id: I54dd3adab88e2262913f7b1e89340a0246c88a8a
We should not maintain BCCH carrier power reduction mode if we loose
connection to the BSC. When entering NM_BTS_ST_OP_DISABLED_OFFLINE,
reset the related state fields if it was enabled.
Change-Id: I34468e3fccc490f48e30b159b63308a395b65fa9
Related: SYS#6435
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (fixes OS#5967
together with change I37e6b23ed95260a8188910cf9754faffcba519c5)
Change-Id: If734ea2c8cae4c1f99b02520dffa4e3862a67745
Related: OS#5961, OS#5967
- Add out-parameter to enable returning a NACK cause (ignored if NULL)
- Return appropriate NACK cause if TRX number is unknown (part of fix
for OS#5967)
Change-Id: I37e6b23ed95260a8188910cf9754faffcba519c5
Related: OS#5961, OS#5967
The following output can be seen when doing 'show bts' in the VTY:
BTS model specific (internal) flags:
001 Measurement and Payload data combined
003 unknown 0x8
Fix this by adding the missing values to the value-string array.
Change-Id: I83e5065f9f80b4f81e9767f184c8dc027883025a
Fixes: 0277cddab "sysmo,oc2g,lc15: Make RadioChannel MO depend on RadioCarrier MO"
Fixes: ee5eb6169 "l1sap: check if BTS model supports interference reporting"
In change 8e04613e I overlooked that osmo-bts-virtual is re-using the
scheduler of osmo-bts-trx and forgot to update its OML logic. As a
result, osmo-bts-virtual is broken and does not transmit anything on
the broadcast channels.
Change-Id: I2276f7e5e4042e56ddf1fd1642c917dba0005ac4
Fixes: 8e04613e "osmo-bts-trx: properly activate [CBCH/]BCCH/CCCH"
Related: OS#6001, OS#1572
Better wait until the DSP is reset and all the information is retrieved
before telling upper layers that the phy is ready. Keep it in CONNECTING
state meanwhile.
Change-Id: Ifdc791336fb8efd42f4428893f687093085af129
The fields used to fill in pinst->version are set when info_compl_cb()
is called, which happens asynchronously and hence later than when in
bts_model_phy_link_open().
Hence, copying the values when in bts_model_phy_link_open()
(l1if_open()) makes no sense at all.
Fill in pinst->version in info_compl_cb(), just when the layer receives
the required information.
Related: OS#5978
Change-Id: Ica53a5d852214b24de7f75b08ad7e595ce5236ee
If the TRX_NR had no matching TRX it would access a NULL pointer trx
after failing to resolve it.
This commit refactors the code path to only require the trx pointer at
the very end, and NACKs the message if TRX fails to be resolved.
Change-Id: If27639ae1727fc5232e1a964a1b29f50c8805d80
All the other objects already use that one; there's no need to have a
specific one for the NM Channel FSM.
Change-Id: Ic5fd37367b500c75a0a53b1d868ba2aed3edef1b
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
As it has come up during code review of Change-ID
I214af0448652a9f321ccbab77977b67663ba28f9 introducing LOGPLCNF, my
approach to the strict preserval of argument order (lchan first from
LOGPLCHAN and fn *after* loglevel from LOGPFN) was considered
sub-optimal.
I used the following spatch rule to clean this up:
@@
expression lc, ss, logl, fn;
expression list trailer;
@@
-LOGPLCFN(lc, ss, logl, fn, trailer);
+LOGPLCFN(lc, fn, ss, logl, trailer);
Change-Id: Iba4a8416545673d03cb057e4855f8b1ecae3e1ec
Add the BTS object to the BTS list as the first thing after it is created,
this way it's always attached and hence simply always detach it during
object free.
Change-Id: Ica4fe2a4be0c85b10702011e978be03bf970b0c8
Move it together with the other similar objects like gprs_nse and
gprs_cell.
Move the "mo" field to the start of the struct, similar to the other
types.
Change-Id: I5dc020a6bab8c94ab831b6ca506bc5cb681d07a3
Octet 2 should contain the address of the GPRS cell in the GPRS NSE
object. Since there's 1 GPRS Cell per BTS and we have only 1 BTS in
osmo-bts, then this address should be 0.
Otherwise, osmo-bts answers sometimes using (0x00, 0xff,0xff) instead of
requested (0x00, 0x00, 0xff), for instance when ACKing an Admin Unlock.
This is kinda still fine since value 0xff has the meaning of "all"
addresses, and that means the only one available.
Still, it's not the proper way to identify the object, so this patch
fixes it.
Change-Id: I2ea05778f5b5ac335c75f3958324664553da7f0d
This way we have further control on how to handle the OPSTART messages
received. For instance, NACK them if the NM object FSMs are not at the
expected correct state.
Related: OS#5992
Change-Id: I5df0bfb4cc812c11c7a00a8ffa882ae1915d562f
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
We have LOGPLCHAN and LOGPGT, but not a combined version for logging
both the lchan and the gsm_time. Let's resolve this.
Log messages without indicating the lchan name are pretty useless if you
have multiple concurrently active lchans...
Change-Id: I4bf3363f92acdf67d8e7333e30ac2209e31cb287
This way we have further control on how to handle the SetAttr meessages
received. For instance, NACK them if the NM object FSMs are not at the expected
correct state.
The originating msgs are now kept owned and freed by the OML layer
(oml.c), and the NM FSMs only uses them and create new OML msgb when
answering with ACK/NACK.
Related: OS#5992
Change-Id: Id68868e25bbf96227ab6459fcd3c9181852ed28e
Calls to bts_model_apply_oml() are done only for BTS, RCARRIER and
RCHANNEL NM Objects in their respective Rx code paths (and they will
be moved to respective FSMs in follow up patches). This function is
never called with any of the GPRS NM objects.
These NM Objectes have the NM_MT_IPACC_SET_ATTR msg ACKED/NACKED in its
own path:
oml_ipa_set_attr()
rc = oml_ipa_mo_set_attr()
return oml_fom_ack_nack(msg, rc);
Change-Id: I1a0d38a122f50ffe749ebc4f1cc11235ca516586
The function repeat_last_sid() is implemented in the common part,
but is only used by osmo-bts-{lc15,oc2g,sysmo} models. These BTS
models call this function when they are looking to see if a
previously cached SID frame needs to retransmitted on the DL
because it is that time according to the SACCH multiframe.
Out of non-AMR codecs, this function previously supported only
FR1 and HR1, but failed to support EFR. Fix that omission.
Change-Id: Iebcd28e65af889254740757eed9c579392eb1c33
Automatic generation of a header file using a C program built during
build of osmo-bts creates several problems when cross-compiling.
The generated header file is only 59 lines long, so let's have it
generated in order to avoid having to call the helper program every
time.
A Makefile target is added to easily regenerate the file manually in
case it's needed:
make -C contrib/ber/ update_codec_bit_class_h
Fixes: acf0f0f0bb
Change-Id: I97efdb4ee00537fcae191b4267d0211d582ef372
There was a surprising number of explicit gsm_lchan_name() calls
from within log message code. Let's avoid that whenever possible and
use a LOGPLCHAN() or related macro.
Change-Id: If4f4f555f5ca61dfa624b298805f5375efc0b137
When FACCH stealing occurs and sysmoBTS L1 delivers GsmL1_Sapi_FacchF
instead of GsmL1_Sapi_TchF, that 20 ms unit still needs to be
accounted for in the RTP timestamp cadence, and if we run with
rtp continuous-streaming enabled, then an actual BFI packet needs
to be emitted. The original code failed to do either; the present
change implements correct behavior for TCH/F.
The present patch only covers the case of TCH/F; handling of TCH/H
is left as a FIXME for other/later developers.
Related: OS#5974
Change-Id: I39d15faade28fb7d670493a99a0e0bdb654e2a4a
The check for (tch_ind->lqual_cb >= bts->min_qual_norm) in
l1sap_tch_ind() has the intent of suppressing valid-seeming
speech frame output from lower layers when the link quality is
too low; this check is particularly important for FR1 codec
where the intrinsic validity check is only a 3-bit CRC which has
1/8 probability of indicating "correct" when decoding radio noise
during DTXu silence.
However, this check is effectively defeated in the current
implementation of rtp continuous-streaming: the RTP packet being
output is the presumed-bogus speech frame from lower layers,
rather than the intended zero-length payload. Fix this bug.
Related: OS#5975
Change-Id: Icee0f57be289a0592a0197469432a012d15f224c
This implements RTP based GSM BER testing for osmo-bts, implementing
ideas described in https://osmocom.org/projects/osmobts/wiki/BER_Testing
In short: The command transmits a PRBS sequence encapsulated in RTP
frames, which are sent to the BTS, which transmits that data in the
(unimpaired) downlink. The mobile station receives the data and is
instructed to loop it back in the (possibly impaired) uplink. The BTS
receives that uplink, puts in in RTP frames which end up being received
back by this very tool. By correlating the received RTP with the PRBS
sequence, this tool can compute the BER (Bit Error Rate) of the
(possibly impaired) uplink. Doing this with different RF channel model
simulators in the uplink allows to establish BER at different levels and
channel conditions.
Original code by Sylvain Munaut extended with some comments and Automake
integration by Harald Welte.
Change-Id: I1cffa0ae959e29ec61775b13185fd1057ed7485a
oml.c: In function ‘bts_model_apply_oml’:
oml.c:1814:17: error: variable ‘cell_size’ set but not used [-Werror=unused-but-set-variable]
1814 | uint8_t cell_size;
| ^~~~~~~~~
Change-Id: I0bf1542f613f613d03609d50836137ff440401af
This default phase of the Codec Mode Indication in downlink direction is
called "odd", which is defined by starting with CMC in every 26
multiframe.
At call set-up, after every successful handover and after a channel mode
modify, the default phase (odd) shall be used in downlink direction.
During a call, the phase of Codec Mode Indication may be changed in
downlink by using a RATSCCH message.
As we don't implement RATSCCH, odd is always correct.
Change-Id: Ia64767fbfdc3fb067d72dbf5eabb1d84e3868ce5
oml.c: In function ‘bts_model_opstart’:
oml.c:1883:32: warning: variable ‘ts’ set but not used [-Wunused-but-set-variable]
1883 | struct gsm_bts_trx_ts *ts;
| ^~
Change-Id: Ifd5552f2dd56f4f9bf4c17d25b741f694f4f2168
l1_if.c: In function ‘activate_rf_compl_cb’:
l1_if.c:1280:17: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
1280 | if (bts_lc15->led_ctrl_mode == LC15_LED_CONTROL_BTS)
| ^~
In file included from ../../include/osmo-bts/dtx_dl_amr_fsm.h:3,
from ../../include/osmo-bts/msg_utils.h:8,
from l1_if.c:55:
l1_if.c:1282:25: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
1282 | osmo_fsm_inst_dispatch(trx->mo.fi, NM_EV_DISABLE, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~
Change-Id: I00ae3faf0f85fecf6e15e71dff071165725e547c
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
Handling of SID in EFR mode was broken in osmo-bts-sysmo.
l1_to_rtppayload_efr(), the function for UL Rx, was using completely
bogus logic (passing bits in ETSI TS 101 318 EFR format to an AMR
decoding function), whereas l1if_tch_encode(), the function for
DL Tx, had missing SID logic for EFR while supporting SID detection
for all other codecs. The fix is to use the new osmo_efr_check_sid()
function in libosmocodec.
Change-Id: Ia56c1bb7432968685110456961d24a907b0a201f
The TCH/F Rx code in osmo-bts-trx uses osmo_fr_check_sid() to detect
when the MS sends SID, and passes the flag to lchan_set_marker().
However, equivalent logic was missing for EFR, as until recently
there was no EFR SID check function in libosmocodec. Now that
we have osmo_efr_check_sid(), use it.
Change-Id: Ib043e00dbf92145c2a6c32f6365517244472a922
So far we only printed it during later modification. Let's print
it also during initial activation of a logical channel.
Change-Id: I6982a52905e4719e2e9c40630252ffef2ff9fbed
When we receive a SID_FIRST_P1 frame from the PHY (during AMR/HR DTXu),
we must generate a SID frame on the RTP side.
The existing code
* ignored that the Amr_SidFirstP1 PHYIF message actually contains the
RTP payload
* manually generated the same content using osmo_amr_rtp_enc()
* forgot to prefix that with the AMR CMR+TOC
* in the end, sent a completely broken (too short) AMR SID frame over RTP
Let's fix this by simply using the 7-byte RTP payload with CMR+TOC that
the PHY is providing to us.
Change-Id: I90479efcc002d497648a71e73847af54e6208358
Related: OS#5944
So far, we've had LOGPLCHAN() and LOGPFN(). This resulted in a number
of log lines containing frame numbers *not* containing the lchan
context, which makes it difficult to deterine which of potentially many
concurrently active lchans is logging.
Let's introduce LOGPLCFN() for a FN-extended version of LOGPLCHAN(),
and convert all callers that have the related context.
Change-Id: I214af0448652a9f321ccbab77977b67663ba28f9
We're printing DEBUG messages for all other DTX frames, but not for
ONSET. This made me think that we never received any ONSET frames
when looking at log output.
Let's add ONSET for completeness.
Related: OS#5944
Change-Id: I9a1511d9929444cef96388492d907e8f3a082311
ph_tch_req() is a recursive function and conditionally calls itself at
the very bottom. The recursive call happens iff all of the following
conditions are met:
* DTXd is enabled,
* AMR codec is in use,
* DTX DL AMR FSM state is recursive.
The problem is that ph_tch_req() may pull sizeof(*lsap) from the given
msgb twice: during the initial and the recursive calls. The second
attempt to pull sizeof(*lsap) causes the process to abort, because
the remaining room is less than it's attempting to pull.
AFAICT, doing msgb_pull() is not really necessary, given that
l1sap_tch_rts_ind() thankfully does set msg->l2h before pushing
the lsap header in front of the actual frame.
Update osmo-bts-sysmo and its copy-pasted siblings, which are likely
affected too, except osmo-bts-octphy which does not do the recursion.
Change-Id: Ib349b74a9e4bd48c902286f872d3b0e9a068256c
Related: OS#5925
It makes no sense to push interference meas results for those TRX since
they are disabled, unused and hence won't be reported in RSL RF Res Ind.
Related: SYS#6370
Change-Id: Ie3fd80970585cb30808b0644568dbc8936a57721
The timeslot carrying BCCH/CCCH on C0 is a bit special in a way that
it's being activated implicitly - there is no explicit RSL CHANnel
ACTIVation for that. This is why we have TRX_CHAN_FLAG_AUTO_ACTIVE,
which marks sub-channels of BCCH/CCCH in the trx_chan_desc[].
The upcoming patch changes the burst buffer allocation strategy, so
that the memory is allocated on channel activation and then free()d
on channel release. This patch facilitates that by making the
activation/deactivation logic consistent for all sub-channels.
Change-Id: Id0c70d6a2b777a5117c85149bfa1b3a997299d1d
Related: OS#1572
The header file <osmocom/gprs/protocol/gsm_04_60.h> was recently
deprecated and moved to <osmocom/gsm/protocol/gsm_44_060.h>, so
it's now part of libosmogsn and depending libosmogb is not needed.
Change-Id: I823de7ebac2fe5dfddb88d533f1a9419f4a605db
Related: libosmocore.git I70cc21bf25a7081070738abacb409ed19094c3b2
Related: OS#5312
This change fixes a problem that prevents osmo-bts-virtual from
starting when dynamic (ipa/osmo) timeslots are in use.
Change-Id: I5db5b7dd6a8e84cf9a0d84f04a650c2ed8a4e368
The code in that function is pretty rotten:
* osmo_fd_write_disable() is called for each message in the queue,
there's no need for that. Let's simply call it at the end if the queue
is empty.
* Asserting for obvious stuff like dequeue returning the first entry in
the list.
* Having error code path for empty message: That shouldn't happen, abort
immediately.
With all thse changes, the function is way simpler, easy to read and
more efficient.
Change-Id: I7ffff98cd8cdf2041bff486c3fde6f16365028d5
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
These two messages indicate that no ACK/NACK message is going to be
sent to the BSC because activation/deactivation was requested by the
PCU. This is absolutely normal and requires no attention from the
user/operator, so better use LOGL_INFO.
Change-Id: I6eaf3a6c07fb30b31c045729c935c8ad6735e5c8
Parse the RTP CSD Format and reply with NACK if the mode is not
RSL_IPAC_RTP_CSD_TRAU_BTS, which is the only one we plan to implement
for now.
Related: OS#4393
Change-Id: Ibfc7811387df5224682d7e6a313d38648d3d8c48
Add documentation for rsl_ipac_rtp_csd_format_d/_ir from
libosmocore.git, include/osmocom/gsm/protocol/gsm_08_58.h and
wireshark.git, epan/dissectors/packet-rsl.c.
Related: OS#4393
Change-Id: Ic8f40076698f2b341cc0096fd96ba2051a41f077
Forwarding of PDCH related data over multicast works for me.
Without these features osmo-bsc would reject the OML connection
if it's configured with [E]GPRS enabled.
Change-Id: I5e13c153805c56904e51d222007228e1c2872c88
Related: OS#5500
osmo-pcu requires to get DATA.ind for all FN/TS it manages in order to
tick its internal FN clock and trigger timeouts. Without this, some
events are ticked in a delay fashion when osmo-pcu detects FN jumps.
Change-Id: I8f1856dd9061c1bfca8b15be30df7a51760231b0
Differentiate in each TRX between being provisioned (configuration available) and being provisioned *plus enabled*.
TRX0 waits for all other TRX to be ready before sending POWERON, since
all TRX need to have been minimally configured over TRXC before POWERON
is called. This "ready" state though, doesn't necessarily mean the
TRX!=0 are enabled (aka NM Enabled and rf_locked=0). With them being
configured it es enough to start the whole PHY.
With the old logic, given any TRX was rf_locked=1 at startup, the PHY
would not become UP because it the TRX_PROV FSM was waiting for OPSTART
to arrive on all TRX, which wouldn't happen on TRX that had rf_locked=1.
So in summary, the desired requirements to start the PHY are (in any
order):
1- Wait all TRX are configured
2- Wait for TRX0 OPSTART
Related: SYS#6370
Change-Id: Ie4836f5721ce8227a63c267730aeb17228994214
Having a common body for PRIM_INFO_{ACTIVATE,DEACTIVATE,MODIFY},
but then branching using if-statements is a bit confusing.
Change-Id: I915c8a541249249e3c0b1f2eda4535e7c52db79f
Related: OS#1572
The variable rc holds the return code of accept(), which returns a file
descriptor on success. So lets call the variable "fd" to make this
clear.
Change-Id: Ibc359d941786b1d1d52b356e239a76a090b52c1f
A request to send an Immediate Assignment over the PCH (not AGCH)
is always coming from the PCU. It's used for DL TBF assignment.
Change-Id: If4b0aa01532ab65b96201ff8829e724c67df6993
Premature activation of virtual scheduler in bts_model_phy_link_open()
leads to segfault in vbts_sched_start(). Fix this by moving scheduler
activation to bts_model_oml_estab()
Change-Id: I116c2548dd4d05df90c16e81fa2e85ed6027a2e1
Fix condition `block_nr == 4`, which was never reached, by effectively
replacing
- `4` by `msg->num_segs`, so we truly check if the current
block is the last of this message
- the index `block_nr` (which starts at zero) by `block_nr + 1`,
so it is comparable to `msg->num_segs`
Related: OS#5354
Change-Id: I3dc116d6c16c80b31712b2a969f0b2a6998b03f0
Looks like this is not needed, so make the jenkins build work without
installing dahdi-source.
Related: OS#5863
Change-Id: I61c483983a4793e0429bb37804dee0a128125daf
The VTY command is "local-port", but write-config would write "port"
instead, which would fail when re-reading the config file.
Realted: SYS#6237
Change-Id: Id08530b626b0e69c3b3bb9d8bb9e16080a73e74d
Both power_ramp_start() and power_ramp_force() are now small macros
around _power_ramp_start()
The new behavior is:
* ramp down power when stopping bts through Ctrl-C
* the other shutdown causes skip power ramping
This will cause the bts to reconnect faster when the oml link is
dropped and power ramping is enabled.
Change-Id: Ida1d7bbf094958b9142af306dbf84206729a609e
Related: SYS#6237
There is no reason why they should have different initial
states. Keep it consistent with the other MOs.
Change-Id: I9fd744ec79da9fc26d3ebe9857b2b0bbd5fcd1ff
This reverts commit c96d34f828.
Reason for revert: This breaks ramping up power since the power ramp logic still assumes the output is full power.
Change-Id: I47a16a4b3ba02d74473569c0f4350a41fc12a464
For the other shutdown causes power ramping doesn't make sense. Instead
shutdown quickly so we can reconnect faster
Change-Id: I71c46478b8f3b236dba3e959fc75e58c0409517f
Related: SYS#6237
The array of trx in gsm_pcu_if_info_ind can hold trx 8 items. Lets use a
define constant to specify the size of that array.
Change-Id: I5fdd5b9e59865fabd0340650ecb347d52208ebe9
The pointer variable l1sap is only used to determine the size of the
related struct but for nothing else. We can use the struct name in
sizeof also directly and get rid of it.
Change-Id: I93abdce1dec60d53ddceb1fce6e9e7451ba6283a
Before this patch, the free CID with the smallest number was always
selected to be used. This caused more or less the same subset of CIDs to
be used all the time, while the CIDs with bigger numbers were mostly
unused.
Let's distribute the use so that all CIDs are used roughly the same.
This has the advantage, among others, that the same CID will not be
re-used immediatelly after being freed if a new call is established.
It is useful to leave the CIDs unused for some time since the other end
peer may know of the call being tear down with some delay.
Hence if a new call is established immediately after the CID was
released, the same CID would be allocated and passed at the peer, which
would then detect that the old call (in its view still active) would
already make use of that remote CID.
Related: SYS#6161
Change-Id: I72803fb172accbabfc81923572890f8ecb06cefd
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
The number of NSVCs is fixed but lets not use magic numbers to define
the sizes of the arrays that hold the config values. In osmo-pcu there
is already a define constant, so lets use a define here as well.
Change-Id: If7fa44abb86c18900110d7ee81fe6140c8c4635b
Some osmo-bts varieties have a method to make an immediate change to
TX power from the vty. In osmo-bts-trx there does not seem to be any
way, so lets start the power ramp loop when the parameter
osmotrx tx-attenution is changed on a running TRX.
Change-Id: I1fa5e8130202fb509593db4132863b762b0f40b7
The parameter l3_len in rsl_tx_meas_res() is defined as int, even though
it can't be negative. Lets use unsigned int for l3_len.
Change-Id: I99068a36e74a557000f406154dce32300615086c
We request the length using msgb_l2len() in two locations where whe
cannot be sure that l2h is populated. Lets check this first.
Change-Id: Ie13d0724f183ff240714dcdbd24e5a21b4276bfe
Related: OS#5645
The function lchan_meas_handle_sacch() calls msgb_l3len without checking
if l3h is even populated. Lets add a check to be sure.
Change-Id: Ie5a9fe1ba880e68edb74f5f4ca559ac191330d4f
The PCU may poll the MS requesting an ACKnowledgment message to be
sent in form of four Access Bursts instead of Normal Bursts. The
BTS has no prior knowledge of the Uplink burst type, so a new MTS
value was specified in order to prevent the BTS from trying to
decode Access Bursts as a PDTCH block.
This patch implements parsing of the new MTS value 0b0110.
Signalling RACH.ind to the PCU is to be implemented.
Change-Id: I0fbb63006797e6be386d1f76ed97fff098c036fc
Related: OS#4006, SYS#4794
Checking if (bi->chan != TRXC_RACH) is not enough to detect HANDOVER
ACCESS. Receiving this message is only possible on CS channels.
Change-Id: Ice1674fd4fed8c54d605ff19d568f6e46b4c5783
Lchans which are marked as non-connected have not yet received
information about its remote peer, hence they may not have some fields
available yet. Let's skip them to avoid accessing such fields
(lchan->abis_ip.osmux.in).
Related: SYS#5987
Change-Id: Id53822c4a0486b0090df2db3d185e047d14fc90a
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#598
Change-Id: I102047685b9b9f4cba43970945f955c4fe9c4c95
This way we have no more access to internal osmux structures.
If those counters are needed in the future they can be counted by
osmo-bts by means of adding rate counters to the caller of
osmux_xfrm_input() and deliver_cb.
Change-Id: Ib952437ea3aa2770c96bddb667491e7675a6a06e
Otherwise some shared variables used by both Osmux and RTP was left set,
like connect_ip and connect_port, and next time the lchan was selected,
those were already configured even if they didn't come in IPAC CRCX.
This is specially bad if the channel was reused to set up an Osmux call,
since the osmux code path relied on those fields being properly reset
until set by IPAC CRCX.
Change-Id: I414bd0bc801451357bb45b89197a95e51b7c97f1
when something fails in osmo-bts during startup and it goes into SHUTDOWN state,
it is desirable to close new RSL links (sockets) which are in progress to connect,
while it waits for a while to complete shutdown (power ramping down, etc.).
This way we don't end up with new interactions and new state against a BSC if we
are shutting down.
The new libosmo-abis API is used since the higher layer struct e1inp_sign_link assigned
to each struct gsm_bts_trx is not provided to the osmo-bts code layer by libosmo-abis API
until the TCP+IPA handshake in the socket becomes fully established (sign_link_up()
callback).
Depends: libosmo-abis.git Ia6418321f3b6f1f7274efd414625a4b10a09a362
Change-Id: I599d074f51f490b43c9a89b105d1823391926947
It's not immediately obvious what numeric values mean for CPU scheduling policy.
Let's document this and add doc reference.
Related: OS#4107
Change-Id: Ib047762a336851e6205d77c83068a99d8a868e8b
Previously osmo-bts created /var/run/osmo-bts.pid which
isn't used by anything and makes it hard to run as non-root
user. Let's get rid of this pre-systemd relic.
Related: OS#4107
Change-Id: I86bcaedbc8cb1297476ad741eaa45585fea3c380
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: I4b7bcd441e5da81c4c5267715675041171a1ce1e
This helps understand the origin/purpose of those 2 bytes and
what's contained in them.
Related: SYS#5987
Change-Id: I607fdf6d627242e010fba35be1b9b0ffde820d08
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
The PRIM_INFO_MODIFY is sent on receipt of the RSL MODE MODIFY message,
which may optionally contain new ciphering parameters. Before this
patch, osmo-bts-trx would ignore the new parameters and continue using
the old ciphering key/algorithm.
* Modify l1if_set_ciphering() to allow updating ciphering params.
* Call l1if_set_ciphering() when handling PRIM_INFO_MODIFY.
This problem was uncovered by BTS_Tests.TC_rsl_modify_encr, which has
been failing ever since it was introduced [1]. This patch makes it pass.
Change-Id: I2278703b487374c0de4cfc42b22e70aaf6548589
Related: [1] I4cbea499bb6a331d314e6573548a4540945208b5 osmo-ttcn3-hacks.git
Related: OS#3750
It will be used too by osmux code present in another file. This is a
preparation commit to simplify the one adding osmux support.
Change-Id: Ie7fa57bb04db9ad9b03971467e12ee7b8e4c190a
The function is long/complex enough, so having one extra struct in_addr
declared the function top only used in one specific small path to print
the variable is unnecesary.
Let's move it to the conditional path where it is used to print the
ip address.
Change-Id: I4c16bbca6a6779537517b6b196828b47eddaa516
There's no need to maintain a duplicate msgb_queue_flush(), which
returns the amount of freed messages (feature not used at all by the
callers).
Change-Id: I9841e18ca0b7b852130bbb02a510e43a3b3fd93f
The queue_limit_to method iterates the entire list of messages every
time a new message is added. Let's use msgb_{enqueue,dequeue}_count()
APIs to do that in constant time. It is true that since the queue is
limited to 1, there's usually at most 1 item in the queue so it's not a
real problem. However, when we add Osmux in the future, we may need to
tweak the amount of messages which can be in the list, due to Osmux
batching mechansim which may be more bursty sometimes.
In any case, this change doesn't make things worse for sure.
The patch also takes the chance to group the queue_limit_to + enqueue
into one function to avoid having the code spread several times.
Change-Id: I61818a3bb521c27bd21a8b6fa70581d27638ec9b
Make them more easy to read and edit by splitting to one element per
line when several elements are present.
Change-Id: I24ecfa1167b806dcb3a5a0c00343299df842a78b
The logic responsible for enabling and disabling the loop appears
to be broken: during my experiments trx_loop_amr_set() was never
called with loop=1. It's not clear what's the motivation behind
this breaker, so I propose to rip it out for now. This patch
finally makes the loop work (confirmed with a TEMS phone).
Change-Id: I09b649973d4269c4082a4fafa493c37825f95a9c
Related: SYS#5917, OS#4984
This reverts commit 1f9fbd8816, which
was a workaround rather than a proper fix. The root problem has
been fixed in libosmocoding [1], so ~50% BER is not the case for
AFS_SID_UPDATE frames anymore.
Related: I813081a4c0865958eee2496fe251ae17235ac842 (libosmocore.git)
Change-Id: Iebe139632daf1d1f72e39fe9d1497059f68625b9
We have two similar values in enum gsm0503_amr_dtx_frames:
* AFS_SID_UPDATE - precursor of SID UPDATE,
* AFS_SID_UPDATE_CN - the actual SID UPDATE.
The former is internally used by libosmocoding to mark the current
frame as a precursor of the actual SID UPDATE frame - the later.
+---+---+---+---+---+---+---+---+
| _ | _ | _ | _ | a | b | c | d | AFS_SID_UPDATE
+---+---+---+---+---+---+---+---+
| a | b | c | d | _ | _ | _ | _ | AFS_SID_UPDATE_CN
+---+---+---+---+---+---+---+---+
^
|
| We're here.
Do not treat the precursor frames as a SUB frames, as they contain
no information (rc=-1) and usually have *expected* BER ~50%. This
fixes unexpected RXQUAL-SUB > 0 in the Uplink measurements during DTX.
Change-Id: I46f32bbbcb6284615d05b8703945c5ca4da55b92
Related: SYS#5853
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
* Print unexpected TDMA FNs, each on a separate new line.
* Do not abort() on mismatch, keep running.
Change-Id: I32c104b139f32a39c8347de19de6ad7caec811de
Related: SYS#5853
Attempting to detect missing Uplink frames in the *Downlink* path
is an ugly hack, that was needed before we had proper per-lchan
detection of missing bursts and NOPE indications in TRXDv1.
* [1] per-lchan detection of missing bursts was fixed in Aug 2018.
* [2] TRXDv1 support was introduced in Jul 2019.
Today is 2022 and it makes no sense to keep this hack. Even if
the transceiver does not support TRXDv1, per-lchan detection
will compensate the missing Uplink bursts.
Change-Id: Ic292d180ba64206fb4d88adb284f9f9d058b4587
Related: [1] I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: [2] If61c71d20d590bf07bfd019afb33000a0b6135bd
The gitlog shows that these warnings were added in
744f745d7a by jolly (in 2012!).
As nobody has bothered for the past ten years, degrade them to comments.
Change-Id: Iebf9961cffbd7aa20b263f7dc0016a44782dec60
Related: osmo-bsc.git I9ef7e18f56aa86b48f0ffeec58406260736170f3
OsmoBSC assumed since If91d85331d402c3ab9c32b70c2c66cd7ba6ceb28 that
OsmoBTS has CCN (NACC, Network Assisted Cell Change). With OsmoBSC
Idf2d933aa8b03b1f708e56a08707fe6c620a97aa, instead of hardcoding some
features for OsmoBTS in OsmoBSC, only the features reported by the
BTS are used. Therefore report that BTS_FEATURE_CCN is supported in
OsmoBTS.
For previous OsmoBSC versions, this fixes the message:
Get Attributes Response: reported feature 'CCN' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ic407e3be82afe61ed64b1cecf3dc94d2caff380a
I did not realize with my previous patch that there's a common place
where features available for all backends should be enabled. So move it
there.
Related: SYS#5922, OS#5538
Change-Id: Id688ddae5cd714355fcc5324f33c9397fecae261
According to osmo-bsc I0e80ca5afc06737273b6699bde6e325e454b57f6, the
PAGING_COORDINATION feature should be well supported in osmo-bts. Adjust
the bts_model_init functions to report this to the BSC, so it properly
sets this in SI13 and so we can avoid this notice in the log:
Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.
Related: SYS#5922, OS#5538
Change-Id: Ib06829501f4221a7f7b0344ec7991ceba74e7641
Currently (without this patch) if tch_dl_dequeue() yields nothing we're
scheduling dummy FACCH/H *regardless* if it's permitted to start at the
given TDMA FN or not. This may result in misaligned FACCH transmission,
so the MS will not able to decode anything and will report BER>0.
With this patch applied we schedule FACCH/H if it's allowed to start
at the current TDMA FN; otherwise send half-filled bursts with even
numbered bits contaning 232 encoded bits of the previous L2 frame
and 232 odd numbered bits all set to 0.
This patch does not guard against sporadic gaps in the Downlink TCH
queue. However when tch_dl_dequeue() constantly yields nothing, e.g.
when we end up with a codec mismatch, then this additional check saves
us from starting misaligned FACCH/H transmission. If we start at a wrong
TDMA offset, then all subsequent FACCH frames will be scheduled at wrong
offsets and thus none of them will be decoded by the MS.
Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b
Related: SYS#5919, OS#4823
* dl_ongoing_facch must be set for correct FACCH/H scheduling;
* dl_facch_bursts must be set for FACCH overpower to work.
Change-Id: Ief12eb67ad80de3b71f5226858dc2e0c8ae76948
Related: SYS#5919, OS#4823
If set, chan_state->dl_ongoing_facch indicates that we're sending
the 2 (out of 6) middle bursts of FACCH/H. In this case there is
no room for encoding an additional frame, because both even and
odd numbered bits are occupied by a previously encoded FACCH/H.
Right after calling tch_dl_dequeue():
* do not check the dequeued message against NULL,
* do not compare the message length to GSM_MACBLOCK_LEN,
* immediately free() it and jump to the sending part.
Change-Id: Ib923b8f5cc1063e9fc18acd2bdd003fd09f4b70f
Related: SYS#5919, OS#4823
Unlike SACCH, FACCH has no dedicated slots on the multiframe layout.
It's multiplexed together with TCH (speech or data) frames basically
by replacing (stealing) them. This is common for both TCH/F and
TCH/H, with the only difference that FACCH/H steals two TCH frames
(not just one) due to a longer interleaving period.
Let's implement the multiplexing in the common function, which is
used to dequeue to be transmitted frames - this slightly reduces
code duplication. Use a new name, so that it's clear what it does.
Change-Id: I9822b1a17185d5487f0f6d3ed0203e806c053d7d
Related: SYS#5919, OS#4823
Manual analysis of code didn't end up in finding any issue, so this
seems a false positive (I can really understand gcc failing to do proper
job here, this function has way to many jumps here and there.
"""
/sched_lchan_tchh.c:88:13: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
88 | int rc, amr = 0;
| ^~
"""
Change-Id: Ifebaee63a9dad04976ffb4438c32360687ef095a
Keep collecting C/I samples even if the MS has not yet applied
previously requested codec mode. The C/I ratio is expected to
stay more or less the same, no matter which codec mode is used.
Change-Id: Ieb5473ead7200f652b5d0e339e4e252d6567482d
Related: SYS#5917, OS#4984
With the current implementation the AMR loop is unable to upgrade
the current codec mode unless it reaches the worst possible value.
The problem is in the 'else' statement connection both 'if's.
Change-Id: I4c0fb28813373c3d4addd28c66f5136d2c4f9ed8
Related: SYS#5917, OS#4984
Currently we're logging AMR mode *indexes*, not the actual modes.
Let's make it cleaner for the user by logging both mode and index.
Change-Id: I4feb3a3823799a290a50a48275e45f3331874d1a
Related: SYS#5917, OS#4984
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
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
This configuration will be used as a fall-back when the MultiRate
configuration IE is not included in the CHAN ACT/MODIFY messages.
Change-Id: Ie96af636105ee1ffe2d9a0bd9eea375faebad149
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917, OS#4984
Normal blue (34) is really hard to read on terminals with dark
background. Let's use light blue (94) instead.
Change-Id: Iadc9b8fb74ec17455435893a532c2f12e02cb804
3GPP TS 48.058 defines the MultiRate configuration IE as optional,
and states that it's "included if the Channel Mode indicates that a
multi-rate codec is used". If I understand this correctly, it may
be omitted even if a multi-rate codec is requested. Otherwise it
would have been defined as a conditional IE.
For now let's print a warnig if this IE was expected, but missing.
We may need to apply some hard-coded defaults in this case.
If this IE is present, but the Channel Mode indicates a codec other
than AMR, let's send NACK with cause=RSL_ERR_OPT_IE_ERROR, assuming
that the CHAN ACT/MODIFY message is malformed.
Change-Id: I6ddc0b46a268ed56ac727cda57d0d68b2746fd59
Related: SYS#5917, OS#4984
There is nothing else except the AMR link adaptation loop in these files.
Change-Id: Iff2c0d32da5cd89824197d05f4732ce974c12f28
Related: SYS#5917, OS#4984
This check is redundant because it's guaranteed in rts_tchh_fn()
that FACCH/H is always scheduled at the correct frame offset.
Change-Id: I2f0c26f6007455aa1e3e8b27bc9d173f6b1f8c38
Related: SYS#5916, OS#5518
Since change [1], in rts_tchh_fn() we're using a lookup table for
DL FACCH/H. Let's do the same for UL FACCH/H in rx_tchh_fn().
Change-Id: I7c4e3befdd33bef4d89a04a4c7cb1a2d4078c156
Related: [1] I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
Unlike TCH/F, TCH/H imposes some additional requirements on the FACCH
transmission, so that a signalling block can be transmitted only at
specific TDMA frame numbers defined in 3GPP TS 45.002, table 1.
This is why in rts_tchh_fn() we need to check the given TDMA frame
number and tell rts_tch_common() whether FACCH/H is permitted or
not. The check is based on a magic formula, which I find a bit
hard to read and understand. Let's better use a lookup table.
Change-Id: I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
It's guaranteed by the calling function bts_model_l1sap_down() that
the prim's operation is PRIM_OP_REQUEST and that the msg is present.
Change-Id: I6a01bba7b5eb337ae1552c442d74447565c52e25
For the sake of consistency and code readability, initialize the
power loop control interval (P_Con_INTERVAL) for both Uplink and
Downlink directions in the same function.
Change-Id: If7c804e51eb104d9fe73294a3867ab3b551d83c3
In change [1] I didn't take into account that the TCH/H burst buffer
is 6 bursts wide, and that we're decoding 2 bursts late:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
The lookup table for TCH/H was calculated with the assumption that
in rx_tchh_fn() the 'bi->fn' indicates TDMA frame number for burst
'd', but in reality it holds the frame number of burst 'f'.
Change-Id: I4f22cf49fd52ed26f8017f76461059a701c181e1
Fixes: [1] I46def864729c8f9063af201750456771ea5558d5
Related: SYS#5916
It makes no sense to have these tables in the header file, because
they're not used anywhere outside of the respective lchan handlers.
Change-Id: Ibdebfb9b1ef78c960b08240ebdb4c7af92cbed11
Related: SYS#5916
In change [1] I broke measurement reporting for TCH/H in signalling
mode. The problem is that in rx_tchh_fn() we started to invalidate
the Uplink RSSI for FACCH regardless of the channel mode: speech or
signalling. In speech mode, the averaged measurements are carried
over by the two BFIs. In signalling mode we send no BFIs, so:
* let's use the proper averaging mode S6N6 (not S6N4), and
* send the averaged measurements together with the FACCH.
This change fixes BTS_Tests.TC_meas_res_sign_tchh[_toa256].
Change-Id: If98aa1f0f7255f20344460bdd07e2c896dd6e56f
Fixes: [1] I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: SYS#5853
There is no reason not to use 'chan_state->tch_mode' directly in
the 'switch' statement. If a logical channel is in signalling
mode, then both 'chan_state->{rsl,tch}_cmode' are set to
RSL_CMOD_SPD_SIGN and GSM48_CMODE_SIGN, respectively.
Change-Id: I9e5e2c891c80c32fc522b53c9371b71ea32dd54d
Related: SYS#5853
3GPP TS 45.009 defines that Codec Mode Indications shall be sent
with speech frames having specific TDMA frame numbers of their
*first* bursts, which are defined in tables 3.2.1.3-{1,2,3,4}.
Performance-wise it's batter to have these tables implemented as
arrays, rather then using the 'switch' statement. We can simplify
things even further and have TDMA frame numbers corresponding to
the *last* bursts in them. This eliminates the need of doing an
additional last-to-first mapping, so that bi->fn can be used.
Change-Id: I46def864729c8f9063af201750456771ea5558d5
Once we have an Uplink speech or FACCH frame decoded, we need to
hand it over to the upper layers indicating TDMA frame number of
the *first* burst corresponding to the beginning of a block.
Currently we use libosmogsm's gsm0502_fn_remap() API to calculate
the first TDMA frame number from the given last frame number.
This API involves iterating over the pre-calculated offset tables
for different channel and payload types, and thus imposes some
additional CPU cycles. Another downside of the current approach
is that we have to perform such lookups several times for each
decoded L2 frame, e.g. for FACCH on TCH/AHS we do it three times!
In this patch I propose an alternative approach of storing TDMA
frame numbers in the measurement history, together with the
associated samples. This way we can easily get N-th frame number
from there without performing any additional computations, other
than what we already do during the measurement processing.
Change-Id: Id9a2b7b0f1a1ad7cfbbab862faf521e135c90605
The idea of this change is to avoid attempting to decode the burst
buffer unless it's filled up completely. This eliminates expected
decoding errors in the beginning of lchan's lifetime. Moreover
this allows us to be sure that the measurement history is complete,
so that we can abuse it to store TDMA frame numbers later.
Note that even in the absence of NOPE indications (TRXDv0 case)
we can still be sure that the burst mask has no gaps due to lost
bursts, because they are compensated by trx_sched_calc_frame_loss().
Change-Id: I56bebe1374eb803e3c1e9f08dda4da50a074ab0b
For both TCH/F and TCH/H, the receive burst buffer needs to be
periodically shifted leftwards due to the nature of block-diagonal
interleaving. Currently we do this on receipt of bid=3 for TCH/F
and bid=1 for TCH/H, right after attempting to decode the buffer.
If for some reason we return early before attempting to decode the
buffer, the content of that buffer might not be shifted and some
bursts might be overwritten. This can be easily avoided by doing
the shifting on receipt of bid=0 for both TCH/H and TCH/F.
Change-Id: I0bd69f5a8f5c665fb5f00c127bc3fe1d91167abb
In the current implementation of both TCH/F and TCH/H lchans, we
set the 'bfi_flag' to true only if decoding fails. Perhaps this
was not the case when I wrote [1], so using meas_avg might result
in using uninitialized memory. This is not the case anymore.
Pass the *averaged* measurememnts regardless of decoding result.
Change-Id: I23f767364a018d30d04885990adf69b50b2c9738
Related: [1] I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
FACCH/H takes out two speech frames, so we send two BFIs once we
have received it in rx_tchh_fn(). The upper layers responsible
for handling of the Uplink measurements expect a fixed amount of
measurement samples, so currently we do:
* send a FACCH frame with the associated measurememnts (S6N6),
* send the 1st BFI with invalidated measurements (RSSI=0),
* send the 2nd BFI with the stored measurememnts of FACCH.
This is achieved by preserving a copy of the FACCH measurememnts
in chan_state->meas_avg_facch and then using it two bursts later.
The same goal can be achieved a lot easier by sending the associated
measurements with both BFIs as if no FACCH was received:
* send a FACCH frame with invalidated measurememnts (RSSI=0),
* send the 1st BFI with the associated measurememnts (S6N4),
* send the 2nd BFI with the associated measurememnts (S6N4).
This eliminates the need to store anything outside of the existing
measurement history and simplifies the code a lot. Also, this
eliminates the need for using a dedicated averaging mode S6N6.
Varified by running BTS_Tests.TC_meas_res_speech_tchh_facch.
Change-Id: I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
It makes no sense to store BER10k value of an Uplink FACCH frame
in order to indicate it in a BFI later on. Given that these BFIs
are generated artificially, it's fine to indicate BER10k=0.
Change-Id: I24d12892760dca0ad0a5c2abca9fc66523d9e614
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
According to 3GPP TS 45.002, table 3, unlike the CCCH+SDCCH/4+CBCH
combination, which can only be allocated on C0/TS0, the SDCCH/8+CBCH
can be allocated on C0..n/TS0..3. In other words, having CBCH on
e.g. C1/TS2 is perfectly legal. This is why in gsm_bts_get_cbch()
we should check all transceivers, not just the C0.
Without this change osmo-bts does not send CBCH Load Indications
at all if the CBCH is allocated on C1..n.
Change-Id: Ib5976783b53521047fbdfc18e0e236e8bce8eaae
Related: osmo-bsc.git Ie79ccff4f8f0f1134757ec0c35e18b58081cc158
Related: SYS#5905
Both TRXC_RACH and TRXC_PTCCH are handled in the rx_rach_fn(),
so we can eliminate the need of having a 'switch' statement in
the general (perfrmance critical) code path.
Change-Id: I66d8785a63215af37a77e258039549e4e6292e49
Compared to TCH/F, TCH/H is a bit special in a way that:
* speech frames are interleaved over 4 consecutive bursts,
* while FACCH frames are interleaved over 6 consecutive bursts.
This is why in rx_tchh_fn() we allocate a buffer large enough to
store up to 6 bursts. Let's say we have that buffer filled up
completely with all 6 bursts (from 'a' to 'f'). Now attempting
to decode them may yield either a speech frame or a FACCH frame:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
For FACCH we use measurement averaging mode SCHED_MEAS_AVG_M_S6N6,
so that 6 last samples are averaged - so far so good. For speech
we use SCHED_MEAS_AVG_M_S4N4, so that 4 last samples corresponding
to bursts 'c', 'd', 'e', 'f' are averaged - this is wrong.
We actually need to average the *first* 4 samples corresponding to
bursts 'a', 'b', 'c', 'd' in the case of speech. Let's add and use
a new averaging mode SCHED_MEAS_AVG_M_S6N4 for that.
Change-Id: Iea6f4e5471550f4c2b57aaebeac83c80e879489d
This should be better performance-wise and would also allow to avoid
having the same switch statement duplicated in functions added later.
Change-Id: If8124dcd38e7c8408a9f3b9a574d9e3181a2eb15
This is a purely cosmetic change. The new naming clearly indicates
how deep to go back in the measurement history (S) and how many
samples to average (N). For example:
* SCHED_MEAS_AVG_M_S4N4 - go S=4 steps back and average N=4 samples;
* SCHED_MEAS_AVG_M_S6N2 - go S=6 steps back and average N=2 samples.
Change-Id: I96a8dd08084c7c179f879fc00e75c5edcfb11caa
Set the FT (Frame Type) in the ToC (Type-of-Content) section as
defined in section 5.2 of RFC 5993. Before this change SID frames
had FT = 000 (Good Speech frame), because gsm0503_tch_hr_decode()
does not distinguish between speech and SID frames internally.
Change-Id: I09cec984bb60c754908126acf0300a2cc602485c
Related: SYS#5853
According to RFC5993, which is referenced by 3GPP TS 48.103, the
complete RTP HR payload consists of a Table-of-Contents (ToC) byte
followed by the 14 bytes of the HR codec frame. See section 5.2.
gsm0503_tch_hr_decode() outputs frames in the RTP format with
length of 15 bytes (120 bits): 1 (ToC) + 14 (HR frame):
+-------------+-------------------------
| ToC section | HR codec frame ...
+-------------+-------------------------
osmo_hr_check_sid() expects a HR codec frame of 14 bytes (112 bits)
as the input, so we should skip the ToC section when calling it.
Change-Id: Ie5fa776dcb2b2203a97aed56ecbf2450af7d87c1
Related: SYS#5853
According to 3GPP TS 48.058, section 4.1.4, BTS shall start transmission
on SACCH if both MS Power and *Timing Advance* IEs are present. There
can be no Access Delay IE in the RSL CHANnel ACTIVation message.
Change-Id: Icd8ccfd6e37ded8966125a473b5003845ba87fec
Fixes: I170b63c9856230d5f1a10654a9d950ada8e730d7
Related: SYS#5838
We already have BER10k calculated in the generic code path, so do
not calculate it once again in the FACCH specific branch.
Change-Id: I5d3955d09990e280d11d687385eeaf5edf437395
It makes no sense to perform the SID codeword lookup in signalling
frames (FACCH), because it can be present only in speech frames.
Change-Id: I2f8137993acfe8a8add3fc2af276e5eb4da1605e
Related: SYS#5853
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
This new rate counter allows to monitor the efficiency of the
radio carrier cache used for routing Downlink bursts when
baseband frequency hopping is in use.
Change-Id: Ie6da829e47298476267c8df2dcedafad564cbbb4
Related: SYS#5855
Given how often we send and receive TRXD PDUs, I believe it maks
sense to use OSMO_UNLIKELY() in the error checking conditions.
Theoretically this should improve performance.
Change-Id: I9266aaf2bbc0acfe21e9bfb12c9f38621d120553
This avoid a NOTICE log line like the following when gsm_lchan_release()
is called.
"""
rsl.c:2484 (bts=0,trx=0,ts=2,ss=0) Sending RTP delete indication: cause = Normal event, unspecified
"""
Change-Id: I0ce78c52644983220f5810bc5c661b07afd9e543
If len is < 0, it means osmo_amr_rtp_dec() failed and some of the out
variables there are not set. We should check the return code before
continuing and using potentially uninitialized values.
Change-Id: I76020c6b5dc8d3e52e8c5be8cdecdf8a0bb52ed9
DSUM is somewhat similar to DMAIN, generic logging category used
in other Osmocom projects. This category is rarely used in a few
places, where the other categories could fit better. Remove it.
Change-Id: Ia9db783bc92b23ba87b4fdf1e4ed07d59ea6bbce
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I12b250e16426b125124def49e124e40ae93d0d58
An additional burst buffer is allocated in rx_data_fn() for Uplink
SACCH repetition, but unlike the main buffer it never gets free()d.
Change-Id: I93310e7aed91a49c0511e2ed30e000440617f95a
Fixes: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
Before a massive refactoring of the scheduler structures [1] it was
impossible to have a clean hierarchy, in which the burst buffers
get allocated as children of their parent timeslot structures.
This change makes it easier to read talloc reports and simplifies
memory management, offloading free()ing of the burst bufferes to
talloc.
Change-Id: Idb1ceaf83c433d2d0eb84d77c2187a00a657905c
Related: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
Add an osmo-bts meta-package that depends on the subpackages
osmo-bts-trx and osmo-bts-virtual. This is important, because the
downstream packaging of debian does not split osmo-bts in subpackages,
it has only one osmo-bts package. So without this, when installing
"osmo-bts" in debian while having the Osmocom binary package repository
installed and expecting to get the newer version, the user will actually
get the older version from debian.
Closes: OS#5319
Related: https://salsa.debian.org/debian-mobcom-team/osmo-bts/-/blob/master/debian/control
Change-Id: I1a6edf2eb146616ac51b7957368a8d057caa685f
Callers of osmo_wqueue_enqueue must always check the return value
and free the message themselves in the error case.
Change-Id: Ic67fbef23e419c0c8a7bcfb16d134e1bf649de72
Related: OS#5329
If a new default message is installed via RSL, and the old default
message is currently being transmitted, we must set cur_msg to NULL.
The old default message must be talloc_free()d unconditionally whenever
a new default message is being set.
We can do that by using the TALLOC_FREE macro.
Change-Id: Id32c2074b61cd1f09957b9d1558ffb3a7691a8e0
Related: OS#5325
If the currently transmitted message is the default message,
bts_ss->cur_msg == bts_ss->derfault_msg. In this case we cannot
simply talloc_free() both of them, as it would result in a boudle-free.
Change-Id: I2d3645e34d31507b012a53ffe12d14223682f808
Closes: OS#5325
Fixes: Ib01d38c59ba9fa083fcc0682009c13d2db3664fe
The order of interference level boundaries is not clearly defined by
3GPP, so we should support both ascending and descending variants.
Change-Id: I88d841d8d835bde8392c7b606b28c9070b7adc6e
Related: SYS#5313
It may happen after the A-bis connection recovery that the RF RESource
INDication message gets sent too early, while some timeslots are not
yet configured. This confuses the BSC and provokes error messages.
Change-Id: I00bc6fe67ea1bbedcd5d8640e73bd8b16b9e667f
Related: SYS#5313, SYS#4971
Let's make sure all ts->pchan* related data is reset when we release the
TS. This is important for pchan_is, since in bts-trx upon shutdown
finish the PDCH lchan of a osmo dyn TS is set to
lchan->state=LCHAN_S_NONE, and as a result when the PCU tries to release
it by means of PCUIF act_req later, it may be ignored since the lchan is
already in erased state.
Related: SYS#4971
Change-Id: Ic7c34c0de23101ce094ffd03e00b4d2f6a551152
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
The current Timing Advance value can be obtained either from the
L1 SACCH header (if received) or from lchan->ta_ctrl.current.
Change-Id: I2b3693a0e49f03f2b4496c9dbd30cf47e9bc86b5
Currently an Uplink SACCH block is being passed to LAPDm first, and
then gets forwareded to the BSC in handle_ms_meas_report(), together
with the Uplink measurements collected so far.
This approach has a serious flaw: handle_ms_meas_report() won't be
called if an Uplink block contains SAPI=3 data (SMS) or was not
decoded at all (len=0) fow whatever reason. Therefore, no RSL
MEASurement RESult message will be sent to the BSC.
Rename handle_ms_meas_report() to lchan_meas_handle_sacch(), and call
it from l1sap_ph_data_ind(). This way perioduc RSL MEASurement RESult
messages will be sent regardless of what happens on Uplink SACCH.
Change-Id: Ifed91f87fd653debc87a09da3fd31ad64a13f330
Fixes: TC_meas_res_speech_{tchf,tchh}_sapi3
Related: SYS#5319
This way we keep all BTS connected to the same BSC if there was a
spurious network problem.
Related: SYS#4971
Change-Id: I16b75da5987584d099edc3a640f3a5cd61f3ad69
priv->current_bsc will for sure be != last, otherwise it would have
entered the if clause above it.
Change-Id: I0a6519f7b93f0b45c67d19fef4f50daeeefc7340
This scenario is actually expected when the call is being set up or torn
down, since we may not be receiving RTP from the MGW to send to the MS.
Hence, let's lower the log level to DEBUG to avoid having log clogged
for each call start/stop if INFO is used.
Related: SYS#5676
Change-Id: Ib7f274b97cc66d671316eae429ee4baf16831534
Recent commit (see below) changed a check to avoid weird results for msg
which had l2h=NULL, since l2len would return unexpected results there.
However, some code branches like FACCH or TCH seem to be always setting
l2h even if len=0. Hence, we must test either of the 2 scenarios (null
pointer and l2len()).
This commit fixes the following message appearing all the time during
calls:
"""
TCH/F: Prim has odd len=0 != 23
"""
Fixes: fb905b8d23
Related: SYS#5676
Related: SYS#4919
Change-Id: I43152bc8484a35cd004d3303d3a6e6efcdefa890
It cannot happen that msg1 is NULL and msg2 is not null, since they are
deuqueed from same place. Only possible combinations are:
msg1!=NULL && msg2!=NULL
msg1!=NULL && msg2==NULL
Change-Id: Ifd789844b1a7dfba596664de440d4c20b9f4c78f
* Remove deprecated configuration options:
'osmotrx timing-advance-loop' is deprecated, Timing Advance loop is now active by default
'osmotrx ms-power-loop <-127-127>' is deprecated, MS Power Control is now managed by BSC
* Adjust 'ipa unit-id' (1801 -> 6969) to match the one from the example osmo-bsc.cfg
* Set clock advance values to known working values:
+ 'osmotrx fn-advance' -> 20
+ 'osmotrx rts-advance' -> 5
* Set 'nominal-tx-power' since the calypso-bts tranceiver does not support NOMTXPOWER
Change-Id: I69436b914cf1bec57f9fe7acea4a896e7c46b3a9
In 2/3 cases when calling process_l1sap_meas_data() we already have
a pointer to the logical channel, so let's pass it as the first
argument instead of a pointer to the transceiver. This way we
avoid calling get_active_lchan_by_chan_nr() two times.
In l1sap_ph_data_ind(), call process_l1sap_meas_data() below the
conditional branch handling PDCH, so it won't be called for
GSM_LCHAN_PDTCH anymore. GPRS specific measurements are handled
by the PCU and not of interest for the BSC.
Change-Id: I9de67a0b2d2b18923f2c2003b400387a0f1af411
After merging the patch [1] fixing handling of the RLL RELease
INDication message in lapdm_rll_tx_cb(), ttcn3-bts-test shows
several regressions:
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_DCCH_3
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_0
pass->fail: BTS_Tests.TC_rll_rel_ind_ACCH_3
pass->fail: BTS_Tests_LAPDm.TC_sabm_dm
[1] I823c9101bcca72d5792e16379b02d3602ffc2726
991020c049
The problem is actually *not* in patch [1], but in the older one
[2] which we attempted to fix. While a logical channel is in
signalling mode, the lower layers do not produce PRIM_TCH_RTS,
and thus the l1sap_tch_rts_ind() is not being called.
Unlike l1sap_tch_rts_ind(), the l1sap_ph_rts_ind() is being called
regardless of the channel mode (signalling vs speech), so let's
move handling of lchan->pending_rel_ind_msg there.
Change-Id: I2c380f9045624f0a0a8f988bb207bc73d8354857
Fixes: [2] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
It could happen if for instance l1 code called trx_sched_clean() when
closing the phy, and after that some code called (erroneously)
trx_sched_set_lchan(). Let's make sure we don't allow other modules to
crash the process when using this function.
Related: SYS#4971
Change-Id: I93af7c3dcf0e34e9317eec0ee183dbf18b8d2f3b
This avoids triggering all sorts of unexpected paths where one tries to
release an already released lchan, etc.
This can happen for instance if BTS shuts down due to BSC link going
down, and hence resets all lchans, announcing it to the PCU. Then the
PCU may try to deactivate the channel sending act_req (disable), but the
BTS already unilaterally dropped the channels.
That code path seems to trigger some crash, probably because something
in lchan has been freed.
Related: SYS#4971
Change-Id: I093e4d4e23b527b10bf5d6ff538460626c30a8f8
The burst is properly pre-filled to _sched_dummy_burst in
bts_sched_init_buffers(), so we are fine doing nothing on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: Ia7045724a1a3206f5890c0b12843711ad2360ed8
msgb_l2len() will return nonzero values if msg->l2h is NULL.
Let's check against msg->l2h being NULL instead.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
This reverts commit 8a85b71167.
This is actually the wrong fix. Proper fix comes as a follow-up patch,
since the root cause happens earlier in upper layers. No msg with
l2h=NULL should reach this point of code ever.
Change-Id: Ie23d94924f824bd7e89437ccf73b260f542477c6
PCU idle blocks are identified by being 0 length, and hence msg->l2h
being null. Don't try to encode those, but simply discard them silently.
In case there's a missing block in C0, we want to log the event since
the BTS is expected to send something on C0.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I57e215fedeb415db4e67fdc56bf0f1410b5f7130
With this change the error case is moved at the end of the function,
which is more usual. At the same time, one goto tag can be removed,
simplifying the function.
This is also a preparation for next patch improvinga bit the logic
around same place.
Related: SYS#5676
Related: SYS#4919
Change-Id: Ifbd95ccbebf4d810b1fe0a162722e63fe69106b8
The new [bit-]fields in the RSL_IE_OSMO_TEMP_OVP_ACCH_CAP allow
more fine-grained control over the overpower feature, which
can be enabled:
* for both SACCH and FACCH,
* for SACCH only, or
* for FACCH only.
Change-Id: Iaaab675a20bbefece832d913963c8c5ae32ff80c
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
This adds a --enable-systemtap configure option, which will then
add static tracepoints to the generated osmo-bts-* binary.
At this point, only two sets of tracepoints are supported, and
only in osmo-bts-trx: ul_data_{start,done} and dl_rts_{start,done}.
The probes are intended to be used for analyzing the amount of time
needed for processing of uplink bursts / generation of downlink bursts.
Change-Id: Ibb4962253f1a195dc1a54405bac058ccb2545799
During the merge of [1] the patch hunk was applied at a slightly
wrong location, so the code path has become unreacheable.
Change-Id: I823c9101bcca72d5792e16379b02d3602ffc2726
Fixes: [1] Ie4f70c75f0137b4bd72d579b3a32575bac2fca3
A logical channel may have associated messages, which are pending
for transmission until some event occurs. Do not leak them.
Change-Id: I3264e6caa007e9e9cb9c1c2f8627c408bbb28b9e
In repeated_dl_facch_active_decision() we rely on the Measurement
Report message, that in some cases may not contain valid Downlink
measurements. In this case, we should simply ignore it.
Change-Id: I0d72b454f2b770d5762303fb70a15a8cdc9d07d7
Related: SYS#5114
For the sake of consistency, call repeated_dl_facch_active_decision()
from handle_ms_meas_report(), so we have all functions using the
measurement results for Downlink executed in a single place.
Change-Id: Ibd5377ce642e49161f320ac8c33e9f966b3ddfaf
Related: SYS#5114, SYS#5319
A bit of archeology, history & recap:
ec1b5a0e9e2b6549e0ede48e803095e569997355 (openbsc.git) Adds assert in gsm_ts2chan_nr()
2f44693fad8505255293d3ed37dbd4e7cabebd37 (openbsc.git) ASSERT is disabled due to reported hit in octphy and
litecell in gerrit for ec1b5a0e9e2b6549e0ede48e803095e569997355
5cef0623ef (osmo-bts,git) minor fixes to gsm_ts2chan_nr() regarding the pragma
c9079d9106 (osmo-bts.git) GSM_PCHAN_NONE case is introduced in gsm_ts2chan_nr()
This code has long evolved and robustness has improved, it's not even
part of openbsc.git for several years now. Let's always assert if we
receive an unexpected value there, since they are all internally handled
values and hence we have control over them.
Related: OS#2906
Change-Id: I25e2cf0c922bc9902336e9add75a47535b9355bf
It can happen when using several TRX that all of them go alreadyunder
shutdown target tx power level, but that due to configuration the BTS
still may want to keep pushing the tx power level even lower. Hence, we
end up in a situation where the FSM is trying to close all the TRX while the
power ramp procedure is ongoing for some of them. As a result, race
conditions can happen where for instance the power ramping procedure for
one TRX ends and calls the cb to send SETPOWER after the TRX PHY has
been closed (and hence TRXC link is unavaialble).
If that happens, the trx_if lower layers store the SETPOWER and attempt
a later retransmit, which may take up to 2 seconds after TRX becomes
active if BTS reconnects immediatelly.
Hence, we end up in some test cases where BTS reconnects and configures
some TRX while others are kep unconfigured for a while due to the
mentioned delay, hence the test attempting to use the TS while it hasn't
been yet configured.
The solution is to avoid this kind of unexpected events with ongoing
powe ramp once we have decided tx power is lower enough to shutdown the
TRX completely. Hence we abort the pending power ramp procedure.
Change-Id: Ibca581131eb142d7c38c917a0d6990efec03123c
Fixes crash when TTCN3 BTS_Tests_LAPDm TC_rr_response_frame_loss
runs run after TC_t200_n200.
The BTS was shutdown after TC_t200_n200 failed (drop oml link), and
lchan was moved ACTIVE->NONE without lapdm_channel_exit() being called
on it. Hence, on next test (TC_rr_response_frame_loss), when
lchan_init_lapdm() was called again, some memory corruption was caused.
The lapdm_channel_exit can be dropped from gsm_lchan_release() and
rsl_tx_rf_rel_ack() since it's already called in the same path:
"""
rsl_rx_rf_chan_rel
gsm_lchan_release(lchan, LCHAN_REL_ACT_RSL);
l1sap_chan_rel(lchan->ts->trx, gsm_lchan2chan_nr(lchan));
l1sap_chan_act_dact_modify(trx, chan_nr, PRIM_INFO_DEACTIVATE)
bts_model_l1sap_down
bts_model_lchan_deactivate_sacch(lchan);
-
lchan_deactivate(lchan);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_NONE); <---------
mph_info_chan_confirm(trx, chan_nr, PRIM_INFO_DEACTIVATE, 0);
l1sap_info_rel_cnf
rsl_tx_rf_rel_ack(lchan);
lapdm_channel_exit(&lchan->lapdm_ch);
lapdm_channel_exit(&lchan->lapdm_ch);
"""
Related: SYS#5262
Change-Id: If0ec5f0c7be4d15c8d684d33e15e24d68bd5192e
osmo-bts-trx/l1_if.c lchan_init_lapdm() for CCCH is already done when
trx_set_ts_as_pchan() calls:
"lchan_set_state(&ts->lchan[CCCH_LCHAN], LCHAN_S_ACTIVE);"
Change-Id: I7a9c3660b9aab57ff8765e2f1526349599630cd9
Let's avoid running over state change conditions or even printing log
lines if there's no state change.
Change-Id: I1ca86aa846084f53751076643665cb6dabc26a06
There's no need to re-setup it every time.
Mark the cb as static since its private to the module, and move it
above its use point so it can be referenced.
Change-Id: I90324f26d8ca09d425c7523a25b3e6c951fa49d6
* Move way too verbose command description to the manuals.
* None of these commands apply immediately, correct the attributes.
** Remove meaningless call to l1if_provision_transceiver_trx().
* Make 'maxdlynb' hidden, so it only appears in the expert mode.
* One GMSK symbol actually corresponds to 550m.
Change-Id: I46839cf56bba2dcdc70303cd393e86d35aa2f3f5
trx_phy_inst_open() already guards against NULL trx ptr when calling
trx_sched_init(). Later on, in same path, trx_phy_inst_close() can be
called which ends up calling trx_sched_clean(trx), this time not being
guarded against NULL trx. This fixes Coverity CID#240498.
Fixes: CID#240498
Change-Id: I00afc739559d57dd98db68c76f2a85006c15e875
- one gsm symbol is 0,00000369 seconds
- 2*550m/c = 0,00000366 seconds
-> one ta symbol is a DISTANCE of 550m (or a RTT of 550m*2) between bts and ue.
-> no idea why this was constrained to TA/2.
Change-Id: I8d79080c82411e6427eec37d008614fa5d5e1ace
Related: OS#5140
The OML NM Channel FSM state only apply to primary timeslots, hence we
need to make sure we pick the primary TS (the non-shadow one).
Due to this bug, all channels on shadow TS where NACKed because the
related state was never "Enabled Ok".
Fixes: c97a7f51e1
Related: OS#5249
Related: OS#5251
Change-Id: If47e4bdd45a05ed1b5709b6e3d541f2830723e37
Since non-shadow TS are currently not allocated as talloc contexts,
lchan objects tend to allocate their own memory on trx talloc ctx
instead. That's fine for non-shadow TS, since the TS follow trx lifecycle
since they are part of the same talloc context. However, shadow TS are
recreated (re-allocated) each time the BTS reconnects, hence when htey
are freed we need to free substructs (lchan) memory in order to avoid it
being kept in trx talloc ctx.
Related: OS#5248
Change-Id: I73742535eb3c40a6866731acbff782940dab06c3
Code in oml.c, upon receiving net attributes, merges the new attributes
with old ones (for some reason I don't really know). Hence, if we
disconnect from a BSC and go to NOT_INSTALLED state, we must free
previous nm_attr in order to avoid mixing them once we connect to a new
(potentially different) BSC upon reconnect.
Related: OS#5248
Change-Id: I45cc22dd68121a7930301581bfd0a8db37879c77
Let's rather put it there instead of the shutdown code path, since we'll
be adding more and more reset coe there.
Change-Id: I43a136ade731a2c58c0a29d97875088e9b6d4414
Currently, only osmo-bts-trx is capable of reporting the interference
levels to L1SAP. Thus it does not make sense to trigger the averaging
logic and send empty reports over the A-bis/RSL and the PCUIF.
Change-Id: Ic17eb46bdca3c33ac4d6e560a093b635b75424a5
Related: SYS#5313
Starting from [1], interference levels on PDCH timeslots are also
reported over the A-bis/RSL. They may be useful for the BSC to
determine whether dynamic PDCH timeslots might be better used for
new circuit switched connections, or whether alternative PDCH slots
should be allocated for interference reasons.
* Handle GSM_LCHAN_PDTCH in lchan_report_interf_meas().
* Rework pcu_tx_interf_ind() to accept 'struct gsm_bts_trx'.
* Call pcu_tx_interf_ind() from l1sap_interf_meas_report().
Regarding pcu_tx_interf_ind(), it's better to call this function
from the upper layers once, rather than calling it from various
places in the model specific code.
[1] I5b4d1da0920e788ac8063cc765fe5b0223c76758
Change-Id: I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Related: SYS#5313
This information may be useful for the BSC to determine whether
dynamic PDCH timeslots might be better used for new circuit
switched connections, or whether alternative PDCH slots should
be allocated for interference reasons.
Change-Id: I5b4d1da0920e788ac8063cc765fe5b0223c76758
Related: SYS#5313
It's cleaner from the architectural point of view to have the
interference measurements processed in a separate function.
Change-Id: I3981608e01a50585359cad673c38c8a305027d30
Related: SYS#5313
It may happen that the BSC requests logical channel activation on a
dynamic timeslot, which is in a process of switching from one pchan
type to another due to a preceding channel activation request.
In this case 'struct gsm_bts_trx_ts' already holds an msgb with the
preceding RSL CHANnel ACTIVation message, that is normally handled
once the PHY completes the process of timeslot re-configuration.
On receipt of subsequent RSL CHANnel ACTIVation messages, in function
dyn_ts_l1_reconnect() we overwrite the preceeding msgb (memleak), by
the most recent one. And once the timeslot re-configuration is done,
only the most recent CHANnel ACTIVation message gets ACKed.
In order to avoid this, let's move the msgb ownership to 'struct
gsm_lchan', so it cannot be overwritten by the CHANnel ACTIVation
message that is related to a different lchan on the same timeslot.
Change-Id: Ia625c2827fca883ea712076706d5ef21ed793ba6
Related: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Fixes: OS#5245
Otherwise after reconnecting some SI are still marked as valid despite
the new BSC conn didn't set them.
Change-Id: I71e2a5cdf4e2e287db7b05df1a165a1e32c958ca
Let's split all lchan and power_control specific stuff into their own headers,
it helps finding out data and operations available related to them.
We already have similar classification in osmo-bsc.
Change-Id: I6424dcbd2e329fc1a516f8886359554ed7e9487e
It makes no sense to transmit load information if the channel is still
not operational. This solves errors messages seen in osmo-bsc.
Related: OS#4872
Change-Id: I7ddda9776158eed0694df9e458f3f91df90bf674
Have a more stable loop with less temporary oscillations at the expense
of increased reaction time.
4 SACCH blocks (P_CON_INTERVAL=2) is the minimum interval to get stable
measurements for the last requested MS Power level. With P_CON_INTERVAL=1,
are also made during a period with stable power being use to transmit,
but the MS Power level used (and announced in MR) is not the last one
requested by the BTS, but the one requested in the previous loop
iteration. This can make the MS and BTS bounce 2 values forth and back,
and create some temporary oscillation.
See osmo-bsc User manual section "Power Control" for more information.
Related: SYS#5371
Change-Id: I91c505447f68714239a4f033d4f06e91893df201
A broken BSC could send a Chan Activation on a TS which has not yet been
enabled (or even configured). This is the case with our TTCN3 tests,
where OML side is currently handled in parallel by an osmo-bsc while
TTCN3 takes care of the RSL side. This can actually be seen as a
malfunctioning BSC, but it was spotted that given this sequence of
events osmo-bts can crash (see ticket below).
Hence, let's NACK any attempt from a BSC to activate an lchan on a
disabled TS.
Related: OS#5249
Change-Id: I9c3b68487c12efc412a057728a561e061560c544
It helps better understanding the code, and will allow handling
situations where for instance a POWERON in in transit while the BTS is
instructed to shutdown, hence a POWEROFF needs to be sent.
Change-Id: Iaf62217ceab7420afa4140cba61e1c2f983c61b4
config.enabled is always true in that state. Hence, those paths can be
securely dropped since only add confusion.
Change-Id: Icf00c52e61ddedd8e32eb37223cea5686005e6a3
The first check in this function ensures that the state is NONE.
Therefore it does not make sense to print it below..
Change-Id: I62ea4117dd5e1eebb8774809134e5cb73774945c
This was colliding with the global "show trx" command introduced a few
years ago, and prevented both command from working.
Change-Id: I57f9515292f7bd906599e2cc277542bfaf3b657b
Related: OS#5080
Each RSL MEASurement RESult message contains a Measurement Number
IE, which is basically a monolithically increasing number. We
shall not increase this counter if for whatever reason the report
has not been sent to the BSC.
Change-Id: I441adb4b202e94ddee8c0b6777849e36ea644b1d
Fixes: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
Fixes: OS#5243
Avoid re-connecting to a new BSC while BTS is in shutting down. All the
FSMs are complex enough to even try to re-start when stopping has not
yet finished...
Change-Id: I1727828a16f4ec8043b00cc6b2e02a4c35f71377
Prior to this patch, the power ramping started when the PHY is
available, but that doesn't necessarily mean the RCARRIER is enabled.
Due to this, it was spotted a situation where BTS bootstrap failed after
PHY turning up, when RSL connection establishment failed. Hence
bts_shutdown_fsm triggered a shutdown while an active power ramping up
was ongoing...
Change-Id: I17208b74ea2649b1bbb717aee0aa355e42b7e860
This may happen if bts_shutdown starts a poweroff procedure while
POWERON was still not sent to the TRX. In this case, we want to go back
to initial closed state to fullfill expected state when BTS is shutdown.
Change-Id: Id660fa1018ef175ab237733b37629c56313c061d
Previous code creating a new line was really a workaround to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and keep using the
same line always (since it can be further configured by libosmo-abis' VTY).
Recent patches to libosmo-abis fixed a bug where e1inp_line_update()
would only work the first time it was called on a e1np_line, and follow
up calls would be no-ops. This fix allows re-configuring and hence
reusing the same line to reconnect to BSC.
Depends: libosmo-abis Change-Id: Iff8092f88726cf238dac2abb99e135ac5864272d
Change-Id: Id7fd3ef81bbc517821def31f1a60f905a0e2fb52
The temporary overpower value that is to be used with FACCH and SACCH is
transferred using a proprietary RSL IE (RSL_IE_OSMO_TOP_ACCH_CAP). The
parsed value is then stored in lchan->bs_acch_overpower_db so that it
can be used.
Change-Id: I426c2510865c4a986c68f2027cc676aaac0d8a4c
Related: SYS#5319
Only once we receive the Measurement Result on L3 from MS we are able to
find out whether DTXu was used, and hence whether SUB or FULL
measurement set should be used.
Let's move all control loops there to have them in one place together,
and have it at a similar level where it would lay if it was to be
implemented in the BSC.
Related: SYS#4917
Change-Id: Ic152473577ff7c33d30b3f4ee7e321fcb523f723
This is a preparation commit in order to move power loops up in the
stack in order to have DTXu information available, in order to decide
whether SUB or FULL ul measurements should be used in the MS Power
Control Loop.
Function rsl_tx_meas_res() is stripped from code changing state, and it
simply encodes content and transmits the message.
Change-Id: Id67259ec9ac4c2c33bd0eef3f64450affbe3fb9f
Recent commit added code to reset trx_provision_fsm state fields in orer
to support re-using the FSM once BTS is reconnected to a BSC.
However, some values being reset there are not set up when reconnecting
to the BSC, but rather configured through VTY at startup. Hence those
values should be kept.
Fixes: 32b51eca7d
Change-Id: I5c31241327b98386c313cd9377cf76c009456105
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
When I introduced this branch in change [1], I was under assumption
that PDCHs never have an associated 'struct gsm_lchan'. This is
incorrect: the association actually happens during PDCH activation,
i.e. when osmo-pcu establishes connection over the PCUIF.
Enforcing attenuation of 0 dB for other channel types makes no sense.
[1] I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Change-Id: I77a839725f22be1be4a025f579c4c9ccdfb53460
There is no need to log channel activation / deactivation messages
as LOGL_NOTICE - this is a normal event requiring no attention.
Change-Id: I7765fecb7f7ec67c8f96e91c378626e21e48c71d
Thanks to [1], there is no need to patch chan_nr for PDCH anymore.
The upper layers are now expected to use the correct values.
[1] I01680140c7201bf5284b278bceaea8ae01c122b2
Change-Id: I26eb2081eddb4ce900a7867897bc69c3f77dbd73
Related: OS#5238
The ip.access style dynamic timeslots are a bit special in a way that
on the A-bis/RSL we always use the Channel Number value of TCH/F,
even in PDCH mode. This is why gsm_lchan2chan_nr() would always
return values corresponding to TCH/F for TCH/F_PDCH.
This behavior is only acceptable in the context of RSL messages, while
other parts of the code base may not work properly due to this trick.
A good example is the scheduler in osmo-bts-trx, where we have to
patch Channel Number value to make channel activation work.
DPCU INFO pcu_sock.c:853 Activate request received: TRX=0 TS=5
DL1C INFO l1sap.c:2043 (bts=0,trx=0,ts=5,ss=0) Activating channel TCH/F on TS5
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PDTCH
DL1C NOTICE scheduler.c:1097 (bts=0,trx=0,ts=5,ss=0) Activating PTCCH
In the code branch responsible for channel deactivation, we somehow
forgot to add the same workaround, so deactivation does not work:
DL1C INFO l1sap.c:2076 (bts=0,trx=0,ts=5,ss=0) Deactivating channel TCH/F on TS5
DTRX INFO trx_if.c:255 phy0.0: Enqueuing TRX control command 'CMD NOHANDOVER 5 0'
DRSL NOTICE rsl.c:1286 (bts=0,trx=0,ts=5,ss=0) (bts=0,trx=0,ts=5,ss=0) not sending REL ACK
Because of that, TCH/F_PDCH timeslots actually remain active after
deactivation, so the scheduler keeps producing L1SAP DATA.ind.
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583426/1194/00/29/14 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DL1P ERROR l1sap.c:732 1583430/1194/04/33/18 No lchan for DATA MEAS IND (chan_nr=PDCH on TS5)
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
DL1P NOTICE l1sap.c:126 (bts=0,trx=0,ts=5,ss=0) assuming active lchan, but state is NONE
DPCU NOTICE pcu_sock.c:973 PCU socket not connected, dropping message
Instead of patching Channel Number in various places, let's rather
make the RSL specific behavior configurable by having two variants
of gsm_lchan2chan_nr().
Change-Id: I01680140c7201bf5284b278bceaea8ae01c122b2
Fixes: OS#5238
LOGPLCHAN() prepends the contextual information for us, there
is no need to print trx->nr again. Take a chance to apply
some additional cosmetic changes, like fixing capital letter.
Change-Id: Ia199d584c937eef4118c99af4523fd91b2e46107
In functions responsible for Downlink burst scheduling, it may happen
that the buffer, containing a complete set of to be transmitted bursts,
a) is not yet allocated or b) was de-allocated intentionally. In this
case, we return early to avoid NULL pointer dereference. The returned
value is then checked against 0 in _sched_dl_burst().
Returning 0 makes _sched_dl_burst() apply per-burst attenuation, as
well as the A5/x encryption (if enabled). And this makes no sense
in either of the cases mentioned above.
Moreover, in the BCCH power reduction mode, this causes some bursts
(bid > 0) of idle PDTCH/PTCCH blocks to be transmitted at full power,
breaking the energy saving feature.
Change-Id: I18aa73cc950fdfac030b63f7a434a71b4596095d
Related: SYS#4919
osmo-bts-omldummy is known to be specially in the sense that it has no
phy. This should ideally be changed to have some dummy object, but so
far that's how it is. A recent commit checking the phy's forgot about
the fact that BTS model has no phy. Let's fix it.
Fixes: 4ddc37ce71
Change-Id: Iba7873530aac74b3bf799819890641196dacf170
Previous code creating a new line was really a workaroudn to have it
working while previous lines were being stacked internally inside
libosmo-abis.
Let's handle reference counts for the line properly and erase +
re-create it every time.
Recent patches to libosmo-abis fixed a crash happening when refcount
being 0 and destroying the object (object was not removed from a global
llist).
Depends: libosmo-abis Change-Id I1314d6b917ecb622994507475eb894e649a1a2ad
Change-Id: Ic37ae5bf657247e8cce99182c40d9adf890a5e41
Commit below (see "Fixes" section) wrongly erased the code re-introduced
in this commit, due to not spotting different between "oml_link" and
"osmo_link". This commit is hence a revert of such commit, updated to
current code.
Fixes: c2ba34d9c1
Change-Id: Id436116e5cd0bec024b2f9943fbff8d0bdc956ac
This function is only called during sign_link_up() e1inp callback, hence
only the link!=NULL condition (UP) is ever executed. Let's drop the DOWN
path and make it a function only used to trigger events when link
becomes up, similar to what bts_link_estab() does with OML.
Here it becomes clear the NM_EV_RSL_DOWN was never sent. It's not much
of an issue though since it would only make transition RCARRIER/BBTRANSC
Enabled->DisabledOffline. However, since due to libosmo-abis limitation
we receive a sign_link_down() for the entire line when 1 of its links
goes down, we don't care much since we go for shutdown of the entire BTS
anyway. Ideally, libosmo-abis would support simply telling us 1 of the
links in the line went down and if it was not OML and not RSL TRX==C0,
then we could keep on running and simply disable the related TRX.
Change-Id: Iac553c68339c0da32fd313676995747eb4344087
This feature is not yet used by any bts_shutdown_fsm caller, but will be
used in the future when Abis link goes down.
Change-Id: I5dc282fdbcf862067be326e72b6183dd544222ae
Since recently we support shutting down phys when BTS goes into shutdown
mode. Let's make sure they are opened again when we connect again to the
BSC.
Change-Id: Ia1df6f4a1e0e6daeffe7303d518776a04b023930
This step is required while turning off the BTS without killing the
process. Right now only osmo-bts-trx supports this feature, so this
function is only available and used by osmo-bts-trx.
Later on, when the feature is support more generally, we can move call
to this function to common place like bts_shutdown_fsm or alike.
Change-Id: I3253112700a31b85db82dc7ccadec8542bac745e
Once the TRXC link is available, we can signal SW_ACT which will
transit rcarrier and bbtransc NM FSMs to Disabled Offline and announce
availability to be configured to the BSC through transmission of
Software Activated Report.
Change-Id: I6e62ec2fdd4cae58b52d83fa851552f7ed51c821
In OML, if Set Attributes comes first for Channel object and then for
BTS object, BSIC will still not be set. Hence, when applying Channel
(TS) specific TSC, the code would compare against an unset value,
enabling use of TRXC extensions (which osmo-trx doesn't support)
without need for it, since actually the TSC of the TS matches the BSIC
of the BTS once both are set.
In order to fix it, don't check for the BSIC when receiving the OML
messages, but rather later when we apply the settings to the the lower
layers once trx_provision_fsm allows for it.
Fixes: 3c1151f945
Change-Id: I49fc7e35acb44ecc4f37ae71acd4c684248548e7
This way the PCU can signal idle RLCMAC blocks (no transmission
required) to the BTS, which can then send dummy/fill blocks aplying
power reduction as needed by TRX.
The block with len=0 is submitted to lower layers up to the scheduler,
which will finally drop it in trx_sched_ph_data_req().
Change-Id: I734c66e236bf3e2015a4571ea1fd84849a9ef02c
Related: SYS#4919
This way we provide an effective way to disable C/I based decision
taking in the MS Power Control Loop. With this set up, MS Power Level is
decided only based on RxLev. This allows for working setup in following
scenarios:
* BTS L1 not passing proper C/I values to upper layers (eg. TRXDv0).
* User not willing to spend time configuring proper C/I levels for each
channel type.
Related: SYS#4917
Change-Id: Ibd10eb96a5d072d5c19f7449a8b11e64aad1cd4c
Get rid of this helper function, which is a remain of past epochs
(pre-FSM). In the current uses, there's only 2 real cases: the "if" path
upon SET BTS ATTR received (and even that one should be moved as per
what the code comment states), and the one happening when the TRX is
closed.
it really makes no sense to DISABLE the TRX as a result of SET BTS ATTR.
Change-Id: I48adfeecd722684152c589bcba827079b0a78c3a
In oml_rx_set_bts_attr, arfcn for C0 is assigned from NM_ATT_BCCH_ARFCN.
The rest of the TRX get their arfcn from oml_rx_set_radio_attr()
NM_ATT_ARFCN_LIST.
Change-Id: I8aa9652622107fe0a707b2cbcbe8be6c71e19087
This will allow in the future advertising children objects that the
parent object has been configured. It is useful for instance to let TRX
know that the BTS is configured.
Change-Id: Ie319465fd0e991bab8451ea34ec72ff3702533d2
There's no real use for this queue. If the link is gone, it makes no
sense to keep old messages. Instead, BTS should generate new messages
sharing current state when link becomes established (it actually does
so already).
Change-Id: Iecd3c7cb96f5fff3b4c7e04c74e031df0f7a6987
This way it can be changed together with operative/availability state,
and changes announced to the BSC if present.
This commit presents no real change in osmo-bts behavior, since the only
place where adm_state is passed different than -1 is in
st_op_disabled_notinstalled_on_enter(), which is actually never called
(yet) since it's the initial state and no other states transition later
to it.
However, this will change in the future once we support re-connecting to
a (possibly different) BSC, which means objects will need to be moved to
that state to restart the whole OML install procedure on the new BSC.
Change-Id: Ifdc6a1dfb673c0ab915ddf2a9d372928f4f86b4c
Do not exit if all BSCs in the list fail to connect, keep trying
forever. This commit still doesn't change the logic after BTS has
successfully connected to a BSC. In that situation, if the link goes
down, BTS will exit in order to reset all state and let the user/system
restart it.
Related: SYS#4971
Change-Id: I67bba3b7e2d9d62b98a59a74987ae55206a3ec51
The pointer was used as "struct bsc_oml_host" sometimes, and other times
as "struct llist_head". It just worked because bsc_oml_host->list is the
first item in the script. The code was really confusing, also because
the bts list of items has a name really similar to the one currently
assigned. Let's rename the currently assigned address to "current_bsc",
store it always as "struct bsc_oml_host*" and finally use llist_entry
helpers when needed.
The related code is also moved to a helper function to enclose there the
logic to get next BSC in list. This change actually changes the logic
where a remote address is removed from VTY, since now the next address
in list is picked at the time, and later when reconnecting the list is
forwarded another time, meaning one address will be skipped.
This could be considered a bug, but this situation is really special
and anyway the entire logic will be changed in new commits where we'll
keep reconnecting in loop without exiting when reaching the end of the
list, so we are fine with it. Think of this commit as a preparation
commit for next ones.
Change-Id: I3cc8a4148b3d63bc185b72dab8108105a6644910
This clarifies the different states and transitions between them:
OML LINK UP: CONNECTING->CONNECTED
ANY LINK DOWN: CONNECTING->CONNECTING, CONNECTED->FAILED
In follow up commits, support to reconnect instead of exit after the BTS
has already connected will be added, so only the last transition needs
to be changed.
Related: SYS#4971
Change-Id: I43e83b1b04fbaa1f87818c096e6ad3920801b1f6
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
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
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
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
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.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
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
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
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
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
If RxQual is considered good enough, attenuation can be increased in
order to lower overall cross-channel noise among different MS.
Change-Id: Ie97898980acd152de15f6b4b619d492048855ef4
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
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
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
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
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
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
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: 9238c3549d
Related: SYS#4918
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
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
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
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
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
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
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
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
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
They will gain support to be activated as SDCCH/8 soon too.
Related: SYS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Ia617d20fc52f09dbab8f4516c06fa1efac08e898
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
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
This is required for ttcn3-bsc-test, see change [1].
Change-Id: I765d5e38cb0746e0458773abf3717ee9bf1cb7d1
Related: [1] I084f7736cd7d09b68ed49f8ba52a14de928d4c01
Related: SYS#4919
This reverts commit cd30a40be1.
As a part of SYS#4919 "BTS energy saving", we want to support
constrained (up to 6 dB) BS power control on BCCH carriers.
Change-Id: I0d2b48c4b2af2d8e94f4ad02fa4774dbd0a0a654
Related: SYS#4919
This new extension protocol is used to forward Osmocom PCUIF messages
BSC<->BTS<->PCU.
It will be sent re-using the IPA multiplex of the OML link between
BSC and BTS. BTS is responsible for forwarding the message over the unix
socket to the PCU.
PCUIF existing RX path needs to be reworked in order to accept
variable-size messages, in order to be able to transparently forward
messages without knowing about them (the new container message is
variable-length).
Related: SYS#5303
Change-Id: I73fdb17107494ade9263a62d1f729e67303fce87
I introduced this regression in [1] during a massive refactoring.
Basically, I copy-pasted a chunk from trx_sched_ph_data_req(), but
forgot to change the union field. This broke voice calls, because
all TCH.req primitives would be enqueued to wrong timeslot.
Change-Id: If841e6ac40a3c6344c304ab970755d6a2d292156
Fixes: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
The PDCH multiframe contains 48 data slots, 2 PTCCH slots, and
2 IDLE slots. The later two can be used for the interference
measurements, since the UEs shall not transmit on them.
bts_report_interf_meas() is called every 104 TDMA frames, what
corresponds to 2 PDCH multiframe periods. Report interference
levels on PDCH timeslots from this function.
Change-Id: I56f83db5264c246ec1b4b8a973105a4fc09931fb
Related: SYS#5313, OS#1569
We already do the intereference measurements on inactive logical
channels. For the active channels we can still use the IDLE
slots, on which the UEs shall not transmit Uplink bursts.
Change-Id: Ic3030dba5eb223177298aa4e43559a93dc3d1392
Related: SYS#5313, OS#1569
Neither we expect any Uplink bursts on IDLE channels, nor we need
to send any Downlink bursts. Automatic activation of TRXC_IDLE
channels does not make sense.
Change-Id: Ifade0eab0605154196322ff20b1b3a44495f8a2e
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped
to inactive logical channels as interference. Average the RSSI
values on the fly using a sliding average with constant a=0.5.
Report averaged values for each logical channel every 104 TDMA
frames (SACCH period) by calling gsm_lchan_interf_meas_push().
Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5
Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c
Related: SYS#5313, OS#1569
With the new ordering, all TRXC_* values starting from TRXC_TCHF
belong to dedicated channels. This is useful for the interference
reporting logic, where we're not interested in broadcast channels.
Change-Id: I7148f4d0bd1abbfe309bc5477e32a56d884533ea
Related: SYS#5313, OS#1569
This change implements general interference averaging logic for
the higher layers. In l1sap_info_time_ind(), where we receive
TDMA time updates from BTS model, call rsl_tx_rf_res() for each
transceiver according to the interval defined by the Intave
parameter received from the BSC. In rsl_tx_rf_res() perform
the actual averaging for each inactive logical channel, and
then send everything to the BSC over the A-bis/RSL.
The BTS model specific code needs to report the measurements
for each logical channel every 104 TDMA frames (SACCH period)
by calling gsm_lchan_interf_meas_push().
Change-Id: Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Looks like this part of the code has never been tested. The old
code would dereference the same value in the loop and assign it
to all members in array 'bts->interference.boundary'.
Change-Id: I7f83d8e6eb6cc19e3e9529ba06617a902de23e35
Related: SYS#5313, OS#1569
OsmoPCU will need this SI2 in order to gain knowledge of the BCCH
Frequency List being broadcasted, in order to build a per-MS specific
Neighbour List using NC_FREQUENCY_LIST bits in Packet Measurement Order.
Related: SYS#5303
Change-Id: If70c64f941f621a9a68aef2c846639b5c7f2f74b
In cfg_trx_phy_cmd(), use phy_instance_link_to_trx() and ensure
that a PHY instance can be bound to a transceiver only once.
Change-Id: I132e08fc496abef278b94254cebfac7a4285a7c2
Thanks to [1], it's now possible to associate a human-readable
name with a rate counter group. Before this API, we had to use
weird index values for each timeslot, and with introduction
of the shadow timeslots the situation got even worse.
Change-Id: Ie872ab37661fa5d44f219f59c7daaa1033113289
Depends: [1] I0dc510783dd9ae8436dae8005a7b3330e80d36f3
Related: SYS#4895, OS#4941
The timeslot number ts->nr is set in gsm_bts_trx_alloc() and can
never be greater than 7. Regarding the physical channel type
returned by ts_pchan(), it's also unlikely to be greater than
_GSM_PCHAN_MAX.
Change-Id: I6d20d7cba49cc8b6d1dc2192598ca372b7d2c5bf
This function is called during the OML bootstrapping, and also
when a dynamic timeslot switches between PDCH and TCH/{F,H}.
In the later case, after switching from TCH/{F,H} to PDCH, some
lchans might still have the old type assigned.
Let's ensure that all logical channels are properly updated.
Change-Id: I44726f2bfb979c2fa2f5f30c5b11700cf4b3399d
Related: SYS#5313, OS#1569
This regression was introduced (by me) in [1] and broke CCCH.
Change-Id: I403ad06574a8505b69dd06781f7fe0f7cabf416f
Fixes: [1] I1c5a033e89d9ca5fb01ebe9ffb521fd67d159bee
Related: SYS#4895, OS#4941
Using the normal arithmetic for TDMA frame numbers may result
in getting wrong values. Consider the following situation:
'info_time_ind->fn' is 0 (beginning of period)
'bts->gsm_time.fn' is 2715647 (end of period)
With these input values the following expression:
info_time_ind->fn - bts->gsm_time.fn
will be equal to:
0 - 2715647 or -2715647
In this case osmo-bts does not log an error, because:
if (-2715647 > 0) // is false
As a consequence, we do not increment number of RACH slots that
have passed by since the last time indication:
for (i = 0; i < -2715647; i++) // is false
This is why we introduced GSM_TDMA_FN_{SUB,SUM,DIFF,INC} API.
Change-Id: I6168dd75daea50bbe2e19338e637185ac9ac87ef
There is no GSM_PCHAN_TCH_F{_TCH_H}_PDCH in trx_sched_multiframes[],
so find_sched_mframe_idx() would always return -1 for these. Fix
this by using ts_pchan(), which returns currently active pchan type.
Change-Id: Ia5e337e897b595e7de6e504664c969b583cc02a1
Starting from TRXDv2 [1], trx_if_send_burst() would keep batching
PDUs to the static buffer, unless it's called with br = NULL, so
we cannot dereference br in the logging statement.
Of course, we could also store TDMA frame number in a static
variable, but I don't think it's worth it just for logging.
Change-Id: I4a361777fc40bdedcebbe54df6274bc5573f77a8
Fixes: [1] I9b4cc8e10cd683b28d22e32890569484cd20372d
Fixes: CID#236232
This is an Osmocom specific RSL IE that, if present, takes
precedence over the values indicated via the A-bis/OML.
Change-Id: I717e5b2a6ca5b4faeaab9cae4bb971907945871b
Related: SYS#4895, OS#4941
Each timeslot can have its own Training Sequence Code value, which
may optionally be included in the NM_MT_SET_CHAN_ATTR message sent
over the A-bis/OML. If it's not present, then the TSC value for a
timeslot is derived from the BCC part of BSIC, which is always
included in the NM_MT_SET_BTS_ATTR message.
On the TRXC interface, the BTS global TSC value is indicated to the
transceiver using either of the 'SETTSC' or 'SETBSIC' commands.
The transceiver then applies this value for all timeslots by default,
however it can be redefined for each timeslot individually using
additional arguments of the 'SETSLOT' command (see section 25.2.4.1
in the user manual [1] for more details).
Currently, trx_set_ts_as_pchan() sends TRX_PROV_EV_CFG_TSC to the
transceiver provisioning FSM, together with the per-timeslot TSC
value. This event causes the FSM to modify the global TSC value,
that is going to be or has already been sent to the transceiver.
This is wrong, the global TSC value shall not be overwritten.
Remove the TRX_PROV_EV_CFG_TSC, and include per-timeslot Training
Sequence Code and Set in the data structure that gets passed together
with the TRX_PROV_EV_CFG_TS instead. Implement handling of the
optional per-timeslot TSC in trx_if_cmd_setslot().
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: Idc5796151e3e83f42d60c2d4cb7c35890d76a7f5
Related: SYS#4895, OS#4941
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
The model name when used when abis_open() is called is sysmoBTS, since
we recently decided to deprecate the type name "sysmobts" in osmo-bsc we
might consider the same thing here.
Change-Id: I3c61d92f5527ae0145316b5ff92660f8b467a8dc
Ensure that we check the PHY capabilities in both cases:
* RSL CHANnel ACTIVation, and
* RSL CHANnel MODE MODIFY,
by calling bts_supports_cm() from rsl_handle_chan_mod_ie().
Modify bts_supports_cm() to accept a 'struct rsl_ie_chan_mode',
so we can handle VAMOS enabled channel modes and CSD later on.
Change-Id: I31a444592436705ec9d6ddade3cbfa7f8cb4bb91
Related: SYS#5315, OS#4940
For some reason, handling of the Channel Identification IE was done
in l1sap_chan_act(). This function is being called on reciept
of the CHANnel ACTIVation message, but not on MODE MODIFY.
Change-Id: I07f95e69e6230a1daca62cc0a7c64954f191fa8a
Related: SYS#5315, OS#4940
This change implements TRXD PDU batching approach b), which is described
in section 25.3.4 of the user manual [1]. This approach is quite easy
to implement on the transceiver side, so we can enable it by default.
.Example: datagram structure for combination b)
----
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=0 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=1 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=2 | BATCH=1 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------+----------------+---------+------------------------+
| TRXN=N | TDMA FN=F TN=7 | BATCH=0 | Hard-/Soft-bits |
+--------+----------------+---------+------------------------+
----
Other PDU batching approaches can be introduced later.
[1] https://downloads.osmocom.org/docs/latest/osmobts-usermanual.pdf
Change-Id: I9b4cc8e10cd683b28d22e32890569484cd20372d
Related: SYS#4895, OS#4941
The path to the temperature sensor was wrong which
results in the SysmoBTS manager always considering
that the state is critical and hence powering OFF
the PA on startup. (with the default config)
As a further side-effect, the temperatures were not
available in the vty 'show manager' command.
Redacted log previous to this patch:
sysmobts_misc.c:128 Error reading temperature
sysmobts_mgr_2050.c:323 Going to enable the PA.
sysmobts_mgr_temp.c:252 Failed to read the digital temperature. rc=-1
sysmobts_mgr_temp.c:267 Failed to read the RF temperature. rc=-1
sysmobts_mgr_temp.c:203 Moving from state NORMAL to CRITICAL.
sysmobts_mgr_temp.c:185 System has reached critical warning.
sysmobts_mgr_temp.c:236 OML alert sent: 0
and in the vty:
Temperature control state: CRITICAL
Current Temperatures
Digital: -0.001000 Celsius
RF: -0.001000 Celsius
With this patch we correctly enable the PA and now can show in the vty:
Temperature control state: NORMAL
Current Temperatures
Digital: 39.000000 Celsius
RF: 35.125000 Celsius
Change-Id: Iac8e9a866ad6326874af91bd12a981f39a9a24c7
In [1] I forgot to update tx_fcch_fn(), where we assume that the
burst buffer is already zero-initialized and do not call memset().
This results in sending dummy bursts on FCCH (instead of zeros).
Change-Id: I491b3b5702b3cfca45c12c002b41e60c629b05b9
Fixes: [1] Iec78989517865b3275a9784d1042a5ebd1d2815f
Currently, in bts_sched_fn() we send a Downlink burst to the PHY
immediately after calling the associated logical channel handler.
Together with the obvious performance advantages, this approach
imposes some serious limitations. The code has already become
quite complex with the introduction of the baseband frequency
hopping, and now it's not possible anymore to extend it further.
TRXD PDU batching, which is essential for VAMOS implementation,
requires us to make the scheduler more flexible at the expense of
increased memory consumption and additional CPU cycles. This patch
splits up Downlink burst scheduling into 3 main steps:
1. bts_sched_init_buffers(): initialization of per-TRX Downlink
burst buffers allocated by phy_instance_create(). For C0/TRX0
all timeslots are pre-initialized with dummy burst.
2. bts_sched_fn(): generating burst bits for all active lchans.
3. bts_sched_flush_buffers(): sending everything to the PHY.
This approach allows us to a) get rid of the ugly tail in bts_sched_fn()
that was responsible for sending dummy bursts on C0/TRX0; b) implement
the PDU batching and have several variants of bts_sched_flush_buffers()
providing the alternative batching approaches later on; c) implement
PDU merging for the upcoming shadow transceivers.
Change-Id: Iec78989517865b3275a9784d1042a5ebd1d2815f
Related: SYS#4895, OS#4941
BCC takes 3 LSB bits of the BSIC, so we should apply 0b111 or 0x07.
The BSIC is specified in 3GPP TS 03.03 section 4.3.2.
Change-Id: Id24ad64e6c6de080ab43faa272daf844fbba6954
Related: SYS#5315, OS#4940
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
In change [1] together with the actual implementation I introduced
a serious bug to bts_sched_fn(): if a timeslot is configured to use
frequency hopping, both 'pinst' and 'l1h' pointers are *overwriten*
in the inner loop, so the Downlink burst is re-directed to the
approproate PHY instance. However, if a subsequent timeslot is not
hopping, the Downlink burst would be re-directed to the wrong PHY
instance because both pointers were overwriten during a previous
iteration.
Let's move the 'struct phy_instance' pointer to the inner loop, so
it's properly re-initialized for each timeslot iteration.
Change-Id: I9afbbef8dc5d885763356470c27d4392dce8e815
Fixes: [1] I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
trx_phy_instance() does assert() that the given TRX pointer is
not NULL. In bts_sched_fn() it can never be NULL, so drop it.
Change-Id: I896ff5117588f2229cc54619ce62fd027a9ef25f
lower layer specific APIs require first to enable the TRX object
(GsmL1_PrimId_MphInitReq, which requires ARFCN received during Set
Radio Carrier Attributes) before enabling the per-TS structure.
Hence, OPSTART must happen in RCARRIER MO before OPSTART can be sent to
the Radio Channel MOs, otherwise the initialization of the TS objet will
fail and OPSTART for the RadioChannel MO will send back a NACK.
In order to avoid this, we need to keep the RadioChannel MO announced as
"Disabled Dependency" until RCARRIER is OPSTARTed.
Related: OS#5157
Change-Id: I8c6e5ff98c32a3cd5006f5e5ed6875bcabb1d85f
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
gsm_bts_trx_alloc() already does initialize some fields of the
allocated 'struct gsm_bts_trx' instance, and having an additional
function for initializing the other fields makes no sense.
Note that I intentionally didn't merge a call to bts_model_trx_init()
into gsm_bts_trx_alloc(), because this would break some assumptions
regarding the order of initialization and cause regressions.
This also allows us to not call bts_model_trx_init() from tests.
Change-Id: I4aefaf47b05a67ec0c4774c1ee7abcc95e04cc13
First of all, there is no reason to use a void pointer because
it's always 'struct phy_instance'. Also, no need to encapsulate
this pointer into 'role_bts' because there are no other roles in
osmo-bts (we used to have shared headers years ago).
This commit also fixes a bug in test_sysmobts_auto_band(), where a
pointer to 'struct femtol1_hdl' was directly assigned to trx.pinst.
Change-Id: I9bd6f0921e0c6bf824d38485486ad78864cbe17e
For a long time, we see this annoying -Wstringop-truncation warning:
In function ‘parse_rsp’,
inlined from ‘trx_ctrl_read_cb’ at trx_if.c:647:6:
trx_if.c:416:2: warning: ‘strncat’ output may be truncated copying
between 0 and 45 bytes from a string of length 1495
416 | strncat(rsp->cmd, buf_in + 4, p - buf_in - 4);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is no real need to use strncat() in parse_rsp(), because we
do not concatenate any strings but simply copy TRXC response parts
from the input buffer to the corresponding 'name' and 'parameters'
buffers. Let's use memcpy() instead. This also fixes the warning.
Change-Id: Ia10adf7d76abe9a423b07e828852fbfb53b95125
We need curly braces becausee1inp_line_get2() is basically a macro
that calls OSMO_ASSERT(), which in its turn contains an 'if' stmt.
Change-Id: I41a5fd13a7fa40e16bcf1a8099624b654274cee3
If the PHY is not powered on and we are not supposed to send any
bursts to it, then trx_if_send_burst() should just return early.
Change-Id: I578bd5a731ad88ebff283c75bb7eb268d9e7e787
Related: SYS#4895, OS#4941, OS#4006
If somehow the TRXC logic negotiates a non-supported TRXD PDU version,
then it's a serious bug in the code. Let's add an assert() for that.
Change-Id: I301377bcebd5e2bbcfc18b3637253ef261bb5b2e
Starting from TRXDv2, several PDUs may be batched together and sent in
all together a single datagram. This requires us to increase the buffer
size that we use for sending and receiving TRXD messages. Let's use
65536 matching the default MTU value for 'lo' interface on Linux.
Given that 65536 is quite a big number, let's allocate a shared Rx/Tx
buffer statically to avoid [potential] stack overflow.
Change-Id: I729451c8ecdc7ff2631beb423f15523db16b3ee3
Related: SYS#4895, OS#4941, OS#4006
This is a preparatory change for the upcoming TRXDv2 support:
* move common TRXDv0/v1 header parser into a separate function;
* move burst handling into a single, version independent function;
** determine modulation and burst length in trx_data_parse_pdu_v0();
Change-Id: I7aedd85a8d4f6d6191cd3b75272a688208fb2879
Related: SYS#4895, OS#4941, OS#4006
This significantly simplifies setups in which not only the IP DSCP
but also the IEEE 802.1Q PCP is to be set for RTP packets.
Depends: libosmo-abis.git I52c08f4b2a46981d002ef0c21e6549445d845a6e
Change-Id: Ia3a91e6788285be3e2e73defee63e6bd79c6258e
Related: SYS#5427
The current usage is to make osmo-bts-omldummy indicate BTS_FEAT_VAMOS
on OML, so that we can test osmo-bsc's behavior when VAMOS is enabled.
Related: SYS#4895
Depends: I699cd27512887d64d824be680303e70fff3677c1 (libosmocore)
Change-Id: Ib50990109f07884ef999ba5a4566f5d1d457b0ae
All these functions need the PHY instance pointer for logging,
they don't really need a pointer to 'struct trx_l1h'.
Change-Id: I626b4392a8bc57a3fe5e8c931aa1ce9dd505676c
Related: SYS#4895, OS#4941, OS#4006
The 'CHDR' stands for 'Common Header', but this does not apply to
TRXDv2 because TDMA frame number may not be present in the batched
PDUs. Let's avoid potential confusion by removing it.
Change-Id: I80495df474c432f4c0a4cfa6f917821d7b35859a
We do have TRXC/TRXD documentation in osmo-gsm-manuals repository.
This big comment is out of sync with what we have in the manuals,
so let's better remove it to avoid maintaining docs in several places.
Change-Id: Ibfcefcbb5f30fe9b6c691578a93e6fedd5644b30
Related: SYS#4895, OS#4941, OS#4006
TRXDv2 brings significant changes to the whole PDU structure, not
just the header. Let's highlight this in the code / strings.
Change-Id: Id0274bd1ae5c419548596ed1852e6a28ec62b713
Related: SYS#4895, OS#4941, OS#4006
New channel mode values have recently been added with change [1]
to 'enum gsm48_chan_mode'. The lack of default branch in
lchan2lch_par() caused build failures on Jenkins:
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V2_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V3_VAMOS’
not handled in switch [-Werror=switch]
oml.c:956:2: error: enumeration value ‘GSM48_CMODE_SPEECH_V5_VAMOS’
not handled in switch [-Werror=switch]
This function is duplicated in osmo-bts-{lc15,oc2g,octphy,sysmo},
so we unfortunately need to apply the same fix to all copy-pasted files.
Change-Id: I557ff8cac6564d22485c101fba9212f5f0e95bb7
Related: [1] Ie0ea592da5610ae70290106d004e549cf3212a89
In change [1] I added the missing 'default' branch to the 'switch'
statement in lchan_tchmode_from_cmode(). This caused massive
regressions in ttcn3-bts-test, because osmo-bts started to NACK
some RSL CHANnel ACTIVation messages.
What caused a lot of regressions in ttcn3-bts-test is actually the
missing branch for RSL_CMOD_SPD_SIGN in the 'switch' statement.
It was not a problem before [1], because the 'default' branch was
not there. I was about to add the missing 'cause' when I realized
that this function needs to be reworked first...
First of all, lchan_tchmode_from_cmode() does a bit more than just
deriving RR (TS 44.018) channel mode from RSL (TS 48.058) channel
mode. It additionally stores the 'Speech or data indicator' to
the logical channel state, and also changes some global DTXd related
flags in 'struct gsm_bts'. Let's use a more precise name.
lchan_tchmode_from_cmode() -> rsl_handle_chan_mod_ie()
Together with renaming, it becomes logical to have the IE presence
check in rsl_handle_chan_mod_ie(), so that we can reduce code
duplication in the calling functions a bit.
Finally, the main problem is that coding and interpretation of the
6-th octet 'Speech coding algor./data rate + transp ind' depends on
the 4-th octet of the Channel Mode IE. We cannot handle all values
in one 'switch' statement without proper discrimination:
a) If octet 4 indicates Speech, then octet 6 shall be interpreted
as the GSM speech coding algorithm (FR, HR, AMR, etc.).
b) If octet 4 indicates Signalling, then octet 6 shall be set
to '00'O, because this is the only value defined in version
16.0.0 of 3GPP TS 48.058. All other values are reserved.
c) If octet 4 indicates Data, then octet 6 shall be interpreted
as CSD data rate further discriminated by service transparency.
Therefore, we need take both values into account. This can be
achieved by mixing them together using the bitwise operators,
just like we do in L1SAP code.
Change-Id: Iba967f5bd0cc8ad6cd3ccd40cca38b15ffe96b2c
Related: [1] I67a70132999be6580a29e6b814763309a6df4ae9
Related: SYS#4895, OS#4941
In [1] I introduced a regression, so osmo-bts started to complain:
This PHY does not support lchan TSC 3 != BSIC-TSC 7
on channel activation, despite the TSC in RSL_IE_CHAN_IDENT was 7.
The problem is that this statement:
cd = (const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT) + 1;
is basically equivalent to:
cd = ((const struct gsm48_chan_desc *) TLVP_VAL(tp, RSL_IE_CHAN_IDENT)) + 1;
so we actually shift the pointer by sizeof(struct gsm48_chan_desc)
and skip 3 octets instead of just one (IEI octet). Fix this.
Change-Id: Ic3a81396b60577e03c541d32839d07dc6d45c838
Fixes: [1] Id100f4c56fd5c1adad5d925d97240bed82981b9b
Fixes: OS#5121
* Calling l1if_provision_transceiver_trx() yelds nothing.
* It does not apply immediately, full restart required.
Change-Id: I93c9e19d0543f19528cec842b8be332b4d93214e
As the prefix in 'GSM48_IE_CHANDESC_2' implies, this IE belongs
to 3GPP TS 04.08 (or TS 44.018), so it can be used in the Radio
Resource assignment messages sent to the MS. While in this
function we're dealing with 3GPP TS 48.058, and thus the IEI
may be (and actually is) different for the RSL messages.
Also, according to 3GPP TS 48.058, section 9.3.5, the Channel
Description IE is included together with its element identifier,
so we need to skip one byte when doing the pointer casting.
Change-Id: Id100f4c56fd5c1adad5d925d97240bed82981b9b
Related: SYS#4895, OS#4941
Instead of blindly assuming what the PHY does support, and what
it does not, let's check the related feature vector.
Change-Id: I699cdddbfab111855998853548d9cfe956f7c60c
Related: SYS#4895, OS#4941
If for whatever reason it fails to initialize the TRXD or TRXC
interface, trx_phy_inst_open() would return an error. This
would cause bts_model_phy_link_open() to call trx_if_close()
on each of the PHY links, including those that were never
opened. This leads to a segfault in trx_if_close().
Make sure that in trx_if_init() we properly init 'struct trx_l1h',
so it's safe to call trx_if_close() at any time and in any state.
Change-Id: I1f128813528f505fede04799e84456f6271058d0
The measurement results / TCH indications that are handed when decoding
the TCH/H are off by two bursts. Since a measurement result / TCH block
is expected every two bursts anyway the problem can only be noticed when
a FACCH transmission is going on and the frame numbers of the BFI TCH
blocks appear to be missaligned towards the FACCH block.
The reason is that the incoming bursts are shifted into a 6 burst wide
buffer. The decoding functions always look at the beginning of that
buffer while the bursts are shifted into the buffer from the end. A
facch will always fit exactly in that buffer but TCH/H blocks are only
4 bursts wide and thereofre they need two additional bursts until they
reach the coverage of the decoding function. Lets fix this by putting
the correct frame number (from two bursts before) into the remap
functions in order to get the correct beginning of the block.
Since the FACCH transmission uses six blocks it takes out two TCH
blocks. This means that if we count the FACCH block we end up with a gap
of one TCH voice block. Lets generate a dummy measurement to compensate
the gap. This will also match the behavior of the osmo-bts-sysmo phy.
Change-Id: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
Related: OS#4799
By reordering the instruction, we scheduler the timerfd prior to
processing the FN on the upper layers. This means the first timerfd
expiration even will happen more inline with the expected time, that is,
CLOCK IND time + GSM_TDMA_FN_DURATION_nS.
Let T(trx_sched_fn) be the time spent executing function trx_sched_fn().
With previous order, the timerfd would have been scheduled later, which
in the end would mean expiration would happen at time CLOCK_IND +
GSM_TDMA_FN_DURATION_nS + T(trx_sched_fn), hence ending up with an extra
skew of T(trx_sched_fn) added by ourselves.
This extra skew added may be important specially at startup time (when
this code path is used), since usually the load in the system is high
and skew is usually already higher, which means helping crossing
unacceptable thresholds which may end up in osmo-bts-trx stopping with
"No clock from osmo-trx" reason.
Change-Id: Ie2ba35cd87f0bd4078ac3b4b5ec2eacad36c4258
These fields are always aready set by the only caller of the function
trx_setup_clock(), so there's no use in re-setting them.
Change-Id: Id8a7141984e07eb11abae08e0c63ae7ebc333511
It can happen that the first burst we receive after enabling the PDCH
channel (when PCU connects to the BTS) is bid!=0. As a result,
chan_state->ul_first_fn is never set and defautl value 0 in there is
passed to the upper layers. As a result, when the 2nd block is
transmitted, this time with correct FN, the PCU will see a huge jump in
FNs. Since in PDCH the bursts are always consecutive, let's simply use
bi->fn - 3 as a first_fn and be done with the issue.
Related: OS#5020
Change-Id: Ie982caeb29f3ffd880b44e88a89b85ea3e6e6947
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I343c7a721dab72411edbca816c8864926bc329fb
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I0b04b013b7bad5ff53d6a969ff0128b37f7f62d5
At the moment osmo-bts is not looging much ACCH repetition related
information. This makes testing ACCH repetition difficult. Lets add some
debug output that informs the user when ACCH repetition is turned on or
off. Lets also add an ACCH repetition status display to the show lchan
VTY command.
Change-Id: I59d11fd03be3d29fb8a4279d9945b03006764c0e
Related: SYS#5114
The MS sets the SRR bit in the L1 SACCH header to request DL-SACCH
repetition from the BTS. At the moment we access the l1_info stored in
tle lchan struct each time we want to check the status of the SRR bit.
However, it is more convinient to do this once at reception and store
the status of the status of the flag in a separate struct member.
Change-Id: Ieddd45d7890343d64db14b9c726f6fa2f25714f6
Related: SYS#5114
The check in lchan_ms_ta_ctrl() breaks Timing Advance control on
SDCCH channels, because 'num_ul_meas' wraps and never reaches 4.
Neither this check makes any sense for other channel types,
because lchan_ms_ta_ctrl() is always called in the end of the
measurement period. Let's drop it.
Change-Id: I0b86d49ec00b38d0f309c56b2519e5d487f0b65b
Fixes: If7ddf74db3abc9b9872abe620a0aeebe3327e70a
Related: OS#5024
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I8713f4e04e92b4d7e211c499fc6e78983edfb139
Related: OS#5034
in struct gsm_lchan and also in other places l1_info is handled in its
binary form. Libosmocore now offers structs to handle l1 info, so lets
use those structs to get rid of all the manual decoding of l1_info.
Depends: libosmocore I23c1890b89d5a0574eb05dace9f64cc59d6f6df7
Change-Id: I5eb516d7849750f3dd174d48c9f07dabf2c80515
So far, the only way to configure GSMTAP Um logging is to use the
cmdline argument '-i'. Let's deprecate it, and add a VTY command
to allow setting the remote host from configuration file.
The legacy '-i' option, if provided, overrides the configuration
file option, and will also appear in 'write file'.
Change-Id: I17676a21c4e0c9cbc88f2c5c53a39c6c6c473ca1
Tweaked by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
The cfg_out macro is used like a function in the code below its
definition. This means a colon will follow after it is used. When
the vty_out call in the macro already has a colon the final result will
be vty_out(...);;. This works fine as long the macro is not used in one
line if/else if/else constructs without curly braces {}. The compiler
will interpret the double colon as two lines of code and run into an
error then. Lets fix this by removing the colon from the vty_cout in the
macro.
Change-Id: I2c23c38ce892067add0f95f3e504a9c559e24519
The only reason why it was not 'const' is that in lchan_new_ul_meas()
we may need to overwrite 'ulm->is_sub'. This can still be done after
memcpy()ing a new set of samples to the destination buffer.
Change-Id: I0cabf75f8e0bf793c01225a4a8433e994c93f562
Related: OS#5024
There's a minor derivative version of sysmoBTS 1002 which has built-in
GPS and PoE. We call it 1003 in the EEPROM. Let's treat it identical
to 1002 in the existing code base.
Related: SYS#5327
Change-Id: Ia558587d36a75a1db1951d25b471b3f2e78ef4c9
At the beginning of repeated_ul_sacch_active_decision() The UL-SACCH
repetition capability is tested. If no UL-SACCH repetition is enabled
the function exits. However, we should also make sure that the struct
member that enabled UL-SACCH repetition on the lower level is set to
false as well. Normally that should be the case because it was never
set to true before, but it is better to be sure.
Change-Id: I76a841514eb955b93f2114470b2c80402cf6883c
Related: SYS#5114
At the beginning of repeated_dl_facch_active_decision() the ACCH
repetition capabilitiy flags (command only or all LAPDM frames) are
tested. If no FACCH repetition is enabled, the function exists. However,
we should also make sure that the struct memeber that enables FACCH
repetition on the lower level is set to false as well. Normally that
should be the case because it was never set to true before, but it is
better to be sure.
Change-Id: Id07091cc89352281b41532d583a8bc004477c71a
Related: SYS#5114
The function checks meas_res->rxqual_sub against the lower threshold
value in order to decide when to turn FACCH repetition off. This is not
correct. It should compare against rxqual instead.
Change-Id: Id4ab101d52f419583c4f4c8a6cf69af6c9097d25
Related: SYS#5114
All IEs in the BSC originated message are optional, so we assume
default values for them. Let's reflect them all in the ACK/NACK.
Change-Id: I5c73e83daad0cea07b9cb674c393e0bfc6268a61
Related: OS#3791
This would allow to compose ACK/NACK messages with additional IEs
not present in the original message. Also, this change basically
eliminates unnecessary msgb_copy() / free().
Change-Id: I17f61636e9a144017e2c46b1540d152c21529391
Related: OS#3791
Both NM_ATT_IPACC_DST_IP and NM_ATT_IPACC_DST_IP_PORT are defined
as TLV_TYPE_FIXED, and NM_ATT_IPACC_STREAM_ID is TLV_TYPE_TV, so
the TLV parser already does check the length for us.
Change-Id: I1e493e552bb22bb42bb196ce71214e28d23fd19e
In function pcu_tx_si_all(), the variable rc is not initalized. If
pcu_tx_si() fails, then rc is populated with value -EINVAL, but if all
si transmissions succeed, which is the normal case, rc remains
uninitalized.
Change-Id: I571fdb4f175fb259b77f989554f569fc2230dfe6
Related: CID#216932
This patch PCUIF extends the SAPI 4 that is used
to transfer SI13 only, so that it can transfer SI1 and SI3 as well.
The system information SI1, SI3 and SI13 is needed by the NACC RIM
application which runs inside osmo-pcu.
Depends: osmo-pcu I5138ab183793e7eee4dc494318d984e9f1f56932
Change-Id: Ib7aeb41e634ad6fcab3766a4667b0267c749436a
Related: SYS#5103
GCC-4 doesn't like static const struct foo bar = (struct foo)...:
measurement.c:33:1: error: initializer element is not constant
Related: OS#5004
Change-Id: Iec5a4006dfc90abe240fcf8b6c2fefd4f7071a70
A channel activation for handover to another cell does not know the
Timing Advance until the handover RACH is received. It does not make
much sense to enable downlink SACCH without an accurate TA.
If the BSC omits the Access Delay IE (a.k.a. the Timing Advance), do not
enable downlink SACCH. This is expected to happen only for inter-cell
handover. In all other situations, the TA should be known either from a
Channel Request RACH for Immediate Assignment, or from the previous
lchan on the same cell upon Assignment / intra-cell handover.
Related: OS#4008 OS#4009 SYS#5192
Change-Id: I170b63c9856230d5f1a10654a9d950ada8e730d7
One part of the algorithm simply provides a _suggested_ 'delta' that
needs to be applied to the current power level, while the other part
ensures that this suggested value does not exceed the limits. Thus
it's possible that some logging messages would state that the power
reduction value remains unchanged, while the 'detla' != 0.
Change-Id: I7496a158b9ac6074a965056d708d8078a98cb1aa
Related: SYS#4918
These new commands are useful for debugging MS/BS power control
loops, e.g. one can change power control mode, overwrite the
current BS power reduction or MS power level at run-time.
Change-Id: I1ebb033b02c2bc3b1fa7de874e0035a07297f266
Related: SYS#4918
The loopback mode was added for testing, and may be dangerous if
enabled in production. Let's make it appear only in expert mode.
Change-Id: I3f68acd7f2b0231f78516f59fb5e8ef56fb69dbf
As far as I can see from my perf measurements, bitvec_fill() is called
quite often and takes 0.27% of the CPU. A more detailed look reveals
that it's indirectly called by fill_paging_type_1() in order to fill
the remaining octets with constant '2B'O padding.
Let's optimize this function:
- use memset() for padding *before* writing optional P1 Rest Octets;
- conditionally initialize the bit vector for P1 Rest Octets;
- use designated initializers instead of memset().
It's generally better to avoid using bitvec_fill() when using memset()
is possible, because the former operates on bits rather than bytes.
Change-Id: I90473356b396e5dd9326598aca025afacca4afc8
It does not make sense to trigger the BS power control loop on C0,
as it's only allowed to reduce power on additional transceivers.
Change-Id: I4fdfe097ae6f9edde5f39ed4da8a559a14b3b38f
Related: SYS#4918
At the moment only rxlev_sub is used to decide when the facch repetition
should be activated, regardless if DTX is used. Lets check if DTX is
actually used and use rxlev_full when DTX is not applied.
Change-Id: I01ba57cf661f0e41b8df209c905f8d135013e472
Related: SYS#5114
The table in repeated_ul_sacch_active_decision() is derived from the
second table in GSM 05.08 8.2.4 but the first table would be correct.
Also the lower threshold is not properly choosen. A lower threshold,
that derives from upper threshold shifted by 2 makes sense (BER must
improved by 2 RXQUAL steps before repetition is turned off.)
Change-Id: I1d9b5c8abb79938cdecdafed84ed2e5d47e0bd3a
Related: SYS#5114
This change makes BS power control loop:
- take the lower RxQual threshold (L_RXQUAL_XX_P) into account, so
the BS power is increased only if RxQual exceeds this threshold;
- apply the configured increase step size instead of reducing the
current attenuation by half.
MS power loop is not affected, it does not even handle RxQual yet.
Change-Id: Ib3c740b9a0f3ba5dfb027e144dc13f456cb26ae2
Related: SYS#4918
It makes more sense to use a reduce step size that is smaller than
the increase step size. This way both MS/BS power control loops
would be able to react quickly of the signal gets weaker, while
the good signal would not trigger radical power reduction.
Change-Id: Ie358fd828a68bfa1d23559197e8df8478fb4535e
Related: SYS#4918
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
MS/BS Power Control parameters have been recently moved to the BSC
and now signaled to the BTS over the A-bis/RSL link. Let's make
sure that the existing VTY commands for Uplink Power Control do:
- trigger deprecation warnings if present in the config file,
- not show up in the online VTY help nor VTY reference,
- affect the fall-back parameters in 'struct gsm_bts',
- still get printed by 'show running-config' command.
Change-Id: Icbd9a7d31ce6723294130a31a179a002fccb4612
Related: SYS#4918
It is expected that setting RxQual threshold to 0 would make the
L1SAP logic enable repetition for both Uplink SACCH and Downlink
FACCH unconditionally. However, this was only valid for the
later. Let's add the missing check and make it consistent.
Change-Id: Ia44a134e7f28ea990798d1b79c87b644504c0876
Related: SYS#5114
For the sake of simplicity, the old structures that are still used
by MS/BS power control loops are kept in place. Migration to the
new structures requires additional changes to the existing power
control logic, so it will be done in the follow-up changes.
The new parameters are integrated as follows:
+ struct gsm_bts - a BTS instance:
| Hard-coded default (fall-back) parameters for all transceivers.
|
+-+-> struct gsm_bts_trx - a TRX instance (transceiver):
| Default parameters for all logical channels inherited from
| 'struct gsm_bts' at start-up. May be overwritten by the
| BSC using ip.access specific 'Measurement Pre-processing
| Defaults' message on the A-bis/RSL interface.
|
+---> struct gsm_lchan - a logical channel (e.g. TCH or SDCCH):
Connection specific parameters inherited from 'struct
gsm_bts_trx'. May be overwritten by parameters sent
by the BSC in CHANnel ACTIVation and other messages.
Change-Id: I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
Related: SYS#4918
This is a follow-up fix for I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
get_si4_ro_offset() itself already checks if it's less than GSM_MACBLOCK_LEN,
so we must check if it's not negative.
Change-Id: Iba99e5de625af6bed6720a38fec26c2acc6251c0
In Change-Id I1fd513ea03297918d15d4b28ed454f9b6dd6ebfa we introduced
patching of SI4 to indicate GPRS presence in terms of PCU connection
status. Unfortauntely this didn't account for optional IEs being
present in SI4, and hence overwrote any CBCH related information
elements, if present.
This in turn meant that since the above-mentioned commit, you could
have either a GPRS-capable, network, or a Cell Broadcast capable one.
Change-Id: I0ee0cf736e2fb74a6759a68101f699b4ec2ef54e
Related: OS#3075
Checking if a given RSL IE is present is a straightforward task,
so there is no need for a special boolean flag.
Change-Id: I6a12930314c79b9c3efabfa575b17f78105fea4c
It does not make sense to dump CCCH/CBCH as dedicated channels:
OsmoBTS# show lchan
BTS 0, TRX 0, Timeslot 0, Lchan 4: Type CCCH
State: ACTIVE
BS (Downlink) Power Control (autonomous):
Channel reduction: 0 dB (max 0 dB)
TRX reduction: 0 dB
Actual / Nominal power: 13 dBm / 13 dBm
MS (Uplink) Power Control (autonomous):
Current power level: 0, -39 dBm (max 0, -39 dBm)
Channel Mode / Codec: SIGNALLING
LAPDm SAPIs: DCCH --, SACCH --
Valid System Information: 0x00000060
MS Timing Offset: 0, propagation delay: 0 symbols
Radio Link Failure Counter 'S': 0
so let's only dump SDCCH, TCH/F, and TCH/H.
Change-Id: Id7880de56a93cc9fa4ca576b094cef35ee269822
During the initial implementation I used the wrong function to change
state. As a result, from BSC point of view the BTS was changing state
but the FSM internally was not. "Fortunately", while in state Dependency
the BTS still could cope with that in order to still be operative with
older osmo-bsc, so there was no major breakage, only some error log
message being printed.
Related: OS#4873
Change-Id: Ifd2eefc362fca0aa9e6ae102c7e6dbc1b4f295d6
struct lchan_power_ctrl_state actually contains more fields,
which also must be initialized on CHANnel ACTIVation.
Change-Id: Id9719088fc6e9479c13e9b327a3466d9e2810a3a
Related: SYS#4918
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Similar to I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87, this change
is another step towards separating the common delta calculation
logic from lchan_ms_pwr_ctrl(), since this function will loose
access to the averaged values.
On the one hand, the affected logging statements are getting
less precise; on the other, logging the averaged value as the
actual value ('rx-current') may be even more confusing.
Change-Id: I07007e45c859b4080fbbe520ffb5ccc0bb9c4244
Related: SYS#4918
This change would allow to separate the common logic from
lchan_ms_pwr_ctrl() and re-use it for Downlink power control.
The logging statement was quite useful during early stages
of development and testing of hysteresis and filtering,
but now we can sacrifice it.
Change-Id: I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87
Related: SYS#4918
This way EWMA based filtering logic can be used not only for
MS Power Control, but also for BS Power Control.
Change-Id: I16c2e1b997f2b8af44d47809420293f072335bbd
Related: SYS#4918
This would allow to pass only two pointers:
- 'struct bts_power_ctrl_params', and
- 'struct lchan_power_ctrl_state',
and get rid of 'struct gsm_lchan' dependency. The later is
exactly where all state variables are supposed to be kept.
Change-Id: Idfefca30f4944bc722b4e9d8f1685eb77670a9db
Related: SYS#4918
When [baseband] frequency hopping is in use, Downlink bursts from
additional transceivers may end up being transmitted on TRX0/C0.
In this case, we must not apply per-lchan attenuation, because
the BTS shall maintain constant power level on that TRX.
Change-Id: Id171df70447283b00da965e1f81dfac20e35495c
Related: SYS#4918
3GPP TS 44.006, section 11 describes a method how the uplink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
3GPP TS 44.006, section 11 describes a method how the downlink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I00806f936b15fbaf6a4e7bbd61f3bec262cdbb28
Related: OS#4794, SYS#5114
The SRR bit, which got specified in 3gpp release 6 to support repeated
ACCH capability is not yet included in the L1 Information IE on RSL
level. Also lets update the spec reference to more modern 3gpp spec ref
numbers.
Change-Id: I987c61608b737521ba36756dabf2f6215b34c2d6
Related: OS#4796 SYS#5114
The recently added IE (RSL_IE_OSMO_REP_ACCH_CAP) has been extended
with more options, update the documentation as well.
Change-Id: I3d95da588e863185bb62e92898c285d52bce9af4
Related: SYS#5114, OS#4796, OS#4794, OS#4795
3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114
This part adds the common lchan flags to indicate whether DL SACCH
should be activated.
Note that currently, osmo-bsc *always* sends the MS Power IE as well as
the TA IE, also for inter-cell HO, so in the osmoverse, nothing will
change until we also adjust osmo-bsc. See OS#4858.
Change-Id: Ibea973ccadf5d424213f141f97a61395856b76de
The sapis_for_ho have only one member, so it's silly to iterate. A
subsequent commit will drop sapis_for_ho.
Change-Id: I896fbca9876fd274ff9c426250b18b50faebfa89
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I6ddc04c5815858c7dfab04ffdac52bce2e7940a1
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I7a5756e106ac1061d37b42c22cc127fdacd87ce7
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: I35ae930b59c48892e5ad9a2826e05d6c5d415abc
Fixes: OS#4865
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Ic3b7c223046a80b51f0bd70ef1b15e12e6487ad0
Fixes: OS#4865
The signal handler function was coded to expect SIGABRT but the signal
handler itself was never enabled for this signal.
Change-Id: Id95d64efe8765fcf19eb09cd3db7895166c6adab
The RSL documentation should reflect some explanatory info about the
recently added RSL_IE_OSMO_REP_ACCH_CAP IE.
Depends: libosmocore I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Change-Id: I1d70846c2c184f7a189074c51137bc1f38fb3859
Related: OS#4796 SYS#5114
Unfortunately, we cannot re-use the existing Makefile rules from:
$(OSMO_GSM_MANUALS_DIR)/build/Makefile.vty-reference.inc
because they do not allow to generate the list of $(DOCBOOKS) from
a template, and require the project to store everything in separate
folders with specific names. Also, those rules expect that the
target PDFs contain only a single word in their names (for example,
'osmoapp-vty-reference', not 'osmo-app-vty-reference'), while in a
project with multiple similarly named targets this would reduce
readability (imagine 'osmotrxuhd-vty-reference').
Change-Id: Idba84164b90e3d183a20b5eb69cbfe15745e447c
Depends: I6aac73d998c5937894233631e654a160d5623198
Related: SYS#4937, SYS#4910, OS#3036
The binary is called 'osmo-bts-lc15', while the containing folder
is named 'osmo-bts-litecell15'. This inconsistency complicates
automatic generation of the XML VTY reference - fix it.
Change-Id: I55c073fbd01aee42871101401d76d87e7c91832e
Related: SYS#4937, OS#3036
Otherwise it ends up in the generated XML VTY reference:
$ head doc/manuals/vty/bts_trx_vty_reference.xml
((*))
|
/ \ OsmoBTS
<vtydoc xmlns='urn:osmocom:xml:libosmocore:vty:doc:1.0'>
<node id='_common_cmds_'>
<name>Common Commands</name>
Also, take a chance to move it below handle_options(), so it
will only be printed if all arguments are parsed successfully.
Change-Id: I5c35f36fdd2a8a80bd501b996f0b161c388d3510
Related: SYS#4937, OS#3036
Now bts_model_vty_init() must be called only once, otherwise the
process would crash when bts_model_init() is called from main().
Change-Id: I262c39896b5db86c54ad9aa7042c7ca6657815d9
Related: SYS#4937, OS#3036
Similar to bts_vty_init(), BTS specific bts_model_vty_init()
requires a pointer to 'struct gsm_bts'. Not only it's used
as a parent talloc context, but also stored locally, so then
it can be used by some VTY commands.
Let's expose the global 'struct gsm_bts' from main, and pass
the application's talloc context like was done in [1].
This finally makes the BTS model specific options appear in
the automatically generated VTY reference (--vty-ref-xml).
[1] Ic356a950da85de02c82e9882a5fbadaaa6929680
Change-Id: Iee7fee6747dd1e7c0af36f9b27326f651ae37aaf
Related: SYS#4937, OS#3036
The variables num_meas_sub_expect - num_meas_sub must not be subtracted
without prior checking. Depending on the input (which might be
errornous), num_meas_sub might be greater then num_meas_sub_expect. This
eventually leads into odd behavior, which can be difficult to debug.
Change-Id: I381cc637d1c125f279ccf88db114609946fe24fe
Related: OS#4799
Otherwise only those commands that are registered by libosmocore
appear in the generated XML VTY reference - change the order.
Instead of a pointer to 'struct gsm_bts', pass the application's
talloc context, as it's only used for dynamic command allocation.
Change-Id: Ic356a950da85de02c82e9882a5fbadaaa6929680
Related: SYS#4937, OS#3036
The logic in measurement.c checks the amount of collected measurement
values. This is done for the total amount of measurements and the amount
of SUB blocks measurements.
The functions that return the expected number of measurement values
currently do not take into account that the mode of a TCH/F or TCH/H has
an effect on the number of expected SUB blocks. (In signalling channels
all blocks count as SUB). Also a TCH/H in signalling mode generates only
half the amount of measurements because the blocks in signalling mode
are sepreded over 6 bursts instead of 4. This also needs to be taken
into account.
Change-Id: I01c7b6cc908c647263ab88f6b6281c4732f88779
Related: OS#4799
SUB frames exist only in voice (or CSD) channels. When a TCH/F is in
signalling mode, all blocks must be counted as SUB blocks. (for TCH/H
the current implementation is correct.)
Change-Id: I04be21200afa1d03afa0d7e476c66fa79cf42249
Related: OS#4799
When the FACCH is generated (while in SPEECH mode), there is also a
fake speech indication handed up to l1sap.c. We must make sure that only
one of the two indications carry a measurement value, so lets invalidate
the measurement values (RSSI in particular) for the generated TCH
indication.
Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b
Related: OS#4799
Otherwise, some objects are announced at startup of osmo-bts towards BSC
during State Changed Report as being "NULL".
According to TS 12.21:
"NULL(Operat. state not supported) FF"
Which doesn't make much sense in startup situation. They are in known
state Disabled until they are OPSTARTed.
Change-Id: I5ba6756ea069d0f995f453ee4b27e6839c914eb1
Previous commit 7810a91733 forgot to
introduce this line, though it was planned to be there.
Most of the time it worked fine anyway because the RSL link is not the last
event bb_transc waits for before switching to Enabled, so later events
would trigger inside the bb_transc fsm a recheck (polling) which wuld
allow to advance to Enabled state.
However, in the situation where RSL link UP is the last event to happen,
no more inside-FSM checks are triggered and hence BB Transeiver never
goes to Enabled state, and as a result no event is triggered towards
each RadioChannel which in turn don't go to Enabled state.
Fixes: 7810a91733
Change-Id: I8c777b946e7abcb4b607ec4d136c981a0716b120
All the Operative State logic to manage a RadioCarrier//BBTransc NM objects is
centralized in these FSM, where other parts of the code simply send
events to it.
This allows keeping state consistent and offloading logic from each bts
backend, since they are only required to submit events now.
The idea in the long run is to also replace other NM objects with
similar FSMs.
This improved logic fixes bug where PHY + RSL link became available before
OPSTART and hence op state changed to Enabled before receiving any OPSTART message.
Change-Id: Ifb249a821c4270918699b6375a72b3a618e8cfbe
This fixes old behavior mimicing broken behavior in nanoBTS (according to TS 12.21)
where BTS Site Mgr NM object was announced as Enabled despite no OPSTART
was sent by the BSC.
With this new FSM, BTS SiteManager will be announced as Disabled Offline
during OML startup conversation, instead of Enabled.
The new osmo-bsc OML management FSMs use this change in behavior to find
out whether it should use the old broken management states (without
Offline state, as per nanoBTS) or use the new state transitions (which
allow fixing several race conditions).
Change-Id: Iab2d17c45c9642860cd2d5d523c1baae24502243
This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs,
which expectes for non-nanoBTS types to follow TS 12.21 guidelines.
Until now, BSC simply waited to received State Event Change Dependency
for each TS and then sent all required commands (Set Chan Attr, Adm
Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when
in Offline state, so we need to transit to that state. For the above
mentioned reason, since we pass through the Dependency state anyway
after this patch, older osmo-bscs will work correctly too.
Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
We originally wanted to intrdouce an OML router which would permit
external proceses to implement certain OML MOs. However, that code
was never completed, and all the existing implementation (in three
copies) does is to create a unix domain socket and discard what
is received there.
Change-Id: I7fcbbd5d6b64ddc666ca836dc49abb430be0d5cb
Sometimes the following messages appear in the logging output:
TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
TCH/F: Prim has wrong chan_nr=0xc2 link_id=00, expecting chan_nr=0x0a link_id=00
when a dynamic timeslot is switched from PDCH to TCH/F (or to TCH/H).
This means that the transmit queue of a timeslot still contains
PDCH frames, that were not properly cleaned on PDCH deactivation.
Let's finally do this in trx_sched_set_lchan().
Change-Id: Ic6560c660c658f36b84e7efa2f1d93e3a870962b
Related: SYS#5108, OS#4804
Trying to (de)activate logical channels that are already (de)activated
is not something that we normally expect. Treat this as error.
Change-Id: I6256280cae35b2b4d7a8ba4b3913ca69cde22611
In this function we already do check that a given timeslot is not
a PDCH slot, so checking if TRX_CHAN_FLAG_PDCH is redundant.
Change-Id: Ie73bdaf0f6bc76ed8d2e95d1fb995333bf617e7e
Both TRXC_PDTCH or TRXC_PTCCH are described in 'trx_chan_desc'
(defined as 'const'), and both have TRX_CHAN_FLAG_PDCH set. So
indeed, this condition can never be true.
Change-Id: Ie185a939b48eb859ac1c8ffa0a4f667fda0cb82b
Recently we've introduced EWMA based uplink power filtering, that
should reduce Uplink power oscillations. However, the power loop
is still quite sensitive to small deviations from the target power
level: even such an insignificant deviation like 2-5 dBm triggers
the loop to increase or decrease the MS power level. Even if the
EWMA based filtering is enabled with 80% smoothing (alpha = 0.2).
This change introduces a new configuration parameter - 'hysteresis':
uplink-power-target <-110-0> hysteresis <1-25>
that together with the 'uplink-power-target' defines a range:
[target - hysteresis .. target + hysteresis]
in which the MS power loop would not trigger any power changes.
This feature is now *enabled* by default, so given that:
- default 'uplink-power-target' is -75 dBm, and
- default 'hysteresis' is 3 dBm,
the default target Uplink power range is: -78 dBm ... -72 dBm.
Change-Id: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
Sending INFO.ind unconditionally in pcu_if_signal_cb() provokes
a lot of warnings during OML bootstrapping / termination:
DPCU INFO pcu_sock.c:247 Sending info
DPCU INFO pcu_sock.c:262 BTS is up
DPCU INFO pcu_sock.c:205 (bts=0,trx=0) unavailable for PCU (op=Disabled adm=Unlocked)
DPCU INFO pcu_sock.c:205 (bts=0,trx=1) unavailable for PCU (op=Disabled adm=Unlocked)
Do not call pcu_tx_info_ind() if the PCU is not connected.
Change-Id: If8bc8bec5ad808be8d40e91278a4a4fde84920b0
So far the Uplink power control loop did not filter the Uplink RSSI
measurements (reported by the BTS) at all. The lack of filtering
makes our implementation too quick on the trigger, so in the real
deployments there will be unneeded Tx power oscillations.
In order to reduce this effect, let's implement a very simple EWMA
(also known as Single Pole IIR) filtering that is defined as follows:
Avg[n] = a * Pwr[n] + (1 - a) * Avg[n - 1]
where parameter 'a' determines how much weight of the latest UL RSSI
measurement result 'Pwr[n]' carries vs the weight of the average
'Avg[n - 1]'. The value of 'a' is usually a float in range 0 .. 1, so:
- value 0.5 gives equal weight to both 'Pwr[n]' and 'Avg[n - 1]';
- value 1.0 means no filtering at all (pass through);
- value 0.0 makes no sense.
This formula was further optimized with the use of '+=' operator.
The floating point math was also eliminated by scaling everything
up (by 100). For more details, see:
https://en.wikipedia.org/wiki/Moving_averagehttps://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filterhttps://tomroelandts.com/articles/low-pass-single-pole-iir-filter
The EWMA filtering is now *enabled by default*, but can be disabled
or (re-)configured over the VTY at any time:
! Completely disable filtering
no uplink-power-filtering
! Enable EWMA smoothing with the given parameters
uplink-power-filtering algo ewma beta <1-99>
Note that the VTY command expects 'beta' instead of 'alpha':
alpha = (100 - beta)
and the value must be in %. This is done for simplicity:
1% means lowest smoothing,
99% means highest smoothing.
Let's say we have EWMA filtering enabled with alpha = 0.4, and get
-98 dBm on the input, while the last output value was -60 dBm.
The new output would be:
Avg[n] = 0.4 * Pwr[n] + 0.6 * Avg[n - 1]
Avg[n] = (0.4 * -98) + (0.6 * -60)
Avg[n] = -75.2 => around -75
Of course, this is not a silver bullet, but better than nothing.
Change-Id: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I895db6086748a5916874e779963caed589050109
Related: SYS#4937, OS#1601
The PCUIF is a 'brilliant' protocol: some fields are expected to
be in the network byte order, some in the host order. The NSVC
remote address and local/remote ports is a good example:
- byte order of the address must be the network order, and
- byte order of the ports must be the host order.
Change-Id: I383cab0b58b62734090023298da8c5a341c670d5
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
This is another regresion introduced by [1]. Both local and remote
port numbers recived in the network order, and must be stored as-is.
Change-Id: I3c21a2c27dcbf6de728ce2c7ccbae9e2f517c450
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
Using gsm_bts_trx_num() involves redundant iterations over the
list of transceivers - we definitely don't want them.
Change-Id: I4bd40ffcc1e925412a21b0a934bbfdeddbc6ad1f
in function rx_tchh_fn() the variable meas_avg is not initalized. This
is not always a problem, since most of the time trx_sched_meas_avg() is
populating the variable properly. In cases where a FACCH is transmitted
(chan_state->ul_ongoing_facch = true) the variable is left unpopulated.
In order to have at least stable values for those cases, initalize the
variable with zeros for the ongoing facch phase.
Change-Id: I5c3c1c41d22f9edaaf6bd4478dd04f090dca12a9
Fixes: CID#214480
The address_family is 8 bit and have a padding byte afterwards.
By using osmo_load16be it's encoding it wrong and result in an
empty/invalid NSVC configuration.
Change-Id: Ie070b5745124d48e74a6dedd8903b74bfb3ce9d2
Since I310699fabbfec4255f0474f31717f215c1201eca the BTS
can decode NM_ATT_OSMO_NS_LINK_CFG. This OML attribute will be
only used if the OML feature IPV6_NSVC is present.
Change-Id: I9910f2afb3ab94167938b0fd356f2f0a8c382130
With PCU interface version 10 it supports IPv6 NSVC. The new OML IE
NM_ATT_OSMO_NS_LINK_CFG allows to configure IPv6 NSVC.
Change-Id: I310699fabbfec4255f0474f31717f215c1201eca
There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
This regression was introduced in 2ff4592ffc.
There is simply no PHY in case of osmo-bts-omldummy.
Change-Id: I864ac3f15e06462d6ce808b3f2188c5c39a5aad2
Fixes: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
Make sure that we pick the correct UL measurements from the
history when we deal with AMR SID frames (SUB frames).
Change-Id: I902bb47d68742d2589156f61099b67a0edbaf40b
Related: OS#2978
Currently the UL measurements (RSSI, ToA256, C/I) of the burst that
concludes a block are passed up to the higher layers. This means
that the measurement values of the other bursts are skipped.
Let's keep record of all UL measurements and average the values
before we pass them up to the higher layers. Use a simple ring
buffer to store the measurement history (up to 8 unique entries
for now). Remove *_num/*_sum variables from l1sched_chan_state.
Change-Id: I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
Related: OS#3032, OS#2978
Introduce a address_type in the NSVC configuration pass the given
protocol. The remote_ip is network byte order, the default
encoding for in_addr and in6_addr.
Change-Id: I6d60277eb5b8d938d9f38114c933d58ee1b884c9
Related: Iae854875a45dbc29cd46a267ccaf60f1f2ac2973
Related: SYS#4915
Otherwise they may be set to ENABLED before CHAN SET ATTR and OPSTART
are sent, and oml_rx_opstart will blindly OPSTART ack (because they are
already enabled) and avoid configuring the timeslots.
That can happen if phy_link & rsl link get ready before receiving all
the OML CHAN SET ATTR and OPSTART commands on all RadioChannels.
Fixes: OS#4757
Change-Id: I50722c4e82faae32371817c3878bb41bfd0175ba
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
Most likely, this part of the structure was copy-pasted from the
corresponding definition in osmo-bsc. In osmo-bts we always
establish a single per-BTS OML link, not per-TRX.
Change-Id: I1792372de484608e04211c9de4294b3c76173ead
If for whatever reason a TS stops being announced as available to the
PCU (for instance because the TRX became administratively locked), the
PCU will send a Release for that channel, but in that case we don't want
to send an RSL RF Channel Release ACK because it was not initiated by
related command from BSC.
In the case of a simple PDCH timeslot (no dynamic), the behavior is
already there but we don't print an error log since it's expected.
In the case of a dyn osmo TS, we only need to respond to RF Channel
Release when PDCH is deactivated here, but in other cases we don't need
to submit anything to BSC.
Change-Id: I8ae9ee450763a0e14edf950e38b64a32df14f44f
Avoid announcing to PCU as available a dyn TS not yet fully
configured in the phy. Otherwise when we receive the Chan Activation
over the PCU sock while pchan_is still is not PDCH, and we fail to fully
activate the channel at that time.
See previous commit description for more information on the issue.
We still want to check for pchan_want because we actually want to stop
announcing the TS when it is in progress of being changed to TCH. This
configuration change is continued/finished once we receive the resulting
Release from PCU.
Change-Id: I8e2b170c1f94e7dfe2576a1fc899bf9c8a826a44
Something is wrong currently with dynamic TS and PDCH activation.
Apparently there's a race condition between activation in BTS lower
layers (example in TRXC) and against PCU.
Currently, when a GSM_PCHAN_TCH_F_TCH_H_PDCH is configured, we set
ts->dyn.pchan_want = GSM_PCHAN_PDCH and submit the async activation
through lower layers (CMD SETSLOT), and once the lower layer acks it we
set ts->dyn.pchan_is = pchan_want (when receiving RSP SETSLOT). However,
we seem to be advertising available TS to PCU based on pchan_want,
instead of pchan_is, which means we advertise channels not yet fully
configured. As a result, we may receive a Channel Act coming from PCU
for a given TS for which we didn't receive confirmation from upper
layers, meaning pchan_is is still GSM_PCHAN_NONE. This is by no means
expected in following code, so let's avoid going further over it.
Actual issue will be fixed in follow-up patch.
Change-Id: I9edb5b8a14ffaed3e24c10c2c7a3f618e05f3a01
It was spotted that sometimes chan_nr BCCH was printed for a TS
containing configured as GSM_PCHAN_TCH_F_TCH_H_PDCH, which was totally
confusing. Indeed the problem is somewhere else, but let's log an error
and return 0 in this case, which will be converted to "UNKNOWN" string
later on.
Change-Id: Ic455af39c668481a13d579f33ac09033fd5c4009
This reverts commit df93a448b7.
It was to early because the frequency hopping wasn't ready to be merged.
Change-Id: I6e67f4cd9828afa53ed4e783b83b039ee6a1d570
Introduce a address_type in the NSVC configuration pass the given
protocol.
The remote_ip is network byte order, the default encoding for in_addr and in6_addr.
Change-Id: I4067b1af041b2cdad60d6fb16c9caee98bc218dd
Operative state is mainly maintained based on 2 requirements:
* phy_link being in CONNECTED state
* RSL connection being up and ready
However, state change report triggered over OMl towards BSC was only
done upon the first event of the two. That means that if for whatever
reason the RSL connection was established AFTER the phy_link became
CONNECTED (ie receiving RSP POWERON in osmo-bts-trx), then the status
towards the BSC would not be updated and hence the BSC would still see
the Radio Carrier object as DISABLED.
The trx_set_available() function is renamed to trx_operability_update()
to keep the logic conditions in one place, and different events
triggering a change in state simply call the function and let it handle
the new state.
Related: SYS#5063
Change-Id: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
In general, it is always set to 1 (Locked) in
st_open_poweroff_on_enter() right after initial POWEROFF, and once the
BSC unlocks it (based on VTY cfg "rf_locked (0|1)") by sending an OML
message, the bts_model_chg_adm_state() call will update it sending
RFMUTE.
This basically fixes the case where osmo-bsc.cfg is configured with
"rf_locked 1" to start with a TRX locked until manually unlocked.
Related: SYS#4920
Change-Id: I96b64cdc901d6f216df628d7be57a67af4a21e25
Since commit 221ee92551,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbfbe15a12c87eef420d1cahttps://osmocom.org/issues/4694https://osmocom.org/issues/4695https://osmocom.org/issues/4696https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
It was reported that both osmo-bsc and osmo-bts-trx may end up
running in a half-broken state, when everything looks good and
the UEs can see the network, but all channel requests get
rejected due to "trx not usable" error:
lchan_select.c:173 (bts=0) lchan_select_by_type(SDCCH)
lchan_select.c:48 looking for lchan CCCH+SDCCH4: (bts=0,trx=0) trx not usable
lchan_select.c:48 looking for lchan SDCCH8: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select SDCCH channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_H)
lchan_select.c:48 looking for lchan TCH/H: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_H channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_F)
lchan_select.c:48 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_F channel
As was then figured out, this happens because the Radio Carrier
MO (Managed Object) remains Disabled even after the BSC has
sent OPSTART and the BTS ACKed it:
oml.c:986 OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
l1_if.c:614 Rx OPSTART for RADIO-CARRIER MO
l1_if.c:201 TRX_PROV(phy0-0)[0x1238c0]{OPEN_POWERON}:
Event TRX_PROV_EV_CFG_ENABLE not permitted
oml.c:144 OC=RADIO-CARRIER(02) INST=(00,00,ff): Tx Opstart Ack
It remains a mistery why the TRX_PROV FSM is already in state
OPEN_POWERON, while it's expected to be in state OPEN_POWEROFF,
but we definitely should not ACKnowledge the OPSTART if this
happens. Send a NACK instead with cause NM_NACK_CANT_PERFORM.
Change-Id: I8727460acbf850b84df67a9cbdc25b47dee1fadd
Related: SYS#5063
We already get quite informative message originated from oml.c:
OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
Change-Id: I3d4a4473541327488d3393b1fa7c6391afb3728a
It's more convenient to use one command to enable/disable sending
of all kinds of UL/DL messages at once, rather than specifying
all of them individually.
Adjust config_write_bts_single(), so it would not print unknown
GSMTAP SAPI entries if gsmtap_sapi_mask is set to UINT32_MAX.
Change-Id: Icd7fce860ecdcf8ffa107bdfee7ec94ea9ea6cb2
Otherwise osmo-bts-omldummy would reject OML Set Channel Attributes
containing the hopping parameters. This change is needed for the
new BSC_Tests.TC_fh_params_* test cases.
Change-Id: I38692252baa7a9fc23078121db0a17557950e4d4
Related: SYS#4868, OS#4545
Latest code relied on features from libosmocore master (> 1.3.0). New
libosmocore release 1.4.0 is now available, so drop the TODO and update
it now, since we can already refer to it.
Change-Id: I992f7e6d5884e53eab8da839d8e77736f9d751c3
See previous commit adding the unit test about the error description and
expected behavior.
The wrong behavior appeared due to step_size_mdB being unsigned and the
whole addition at the left side of the comparison being turned too as
unsigned, hence a small negative value turning into a big positive
value, and tpp->p_total_cur_mdBm not being updated to speed up the power
ramping.
Change-Id: I36a34362ebc90226fd8e1e190f898c3718fd923a
The test code is extended to support testing more than one ramping loop.
A new test ramping test is added, which shows buggy behavior, since
being in -10dBm and targeting 10dBm with max_initial_pout_mdBm=0 should
immediatelly jump -10->0 and then slowly ramp up (2dB) 0->10dB.
The issue will be fixed in next commit.
Change-Id: I5adc9008ac415eb23274755fc8270df8eebdc6fb
osmotrx fn-advance (which is the clock_advance variable here) and
osmotrx rts-advance together make up the minimum delay the BTS can react
to a channel request, etc.
The default of 20 are around 92ms which is clearly too much. With
modern hardware and using SCHED_RR a lower value should not be an issue.
See OS#4487 for some related measurements on more CPU-limited devices like a
LimeNet-micro3.
Fixes: OS#4487
Fixes: SYS#4885
Related: SYS#4881
Change-Id: I7da3d0948f38e12342fb714b29f8edc5e9d0933d
We gain other features from libosmovty for free, like configuring
cpu-affinity of the only thread in the process.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: Ice46e406b84fa11afcc7ba31e521e7677df73cf3
The idea behind the baseband frequency hopping is quite simple: we
have several RF carriers (transceivers) transmitting and receiving
on fixed frequencies (just like in a regular multi-trx setup), and
an additional burst routing layer between the schedulear and the
transceiver interface (TRXD over UDP).
Speaking in terms of the proposed implementation:
- on Downlink, dlfh_route_br() calculates the ARFCN corresponding
to the current TDMA frame number according to the hopping sequence
parametets, and picks the transceiver with matching ARFCN;
- on Uplink, ulfh_route_bi() iterates over the transceiver list of
of the BTS, calculating hopping ARFCNs for equivalent timeslots,
and picks the one with ARFCN matching the received burst.
In order to avoid frequent transceiver lookups on the Downlink path,
dlfh_route_br() maintains a "cache" in the timeslot state structure.
Unfortunately, this "cache" seems to be useless on the Uplink path,
so ulfh_route_bi() always needs to lookup the matching transceiver
for each burst received over the TRXD interface.
It may also happen that the scheduler will be unable to route an
Uplink or Downlink burst, e.g. due to inconsistent / incorrect
hopping sequence parameters received from the BSC, or in case
if a transceiver gets RF-locked by the BTS operator.
Such events are logged as "FATAL" and aditionally signalled by the
following osmo-bts-trx specific rate counters:
- trx_sched:dl_fh_no_carrier (Downlink), and
- trx_sched:ul_fh_no_carrier (Uplink).
Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
On receipt of either SIGTERM or SIGINT the shutdown FSM initiates
ramping down of the transmit power on Downlink. I noticed that
for some reason osmo-bts-trx stops sending Downlink bursts during
the process of ramping down.
I also noticed the following imporatant message:
DL1C NOTICE scheduler_trx.c:287 No more clock from transceiver
despite the transceiver is still powered on and keeps sending
the clock indications over the TRXC interface.
As it turned out, the problem is that on receipt of either SIGTERM
or SIGINT, we also raise the global 'quit' flag, so in the scheduler
trx_sched_clock() stealthy stops handling the clock indications.
Let's ensure that clock indications are handled regardless of the
state of 'quit' flag, so the ramping down would work as expected.
Change-Id: Ia71133d6f0b900e5e103595c83303a7cc5c06edf
Until now, power-ramp max-initial was only taken into account in order
to skip ramping if the desired target level was below it, in order to
forbid growin too quickly or applying directly to much power given power
amplifier requirements.
However, in the event that a higher tx power level is desired,
max-initial was not taking into account and ramping simply started from
current tx power level, which could be a lot lower than max-initial.
Allow shortcutting the ramping in that case so that max-initial is
applied directly, and ramping continues from there, in order to have a
more expected behavior (max-initial applied the same).
Since max-initial can since a few commits before handle a negative
value, this means One can for instance set max-initial to -10 and still
keep the old behavior of ramping step by step from -10 (rf-locked in
osmo-bts-trx) to 0 or 7 or whatever is the nominal power
(max_power_red).
Change-Id: I4e5742ecdbf66d77ff9445999f6fff43bbf4856a
If TRX is administratively locked during startup, for TS conigured as
TCH/F_PDCH the BSC will send a ACT PDCH message, but osmo-bts-trx won't
apply it by signalling it as available to the PCU, since the TRX is
locked.
That means the ts->flags contains the pending action to activate
it until it is unlocked. As a result, calling trx_set_ts() on it was
hitting the assert inside which expects not to apply the TS until it has
been confirmed by the PCU.
Let's still skip setting the TS and let pcu_tx_info_ind() trigger the
activation confirmation from PCU, since the TRX has just been unlocked.
Fixes following assert:
Assert failed (ts->flags & TS_F_PDCH_PENDING_MASK) == 0 /osmo-bts/src/osmo-bts-trx/l1_if.c:34
Change-Id: Ie3cad15d31870346d03a6e2f6dd32a9d2dd3067e
This allows for instance ramping up from -10 dBm -> -4 dBm if NOMTXPOWER
of SDR is really low (below 0dBm) or because the max_power_red is >=
NOMTXPOWER.
Related: SYS#4920
Change-Id: I0f27fb7b86b58c5a80f5342b66ff4f5d1b775498
Fix power ramping if administrative state changes while previous
opposite change was already ACKED but power ramping was still ongoing.
With previous code, osmo-bts-trx would have sent a NACK and BSc would
drop the BTs link as a result.
Change-Id: I6c5240710ef6d223651dfb4a8db939b5d2f974ca
Ramping down was set up with a target of -10 dBm, but then the code only
waited for all TRXs to be at least 0dBm, meaning that if operating more
than 1 TRX, the FSM could transit to state ST_WAIT_TRX_CLOSED when one
TRX reached -10 and other were already equal or below 0 (but not yet
-10). As a result, later on, when other TRXs reached -10 dBm they would
trigger EV_TRX_RAMP_COMPL which was not expected (no use) in
ST_WAIT_TRX_CLOSED.
Related: SYS#4864
Change-Id: If7af0b138efe78ec591c199a19fc22b304416a13
They were both half implemented but named differently, due to myself
adding them during the initial FSM implementation. This prevents
osmo-bts-trx sending a POWEROFF when OML link is dropped.
Related: SYS#4864
Change-Id: Ic2dab864b6d4075dfb9a1e4acfd9af013c9c46fe
How to reproduce:
* Configure a TS to be TCH/F_TCH/H_PDCH in osmo-bsc.cfg
* Run the network with osmo-bts-trx, then use osmo-bsc's "rf_locked 1"
* Then, unlock it: "rf_locked 0"
* The following assert will be hit:
Assert failed ts->dyn.pchan_is == ts->dyn.pchan_want /osmo-bts/src/osmo-bts-trx/l1_if.c:349
"""
(gdb) bt
#0 0x00007ffff5bb9355 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff5ba2853 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff6832361 in osmo_panic_default (
fmt=0x555555814e60 "Assert failed %s %s:%d\n", args=0x7fffffffc6e0)
at /libosmocore/src/panic.c:49
#3 0x00007ffff683249d in osmo_panic (
fmt=0x555555814e60 "Assert failed %s %s:%d\n")
at /libosmocore/src/panic.c:84
#4 0x000055555570fdf7 in trx_set_ts (ts=0x7ffff1e6bce8)
at /osmo-bts/src/osmo-bts-trx/l1_if.c:349
#5 0x00005555557133c1 in bts_model_chg_adm_state (bts=0x627000000160,
mo=0x7ffff1e0f8a0, obj=0x7ffff1e0f860, adm_state=2 '\002')
at /osmo-bts/src/osmo-bts-trx/l1_if.c:681
#6 0x0000555555769978 in oml_rx_chg_adm_state (bts=0x627000000160,
msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1044
#7 0x000055555576a8d3 in down_fom (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1129
#8 0x0000555555770aed in down_oml (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1476
#9 0x00005555557f8174 in sign_link_cb (msg=0x633000003e00)
at /osmo-bts/src/common/abis.c:188
#10 0x00007ffff73b5935 in ipaccess_bts_read_cb (link=0x6120000030a0,
--Type <RET> for more, q to quit, c to continue without paging--
msg=0x633000003e00)
at /libosmo-abis/src/input/ipaccess.c:980
#11 0x00007ffff73a1060 in ipa_client_read (link=0x6120000030a0)
at /libosmo-abis/src/input/ipa.c:72
#12 0x00007ffff73a2458 in ipa_client_fd_cb (ofd=0x62f000038a50, what=1)
at /libosmo-abis/src/input/ipa.c:136
#13 0x00007ffff67ebfa7 in osmo_fd_disp_fds (_rset=0x7fffffffdda0,
_wset=0x7fffffffde40, _eset=0x7fffffffdee0)
at /libosmocore/src/select.c:227
#14 0x00007ffff67ec38c in _osmo_select_main (polling=0)
at /libosmocore/src/select.c:265
#15 0x00007ffff67ec46b in osmo_select_main (polling=0)
at /libosmocore/src/select.c:274
#16 0x00005555557ef089 in bts_main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/common/main.c:354
#17 0x00005555556fe621 in main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/osmo-bts-trx/main.c:176
"""
Related: OS#4920
Change-Id: Ia3210e24b921fd0c67f77068b7ef4a65f270cd11
Waiting until all other TRX are provisioned before really sending
POWERON helps avoiding race conditions where TRX!=0 are not yet fully
configured at the TRX side before POWERON is called.
This solves for instance the situation where after POWERON RSP the BTS
started ramping up on all TRX while on some NOMTXPOWER RSP was yet not
received...
Related: SYS#4920
Change-Id: I906be4714807c7a2793971cb6062120e24337d7b
The state of each config required is now tracked through the "acked"
variables, this way the FSM can know when all configs are confirmed by
the TRX and can proceed to submit POWERON command.
With this version each TRX is still totally independent (there's an FSM
per TRX), which means POWERON can be sent on TRX0 before TRX!=0 are
fully configured. As a result, powe ramping may start before we know the
NOMTXPOWER of a TRX. This kind of issue will be fixed in next commit.
Related: SYS#4920
Change-Id: I1b736a4be5ce52a854f5767d8609153e1f4c08d9
With prior code state managing the TRXC side of osmo-bts-trx, there are
plenty o cases (race conditions) where things can go wrong/unexpected,
because there's really no infrastructure to wait and synchronize between
different TRXs (eg wait until all are configured to POWERON), or to
simply keep well known per-trx state regarding lower layers.
In order to fix in the future all of those issues and to sanitize
current code, a new per-trx FSM is introduced, which takes care of
submitting TRXC commands and waiting for response when needed to manage
the state of the TRX.
Related: OS#4364
Change-Id: I2a00c23df15840e33fbb232c9e1dd6db128f63f6
the RSL link has nothing to do regarding the state of the Radio Carrier,
as in it being up is not enough to have a working (enabled) Radio
Carrier.
Change-Id: Iefb5c4e1097233b5c31e4d621c544d51516af678
At that time we schedule a POWERON command towards osmo-trx, so let the
callback of RSP POWERON set the OPSTATE in l1if_poweronoff_cb rather
than setting it without waiting for confirmation from osmo-trx.
Change-Id: Ib36a073cae5e1522821a04d8806648562f4e0f5b
Move all struct gsm_bts_trx references from bulky gsm_data to its own
file containing all related definitions and implementations. Also move a
few functions clearly related to that object which were placed in bts.*
Change-Id: Iebaf5b221c48b571f45408af867ce6f9c0cd9f4a
commit d211c490ca avoided sending
GSMTAP packets on the virtual Um interface with type
GSMTAP_CHANNEL_UNKNOWN by relying on gsmtap_makemsg returning NULL.
But that's not the corect approach since it's totally fine to be sending
GSMTAP_CHANNEL_UNKNOWN on some GSMTAP cases (for instance when the
program fails to infer the type when decoding a message), since then
this way one can study pcap files and find the offending encoded
messages which failed to be decoded.
This patch goes togehter with revert patch introduced in libosmocore as
explained in the commit referred above.
Change-Id: I233afd930d3e43f7b120d40192c7c192102e38d9
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
Ramp down when BTS is administratevly locked, and ramp up when it
becomes unlocked again.
Af ramping down, bts_model_trx_deact_rf is called to make sure all
channels are released.
power_ramp_start() is dropped from inside bts_model_trx_deact_rf since
it's not the proper place. In there we simply want to instantaneously
drop RF.
Related: SYS#4920
Change-Id: Ib7a7b0a0c24779349f142215f0bb32b72c86ce70
This should provide a quick way to check if the system is frequently
overloaded over time and hence downlink FNs are scheduled later than
expected.
Change-Id: I0051b9ab18ebc9f92db11374d856de94f155efa4
I believe the modern compilers are smart enough to optimize the
outer (per-timeslot) loop of trx_sched_fn() in a way that TDMA
frame number is advanced after making sure that a transceiver
is powered on. However, it's still more perspicuous to check
availability of a given transceiver first.
Change-Id: I6a97000c1c84e36096e9ba378a489c82caa4cc5b
According to 3GPP 45.002, section 5.2.4, a frequency correction
burst is basically a sequence of zeros. Since br->burst is already
zero-initialized, there is no need to maintain and memcpy() another
sequence of zeros into it. Just set the length.
Change-Id: Ic4f6d550010da5caf4bc471ff1e184c9fab30c6d
In trx_sched_fn() we schedule Downlink bursts in advance, in order
to give the transceiver some time to process them. This function
handles all timeslots of all transceivers in a loop. The problem
is that the given frame number is overwritten on each iteration.
Let's say we have 4 transceivers, each with default fn-advance 20.
The given frame number N will be advanced 4 times, so the resulting
frame number for 4-th transceiver would be (N + 4 * 20) instead of
(N + 20) as expected. Therefore, all additional transceivers would
be served more and more in the future (depending on their position).
Change-Id: Ie3ab544eac81a675266df09cd2b7740e4183188e
There's a standarized way through OML's Administrate State to control
the status of TRX, so let's use and maintain that one rather than this
ad-hoc hack.
Related: SYS#4920
Change-Id: Ia7f190063c35e0ed8e2e734047b3aff608cd3ce3
Setting the phy link of a trx to SHUTDOWN sets operative state to
DISABLED, so we use operative state as a condition to know whether all
TRX are already powered off properly and we can exit.
Change-Id: I2bcd211d7edcc8486461a555d6c470a94b166ed7
Some backends like osmo-bts-trx require exchanging messages like
POWEROFF to close the TRX, and hence need some time. Switch the function
to expect result asynchronously by calling a callback.
This will be used later to wait until all TRX are really powered off
before exiting the process.
Change-Id: I7d76b600fc06e1114b35bf0c2d08eff5bbd1b69a
It makes more sense to first deactive RF on all TRX and finally close
them totally. This way we keep consistency between all TRXs and it's
easier for lower layers which may need to close them all at once. Also
in the event that we want to turn bts_model_trx_deact_rf to return
asynchronously.
Change-Id: Ib62358384e37a5cef692926439462042fab0138c
bts_model_trx_close is only called during bts_shutdown immediately after
bts_model_deact_rf, so its logic keeps being essentially the same after
this code movement.
On the other hand, bts_model_deact_rf is also called during RSL link
establishment if it failed for whatever reason in
bts.c:trx_link_estab(). In that case, we want to make sure the TRX is
not used so we need to implement bts_model_deact_rf.
Change-Id: Id4eae743da81773a04b82e7b454071b0cc66677a
Upon BTS shutdown (for instance because the Abis link against BSC was
lost), stop the operation in an ordered manner (cell soft lock). This
means slowly decrease tx power so that MS have time to handover to other
neighbour cells.
Related: SYS#4920
Change-Id: I70e34dda8974ebd94aea33bd9fb1d99f9063cc55
Using an FSM here will allow for more complex ordered shutdown
procedures, like power ramp down, waiting for TRX deact asyncrhonously,
etc.
Current commit leaves everything in place already prepared to implement
ramp down, which will be implemented in next commit in the series.
Related: SYS#4920
Change-Id: I8f48f17e61c3b9b86342eaf5b8a2b1ac9758bde5
Using the VTY command will force that value and prevent osmo-bts-trx to
use/send NOMTXPOWER cmd over TRXC.
Change-Id: I496753bc74767a7e18b831768d9d422a738192b7
Together with previous counter L1SCHED_TS_CTR_DL_LATE, it allows
understanding which dl blocks are really lost (never queued) and which
were simply queued too late.
Change-Id: I456d0cfbef1e03b147ce7d968a3ec42dd728fe74
Old _shared one comes from time where we shared header with other
componenets. It's no longer the case sine a logn time ago.
The gsm_data_shared.h is only being included by gsm_data.h nowadays, so
let's simply merge it to simplify header dependency and struct
definitions.
Similarly, gsm_data_shared.c is renamed to gsm_data.c
Change-Id: Id60e7582e3a32dbc5e3531b87b2b49f07aee734d
We should always expect the msgb queue to be ordered by FN, so there's
no use in continue traversing the queue after we found a later primitive
than the one at current time, since next onews will be even more in the
future.
Change-Id: If57fc3d89a74e6cbc79fce80dae7bf4f77e9364d
According to 3GPP TS 08.58, section 9.3.4, BS Power IE indicates
the transmission power attenuation on a particular channel:
+--------------+---------+-----------------+
| Reserved (3) | FPC (1) | Power level (4) |
+--------------+---------+-----------------+
so let's change handling of this IE as follows:
- s/bs_power/bs_power_red/g, so it reflects 'reduction';
- store power attenuation value in dB, not in 2 db steps;
- get rid of ms_power_ctrl.bts_tx_pwr, it's always 0 anyway;
- fix rsl_tx_meas_res(): use lchan->bs_power_red;
- always check if FPC (Fast Power Control) flag is set;
- we don't support it, so reject messages containing it;
- fix rsl_rx_chan_activ(): properly apply the bitmask.
Change-Id: I16cc50dfca102030380a06e16c234d5f6698f38f
For those osmo-bts-trx specific logical channels with a generic
logical channel state associated, let's finally apply the BS Power
reduction (attenuation) value that was received from the BSC.
Change-Id: Ib692ff1a75a80fceccb481839c8514d4b2a547b9
This change simplifies access to generic logical channel state
(struct gsm_lchan) from osmo-bts-trx specific state (struct
l1sched_chan_state), so there is no need to look it up using
get_lchan_by_chan_nr() on receipt of each Uplink burst.
Change-Id: Ic4378020f980845b962f71b9e4b7faea738bc174
This change is similar to what we did for Uplink bursts:
- group all Downlink burst parameters into a single structure,
- allocate it once and pass a pointer to lchan handlers,
- pass a pointer to trx_if_send_burst().
Given that the structure is allocated and (zero-)initialized in
trx_sched_fn(), we can get rid of some memset() calls in lchan
handlers and thus improve the overall performance a bit.
Change-Id: If3014e69746559963569b77561dbf7b163c68ffa
It's easier to maintain the logical channel handlers in separate
files, rather than in a huge one (scheduler_trx.c, ~2k lines).
Change-Id: Ie5663fd90596b4800a4546675a323250bbb24c80
Since we are returning the pointer, it should always be grabbing a
reference (find doesn't do it).
In practice it's not much important since it is always created and not
found.
Change-Id: Ib84636663be2df33d497131c780b010b57f17e32
If for whatever reason (eg fn-advance too small) there's no burst
available for a PDCH TS where EGPRS is enabled, a dummy burst of size GSM_BURST_LEN
would be selected in _sched_dl_burst(), but the nbits length would still be set to
EGPRS_BURST_LEN above by func() pointer (tx_pdtch_fn()).
As a result, trx_if_send_burst() would later read EGPRS_BURST_LEN from the
dummy burst of size GSM_BURST_LEN.
The issue was found by ASan. See OS#4606 for more info.
Fixes: OS#4606
Change-Id: Iba6ccceed5c0f1db810259768678f174d39cbf8b
it was perceived that sometimes based on order of events (OML attr setup
and timing of RSL connections, etc.), the NOMTXPOWER for TRX!=0 can come
after the RSP POWERON, and hence the target power level for TRX!=0 is
not done correcty. This can be seen by running any test using the
ttcn3-bts setup of docker-playgrounds.git.
Change-Id: I2ec8dba61393be6edfab9e7e478e096e2d0933ad
The nominal transmit power is still only configurable manually from
osmo-bts-trx VTY interface. Support to retrieve the nominal power
from osmo-trx will come later.
Change-Id: Ia7c353e4c199e0fc3bcab55c45a4abda2c66d2c1
It's not something useful to see unless someone's really debugging that
part, and it shows up quite frequently.
Change-Id: I3c0dee36c7d34e6b1341b517ce3bcd1b275e69c1
Looking at GSMTAP during handover, I've noticed many packets on
RACH looking pretty much like false positives, all with RA=0x00.
I correlated GSMTAP traces with TRXD traces, and figured out
that they all are triggered by NOPE indications from osmo-trx.
Since a NOPE.ind carries no valid burst, all its bits are set to
zero. Funny enough, this sequence is still decoded just fine as
a valid RACH, so that's why we see it on GSMTAP. Later on it
gets rejected by L1SAP due to bad RSSI, ToA, and/or C/I ratio.
The is a side effect of [1]. In order to ensure proper Uplink
measurement reporting during handover, including the time
before the handover RACH is received, let's treat and handle
NOPE indications as Normal Bursts.
[1] Ice45d5986610d9bcef2a7e41f0a395ec779e3928
Change-Id: Ic69f3bc2b776a23374c28a6884080a54bc16ef5f
Related: OS#4592
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
EGPRS support, in particular MCS channel coding, was introduced
to osmo-bts-trx years ago, but we still report that it's not
supported. Let's stop confusing BSC, and set this feature too.
Change-Id: Iaf92764d266e12efd2350967deffae50fbbb3b9e
An additional octet is only needed if total number of features
cannot be devided by 8 without the remainder. Fix this.
Change-Id: Ie501e5a635493830e0597f7b2fa287b6448e660d
This makes use of the newly-introduced lapdm_channel_init3() API,
which provides the user (BTS in this case) to provide a human-readable
string identifier for each LAPDm channel. This identifier is
subsequently used in all related log lines to provide context.
This means we will now get context information about which specific
SAPI in which sub-channel (ACCH/DCCH) on which lchan/ts/trx/bts a given
message originated from.
Example:
DLLAPD <0011> lapd_core.c:829 ((bts=0,trx=0,ts=0,ss=0)[DCCH][0]) SABM(E) received in state LAPD_STATE_IDLE
Change-Id: I17e3d4797ec71e31d0775330ae36d2e1fd70423f
Depends: libosmocore.git Ie6742843fff809edffcac24c4dce4edf66bc71be
Related: OS#1938
This is not the right place to ship configuration examples for
other projects, and definitely not for abandoned ones.
Change-Id: Ib165b16f948126df8023bb42ad5d6d4b2fc11e6a
- get rid of gsm_lchan::mr_bts_lv, it's never used anyway,
- check IE length in amr_parse_mr_conf() before parsing,
- check return code of amr_parse_mr_conf().
Change-Id: Ibfd5845ea429945b352dd14421e86562998d65ca
This value will be soon acquired automatically by osmo-bts-trx by asking
over TRXC to new versions of osmo-trx which is the nominal tx power for a given trx.
However, to still be able to work correctly against older versions of
osmo-trx or other TRX implementation (older or current) not supporting
this new TRX comamnd, let's allow the user to force a given value
through VTY for Tx power to work correctly.
Change-Id: Ib1b6f80d3b54afc42db9d358a79582cc619c6ce4
Accidentally noticed this typo while working on osmo-bsc:
DNM ERROR abis_nm.c:525 BTS0 reported unknown variant
'omso-bts-trx' (expected 'osmo-bts-trx')
Change-Id: I45b0fb7b940ee4267e6ee315d18e5b95c9231894
Related change in libosmocore will let gsmtap_makemsg return NULL if the
channel type is unknown: Ib4147a33a75c3cf425c30da8b0678c7fba8a371d
Related: SYS#4822
Change-Id: Ic22ab71e520ab44429a93724250d349d16250801
Remove OpenSUSE bug report link, set version to @VERSION@, make it build with
CentOS 8 etc.
Related: OS#4550
Change-Id: Ia160d1a04b95e9efeb6c26eabd28c3697968d177
The amount of SUB frames that may occur in AMR is not fixed, nor can it
be determined by some formular or lookup table. The reason for this is
that the DTX period may negotiated dynamicly. This means that the lower
layers must make the decision if an AMR sub frame is a SUB frame early
and tag the repective measurement / frame they hand up to the upper
layers accordingly. However, regardles of the occurrence of DTX periods
the amount of SUB frames in AMR must be always 1 or more because SACCH
frames always count as SUB frames as well. Lets make sure that this is
respected in the debug log as well as in the logic that tries to
substitue missing SUB frame measuremnets.
Change-Id: I1fd91b576ff7274caa6d4356bcd7a4fa4311219d
Related: OS#4465
This redundant call to msgb_put() appends five '00'O octets to the
"Software Activated Report" message, so they look like an unknown
attribute(s). I accidentally noticed this in Wireshark.
Change-Id: I7377575135f4a154572891d1b5b39ff814b97f38
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_READ symbol when
copy-pasting somewhere else.
Change-Id: Id51ccb2c273c5f0fa4986f28bbd69a72d2dbaa0e
A debug line is printed whenever a measurement is added and it also
displays if the added measurement is a sub frame or not, lets display
all the other properties too, especially inv_rssi would help a lot as it
shows us the rssi values which are reported by the lower layers
Related: OS#2978
Change-Id: I0299b75e99661e8dd22ad6604a897db4533c3b2b
== How to reproduce?
phy 0
instance 0
dsp-trace-flag error
dsp-trace-flag debug
== What happens?
Program received signal SIGSEGV, Segmentation fault.
0x432dbe64 in strcasecmp () from /lib/libc.so.6
(gdb)
(gdb) bt
#00x432dbe64 in strcasecmp () from /lib/libc.so.6
#10xb6ed69ec in get_string_value () from /usr/lib/libosmocore.so.12
#20x0001bcf0 in cfg_phy_dsp_trace_f ()
#30xb6fc1080 in ?? () from /usr/lib/libosmovty.so.4
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Change-Id: I23137930f81bfa8adbb62828f341470c11202b5e
The function ts45008_83_is_sub rougly decides if a frame is a SUB frame
or not. This works by checking the frame number against against lookup
tables. This works fine for codecs where the occurrence of SUB frames is
fixed. However for AMR this is not the case as the DTX periods are
dynamic. Here it is the responsibility of the lower layers (phy,
frame decoding) to tag SUB frames early since making the decision later
based on the frame number is not possible.
The parameter is_amr_sid_update was probably added as a placeholder. It
is set to falls by the callers of the function. Lets remove this
parameter as a late decision if an AMR frame is a SUB frame will never
work.
Change-Id: I125d5ff592218a9e98130a6a7b6bbc6378ce4132
Related: OS#2978
Currently we do not detect any of the DTX frames (SID_FIRST, SID_UPDATE
etc.) Detecting and tagging those frames as is_sub is important for
measurement processing. Also the RTP marker bit must be set on each
ONSET frame.
- Add detection of DTX frames
- Tag DTX frames as is_sub and set frame type to AMR_SID
- Set RTP marker bit when ONSET frames are received
Change-Id: I5afe730fff2fa3199a5913b0de4f5c7b23a39f31
Depends: libosmocore I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
Related: OS#2978
Many hardware parameters of the LC 1.5 were not exposed to the user.
This change introduces most of the features, being very similar
to osmo-bts-oc2g code. Mostly based on commit
653e974fec00414ba85baf258ccc46ea778a53bd from NuRAN's osmo-bts fork
at: https://gitlab.com/nrw_noa/osmo-bts
Change-Id: Ib16e7d423fc7030573acd86fbd356ae96697ed5d
/usr/bin/ld: /home/laforge/projects/git/osmo-bts/tests/sysmobts/../../src/osmo-bts-sysmo/tch.c:584: undefined reference to `femtobts_tch_pl_names'
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: multiple definition of `pdch_msu_size'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:108: first defined here
/usr/bin/ld: l1_transp_hw.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: multiple definition of `femtobts_l1prim_type'; main.o:/home/laforge/projects/git/osmo-bts/src/osmo-bts-sysmo/femtobts.h:71: first defined here
see also: https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000651.html
Change-Id: I4a9896153876fcda496365776883827746205f00
some of the log categories in logging.c are set to LOGL_INFO or even to
LOGL_DEBUG. This is too verbose. Lets set those categories to
LOGL_NOTICE. Also the BTS manager programs (...bts_mgr.c) use LOGL_INFO
by default. This should be set to LOGL_NOTICE as well
Related: OS#2577
Change-Id: I6e7a635f9b4a93529661dafc591d512d7b7e8c75
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I9b18ac186d5870e3a6b46678ab7fb2154c9cae07
When a NOPE indication is received from the TRX normally a separate
handler (.nope_fn) is called. It turned out that calling the Uplink
handler (.ul_fn) on NOPE indications is the usual case, so let's
remove the .nope_fn member and call the Uplink handler directly.
Since a NOPE.ind comes without burst bits, the Uplink handlers must
check bi->burst_len to avoid uninitialized memory access. For some
logical channels (in particular RACH, PDTCH/U, and PTCCH/U) it does
not make sense to call the Uplink handler, so we ignore them.
Change-Id: Ice45d5986610d9bcef2a7e41f0a395ec779e3928
Related: OS#4461
According to 3GPP TS 44.004, section 7.4a, two alternative RACH
block formats are specified: 8 bit (1 octet) and 11 bit. The
bit order is little-endian (right to left).
In L1SAP PH-RACH.ind structure (see ph_rach_ind_param) we use
a field of type uint16_t to store RA values regardles of the
block format. Thus when packing it to bytes, we cannot just
cast uint16_t* to uint8_t*, we need to do some bit shifting.
Change-Id: I0e91d825bb2e1897647dd5403c311d833a89ff2e
Send test failure event report OML message to the BSC. I found this
useful while manually testing related handling code in OsmoBSC.
Related: OS#1605
Change-Id: I0c4eba1636d8faf5012db26643bdf1d9fb6bfa1e
The sample configs supplied within the doc/trx directory set the
rx-gain parameter to 1. A low value like this may cause a noticeable
degration of rx performance (For an USRP B200 an rx-gain of 38dbm is
recommended). Lets remove this seting from the sample configuration to
allow the default settings in osmo-trx to be applied.
Change-Id: I76be1739b638b3c1b0de5ac667eed53397631caa
Related: OS#4467
Without using the NOPE indication it might happen that we get
into the following situation:
* bursts 0,1,2 of a given block are received
* burst 3 is lost on the radio interface, OsmoTRX sends NOPE
* osmo-bts-trx doesn't pass the NOPE the the rx_tch*_fn()
* we never detect the end of the block, never perform decoding
and even if the burst could be fully decoded, we loose the block
Related: OS#4661
Related: OS#2975
Change-Id: Idfc5c9a23db808c5f87ef5646c7e1d1cd3127371
Without using the NOPE indication it might happen that we get
into the following situation:
* bursts 0,1,2 of a given block are received
* burst 3 is lost on the radio interface, OsmoTRX sends NOPE
* osmo-bts-trx doesn't pass the NOPE the the rx_tch*_fn()
* we never detect the end of the block, never perform decoding
and even if the burst could be fully decoded, we loose the block
For voice, it can lead to lost RTP frames in uplink, which is also
problematic.
Let's deal with burst_len=0 in rx_tch*_fn() and use it as nope_fn.
Closes: OS#4661
Related: OS#2975
Change-Id: I0fbf4617daf24bd8aecfd9cfe1efd66cf73a277a
This fixes a regression introduced in I710d0b7cf193afa8515807836ee69b8b7db84a84
We (obviously!) cannot compute the BER before performing convolutional
decoding.
Change-Id: I4e57f45d49cb513e4843e56f50c8de6980958fdc
Related: OS#2977
Related: OS#4667
The VTY option to bind the virtual Um multicast to a specific
network interface has existed ever since osmo-bts-virtual was
first merged to the repo. However, embarrassingly, until today
it never did anything, i.e. the code to actually perform the bind
was missing.
Depends: libosmocore.git Ib52d22710020b56965aefcef09bde8247ace4a9c
Change-Id: I303f2e616d2d32b5a8005c3dcf0f5fad19ad3445
Related: OS#2966
This can be used to determine the multicast TTL packet and hence
how far the packet will propagate in the network. If you want to
operate the virtual Um only on your own machine, a TTL of 0 would
prevent the packets from ever being transmitted on your local
ethernet segment.
Change-Id: I18a9f93b764aee4e1dc68a1c6ac4d078e52ca61d
Related: OS#2966
GSMTAP_CHANNEL_VOICE is the mechanism by which GSMTAP can [finally!]
be used to transport circuit-switched voice codec payload, and not
just signalling.
Original patch by Neels Hofmeyr, heavily extended by Harald Welte.
Depends: libosmocore.git I952044a17334f35712e087dc41781805000aebc1
Change-Id: I1cd9a251ce0b87181a0822d7940bbfc9f1428543
In l1sap_ph_data_ind() we can use msgb_pull_l2() which is an exact
implementation of the functionality there.
In l1sap_tch_ind(), the existing code is actually wrong by making the
assumption that the msgb contains exactly an entire osmo_phsap_prim.
Better to also dynamically compute the number of bytes to ensure
we only pull those ahead of the L2 header, no matter what their exact
count.
Change-Id: I13f7f8ba93795e40b1fb4a306fe765e059f642cf
During the process of bootstrapping, it may happen that System
Information Type 3 is not yet received from the BSC, while the
BTS already needs to transmit a block on AGCH or PCH.
Since the RSL link is established later than the OML link, it's
kind of expected, so we should not log it as error.
Change-Id: I41aa3dbe375cf42c39032bafa80dba94d6219d35
osmo-bts-virtual uses GSMTAP over multicast groups to communicate
with one or more virtphy instances. There are some well-known default
multicast groups, but those can also be overridden via the VTY.
The problem is: If you actually try that, osmo-bts-virtual will abort,
as we try to talloc_free() when using osmo_talloc_replace_string()
on the constant default string.
The proper solution is to talloc_strdup() the constant default string
when setting the default value in bts_model_phy_link_set_defaults().
Change-Id: Ia96fea891a22e5a3c47ce658eda130ba8d4fc411
For osmo-bts-sysmo the MPH INFO MEAS IND indication is still sent
separately. Lets merge the measurement information into the PH DATA
Change-Id: Iffe7865727fbf9bca8eb32a96e8ea05cf718a948
Related: OS#2977
The struct members ber10k, ta_offs_256bits and lqual_cb in ph_data_ind
are only populated when the pcu_direct flag is not set.
The pcu_direct flag is set when the pcu is directly attached to the phy
and all pcu related traffic (pdtch) is handled without sending it through
osmo-bts-sysmo. For those cases osmo_bts_sysmo will not make use of
those struct members, even if they were populated. When the PCU is not
directly attached the data is needed because it is sent through the
pcu_sock to the PCU.
Lets remove the check because it is not required. Also in future patches
where measurement indications and data / tch indicatins are merged the
struct members are also needed to carry the measurement information for
SACCH as well.
Change-Id: Iaa37bb62af4f5eb4b6e684cb754e68d11e6fd676
This line appears tens of times per second when a call is ongoing,
making it impossible to follow logs on INFO level.
Change-Id: Iadb1baf55df2f6d96f85260f2e8d03627fef7e66
Some use LOGPC, but were used after a LOGP with a trailing newline.
Let's simply add some defines/macros to be able to include it into a
normal LOGP easily insted of having a function.
Change-Id: Ie082b11c9d6d00ff2206184f03f6e3647c3da18c
src/osmo-bts-sysmo/Makefile.am:25: warning: bin_PROGRAMS was already
defined in condition TRUE, which
includes condition ENABLE_SYSMOBTS_CALIB
src/osmo-bts-sysmo/Makefile.am:10: ... 'bin_PROGRAMS' previously defined here
Change-Id: Ib2334dccefd507eaaa6d33e58d4c1e029d7fd540
The MPH INFO MEAS IND indication, which contains the uplink measurement
data is sent in parallel to the PH DATA and TCH indications as a
separate indications. This makes the overall uplink measurement data
processing unnecessarly complex. So lets put the data that is relevant
for measurement into the PH DATA and TCH indications directly.
This change only affects osmo-bts-trx at the moment. In order to keep
the upper layers (l1sap.c) compatible we add an autodection to switch
between separate measurement indications and included measurement data.
Related: OS#2977
Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42
Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
The variable irssi_full_sum is not populated with a dummy value when we
are not able to compute irssi_full_sum. Instead we mistakenly write
MEASUREMENT_DUMMY_IRSSI to ber_full_sum, which is wrong
Change-Id: I44d7cb48e3c68ab1b48c78cceb9381ce3e39d7e8
Related: OS#2987
The timing advance controller that is implemented in loops.c of
osmo-bts-trx only works for osmo-bts-trx and not for any of the phy
based bts. Lets move the timing advance controller into the common part
and make it available for every bts. Also lets add a unit-test.
Change-Id: If7ddf74db3abc9b9872abe620a0aeebe3327e70a
Related: SYS#4567
Due to relatively small training sequence of Access Bursts, there
can be frequent false-positives (basically noise). Fortunately,
we can distinguish them from the real Access Bursts by checking
the signal measurements attached to them (BER, ToA and C/I).
Let's reduce verbosity of logging messages as they are mostly
useful for debugging and may confuse the users / operators.
Change-Id: I7ab6727ffff00140a7f9e762b299b711481393f1
rsl.c: In function ‘rsl_rx_ipac_XXcx’:
rsl.c:2147:39: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 28 [-Werror=format-truncation=]
2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr);
| ^~
rsl.c:2147:3: note: ‘snprintf’ output between 5 and 260 bytes into a destination of size 32
2147 | snprintf(cname, sizeof(cname), "bts@%s", ipstr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Id982a814f401e304327d25c77666f039bc156c1f
The variable ta256b_sum is int32_t and num_ul_meas_actual is unsigned
int. When ta256b_sum is negative the division produces the wrong result.
This is beacuse the division is performed unsigned as the usual
arithmetic conversions promote to unsigned where both both operands are
the same width.
Lets fix this by casting num_ul_meas_actual to signed.
(Note that in the same function there are various other averages
computed in the same pattern, but they have unsigned operands and so are
correct.)
Related: SYS#4728
Change-Id: I37e3f69109c5ca2948bd4cdb7aa017bf2fcb8172
When a bad SACCH frame is received the processing of the frame is ended
early and lchan_ms_pwr_ctrl() is not called. This means that the power
control loop does not get informed about a situation where the signal
level is very weak and increasing the ms power would make sense. In
order to ensure that the power control keeps working on lost SACCH
frames, lets call lchan_ms_pwr_ctrl() with the current RSSI and the
requested (BSC) power setting.
Related: OS#4281
Change-Id: I4fb85754b1a69376b02da7f4b175c6e8ec9cc35c
osmo-bts currently does not generate a measurement report in case the
SACCH of the related traffic channel is lost. This is a problem because
the moment when reception gets bad measurmenet reporting is crucial to
carry out handover decisions effectively.
The presence of a SACCH block controls the conclusion of the measurement
interval and the sending of the RSL measurement report. The latter one
not only requires a measurmenet indication, it also requires a fully
intact SACCH block.
Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to
ensure a SACCH block is always reported up to l1sap.c. In cases where
the SACCH is bad, trigger the sending of the RSL measurement report
manually without attaching the measurmenet data from the MS (which we do
not have in this case)
Related: OS#2975
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
osmo-bts-trx used to have its own (low-level) MS Power Control loop,
but recently it has been ripped out. Since [1], the process fails to
start if the configuration file still contains 'ms-power-control dsp'.
Let's be more tolerant: override 'dsp' by 'osmo' and print a warning.
[1] I49706926b1e962b18791174627bc3cc0cd0cd9d5
Change-Id: I4facd21bca3d8cb80d21e83ea267bc013e474533
Rename some variables so that:
* Variables containing power control levels end up with "_lvl".
* Variables containing power levels end up with _dbm.
* Move old current_dbm var to be ms_dbm, to match its power control
level counterpart ms_power_lvl, and add current_dbm to match its
counterpart ns_power_ctrl.current.
Now that variables are more clear, it also becomes clear that old "diff >
0" condition, apart from difficult, was currently wrong, since in order
to print the raise/low verb we want to compare between old and new
values, not between received and new values. Let's fix that in this same
commit.
Change-Id: I4e279a6b93fbcc5da25bf8c9213310939fd493ce
Simplify when the fixed field is set in rsl_rx_chan_activ.
Comment talks about enabling autonoumous control loop, but it is
actually describing it when disabling it, which is confusing.
Change-Id: Id6b444a33ab062f6dab11a0ce62d8aecaea87591
When logging about filtering access bursts, let's indicate if this is
on a CCCH, PDCH or handover related.
Change-Id: I03f21f2b54cbe5aad36ac71a614d5df98867df80
This way it's much easier to introspect the library internal
talloc allocations from the VTY interface.
Change-Id: Ic8d9fc7ce3da8abf0ea73d2b20366133cd801c37
Let's drop it instead of having code duplication from common code in a
lower layer, and maintain only the one in l1sap for all BTS models.
As a result, osmo-bts-trx loses feature BTS_FEAT_MS_PWR_CTRL_DSP and
will only be able to use "ms-power-control osmo" in VTY, which will be
enabled by default (meaning: change of behavior, now MS Power Control is
enabled by default in osmo-bts-trx and can only by disabled by BSC).
Old bts-trx specific VTY command "(no) osmotrx ms-power-loop" is marked
as deprecated but still working for more usual case (1 TRX configured)
to avoid breaking backward compatibility.
TA low level loop is still kept in loops.c and will be moved to l1sap at
some point too.
Related: OS#1851
Change-Id: I0d8b0c981d9ead91d93999df6e45fb06e426aeb9
On an ARM toolchain:
scheduler_trx.c:294:3: warning: format '%ld' expects argument of type 'long int', but argument 10 has type 'int'
Let's cast it to long int to make sure correct size is applied in all
platforms.
Change-Id: I701b3dbc4e84db21cf02305d374b0df731e70313
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
It's not a good idea to request big changes in MS Power based on
sporadic bad signal received, let's instead change announced MS power
levels more smoothly to avoid possible big signal strength fluctations,
similar to what is already done in osmo-bts-trx specific loop (loops.c).
Related: OS#1851
Change-Id: Iecc4ec7e21471ec853ad2d5659af4052aba5444c
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
There is theoretical risk that when calculating the BER that a division
by zero occurrs. Lets add a check to avoid n_errors / n_bits_total when
n_bits_total is zero.
Change-Id: I1c0731b9a60be4b8c0c84b85b4403168120ceacd
Fixes: CID#205696
Fix error while starting osmo-bts-virtual with the example config:
"This BTS model has no DSP/HW MS Power Control support"
Fixes: c693067b7e ("Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSP")
Change-Id: I4f9a06e85d58294719a24197eb1c42a69fbd03d6
A NOPE.ind indicates absence of an Uplink burst, thus it does not
carry a burst. Let's init the burst length to avoid uninitialized
memory access in the scheduler code.
Change-Id: I77f686bf7df385215892e71733a28ff0d90d7222
Fixes: CID#205857
Each logical channel can now optionally have an additional handler,
that will be called when a NOPE / IDLE indication is received from
the transceiver. The aim of that handler is to keep the logical
channel state updated in case if one or more Uplink bursts are lost.
Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637
Related: OS#3428
It indicates whether BTS model supports managing an MS Power Control
Loop over HW/DSP instead of using the software based osmocom algorithm
present in osmo-bts.
osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one
since it acts on lower layers and interferes with osmocom algorithm
since it controls the same end variable "lchan->ms_power_ctrl.current",
this way we make sure both aren't enabled at the same time.
Old behavior in kept: if common upper-layer algo is not enabled
explicitly in VTY (ms-power-control osmo) and bts-trx specific lower
layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no
power control is done at all.
Related: OS#1851
Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
Several improvements have been made lately to MS Power Control loop from
osmo-bts-trx in loops.c. Let's port these to the common algorithm.
Related: OS#1851
Change-Id: I579967cc8bb69dc76a315c6c9d3a351f5961d92f
The affirmation written there is not true, since actually it depends on
the band. For instance, for DCS1800 the maximum MS power is provided by
class 3. Let ms_pwr_ctl_lvl() take care of campling instead.
Change-Id: I744e7c315b818a1e7d3dd2579cd483c693d89b73
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
Thies field is used to store and retrieve whether MS power needs to be
calculated and updated by osmo-bts software or autonomously by lower
layers. Previous name was not clear
and may have been understood as indicating whether MS Power Control loop
is done or not in general, and the responsible for that is located under
lchan's ms_power_ctrl.fixed.
Related: OS#1851
Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
Some bands, such as DCS1800, contain power levels such as 29, 30 and 31 not following same
unified sequence other power levels follow regarding conversion to dBm
values.
This makes extremly complex and prone to error comparing different power
levels. Let's instead use dBm values to calculate and crop desired new
value, and then convert it back to TS 05.05 ms power control level
value.
With this commit the control loop should be able to manage correctly the MS power
levels explained above.
Related: OS#4244
Change-Id: I0160637c5ffa606ee3081ad30be8e6f2a42b725b
Otherwise older ms_power value will be kept and used as a maximum.
From TS 08.58 sec 4.8 "MS power control":
"""
If power control is supported by BTS and it is to be used,
this is indicated by optional parameters in the MS POWER CONTROL
message (or the CHANNEL ACTIVATION message). Based on the
measurements performed on the uplink, TRX then attempts to keep
the power control parameters within the limits set by the
MS POWER CONTROL message (or by the CHANNEL ACTIVATION message).
"""
Change-Id: I0583eef477c33279ee5bfcda80141f365413a276
Make sure the variables n_errors, n_bursts_bits, n_bits_total are always
initalized. For example in rx_tchh_fn() the value for n_errors is
defined in a switch statement, where the default lets n_errors
uninitalized, which is in that particular case a theoretical problem,
however, lets make sure that the variables n_errors, n_bursts_bits and
n_bits_total are always initalized with 0
Related: CID#205452
Related: CID#205451
Change-Id: If28ea11cc111c7d73ca47b25e65ce399e5baa4c1
When sched_compose_tch_ind, sched_compose_ph_data_ind or l1if_process_meas_res
is called from rx_tchf_fn or rx_tchh_fn the frame number of the beginning of
the block is required. At the moment this frame number is calculated
wrongly using strange formulas. Lets use gsm0502_fn_remap() to calculate
the beginning of the block properly
Change-Id: I37601ddd85e4287dd9e41ad4a8cb7d314de1a83d
Depends: libosmocore I3d71c66f8c401f5afbad9b1c86c24580dab9e0ce
Related: OS#3803
This is similar commit to Ifda92155bd9c277ac150a327a7ab63c854087788,
which previously fixed same issue for osmo-bts-trx specific power
control loop code.
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Should fix TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max for non-bts-trx BTS
models.
Related: OS#1622
Change-Id: I376b52d7bee44132993a69cf532bd418171d0ca2
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Fixes TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max
Change-Id: Ifda92155bd9c277ac150a327a7ab63c854087788
All other Uplink burst handlers print frame number of the last
(currently received) burst. Let's make rx_data_fn() consistent.
Change-Id: Ie5762a132326be3ef4e4e38cc126f05d51098a20
Make it obvious for compilers and for coverity, that the sapi value used
to shift a bit for the sapi_mask is always <= 31. The sapi value is an
index of the value string l1sap_common_sapi_names, which has 24 entries.
Fixes: CID#205067, CID#205068
Change-Id: Id8be0ab67479b1f76a4f624bd3a5242e4fe59f4b
Change uint8_t sapi to int, so we can properly assert on errors from
get_string_value().
Fixes: CID#205066, CID#205069
Change-Id: I4d30afacfab93051868ae8f462cee9ad3dbc7fd0
Before this patch, if due to whatever reason the TRX started fine (RSP
POWERON 0) and sockets were created but no CLOCK IND was ever received
by the BTS, it wouldn't notice since the timerfd timeouts
(bts_shutdown("no clock")) are only checked after the first CLOCK IND is
sent by the TRX.
As a result, the BTS would be kept on forever saying everything is fine
but it would be sending no DL burst at all to the TRX (tested with a
modfied osmo-trx dropping clock indication).
With this patch, new APIs are added to indicate the scheduler_trx code
the timeframes where clock ind are expected (between RSP POWERON 0 and
RSP POWEROFF 0); if TRX sends clock indications out of that timeframe,
BTs lower layers will drop them (controlled by "powered" bool).
Hence, the scheduler_trx can now place a timeout (reusing same timerfd
because its new use is exclusive in time with its other previous use)
when it is told that CLOCK IND should start appearing, and if none
arrives in considerable time, then the BTS can be shut down to notify
the rest of the network.
Related: OS#4215
Change-Id: Iba5dbe867aff10e70ec73dbf1f7aeeecb15c0a4d
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
The ticket has been closed, BER and C/I measurements are now being
sent to OsmoPCU (see Ia58043bd2381a4d34d604522e02899ae64ee0d26).
Change-Id: I1909a70b82421802f32c1bc4f69a2e4210db5b2d
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
Currently we don't distinguish between CBCH on BCCH+SDCCH/4 and
CBCH on SDCCH/8, but in libosmogsm we have two independent
(non-standard) RSL channel number values for them. Maybe some day
we will, so let's extend the definition of L1SAP_IS_CHAN_CBCH.
Change-Id: I2f6d501a29edaf89dfb17d5d64f930cdb1943630
After getting rid of transceiver_available, this function is not used
anymore by any code, since its per-trx counterpart
l1if_provision_transceiver_trx() is the one used by other
code.
Change-Id: If5a988eb14658a78dd46234dccc052dc12fb872a
This variable meaning has been changing its exact meaning over time
until finally not being really clear which kind of state it holds.
Initially it seemed to be used to identfy whether CLOCK IND were being
received. However, over time both osmo-bts and osmo-trx have evolved and
were fixed so that clock indications are only sent by osmo-trx after
POWERON command is sent. As a result, this state can be checked simply by
looking at the "powered" phy_link variable, which is only set to true
once the TRX has confirmed the POWERON command, and hence it is sending
CLOCK IND.
On the other hand, at some point in time "available" started to be set to 1
in bts_model_phy_link_open(), which means available is nowadays almost
always 1 from startup until the end (only dropped during bts_shutdown(),
when we are already exiting the process anyway).
As a result, !available condition in scheduler_trx.c:trx_fn_timer_cb can
almost never happen, because available is set to true already. Only
possibility would be if an old process of osmo-trx (not set up by this
BTS process) is still sending CLOCK INDs, but in that case we for sure
don't want to configure the BTS based on that, but ignore them until
this BTS process has again configured the TRX. So that whole check can
be dropped. We are better checking for "powered" state, which is far
more accurate, and we better do that in trx_if.c before calling
trx_fn_timer_cb().
Other uses of "transceiver_available" being used can be changed to use
plink->state!= PHY_LINK_SHUTDOWN, since available was already being set
to 1 at the same time the plink->state was being set to
PHY_LINK_CONNECTING.
As a result of this state handling re-arrangement, OS#4215 is fixed
since trx_if_powered() is used instead of previous state condition to
check whether data frames should be sent.
Related: OS#4215
Change-Id: I35f4697bd33dbe8a4c76c9500b82c16589c701d4
It can be dropped since bts_shutdown() ends up calling immediatelly
bts_model_trx_close() which in turn calls bts_model_trx_close() which
sets enabled = false and calls l1if_provision_transceiver_trx() to
power off the TRX.
Related: OS#4215
Change-Id: If8b3d2379d7ae102e1c338f4558ac1352de761cc
Use of variables in each code is confusing and mixing configuration with
POWERON/POWEROFF state (which is at least per phy inst and not per TRX,
since those commands are only expected on the 1st phy inst).
* field "poweron" becomes "enabled", and is used as an indicator for
actions to take during TRX provisioning (hether to power it on and
configure it or to power it off).
* poweron/poweroff state becomes "powered", and it is shared by all trx
in same phy_link, and is updated only after confirmation by TRX.
* poweron_set becomes poweronoff_set (because it's used by both POWERON
and POWEROFF), and becomes shared by all trx in same phy_link, since
those CMDs are usually sent by first phy instance of the link (the first
trx).
Related: OS#4215
Change-Id: Icd0b482f1454236432e1952220bbec9d178b8607
check_transceiver_availability() is a loop over every trx, same to what
trx_set_bts() does, so let's call the per-trx version directly.
Change-Id: I8843c1438c6af700631aba7b7e72aae0bdb7ec3a
Currently there's bts-virtual specific fields in gsm_bts which is not used
by other models and are always allocated.
An alternative would be having a union with different structs inside,
one per model, but since we already have the bts_model abstraction, in this
case it makes more sense to use that abstraction instead of filling code
with preprocessor ifdefs to guard against non-defined types, etc.
Existing model specific data is moved there.
This new infra will be user further in forthcoming commits.
Related: OS#4215
Change-Id: Ib17a752cdbaa7d5eb8c5dfa0b197f80a4f38b38e
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
If a logical channel, on which an Access Burst has been received,
is not either of RACH, PDTCH or PTCCH, then this is a handover
Access Burst, which is always encoded as 8-bit and shall contain
the generic training sequence (TS0).
Access Bursts on a PDCH time-slot are not related to handover.
Change-Id: If7d6135d6c4d7f9bd71d9fab6f8adc3f8cfd10ea
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
Otherwise using "logging level set-all info" makes it impossible to see
anything in VTY due to tons of those two lines appearing.
Change-Id: I9c7500c1e56db0c4dcb474f93c882a9c7c004d55
If VTY cmd "osmotrx trxd-max-version 0" is used, max version 0 is used
(default starting one) and hence no need to send SETFORMAT (this is
useful in order to avoid sending SETFORMAT to old TRX implementations
not supporting the command). In this case, let's inform the user that
indeed osmo-bts won't send SETFORMAT because version 0 is assumed.
Change-Id: I7136ea6745c2275278bc400676b58fb4b10da966
libosmocodec has recently introduced a generic ECU abstraction layer
which supports (pluggable) Error Concealment Units for not only the
FR codec, but potentially any other codec, too.
Change-Id: I001005aae6de76d4e045b8dc572239f057bb150d
Depends: libosmocore I4d33c9c7c2d4c7462ff38a49c178b65accae1915
We call _sched_compose_tch_ind() after the switch statement, so
there is no need to send it from case 'GSM48_CMODE_SPEECH_AMR'.
Change-Id: I0488082494120157ac438d7763b52e3998f0eac7
When sending an AMR BFI, we need to call osmo_amr_rtp_enc() with
AMR_BAD as the last parameter. This function returns the length
of encoded payload, which needs to be at least 2 octets long.
If osmo_amr_rtp_enc() returns a length value lower than 2 octets
(what should not happen in general), we should neither call
memset() on it, nor call _sched_compose_tch_ind().
Change-Id: I70ce98c5697b9ce6fac7ab57a5d70f3201db29d9
Fixes: CID#178648, CID#178637, CID#178651
All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This enables the last of the three methods by passing any
ETWS Primary Notifications received over RSL via the PCU socket into
the PCU.
Change-Id: Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
Related: OS#4047, OS#4048
The ETWS (Earthquake and Tsunami Warning System) uses a so-called
ETWS Primary Notification which is sent
* to phones in dedicated mode (via DCCH from the BSC)
* to phones in idle mode (via P1 Rest Octets on PCH/CCCH)
This patch implements the second part of the functionality, i.e.
transmitting the related ETWS Primary Notification via PCH. As
3GPP doesn't specify how this is communicated over Abis, we use
a new, vendor-specific RSL message type.
Closes: OS#4047
Depends: libosmocore I89c24a81ada6627694a9632e87485a61cbd3e680
Depends: libosmocore I36fc2ffc22728887d1cb8768c7fcd9739a8ec0fc
Change-Id: I18c60cdb86b9c19e09f5ec06d66e9b91608880e6
Convert the cell identity to LE when sending it to the PCU via unix
socket, just like we do it with the location area code.
In the Osmocom stack, the CellID is configured in OsmoBSC, sent as BE
via RSL to OsmoBTS, then with a socket to OsmoPCU (where OsmoPCU expects
it to be LE in a LE system). OsmoBTS was always sending the CellID as
BE to OsmoPCU. In March 2018, a regression in OsmoPCU [1] caused an
endianness swap in the CellID on LE systems, resulting by chance in the
correct, LE encoded, CellID as it should have been sent from OsmoBSC
(for LE systems). This regression was fixed in March 2019 [2].
I've verified this fix with a TTCN3 test [3].
[1] I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
[2] I2f6cc930c5dbf8dac386b24b0756df2efe8199e4 (osmo-pcu)
[3] I6516808f4b9e9a2301f9ccc1e55ded14e7334c33 (osmo-ttcn3-hacks)
Related: OS#3854
Change-Id: I68faf4558f0686fb2a3db24077dceaae05bf0262
Some commits started using libosmocore APIs
osmo_gsm48_rest_octets_si3_encode() and lapdm_channel_init2(), which are
only available in latest libosmocore release 1.2.0. Let's update
configure.ac accordingly.
Fixes: 1e96e31c10
Fixes: 46d62b984a
Change-Id: If84c53d8192e8db98eb9439b898d83e94c5e5476
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Ia4d1a7914308d1481fe31fe0986265ead339e61e
Related: OS#4138
If gsm0503_tch_hr_decode() returns a negative error, we shouldn't
set the marker bit or pass the negative value as length value into
osmo_hr_check_sid().
Change-Id: If49ca6926c576a2b17507b6a95b6f3ca17877d66
Closes: CID#187645
If the BSC has instructed the BTS via RSL to not autonomously perform
MS power control, we are storing this in lchan->ms_power_ctrl.fixed.
However, osmo-bts-trx would simply ignore that flag in loops.c and
continue to compute new MS power values based on measurement results.
Change-Id: I628d1f4f1094c22248d372c11c2ecc504135b757
This command allows setting a maximum TRXD format version to negotiate
with TRX. osmo-bts-trx will hence end up using that version if supported
by TRX, or a lower one otherwise (or fail if TRX doesn't support any of
them).
Since now the maximum version can be 0, avoid going through SETFORMAT
negotiation in that case, since 0 is the default version. This way we
keep backward compatibility with TRX implementations that exit upon
receival of unknown commands (such as SC5 current one).
The VTY command is located in the "phy" node instead of the "phy
instance" node because instances of same phy are expected to use same
host with same implementation, so TRXD version to use should be the same
for both.
Related: OS#4006
Change-Id: I5eb1fdc002f9d7f4acf475356d8fc998dc8f6326
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
It was noticed with old Sony Ericsson phones (like W595 and K510i)
that the service provided by Osmocom network becomes unreliable
from time to time. The RSSI indicator on those phones shows that
the signal is lost, so neither CS nor PS services are working.
As it then turned out, System Information 3 broadcasted on the
Um interface is different than the one received from the BSC.
In particular, the content of SI3 Rest Octets IE is different.
Among with the 'GPRS Indicator', which is actually expected to
indicate whether the PCU is connected or not, SI3 Rest Octets
on the Um interface contain both 'Optional Power Offset' and
'Scheduling if and where' IEs, which are not present in the
original messages from the BSC.
Moreover, as soon as the PCU is connected, 'GPRS Indicator' IE
contains different 'GPRS RA Colour' value, and informs the MS
that System Information 13 is sent on extended BCCH, which
is not even supported by OsmoBTS!
The culprit is in rsl_rx_bcch_info(), where we pass a pointer
to osmo_gsm48_rest_octets_si3_decode(). Instead of passing a
pointer to the beginning of SI3 buffer, we actually need to
shift it to the beginning of the SI3 Rest Octets IE.
This change makes my Sony Ericsson phones happy ;)
Change-Id: Ia962cf21903ba674057cf52746996dd3254bc1c6
TSC (Training Sequence Code) is an optional parameter of the UL burst
indication. We need this information in order to decide whether an
Access Burst is 11-bit encoded or not (see OS#1854).
If this information is absent, we try to correlate the received synch.
sequence with the known ones (3GPP TS 05.02, section 5.2.7), and
fall-back to the default TS0 if it fails.
Since the new TRXD header version, the training sequence code is
indicated by the transceiver. Let's use it!
Change-Id: I1e654a2e49cb83c5f1e6249c0de688f99bc466b0
Related: OS#1854, OS#4006
C/I (Carrier-to-Interference ratio) is a value in cB (centiBels),
computed from the training sequence of each received burst,
by comparing the "ideal" training sequence with the actual one.
So far, there was no way to expose more measurements from OsmoTRX,
excluding both RSSI and ToA. Since the new version of TRXD header,
we can receive C/I indications and send the averaged (per 4 bursts)
values to OsmoPCU (as a part of PCUIF_DATA.ind).
Please note that we also need to attach C/I measurements
to the following L1SAP primitives:
- PRIM_PH_RACH.ind,
- PRIM_PH_DATA.ind,
- PRIM_TCH.ind,
but this will be done in the follow up changes.
Change-Id: Ia58043bd2381a4d34d604522e02899ae64ee0d26
Fixes: OS#1855
This change needs to be done in order avoid adding more and more
arguments to the UL logical channel handlers (such as rx_rach_fn).
Since we have different versions of the TRXD header, and may have
other burst-based PHYs in the future, some fields of an Uplink
burst indication have conditional presence.
Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0
Related: OS#4006, OS#1855
Both TRX2L1 (Uplink) and L12TRX (Downlink) messages should use
the same TRXD header format (and version) as was negotiated.
Change-Id: Idbc598ef7c1871ee8da830f3fbe0a5cc386f873d
Related: OS#4006
This change introduces a new command for TRXD header format
negotiation - SETFORMAT. If the transceiver does not support
the format negotiation, it would reject this command with
'RSP ERR 1'. If the requested version is not supported by
the transceiver, status code of the response message should
indicate a preferred (basically, the latest) version.
The format of SETFORMAT command is the following:
L1 -> TRX: CMD SETFORMAT VER_REQ
L1 <- TRX: RSP SETFORMAT VER_RSP VER_REQ
where:
- VER_REQ is the requested version (suggested by the L1),
- VER_RSP is either the applied version if matches VER_REQ,
or a preferred version if VER_REQ is not supported.
If the transceiver indicates VER_RSP different than VER_REQ,
OsmoBTS is supposed to reinitiate the version negotiation
using the suggested VER_RSP. For example:
L1 -> TRX: CMD SETFORMAT 2
L1 <- TRX: RSP SETFORMAT 1 2
L1 -> TRX: CMD SETFORMAT 1
L1 <- TRX: RSP SETFORMAT 1 1
If no suitable VER_RSP is found, or the VER_REQ is incorrect,
the status code in the response would be -1.
As soon as VER_RSP matches VER_REQ in the response, the process
of negotiation is complete. Changing the header version is
supposed to be done before POWERON.
Change-Id: I8afe950bd1ec2afaf3347ff848ee46e69c4f5011
Related: OS#4006
Since we may have different versions of the TRXD header, some new
fields of an Uplink burst indication have conditional presence.
Therefore we need a smart function to print them conditionally.
Change-Id: I68729dc98a1840d2aa9e091153d176a103d5a228
Related: OS#4006
This kind of debugging can be done using trx_sniff.py tool from
the TRX Toolkit [1]. Probably, this code was needed during the
initial development and testing.
[1] https://git.osmocom.org/osmocom-bb/tree/src/target/trx_toolkit
Change-Id: I50e0e5feeba4c3028f55209dd8e41e09ed5f70b1
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
This constant actually defines the maximum TRXD message length,
which includes the header and burst bits, not just burst.
Change-Id: I383125e1c4df039fc6b554833bc8736deacbe731
Otherwise t200_ms_dcch array values are left uninitialized with random
values, and passed later on to lapdm_channel_init2().
lapdm_channel_init2() will anyways fail during initial check on
get_n200_dcch() and return -EINVAL, so let's not print garbage or call a
function which will anyways simply return an error.
Catched due to some strange values seen in log (see D0 and D3):
osmo-bts/src/common/bts.c:421 (bts=0,trx=0,ts=0,ss=4) Setting T200 D0=1028672, D3=2, S0=520, S3=520 (all in ms)
Related: OS#4066
Change-Id: I3d7e1883811acf97aac97325739f2ff97fc2aa08
The timers are unfortunately completely broken, so let's go back to the
long default timeout values from 1ff0a2addd
See related issues OS#4066 and OS#4074
Change-Id: Ia44310245a348675dbbf3ffc3dc5b6d207fd62d3
This will generate the VTY/counter documentation for osmo-bts-virtual so
it will be missing documentation for device-specific commands/counters.
Change-Id: Idebb099b69924d6212db119f7a2f2861d4150d7e
Related: OS#1700
By using new libosmocore LAPDm API we can specify the GSM channel type
and hence enable the LAPDm code to use a per-channel-type specific N200
value.
At the same time, this new API also allows us to specify T200 values
when initializing the LAPDm channel, so we don't have to fiddle with
low-level lapdm data structures in what used to be oml_set_lchan_t200().
Change-Id: I0e814fbae13e0feddd148c47255dcc38cb718f48
Depends: libosmocore I90fdc4dd4720d4e02213197c894eb0a55a39158c
Closes: OS#4037
As per GSM TS 12.21, the LAPDm timers (T200) of the LAPDm instances
in the BTS are configured via OML from the BSC. While OsmoBSC
is sending them and OsmoBTS is parsing them, OsmoBTS stopped to
make use of them from commit 3ca59512d2
(January 2016) onwards.
The cause for this has been documented and discovered in May 2017
in https://osmocom.org/issues/2294 and it is quite obvious: LAPDm
timers are supposed to start when a given frame is actually transmitted
on the radio interface. PH-RTS.ind and PH-DATA.req are suppsed to be
used over a synchronous interface in some deeply embedded processor.
With OsmoBTS however, we have an asynchronous L1/L2 interface between
a DSP (osmo-bts-{sysmo,lc15,oc2g,octphy}) or OsmoTRX (osmo-bts-trx)
and we receive PH-RTS.ind quite some time ahead. So if we start T200
at that point, then it will start running way before it has been sent
or before the MS has had a chance to receive the message.
The "correct" way to handle this is to actually measure the difference
between frame numbers in PH-RTS.ind (uplink, advanced) and PH-DATA.ind
(downlink) or PH-TIME.ind, and then add that amount to the actual
timeout value. This ensures that the timers will time-out the
user-specified amount of time after the actual transmit.
Change-Id: If8babda9e3e5e219908911ddd9c0756b5ea0bca4
Closes: OS#2294
Closes: OS#3906
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
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Get rid of value-string array 'trx_chan_type_names', since each
logical channel has its name defined in 'trx_chan_desc'.
Get rid of field 'chan' of 'trx_lchan_desc' structure since it's
not used anywhere, and not actually needed because the position
of each lchan description is defined by its TRXC_* type.
Replace both 'pdch' and 'auto_active' fields with more generic
bitmask field called 'flags', and define the following flags:
- TRX_CHAN_FLAG_AUTO_ACTIVE,
- TRX_CHAN_FLAG_PDCH.
Use RSL channel mode #defines from libosmogsm instead of having
hard-coded numbers. This increases readability.
As a bonus, let's add a human readable description to each lchan
definition, so it can be printed in the VTY some day.
Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315
Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
I7ab4958801b3422973b67ff0452b90afa8a3f501
This way we unify format. We take the chance to add related information
to some log messages which were not printing that information (and was
confusing when using more than one phy instance).
Change-Id: I5b17a01638ade9a6c41da73e550d5947fa92f568
At the moment, bts_supports_cm() is only called on reception of
RSL Channel MODE MODIFY from the BSC. The idea is to check whether
the indicated RSL channel mode is supported by a BTS model.
RSL Channel MODE MODIFY message may indicate a channel in signalling
mode, i.e. GSM48_CMODE_SIGN, which has always been rejected so far.
Let's assume that signalling is always supported, as there is
no special BTS_FEAT_* definition to check that.
This change should make BTS_Tests.TC_rsl_modify_encr pass.
Change-Id: I8ea98a3eb9dc15a04f665596ee276883eb824b9a
According to 3GPP TS 48.058, section 8.4.1, the Handover Reference
element must be included if channel activation type is 'handover'.
Let's properly reject CHANnel ACTivation messages with missing
RSL_IE_HANDO_REF. Otherwise such requests are misinterpreted
as regular (non-handover) channel requests.
Found using TC_ho_rach() TTCN-3 test case.
Change-Id: I9c50e1dbeb54c5470560adcdfb2bdf5abbe47993
It looks like the status LED on the sysmobts2100 never worked correctly
since lc15bts-mgr expects osmo-bts-lc15 to create and manage
/var/run/osmo-bts/state, but there is nothing to do so in osmo-bts.
This patch copies the functions from oc2g to manage the state file in
lc15.
Change-Id: Iad32a22fc72e2aba45e4f1b9ae585f6e0b8757ed
Related: SYS#4493
osmo-bts-oc2g no longer modifies the status LED and instead leaves that
to the bts manager. The service file now also creates a directory in
/var/run needed for osmo-bts to communicate with oc2gbts-mgr. This
status file is used by oc2gbts-mgr to figure out when the bts is
operational.
Related: SYS#4493
Change-Id: Ifae634c6c2ecec7d32298c0f266f91f3e81308f5
osmo-bts cannot provide GPRS service while osmo-pcu is not connected.
The BSC has no knowledge of the PCU connection state. Prevent MSs
from trying to register for GPRS while the PCU is disconnected by
erasing the GPRS Indicator in SI3.
Change-Id: I1a6f5c636c0fe098ee31c280d4572a3f8122b44b
Depends: I690cf308311f910005a325d50f5d5d825678d2b2 (libosmocore.git)
Depends: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0 (libosmocore.git)
Depends: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330 (libosmocore.git)
Related: OS#3075
Remove the '~' from '|= flag', it is plain wrong.
This affects the correct parsing of DSP trace flags from the config
file only. The bug is not present in the interactive VTY command
at runtime.
Change-Id: I915971f49642967c969f5dd475e8faa960ef3960
The existing code ssumed that the RR SUSPEND REQ would be a
LAPDm/RSL unitdata request. I couldn't find any spec reference
that would support this. Rather, the message is sent via the normal
main dedicated channel, which is operated in ABM mode.
As the somewhat similar check for diverting measurement results
is in fact looking for UNITDATA, we have to untangle this slightly.
Change-Id: Ic75486f8edaefa9c07bd92515ba1832b1c482fa6
Related: OS#2249
Related: OS#4023
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
Rather than open-coding "Tx foobar..." in various functions (and
forgetting it in half of them), let's add a generic message into
oml_mo_send_msg().
Change-Id: I5dd4b1749e68fb7fc74cb2e3a778d2418f46b770
Some of our OML log lines were missing any context. Try making more
sense by printing any context information about the given managed
object, TRX, ... as we have it.
Change-Id: I60d1660c6d574f206d7b8cc10082b413142365dd
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
While we re-set the PCH load counters after every report, we never
actually re-set the RACH load counters. This meant that the
period/window for RACH load averaging would always grow, rather than
being reset every load indication period.
Related: OS#3750
Change-Id: Icd9150ba56d77d031c3cf496c5936c2de52b364c
The spec is quite clear: If the MS Power Parameters IE is present, then
the BTS shall perform autonomous MS power control. If it's absent,
then the MS power shall be fied. Let's adjust our code accordingly.
Change-Id: Ie43a1fc9cc658677c8c945ae82d03b7bffbe52d5
Related: OS#1622
In the following commit, we introduced transmitting the
RSL DELETE INDICATION on AGCH overflow:
commit 19da7fdea8
Author: Harald Welte <laforge@gnumonks.org>
Date: Sat Feb 24 04:32:29 2018 +0100
So let's sync the manual with the code.
Change-Id: I988778bdb83271355dc11b1a30a59e1a5dba5fb2
Related: OS#2990
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
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
The function get_p_max_out_mdBm() returns a value in 1/1000th of dBm,
"milli-dBm", while trx->nominal_power is only whole dBm. We were
missing the required divider of 1000 ever since Change-Id
Ieff75d5becaa80a2097b6e744c75c2d16259c9a4 was merged in February 2017.
The good news is that this really only affected the VTY output and
not any actual operational aspect of the system.
Change-Id: If92d0b15c48dafc63776b82c7ff5f3c2b3505f68
Closes: SYS#4570
We meanwhile support the SMSCB Channel Indicator IE and hence
can send SMSCB on both BASIC as well as EXTENDED CBCH
Change-Id: I63cc9c8c4c8c80440a61a0687e1f0cb97cc723b7
The logic for Extended CBCH are the same as for the Basic CBCH, we just
need to
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429
Closes: OS#3535
The BSC can not only send us each to-be-sent message separately, but
it can also configure a DEFAULT message, which is then to be sent
instead of the NULL message. Let's add support for this
Change-Id: I65a79215b54155d128c26d2ca11ff9ff3ed2cdba
Closes: OS#4013
There's no need to keep around a pointer to the next segment
in a SMSCB message. The way how the multiframe structure is
laid out (and how the tb number works), we can use the result
of a modulo-division on the frame number to determine which
of the segments/blocks inside a SMSCB message (page) we have
to transmit.
This also acts as a simplification in preparation of support
for the SMSCB DEFAULT type.
Change-Id: I48faa19fec4a0852e6112ca2faa98960c678d4c5
Related: OS#4013
The first block of "schedule" messages must be advertised with
a special sequence number coding, see Table 1 of 3GPP TS 44.012.
Change-Id: I473edf698eba7ff5008f2fd1ec1776f0aa013858
Closes: OS#4012
This off-by-one error in length verification caused all SACCH INFO IE
to be deemed invalid and hence any RSL CHAN ACT with that IE to be
rejected.
Change-Id: I6436caf5c2caefbf7c089d66e37d8d1babe1c24e
Related: OS#3750
The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
Related: OS#3750
Change-Id: I68dbb622aeaee657471664cdc0b69c2ac316d77e
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.
Related: OS#3750
Change-Id: I8155e0d37096bd7bf3563e4f7853171ca4b3aa58
Send an RSL Error Report in case of unknown/unsupported msg_type,
as describedi in section 7.3 of 3GPP TS 48.058.
Related: OS#3750
Change-Id: Ib2918007410e635b144a7535cec30b9f3378c755
This reverts commit ad7b8bee71.
Unfortunately the osmo-gsm-manuals-dev package isn't working properly
yet, therefore osmo-bts fails to build on nightly OBS now. My apologies
for not testing enough in my own OBS namespace, before merging. I'll do
that in the future. I'm reverting the patch now, so osmo-bts isn't
missing from the nightly repository until I've fixed the
osmo-gsm-manuals package.
Change-Id: I89c2b92c8ae6331d6fff95a378fb58d82059af13
Neither the bug has been reproduced, nor the bug reporter
did respond to request for configuration files.
Change-Id: Ibc9db360be1380abaa9eef4bdf6e9a6d251670da
Support for extended (11-bit) RACH has been implemented:
- in libosmocoding: I85a34a82d5cd39a594ee89d91a2338226066ab5d,
- and OsmoBTS: Ia28741603636406744e5e22ffff1fb7a9689955a.
We also have a TTCN-3 test case called TC_pcu_ext_rach_content,
see I8fe156aeac9de3dc1e71a4950821d4942ba9a253.
Change-Id: I091f4fbd52c29c7d56ca392b8a1b872609829d81
It seems osmo-bts-sysmo does support CBCH (Cell Broadcast), but
for some reason it doesn't report BTS_FEAT_CBCH to the BSC.
Change-Id: I42dd3f84c44c210d9255e17153372bf252f897a1
Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases,
it was discovered that there are possible collisions when trying
to decode a regular 8-bit Access Burst as an 11-bit one. This is
exactly what we are doing in rx_rach_fn():
- calling gsm0503_rach_ext_decode_ber() first,
- if it failed, falling-back to gsm0503_rach_decode_ber().
With default BSIC=63, the following 8-bit RA values are being
misinterpreted as 11-bit Access Bursts:
Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f
Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f
Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f
According to 3GPP TS 05.02, section 5.2.7, there are two alternative
synch. (training) sequences for Access Bursts: TS1 & TS2. By default,
TS0 synch. sequence is used, unless explicitly stated otherwise
(see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using one of the alternative training
sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
In other words, knowing the synch. sequence of a received Access
Burst would allow to decide whether it's extended (11-bit)
or a regular (8-bit) one. As a result, we would avoid possible
collisions and save some CPU power.
Unfortunately, due to the limitations of the current TRXD protocol,
there is no easy way to expose such information from the transceiver.
A proper solution would be to extend the TRX protocol, but for now,
let's do the synch. sequence detection in rx_rach_fn(). As soon as
the TRX protocol is extended with info about the synch. sequence,
this code would serve for the backwards-compatibility.
This change makes the both TC_rach_content and TC_rach_count happy,
as well as the new TC_pcu_ext_rach_content() test case aimed to
verify extended (11-bit) Access Burst decoding.
Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253
Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284
Related: OS#1854
According to 3GPP TS 52.021, sections 9.4.61-62, 'SW Configuration'
shall contain a list of 'SW Descriptions' related to the MO. In
other words, all 'NM_ATT_SW_DESCR' blobs shall be encapsulated
into a single NM_ATT_SW_CONFIG attribute.
For some reason, they were not encapsulated properly, so
OsmoBSC were unable to parse the 'SW Descriptions'.
However, unlike OsmoBSC the old OpenBSC does not expect this
encapsulation, thus after this change it will be unable to
parse the 'SW Descriptions'.
Change-Id: Id26104719891944f3e2151df362bd45bb057a9c5
Related: OS#3938
Instead of allocating two transitional buffers (one static,
another dynamic), we can use the existing message buffer.
Both handle_attrs_bts() and handle_attrs_trx() can put (append)
the reported attributes, and push (prepend) non-reported ones
as per 3GPP TS 52.021, 9.4.64 "Get Attribute Response Info".
Change-Id: I349447a43bce360f59e0c6b435906c65167d158b
Passing a pointer to a packed structure to tmsi_mi_to_uint() may
result in unaligned pointer value. Found with clang-8.
Change-Id: Ief69854973a098e6da7c05f4417dc11988edd777
Found using clang-8:
rsl.c:1646:7: warning: taking address of packed member 'packets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1646:28: warning: taking address of packed member 'octets_sent'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:7: warning: taking address of packed member 'packets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1647:28: warning: taking address of packed member 'octets_recv'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:7: warning: taking address of packed member 'packets_lost'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
rsl.c:1648:28: warning: taking address of packed member 'arrival_jitter'
of class or structure 'ipa_stats' may result in an
unaligned pointer value
Change-Id: Ifba33cfd8edeccc99a21c7d076db7119c29d4f40
Found using clang-8:
rsl.c:1607:93: warning: size argument in 'memcmp' call
is a comparison [-Wmemsize-comparison]
rsl.c:1607:7: note: did you mean to compare the result of 'memcmp' instead?
It looks more logical to compare the result of memcmp() against
zero instead of passing 'sizeof(sysinfo_buf_t) != 0' as size.
Change-Id: Ia8b95b017dbbfeb058d479fbaaf4861930569bb5
Both callers of cleanup_attr_msg(), i.e. handle_attrs_trx() and
handle_attrs_bts(), always pass out_offset >= 1, so the length
of the unsupported attributes counter is already accounted.
Otherwise, both callers would copy an additional garbage byte
from uninitialized memory. Discovered using Valgrind:
DOML DEBUG oml.c:539 OC=BTS(01) INST=(ff,ff,ff) Rx GET ATTR
DOML INFO oml.c:265 BTS Tx Get Attribute Response
==25467== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==25467== at 0x623E0BD: send (send.c:27)
==25467== by 0x5685846: __handle_ts1_write (ipaccess.c:358)
==25467== by 0x5683F8B: ipa_client_write (ipa.c:79)
==25467== by 0x5683F8B: ipa_client_fd_cb (ipa.c:140)
==25467== by 0x5F1DC23: osmo_fd_disp_fds (select.c:223)
==25467== by 0x5F1DC23: osmo_select_main (select.c:263)
==25467== by 0x42980B: bts_main (main.c:354)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Address 0x7d83895 is 23,669 bytes inside a block of size 102,528 alloc'd
==25467== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==25467== by 0x589A6B4: talloc_pool (in /usr/lib/x86_64-linux-gnu/libtalloc.so.2.1.5)
==25467== by 0x5F1E28B: msgb_talloc_ctx_init (msgb.c:316)
==25467== by 0x4293D0: bts_main (main.c:234)
==25467== by 0x6160F44: (below main) (libc-start.c:287)
==25467== Uninitialised value was created by a stack allocation
==25467== at 0x415FE5: oml_tx_attr_resp (oml.c:259)
==25467== by 0x415FE5: oml_rx_get_attr (oml.c:561)
==25467==
Change-Id: Ic7c2c4e54e9f99b60aaf70604044933978be945c
Related: OS#3938
It was noticed that the Get Attribute Response message always
indicates BTS(00,ff,ff) as the addressed OML entity, even if
e.g. Baseband Transceiver(00,00,ff) was requested by the BSC.
Despite neither OsmoBSC nor OpenBSC does complain about this,
such behaviour violates 3GPP TS 52.021. Let's fix this.
Change-Id: Icb1ee75d4bf680deb6365288d8c2053816a12217
Related: OS#3938
When using %lu and sizeof() for printing the compiler may throw a
warning. Lets prevent this by using %zu instead of %lu as conversion
specifier.
Change-Id: If5cb656537b1b73b9361a132801ab47ab7f8a709
The functions oc2gbts_par_get_uptime() and oc2gbts_par_set_uptime() try
to return with NULL, but both functions are declared as int. Lets return
-EINVAL instead.
Change-Id: I63b61be2940c59b221089d3d1501371b0116d89a
fsync() takes an integer file descriptor but we have a *FILE pointer
here. Lets use fileno() first to convert the integer file descriptor to
a FILE pointer.
Change-Id: I46ffd8c680ba0b445cbbd133d5ce92b79e3d8d87
the function bts_cbch_get() is used in l1_if.c. The function is
declared in cbch.h. Lets include this header file in order to be
complete.
Change-Id: I95d7e89eed969dd5b3ccff0eebcc6c568196a97d
In oml_send_msg() we optionally push the A-bis IPA magic string
("com.ipaccess") to a given message buffer as LV (Length Value),
including the terminating null byte ('\0').
There was a mix of both sizeof() and strlen() calls, and worse
luck, memcpy() has been used in a wrong way, skipping the '\0':
memcpy(dest, src, strlen(src));
In general, this is not critical because the headroom of a given
message buffer would most likely be zero-initialized, so the '\0'
is already there. However, msgb_push() gives no such guarantee.
Let's use the libosmocore's TLV API (in particular, lv_put()),
and stick to sizeof(), so the null byte will always be included.
Change-Id: I0c7f8776d0caec40f9ed992db541f43b732e47ae
Closes: OS#3022
As specified in 3GPP TS 03.60 Section 16.2.1 and 44.018 Section 3.4.15,
a Class B MS is sending a "RR GPRS SUSPEND REQ" via a DCCH to the BTS if
it wants to suspend GPRS services. The BSS is now responsible to
somehow forward this to the SGSN. As the Gs interface between BSC and
SGSN is both optional and doesn't have any provision to forward this
message, we have to send it over to the PCU so it can use regular BSSGP
signaling to inform the SGSN of the SUSPEND REQUEST.
This patch requires libosmocore Change-Id
I90113044460a6c511ced14f588876c4280d1cac7 for the related definition of
struct gsm48_gprs_susp_req.
Change-Id: I3c1af662c8f0d3d22da200638480f6ef05c3ed1f
Closes: OS#2249
At some locations in the code a signal to SS_FAIL is dispatched in order
to trigger the sending of an OML failure event report in oml.c. This is
a bit overcomplicated for the task. Lets use oml_tx_failure_event_rep()
to send the failure event reports and lets remove the signal handler for
SS_FAIL.
Change-Id: Ie4fce1273a19cc14f37ff6fc7582b2945c7e7c47
Related: OS#3843
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
SIGUSR1/2 and SIGABRT should not trigger a failure event report on
OML since we only use it to get an intermediate talloc report. (In
case of SIGUSR1/2 without leaving the process.)
Change-Id: I99e637496afff2530425b89c6e9befc76db24906
The function gsmnet_from_vty() is used in oc2gbts_vty.c, but it is not
declared in vty.h. Lets add the declaration to vty.h, so that
gsmnet_from_vty() can be used properly by other modules.
Change-Id: I8cf63c6fabdb1f2dc67ca8193704ce4d1d4882d9
Nowadays only known users (OE images) use systemd and don't require this
kind of screen setup.
In any case, this kind of file belongs to scpeific setup and are not
needed here.
Change-Id: I65b0eee44336e4627620443861092b8988f2e01d
This fixes the below compile error:
rsl.c:900:43: error: ‘gsm0808_chosen_enc_alg_names’ undeclared (first use in this function)
Change-Id: I4aed0242737602e61b785862e3c37c963bf48455
The log level of the messages that notify calibration file loading
problems is NOTICE, but since it is a severe problem when calibration
can not be loaded lets change it to FATAL
Change-Id: I32aed25ca7925f1c776f00b37f404a58a85ddbc7
Related: OS#3823
When the TX/RX calibration files can not be loaded a failure event
report should be sent to the BSC. Lets send a failure event report when
calbration data is either bad or can not be loaded (see also remvoed TODOs).
Change-Id: I3318470518b34807a443f7cb78c7091b4a3d4481
Related OS#3823
On links with high latency it can happen that RADIO CARRIER OPSTART is
carried out to early, even before SET BTS ATTRIBUTES is carried out.
This means that important parameters for the initalization are not yet
set and the TRX initalization failed. Lets delay the TRX initalization a
bit in order to be sure that all BTS attributes are set before the
initalization is carried out.
Change-Id: Id3bdc88d28417e422d2c0c33b03be06f1a4706c2
Related: OS#3782
The function vty_install_default() is deprecated and throws a compiler
warning that suggests to remove it, so lets remove it.
Change-Id: I1a4afb6e352bed9a5af794b39b984a7ddef36e08
The static function oml_tx_failure_event_rep() is a lot easier to use
than the currently implemented signal scheme. Lets make it public so
that we can quickly generate failure event reports.
Change-Id: I9c4601840a06119f35cfe4da453fff3b293fe615
Related: OS#3823
According to the OC-2G product specifiacation, the maximum output power
is 25 dBm. This should be reflected in the code, there's no point in
claiming to be able to trnasmit 40 dBm - which just creates confusion on
all levels (such as the logs, where Tx power is claimed to be ramped up
to 40 dBm right now).
Closes: OS#3823
Change-Id: Ia6b3476ab2f9279f8905b8c7cfd07ef7b0a939ed
For some strange historical reason, the baseband transceiver MO was
brought up in state "UNLOCKED".
The object should come up in "locked" state until it's explicitly
unlocked by the BSC.
See Section 6.8.2 of TS 12.21: "If there is yet no administrative state
value explicitly set by the BSC (e.g., at an initialization time), the
object shall be presumed to be administratively locked by default"
Change-Id: Id505594b9f224567566caac84dae2e2ae4477fae
Closes: OS#3790
For the TS 12.21 standard OML attributes, we store a copy of the
most-recently set value for each attribute in "mo->nm_attr". This
somehow was missed when adding support for the IPA specific MOs like
those relevant for GPRS.
Change-Id: I75ebda46da9c1fcecc484311bf3833f31c536ee1
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Similar to commit fixing same issue in lc15 in 080302f8.
Change-Id: Ie393a21bc3a725520343c70941cb4f591b313420
it's used in oc2g/main.c and it needs to be in a header file.
Similar as previously done for lc15 in 19795c5a.
Change-Id: Ic6826d8c8ff5c648158493454a80704bb956b51d
When the ph-data indications for the PDTCH are passed up to l1sap,
then a forumla is used to calculate the frame number of the beginning of
the block that is just passed up. This is not necessary since the start
frame number of the block is stored in *first_fn when the block arrives.
We should use this frame number instead. (For the measurement indication
it is already done this way).
Change-Id: I6c01987be78203acfa689c6decb2c806f8fff3d6
Related: OS#2977
Attempt to decode incoming RACH burst as 11-bit first
and fallback to 8-bit if unsuccessful.
Change-Id: Ia28741603636406744e5e22ffff1fb7a9689955a
Related: OS#1854
OsmoBSC used to have a bug in encoding the "GET ATTRIBUTES" OML message,
resulting in the actual message length being three bytes longer than the
encoded length value.
As in Ib98f0d7c2cff9172714ed18667c02564540d65d7 we have introduced
proper consistency checks on length values, all "GET ATTRIBUTES" from
OsmoBSC version suntil today will fail. This patch introduces a
work-around to remain compatible with old OsmoBSC while still keeping
the consistency checks for all other messages.
Change-Id: Ifa24e9e2c71feb2c597557807d675438c2825b2d
Related: OS#3799
For OML, what matters is the length indicated in the OML message header.
If we don't have sufficient bytes, reject the message and send a failure
event report.
If we have more bytes, truncate the message at the number of bytes
indicated in the OML length header.
Change-Id: Ib98f0d7c2cff9172714ed18667c02564540d65d7
TS 12.21 describes segmenting of OML messages using placement
fist/middle/last and the "sequence' number of the OML header. We don't
implement this and hence must ignore or reject any related messages.
Before this patch however, we simply treated such segments as if they
were a complete OML message. Let's fix that.
Change-Id: Idd42cf4edc1bf9ab366853bd9b0f7afd9c060910
Closes: OS#3795
Simply use a "mo" variable on the stack rather than having duplicate
but otherwise identical calls to oml_tx_failure_event_rep()
Change-Id: Ibe6c79e95405b13d041047549d2ffa39aa355eb2
When we send an OML failure event report using
oml_tx_failure_event_rep(), the function itself will not only send
the report to the BSC but also log it. So there's no need to both
have an explicit LOGP() and a call to oml_tx_failure_event_rep().
Change-Id: Ib3fd06b3266d896aebeed4ebe42ac71ff173bb5c
In Change-Id Ic163bcfb6361a8ebd39e0bc0f238ef51e2cb214e we introduced
several additional calls to oml_tx_failure_event_rep() during OML
messaeg processing. However, for some reason, we *overwrite* the
bts_nt/trx_nr/ts_nr of the TRX MO. This is clearly wrong. The
"address" of a managed object doesn't change at runtime!
Change-Id: Idfb80ccd6dd485d52dc006867fae3dde3fb005f3
When osmo-bts connects to the BSC, it sends a ton of "State Change Event
Report" messages indicating the Operational State (NULL), Availability
status (power off) and [as an osmocom extension] also the Administrative
State. However, the value of the administrative state is "0", which is
not defined in TS 12.21 Section 9.4.4
Change-Id: I03f8a4b08b266cd40036076c76f9dc7e8bf08da2
Closes: OS#3785
As per 3GPP TS 12.21 Section 8.2 "ACK messages shall return all the
attributes in the original message". OsmoBTS fails to do so but simply
sends no attributes at all in the ACK.
TS 12.21 is a bit vague whether or not the attributes shall also be
achoed in the NACK. Let's do it and append the CAUSE in this case.
Closes: OS#3788
Change-Id: Ifb305fe75f8305bb04872f26492b8b1bb8c27f49
Commit acefd0586e introduced the "toa256"
resolution change.
Before the change, _sched_compose_ph_data_ind() used quarter-bits as
units, so multiplying the old "toa" value by four made sense.
However, after said change, the value is in 1/256th of bits, and hence
we need to report the toa256 value without any multiply-by-four.
Change-Id: I9f980236ea1cd635cb229290e187747cc8c86d8d
Related: OS#2977
A comma is needed to separate a command definition from its
description, not the parts of description. Let's fix this.
Before this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no PHY Instance number
OsmoBTS(phy)# no ?
instance
osmotrx OsmoTRX Transceiver configuration
After this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no Negate a command or set its defaults
OsmoBTS(phy)# no ?
instance Select a PHY instance to remove
osmotrx OsmoTRX Transceiver configuration
Change-Id: If10d85abc6506118ba08c37e8101f423d6f838ea
Use the 'else' construct where applicable to avoid too many return paths
from functions
Change-Id: I819f0c80e90855e8b3252795c837f8e3053b6e87
Related: OS#1622, OS#1851
The loops.c code dates back to ancient times when we printed the TRX
number and the raw channel number to identify a logical channel. We
meanwhile have gsm_lchan_name() and should use it to log messages
related to this lchan in a common format.
This commit introduces the LOGPLCHAN() helper macro [similar to
osmo-bsc], and uses it from loops.c.
As a result, some functions don't need a chan_nr argument anymore,
while some need to add a new lchan argument.
Change-Id: I6976dd7444c26b1f52741bc367b0311ebbef1718
Related: OS#1622, OS#1851
The concept of a return value only makes sense if there's actually ever
something non-constant to return, and if the caller actually processes
that return value. If we always "return 0" and ignore it on the caller
side, functions should be of "void" type.
Change-Id: I3575a2cef75f3fd4c3f95eddb40719d28a055b54
Related: OS#1622, OS#1851
The loops.c code is not very easily understood, so let's add some
comments to it.
As can be seen, there are functions of integer type which always return
0, and whose callers don't check for the return value. This will be
adressed in subsequent patches.
Change-Id: Iafea07eb751ed85d29b214576bb0d31ea919cd72
Related: OS#1622, OS#1851
Fix recent commit which broke TTCN3 BTS_tests
TC_dyn_ipa_pdch_tchf_act_pdch_act_nack.
Prior to the breaking commit, logic was still not good, because
1- It didn't return after sending the NACK
2- It sent a NACK in all cases, while for PDCH DEACT we want to force
its deactivation. Going through tests it can be seen that indeed it
can deactivate it in that case:
rsl.c:2206 (bts=0,trx=0,ts=3,pchan=TCH/F_PDCH as PDCH) Request to PDCH DEACT, but lchan is still in state ACTIVE
...
rsl.c:2103 (bts=0,trx=0,ts=3,ss=0) Tx PDCH DEACT ACK
Fixes: 133a3d96dc ("rsl: Avoid sending ipa PDCH DEACT NACK followed by ACK")
Change-Id: I6d6d12aec10c801fe55012ca6e58d0bc8755b15d
This allows running sysmobts-mgr on systems with old gpsd releases
(which may have other software depending on such old release).
GPSD_API_MAJOR_VERSION define was first added in gpsd 2.39, before that
it didn't exist (but this code is known to work against 2.38).
GPSD_API_MAJOR_VERSION == 5 was set in version 2.96.
Related gpsd commits:
3771dba081bd1175adab6096d7b6270d3822aaa1
e69bcb6b01af6b25c6a525fb1961b92ac04f5213
Related: SYS#4290
Change-Id: If3c35021a020a61d5fa3cde5eebcd09908db822b
API prior to that version allocates the pointer internally. Let's change
current code to always use a pointer and in current supported code (gpsd
>= 2.96) point it to a user-allocated struct.
Follow-up patch will introduce necessary ifdefs to support older gpsd.
Change-Id: Iaeb5ac527cc3e58168027021d0f60afa93d1fb6f
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of jenkins_bts_model.sh. Change the top description line to look
like all the other contrib/jenkins.sh files (from other repositories),
so it is clear that this is the entry point of Jenkins (and not the
other contrib/jenkins_*.sh scripts).
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: If51194cc595bd8cf1081b35ab0e1a5ddcd448860
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: I332c94502cce0f3f11fe3f4d9f6c9918ff0c0263
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: I728ebb56ade6dda079a0744c4e592284e1bea4f6
Surrounding with '@' didn't seem to yield the intended result, the
charactars appeared in the compiled document.
Change-Id: I66e7949fa4a6c2164bf9572a2beaf8ace169fa1c
This chapter defines the protocol used between osmo-trx and
osmo-bts-trx.
Most of the text comes originally from osmo-trx.git/README, as it's the
only known documentation of the protocol other than the code itself.
Change-Id: I56c418eef0f826ae1aadbed5b151fbed241c7885
The initial goal was to make sure we don't have overall FORCE rules causing
unnecessary rebuilds -- annoying while writing documentation. As I looked
through possible dependencies, I finally understood what's going on here.
Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In
each, describe in a top comment how to use it, and also unify how they are
used:
- Rename Makefile.inc to Makefile.docbook.inc and refactor
- Add Makefile.vty-reference.inc
- Add Makefile.common.inc
Make sure that we accurately pick up all dependencies.
Drop use of the macro called 'command', that silenced the actual command lines
invoked and replaced them with short strings: it obscures what is actually
going on and makes the Makefiles hard to read and understand.
Each manual's makefile is greatly reduced to few definitions and a Makefile
include, e.g. one for asciidoc, one for VTY reference.
Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link
from OsmoNITB. It applies only to OsmoBSC and OsmoNITB.
Add a script that combines a VTY reference file with *all* additions files
found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc.
Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0
All parts referencing GFDL can be easily disabled by removing the
'gfdl-enabled' attribute from the document.
Change-Id: I2489726ad2e90301bceadfada926e31ae0f85986
Add high level description on and a config example for dynamic timeslots in a
new chapter featured in the OsmoBSC and OsmoNITB manuals.
From the OsmoBTS manual's chapter on dynamic timeslots, add references to the
above.
Change-Id: I44ff1e4c2340c65ff23e85408fc6d6a45ea9e046
Add it to Makefile with proper docinfo so it's build automatically
alongside with other documentation.
Change-Id: Iacd7fadc003ce0f9ffd20aa5b36c7d598b04f882
Add two new chapters contributed by Nutaq:
* TCH/AFS Downlink: Inhibiting a SID_FIRST frame
* TCH/AFS Downlink: FACCH/F During DTX Operation
Change-Id: Ic39d035f9d17bd0634c2df78ae3359a5eb7dfd46
Below commit accidentally removed osmobts-abis.pdf from the Makefile entirely.
The pdf was re-added, but the dependencies are still missing, so that
osmobts-abis.pdf is not rebuilt when abis/* is newer. Fix that.
Culprit: 05f5adbe837f2cbfb9301cdb8c9b454ca0bfc825
"OsmoBTS: add vty reference documentation"
Half-fix: 707827196f0734eefa74ce0c35c2ab2fe754cc4c
"OsmoBTS: generate osmobts-abis.pdf again"
Change-Id: Id2ee8177cfb8eb58409d164bdd994ef5e86ad82b
Split both of the lengthy mscgen generated ladder diagrams in two so that the
diagrams are split over two pages and don't bleed into the page footer.
Change-Id: If90250123a85cd275f07c69ee64c6e10a7269f06
Unfortunately a glob like osmo-x__*.{svg,png} doesn't work, so have the
suffixes in separate globs.
Add dashes to indicate that failure should be ignored.
Change-Id: I6bc4d9ea72b43a573acbc860c23397f748de2c7b
There were two separate sections saying basically the same. Move the
entire 'Dynamic Channel Combinations' section further above and combine
with the 'IPA Style PDCH Management' section to avoid repetition.
Change-Id: Ic370ba34de5cb14f0194ff8c8661e45d7ca98e2b
Generate *.check files from asciidoc output and grep for WARNINGs.
Add *.check files to gitignore and to 'make clean'.
Change-Id: Ibccc83a3415930a528f2e8e4e4dda3b81c6d0b64
The section 'Osmocom Style Dynamic Channels' ended in mid-sentence without
naming any of the hard facts. Complete that.
Add section links.
Change-Id: Ib92895fe1bb89fb1b14dc8fcbd88b98bbb6edeee
Consistently name the PDCH act methid 'IPA style', name ip.access only once
in the 'IPA Style Dynamic Channels' section.
Consistently write 'IPA style' without hyphen (not 'IPA-style').
Capitalize section headers ('IPA Style').
Change-Id: I91112c2d8af9424ebe7e1972fd4ef9c77d24a7b4
In effect, this fixes the dangling references from the table of RSL messages
with additions/limitations to the Chan Act message description.
Change-Id: Ic6f83f016ce9ec90af7eb0af1b1f71a10263915d
Including the required changes of the Makefile which is now simliar
as the other projects Makefile's.
Based on: OsmoBTS 0.3.0.283-f869
Change-Id: Id7362ce1c584b1926330b93770d68453e091c71c
The act ack for switchover to PDCH is now issued immediately, after
commit 'dyn TS: if PCU is not connected, allow operation as TCH'.
Adjust the chart accordingly.
The manuals existed in different form for several years in an internal
sysmocom repository. However, since they had just recently been
converted from docboox-xml to asciidoc and all files have been
re-shuffled for enabling the public release, there's not much point in
keeping the history with git-filter-branch.
This commit doesn't change internal logic of any model, only the API to
be able to return result of connect TS asyncrhonously since some models
(like osmo-bts-trx) require some time to process the result. This way
PDCH ACT/DEACT (N)ACK can be sent once the result of this long process
is known. For instance, nowadays in osmo-bts-trx we PDCH (DE)ACT ACK
before getting the result from SETSLOT on the TRX iface.
With this new API, bts_model_ts_connect doesn't return any value
synchronously. Instead, it is expected to always end up calling
cb_ts_connected with the return code from the TS activation process. 0
is considered a successs, while any other value is considered an error.
Change-Id: Ie073a4397dd2f1a691968d12b15b8b42f1e1b0cf
Later on it's expected to add more rsp parsing, so let's return here and
not depend on generic return further down.
Change-Id: I8ddee46374ab329c47dc68e720e236f13d393f66
It was spotted during osmo-gsm-tester test
dynts:trx-sysmocell5000+mod-bts0-dynts67-ipa+cfg-codec-fr-any that
osmo-bts-trx was answering to PDCH DEACT from BSC first with a NACK
followed immediatelly after by an ACK. That happens after the test does
a GPRS pdp ctx act successfuly and then deactivates the ctx and the 2 MS
try to place a call between them (and thus channels need to be moved to
TCH/F).
Most probably the if condition where the lines for this commit are
modified need to be fine-grained. Patch before this one should help to
understand the steates/situation in this scenario, and then a follow-up
patch can be created to improve the logic.
Change-Id: I91c65da6b6b7094f32187d3b083153a87c3219fd
TRX0 is allocated in a different place than other TRX.
Commit that introduced the bug added an initialization step
(bts_trx_init) applied in VTY cmd "trx <0-254>", where TRX are allocated
since same commit, but doesn't initialize TRX0 for reasons explained in
first paragraph.
As a result, some parameters were not applied to TRX0, like
power ramping increment step, which prevented MS from finding the network in
osmo-gsm-tester tests.
Fixes: eebb6a4216 ("bts: Allocate TRX for BTS dynamically, deprecate -t")
Change-Id: I5afd66548634ff53e2af24dc7055d408ca8ca4e3
If POWERON fails, announce to BSC that the TRX is not available, and
announce it as available as soon as POWERON success is received.
Related: OS#3692
Change-Id: Iaa8f497381038fd7f9f779a8211ebc6453837c65
The setup is only needed once, so no need to set it every time we want
to schedule it.
Furthermore, it will ease new code introduced in follow-up patches,
which will schedule this timer under some circumstances without need to
send a message at the same time (because re-try of a cmd after a delay
is wanted).
This commit adds an alloc function and an init function to keep
different parts of the code decoupled and avoid exposing more
implementation details between them (like exposing the trx_if timer).
Change-Id: I3b6461d0130d25284e673c5efce0b3832c48bbb5
The return value of osmo_wqueue_enqueue() isn't checked.
This can result in a memory leak if the message cannot
be enqueued. Log an error an free the message upon failure,
as done elsewhere.
Change-Id: I5671ca364f31d98f2b28d028e7bf1797386de2ec
Related: CID#57662
No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
If chan_state->ongoing_facch is set, this code's logic
suggests that both msg_facch and msg_tch could be NULL.
Don't dereference msg_tch unconditionally.
Change-Id: Icf5584396c5b925d55ca9380dd4f869ae5d72da3
Related: CID#172047
This change modifies the logic of TDMA frame loss tracking. To
be more precise, the tracking logic was moved from per timeslot
level to per logical channel level, what makes OsmoBTS more
accurate in its measurements.
But before getting into details, it's important to clarify some
things about the Uplink burst processing in transceiver (OsmoTRX).
If an Uplink burst is detected, OsmoTRX demodulates it and sends
to OsmoBTS. If nothing is detected on a particular timeslot,
OsmoTRX will do nothing. In other words, it will not
notify OsmoBTS about this.
Meanwhile, there are usually a few logical channels mapped to a
single TDMA timeslot. Let's use SDCCH8 channel configuration as
an example (simplified layout):
/* SDCCH/8 (ss=0), subscriber A (active) */
{ TRXC_SDCCH8_0, bid=0 },
{ TRXC_SDCCH8_0, bid=1 },
{ TRXC_SDCCH8_0, bid=2 },
{ TRXC_SDCCH8_0, bid=3 }, // <-- last_fn=X
/* SDCCH/8 (ss=1), subscriber B (inactive) */
{ TRXC_SDCCH8_1, bid=0 },
{ TRXC_SDCCH8_1, bid=1 },
{ TRXC_SDCCH8_1, bid=2 },
{ TRXC_SDCCH8_1, bid=3 },
/* SDCCH/8 (ss=2), subscriber C (active) */
{ TRXC_SDCCH8_2, bid=0 }, // <-- current_fn=X+5
{ TRXC_SDCCH8_2, bid=1 },
{ TRXC_SDCCH8_2, bid=2 },
{ TRXC_SDCCH8_2, bid=3 },
SDCCH8 has 8 sub-slots, so up to 8 subscribers can use a single
timeslot. Let's imagine there are three subscribers: A, B, and C.
Both A and C are active subscribers, i.e. they are continuously
transmitting UL bursts, while B is not using ss=1 anymore.
The original way of TDMA frame loss tracking was the following:
- when an UL burst is received, store it's frame number in
the timeslot state structure (last_fn);
- when the next UL burst is received on same timeslot, compute
how many frames elapsed since the last_fn;
- if elapsed = (current_fn - last_fn) is lower than 10, then
iterate from (last_fn + 1) until the current_fn and send
dummy zero-filled bursts to the higher layers;
- otherwise (elapsed > 10), process the current burst,
and do nothing :/
According to our example, subscriber A is sending 4 bursts, then
nobody is sending anything, and then subscriber C is sending
4 bursts. So, there is a 4 frames long gap between the both
transmissions, which is being substituted by dummy bursts. But,
as the logical channel on ss=1 is not active, they are dropped.
This is not that scary, but the current algorithm produces lots
of false-positives, and moreover is not able to track real frame
drops in longer periods (i.e. >10). So, tracking the frame loss
per individual logical channels makes much more sense.
Let's finally drop this hackish 'while (42) { ... }', and track
the amount of lost / received TDMA frames (bursts) individually
per logical channels. Let's also use the multiframe period as
the loss detection period, instead of hardcoded 10. And finally,
let's print more informative debug messages.
Also, it makes sense to use the amount of lost / received bursts
during the calculation of the measurement reports, instead of
sending dummy bursts, but let's do this separately.
Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: OS#3428
Before this patch it was being coded as SDCCH4 TS0 SS 0, and as a
result the state LCHAN_REL_ACT_OML applied in opstart_compl in abused
SDCCH4 TS0 SS 4 was not being checked when deciding whether to send a
Chan Act ACK in rsl_tx_chan_act_acknack.
Fixes: OS#3513
Change-Id: I1641960c9ffbb3ed0de74ab5b53e24e5b4ff3397
Previous implementation made no sense, since chan_nr is never read
before being set below from lchan_nr.
Furthemore, if lcahn_nr=CCH_LCHAN=4, then:
cbits = 0x4 + lchan_nr = 0x8 = b1000 which then becomes SDCCH8 according
to GSM 08.58 9.3.1, so it's totally wrong:
SDCCH/8 + ACCH 0 1 T T T
Change-Id: Id1dee716991e6faa406f02c029e998af5780162a
In the most cases a PDCH time-slot has only one logical channel
allocated. In case of both osmo-bts-trx and osmo-bts-virtual,
there are two kinds of logical channels: PDTCH and PTCCH,
but since they share the same chan_nr value, deactivating
one of them would trigger deactivation of another one.
Let's explicitly address the first logical channel in array.
Change-Id: I8edcb46e887c4db63a425eba89cec4374165763e
Closes: OS#3023
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
* we have to use modulo 51, not 50
* the check for FACCH/SCH has to be applied to to the fn % 51 result
Change-Id: I540a7eeef3ea3ed7347f0f1b5a5a6fe7ce0ec8bb
The '--with-osmo-pcu' flag dates back to a time where the
'pcu_interface' header was not copied in both repositories
and you had to point one to the other.
Change-Id: I79e494484cb099cc9ca8c27c38b785c5ea8c3bc6
Closes OS#3514
The command implementation says "deprecated", so then the vty command attribute
should also be DEPRECATED. It will be hidden from online docs and vty
reference.
Change-Id: I23e620f1b947e129989fe69c6380c91b9abf7021
We used to permit multiple spaces to enter a new node in the config,
but modern osmo* code writes config files well-formed where every node
equals exactly one indent level.
Change-Id: I3da56b34e87503c46e6bf3c7505b83ec5e6aaa20
Fix compilation warning. At runtime it's not a big issue because the
"list" field is the first field of the led_list (struct
lc15bts_led_timer_list) variable. Hence, the address passed is the same.
Change-Id: Ib8bf07990800d74bfb3ad7a55eccfc65e40cd480
During the investigation of OS#3559, it was discovered that the
log message, which warns that an RSL message was dropped due to
inactive logical channel, has incorrect log level - LOGL_INFO.
This is not informative kind of message, so let's increase the
log level, and additionally let's print the hexdump of message
and it's length.
Change-Id: I26eac5e4466c493ffe08dbb89de20f5e1c2bb85d
As the CBCH replaces SDCCH sub-slot-2 in downlink, we should mark
the uplink as IDLE, just as the associated SACCH in uplink and downlink.
Also, there are no burst_numbers in IDLE slots.
Change-Id: Ib8565d1d0080bfce5d2aec77609709a445a2171c
Unfortunately the code in Icc15603079a1709ec094f400a9bcf0008211890f
was incomplete as it missed a few spots where the CBCH-enabled channel
types weren't yet covered.
Using this patch I can both still perform RACH / Location Update as
well as actually receive SMSCB messages on an attached phone (Galaxy S5).
Change-Id: I311b141668549ef37054cbe74be66bf17ac1d7e6
Closes: OS#1617
Closes: OS#3559
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
This fixes a bug introduced in "CBCH: Move processing via L1SAP"
commit 02d99db08b
Author: Harald Welte <laforge@gnumonks.org>
Date: Fri Aug 24 23:37:45 2018 +0200
where the full channel number 0xc8 was used instead of the
(right-shifted) C-bits only.
Change-Id: I0fd8d7762e9cc3319a534f261e8857a1aa2220e0
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
Also print a newline at the end of print_hwversion().
In the process of rewrite, fix several warnings in the few lines of this functions:
osmo-bts/src/osmo-bts-litecell15/main.c: In function ‘print_hwversion’:
osmo-bts/src/osmo-bts-litecell15/main.c:162:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:12: warning: passing argument 1 to restrict-qualified parameter aliases with argument 4 [-Wrestrict]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~
model_name, model);
~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:47: warning: ‘ Rev ’ directive output may be truncated writing 5 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:162:3: note: ‘snprintf’ output between 7 and 70 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s Rev %c",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, (char)rev);
~~~~~~~~~~~~~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:47: warning: ‘ (’ directive output may be truncated writing 2 bytes into a region of size between 1 and 64 [-Wformat-truncation=]
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~
osmo-bts/src/osmo-bts-litecell15/main.c:168:44: note: using the range [0, 4294967295] for directive argument
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~
osmo-bts/src/osmo-bts-litecell15/main.c:168:3: note: ‘snprintf’ output between 9 and 75 bytes into a destination of size 64
snprintf(model_name, sizeof(model_name), "%s (%05X)",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
model_name, model);
~~~~~~~~~~~~~~~~~~
Change-Id: I079b056a04fe77d2f7f361ff5899232cb70b5a93
Fixes following compilation warning:
osmo-bts/src/osmo-bts-litecell15/lc15bts_vty.c:244:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: Id9b144d068d53393e1c1887aad285ae757156ec6
There is a big difference between both L1 and L2 frames. In the
first case, a TDMA frame is assumed, while a L2 frame is the
result of decoding a few bursts (e.g. 4 for xCCH) arrived
on a few TDMA frames.
Anyway, the purpose of l1if_process_meas_res() is to handle
measurements, not frames.
Change-Id: Ic4362c2869e658c2f42664b4009a30e777f8048c
The unit test that tests lchan_meas_process_measurement() only inputs
test data to lchan_meas_process_measurement() but it is not checked if
the interval end could be detected or not.
- Add a return code to lchan_meas_process_measurement()
- Ensure that the return code is checked in the unit-test
Change-Id: I9e00ce683e8c44528804f65181dbfed9e85e3aed
Related: OS#2975
The function is_meas_overdue() was introduced to allow
lchan_meas_process_measurement() to detect when the end of a measurement
interval has been missed. Interval ends may be missed when the SACCH
block of the related measurement interval gets lost. This is due to the
fact that the SACCH block is used as a trigger to start the measurement
result computation.
The idea behind is_meas_overdue() was to check the frame number of the
current measurement against the frame number of the previous measurement
in order to see if there was a measurement for SACCH in between or not.
Unfortunately SACCH and TCH Voice data is not necessarly processed in
order by each phy. Depending on the phy there may be a jitter between
the timing of SACCH and TCH Voice. Depending on the phy this jitter may
be enough to mess up the timing so that we see a SACCH block earlier
than expected. So we can not use the current frame number of TCH Voice
measurements to check for missed SACCH blocks.
Change-Id: Idfdbf64c1f965f35c12559b3995e2b746c74ee9e
Related: OS#3502
Related: OS#2975
Change cfg file names so they don't overlap when installing different
osmo-bts versions, and make systemd services look for correct new name.
Remove unneeded duplicated EXTRA_DIST files from root dir Makefile.am
Change-Id: I75fdd06cc52ce50628efb1f9b007d2e3926db27d
Convert the if-cascade to a switch().
For any unexpected pchan kind, reject the chan mode immediately instead of
going on to invoke gsm_bts_has_feature on feature = _NUM_BTS_FEAT, and log the
error.
Tweaked-by: neels
Change-Id: Ieaded9258554b15fcc4b7f05d5a8847175b7962f
Fix the chan mode checking for RSL Chan Mode Modif: do not reject
all modes on dyn TS.
In rsl_rx_mode_modif(), bts_supports_cm() should never
be fed with dynamic pchan kinds (e.g. GSM_PCHAN_TCH_F_TCH_H_PDCH).
Feed instead the return value of ts_pchan() that is to say,
the actual pchan type (e.g. GSM_PCHAN_TCH_F).
Change-Id: I7f0c835b25289931bccf96e982ea5564c8be4192
This patch adds scheduler support for the channel combinations that
substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4.
Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f
Closes: OS#1617
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
Whenever a CBCH is used, this results in a new physical channel
combination on the relevant timeslot. The chan_nr_by_sapi() function
must handle those cbch-enabled PCHAN types.
Change-Id: I963909bcec8392ec445d0bcf53a2a8d7d9535444
Normally, the "Common Channel" related RSL messages should actually
contain such a common channel. However, since cell broadcast is
implemented inside what's essentially a downlink SDCCH, we should add
some explicit exceptions.
Before this patch, any RSL SMS BC CMD would have been discarded and
an RSL Error Indiciation returned.
Change-Id: I2f7f1dd43505cc27cd33489d8b0e8c981cd93880
Closes: OS#3533
When adding a new measurement also log the frame number by the modulus
of the measurement interval to simplify debuggung
Change-Id: I77a4d947dab32de0d5717ebf13bd8de6179dfe6a
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
The unit-test function test_lchan_meas_process_measurement() does not
tag measurements as SUB. Lets make the test function more realistic by
setting the is_sub flag at the correct positions.
- Add SUB-Measurements in the correct position
- Print log lines when adding measurements for sub, also fix
minor bugs in the log printing.
Change-Id: I25c361b21a406c0017ee586f0492c38f2e737e57
Related: OS#3502
Related: OS#2975
At the moment the measurement calculation of osmo-bts works by
collecting the measurement reports the phy emits during a measurement
interval. Normally one would expect a well defind fixed number here, but
some phys will not emit a measurement report for lost blocks. Also
blocks and their reports may get lost because of cpu overload etc.
The computation that is executed at the end of the measurement interval
computes over all received measurement. This evenutally means that
missing measurements will not taken into account and the result will
look better than it is in reality.
To fix this, the interval must be of a defined size and in cases where
less measurements as expected were collected, the algorithm must assume
they have been received with a 100%BER and take that into account.
However, all RSSI and TA/TOA related computations should continue to
rely on actual measurement data.
- make sure the algorithm works over a fixed interval
- replace missing measurements with 100%BER
- fix and extend unit-tests
Change-Id: Idd30fc07603ad7d042c1fb416e247c3bf7d35c8b
Related: OS#2987
The function is_meas_overdue() does not use is_meas_complete() anymore
and therefore the related log output is wrong. Lets correct this.
Change-Id: I9b7aa2f7a7c75bc3eed0c94b6ef9d17e7e36ce96
Related: OS#2975
The lookup table that control the measurement interval endings do not
make clear what their indexes refer to. Lets give them more distinct
names.
rename sdcch8_meas_rep_fn102 to sdcch8_meas_rep_fn102_by_ss
rename sdcch4_meas_rep_fn102 to sdcch4_meas_rep_fn102_by_ss
rename tchf_meas_rep_fn104 to tchf_meas_rep_fn104_by_ts
rename tchh0_meas_rep_fn104 to tchh0_meas_rep_fn104_by_ts
rename tchh1_meas_rep_fn104 to tchh1_meas_rep_fn104_by_ts
Change-Id: I3dc891e1860109f803c1bfa46445e8fef35586d9
Related: OS#2975
The tests TC_meas_res_sign_sdcch4 and TC_meas_res_sign_sdcch8 are
failing mainly because lchan->ts->nr is confused with lchan->nr.
There is also a small problem with one of the formulas that compute
fn_missed_end.
- Add explainatory comment to the lookup tables on what the index
is refering to
- use lchan-nr instead of lchan->ts->nr when dealing with SDCCH/4/8
- simplfy and fix the formula
- increase the testcoverage of the unit tests, give SDCCH/4/8 also
a thorough check.
Change-Id: I5d555a21003943bf720c53f3a611029ba45339a9
Related: OS#2975
The function ts45008_83_is_sub() is an integral part of the measurement
calculation as it automatically tags incoming measurements as SUB
measurements. This is important in the context of DTX. Unfortunately
there is no unit test for this function yet.
- Add unit test for ts45008_83_is_sub()
Change-Id: Ia26774859f4bf31baee075896905079368bddd42
Related: OS#3502
The Table that lists the fn%104 frame number masks that define which of
the incoming measurements to be recognized as SUB measurements contains
one wrong number.
For comparison see also:
3GPP TS 05.08, chapter 8.3 Aspects of discontinuous transmission (DTX)
- Change 29 to 20 in ts45008_83_tch_hs1[]
Change-Id: Id3698551d94866f418e662b9fe81429b16e2621c
Related: OS#3502
We do not test is_meas_complete() individually yet, but it is an
integral part of the measurement processings since this function decides
where a measurement interval ends.
- Add unit tests that test TCH/F, TCH/H, SDCCH/4 and STDCH/8
Change-Id: I8f89d9e7092cd65ba4d5c5649140692dcc20bdd6
Related: OS#2987
For enabling PDCH on a dynamic timeslot, PDTCH and PTCCH SAPIs shall be
enabled. While osmo-bts-sysmo uses the lchan->type to determine which SAPIs to
enable (see lchan_activate() in osmo-bts-sysmo/oml.c:
sapis_for_lchan[lchan->type]), the osmo-bts-trx code instead relies on the
chan_nr indicating RSL_CHAN_OSMO_PDCH = 0xc0 (see trx_sched_set_lchan() in
common/scheduler.c and the PDTCH,PTCCH entries in trx_chan_desc[]).
The 0xc0 cbits are a non-standard invention specifically used for only Osmocom
style dyn TS, so the chan_nr for IPA style dyn TS will and should never include
this cbits pattern. Hence gsm_lchan2chan_nr() correctly always returns the
TCH/F equivalent chan_nr for IPA dyn TS.
Because trx_chan_desc[] relies on the 0xc0 in the chan_nr to activate the PDTCH
and PTCCH SAPIs, internally patch the 0xc0 cbits over the chan_nr in
osmo-bts-trx/l1_if.c for channel de-/activation, iff lchan->type == PDTCH.
This is technically a convoluted mix-up of the cbits usage. Nevertheless, it is
the simplest way to make IPA dyn TS behave the same as Osmocom dyn TS in
scheduler.c.
Apparently, IPA style dyn TS have never worked for osmo-bts-trx before?
Related: OS#3493
Change-Id: I0eed8a135f2ab7e7c0d15ad5c76430b7fe54df3d
osmo-bts-virtual uses UDP multicast to communicate with its virtphy
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.
- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set
Change-Id: I7f27758b7aa786c8dbae669cbcde10baab8e4845
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497
for SDDCH4 channels, the detection is not working correctly since the
function uses the lookup table for SDCCH8 interval endings there. This
needs to be corrected. Also there are two unnecessary assignments in
the code which should be removed.
- use correct table (sdcch4_meas_rep_fn102 instead of
sdcch8_meas_rep_fn102.
- remove unnecessary assignments to last_fn_mod
Change-Id: If8a269ecd3f9fa4eeadf379114db816ef5c77d77
Related: OS#2975
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
the measurement interval end is detected by using the measurement
indication that is related to the SACCH block as a trigger to start the
computation. If the measurement indication for the SACCH gets lost
because the block could not be received then the processing is not
executed. This may cause wrong results or when it happens condecutively
an overflow of the measurement sample buffer.
- Store the frame number of the last received measurement indication
- Use the stored frame number to check if an interval was crossed when
the next measurement indication is received. If we detect that we
missed the interval, catch up by running the computation and
start the next interval.
Change-Id: I3a86cd8185cc6b94258373fe929f0c2f1cf27cfa
Related: OS#2975
At the moment only lchan_meas_reset is reset on channel activation.
All other states are not reset. This may lead to irretations in the
first measurement interval if there are still leftover messages from
a previous connection. Lets ensure everything is reset to zero by
zeroing out the whole .meas struct in struct lchan.
- Add a centralized function that does the reset
- Call that function from rsl_tx_chan_act_ack() in rsl.c
Change-Id: I880ae3030df6dcd60c32b7144c3430528429bdea
Related: OS#2975
Related: OS#2987
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
The previous implementation unconditionally subtracted nanosecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() instead, which
accounts for nanoseconds correctly.
This is a similar bug as fixed in osmo-pcu for issue OS#3225
While here, switch variables which are calculated based on
struct timespec to 64 bit types. While probably not strictly necessary
in practice, this makes the types used in calculations more compatible.
Change-Id: Idfd9c807e35cd7fb5c80625b9746121f81c24599
Related: OS#3467
Related: OS#3225
the testcase definitions in meas_test.c that define different test
situations for uplink measurement are quite large. Lets have them in a
separate file so that the code meas_test.c is easier to maintain.
- Move all mtc* and ulm* structs as well as the struct definitions
to meas_testcase.h.
Change-Id: I90139ec535056d2cea6de10e77f435d807ce496e
Related: OS#2987
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: Idde432ffd3dae3b7beac77c794e60b6ba555e488
Related: OS#3449
Each logical channel (e.g. SACCH, SDCCH, etc.) has a counter of
lost L2 frames. Let's use a bit better name for it, and correct
its description in the 'l1sched_chan_state' struct definition.
Change-Id: I92ef95f6b3f647170cfd434a970701406b0a7c82
During SACCH FILL processing, update lchan SI values only
for lchans which follow BTS-global default values, keeping
lchan-specific overrides in place.
Change-Id: I515bbd9983fa894507386b241863a9aa4d279497
Fixes: eee7247ebe
Related: OS#3173
When a SACCH FILL is received, loop over all lchans and update
their copies of system information data.
This change makes BTS_Tests.TC_sacch_multi_chg pass.
Change-Id: I3e63eeb5fcf320fb029de16e4d327e153cc34567
Related: OS#3173
Upper layer requires us to trigger all events coming from lower layers
in order to keep the RTP clock in sync. In this case, this is done by
sending an empty payload to indicate there's no data to send.
Change-Id: I0bdfb529f35253ca7e531bb9984a3839c3bfe7e8
Other backends use already msgb in lower layers and eventually call
add_l1sap_header to push TCH data up the stack.
backends using common/scheduler.c (bts-trx, bts-virt) are the only ones
not yet using msgb in lower layer but only creating the msgb
immediatelly before sending it in _sched_compose_tch_ind. Let's add a
log message there too to have similar output in all BTS backends.
Change-Id: Ia90b051f308abcd8b88b84e861da593844b0d81a
Avoid 'osmo-bts' in parallel to the other osmo-bts components from
the OBS generating confusion and not starting binaries (lib conflicts).
Related: OS#3364
Change-Id: Ie8e8d604afeac55530162a69c4dc94e8048ac78d
All code in osmo-bts goes through APIs in libosmotrau (osmo_ortp.h),
hence direct dependency is not needed. Fixes OBS warnings:
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-trx/usr/bin/osmo-bts-trx was not linked against libortp.so.9 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-bts-virtual/usr/bin/osmo-bts-omldummy debian/osmo-bts-virtual/usr/bin/osmo-bts-virtual were not linked against libortp.so.9 (they use none of the library's symbols)
Change-Id: I96a9b5f0678331dcf66c007928866a124d8700de
Files from doc/examples/foo/bar.cfg are install to
/usr/share/doc/osmo-bts/examples/osmo-bts-foo/bar.cfg.
Change-Id: I7525d5a3e1a3c83a54f919cce9096303dd506f35
CalypsoBTS is a regular osmo-bts-trx with specific config options, so
let's move the cfg file to correct place. This also makes it easier to
install and package example files later on.
Change-Id: Ie2b968c478f1cf4d3e4cb36e4fb743e413cc93f0
This patch adds extended processing of the high-resolution TOA256
measurement values. It adds reporting of the following values
for each RSL MEAS REP for uplink measurements:
* minimum TOA256 value during reporting period
* maximum TOA256 value during reporting period
* standard deviation of TOA256 value during reporting period
Change-Id: Iea4a4781481f77c6163d82dcd71a844a5be87bf2
The latest octphy firmware release (octsdr-2g-02.11.00-B1927-alpha),
introduces a 16X oversampling option which is not yet supported in
osmo-bts.
- Add oversampling flag in phy_link.h
- Add VTY commands to enable/disable oversampling
- Add phy messages to enable/disable oversampling
- Add conditional compilation to preserve support for legacy
header files and firmware
Change-Id: Ib78f92bfe03ff20aa0a257763c90844fb7b87cf0
Related: SYS#4257
Patch-by: Octasic inc.
osmo-pcu currently sends paging requests in PCU_IF_MSG_DATA_REQ
messages, rather than PCU_IF_MSG_PAG_REQ. Clarify a comment which
already alluded to this, and leave an explicit log entry if a
PCU_IF_MSG_PAG_REQ message is received.
Change-Id: I75fd8f051f943d876b5614fa088fff7e56b310ab
Related: OS#3018
The flag is enabled for all BTS flavour except for lc15, which still
contain several compilation warnings (fixes submitted to gerrit, but not
merged since no contributor is testing lc15 nowadays).
Change-Id: Ib65056633697dafa63831fc2a480b798df550db6
Fixes following compilation warning:
In file included from l1_if.c:32:0:
l1_if.c: In function ‘l1if_mute_rf’:
/include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
l1_if.c:1405:29: note: in expansion of macro ‘ARRAY_SIZE’
if (!memcmp(mute, unmuted, ARRAY_SIZE(mute))) {
^~~~~~~~~~
l1_if.c:1388:51: note: declared here
int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb)
^~~~
In file included from l1_if.c:32:0:
/include/osmocom/core/utils.h:13:30: error: ‘sizeof’ on array function parameter ‘mute’ will return size of ‘uint8_t * {aka unsigned char *}’ [-Werror=sizeof-array-argument]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
l1_if.c:1408:19: note: in expansion of macro ‘ARRAY_SIZE’
for (i = 0; i < ARRAY_SIZE(mute); ++i)
^~~~~~~~~~
l1_if.c:1388:51: note: declared here
int l1if_mute_rf(struct femtol1_hdl *hdl, uint8_t mute[8], l1if_compl_cb *cb)
^~~~
Change-Id: Id040aeb35549ddb75072942be0093064a89092a6
Fixes following compilation warning:
osmo-bts/src/osmo-bts-sysmo/sysmobts_vty.c:349:3: warning: implicit declaration of function ‘lchan_deactivate’
Change-Id: I1dba0b08fdb2af199f009842c9abf32e25f74be1
This way we give the opportunity to the BSC to release the channel
quicker, otherwise it has to wait until T3101 expires.
Same procedure is already done in rsl.c rsl_rx_imm_ass() when we return
an error (hard limit AGCH queue len reached) from bts_agch_enqueue().
Related: OS#2990
Change-Id: Id9927c0789054ce3ecc7b30380585a1ffe05db5a
We saw in a recent prod setup a BSC with saturated channels. Further
investigation lead to a AGCH queue of 1000 (previous hard_limit)
messages, most of them being regular IMM ASSIGN (non REJ). Hence, we
also want to get rid of other messages in the AGCH queue (like regular
IMM ASSIGN).
Furthermore, In this scenario, sending IMM ASS REJ is as important as other
messages given than nowadays we support dynamic wait indicatior
(calculated based on chan load), which means if we reach the MS, we can
tell it to wait for a long time to reach us again, which is desirable.
Change-Id: I022b8948da8be13fb8f4bc36e7c9dab11c35fddb
In a prod setup, complete channel saturation at the bsc was detected,
and Immediate Assignments were not being answered by the MS once sent by
the BTS.
Further investigation showed that the BTS was all the time printing
messages like this:
"bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10"
So it seems the AGCH queue was becoming incredibly full (1000, hard
limit triggered the log), while acgch_queue.max_length was set to 10.
As a result, most probably the Immediate Assignments being sent to the
MS are super old in time, and the MS doesn't known about them anymore
once they are receivied, so no answer is sent back.
Let's try to avoid that by decreasing the hard limit so we never reach
that big queue_len scenario.
The number 100 is selected from data gatherered in agch_test.c which
prints a table of max_length values based on different setups. Some
values can reach around 80 messages, so let's use a slightly bigger hard
limit.
Related: SYS#2695
Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
It seems I somehow mischecked that the required include for gsm48_rr_msg_name
was not yet present in the file.
Fixes: 44a35902ad
Change-Id: Ia82bc6a5ff7e3989cf0b85ee689d0c3344720eda
The current implementation does not allow the user to specify a port
range in which the BTS is allowed to allocate a local RTP port. Also
the ports the BTS picks do not match the policy described in RFC3550.
An RTP Port must be at an even port number and the matching RTCP
port must be at the following (odd) port number. The BTS currently
picks random port numbers for both.
- Add a VTY command to specify a port range in which the BTS may
assign local ports.
- Pick ports as described in RFC3550.
Change-Id: Id75f1dfaf898ed8750d28b1c4840e188f4cfdc87
Related: OS#2825 OS#2635
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
Let' wait until the just-merged osmo_timerfd_* functions
of Change-Id Ibeffba7c997252c003723bcd5d14122c4ded2fe7 have made it
into the next tagged release, and then replace the implementation
here.
Change-Id: Ic0f0a7437b6acb535177e5ad6ac7a6d336654c66
A frequent configuration file error is that the unit_id settings of
osmo-bts and osmo-bsc don't match. The BSC already prints an error
in this case. Let the BTS print an error as well.
We use a heuristic for this purpose: If the OML link is dropped within
10 seconds after being established, log a special warning which alerts
the user and recommend a manual configuration file check.
Change-Id: I476ac797458b5a46edea3ae9cfbd491fd7f77f47
Related: OS#3143
To allow switching a dyn TS also between TCH/H <-> TCH/F and anything else,
don't thwart RSL messages just because their chan_nr doesn't reflect the
current pchan mode. For dyn TS, leave that to message handling.
In particular, a TS switch is invoked by a Chan Activ message, in which case
the current pchan by definition mismatches the incoming chan_nr's reflected
channel type.
With this patch, I have tested successful direct TCH/H<->TCH/F switchover on
sysmoBTS, with osmo-bsc patch I72d5d833b186b1e1925d513885b405d8c19aa496 (and
'msc'/'codec-list' vty config to change TCH kinds while gprs mode was none).
Change-Id: I19e5e509101ec91204de9baff04582d99bc8dcb8
This actually should have been working since 2015, when the following
patch was merged to libosmcore:
commit f8699ca51eeb4f3d34336501abcaf071b4a95a47
Author: Max <max.suraev@fairwaves.co>
Date: Wed Mar 25 17:20:31 2015 +0100
gsm: Add A5/3-4 cipher support
however, it seems nobody so far bothered to actually enable A5/3 for
osmo-bts-trx!
Change-Id: I8192d6d07cdb87783bce997456ead673c600f7c0
Closes: OS#3253
The existign code only sent an ERROR REPORT, but it failed to actually
send a proper NACK to the related request. This is confusing, as the
operation should always be ACKed or NACKed, and not simply result in no
response.
Change-Id: Ic374a8e5e239ffe37082a54cdb94cb6ac9723e83
Closes: OS#3254
Whenever we encounter an error condition during processing of RSL CHAN
ACT or RSL MODE MODIFY, it's insufficient to simply send an RSL ERROR
INDICATION, but we also must send a proper NACK back to the BSC.
Change-Id: I4dd7ff2fd2cdbc6e892cd329c826ac1bc3b16bb9
The code actually always *wanted* to make lchan activation fail in
case we don't support the algorithm, but it failed ot do so.
The problem is encr_info2lchan() which uses bts_supports_cipher() to
determine if the cipher is supported. However, if bts_supports_cipher()
returns 0 (not supported), it uses this value as return value of
encr_info2lchan() where '0' means success (standard osmocom convention).
This results in channel activation proceeding, which it shouldn't.
Change-Id: I46275b8fc2a1a74f68b4cc60e0f64ba226b108cd
Related: OS#3254
This logging turned up while I was debugging dynamic timeslots:
- OML Set Channel Attributes logging.
- a specific dyn TS pchan error.
- show pchan and lchan types on CHAN ACT ACK and REL ACK logging.
- on RSL message Rx, log the current pchan kind in detail, using
gsm_ts_and_pchan_name(). This logs the underlying pchan as well as the
current pchan mode a dyn TS is in.
- move 2 dyn TS logging from DL1C to DRSL, where all the other dyn ts logging
is.
Change-Id: Ia89c134060e85f7065afd5642d1c541c65dd25ea
In early rsl_rx_chan_activ(), do not use rsl_tx_chan_act_acknack() to trigger
sending a NACK, instead use rsl_tx_chan_act_nack() directly.
Rationale: the previously used rsl_tx_chan_act_acknack() may decide to omit the
NACK, particularly based on the lchan->rel_act_kind. lchan->rel_act_kind
indicates whether the Chan Release or Activation was explicitly requested via
RSL, and thus whether an ACK/NACK should go back to RSL or not. This gets set
only late in rsl_rx_chan_activ(). We cannot set it on top, because we need to
first establish whether the Chan Activ is permitted or not. In case of early
rejection of the Chan Activ, we do not want to modify the lchan state, but
merely reply with a NACK, unconditionally.
Before this patch, NACKs that rsl_rx_chan_activ() wants to trigger would
possibly be not be sent out on RSL, because lchan->rel_act_kind is not
explicitly initialized until later.
Fixes: BTS_Tests.TC_dyn_ipa_pdch_act_tchf_act_nack
Change-Id: Ic981f768cc024f0acd3d7ae55846cfbc7bc089ce
When an RF CHANnel RELease request is received on an already released lchan,
there is no "REL NACK" message or similar, we just ACK the release.
When ACKing the release, make sure to reflect the same chan_nr that the release
was asked for, since the lchan state may actually reflect a different chan_nr.
Factor the actual Rel Ack message sending out of rsl_tx_rf_rel_ack(), which
makes all sorts of decisions around normal Rel Ack: add static tx_rf_rel_ack(),
with chan_nr argument instead of deriving chan_nr from the lchan.
Use this to directly ACK an unusual Chan Rel with the chan_nr that came in with
the request.
Fixes: BTS_Tests.TC_dyn_osmo_pdch_unsol_deact
(after I6b790e866ce4e66d9385b286b727ae41a83d3e67)
Change-Id: Iceaa2e87874ced42d664a2a0b01a1c59e46a19b3
Make osmo-bts send a State Changed Event Report when RF is locked
or unlocked. This behaviour isn't mentioned in the spec as far as
we know, but an ipaccess nanobts also produces these messages.
Change-Id: I37e44ef4881c41f8835428b610e7863f37397c9f
Related: OS#3161
In gsm_lchan2chan_nr(), use a switch to reflect both dyn TS kinds and enrich
with comments. Move GSM_PCHAN_TCH_F_PDCH out of gsm_pchan2chan_nr(), which is
now back to pure standard PCHAN values.
Rationale: it's easier to figure out what is going on and why.
Change-Id: I6a31b44220d97c9173c52d3567a1382541710d10
For ip.access style TCH/F_PDCH, this fixes switch-back to PDCH in case the TCH
use employed encryption.
For Osmocom style TCH/F_TCH/H_PDCH, do the same, purely out of sanity. Roughly
the same should already be happening during PDCH Chan Activ, but make sure to
clear all these fields, so they are cleared even if IEs are missing.
From both dyn TS code paths, call new clear_lchan_for_pdch_activ(), which
clears the same fields that are normally overwritten by an RSL Chan Activ.
Related: OS#3238
Change-Id: I8451039683b54bee910c97c5a3e6873e0ff1b160
When the PCU is not connected, we immediately call rsl_tx_rf_rel_ack() because
we don't need to wait for a PDCH deactivation. Fix: properly mark rel_act_kind
= LCHAN_REL_ACT_PCU to invoke identical behavior as when the PCU were involved.
(When the PCU is connected, a PDCH release on an Osmocom style dyn TS causes an
actual release of the PDCH TS, and then triggers an rsl_tx_rf_rel_ack() with
rel_act_kind == LCHAN_REL_ACT_PCU.)
Clarify the code flow: rc == 1 is the special case of no PCU being connected,
so have that in a separate if{}.
Change-Id: I654b963815b32fcbce050c2e15f3190c97bc259f
When a release of PDCH is complete, actually set the dyn.pchan_is to NONE.
Failure to do so currently caused errors on activation of an Osmocom style dyn
TS as TCH, in the shape of:
rsl.c:636 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK
rsl.c:164 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH switching PDCH -> NONE) RSL rx DCHAN: mismatching chan_nr=0x12
rsl.c:2611 Rx RSL CHAN_ACTIV for unknown lchan
rsl.c:710 0x12: Sending Channel Activated NACK: cause = 0x64
The Tx RF CHAN REL ACK shows that we're through with PDCH release, but the
following line showing "chan=TCH/F_TCH/H_PDCH switching PDCH -> NONE" shows
that the state still reflects active switching. Thus the DCHAN code decides
that the chan_nr = 0x12 reflecting a TCH/H on TS 2 is a mismatch and NACKs the
TCH activation.
(For ip.access style TCH/F_PDCH, the ts->flags are cleared in
ipacc_dyn_pdch_complete()).
Related: OS#3235
Change-Id: Ic06c8f0fe82ae8a06afa5defd93a685010687965
Use a switch statement and ample comments to clarify what is done and why.
Cosmetically prepares for Ic06c8f0fe82ae8a06afa5defd93a685010687965.
Related: OS#3235
Change-Id: I8a9953b011a4516972aae468754494f57ebc0a3f
Should fix following observed run time errors:
osmo-bts-trx/scheduler_trx.c:1627:65: runtime error: signed integer overflow: -1081823 * 4615 cannot be represented in type 'int'
osmo-bts-trx/scheduler_trx.c:1627:21: runtime error: signed integer overflow: 1852394502 - -697645849 cannot be represented in type 'int'
Related: OS#3213
Change-Id: I36e0d2d0d0c6e35e963f611135453c4a4c00bc99
The caller translates errno values back into NACK codes anyway,
so lets's return NACK codes directly.
Change-Id: I2b1f79e66c778139d64101c89dd6377921807e2d
Related: OS#2295
In addition to logging an error, send a NACK if the BSC attempts
to set more than one ARFCN in Radio Carrier Attributes for a BTS
which does not support frequency hopping.
Change-Id: Ia72e23a3f08f825cf9cf0d9a55302d13cfed51d6
Related: OS#2295
src/common/sysinfo.c:147:1: warning: control reaches end of non-void function [-Wreturn-type]
}
The compiler warning is actually a false positive since we call
OSMO_ABORT on that path, but let's add a return anyway so the
compiler doesn't throw a warning.
Change-Id: I9b4e06927489a8bc20ce173279a01415a8c4295a
When a bad voice frame is received, it is replaced by
a silence frame. This may cause unpleasant audio effects.
This change implements a functionality to craft a replacement
frame from the last known good frame using ECU implementation
from libosmocodec. At the moment, only FR is supported.
Depends: libosmocore I06a21f60db01bfe1c2b838f93866fad1d53fdcd1
Change-Id: Iae9e69a9578ae305bca42f834694af96a29084e6
At the moment osmo-bts does not compile with the latest header
file release from OCTSDR-2G-02.10.00-B1837-ALPHA as there are
struct members removed and new ones added. The changes do not
affect actual functionality in the existing code. The only
affected parts are vty functions that query status information
about the clock sync manager.
- Add detection logic in configure.ac to detect if the affected
struct members are present
- Add conditional compiling to handle the different combinations
of available struct members.
Change-Id: Ic38d8dc35522205c4ffab583b4e61b5ef03cdba2
Related: SYS#4139
Patch-by: Octasic inc.
in change-id Iebd2571726d1284a7431b3f9b23ad3185e832ed1 we introduced
tighter validation on whether the requested channel number matches the
underlying physical channel configuration. Unfortunately this broke
activation of an osmocom-style dynamic PDCH as TCH/F or TCH/H
rsl_lchan_lookup already permitted a chan_nr if the dynamic PDCH was
already switched to the given TCH mode, or at least the related
switching had already been initiated.
However, in the case of the bug, the current type is NONE, which means
that the compatibility check of rsl_lchan_lookup will fail
Let's relax the checks of rsl_lchan_lookup() slightly to permit
matching for "ts->dyn.pchan_is == GSM_PCHAN_NONE" cases.
This fixes BTS_Tests.TC_dyn_osmo_pdch_tchh_act and
BTS_Tests.TC_dyn_osmo_pdch_tchf_act
Change-Id: I14ae4c4ed2aae0966e5cb5116cf024d6bd890237
Related: OS#3134
It seems that the IPA PDCH ACT ACK contains not only the channel number,
but also the frame number. Let's make sure we're as close as possible
to other implementations to ensure maximum interoperability.
Change-Id: Ibe7988e9ef374e8c7d9429777fb32322d90c2024
When writing chan_nr_is_dchan() in Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349,
I apparently only looked at TS 48.058 without considering the osmocom
extension to it for PDCH activation. The result is complete breakage
for "osmocom style dynamic PDCH" support.
This patch fixes the mistake by making the compare more specific.
Change-Id: I18e0774fdd48966bc95261e715f798464b8b681f
Related: OS#3131, OS#1853
Completely drop bts_log_init(), call osmo_init_logging2() directly instead: all
callers of bts_log_init() passed NULL as category string, so all it ever did
was call osmo_init_logging(). The bts_log_info is already declared in the .h.
Here and there also define a proper talloc root context instead of using NULL.
Change-Id: Ic049f77bef74123b95350bcae182a468e0086b9c
This commit restores ability to read write to the
SuperFemto EEPROM.
Use offsetof() instead of casts to pointers when
calculating the address to pass to
eeprom_read() and eeprom_write()
Fixes: 7cf144b27d
Change-Id: Iaa7318387ad7bb248c261b1f428019244039e7d2
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
In omldummy, we don't have a RSL link and hence any transmission
attempts to RSL should silently go to /dev/null rather than printing
error messages via libosmo-abis. So check for the OMLDUMMY variant and
silently discard any RSL message that the code may want to transmit.
Change-Id: I04a9ec7e416822cc1e45c533e6a66628689615ad
This is used only in integration testing, where in the TTCN-3 testsuite
we currently have no A-bis OML implementation, but only a RSL one.
Change-Id: Id8e5f34091e6e32621d8c8673de7ea848dfd252f
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
Rathert han have 11 direct members of gsm_bts_role_bts, group them
into a sub-struct as ew do for other parts like interference, laod, ...
Change-Id: Iefecf4b70c1b11c650913f2ae3783718ffb8a36c
What we remove here is a legacy from sharing this header file with
openbsc/osmo-bsc-sccplite, which we stopped to do quite some time ago
and hence can remove those parts that are only relevant to the BSC but
not to the BTS.
Change-Id: Icac1656da68f6a006a28c779e3b563bbdd905b3d
In order to be able to introspect not only the root application
context, but also all other contexts, e.g. allocated within
libosmocore or other libraries, let's enable tracking the
use of NULL contexts using the corresponding talloc API.
In order to obserbe all existing contexts,
use the following VTY command:
OsmoBTS# show talloc-context all ...
Example of usage:
OsmoBTS# show talloc-context all brief
talloc report on 'null_context' (total 1302808 bytes in 5185 blocks)
lapd context contains 129 bytes in 5 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct pcu_sock_state contains 120 bytes in 1 blocks
struct lookup_helper contains 24 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
abis contains 49065 bytes in 19 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
struct signal_handler contains 40 bytes in 1 blocks
vty contains 93690 bytes in 5008 blocks
logging contains 2862 bytes in 7 blocks
OsmoBTS context contains 1156678 bytes in 137 blocks
Change-Id: I5e9381902dace7dfd37f98b657e4697b5afcff96
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: I5b37602a117350159183fb53ac330294b94f4195
The existing algorithm (present since 2012!) failed to work
in the sole case that only *one* SACCH filling type was present.
So if you had your BTS configured to only broadcast SI5, but not
broadcast SI5ter, SI6 or any other SACCH filling, it would send
the SI5 message only once on a newly-established channel, and never
again.
The old code was working for more-than-one SACCH filling, as well
as for no SACCH filling at all.
Let's also add a NOTICE message if there is no SACCH filling available
at all. This is highly unusual and definitely a noticeable event.
Change-Id: Ica801f9b9c118f00d9e3dc2780b3123e925f59b4
Closes: OS#3057
Related: OS#2963
Record the mnc_3_digits flag from SI and pass on via the PCU interface.
Instead of changing to e.g. osmo_plmn_id, add the flag separately, and instead
of bool use a uint8_t, to not raise any struct packing issues and clarify the
flag's size beyond any doubt.
Bump the PCU interface version to 9.
This is one part of the three identical pcuif_proto.h patches:
- I49cd762c3c9d7ee6a82451bdf3ffa2a060767947 (osmo-bts)
- I787fed84a7b613158a5618dd5cffafe4e4927234 (osmo-pcu)
- I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 (osmo-bsc)
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore)
Change-Id: I49cd762c3c9d7ee6a82451bdf3ffa2a060767947
When using a firmware version < 3.6, the call to l1if_mute_rf()
returned an error, which caused an OML CHG ADM STATE NACK.
Let's check if the l1if_mute_rf() call is an un-mute for all
timeslots (which apparently we do always at start-up). If it is, then
acknowledge it even if muting is not supported by earlier firmwares.
I suppose the change causing this problem was introduced in:
commit b26b8fc776
Author: Holger Hans Peter Freyther <zecke@selfish.org>
Date: Tue Mar 4 15:03:59 2014 +0100
sysmobts: Do a RF mute at initialization when the RC is locked
With the current change applied, we can run the BTS with earlier
firmware versions than 3.6.0 again. Tested with 3.1 and 2.4
Change-Id: I1a29c1031d96e65a0111bc812a90f2dbaf2a5aa3
SI1 is only required if frequency hopping is used or if NCH is used. So it's optional.
If OsmoBTS has no SI1 configured, it will transmit the empty SI1 buffer
at TC=0, and as a result no valid SI will be broadcast at TC=0.
Change-Id: I41ab885c00e943199b2e939e98f30e267ecffbee
Closes: OS#3051
Commit c2b4c668f3
I3b989580cb38082e3fd8fc50a11fedda13991092 introduces evaluation of ra_ind
members below the msgb_trim() call that actually invalidates ra_ind.
A symptom is that it breaks detection of Handover RACH, wich always ends up
with lchan == NULL and interpreting all RACH as chan_nr == 0x88.
Fix: do all evaluation of ra_ind before the msgb_trim(), for osmo-bts-sysmo,
litecell-15 and octphy.
To guard against similar mistakes in the future, set ra_ind = NULL before the
msgb_trim() call.
Related: OS#3045
Change-Id: I203021ee57f49cb963679ba8bec5943e2abb67fb
the file l1_tch.c in the octphy spcific code has its root in the
tch.c file of sysmobts. It contains some sysmobts specific ifdefs
which enclose dead code.
- Remove the sysmobts specif ifdefs and the dead code
Change-Id: I33f3e0fd293ca8387fddf5ed20f642621e9680de
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
This was useful for software simulation of burst delay, expressed
by ToA (Time of Arrival). Since we have FakeTRX toolkit, ToA value
may be simulated in a more flexible way, so let's remove this code.
Change-Id: Ied0fcfcf58b93efdc6de9666fbbf8fea104e2543
The current log output logs connect_ip connect_port
speech mode and payload type over multiple lines and without
logging context (lchan name). Also the logging level
incorrectly set.
- shrink log output into one line.
- add context (lchan name)
- encode ip/port into human readable form
Change-Id: I61044edc0672b268aeebf48b59a772887703399f
Closes: OS#3001
Add PCU_IF_MSG_DATA_CNF_DT and PCU_IF_SAPI_AGCH_DT to bring the
pccif_proto into sync. Both commands are required to support the
rb11 with an osmo-bsc co-located pcu.
Change-Id: I6d330aca26249ee94ece5e415079f0b75c6e8b48
PCU_SOCK_DEFAULT is defined in the pcu counterpart of the file pcuif_proto.h
To be consistent with the pcu move the definition pcuif_proto.h
The pcuif_proto.h will be exact the same in the pcu repo and bts repo.
Change-Id: I67f8ec036e219994cc296d0ed5409da7f3ec681e
warning causes the compiler to throw an actual warning. Lets
change those intentional warnings to messages.
Change-Id: I2fc83a1a07db9c569b93f29835bf3a0fd8ef4ef5
In OsmoBTS, we (so far?) only have a single BTS inside each process,
let's make sure we log an error message if the PCU should ever want to
transmit primitives to a non-zero BTS number.
Change-Id: I158f935fed12941737c806c0677a8192ea3418a0
Don't blindly trust that the ts_nr received on the PCU socket will be
small enough to not overflow our timeslot array!
Change-Id: Ie9964c8dc0ca7b049da7dfec0ac0a0d3f1aedd45
The downstream code of pcu_sock.c doesn't contain any length checks,
so let's discard any messages that are shorter than the primitive
length.
Change-Id: I35ac84d4db6d21ea61afbd1864c810bbf601d69b
Normal Abis RSL MEasurement Results contain only the "MS Timing Offset
IE" in units of full symbols. In some use cases it is important to have
higher-accuracy timing information exposed to the BSC.
We do this by adding the average timing offset value during the last
measurement interval in 1/256th symbol accuracy to the "Supplementary
MEasuremen Information" part of the TS 48.058 9.3.25 Uplink Measurements
IE.
In order to avoid any compatibility issues, this feature is only enabled
if the new vty config command "supp-meas-info toa256" at the bts node
is enabled.
Change-Id: Ie85e53b47d4041cc4e6d7b78406ae8b79b2d9397
At the end of a measurement processing window, we currently compute
the ToA / timing offset at 1/256th symbol accuracy, but we only print
it to the log. Let's store the value in the lchan to make it usable
by other code in follow-up patches.
Change-Id: I5f00a16ac966b627d9452a98b8fa70984bed684a
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
There's no need to express TOA as a float:
* We receive it as signed 16bit integer in units 1/256 symbol periods
* We pass it to L1SAP as signed integer in 1/4 symbol periods
So turn it into an int16_t with 1/256 symbol period accuracy throughout
the code to avoid both float arithmetic as well as loosing any precision.
Change-Id: Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec
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
The existing code contained an ugly hack that if we didn't have any
"SUB" measurements we would simply use the "FULL" values. That's wrong
as TS 45.008 contains quite detailed rules on how the "SUB" values are
to be computed. In some cases, they are identical to "FULL", but in
most they are not.
Let's remove the hack and replace it with an ERROR message, as clearly
something is wrong if we ever encounter a measurement period end in
which no single "SUB" measurement was received. The only situation in
which this can occur is if the related uplink burst/block was missing,
so let's set BER to 100% and level to lowest possible.
Change-Id: I358f7b97fd4ea19264a77eff7abef13da7d5fbcd
The rules on how to compute RX{LEV,QUAL}-SUB are rather convoluted, and
depend on the detailed channel type and mode.
For SDCCH and TCH/H in signalling mode, it's easy: No DTX is allowed,
and all measurements are used in SUB.
For non-AMR (TCH/F and TCH/H in non-signalling mode), we need to count
the SACCH block measurements, as well as any
SID/SID_UPDATE/L3_FILL/DUMMY blocks received in the blocks of table
8.3 of TS 45.008.
Only AMR (TCH/AFS + TCH/AHS) are more difficult, as there are no fixed
blocks/bursts/frames that always contain uplink messages, but the L1
will have to determine if a valid SID_UPDATE was received or not.
This patch implements the above rules (except AMR related) in the common
part of OsmoBTS. The AMR specific bits will have to follow as a later
patch, likely in a BTS specific way, i.e. separate changes to
sysmo/lc15/octphy/trx code.
Related: OS#2978
Change-Id: I16eb3747a1c23df935a4c50dafe46abce512a474
There are use cases for the multiframe scheduler tables outside the
context of the entire scheduler. Let's prepare for that.
Related: OS#2978
Change-Id: I6a501e66c47809ae3cdc55bef2cb6390ee0096b1
Combined CCCH with CBCH is a separate PCHAN type and hence we must
accept it in the list of RACH-carrying pchan types in order to correctly
report the RACH chan_nr when handing RACH requests up to L1SAP.
The bug this fixes likely might have rendered cells with combined CBCH
impossible to use.
Change-Id: I9537463e5eedd2b8b30f298e0d3b308367c5b1fb
L1SAP uses 'ber10k' values, i.e. BER in 1/10000 units, where 10000
is all errors are bit-errors (= 100%).
The PHY on osmo-bts-sysmo and osmo-bts-lc15 is reporting a float fBer
value scaled to 1, i.e. 1.00 = 100% and hence must be 10000 as ber10k.
Before this patch, BER values reported on those BTS models were too
low by a factor of 100, resulting in way too optimistic RxQual values
reported to the BSC.
Closes: OS#3005
Change-Id: I17e2f8fe8055f613da1e554cd36ed13289f56fb3
Let's introduce some functions to hide the details of BER and RSSI
conversion from OCTPHY representation to L1SAP representation.
Change-Id: I517669c87a97b2ba164a2812811c8802fe0b92e8
Since Change-Id: I23fba50f48415314da40cf5bf86fce2ed3e66af6 we were not
reporting measurements for SDCCH channel types due to the wrong
encoding of the sdcch{4,8}_meas_rep_fn102 table.
Let's fix the table by encoding the needed information:
"What is the modulo-102 remainder of the first burst of the last block
before fn%102 reaches 37?" (SDCCH/4)
"What is the modulo-102 remainder of the first burst of the last block
before fn%102 reaches 12?" (SDCCH/8)
The TS 45.002 Clause 7 tables have to be consulted carefully to
determine this information.
Change-Id: Icf02354872670126ab3297b787b216981ca6c309
Related: OS#2965
In case a DLCX _with conn-id_ is issued without any CRCX before,
we ran into a NULL pointer dereference in adding the connection
statistics. Let's handle this gracefully and simply return empty
statistics.
Change-Id: If8b71266c847b90cdc51695b9f47b527c51bd70c
Closes: OS#2996
In case a DLCX is issued without any CRCX before, let's handle this
gracefully and simply ack the DLCX anyway.
Change-Id: I7c5bedccfc5a7cf552a9ce3a2dc712081c7ce177
Closes: OS#2996
The RR PAGING TYPE 3 Rest Octets IE contains (among other things) the
channel type needed for Mobile Identity 3 + 4 in the paging message.
We did not only "forget" to encode those channel type needed field, but
we have a completely wrong definition of those rest octets in
libosmocore/include/gsm/protocol/gsm04_08.h "struct gsm48_paging3"
Change-Id: I3a0bca6707ce95b68459c89f5b2b07f1590a1ab3
Closes: OS#2994
It seems we have been encoding PAGING REQUEST TYPE 1 and
PAGING REQUEST TYPE 2 erroneously all the time. The optional last
Mobile Identity in those messages are TLV, not just LV.
This is a quite serious bug in one of the most fundamental parts of
the Radio Resource layer, and it has likely stayed hidden for a long
time as usually in small networks there's a low paging load, reducing
the amount of pressure to put multiple identities in one PAGING REQUEST
message.
Change-Id: Icc320ed130d0c29e9260a6a2aabe52e7346c3888
Closes: OS#2993
This patch adds generation of a DELETE INDICATION when the BTS AGCH
queue overflows due to too many IMMEDIATE ASSIGN CMDs, as required
by the specs.
The AGCH queue length in OsmoBTS so far is at 1000 entries, which I
consider way too high. But that is for another patch.
Change-Id: Ied3306e85cbdc6f3476b10dc4bb0463cd728b274
Related: OS#2990
Starting the timer in bts_init() may result in it expiring already
before the load indication period is set via OML. Let's make
load_timer_start() safe to call several times and call it from OML
code.
Change-Id: I295d91413542014aa2507d5f09e01243fc3916fa
Fixes: OS#2991
Whenever we receive discontinuous frame numbers from the TRX socket,
osmo-bts-trx is substituting zero-filled bursts for those frame numbers
which we missed. Don't just do this silently, but actually log about
it, as it is an error.
Note: This [currently] happens when using a virtual air interface with trxcon
as opposed to a real SDR receiver with osmo-trx.
Change-Id: If79eab37c80647c9ab64f399fa4676d97af3e9ad
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
This reverts commit d5fdcfe6d9, which
introduces a new function lchan_meas_update_ordered_TA whose
functionality I still haven't yet managed to fully understand. It
appears to be adjusting the requested timing advance (lchan->rqd_ta) but
outside osmo-bts-trx/loops.c code. This is odd, as rqd_ta is a state
variable of that loops.c code.
So for one part, it is a failure of encapsulation. The TA loop code
should be self-contained, particularly as it is only used for
omso-bts-trx, and not for the other BTS models. The new
lchan_meas_update_ordered_TA() function is used from common code,
applicable to all BTS models.
The resulting interaction between loops.c code and this new (now
reverted) function cause the TA value to only ever grow, despite the MS
never moving at all.
Change-Id: I5a5adac6f18f94a5b51758a5ace8ef6ddfd23e80
Related: OS#2989
For proper measurement processing of RX{LEV,QUAL}-SUB, we will
need this information.
Related: OS#2978
Change-Id: I768fde62452a74dce471ebf946e56eb1e4de1abc
Let's split the look-up of the multiframe scheduler from the asignment
to a given l1ts in trx_sched_set_pchan.
Related: OS#2978
Change-Id: I79548b25aae647ce993a9d83c771d22b08cb1c74
Measurement reports fed into L1SAP so far had their frame number always
set to zero, resulting in higher-layer common code above L1SAP to never
detect the end of the measurement period, which in turn caused no RSL
MEAS REP to be sent.
Related: OS#2978
Change-Id: I67837d19515ea335614928570c12dd5027104c6b
In Change-Id I5703b46c8a59fe00a3cdc063bcf72872980ec5e5 we introduced
LOGL1S and starte to use in in common/scheduler.c as well as
osmo-bts-trx but somehow we didn't introduce it in osmo-bts-virtual
at the time. Let's catch up.
Change-Id: I0b5fd3b7982b9119becda844531108f64c68d19f
Let's make sure whenever we do have a frame number, we print it as
context in the related log line
Change-Id: I751d5ddb3322fce489bc241459738cbcc55c890b
The problem is that measurement processing above L1SAP requires/expects
those PRIM_INFO_MEAS indications from the bts specific parts. Otherwise
it will never generate even uplink-only measurement reports to the BSC,
which is a violation of Abis protocol specs.
Change-Id: I48f73293cb4f0ab4c657dfd00e7ddd032a3c030f
osmo-bts has a table of pchan/channel mode combinations for every
bts. This table models the codec capabilitys of the BTS hardware.
However, having the speech codec apabilities modeled inside the
BTS feature list would be much more comfortable and since the
feature list is communicated back to the BSC we would get the
codec capabilities inside the BSC domain as well.
- remove the pchan/channel mode tables
- set speech codec variants for each BTS type
- fix bts_supports_cm so that it queries the feature list
Change-Id: I977dc729ba856631245aedf76afd48eac92166f7
The VTY command show bts does not display the bts specific
features yet.
- Also display the feature list in snow-bts
Change-Id: I509f2a7bbfa96c70bdfea4ff2488ee371e914620
Most of the BTS models do not or do register not all of thier
features to the the feature list.
- Update/extend the feature lists for all BTS-Models
Change-Id: I26765a64153368016921c2ac115b1c4aec9bc5e4
The feature list does not cover any speech codec related information.
- Add speech codec related items to feature list.
Change-Id: If6d50c6f4e2348b23f31c3415b0f5577a3f5be50
If the Channel Number IE points to a common channel, we cannot
accept such messages in code paths that only process dedicated
channels, such as RLL/DCHAN/IPA.
Related: OS#2972, OS#2971
Change-Id: I43a78bec63aeb36dd67043d237b27fe880209349
If we receive a message for a dedicated channel, whose channel number
structure doesn't match with the physical channel (timeslot) type,
we must properly reject this. For RSL CHAN ACT it means sending a NACK,
and for all other cases it means sending an RSL ERROR REPORT.
Related: OS#2972, OS#2971
Change-Id: Iebd2571726d1284a7431b3f9b23ad3185e832ed1
This avoids compiler warnings like this:
../../src/osmo-bts-sysmo/l1_transp_hw.c:130:13: warning: implicit declaration of function ‘writev’; did you mean ‘write’? [-Wimplicit-function-declaration]
written = writev(fd->fd, iov, count);
Change-Id: Ic67d369a3ca33bfa636ace9f272f1c7257de86e1
This avoids compiler warnings like
../../src/osmo-bts-sysmo/eeprom.c: In function ‘eeprom_WriteSysInfo’:
../../src/osmo-bts-sysmo/eeprom.c:605:58: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
err = eeprom_write( EEPROM_CFG_START_ADDR + ((uint32_t)&ee.cfg.v1.sysInfo - (uint32_t)&ee), sizeof(ee.cfg.v1.sysInfo), (const char *) &ee.cfg.v1.sysInfo );
Change-Id: Ic748038e6f25ec18ccb4a2f2503ca567fb00a586
When the BSC sends a MODE MODIFY request with an unsupported
codec, the BTS must respond with a negative acknowledge.
Currently the codec parameter is not checked at all, which may
lead into malfunction or crash of the BTS.
- Introduce a mechanism to check the codec/rate against a
table that is set up in the phy specific code.
- Add tables with supported codec/rate combinations for
octphy, sysmobts, and trx.
Change-Id: Id9b222b7ab19ece90591718bc562b3a8c5e02023
Related: SYS#3212
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
It seems like some of the functions invoked by _sched_dl_burst()
do not sent nbits properly. This leads to a number of errors on
startup:
trx_if.c:593 Tx burst length 65535 invalid
It happens in conjunction with:
Transceiver.cpp:382:pushRadioVector: dumping STALE burst in TRX->USRP interface
Let's fix this by initializing nbits to 0 to make sure those bursts
are properly ignored.
Change-Id: Iaf85826861163c185925de528c8347ab22779e30
This adds printing of remote RTP IP/Port, LAPDm SAPI information,
MS Timing offset, propagation delay, encryption algorithm+state,
loopback status and radio link failure counter to the "show lchan"
command. It also adds TODO comments fro those bits that are not yet
printed but which would make sense to print.
Change-Id: Ic4bc47638b7b402aee9344dc912745a9929c37f4
This is more or less a 1:1 import from the BSC side commands. Having
the commands on the BTS side will allow us to expose information that's
not visible to the BSC [in upcoming, separate patches].
Change-Id: I2a596938849a9c84fe6fedcac5d7f71ee97af575
Commit 5eb17e28ac added this warning when
implementing the full function. However, other backends seem to be also
passing the primitive from the stack to l1sap_up without any visible issues.
Furthermore, according to the documentation of l1sap_up, it takes ownership of the
msgb, but doesn't take ownserhip of the prim itself.
Change-Id: I45fe40e3377eac999d1dac5356678195381d94ca
This warning was included in commit
6d7b78bde1 from 2011, and nowadays I only
see this command used in osmo-bts, so I think we most probably drop it
as it doesn't make sense anymore.
Change-Id: Ie277dce00292c8f403b9a2b405efe4429e6af86a
It is required for bts_shutdown used in trx_fn_timer_cb, and compiler
warns about implicit declaration.
Change-Id: I274662cd657ce8c36ed1d262d138590808bfafea
The function rsl_tx_mode_modif_nack() uses abis_bts_rsl_sendmsg().
This function relys on msg->trx to be set (see abis.c). However,
rsl_tx_mode_modif_nack() creates the message buffer, but does
not set msg->trx.
- Make sure that msg->trx is set properly
Change-Id: Ib5990db11df1b25dc5d321193731426b11f8005a
When the RSL_IE_CHAN_MODE is is missing, then the message buffer
is freed and the channel mode modify is nacked using
return rsl_tx_mode_modif_nack()
The function rsl_tx_mode_modif_nack uses abis_bts_rsl_sendmsg()
which returns 0 on success. This eventually leads into a double-
free in rsl_rx_dchan() which frees the message buffer on all
return codes except 1.
- Remove the excess msgb_free() in the error handling path.
Change-Id: I946a927ba35aa115520b1248eefccd91832f69f6
The independent copy of pcuif_proto.h file is used by OsmoBTS so we
don't have to checkout OsmoPCU to obtain it.
Change-Id: If8d7330adf3edc44c3b49b1f6e854cce0eca2d8e
The sysmoBTS-specific headers were never looked for in the current
directory. None of the CI tests use it as well. None of the other BTS
models use such defaults. Let's just drop this to restore expected
header location semantics.
Change-Id: I0b2906e284e1e22a960c4f0f1f38724de009eda5
Previouslywe could end-up passing empty '-I' to compilerif corresponding
_INCDIR variable was not defined during the ./configure step. This is
apparently tolerated by gcc but still seems like a wrong thingto
do. Let's fix this by moving -I inside of *_INCDIR.
Change-Id: I80915e5756d1bf64d789cfd5341fdd417ca8eed9
When testing for sbts2050_header.h during ./configure stage, use proper
include path defined earlier.
Change-Id: I55e50f612ab2a082b34096d71359dd08da150cf1
When testing for the presence of particular BTS model-specific header
during ./configure step, we don't need to add LIBOSMOCORE_CFLAGS because
none of those headers use it for compilation. Moreover, adding it might
hide the problem if the headers under check are available in the same
location where libosmocore headers were checked out.
Change-Id: I64bf1acb9db999567e8a2a6690cfc96d6e4b7ee1
It was detected that under some conditions, osmo-trx (with limesdr)
may take a long time to answer to CMDs, which means trx_ctrl_timer will
trigger re-transmitting the last sent but yet unacked CMD. Due to the
high latency in osmo-trx, the original AND the rentrasnmited CMD are
handled after a while and RSP messages are sent for both. When
osmo-bts-trx receives the first RSP, it was marking the CMD as acked and
carried on with next one. Then, when the RSP from the retransmited CMD
arrives, it already lost state and doesn't know where does that come
from. As a result, osmo-bts-trx shutdowns.
The issue can be seen in the following truncated log from osmo-bts-trx
with TRX category enabled:
20180117135228175 Enqueuing TRX control command 'CMD RXTUNE 1782000'
20180117135228175 Enqueuing TRX control command 'CMD TXTUNE 1877000'
20180117135228175 Enqueuing TRX control command 'CMD SETTSC 7'
20180117135228175 Enqueuing TRX control command 'CMD POWERON'
20180117135228175 Enqueuing TRX control command 'CMD SETRXGAIN 1'
20180117135228175 Enqueuing TRX control command 'CMD SETPOWER 20'
20180117135228175 Enqueuing TRX control command 'CMD SETSLOT 0 5'
...
20180117135249829 Response message: 'RSP POWEROFF 0'
20180117135249855 Response message: 'RSP RXTUNE 0 1782000'
20180117135249876 Response message: 'RSP TXTUNE 0 1877000'
20180117135249876 Response message: 'RSP SETTSC 0 7'
20180117135250648 Response message: 'RSP POWERON 0'
20180117135251150 Response message: 'RSP SETRXGAIN 0 0'
20180117135253151 No response from transceiver for phy0.0 (CMD SETPOWER 20)
20180117135253777 Response message: 'RSP SETPOWER 0 20'
20180117135254535 Clock indication: fn=2018878
20180117135255777 No response from transceiver for phy0.0 (CMD SETSLOT 0 5)
...
20180117135256858 Response message: 'RSP SETPOWER 0 20'
20180117135256858 Discarding duplicated RSP from old CMD 'RSP SETPOWER 0 20'
20180117135256858 Response message: 'RSP SETSLOT 0 0 5'
20180117135256858 Response message: 'RSP SETSLOT 0 0 5'
20180117135256858 Discarding duplicated RSP from old CMD 'RSP SETSLOT 0 0 5'
Change-Id: I3633cba212edde878f83ed36aef922aaca6f503a
First the cached CMD sent (struct trx_ctrl_msg) is reworked to have the
cmdname and the params in different buffers for easier comparison with
RSP later.
For the receive path (trx_ctrl_read_cb), new function helpers are added
to parse the buffer into cmdname+params+code (parse_rsp) and to compare
if a given RSP matches the current CMD we sent (cmd_matches_rsp).
The reasoning behind this patch is that a way to check for parameters
when receiving a RSP will be needed in future work, as before this patch
checking of parameters is ignored. This commit is a preparation for commit
to check for duplicated responses.
Change-Id: I2474cbc3e4457cf04f78e1c168768295e1132034
The move includes a small logic change: If there's a mismatch between
the rsp and the cmd, now we bts_shutdown instead of blindly skipping
expected RSP and continuing with sending the next CMD in the queue. The
change is specially not a problem since next patches are improving the
logic furthermore to account for duplicates, different parameters, etc.
Change-Id: I7018ded23fe51f364f248ade111aaa80ef46187e
The default (for both manual and .deb builds) is to use shared build (as
before) - the static build is entirely optional.
Change-Id: Iabdebefef5c07dd1cd4b94b29ca40c6be0f8adda
Add missing LIBOSMOABIS_CFLAGS and LIBOSMOTRAU_CFLAGS.
Pair the _LIBS below the _CFLAGS in LDADD above (cosmetic).
Fixes the stow-enabled jenkins builds are currently failing like below:
In file included from ../../include/osmo-bts/gsm_data.h:136:0,
from ../../include/osmo-bts/bts.h:4,
from misc_test.c:23:
../../include/osmo-bts/gsm_data_shared.h:21:35: fatal error: osmocom/abis/e1_input.h: No such file or directory
#include <osmocom/abis/e1_input.h>
Change-Id: I94ea8bad8b410550f72ee6a0408f42f6bd8b6cac
Add configure option --with-sysmobts=$INCDIR (like for LC1.5).
Use to fix the jenkins build to fix the build after migration to stow, where we
can no longer use a commin -I to include the sysmobts headers as well.
Tweaked-by: neels
Change-Id: I0416a9f4c428189cd9c3909c8bd016ca2908128a
Passing configure flags in DISTCHECK_CONFIGURE_FLAGS requires enclosing all
flags in quotes. Currently we seem to have no callers with more than one
configure flag, so we were lucky not to break there.
Change-Id: I37bc517a30d00c744eddc8565a0a8181cb3b2cdb
It's prerequisite for jenkins tests fix after migration to stow. The
sysmobts-calib uses hand-coded Makefile instead of automake which makes
it hard to properly propagate build flags. Also, make it optional to
enable excluding it from certain jenkins tests.
Change-Id: I3b54bfa5ef1d89092f6cf13dc27de10874b31b18
The unittest module meas_test.c contains a lot of unused header
files as the result of a cut and paste error made earlier. Also
the reference to stdio.h is missing.
remove all header file references that are not needed.
add missing header reference to stdio.h
Change-Id: I167be096ed25a86b1114de1ada955822a0b42856
In oml_ipa_mo_set_attr_cell, as well as we do in other set functions in
the same file, we want to store a parsed value from a TLV received on
the network into a host local structure. We hence need to use ntohs
instead of htons.
Change-Id: Icbf65f8a4b871b0fa2e84ad6cd2188d4e34f704b
The function trx_by_l1h() is used to fetch the pointer to a an
osmo_bts_trx from a list. The ID that is used to reference the
transceiver comes from the incoming message. If the firmware
sends odd identifiers (firmware bugs, damaged packets) the
transceiver can not be found in the list and a nullpointer is
returned, which then leads into a nullpointer derefernece
problem.
Check the returncode, and depending on the situation either
return with -EINVAL or exit osmo-bts immediately.
Change-Id: I04ef3b4896e1322c2a6d29ea86a88994c7748bf7
Wireshark was showing a Malformed packet alert, and further
ivnestigation showed that "Resource Information" TLV was missing in the
packet. See GSM 08.58 sections 8.6.1 and 9.3.21 for more information.
Indicating interference level is not yet implemented, but at least now
we avoid sending a malformed packet.
Patch has been validated against a running setup with wireshark in my local PC.
Related: OS#2735
Change-Id: Ie97170811aaf8a089febfa20380ab48ea174056a
While debugging other protocol/timing issues between osmobts-trx and osmo-trx,
I found that sometimes two consecutives "POWER OFF" commands are
enqueued and sent to osmo-trx.
There's no point in doing so, as the write queue already maintains state
and retries the command until a RSP is received, then goes for the next
one.
With this change we hence improve timing response as we don't need to
wait for the second command to be processed, and on top we get cleaner
logs and simplified states which are easier to debug.
Change-Id: Ib6a5e7bfac8bc5e1b372da6a1f801c07a3d5ebb7
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
The upper layers (L1SAP, the common part of L1) *always* require frame
numbers in the uplink direction to be reported as the frame number of
the *first* burst, not the last burst of a given block.
This is particularly important in the case of passing up measurement
information, as we use this frame number to detect if the measurement
interval for that specific timeslot has just ended (and hence we must
process the measurements and send an uplink measurement report to the
BSC.
Before this patch, the measurement results were reported with the *last*
frame number, which caused the common/measurement.c code never detect
the end of a measurement window.
On TS2, tons of the following log messages were observed:
<0004> measurement.c:199 (bts=0,trx=0,ts=2,ss=0) no space for uplink measurement, num_ul_meas=104
With this patch, it behves as expected: the measurements of 25 blocks
(= 100 bursts) are aggregated, after which point the report is computed
and sent. Subsequently, num_ul_meas is reset to 0 and the cycle
restarts.
Related: OS#2329
Change-Id: I1065ae9c400bb5240a63ab8213aee59aeb9ceeff
The RTCP Sender Description is supposed to contain useful information
to identify the source of the RTP stream. So far, it only contained
compile-time default data of libortp. Let's put the BTS UnitID, the
lchan number and the OsmoBTS version in there.
This change requires libosmo-abis Change-Id Ice794f9e0c6caeea1c67520c12efbfa375d1fb82
Change-Id: Id6ce7188354d3a0517661c9648854ec829ef1cac
Related: OS#2701
The respective errors/events occur as a result of calling osmo_rtp_*
API, and are clearly more fitting into the DRTP category than the DRSL,
even though the respective actions are triggered by RSL.
Change-Id: I52e6f9865492a2f757a37860eb92a3dc49e174ef
Contrary to osmo-bts-sysmo, the OCTPHY-2G does not have different L1
SAPI for AGCH and PCH. It uses cOCTVC1_GSM_SAPI_ENUM_PCH_AGCH for both,
and we convert that to the cbits=0x12 (Downlink CCCH) on the L1SAP.
The code above L1SAP can hence freely decide if it wants to respond with
an AGCH or PCH message, based on its knowledge of BS_AG_BLKS_RES,
without the OCTPHY specific code having to do anything about it.
Hence, there's nothing to do, and the warning can be removed
Change-Id: Ic1038b8dc57bdaf05493cd8479355b960275ea41
Related: OS#1575
There's no point in either having full verbosity in DEBUG level
and not logging any measurement related information in INFO. Let's
at least print the results at the end of each measurement period in INFO
level.
Change-Id: I2c870531478c05ce31cc1015597a068a4a76cf99
Almost all log statements in scheduler_trx.c were using the wrong
logging subsystem. Let's fix this. Also, make it more obvious from
the log subsystem help text
Change-Id: I4312f8ab0414eb38db0d62f05c95ab961f500c14
Despite the CalypsoBTS transceiver is similar to OsmoTRX, there
are some changes required to make it work with OsmoBTS. Let's
add a new configuration example for that.
Change-Id: Ia4b1797de576ab987b05046aa9a9828858023ed3
It seems like rx previously had 'float' type. Remove the comments and
checks which are not relevant since rx is 'int'.
Change-Id: Idb4aad53667f88f9656c5bb1c52e7e75b385f446
Fixes: OS#2223
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 osmo-bts detects a mismatch between the firmware of the DSP
and the header version which it was compile with, a hard exit
is performed. In some cases this may hinder debugging/testing things.
Implement a commandline option to intentinally override the check.
Change-Id: I5774fbb29da832786326afb991014b9bd8b04b59
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
In trx_clk_read_cb(), when calling phy_instance_by_num(), that
function might in error cases return a NULL phy-instance. Let's
put an OSMO_ASSERT() there as safeguard to avoid NULL dereference
when dereferencing pinst->trx->bts.
Fixes: Coverity CID#178657
Change-Id: If6b6b45380368e9ee9e03ca1eb7ac56c21e72b03
In rx_tchf_fn(), if gsm0503_tch_fr_decode() returns a negative
result, we cannot use that result as length argument to
osmo_fr_check_sid()
Change-Id: Ic4080b5bf6c865be3333f923f19a2340e1e272c8
Fixes: Coverity CID#178659
We unconditionally pass "p+1" into sscanf() despite not knowing
if 'p' is NULL or not.
Change-Id: I40a49c3feb3b55ef577eebd7d567afdbcfe0d624
Fixes: Coverity CID#178661
There's a lot of pointer arithmetic in trx_ctrl_read_cb which is
not so nice. While I believe the current code is safe, Coverity
raises "CID 178665: Insecure data handling (INTEGER_OVERFLOW)"
regardin the use of rsp_len in the strcmp().
Let's put some OSMO_ASSERT() in front and hope that makes Coverity
happy.
Change-Id: I5a9b3307f83cdde7c8e9f66932446604f5623b05
I was unable to start osmo-bts-lc15 with this config file until this
change was made, it said this command didn't exist.
Change-Id: Iae80e2ed504b5e26d748d57be7558ce470555f97
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I5e8e9d7989ee20fe722bdd3109965d5bce9519fb
This marks a new release that's compatible with libosmocore >= 0.10.0,
and which no longer depends on openbsc-dev.
Change-Id: I67405cb5f0f4dea85c67febfdef80f49ae1d41a6
We've had openbsc.org ages ago but have moved everything to osmocom.org
at some point in 2010/2011. This should have been updated back then
Change-Id: I5da8e9fba8f15719414fa81e2a6211f906329c2e
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I830b17462b636e0bf03f4d88000660409503c3e5
We can either try to really build with those old versions or find the
minimum version, or we can simply require latest version of all
libosmo*, which is the safeest choice for now.
Change-Id: I08915540b92d5135b0c325e30b5b6e24f88e6282
Since libosmocore Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2
we enforce that FSM names do not contain illegal characteers such as
spaces. Let's change the DL TX FSM for AMR to comply to this. Also,
actually do check the result of the FSM registration.
Change-Id: Ieccd1dc32c0faf5e544d17daca4a417d1d168c21
Power control loop test outputs next to nothing which is not very
helpful. Make it more verbose. While at it, also move duplicated code
into static function to make test cases less cluttered.
Change-Id: I0a5e65e23e62442ef8758ecbcf8e7820b4f15d7b
Related: OS#2223
There's nothing sysmobts specific in this test so let's move it into
separate directory and run unconditionally. The test itself is unaltered
except for intro text.
Change-Id: I0d1957cd9cf5497826be095c7a42b7bb4fa10397
Related: OS#2223
Previously it could be possible that the attribute request comes from
BSC before the TRX is properly initialized which would lead to SIGABRT
caused by OSMO_ASSERT() in PHY instantiation. Workaround this by
explicitly checking for TRX availability before handling TRX-specific
attributes.
This only happens with osmo-bts-trx and is hard to reproduce. Ideal fix
would be to defer attribute response until we have TRX connected but
that would make corresponding code more complex because we'll need to
save the attribute request and properly hook response routine into TRX
connection handler. Alternatively we can postpone osmo-bts-trx
connection to BSC until TRX is available: it's not very useful without
it anyway.
Change-Id: Id36885e507c4a3203b5662c0fde12c5206174d82
Fixes: OS#2560
On 'write file':
- Write 'osmotrx' before 'maxdly' and 'maxdlynb' (broken since "Introduce new
phy_link and phy_instance abstraction"
d784e50747)
- Fix indenting of 'write file' output, command 'osmotrx timing-advance-loop',
had a stray space in case there is not a 'no' preceding it.
Add some missing instances of OSMOTRX_STR doc strings.
examples/osmo-bts.cfg:
- Drop 'settsc', the command no longer exists.
- Fix indenting of 'osmotrx rx-gain' command.
osmo-bts does not feature VTY tests, so it is pointless to add example files to
test these fixes. We should probably add VTY tests separately. However, I have
briefly tested manually (and hence found all of these issues).
Change-Id: I018eaef40345bfa26e12eb7d09e83a52596c1000
Previously clock source configured via vty was ignored. Check that it
wasn't configured and only apply default value in that case.
Change-Id: I8de74a12d2096971a8a83946dc6c7cdb9889acd7
Fixes: OS#1944
Make get_clk_cal() public and use it for ctrl commands handling. This
ensures that the calibration is properly selected depending on the clock
source.
Change-Id: I1c809d48f29ef8e8c50641f882d7a954dfcf88f9
Related: OS#1944
The dependency on OpenBSC has been removed in
ec33b0397f so we can drop it from jenkins
scripts too.
Change-Id: Ie28d444f2154f5b4bbbd9a1cb45b74ebca890cb1
Previously the received SI was copied to si_buf unconditionally which
means that the first SI2q message is always overwritten be the last one.
Fix it moving check for SI2q ahead of generic code and moving generic
copy into else branch of SI2q check.
Change-Id: Ib8031d2f0e00368283a40b4aadb3eea616038d04
Related: OS#2357
* copy-paste gsm_data_shared.* from OpenBSC master
* remove corresponding configure check and option
* remove .deb dependency
Actual refactoring with removal of unnecessary structures/parts, moving
common OpenBSC/OsmoBSC parts into libraries etc. are left for further
patches.
Current patch will make coexistence with *BSC easier and will simplify
our build infrastructure.
Change-Id: I9f004fb5c4c1db29d4792dfd281d388c7063da13
Related: OS#1923
When printing BTS via 'show bts ..' let's also print each TRX, which phy
number and version it uses and its description. It's helpful in
troubleshooting low-level issues as it allows vendor-specific code to
easily expose firmware version.
Related: SYS#3884
Change-Id: Iabcc862566b40a9314f3e1d17fda61d8ab24a3cd
* remove leftover from copy-paste of corresponding OpenBSC code
* print OML link state
* print paging load
Change-Id: Ia5e3dc10efe2b5ab212cab1518a10d36b20b8bb2
We re-use the same facility to send different data so it's better to
print actual cause value to avoid confusion.
Change-Id: I9413ecf57eaa6fc661f1a57ccdaa2f04c50ea43b
Previously result of readv() was used unconditionally so when it failed
and returned negative value it was treated like very large positive
which lead to memory corruption. Fix this and add proper error log.
Change-Id: I956c8d551f45c9dd43b5e9de11dfe20dd8783647
Related: SYS#3865
* do not deactivate lchan when called with LCHAN_REL_ACT_REACT
* add fixme comment
It's unclear yet if any special steps are required for osmo-bts-trx so
let's just make it compatible with setups [1] using BS_AG_BLKS_RES != 1
for now.
Background: CCCH is auto activated by some OsmoBTS - before we receive
SI3, see 4a85828462. To accommodate for
that we deactivate CCCH in common/rsl.c, which triggers BTS-model
specific callback sapi_deactivate_cb() which updates parameters and
activates it again.
In case of osmo-bts-trx there is no auto-activation and (seems to be) no
need in special interaction with hw to activate channel (no
lchan_activate()) hence we can just skip entire
deactivate/setup/activate again routine.
[1] "channel-descrption bs-ag-blks-res N" in OpenBSC config file.
Related: OS#1575
Change-Id: I20b89ba1e43d1414180b083cd1e085eeffe5d513
If SI13 becomes unavailable in runtime than send 0-length message with
BCCH SAPI to PCU to indicate that SI13 have to be removed.
Change-Id: I72aef8bd98f21c4b5ea6eed21fc56b30d85bfc1b
Related: OS#2400
* 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
Original OpenBTS transcievers add 2 bytes of padding to the end of data
bursts, having in total 158 bytes. As those two extra bytes are being
ignored after the initial validation, let's relax this validation a bit
in order to accept transcievers that decide no to send these two extra
bytes.
Change-Id: I94c3cb160bfed0ba9c41ed7ef5f8d8a65b81ad07
* move TA related globals into phy_link
* move power loop related globals into phy_link
* prefix corresponding vty vars with osmotrx
Change-Id: I01d7c1abad67e51b886a4ecf2de072929d67da27
Related: OS#1848
Use Obj. Class and TRX# from abis_om_fom_hdr of incoming request instead
of BTS' MO to properly distinguish between BTS-level and TRX-level
attributes.
Change-Id: I8b5a5ab8bd07daf2500b66dec428b89b7f8cd852
Related: OS#2317
New libosmocore has some plugin system which requires dlopen(). So we need
to make sure we always link with libdl, even when building statically.
Note that this doesn't fix static build of tests - they are still failing
with some errors.
Change-Id: I8315d6e032e34528def268a49fd88d07bc06ab2e
When somebody kills the process, it's best to handle the signal
and to use the opportunity for some cleanup. We always did this
in the BTS on SIGINT, but never on SIGTERM. Let's change it.
Change-Id: I10009c08b7178988f646e2b6035197b9640ac9b5
We tend to start MS with high power to make sure distant phones get good QoS,
but this also means that we need to reduce their power rather quickly. OTOH
we can't make this step too high because this may lead to power output
oscillation. From my (manual, limited) testing 4dB looks like a reasonable
compromise.
Change-Id: I58785513e5739474b881ed7f2a312ecc690e7e60
The following two commits from 2014-12-06 introduced a new variable to control
MS power - ms_power_ctrl, but kept the old ms_power variable in place. They
have also changed the meaning of the ms_power variable - it now keeps original
RSL configured value. So when much later osmo-trx-bts code was merged to master
the code was compiling fine and this change in the meaning was overlooked.
In osmo-bts:
579651bf30 power/sysmobts: Add a manual ms power level control
In OpenBSC:
f6f86b0eec18da165db136b14bf2db87fde4b4ac osmo-bts: Introduce new struct for a power loop in the BTS code
Change-Id: I713e39b882db32a0d17aa04790d16fa79afa1fb1
* move duplicated code into separate functions in jenkins_common.sh
* use that function in individual builds
Change-Id: I4d09c5f2693b5ac0a4d8f2c840971e13d1ec58cf
Implement API functions bts_model_ts_connect() and
bts_model_ts_disconnect() in order to support dynamic timeslot
allocation.
Change-Id: Ia109d4bfade7bc28442127581f4bb0289146ea71
There are currently two ways to specify power reductions to be sent to
osmo-trx from osmo-bts-trx:
* osmotrx tx-attenuation oml
* osmotrx tx-attenuation <0-50>
None of them is enabled by default, which means if none of them is
specified in the config file of osmo-bts-trx, SETPOWER cmd won't be sent
to osmo-trx, which in turn won't turn on the transciever.
Let's enable osmo tx-attenuation oml by default and leave it up to the
bsc to decide which power reduction to use. If the user wants to
configure a specific tx-attentuation, it can still do so in exactly the
same way he used to do it.
Change-Id: Ia8640751630ee37e5f5d1f470bad892a08e80654
In openbsc.git Change-Id I61c18a7f021fcb1ec00d34a745f4e3ab03416c2d
we changed the gsm_bts_alloc() function signature to include
a second argument (the BTS number). This broke omso-bts, and this
commit is intended to make it build again.
Change-Id: I7ef7654d48c1cfc7e4ecb0b771553ec0740ce2bf
Whether or not we are talking to an OpenBTS (SETBSIC) or OsmoTRX
(SETTSC) transceiver is a property of the phy_link, and not a property
of the BTS. Also, we *really, really* should never use global
variables. I'm very happy this is being cleaned up, finally.
Change-Id: I51aeb17661dfd63ff347f7b2c0d7ffa383ec814c
Those global variable declarations for non-existing variables were
introduced in 8a8d73a691, let's remove
them again. The source / destination IP address is a parameter of the
phy_link, and not a global variable.
Related: OS#1848
Change-Id: I94b5f934fc3bd00b0467d90029d3053b16594186
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
service sets led to orange before/while osmo-bts is being started.
osmo-bts-lc15 sets led to green while operating. (unchanged in here)
service sets led to red when osmo-bts stops running.
Change-Id: If351f49d1ead359192d0d80bbc381afd3459c940
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
In bts_model_l1sap_down() we want to identify BCCH/CCCH channel numbers,
but our check is a bit non-specific. Let's make the check more specific
to only cover the BCCH, Uplink CCCH and Downlink CCCH C-bits as defined
n 3GPP TS 08.58 Section 9.3.1
Change-Id: Ia20ab09b96c87c0dfbfaf98e5b2a8d36423fac67
There are plenty of functions stubbed out in osmo-bts-virtual, let's
print a NOTICE level log message to be able to correlate any kind of
erroneous behavior with the fact that a given function has no actual
implementation.
Change-Id: Ib607d192f90af7fb2d5a8747de5527f39e3cfefa
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit:
* adjust comments to simplify further diffs
* add libsystemd dependency to lc15bts-mgr
* add software watchdog which uses it
* ocxo calibration and gps related code
Change-Id: I475a330af771891ba3c897294ce0dd57ec2ba8db
Related: SYS#3732
The sysmobts- and lc15bts- mgr have different semantics for the same
command line option (-n: writing to EEPROM vs writing to ROM). and
different default value. Hence it make sense to use separate files,
similar to osmo-bts-*.service
Change-Id: I645a81e30d7146ff26720391db763b6d585037e6
Related: SYS#3728
In a larger simulated network with multiple BTSs it is normal that one
BTS will see GSMTAP frames for an ARFCN that is not an ARFCN used by the
local BTS. This is just normal operation.
Change-Id: Ic68cace9648ccb17500c94b6ede8814674aa9c29
That's mostly changes related to lc15bts-mgr from
https://gitlab.com/nrw_noa/osmo-bts branch nrw/litecell15 based on
eb5b7f80510b603579f7af6d7d5ead296c2fa260 commit.
I wanted to incorporate vty and hardcoded paths changes so we can use it
from this point without major backward-incompatible changes as a base
for future ports.
Change-Id: Iabbaedc84aaaa594150a4e5445c16dd1f6f89858
Related: SYS#3679
* move common code into separate function
* print error similar to parameter reading code
Change-Id: Icf3285d7bb921d212cb8945e835be2c81189fb87
Related: SYS#3728
Recent introduction of VIRT-PHY broke .deb build. Fix it by installing
osmo-bts-virtual as part of Debian package.
Change-Id: I1ca7eb51019247eb95c6bac752d6e2c4406ce5a2
When no SI 2bis, nor 2ter, nor 2quater is in use, then the code in
bts_sysinfo_get() will return null, causing the transmission of a dummy
frame (0303012B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B2B) instead of a
system information message. This is - at least - very odd and might not
be backed by the specification. We should simply send any other system
information message instead of sending a frame that does not have a
valid SI header.
While 030301 might be a valid, empty UI frame on a DCCH, it is not a
valid frame for the BCCH, where the header is structured differently.
In fact, bts_sysinfo_get() should never return NULL and always return a
valid BCCH message.
This bug was found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn
Change-Id: Ifeaed27d1d7ba9994fb8ce67d660648bcc8efece
Closes: OS#2365
It is important that we reliably terminate the BTS in case any of the
VirtPHY multicast sockets dies for whatever reason.
Change-Id: I5ae3fdd7cc35fdf235550a3b8362020fdd287c13
The addresses in the original code make little sense:
* 224.0.0.1 is "All systems on this subnet" and not routed
outside the local ethernet segment
* 225.0.0.1 is in a RESERVED range that shouldn't be used
Change-Id: Iba1ae69f3f193a33f1da343c6562f67bd8d3557f
Frame number will restart at 0 after each superframe (approx. 6.1 sec)
if enabled. Can be enabled by preprocessor define.
Change-Id: If3adf14df5fcd8daf53363c27b3772c42d7122e9
The defaults must be set during bts_model_phy_link_set_defaults()
and can then later be overridden by the vty (from the config file).
They should only be written back to the file if they differ from
the default settings.
Change-Id: I5d7f2c1dc8bc3d11db5c607b664730e4dcd58c96
Timeslot is not encoded in the chan_nr accessible in the channel
description but was taken from there and so it was always 0.
Change-Id: I881a1c61ea47399c9b1385fb220cd587e3593e82
This patch adds a virtual physical layer designed to simulate the
Um air interface between BTS and MS. It does so by encapsulating MAC
blocks (Layer 2 PDUs) via GSMTAP and sending them through multicast UDP
streams, both in uplink and in downlink.
The purpose of this is enable testing without any radio hardware or
related licenses.
OsmocomBB has recently received as similar patch-set, adding a virty_phy
executable that can be run on a PC instead of the classic 'layer1'
firmware on a real phone.
Using GSMTAP means that one can use unmodified wireshark to decode the
messages exchanged on the virtual Um layer.
This code was originally started by Harald in January 2016, continued
by Sebastian Stumpf in late 2016 and early 2017, and finally completed
by Harald in July 2017.
Change-Id: I1bf7670975b1e367c1c62983020865a043542622
The number of SI2quater messages might be updated dynamically by
BSC (via 'bts 0 resend-system-information' command for example). Log it
but do not return error.
Related: OS#2357
Change-Id: I9625be879c672e20543cc40af288828143ffb983
The octasic phy stamps the SACCH channel that carries the
measurmenet indication with the frame number of the last
SACCH that falls within the measurement period.
The higher layers expect the frame number to be aligned
to the SACCH channel after, which marks also the beginning
of the next measurement period.
Make the octphy code compatible to the higher layers by
remapping the measurement indication frame number.
Change-Id: I8ecb27c018bf4ad5151878a6ad34026fd0f801a1
The end of the measurement reporting period is not aligned with the
SACCH block where the results are reported. The tables that are
used to detect the end of the measurement period are therefore
wrong. The frame number of the SACCH block must be used and not the
TDMA frame number (modulo 104) of the measurement reporing interval.
The tables are oriented to the frame number of the first SACCH block,
at the beginning of an interval. However, when a SACCH block is received
it will always contain the result of the recently passed measurement
reporting period.
To match the tables, introduce another lookup table to remap each
SACCH block that ends to the matching beginning block number.
Change-Id: I1eef894e6f15b4449fc8926bebb118624efc7924
l1_if.c does not generate struct osmo_phsap_prim l1sap properly.
The frame number is not included in this struct. This renders the
logic that processes the reported measurements non functional,
since the logic (see measurement.c) is not able to detect the
end of the measurement period. This commit fixes the problem by
adding the missing frame number to the l1sap structure.
Change-Id: I09241d6cc2ff09e71a3d723d90e4468108a27ae1
We should print meaningful error messages in case a user doesn't have
the required local PATH set up, or doesn't specify a required command
line argument.
Change-Id: I30a2935f93ade69222b1e0c3e212ee10e17c1823
ph_data_req() and ph_tch_req() are generating empty (idle)
frames when no data (msg == NULL) is available. Since the
phy is able to generate idle frames internally, there is
no need to waste Host CPU cycles by doing this in software.
Remove the empty frame generation and exit the function
cleanly.
(Patch by Octasic Inc.)
Change-Id: Ib857b7dab490ad426c48d6a9e5e6fa10ef5a0838
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
The value string table octphy_cid_vals lacks the strings for
cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID and cOCTVC1_MAIN_MSG_APPLICATION_INFO_CID
(Patch by Octasic Inc.)
Change-Id: I9843137b55534a29938d5c2308244a6950de788f
For some reason, osmo-bts-trx attempted to interpret/validate the
contents of the downlink TCH block that it was about to transmit. If
such checks are made, they should clearly be in the common part above
L1SAP, and not in the bts-model specific part.
Also, having the checks in place didn't allow us to send an all-zero
downlink block, as is required for detection of uplink FER in a loopback
testing setup, e.g. with CMU-300.
Change-Id: I6388de98e4a7e20843a1be88a58bba8d2c9aa0d5
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
l1h is allocated in bts_model_phy_instance_set_defaults() and not in
trx_phy_inst_open(). Hence, trx_phy_inst_close() should not free() it!
Change-Id: I0ac4e57a882e5a31143499c1662d8d8e52320938
Related code / function structure still dates back to the pre-phy_link
days. Let's clean this up to make things less convoluted and reduce the
number of non-static symbols needed between code split over two files.
Change-Id: I1f30ae1f547a5c01c516d4a05032193294c25f2d
The new name makes it clear what the function actually does: Send burst
data via the trx interface.
Change-Id: I5031541d4ae4244a62a18acf71139db2874927fa
There ware some error conditions that the previous code didn't catch
and/or report, such as unparseable TRX control strings, non-terminated
buffers, ...
Change-Id: I354d0c121880553ce1bd59b7394d52b104b7d6da
The layer 1 interface (l1_if.c) for osmo-bts-litecell15 does not include
the frame number into the measurement indications it forwards
to higher layers. The frame number is required to properly
detect the end of a measurement period.
change process_meas_res() to properly include the frame number into the
l1sap primitive (struct osmo_phsap_prim *l1sap)
Change-Id: Iee9c8f88b05cd5dba9920bb08e079a643e713237
The layer 1 interface (l1_if.c) for osmo-bts-trx does not include
the frame number into the measurement indications it forwards
to higher layers. The frame number is required to properly
detect the end of a measurement period.
Change-Id: Ife3c791ff50e8a866a97b9783ac7ef3ef2402a70
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
using gettimeofday() is not suitable for the GSM frame timer, as it
relies on the normal 'wall clock' system time, which may be adjusted by
ntp, gps or other means at runtime.
Switching to a different clock source means we cannot use
osmo_timer_list anymore, but timerfd integrates just fine with our
libosmocore select() loop handling.
Change-Id: I51b19adde14ebb7ef3bb863d45e06243c323e22e
Closes: #2325
When handle_ph_data_ind() runs BER and RSSI is logged. Remove
this log output by removing the call to dump_meas_res
(Patch by Octasic Inc.)
Change-Id: I5e755465daa3daec2e2b4f61bc8d779c49196e9a
nmsg is initalized every time the function runs, even when it
is not needed. Move the initalization into the if (msg) body
so that nmsg is only initalized when we really need it.
(Patch by Octasic Inc.)
Change-Id: If51dc50a9f4bdb4aba62c0ae5fbfac552806f0c0
l1msg is initalized when the variable is declared. This means
the allocation always runs right on the beginning. Even when
the buffer is not needed at all.
do a prober l1msg initalization only when needed and check the
return code.
(Patch by Octasic Inc.)
Change-Id: Ia71d49b9cc109af53d997a687a7fb1b5ed062d1c
Printing the RX payload size is strictly informative, so the
loglevel LOGL_ERROR is wrong. This commit changes it to
LOGL_DEBUG
(Patch by Octasic Inc.)
Change-Id: I712cdd79cbba93f457705d38871bd8d4b7f4e897
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
That's resubmission of 340cff51f4 and
186c6bac07 with memory initialization
order change to fix the issue detected by osmo-gsm-tester - see OS#2338.
Change-Id: Ib595733cde108387bc7ee76b1b11ada6a235f13c
Related: OS#1660, OS#2338
The code that receives the uplink measurement data from L1 does not
print the number of already received uplink measurements. Since
this is a valuable information when debugging the log output will
now print this information as well.
(Patch by Octasic Inc.)
Change-Id: I79926f25de088571fcc2c14388c72fc968c2d382
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
We used to have trx_meas_check_compute() and call that from the
bts-specific code in order to iterate over all timeslots and all lchans
in the timeslots if we have to send measurement reports. This was
executed once per frame, and created unequal CPU load over time, which
in turn might increase different per-ts jitter.
Since 2f028c4e2c in April 2017 we have
lchan_meas_check_compute(), which performs this on a per-lchan basis,
and hence CPU load is distributed over all active timeslots.
Change-Id: I6308cefe4a51e55719ea4ed4d613d3782b805c08
This reverts commit 340cff51f4.
osmo-gsm-tester detected a regression due to this commit, when running
osmo-bts-trx. The modems timed out when waiting for them to register with the
osmo-bts-trx network. osmo-bts-sysmo is apparently not affected. No further
details on the failure cause are known yet. The failure is shown for example by
http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/868/
Change-Id: I15bca30ddc09a7a3044096626016f6130d07636c
This reverts commit 186c6bac07.
osmo-gsm-tester detected a regression due to commit
340cff51f4, which above commit apparently depends
on. Revert this along to avoid conflicts.
Change-Id: I456e9add788393ca781213cef31b5bc3d48fd531
* move code which checks for BTS number (obtained via OML) validity into
separate function
* adjust log messages to match the check
* add spec reference and comments
Change-Id: Id5714fbed910696d30e18d1f20f4c9fced4b9230
Related: OS#2317
This way the name of systemd service file will match the name of the
binary similar to lc15. Add aliases so the user can use both old and new
names regardless of which file is installed. Once the corresponding
changes to OE recipes are applied old file can be removed.
Based on work by Pau Espin Pedrol <pespin@sysmocom.de>
Change-Id: I08615eb625d488603aeb5962ad9f30869c0e77c5
Add jenkins build helper for lc15 and separate header with BTS-agnostic
functions.
Change-Id: Ib47f5a6cc88e784c5662b0dab4ddc03ce9a35132
Related: SYS#3682
Move value_string termination check and OpenBSC headers checkout into
shared jenkins helper from BTS' model-specific helpers to get rid of
copy-pasted code. While at it - also remove unnecessary bash
dependency.
Change-Id: Ic48b1f75179b9008d65219dd5a47c1ab3b886408
* use talloc for file path allocation
* print detailed error on failures
This simplifies troubleshooting of lc15bts-mgr failures.
Change-Id: I86c93a2a4f080e8ac1517be93f58f6ffd00d248c
Related: SYS#3686
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
Check for impossible index and count values of SI2q messages. The limit
is defined in 3GPP TS 44.018 Table 10.5.2.33b.1
Change-Id: I351f8e8641a1cb9548154803da70bfde46ee180d
Fixes: CID 170749
* change BCCH Info handler to explicitly support multiple SI2quater
messages sent from BSC
* change SI scheduler to send SI2q in round-robin way
Change-Id: I3aeb90804edab1b0325c3eb7347526ae995dbf51
Related: OS#1660
* use GSM_BTS_HAS_SI() from OpenBSC instead of local copy
* arrange GSM_BTS_HAS_SI() checks to improve readability
* constify SI scheduler parameters
Change-Id: If74bc536fe7d2bfbc976c07d882151873ecda4f2
Related: OS#1660
Set (possibly incomplete) list of BTS model-specific features and report
them in response to attribute request via OML.
Change-Id: I5f8a6681c3562ec261441e84dde6e085b516d92f
Related: OS#1614
* detect if attributes are requested for BTS or TRX and act accordingly
* report TRX phy version
Change-Id: I9f72305bbf1ab74745bffac1bee9f539f5a6de32
Related: OS#1614
* copy sysmobts-mgr.cfg to sysmo/ directory
* add lc15bts-mgr.cfg
The configuration is BTS-specific so it should be located inside
appropriate subdirs.
Note: the old copy of sysmobts-mgr.cfg can be removed once the image
build recipes are adjusted.
Change-Id: Ic81197464809ba508b2572e86dd978a994f4b116
Related: SYS#3686
Use systemd template specifier for config name instead of hardcoding
it. This will allow to specify different config file name depending on
the name of the service file.
By default sysmobts-mgr.cfg will be used preserving compatibilty with
existing installations but if the unit is named lc15bts-mgr.service than
lc15bts-mgr.cfg will be used. This gives us necessary flexibility to use
BTS-specific configuration.
Change-Id: I475df6a06691390120eea0bd8a61fa469df2bd2d
Related: SYS#3686
The debug log does not print much information about the measured
rxlev and rxqual values. This commit adds debug output to make
measurement debugging simpler
Change-Id: Ic871eed6dcbc7d10aca6cd11dbc803b3e6da449f
The higher layers relay on a normalized version of frame number
in order to detect the end of a measurement period.
The frame number on which the measurement reports are sent may
depend on the phy, so we need to normalize the frame number
before we report it to the higher layers.
Change-Id: I90bd01479e41f04a6b0aefe3845d071e3148d0c6
The offsets used in the lookup tables may be phy dependand. So we
will have to do the alignment in the layer 1 interface of the
phy dependand code before we report the frame number up to the
higher layers.
This reverts commit e0fb3ae52d.
Change-Id: I8acab50cc1bb1cb133831c6a145f4d790e99176c
The priv pointer of the callback function app_info_compl_cb() is
set to null by the pointer. It should be set to pinst instead.
Besides of that there is a memory violation while accessing
the local variable ver_hdr using osmo_strlcpy(). Both is fixed
with this commit.
Change-Id: I558d78ef29e9a4d8f45f4142611f11289d3ed806
This is resubmission of 9eeb0b1a13 with
errorneous use of talloc_asprintf() removed which should fix OS#2316.
Change-Id: I02ae6fffdc808c1ea14185dbb4a720d27a62d4bb
Related: OS#1614
Timing advance is currently not taken into account when computing
the measurement results, this commit fixes that
Change-Id: I2e0dfd13b53e8aa2822985f12bf2985e683ab553
This reverts commit 9eeb0b1a13.
This commit caused osmo-gsm-tester test runs for the sysmoBTS to fail with
SIGABRT consistently. See below redmine issues.
In osmo-bts-sysmo/l1_if.c, it uses talloc_asprintf to write to the char
version[MAX_VERSION_LENGTH]; talloc_asprintf() however is intended to work on
string buffers allocated by talloc, and attempts to reallocate version[].
Furthermore, it is not clear why the patch passes a 'data' arg to
app_info_sys_compl_cb() that is not used.
Hence I will revert this instead of trying to fix. Please resolve issues and
re-submit.
Related: OS#2316 OS#1614
Change-Id: I2c9fd5e6739c1750365c0241476ce4b1aa2df3d4
The so-called "RTP mode" of the DSP contains a bug on all firmware
versions < 5.3.3 which causes the bit-order within each of the
non-aligned codec parameters to be wrong. Introduce a function
originally written by Sylvain Munaut during 32C3 in
http://git.osmocom.org/openbsc/commit/?h=sylvain/32c3_codec&id=5b4a16bbe93a7b1ace65cc23d6cce56ecf4f1275
to bring the bits into [the correct] order.
This has never been seen in a "pure sysmoBTS" setup, as all BTSs would
use the same (wrong) bit-ordering and thus interoperate. This patch now
checks for an affected DSP firmware version and then jumbles (old DSP
firmware version) or does nothing (new DSP firmware version).
Change-Id: Ia0eee4f514fb8fd81c052bb44a4facba898d6afb
Closes: SYS#2452
OsmoBTS won't run without being connected to a BSC. The BTS wouldn't
start to transmit if the BSC doesn't properly initialize it. So if we
want to activate some channels manually for testing, we should do so
from the BSC, and not inside the BTS code. Doing this in the BTS means
that the BSC is not aware of it and might want to use that channel for
something else meanwhile.
Osmo{BSC,NITB} has gained ability to manually activate a channel from
the VTY in Change-Id I44fc3904678eb48bd3ab1a3da8c0c265fa082e0d as can be
seen at https://gerrit.osmocom.org/2759
So let's remove the old/obsoleted code here.
Change-Id: I7ba0301b55cc283aa6a441899f84357e28a97321
For some reason, osmo-bts-trx did another take at parsing
NM_ATT_CONN_FAIL_CRIT and storing the second octet in
btsb->radio_link_timeout, just like the generic code already does in
oml_rx_set_bts_attr(), but without proper checking and any error
message. Let's remove it.
Change-Id: Idb0179e1443c0b5a97e59919dba684a001e90192
Make more use of TLVP_PRES_LEN() instead of plain TLVP_PRESENT() and
implicitly assuming a certain length of the information element.
What this obviously doesn't introduce is some kind of error
generation/reporting in case the minimum length is not fulfilled. An IE
that's too small is silently ignored by TLVP_PRES_LEN() and treated as
if the IE wouldn't exist in the first place.
Change-Id: If5c4eee65711c49bc8ba4675221b1d5fd16198e9
l1_if.c does not generate struct osmo_phsap_prim l1sap properly.
The (logical) frame number is not included in this struct. This
renders the logic that processes the reported measurements non
functional, since the logic (see measurement.c) is no longer
able to detect the end of the measurement period.
This commit fixes the problem by adding the missing frame number
to the l1sap structure.
Change-Id: I2bab40c30d727395eb3096026810917407419cd7
Event handling is done internally in the Octasic BTS. When the TRX is opened,
events are enabled automatically and when TRX is closed events are disabled.
The change is valid for the recent firmware version and for the last couple
of previous releases.
Change-Id: I0652627495f6a9bcb0da2431b8beb839bc22062b
recent octphy firmware versions do support proper channel measurement handling.
The new implementation replaces the old, and for osmo-bts non functional
implementation.
This commit introduces the necessary adjustments. Older firmeware releses will
still work. However, the measurement computation results will still be wrong.
Change-Id: I0f053bb10b1cb112a8814ee591969d607888e686
instead, let's introduce a specific function for that. Also, as this
can be easily determined from the frame number, skip one argument to
tx_tch_common().
Change-Id: Ibbb9b685cf0b6a45339b0874438a500dd6254bc2
gsm0503_conv.c should have been removed as part of
efbef50efc but somehow was left here. It's
not referenced/compiled by the Makefile anymore, and the gsm053_conv.c
in libosmogsm has superseded it anyway.
Change-Id: Icdcca1bc55a83c76ec47918dc4dd301155210091
The DATA-IND, received from the physical layer does not only include the actual
uplink data. It also includes the frames which are received when the channel
is idle (which is just noise). This would falsify the measurement results.
Depending on the BTS model, the phy may also filter the idle frames and not
send a DATA-IND at all, when the channel is idle. If this is the case, the
measurement period end can not be detected properly.
The idle frames are located at the very end of each measurement period. In
order to fix the issue, the measurement perioud has to end early. For TCH/F and
TCH/H 1, one frame has to be skipped. For TCH/H 0 two frames are skipped.
Example: For a TCH/F in TS0, the Measurement perioud would end at frame number
103. However, 103 is reserverd as idle frame. So we need to detect the end of
the measurement period at frame number 103 (-1).
Change-Id: I471a767c7974bdacadc3233d0c3e7b7965f6eafa
After switching to libosmocoding there's no need in low-level bursts
test which is part of libosmocoding anyway.
Change-Id: Icb8caf62ac653a39a7a82f2225e8edeab7f5afb5
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
lchan_meas_check_compute() is a static function measurement.c.
In order to distribute the measurement result calculation events,
we need to be able to call lchan_meas_check_compute() from l1sap.c
Change-Id: Ideffe896613e0feda443bc13dac59dcdbbc605aa
The measurement reporting for the MS on a SDCCH lacks some of
the periods, defined in 3GPP TS 45.008, section 8.4.2. This
adds the missing conditions by adding complete lookup tables.
Change-Id: I23fba50f48415314da40cf5bf86fce2ed3e66af6
The l1 interface does not explicitly set the flag for 11 bit
rach when a rach request is received. Since the current and
previous octphy firmwares do not support 11 bit rach requests,
the flag should be explicitly set to zero.
Change-Id: Ifa165c56e54d272caafa45d1bf0e177848fcdfbd
Firmware releases OCTSDR-2G-02.07.00-B1314-BETA and newer require
to align the GPRS frame number (fn-3) for ph_data indications.
To preserve compatibility the header version is checked during
compile time and the right method is compiled in.
Change-Id: Ib93d5fb3b34ff92f10021a0e9ce9c8aa3044b7ff
CBCH is activated when the SAPI for TS0 is activated. Since the CBCH can be
configured on any physical TS, we wait until all (TS7 is the last) physical
timeslots are configured.
Change-Id: Ie307bf9f370a346686e3bd8c8a8483953a1bc279
the function is_meas_complete() uses the *_meas_rep_fn104[]
lookup tables, defined at the beginning of the source file.
These lookup tabels contain a lot of magic numbers. This
commit adds a more elaborated comment with a reference
to the specification/section in order make the values
understandable.
Change-Id: Ic6e4037f965772e6b851c67662d5e7bf64cc04eb
the function ber10k_to_rxqual() has only a very brief
comment with the spec reference. This commit adds a more
explainatory comment that makes it easier to understand
from where the ber10k constants are taken.
Change-Id: I3d3488c97d0bffa7d449d3675afcc75b2a6a2703
* move BTS model name resolution into separate function
* add convenience wrappers for BTS type and number fo TRX and use then
in L1 interface
Change-Id: I4649100df8f1b8e095f210fc294567ba014c0b6a
Related: OS#1614
SI2quater support as per 3GPP TS 44.018 will require chnages to the way
System Information is stored because it uses 1:n instead of 1:1 mapping
between SI type and generated SI content. This should not affect other
SI types though. To facilitate this transition:
* convert the code to always use GSM_LCHAN_SI helper instead of
accessing buffer directly
* move duplicated code to inline function
* add logging for buffer truncation and corresponding length values
Requires I74e4e3cb86364cec869a1472a41b4a95af0d50dd in OpenBSC.
Change-Id: Ie97be6ead6ce6d2d425fbfac8429bb90afb95acc
Related: RT#8792
While at it - do not serialize NULL as a string when delivering OML
Failure Report.
Change-Id: I41a731bd719aee0bbb98d3236405fb3a7f3ddec0
Related: OS#1615
When a new TRX is allocated using gsm_bts_trx_alloc() (see gsm_data_shared.c in
openbsc.git), than it is added to the list in order. When octphy is shutting
down the BTS, it uses llist_for_each_entry() to iterate the tansceiver list to
shut all transceivers down. This means it starts the shut down process with
the primary TRX and then continues with the secondary transceivers in order.
However, octphy does not allow to close primary TRX if the secondary TRX is
open. The shutdown sequence must begin with the secondary transceivers and
finish with the primiary transceiver as last item.
The problem can be easily fixed by iterating the transceiver list in reverse
order using llist_for_each_entry_reverse() instead of llist_for_each_entry()
Since this is a change in the common code, all BTS models (not only octphy)
are affected, but from the logical perspective, this change makes sense
for all other BTS models too.
Change-Id: I18485de586b402610f9e98053d69e92bc9b18dc2
Make it possible to store:
* Static vs. DHCP mode
* IPv4 address
* Netmask
* GW IPv4 address
* DNS IPv4 address
Add a simple CRC8 and pick 0xFF as initial value so an all
zero EEPROM will not generate a 0 CRC. The code tries to
differentiate exit code between unreadable EEPROM and CRC error.
This is a reference to see if we want to have store it in the
EEPROM or not.
Change-Id: Id8a37fe952ef2a8ef36778729f506f900accf8d1
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
add support for the TX/RX antenna-id feature that has been
introduced with release OCTSDR-2G-02.07.00-B1314-BETA. The
user can now set individual ID numbers for the TX and for
the RX antenna.
Change-Id: I872fe3c4d7b593358a4ce2f02cf0726611b9f3aa
With octasics latest release (octsdr-2g-02.07.01-B1351-beta), some struct
members are moved or renamed. This patch adds ifdef-logic and configure
checks to restore compatibilty.
Change-Id: I73287983e8bed8bf64b2ab87e6b810c2c59ea6fd
Making use of the multi-trx feature requires to tell osmo-bts that
more than one transceiver are available. Otherwise it will complain
that not enough transceivers are available. This can be quite
confusing, even a correct config file will fail to parse if it
specifies more transcrivers than available.
This patch adds a hint to the error message so that the user knows
that he should check the -t commandline option
Change-Id: Ifbeacd9d43f7c6cd74a1e1b33288e66828fe843f
Some header file versions support multi-trx and some do not. After
to compiling it is very difficult to find out if the binary is
multi-trx capable por not. This patch adds a log line that should
rule out any doubts.
Change-Id: I257c0a5e7c5ff5df2f0a603d1ede6db5679382e0
octphy_hw_get_rf_ant_tx_config() uses define constant
cOCTVC1_HW_MSG_RF_PORT_INFO_ANTENNA_RX_CONFIG_CID instead of
cOCTVC1_HW_MSG_RF_PORT_INFO_ANTENNA_TX_CONFIG_CID. This commit
replaces exchanges the wrong constant with the correct one.
Change-Id: Ie4de23daf79bb07ca0c0b818eefe350d18d27e4d
In case a system has a high-gain external PA (like a 40dB PA) connected
externally, we cannot simply switch the transceiver to 0 dBm in
trx_init() only to then start the ramping at much lower levels once the
PHJ completes in trx_init_compl_cb(). The result would be a short
0 + 40 dBm spike followed by later ramping. We want to avoid that
spike, particularly its associated inrush current, so let's bring up the
board with smething very conservative like -50 dBm, and then ramp from
there.
Change-Id: I0ad91fce64f65e0213c9fcfde3390ace519055db
Fixes: SYS#3259
Currently the channel combination II is used for TCH/H, which
allows only one lchan to be allocated. The reason is that it
saves a bit of CPU by disabling UL burst detection on lchan 1.
There is also the channel combination III, which allows to
increase channel capacity, providing two lchans on a single
TCH/H timeslot.
Ideally we should implement some dynamic II <-> III switching
depending on the network load level. But for now this change
replaces the channel combination of TCH/H by III, until dynamic
switching is implemented.
Fixes issue: https://osmocom.org/issues/1795
Change-Id: I8fd4abb42c153fcd26bcfe22a2554b5c2d02d810
* DTXu: don't set marker for broken frames
* do not attempt to send 0-length bursts to avoid flood of errors after
bts startup
Change-Id: Icb536f951386b9abe34c0dacbb203f3db1e41bb3
The macro L1SAP_IS_PTCCH(fn) only detects a PTCCH channel at fn%52 = 12,
the detection logic has been extended in order to detect PTCCH at fn%52 = 38.
See also 3GPP TS 05.02, Clause 7, Table 6 of 9
Change-Id: Ia6f3333121e5e920c5e1d562a081d0a1b58a1153
The ra parameter indicates the reason for the received rach
request. osmo-bts uses the ra parameter to determine if the
received rach request is packet access related. If yes,
osmo-bts will forward the request to the PCU.
In order to determine if the ra is packet related or not,
the higher 4 bits must be equel to 0x7 and at least one of
the lower 4 bits must be zero.
The current method lacks checking of the lower 4 bits. It
would also accept 0b01111111, which is reserved for future
use. This commit extends the check to take also the last
4 bits into accound.
See also: 3GPP TS 04.08, Table 9.9
Change-Id: I5eb88c42a91e158d9bfa4105ec9636035baf8959
Log error when handover RACH is detected on wrong channel: according to
3GPP TS 44.018 it can only be seen on SACCH and DCCH.
Change-Id: Iacbcc8441d6cfbb8f808948a8baddde1ebca488a
Related: OS#1898
The VTY commands show phy 0 rf-port-stats and show phy 0 clk-sync-stats
do not output their results on the VTY console. If one of those commands
is entered the user is prompted to view the logtext, which is an
uncomfortable solution. This commit adds the missing functionality to
print the information in the VTY as well.
octphy_hw_api.c contains two value_string structs (radio_std_vals and
clocksync_state_vals) which are now exported in octphy_hw_api.h in
order to access them from octphy_vty.c
Change-Id: Iae5aa91fe2ebba7c2874eed88b15ed66e8c9cd61
This bug was introduced during moving oml definitions from osmo-bts to libosmocore
in libosmocore 0bee65c0d89f81a4b90aa3d484016d9ba680dd46 and
osmo-bts 2cf6b73a42:
The type of abis_nm_att_tlvdef_ipa was changed from struct tlv_definition to
const struct tlv_definition, so:
* create static abis_nm_att_tlvdef_ipa_local variable for oml attribute
definitions
* copy abis_nm_att_tlvdef_ipa to abis_nm_att_tlvdef_ipa_local
* merge abis_nm_att_tlvdef with abis_nm_att_tlvdef_ipa_local
* use abis_nm_att_tlvdef_ipa_local in oml_tlv_parse function
Change-Id: Ia9f3c94ab247adeecb26a01c3ccd6f3a8c17ba1c
This issue occurs in case of osmo-trx restart which leads to losing clock from osmo-trx.
Function bts_shutdown from common/bts.c should be used in this case for proper bts shutdown.
Change-Id: Ie65cf2e8f98cb8bf3314a00048aa53c1f8cd4c25
The simplistic approach of sysmobts_get_nominal_power() is insufficient
to cope for devices that have an internal PA. The Actual transceiver
board is driven to a certain level (0..23 dBm typically), and the
external PA must be handled independent of that. Increasing the return
value of sysmobts_get_nominal_power() would result in the sysmoBTS
mainboard attempting to reach a higher power, which is wrong.
This change affects sysmoBTS 1020 and 1100. It causes power-ramping to
be used by default. For 1002 and 2050, no behavior change is expected.
Change-Id: Ieff75d5becaa80a2097b6e744c75c2d16259c9a4
This issue occurs in case of osmo-nitb restart which leads to abis connection closure.
Function bts_shutdown from common/bts.c should be used in this case for proper bts shutdown.
Change-Id: Id025e703dd5c91896d450d200e88e46552f178f0
According to Table 4 in 3GPP TS 45.003 j=11, b=3 case corresponds to
k=91 and not j=12 as was previously used.
Change-Id: Iad3cf545b2f7e16276466cc37dd7a1e7858467e5
pinst->u.osmotrx.hdl should be allocated before reading phy_instance parameters from config file and applying them.
So allocation of pinst->u.osmotrx.hdl should be moved from l1if_open function to bts_model_phy_instance_set_defaults function,
which is proper place for this allocation according to start-up procedure of osmo-bts.
Change-Id: I6e23f92644400acb268818c9373a8fb10c003da1
Move rxgain and tx-attenuation (power) parameters from phy_link layer to phy_inst layer.
Rxgain and tx-attenuation parameters should be set for each phy_inst and send for each osmo-trx channel accordingly via control commands.
Change-Id: I4861a59d10d1ef91954e0c6ea265e66dec08844f
It's useful to know RTP statistics (number of packets lost, jitter, etc)
when looking at voice call quality issues. Right now this information is
not avialable anywhere and this looks like the best place to start.
Change-Id: Ife9f27c43157b4a1bf71aba41cd7b0f5f41ac99f
The vty write for phy/inst is broken, leading to a written-out config being
unparsable; fix all of these:
- in common/vty.c, actually call bts_model_config_write_phy_inst().
- in sysmo and lc15 write the phy instance elements in
bts_model_config_write_phy_inst() and not in bts_model_config_write_phy(),
which lead to writing the members above their parent 'instance'.
- sysmo, lc15 and oct omit the bts_model_config_write_phy_inst()
implementation. This did not cause a compilation problem because it
was in fact never called.
- sysmo writes 'clock-source None' when clk_src is zero, leading to unparsable
config (related: OS#1944). Instead omit the 'clock-source' when zero.
- osmo-bts-trx seems to be the only part that lacks nothing, yet it
also didn't work properly because bts_model_config_write_phy_inst()
was never called.
This problem existed since commit d784e50747
"Introduce new phy_link and phy_instance abstraction"
Change-Id: Icc54fa70045c8fa58e78cf9f788c21a437edfbd4
In case our SI enums ever move past 31, this static assert will warn us to
enlarge osmo_si_shifted.
Change-Id: I4185d7de590329ff5f523b241721c586ffdbcd8b
In copy_sacch_si_to_lchan(), the variable to hold the bit mask for SI-is-valid
was chosen as uint8_t, and as a result none of the SIs with an enum value >= 8
would ever be sent. Use int for enum value and uint32_t for the bit mask.
Fixes: #1945
Change-Id: I85fa9a50691601bcd103845c6811caa061a39824
Upon rx of a SACCH INFO Modify for an lchan that has no L3 INFO IE, clear only
the si.valid bit in question, instead of clearing all but the one in question.
BTW, It first looked like it could be, but is *not* the cause for OS#1945
(SI5ter never sent to MS).
Change-Id: I0df20b6643b0bfd219ce1df594075838d8406719
This tests the computations of the tx_power.c code using sysmoBTS 1002,
1020, 1100 and 2050 values, as well as the power ramping code.
Change-Id: I1cc88d4c6edff326e2e67d4f869aa02c9b2b1ac5
It seems more user friendly to look at a calibration table in terms of
the delta (positive or negative) compared to the nominal gain value,
rather than a collection of absolute gain values. It has the added
benefit that the (API/data model) user doesn't have to specify a gain
value for each ARFCN, but rather can rely on the default nominal gain in
absence of a calibration table for this specific unit.
Change-Id: I7311815902a88d2fc9d211cf4c62fa6fdc5e86ad
This reverts commit 1965b0d880, which was
a premature change. The 10dB gain are not the power of the TRX board,
but are due to an internal, factory mounted PA, i.e. the
trx_power_params.pa. This will be introduced after adding a set of
tx_power.c unit tests.
Change-Id: I524b63c51fb0fe1f90ced28486a8e712f2dc50ae
Based on GSM 04.08 3.4.13 RR connection release procedure, after the network
sends a deactivate SACCH it receives DISC from MS which cause BTS to
send RLL release indication to BSC in order to stop T3109 timer. It has been
found that after a location update BSC never receives RLL release indication
which causes a T3109 timeout because no TCH is currently allocated. This fix
ensures RLL release indication to be sent to BSC when no TCH is allocated
in the particular case of a location update.
Change-Id: Ibe2a365641eb8c9a7f0a462b7393ec3fd28cc366
The sysmoBTS 1020 is a 2W BTS, hence its nominal transmit powre is
33dBm. We must handle this correctly based on the model-nr in the
EEPROM. As a result, proper power ramping will be made during start of
the unit by default.
Change-Id: I91a78dadfd7d2e1bc74c8086808c55effdcdd132
Improve state handling for for lock/unlock of OC_RADIO_CARRIER obj class. in
bts_model_chg_adm_state()
Change-Id: I034114beca95210169429d8ac1eb8648df12fc6c
Fix SID_FIRST_INH detection during speech and when SID_FIRST is interrupted by FACCH.
Fix SID_UPDATE_INH detection during silence and when SID_UPDATE is interrupted by FACCH.
Add a delay for SID_FIRST to appear at the right time after FACCH.
Fix extra byte sent in downlink for SID_FIRST and SID_UPDATE.
Change-Id: Ia811305e15541f2376005df736bd610e8b0d2f69
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
Fix error during FACCH interruption of DTX for AMR HR.
Max's note: added fix for sysmobts.
Change-Id: Ib064952331b4f89676ee68a3d8078b1d9debe570
Related: OS#1801
Fix invalid configuration generated by VTY 'write' command for the 'phy'
section of osmo-bts-octphy.
The problem was introduced during refactoring
commit d784e50747 (Sat Jan 9 13:13:37
2016 +0100, "Introduce new phy_link and phy_instance abstraction")
Change-Id: Ib018e07e332aa8a6144fb2d87889032bd5fc2533
* 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
There should be no other OpenBSC headers included and nobody is using
bsc_controlif_setup. Remove the include. This was introduced in
4723a19508.
Change-Id: I581f938e8fe9161b1d7076cedd74ff192cea86b2
Use --with-openbsc= to pick up gsm_data_shared.h coming from the
openbsc-dev package. With the revert of the change
Iec6b0f0eb0b7fffaa814c9769c0ee777d641a07f, packaging could work
now.
Change-Id: Ie0a005315454a6450205ce6fd76242b85405de8d
As the Osmocom project is providing packages and we build them
directly from git we should have native packages. openbsc-dev
should provide files in the same directory structure as the git
repository and then --with-openbsc=/usr/src/osmocom/openbsc/openbsc/include/openbsc
can be used. Follow up patches are coming.
This reverts commit 70b71507c2.
Change-Id: I8bc3a5c2b9446d9e94e362ed5d85a61e3a727f8b
Use gsm_data-shared.* from absolute path where it's installed by
openbsc-dev package instead of relative path to fix OBS package
building.
Change-Id: Iec6b0f0eb0b7fffaa814c9769c0ee777d641a07f
Related: OS#1860
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
Currently the IP address where the control interface is bound
to is hardcoded to 127.0.0.1. This leads to problems with
multiple instances on one and the same machine. This commit
integrates the ctrl interface bind option into the VTY, so
that we can bind the ctrl interface to any IP address, just
like we do it with the VTY already.
Change-Id: If51e0c645c0789a4f4a8c51737fb81fb12f80829
oml_ipa_set_attr() is using gsm_objclass2mo() to determine the
*mo object. However, it is possible that gsm_objclass2mo() returns a
null-pointer. The code following up is using *mo without checking.
Reject instead of dereferencing a NULL *mo.
Fixes: coverity scan CID#159533
Change-Id: Ia2cc9bc504c46ca3843c43d712cd8649bfae9526
The public functions in rsl.c do not check for null pointers,
add assertions to catch null pointers early.
Change-Id: I63f127ce70a4127180f90238f564b63e355216ec
rsl_rx_paging_cmd() checks if the pointer *trx is NULL, this check
does not make much sense since *trx has already been dereferenced
without checking earlier in the code. Furthermore *trx is also a
mandatory parameter which must not be NULL.
Fixes: coverity scan CID#159534
Change-Id: I17dfb42ff404b2a1e18354fb7a7278089b407a79
With libosmocore commits I9c3bc15662949654e7bba6aad5488c69ee7d0c45 and
Ieaaaed19da9c069fe451faa53d24c5b84d7d5615 functions to copy and merge
parsed TLV were added as well as abis_nm_att_tlvdef_ipa TLV definition
with related enums. Hence we can remove it from here.
Change-Id: Ia4980062ea88ffe9019b201f84e92e006ae3c2e3
Add debian/copyright in Debian format which should have been added in
c2ecca6b04.
Change-Id: I4c7ef1286ba6d2f3c6aadc8ea1864be513f8cf1d
Related: OS#1694
Fix pchan value used for uplink measurement decisions for dynamic channels in
TCH mode.
Fixes this error log message flooding the osmo-bts log when a dyn ts is serving
a voice call:
<0004> ../../../src/common/measurement.c:104 (bts=0,trx=0,ts=3,ss=0) no space for uplink measurement
Change-Id: Id19316701fd8de6f295eeae0272eea0c315ab1b7
* 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
debian/control:
* restructure to make it easier to incorporate further changes
* update package descriptions
* update project URL
debian/rules:
* use proper hardening syntax
* restructure to make it easier to incorporate further changes
* remove useless comment
* add cleanup and test overrides
debian/compat: update compatibility version
Change-Id: Ibf62448eee1df914d21834f5b54831e3f642b79c
Related: OS#1694
* add vty option to manually enable adaptive RTP jitter
buffering (disabled by default) on per-bts level
* use this setting on per-lchan level when setting jitter parameters via
vty at runtime
* check and log result of osmo_rtp_socket_set_param()
* note: older libosmo-abis will ignore this setting which will be
properly detected via return value
* if jitter buffer is disabled by configuring "rtp jitter-buffer 0" than
adaptive buffering is disabled as well but it will be used if jitter
buffer is set to different value for a givel lchan via vty
Change-Id: I489f3c419039f40b57c2ef0641c176478b8d3566
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
Use chan_nr for deactivating lchan instead of lchan->nr: chan_nr is the
RSL Channel Number IE value, a bitfield aggregation of lchan type
bits (cbits) and lchan number (lowest three bits). The error was
introduced in 36153239bf.
Change-Id: I6dd7060422ab9d18743c1ff2ab419e3e7299d74d
Having RTP metadata is useful for debugging - save Sequence Number and
Timestamp next to Marker bit from RTP header.
Change-Id: I359b3bcb74fbfc071547fe2f9d837829374fe997
Check explicitly if DTX is enabled for AMR before checking if SID frame
repetition is optional.
Change-Id: I660688d56505798cade1495c30338fd6806a3259
Related: OS#1801
Previously if multiply phy instances were configured but not used
osmo-bts-trx would segfault. Terminate with clear error message instead
so user can correct configuration. Example configuration which caused
problem:
...
phy 0
instance 0
instance 1
...
trx 0
phy 0 instance 0
Note the 2nd instance of phy 0 which is not used in trx later on.
Change-Id: Id979506731ea92401458f1060e87aeb690901539
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
Typically, our VTY prompts have space after the '#', but some of the osmo-bts
VTY prompts don't:
OsmoBTS# configure terminal
OsmoBTS(config)# bts 0
OsmoBTS(bts)#gsmtap-sapi ccch
Add spaces after the '#' to yield e.g.
OsmoBTS(bts)# gsmtap-sapi ccch
Change-Id: If0591a359e77f01abb76c4113181af7a7733ddd4
Remove lchan deactivation related code duplication to facilitate future
use for dynamic CCCH re-activation.
Change-Id: Id0d3b19dbfaa16d1734321a07a6eb0355bfd77c9
Add explicit state for recursion (sending the different payload data in
response to the RTS request for same FN) and corresponding
transition. Remove ST_FACCH_V as with new explicit recursion handling it
becomes unreacheable. This makes it easier to maintain
preemption (interruption of current procedure due to FACCH or
Inhibition). This also reduces the number of possible transitions out of
each state thus reducing graph's cyclomatic complexity.
Change-Id: If39b68083d23a4a35f468a5d75f54eb733ebfd14
Originally `maxdly` command in osmo-trx was contrlling max TA for Normal Bursts.
This was not a proper behaviour, because it was used to "control maximum
distance a handset can attach from" which is controlled by Access Bursts max TA.
Osmo-trx was corrected to apply `maxdly` to Access Bursts and a new command was
introduced to contrl max TA for Normal Bursts - `maxdlynb`. This patch adds
support for this configuration command into osmo-bts-trx.
If you wonder why would you need that - some test equipment (namely R&S CMD57)
has really bad timing sync and can generate signal a few symbols off. That
prevents osmo-trx from properly receiving otherwise perfectly good bursts
generated by CMD57. This configuration is a solution for this.
Change-Id: Ib5d255299668ac1ef9f0ce95e016f55ba3c82277
The header file octphy/octvc1/gsm/octvc1_gsm_default.h is not
visible to the configure script when the octphy header files
are referenced via --with-octsdr-2g instead having them
installed in /usr/local/include. This results in a failed
AC_CHECK_MEMBER check for tOCTVC1_GSM_TRX_CONFIG.usCentreArfcn,
even if header files with multi-trx support are used.
The configure.ac script manipulates the CPPFLAGS in order to
make the octphy include files visible to AC_CHECK_ and restores
the original CPPFLAGS when done. This is required when
--with-octsdr-2g is used. AC_CHECK_MEMBER is executed
before the CPPFLAGS are manipulated. This causes no issues
if the headers are properly installed to /usr/local/include,
but does not work when --with-octsdr-2g is used.
This commit moves the AC_CHECK_MEMBER command into the section
where the manipulated CPPFLAGS are valid in order to fix the
problem described above
See also commit: f5494e84e8
Change-Id: I7bdfa4449cd6061c395cce315b372c2833520e37
I noticed that the README is prominently shown on github, so it makes sense
to get rid of the worst typos and misinformation there.
Change-Id: I60defef6224a78bb84d7d0b57bc8da17ad7877bb
This is the easiest way I found to make BTS level loopback to work.
Another way to implement this is to have BSC/NITB to send the OML command, but
it's a longer path with no clear benefits.
Note, that the current code hardcodes the channel to be TCH/F with v1 speech,
which is what we need for the basic BER testing. We may want to extend this
later to support more channel types.
Change-Id: Ia2734afeff023e5b3d6b934c7e8b1ed95a071b72
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
Call vty_init() before handle_options() to make sure the host.app_info is
populated before --version potentially tries to print it.
Change-Id: Ic87b5498b57b2f0f876171a15e769b74c28348c1
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
Previously, if ONSET happened exactly at the place where next SID FIRST
or UPDATE should be it was incorrectly detected as error. Similarly,
continuos FACCH was misinterpreted as error.
Change-Id: I43fdbceea0dbdb0833c3b1cf0fc3b825803ed30e
The parameters related to support 11bit RACH are initialized in
osmo-trx. These parameter determaine the type of the RACH received
in osmo-pcu.
Change-Id: I164d449303373d0757719d5204f4716975fb517a
* re-introduce ST_ONSET_F to guard from repetitive ONSET messages in case
multiple FACCH occur duriing DTX silence period.
* produce ONSET event after both SID FIRST and UPDATE in case of AMR FR.
* always dispatch E_SID_F (SID FIRST) signal if in talkspurt.
* allow E_SID_* right after ONSET (zero-length talkspurt).
* add missing E_ONSET signal description.
* fix FSM transitions for AMR HR *Inhibited and First P*.
* fix incorrect return from l1if_tch_encode() in ONSET FACCH with
incoming SID UPDATE
Change-Id: I0e9033c5f169da46aed9a0d1295faff489778dcf
Related: OS#1801
superfemto.sh: Expand log converter to use case-insensitive matching to
accommodate for spelling differences in DSP logs. Add strings/events
specific to AMR HR.
dtx_check.gawk: Remove redundand variables from output. Add checks
specific to AMR HR.
Change-Id: Icce3178605f46bbf3cad15d4eaff18a4d164ad1a
It was moved to OpenBSC in 582e4f627674f46310a90d9061e82fb342051b42 as
it's used by both projects.
Change-Id: I8aba987e3cdaa840cf3e14913a8455b0ba759889
Handle ONSET cause by Voice and FACCH separately. In case of Voice we
have RTP payload which we have to cache and send later on in next
response to L1 RTS. FACCH have higher priority so it preempts both voice
and silence alike - hence we can send ONSET immediately but still have
to track previous state in order to get back to it gracefully.
This affects lc15 and sysmo hw as there's no FSM-based DTX
implementation for other models yet.
Note: this requires patch for OpenBSC which adds FACCH buffer to tch.dtx
struct.
Change-Id: Idba14dcd0cb12cd7aee86391fcc152c49fcd7052
Related: OS#1802
Based on the indication from L1, number of bits in RACH and burst
type is determined. Appropriate parameters are filled in
osmo-bts-litecell15. These parameters are sent to osmo-pcu for
processing of the RACH.
Change-Id: Ie5207a15424fb287febf74e830297531232accde
* superfemto.sh can parse superfemto-compatible DSP log output to
properly sort records into MT/MO and DL/UL parts
* dtx_check.gawk can process output of superfemto.sh and check for
common scheduling errors
This allows to check lc15 and sysmo for errors in DTX DL scheduling. As
dtx_check.gawk is generic it can be used with any other BTS hw (or
virtual BTS) as long as raw logs from this hw can be converted to simple
input format 'FN EVENT' per-line.
Change-Id: Ib1c70c4543b24c2a05a7df8eec5ce3f4eda2c02e
Related: OS#1801
Previously SID UPDATE was sometimes scheduled incorrectly. Fix this by:
* avoid rounding error when computing scheduling time difference from FN
* properly saving and updating cached SID type and FN
Change-Id: I7acffae4792e7bddc2ae19a2f04ee921dc194c36
Related: OS#1801
Use ARRAY_SIZE macro for each pointer separately.
Fix suggested by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
Change-Id: I68ec1be33fb743977121d654187d85d6b8451e2b
Fixes: Coverity CID 150132
SDCCH occupy lchan 0..3 in combined configuration so for CCCH we've
always used lchan[4] - replace it with CCCH_LCHAN define and add
comment.
Change-Id: Ic5d742c292d638f119c6b4672120c1950adeb7f0
Use dedicated FSM to handle all DTX DL related events:
- add explicit checks if DTX DL is enabled (fixes regression for non-DTX
setup introduced in 654175f33b)
- fix handling of AMR CMI for SPEECH frames
- add FSM for DTX DL
- sync with corresponding changes in OpenBSC's
- handle FACCH-related DTX ONSET events
This affects both lc15 and sysmobts and requires corresponding change in
OpenBSC (Change-Id: Idac8609faf9b5ced818fde899ccfc6ed0c42e8fd).
Change-Id: I74a0b42cb34d525b8a70d264135e82994ca70d31
in its current statue l1_oml.c does not check if the version
number in the header files (octvc1_main_version.h) matches up
the version that is reported from the DSP during startip. This
patch ads a check to make sure that the currently loaded
firmware and the headers used during compile time match. If
a mismatch is detected, osmo-bts exits immediately.
Change-Id: Icba5756517d632d53b129c5ce1a1dab4936dab91
Previously FN was converted to millisecondss incorrectly due to wrong
conversion between FN and a number of voice samples. The conversion
should be based on following:
* there are 12/13 useful frames for audio in TCH
* there is 1 RTP packet per 4 frame
* there are 160 samples per RTP packet
Fixes: OS#1801
Change-Id: I9cc70cacabde98621aa892cee74f4ac461645093
Use "impossible" dummy value to initialize last_fn to prevent dropping
of 1st RTP frame due to timestamp jump.
Fixes: OS#1803
Change-Id: I485af21f6761048d12dc7f5552fcdd46daf786ed
The constant cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_UNUSED in header
file octvc1/hw/octvc1_hw_api.h has been renamed to
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_IDLE. This commit adds an ifdef
decision in to code to ensure that older header files will still work.
Change-Id: I4c0b976d29689ace06741c5943434fc33ee2df14
The multi-trx had to be removed because of build conflicts
with octphy header that lack the struct members for needed
to support multi-trx.
For details see the following revert-commits:
ed6b48e4a5c9a1f284ac
This commit reintroduces multi trx support and ads an ifdef
decision to ensure that header files without multi-trx
support still work.
Change-Id: I7f9b2906cc149c817183745b4c96bcc7f9ebdad0
Explicitly set AC_CONFIG_AUX_DIR.
To reproduce the error avoided by this patch:
rm install-sh # in case it was already generated.
touch ../install-sh # yes, outside this source tree
autoreconf -fi
This will produce an error like
...
configure.ac:16: error: required file '../ltmain.sh' not found
configure.ac:5: installing '../missing'
src/Makefile.am: installing '../depcomp'
autoreconf: automake failed with exit status: 1
See also automake (vim `which automake`) and look for 'sub locate_aux_dir'.
Change-Id: I02153ad52faf1465e9f7821378e04118f17352d2
When ONSET event happens (either via Marker bit or due to unmarked
talkspurt) we should first send Onset event to L1 and than send voice
data in response to the same PH-RTS.ind.
Change-Id: I2a7b89430ca49eee4a350c5f980bd6bcbc386347
Move code from tch.c (lc15, sysmo) into generic function which:
- check if talkspurt is happening
- cache SID if necessary or invalidate cache
- fill in CMR & CMI prefix
This also fixes the problem when SID FIRST was cached without sending
just like SID UPDATE instead of being sent right away.
Change-Id: I6c7016a54749abadeef4fd4f5b6f750b256fb916
* consolidate AMR CMR and CMI handling in common/amr.c
* use it in save_last_sid()
* remove dead code
* properly compute RTP payload length for AMR
* use save_last_sid() for FR & HR as well
* invalidate cached SID if SPEECH frame is received
Fixes: OS #1800, #1801
Change-Id: I5a1c1ad0b0a295a50e67775a4db85f1d331755ed
Note: this also require changes to properly link against libosmocodec -
see 2bb65be159dfdabf664fec569b343320301701b0 in libosmocore.
Change-Id: I96594cf3aa1013d505bd20069d5bf261d9a2aefb
If Marker bit is set than it's a talkspurt which we have to explicitly
indicate to L1 by first sending ONSET message and than actual voice
data in a separate message.
This change affect sysmobts and LC15 hw.
Change-Id: I88c41568bcb0d82699f617adc4ad192603dd1bb6
Related: OS#1750
There is now an exception for ARFCN 0 in osmocom_to_octphy_band to
distingush ARFCN 0 (E-GSM) and 1-124 (P-GSM).
Change-Id: If012f31121e9d0d45b36459807c5f290aa17374f
in l1_oml.c:ts_connect() the payload type (ulPayloadType) was not
configured to full-rate for PDTCHF PACCHF and PTCCHF. Older octasic
firmwares (below octsdr-2g-02.06.00-B964-alpha) will tolerate this,
newer versions will crash during channel initalitation.
Change-Id: Id2f6a439ceb063b10efc7b9d1d70bb5b29a01033
Some phone seems to not send SID_FIRST_P2 message which seems like a
different understanding of the DTX spec. L1 accommodates for that by
using P1 to supply data for SID. Hence we should use it to initiate DTX
and ignore P2 message in case of AMR HR.
Change-Id: Iaf993b89caa0ad49b97d1c745dcaf039f867f018
Previously receiving SID via RTP always caused it's transmission to L1
regardless of the time which might have resulted in excess traffic. Fix
this by only saving SID data and transmitting it later on as necessary
according to 3GPP TS 26.093 A.5.1.1.
Change-Id: Ifcdc5c60d0238b704a94f6778d4e00f2b087b090
Fixes: OS#1801
Previously SID retransmission was scheduled incorrectly based on GSM
frames instead of voice frames. Fix this by using GSM Fn only as elapsed
time estimation:
* move saved SID retransmission into generic function from lc15 and sysmo
specific code
* split retransmission time check into separate generic function
* compute estimation for elapsed time since last retransmission using
GSM Fn
Change-Id: Ib054b458a7345d9ba40dba53754ca59ab099c8e8
Fixes: OS#1799
Previously SID was saved explicitly by each BTS model (lc15, sysmo)
instead of relying on generic function. Fix it by using generic function
and propagating necessary parameters for it.
Change-Id: Ie545212cce5ed2b3ea3228597f18a473f5e1deb4
Fixes: OS#1800
Like most other osmo-* programs, bind the telnet VTY to the address specified
by the 'line vty'/'bind' command. This is added by vty_init(), so until now the
BTS offered this config but ignored it.
Change-Id: Ic4ab32aee08d8a779adeb9943892de0c828c7b3d
Add log_name to lchan_lookup() and pass such from the various RSL rx events
that call it to validate the RSL chan_nr.
Change-Id: I0d9923f47ac655b204169eec302d607412d5754d
The osmo-bts log used to say this a lot:
DL1C <0006> oml.c:758 (bts=0,trx=0,ts=0,ss=1) End of queue encountered. Now empty? 1
- Move this to DEBUG level instead of NOTICE.
- Tweak wording and logic so it says one of:
[...] End of SAPI cmd queue encountered. Queue is now empty.
[...] End of SAPI cmd queue encountered. More pending.
Change-Id: I5a46c90d016cee9b50f32db2af568765d3cb74cc
Based on the indication from L1, number of bits in RACH and burst
type is determined. Appropriate parameters are filled in osmo-bts-sysmo
These parameters are sent to osmo-pcu for processing of the RACH.
Change-Id: I93831ddfb3f31b637e6a576f23a9bb4557758582
Before this patch, Osmocom style TCH/F_TCH/H_PDCH dyn TS were paralyzed if no
PCU was running. The state of the dyn TS would lock up in the PDCH activation
phase since the PCU never completed the process.
Make more robust, i.e. don't concern the BSC with PDCH activation failures.
This matches the way plain PDCH TS work: besides declaring the TS as PDCH, the
BSC is not involved and is not told about errors.
During PDCH deactivation, still wait for the PCU to tear down the PDTCH SAPIs,
but in case no PCU is connected, send a rel ack right away.
Thus, the BSC will happily switch Osmocom style dynamic timeslots to and from
PDCH mode, using the dyn TS as voice channels as needed, and not caring about
possible PDCH failures. GPRS starts working right away as soon as a PCU
connects, regardless of dyn TS having been used for voice any number of times,
and without another switchover needed.
In detail:
In rsl_rx_chan_activ(), upon receiving a PDCH activation, send an RSL chan act
ack right away, unconditionally (with an explaining comment). Do not concern
the Abis link with PDCH activation failures.
Since we're acking right away now, drop the chan act ack that would follow
after the PCU activation: as before dyn TS, only send acks and nacks for
rel_act_kind == LCHAN_REL_ACT_RSL (PDCH runs as LCHAN_REL_ACT_PCU).
In dyn_ts_pdch_release, indicate that the PCU is not connected by means of
returning 1. In rsl_rx_rf_chan_rel(), use this indicator to send a rel ack
right away if the PCU is not connected.
Change-Id: I2a0b9730197786b99ff3bc1f08c75f7d279cb1f7
There was an apparent change of name from
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_IDLE
to
cOCTVC1_HW_CLOCK_SYNC_MGR_STATE_ENUM_UNUSED
in:
git://git.osmocom.org/octphy-2g-headers
commit 953a258aadf18c05e8128a339f15b1c5bb377cfd
"Import headers from OCTSDR-OPENBSC-02.07.00-B708.tgz"
In order to build octphy with these headers, apply the same rename in
osmo-bts-octphy/*.
Change-Id: Ic07055860035a7c1b83ab923817423eeb39f33d3
This reverts commit c4fc00d851, except: we keep
the part that sets the trx_id in bts_model_phy_instance_set_defaults().
Theoretically, this patch makes a lot of sense, but in order to be able to
build osmo-bts-octphy until the headers version is clarified, revert use of
usCentreArfcn:
Above commit uses an usCentreArfcn member that is never defined in the history
of our octphy-2g-headers.git. This usCentreArfcn does exist in a code snapshot
OCTSDR-2G-02.05.00-B780-DEBUG, which is not (yet?) publicly available.
Also, the current headers version is apparently 02.07, though the octasic
version numbers have been known to cause confusion among osmocom folks.
This along with one other revert fixes this build problem:
make[3]: Entering directory '/n/s/octphy/git/osmo-bts/src/osmo-bts-octphy'
CC l1_oml.o
l1_oml.c: In function ‘l1if_trx_open’:
l1_oml.c:1350:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = plink->u.octphy.center_arfcn;
^
l1_oml.c:1352:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = trx->arfcn;
^
In file included from ../../include/osmo-bts/logging.h:5:0,
from l1_oml.c:33:
l1_oml.c:1365:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn, oc->Config.usTsc, oc->RfConfig.ulRxGainDb,
^
Change-Id: Ic643709e8fb3df2d66337190ed1f07fd230d7dca
This reverts commit 06968beab9.
Theoretically, this patch makes a lot of sense, but in order to be able to
build osmo-bts-octphy until the headers version is clarified, revert use of
usCentreArfcn:
Above commit uses an usCentreArfcn member that is never defined in the history
of our octphy-2g-headers.git. This usCentreArfcn does exist in a code snapshot
OCTSDR-2G-02.05.00-B780-DEBUG, which is not (yet?) publicly available.
Also, the current headers version is apparently 02.07, though the octasic
version numbers have been known to cause confusion among osmocom folks.
This along with one other revert fixes this build problem:
make[3]: Entering directory '/n/s/octphy/git/osmo-bts/src/osmo-bts-octphy'
CC l1_oml.o
l1_oml.c: In function ‘l1if_trx_open’:
l1_oml.c:1350:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = plink->u.octphy.center_arfcn;
^
l1_oml.c:1352:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn = trx->arfcn;
^
In file included from ../../include/osmo-bts/logging.h:5:0,
from l1_oml.c:33:
l1_oml.c:1365:13: error: ‘tOCTVC1_GSM_TRX_CONFIG’ has no member named ‘usCentreArfcn’
oc->Config.usCentreArfcn, oc->Config.usTsc, oc->RfConfig.ulRxGainDb,
^
Change-Id: I222766f6961f5f35aa3651e2907e3e908fe9a66e
Prepare for a dyn TS patch that needs to call rsl_tx_chan_act_ack() directly
without the rel_act_kind decision.
Add function rsl_tx_chan_act_acknack() to wrap rsl_tx_chan_act_ack() and
rsl_tx_chan_act_nack(). Move the decision whether to drop the ack/nack, based
on lchan->rel_act_kind, to the new function, losing some code dup.
Change all callers to use the new function; drop the two older ones from rsl.h
and make them static.
Note: for nack, the exception for dyn TS in PDCH mode was missing
(rsl_tx_chan_act_nack() had only the rel_act_kind != LCHAN_REL_ACT_RSL
condition, but should also have had the dyn TS exception as in
rsl_tx_chan_act_ack()). I already know that this exception will again be
removed in an upcoming commit, but for patch readability it logically makes
sense to add it here. To easily include the nack case, drop the check for which
pchan the dyn TS is operating as, because a rel_act_kind == LCHAN_REL_ACT_PCU
implies that it is either already in or trying to become PDCH mode.
Change-Id: I57ba60c670730c6d7877a6a9b96ece0a7679a0bb
Commit "sysmo,lc15: ts_connect_as(): log error also for pchan_as == TCH/F_PDCH"
introduced a check for TCH/F_PDCH intended only for TCH/F_TCH/H_PDCH. It looked
correct, but TCH/F_PDCH startup was designed differently:
For TCH/F_PDCH, the idea was to look it up in pchan_to_logChComb[] and obtain
the TCH/F channel combination, so that TCH/F_PDCH first initialize as TCH/F.
So pchan was in fact intended to be passed as TCH/F_PDCH.
For Osmocom TCH/F_TCH/H_PDCH, we've in the meantime added a ts_opstart()
function that makes this decision explicitly. So, instead of reverting the
erratic commit, add TCH/F_PDCH to ts_opstart(), for both sysmo and lc15.
In ts_opstart(), move to a switch statement to resolve the actual pchan to use
for ts_connect_as().
Drop TCH/F_PDCH and TCH/F_TCH/H_PDCH from pchan_to_logChComb[] and comment.
Change-Id: I376b92a06f4cbe943c1c913dea7487fac53a7d08
Though this patch theoretically makes a lot of sense, it is not entirely clear
why dyn TS are working without it. Committing due to common sense, not to fix
any actual breakage.
Change-Id: I6136cb42a4d627ebefc963eb5321fadfe63cca4b
Have one common ts_is_pdch(), placed in lchan.c, since this file is pretty
empty and pretty close to ts. Publish in gsm_data.h.
Remove the if-style implementation from l1sap.c, and instead implement in a
switch statement.
This prepares for upcoming ts_is_pdch() usage in ph_data_req() for sysmo and
lc15.
Change-Id: Ib78d663fdbac5a1d7053f1b9d543649b66da00e2
In measurement.c, fix the number of sublots for TCH/F_TCH/H_PDCH, by using
ts_subslots() from gsm_data_shared.c. The local dup of subslots_per_pchan[] is
no longer needed. (depends on recent commit to openbsc.git for ts_sublots())
Change-Id: I9d9df470c49487bffd56dde42c7bec0da2f50642
Interface structure between osmo-bts and osmo-pcu is updated with the
parameters to differentiate the type of RACH and further support 11 bit
RACH. The function prototype and definitions are changed accordingly.
Interface version number is increased.
Change-Id: I4f4c501b2d86d77c78de32a84b1804172ffb6f4d
This reverts commit 53d792c3b0.
See http://osmocom.org/issues/1796
The commit caused this error for PDCH TS with SysmoBTS:
DL1P <0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
DL1C <0006> oml.c:811 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter
DL1C <0006> oml.c:1089 (bts=0,trx=0,ts=7,ss=0) act failed mark broken due status: -4
Plain PDCH TS show this error but continue to function despite the SAPI
activation failure.
As a side effect, the SAPI activation failure breaks dynamic TS. GPRS
initially works, but the broken status prevents transitions to TCH/* modes
in the BSC:
DRLL <0000> chan_alloc.c:355 Failed to allocate TCH_H channel
DRSL <0004> abis_rsl.c:1656 BTS 0 CHAN RQD: no resources for TCH_H 0x45
Since the commit only enabled PTCCH UL in sysmobts, no other BTS models are
affected. Notice that lc15 still has PTCCH UL disabled all the while, before
and after this commit and its revert.
Also note that PTCCH DL is and has been enabled without problems (see
further above in sapi_dir_pdtch_sapis[]). This is only about PTCCH UL.
Related: OS#1796
Change-Id: Ia59d95c75a8a5d3bd596f55cd1dc0906a6a95f7f
Apply similar fixes as for TCH/F_PDCH also for TCH/F_TCH/H_PDCH:
Detect dyn TS in PDCH mode in ts_is_pdch().
In trx_set_ts(), enhance the "if (TCH_F_PDCH)" to a switch statement including
both dynamic channel types. Adjust the comment to include both kinds.
Change-Id: I6669739cd08780cd9ffb9451cdae9f6b9704c4fe
It is not an exceptional situation if the air-interface is experiencing
non-recoverable decoding errors. At bad signal conditions and/or
interference, this is perfectly normal. Let's use DEBUG instead of
NOTICE log level.
Change-Id: Ifd39c53ec22f57cdb5299e5d76ff6ff1482d3beb
As the ARFCN numbers in DCS (1800) and PCS (1900) are not unique,
we need to specify the band in the upper bits of the ARFCN value before
calling gsm_arfcn2freq10().
Change-Id: I637b76bc1fc749eed8e364412d76606589991c02
Fill in values for BER, BTO, Link quality in L1SAP and send them to
PCU. Note: this increases the version of BTS <-> PCU protocol. It also
requires corresponding changes in libosmocore.
All BTS models provide measurements data unless direct DSP access for
PCU is enabled. For BTS-specific notes see below.
Octphy: conversion from sSNRDb to Link Quality uses formulae which works
in practice instead of what's documented for sSNRDb value. Subject to
change in future revisions.
TRX: C / I link quality estimator is not computed.
Change-Id: Ic9693a044756fb1c7bd2ff3cfa0db042c3c4e01c
Related: OS#1616
spatch on Debian 8.0 has already crashed twice and is likely to
crash more and at the same time the value for this static checking
is close to zero (nice idea but never blossomed). So let's remove
it, have a more reliable build and let's coverity find those issues.
Change-Id: Ic1004edf7f0bee8dda30b95554a0aaf0b116b6b8
Allow output of encoded bit count or error count on BER calculation
without requiring both pointers to exist.
Change-Id: I2c78fa6a92a3b3da4aad8f70353e5a43451b0aa5
Fixes: Coverity CID 137963
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
bts_model_ts_disconnect() has nothing to do.
bts_model_ts_connect() merely sets the new pchan on the ts.
Change-Id: Ieb66935d6efc26854e95d238e810c4f8b16cfa88
To be able to set a specific pchan type for dynamic channels, have the
trx_set_ts_as_pchan() function with an explicit pchan argument instead of
using ts->pchan.
Keep trx_set_ts() as a thin wrapper to use ts->pchan directly.
Change-Id: I9eeef05d2a6763f86a5b89ee7c3b4211f6736e4d
In l1sap_ph_rts_ind(), l1sap_ph_data_ind() and to_gsmtap(), the decision
to handle a TS as PDCH was still missing for dynamic TS.
It is not yet clear why this did not impact functionality for dynamic timeslots
on other BTS models. AFAICT they should not work without this patch, but in
fact they do. It would be nice to clarify this some day.
Change-Id: I7b873a089a3de70d980885a7539cb91997464743
Due to missing runtime cmd patching DSP tracing was not possible at phy
level of config file. No it is possible to specify it as follows:
...
phy 0
instance 0
dsp-trace-flag debug
dsp-trace-flag mph_cnf
...
Change-Id: Ibbbf81d2c4b5d3adbcbc1f08a844d262e603e571
Since the osmo_unixsock_listen() was moved to libosmocore
it would be better to use the library's implementation
instead of reinventing the wheel again.
Change-Id: Id5828649d44ef11e70946793696b0d689d6b35e3
Existing interfaces are coded with the implicit expectation of using
a burst sequence length of 148, which is constant with GSM and GPRS.
That changes with EGPRS, where the burst length may be 444 due to
the use of 8-PSK instead of GMSK modulation.
Setup the interface to accept and return a length value with the
burst sequence. This allows 444 length bit vectors to/from the
EGPRS decoder/encoder. Length is explicitly used as a identifier for
8-PSK vs. GMSK modulated sequences.
Change-Id: I90b46b46b11b6ce280e7f8232d5a2fccec2d4f18
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Handles uplink decoding and downlink encoding procedures for MCS 1-9.
Includes Type 1, 2, and 3 headers and tables from 3GPP TS 44.060 in
order to independently recover coding and puncturing scheme (CPS)
parameters for each coded message.
Change-Id: I0f059ae34c6f36179553cbc972f8becf8179eb55
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Addition of GSM_PCHAN_TCH_F_TCH_H_PDCH should have added these assertions.
They clarify that only 'real' pchan types are expected in this function.
Change-Id: Ifd4b6820861ef716237e7eeed149b2add9e7d485
For chan_nr_by_sapi(), add GSM_PCHAN_TCH_F_TCH_H_PDCH to pick_pchan().
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to pchan_to_logChComb[] for first pchan
initialization.
In ts_connect_as(), make sure that callers pass proper "real world" pchan
types, i.e. reject the "meta" GSM_PCHAN_TCH_F_TCH_H_PDCH pchan constant.
In ts_opstart(), connect as PCHAN_NONE since we will only know the desired
pchan when the first RSL chan activ is received.
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to lchan_to_GsmL1_SubCh_t(), by using its
current "real" pchan mode.
Call cb_ts_[dis]connected() unconditionally, i.e. not only for TCH_F_PDCH when
a pending flag is set. The cb_ts_[dis]connected() will be a no-op if the pchan
type is not dynamic.
Change-Id: Ie30323f968da25027045c42a7ae7f1e70ca711ae
ts_connect() is only called during OPSTART. Name it such because a special
case for OPSTART will be added there for dyn TS.
Change-Id: Iba6880d94142096a8371b08f7404035912cadbb0
For chan_nr_by_sapi(), add GSM_PCHAN_TCH_F_TCH_H_PDCH to pick_pchan().
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to pchan_to_logChComb[] for first pchan
initialization.
In ts_connect_as(), make sure that callers pass proper "real world" pchan
types, i.e. reject the "meta" GSM_PCHAN_TCH_F_TCH_H_PDCH pchan constant.
In ts_opstart(), connect as PCHAN_NONE since we will only know the desired
pchan when the first RSL chan activ is received.
Add GSM_PCHAN_TCH_F_TCH_H_PDCH to lchan_to_GsmL1_SubCh_t(), by using its
current "real" pchan mode.
Call cb_ts_[dis]connected() unconditionally, i.e. not only for TCH_F_PDCH when
a pending flag is set. The cb_ts_[dis]connected() will be a no-op if the pchan
type is not dynamic.
Change-Id: Iaffd2fc0aa9fc6c4a2acbc534ce6384392e0635b
ts_connect() is only called during OPSTART. Name it such because a special
case for OPSTART will be added there for dyn TS.
Change-Id: I09cc81e79661e8084aeebf8132435c207b2cf422
common/l1sap: For dyn TS, the BSC will issue RSL Chan Activ requests with a
non-standard chan_nr. While the rest of the code now understands that, the L1
phy will not. Translate to standard PDCH (== TCH/F).
common/oml: use dyn TS' current pchan mode for lchans config.
common/pcu_sock: detect desired PDCH mode of dyn TS.
common/rsl: implement reconnection chain of a TS for changing its pchan:
* rsl_rx_chan_activ():
** Add dyn_pchan_from_chan_nr() to derive the requested pchan from the RSL
chan_nr IE.
** Notice the need for a pchan change and invoke dyn_ts_l1_reconnect() (s.b.)
** Make Chan Mode IE presence optional, because the non-standard PDCH
activation message is simpler and does not require it.
** Do PDCH activation via PCU.
* Add dyn_ts_l1_reconnect(): store state and disconnect the L1 channel;
then wait for cb_ts_disconnected().
* Add osmo_dyn_ts_disconnected() to cb_ts_disconnected():
verify state and connect with the new pchan type; then wait for
cb_ts_connected().
* Add osmo_dyn_ts_connected() to cb_ts_connected(), which re-issues
the cached chan activation message from before disconnecting the L1 channel.
* Also send an rf chan rel/act ack for dyn TS upon PDCH de/act via PCU.
* Add dyn_ts_pdch_release(): on channel release of a dyn TS in PDCH mode,
release via the PCU. Call from rsl_rx_rd_chan_rel().
Change-Id: I463bb6b4e57674f091c3badba9257374961c52c7
lchan_lookup in openbsc abis_rsl.c and rsl_lchan_lookup() rsl.c are the
same code, except for the log context, which is only set in abis_rsl.c.
The common code was factored out to gsm_data_shared.c in openbsc.git.
Use the *rc return code argument to keep the logging part in the newly
introduced thin wrapper lchan_lookup() in common/rsl.c. This also removes code
dup for logging
The rsl_lchan_lookup() implementation is removed from osmo-bts, so a recent
openbsc is needed to build this.
Change-Id: Ibc469b75e31560271be8633d524366442d27e6fb
Includes EGPRS specific convolutional codes, interleaving tables
and functions, burst mappings, training sequences, and parity
checks from 3GPP TS 44.060 needed to handle MCS codings 1-9.
Change-Id: Ie270398dd7a72f282ba53e646853d8de1eabee93
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Move the actual switch from static conf_lchans_for_pchan() into new 'public'
function conf_lchans_as_pchan(), adding an explicit pchan argument. This allows
passing a non-trivial pchan, for dynamic TS.
conf_lchans_as_pchan() now takes a pchan argument, so distinguish the naming
and drop the 'for_pchan' from conf_lchans_for_pchan(), which takes only a ts
argument.
Change-Id: I8e458501fff5503c243512aeb3469c12b1f2bbc4
We're about to introduce a new kind of dynamic channel, which will also use
parts of the ip.access mode dyn PDCH code paths. Make sure the general parts
have general names and mark ip.access specific parts as such.
Rename dyn_pdch_ts_[dis]connected() to cb_ts_[dis]connected().
Rename dyn_pdch_complete to ipacc_dyn_pdch_complete().
From cb_ts_[dis]connected(), factor out the current code into static
functions ipacc_dyn_pdch_[dis]connected() -- this will make sense once the
new dynamic kind is added to cb_ts_[dis]connected().
Change-Id: I7da5b7cb7b48572671f50e0dec97d9eec3083df1
Also remove related cruft: .gitignore, msc-README and adjust an in-code
comment that referenced dyn_pdch.msc.
Change-Id: Ie41a453bb5070c1f18793f646dc053a978f43fba
When receiving an OPSTART for the BTS object, also set the availability state
to OK.
Before, the availability would remain at NM_AVSTATE_DEPENDENCY, which caused an
unfortunate chain reaction resulting in osmo-bts-trx going through the
initialization sequence twice:
BTS BSC
|<-----| SITE_MANAGER OPSTART
n |----->| BTS state change: OPSTATE_DISABLED, AVSTATE_DEPENDENCY
o | | This signals to nm_statechg_event() in bts_ipaccess_nanobts.c
r | | to (a) Set BTS Attributes and (b) send BTS OPSTART
m |<-----| Set BTS Attributes (a)
a | | When osmo-bts-trx receives a Set BTS Attributes, it sends
l |----->| CHANNEL state change: OPSTATE_DISABLED x8
| | This signals the BSC to Set CHANNEL Attributes and OPSTART
i |<-----| Set CHANNEL Attributes x8
n |<-----| CHANNEL OPSTART x8
i |----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8
t | |
|<-----| BTS OPSTART (b)
| | osmo-bts-trx immediately replies with:
|----->| BTS state change: OPSTATE_ENABLED, AVSTATE_DEPENDENCY
| | Unfortunately, availability is left at DEPENDENCY,
| | and the NM_OC_BTS case in nm_statechg_event() only
| | checks for availability, not for the opstate.
| | Hence nm_statechg_event() again feels inclined to
| | to (a) Set BTS Attributes and (b) send BTS OPSTART,
| |
--+------+----- This is where the second round starts
| |
s |<-----| Set BTS Attributes (a)
e | | When osmo-bts-trx receives a Set BTS Attributes, it sends
c |----->| CHANNEL state change: OPSTATE_DISABLED x8
o | | All channels are disabled again, and then re-launched:
n |<-----| Set CHANNEL Attributes x8
d |<-----| CHANNEL OPSTART x8
|----->| CHANNEL state change: OPSTATE_ENABLED, AVSTATE_OK x8
| |
i |<-----| BTS OPSTART (b)
n | | osmo-bts-trx again sets the OPSTATE_ENABLED, but since
i | | this time it was already enabled, no further state change
t | | is sent back to the BSC.
This nightmare pivots on two hinges:
1. osmo-bts-trx fails to set BTS availability to AVSTATE_OK.
2. nm_statechg_event() fails to heed the OPSTATE_ENABLED of the BTS state
change.
Note, the configured channels from the first round were not actually taken
down, only the OML OPSTATE_DISABLED were sent.
In this commit, fix the osmo-bts-trx side: send AVSTATE_OK for the BTS object
upon sending OPSTATE_ENABLED, so that only the part marked "normal init" above
is run.
This change applies the same fix to other OML objects, which should make sense
in the same manner, within the current hackish OML implementation:
* NM_OC_BTS
* NM_OC_SITE_MANAGER
* NM_OC_BASEB_TRANSC
* NM_OC_GPRS_NSE
* NM_OC_GPRS_CELL
* NM_OC_GPRS_NSVC
This means that the NM_OC_CHANNEL case just above is identical, and thus
collapse NM_OC_CHANNEL onto the other cases. Drop the comments from
NM_OC_CHANNEL since they merely rephrase the commands themselves.
See OS#1770 for BTS and NITB logs.
Fixes: OS#1770
Change-Id: I08aa861f6100568c79750f4fbc9a32e1557b9304
Many erratic bursts are expected. To not bloat the log, notifications for this
should be on debug level.
See http://lists.osmocom.org/pipermail/openbsc/2016-July/009482.html
(Tue, 5 Jul 2016 15:38:27 -0700 / Tom Tsou <tom@tsou.cc>
/ Re: osmo-bts-trx error logs -- was: GPRS on osmo-trx not working)
Change-Id: If591c087ba8fd48564139e32930050ee8ab07001
Correct the too short padding I introduced in the commit
a55b166c6c. The result needs to
be 121 and not 120. Add static asserts to make sure it does
not happen again.
Change-Id: I3da7f3b8d3c8e12deb8b805cd15ff52a103d4e56
Back in January in commit 634c3e4648 we
changed the executable name from 'sysmobts' to 'osmo-bts-sysmo', which
is a change that has not been propagated to the contributed screenrc and
systemd init files.
Change-Id: I875a0ce4f470226e1b06ed1b7c74ca9471ebb574
* detect SID and set RTP Marker accordingly (emulate ONSET events)
* set proper FN in TCH_IND
* detect speech pause and do not send dummy 'bad' frames during that
time
Change-Id: Id518e5c667df7773c281effb9e75b66bf898f6fc
Related: OS#1750
Abstract code for checking/setting lchan's UL SID flag and RTP Marker
into generic function and use it for LC15 and sysmoBTS.
Change-Id: Ica5392e92bab29164711163e7b01adb174272883
Related: OS#1750
The cfg_trx_nominal_power_cmd added 12 days ago in
58e4e18206 was floating.
Actually add it to the TRX_NODE.
Change-Id: I89d638b2e2bb1fb9baeabe566035ff171f4bfad0
The function would currently only be called in cases where one of the if
branches catches on, but for safety's and clarity's sake, don't ts_connect
using as_pchan if no reconnect is pending.
Change-Id: I52c34065254e902bb80662fc04540901b36cb4c3
Analogous to 63b296bdd9 on osmo-bts-sysmo.
Implement bts_model_ts_disconnect() by sending an MphDisconnect message to L1.
Pass a disconnect callback to invoke dyn_pdch_ts_disconnected() in
common/rsl.c.
Implement bts_model_ts_connect() by calling ts_connect_as(). Pass a connect cb
to invoke dyn_pdch_connected() in common/rsl.c.
Change-Id: I8c8c3244c726fd6055cedb22ee11706994ff9cd4
Analogous to 294fbe104b on osmo-bts-sysmo.
For upcoming dyn PDCH switching, I want to be able to set the pchan dynamically
upon ts_connect() and not continue with OPSTART ACK, but with the dyn PDCH.
Thus recoin ts_connect(ts) to ts_connect_as(ts, pchan, cb) and leave
ts_connect() as a thin wrapper to leave init code unchanged.
Change-Id: I7a27193168f83e8c40b6e54d1842f4502d0475e5
Analogous to 0d10f0e482 on osmo-bts-sysmo.
According to the PDCH Active flag, handle a TS as TCH/F or PDCH.
Change-Id: I0c97b360136f76bdae8d70d06af9a31fdf75c1ba
Analogous to 7158c2ed08 in osmo-bts-sysmo.
Place a layer 3 handle into GSM L1 messages to better match up confirmations to
respective requests. This handle is a uint32_t transparently returned in the
confirmation messages, so a match-up is easy to add.
So far, a GSM L1 confirmation message received for a preceding L1 Request was
matched only by the prim_id. That meant that only one instance of the same
primitive could be waiting for a confirmation at any given time, or the
responses would get mixed up: the struct wait_l1_conf instances entered into
the fl1h->wlc_list queue would be returned to a possibly mismatching
confirmation handler. (Seen during testing of dyn pdch switching.)
Send the hLayer3 handle out via prim_init(), using new static functions to
produce handles on different scopes:
* l1p_handle_for_trx()
* l1p_handle_for_ts()
* l1p_handle_for_lchan()
(These could possibly move to a more general .h/.c file later.)
Remember the hLayer3 handle in
* struct wait_l1_conf.
Match the incoming confirmations' and stored hLayer3 handles up in, and remove
a now obsolete comment from:
* is_prim_compat()
Since the hLayer3 members are at different byte offsets in
GsmL1_Prim_t.u.*, use large switch statements to set/get the value:
* In prim_init(), extend existing switch statement to set in GsmL1_Prim_t.
* Add l1p_get_hLayer3() to retrieve from GsmL1_Prim_t (could possibly move to a
more general .h/.c file later).
Note that some messages are already using the hLayer3 handle, and will
overwrite it after calling prim_init(), so those are not affected.
Change-Id: I17f95ba744c3e944a2241809106506f8dd1b24f0
When switching to the gsm_chan_t_names string list from libosmogsm,
libosmogsm actually became a dependency of the local libbts.a.
The breaking change is in openbsc.git 29048b2a80b5865ffc41fa4401113c5826227e23
and came in here because gsm_data_shared.h is included from openbsc.
Change-Id: I70e5735fc2a212305182d46a7e8485d0199ade7b
Switch to using libosmocodec functions as a preparation step for DTX
support as they expose necessary bits.
Change-Id: Ie7423032fd06779d78876182ee63538d98906328
Related: OS#1750
Implement bts_model_ts_disconnect() by sending an MphDisconnect message to L1.
Pass a disconnect callback to invoke dyn_pdch_ts_disconnected() in
common/rsl.c.
Implement bts_model_ts_connect() by calling ts_connect_as(). Pass a connect cb
to invoke dyn_pdch_connected() in common/rsl.c.
Change-Id: I61709fdf6b093689a6d3a046f67db6d02f1296ae
For upcoming dyn PDCH switching, I want to be able to set the pchan dynamically
upon ts_connect() and not continue with OPSTART ACK, but with the dyn PDCH.
Thus recoin ts_connect(ts) to ts_connect_as(ts, pchan, cb) and leave
ts_connect() as a thin wrapper to leave init code unchanged.
Change-Id: I09cc794cb424e17411e608c65f2b68e2f2544e07
React on IPAC PDCH ACT and DEACT messages and invoke the PCU and bts_model_ts_*
APIs to effect switchover. The dyn PDCH interaction is described in the comment
to rsl_rx_dyn_pdch(), the main entry point for PDCH switchover.
In case the bts_model_ts_* are not implemented (or return other errors),
reply with an IPAC PDCH ACT/DEACT NACK.
Add callbacks that mark steps in the PDCH switchover process,
dyn_pdch_ts_disconnected(), dyn_pdch_ts_connected() and dyn_pdch_complete().
Add hooks in l1sap.c on channel activation and release confirmation, to call
dyn PDCH callbacks.
BTS dyn PDCH implementations should invoke dyn_pdch_ts_disconnected() and
dyn_pdch_ts_connected() when bts_model_ts_disconnect() or
bts_model_ts_connect() are called, respectively. (upcoming for sysmoBTS)
Change-Id: Id2f5f77121a65d6c14eac127b3d4fb50e97a77ab
Introduce a static function to encapsulate the decision whether a TS is
used for PDCH. Depending on the ts->flags, handle a TCH/F_PDCH TS exactly like
a standard PDCH TS.
Change-Id: Ic72fd06ecc99609823efa3edcf773007cc514b5b
Enhance bts_model_ API in preparation of dyn PDCH switching. These will be used
to re-connect a TCH/F_PDCH TS in a different mode: either as TCH/F or as PDCH.
All implementations so far return -ENOTSUP, and thus will cause a IPAC PDCH ACT
or DEACT *NACK* to be sent to the BSC as soon as these messages are handled.
Also add stubs in tests.
Change-Id: I21e60c028a1333431c3ed000f788b654d1170b0d
It is cosmetic since the 'default:' case already caught TCH_F_PDCH, but it's
good to mention all expected pchans explicitly.
Change-Id: I5aef84209e46c9288f6adf0730178fe08f26764f
Before, only standard ABIS RSL message names were logged, add ip.access
specific ones.
The IPAC_PDCH_ACT and _DEACT msgs are received with an ABIS_RSL_MDISC_DED_CHAN
discriminator, and not with _MDISC_IPACCESS like the others. Thus rsl_rx_dchan()
should be able to log ip.access message types properly.
Change-Id: I9db6826b515bf565fc7ae24fc0760b60928cc89f
Add vty command (under "phy X instance Y" hierarchy) to manually send
POWERON or POWEROFF command. It's useful for debugging issues related to
BTS/TRX initialization.
Change-Id: I6dfebaf118cdf5ad144516b2b839b17350a73ce4
Related: OS#1648
Previously software activation could have been reported multiple times
which broke proper BTS init. Introduce guard variable to ensure
reporting happens only once.
Note: this is just minimal workaround - ideally proper OML state machine
should be implemented.
Change-Id: Ifffbdb756bc5d2864f985c01a3299b839c4de7af
Related: OS#1648
- Change system devices path
- Remove obsoleted sensors and add new sensors
- Change TRX and sensors numbering to 0,1 instead of 1,2 (JFD)
Change-Id: I5172daf68d3145a6398e37df87df21b0e5affe42
Place a layer 3 handle into GSM L1 messages to better match up confirmations to
respective requests. This handle is a uint32_t transparently returned in the
confirmation messages, so a match-up is easy to add.
So far, a GSM L1 confirmation message received for a preceding L1 Request was
matched only by the prim_id. That meant that only one instance of the same
primitive could be waiting for a confirmation at any given time, or the
responses would get mixed up: the struct wait_l1_conf instances entered into
the fl1h->wlc_list queue would be returned to a possibly mismatching
confirmation handler. (Seen during testing of dyn pdch switching.)
Send the hLayer3 handle out via prim_init(), using new static functions to
produce handles on different scopes:
* l1p_handle_for_trx()
* l1p_handle_for_ts()
* l1p_handle_for_lchan()
(These could possibly move to a more general .h/.c file later.)
Remember the hLayer3 handle in
* struct wait_l1_conf.
Match the incoming confirmations' and stored hLayer3 handles up in, and remove
a now obsolete comment from:
* is_prim_compat()
Since the hLayer3 members are at different byte offsets in
GsmL1_Prim_t.u.*, use large switch statements to set/get the value:
* In prim_init(), extend existing switch statement to set in GsmL1_Prim_t.
* Add l1p_get_hLayer3() to retrieve from GsmL1_Prim_t (could possibly move to a
more general .h/.c file later).
Change-Id: Ie4533c6cbc160318917e7a672ab6f9a848f01d1b
We are using up to 48 (actually only 8) bytes to manage the boot
state of the device. Add it to the eeprom reservation. It turns out
the current padding was too large (37 + 84 don't end at 120).
Change-Id: I4c1de5925577f1d0b7b5cc08529642ffa333d7de
We have seen that the DSP time to time rejects PTCCH message from BTS due to invalid block number.
As a result, we patched FN2PTCCHBLOCK calculation according TS 45.0002 Table 6.
Change-Id: I8be1c8b9159c94788857c6de5440a418739f1212
Store last SID received over RTP and repeat is if necessary (no new SID
or SPEECH frames) according to codec-specific scheduling rules.
Related: OS#1563
Copy-paster from I4d23846a27d3dbd2a6e75e481c1efcdb2a85f305 for LC15.
Change-Id: I29acea6e8bbf426330ce52554a48afb5d2ef1679
Store last SID received over RTP and repeat is if necessary (no new SID
or SPEECH frames) according to codec-specific scheduling rules.
Change-Id: I4d23846a27d3dbd2a6e75e481c1efcdb2a85f305
Related: OS#1563
Previously frame number was not saved in case of PRIM_TCH rendering many
debug statements with g_time useless.
Copy-paste from ef30f50d5d.
Change-Id: I952b39458d921622d5964cbdcc2f4e45ff9ea951
This fixes the unstable behavior (BTS loosing subscribers after some
time) in case previous run of osmo-bts was interrupted (with ctrl+c for
example).
Change-Id: Ie2119b0b566d01f0e70b38c8a149fecb47def38d
Use libosmocodec function to parse RTP with AMR payload in sysmoBTS and
LC15. This replaces "manual" parsing of AMR frame with function covered
by test suite and makes adding DTXd support easier.
Related: OS#1563
Change-Id: I1464f9a12e3f92926d03d5dd5d18e8f0f7206dd9
Reviewed-on: https://gerrit.osmocom.org/204
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
* set/clear DTXd activity indicator for measurement reporting
* set DTXd status based on information from RSL
Related: OS#1563
Change-Id: I148a75725c4e5089b6f2da6e9adcbe94170d3257
Depends-On: I4a033b03fcd0deb4db7a38273b5407511dbf1d6c
Reviewed-on: https://gerrit.osmocom.org/220
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Compute RTP user_ts adjustment based on the difference between current
and previous FN instead of hard-coded value.
Change-Id: If1677ddcf754b29990ff7cd846e11c32e3d30b33
Related: OS#1562
Reviewed-on: https://gerrit.osmocom.org/196
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Previously frame number was not saved in case of PRIM_TCH rendering many
debug statements with g_time useless.
Change-Id: Ib8d8c919862d0de8e2ebf7753c2592e0d91b09c5
Reviewed-on: https://gerrit.osmocom.org/195
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
There is implicit invariant in trx_phy_instance() which is actively used
by various hw-specific implementations to get TRX's phy instance. Let's
make sure there's explicit assertion for this because there's been
segfaults in the past related to it.
There are several types of System Information messages with tricky
scheduling rules described in 3GPP TS 05.02 § 6.3.1.3. This GNU Awk
script takes in .csv file with sequence of scheduled SI messages (for
example generated using tshark from GSMTAP capture - see usage note
inside the script) and check the scheduling rules compliance.
I had accidently bumped the version as I thought that osmo_ph_pres_info_type
was part of the ABI. It is not an only internal to the BTS. Revert
this part of the change.
Previously osmo-bts-octphy have not provided in-band presence
information which cause off-by-one errors and misinterpretation of
ph_data_ind by PCU. This fixed now by adding support for explicitly
passing PH-DATA presence info. Corresponding check and in-band passing
of presence information are removed.
Note: this requires libosmocore version with osmo_ph_pres_info_type
support integrated.
[hfreyther/max: Remove + 1 from the decoded length]
In some cases we'd like to run multiple instances of osmo-bts on a
single machine. This is the case where we a multi-TRX PHY is to be used
for several BTSs, or in case osmo-bts-trx has multple SDRs attached.
This wa currently prevented by having a hard-coded PCU socket path
and telnet port, which are now configurable via VTY / config file
itself.
It remains up to the individual BTS hardware models to decide
whether or not to register those commands (depending on whether they
support the feature) via cfg_bts_auto_band_cmd / cfg_bts_no_auto_band_cmd
At the time the phy link / phy instance level VTY configuration
commands are parsed, we did not yet call l1if_open() and thus
pinst->u.{lc15,sysmobts}.hdl == NULL.
PHY or PHY instance specific configuration must thus be stored inside
the phy_link or phy_instance itself, and not inside the (not yet
existing) handle.
We solve this by moving around some parameters:
* clk_use_eeprom/clk_cal/clk_src/calib_path get replicated in
phy_instance
* min_qual_{rach,norm} are moved into the generic part (which means
that osmo-bts-octphy and osmo-bts-trx should also implement them)
Due to the changes introduced by the phy_link API, it's not easy to set
the default DSP trace flags via a command line argument anymore. We now
rather introduce a persitent VTY configuration command, by which the
default DSP tracing configuration can be set (for each PHY).
The persistent trace flags are stored in the phy_instance, while the
current operational run-time flags are in fl1h->phy_instance.
This includes changes required for
* shared main() function accross all BTS models
* use of the new phy_link / phy_instance infrastructure as the basis
for true multi-TRX operation
by using a talloc pool, we avoid having to go back to the libc
malloc pool all the time. The msgb allocations and libortp allocations
happen quite frequently during processing and show up as one of the
high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent
TCH/H calls (highest load scenario).
talloc still consumes significant CPU, this is mostly due to the
zero-initialization of all the associated buffers. Strictly speaking
we shouldn't need this, but any change there would require lots of
testing, as there might be hidden assumptions in the code?
In some percentage of cases, talloc still seems to fall back on malloc
for msgb allocations, which is currently a bit of a mystery. The pools
certainly are large enough, talloc_reprt() rarely reports more than a
few tens of kilobytes used by the msgb pool.
From 2ecbf87130
This commit adds basic support for the Litecell 1.5. Multi-TRX is not
supported yet. Instead, multiple instances of the BTS can be launched
using command line parameter -n <HW_TRX_NR> to specify if TRX 1 or
2 must be used by the bts. Note that only TRX 1 opens a connection to
the PCU. Full support for GPRS on both TRX will come at the same time
than the multi-TRX support.
The BTS manager has been adapted to match the new hardware but otherwise
it has not been improved or changed compared to the one used on the
SuperFemto/Litecell (sysmobts).
When the OML signalling link is lost, first set bts->oml_link = NULL,
then iterate over the RSL links and close them. Closing the RSL link
will cause a OML state change message to be sent, which in turn tries
to use the no-longer-existing OML link.
The code should be cleaned up further to distinguish which signalling
link was lost, and actually communicate a RSL(only) loss to OML.
But for now, it's best to simply close down all links and terminate
osmo-bts to ensure all state is properly reset and recovered.
this introduces the new phy_link / phy_instance interface, which is the
basis of clean support for all kinds of multi-trx configurations with
various BTS modules.
WARNING: This breaks configuration file compatibility. You will need to
introduce config nodes for 'phy' and 'instance', as well as the link
from the 'trx' nodes towards the phy instance.
It seems the right thing to do: Once we know a PHY link is established,
the associated OML managed objects should change their state
accordingly. However, given all the hackery we do with MO states, this
actually breaks things, rather than helping. So I'm disabling that part
for now, but this needs to be re-visited at some point.
This splits the TRX scheduler into a generic part and an osmo-bts-trx
specific part. It is the basis for re-using the scheduler from other
bts modules such as the upcoming osmo-bts-virtual.
the backend is performing the actual encoding and decoding functions,
while the generic part constsits of the TDMA structures and generating
the RTS.ind
The L1 scheduler is a generally useful component that is unfortunately
tied quite a bit into the OsmoTRX support. Let's try to separate it out
by having separate per-trx/per-ts/per-chan data structures pre-fixed
with l1sched_
Using this patch it should be one step easier to use the scheduler for
other BTS models, such as the intended upcoming virtual BTS.
During the L1SAP related changes, somehow an old version of
check_for_ciph_cmd() was re-introduced, which didn't store the N(s) as
part of the lchan. To make things worse, the old code was still present
in the sysmobts specific part, but never executed.
When the oml_link is down or not yet established, we currently lost
any OML messages that were scheduled for transmission to the BSC. Let's
prevent that by keeping a queue of OML messages, which is drained at the
time the OML link comes up again.
Use the right identifier for the timeslot and not the trx number
which would always use ts==0 on the first trx. This should fix
ciphering issues for TS>0 (e.g. SDCCH8 on TS==1)
It seems that once we start to respect the T200 values as specified by
the BSC, we run into all kinds of issues with LAPDm re-transmissions,
REJ frames, unexpected supervisory frames and the like.
The libosmogsm LAPDm T200 defaults of 1s/2s are proven to "work" (i.e.
not expose the above behavior), so let's revert to them until the root
cause of this problem is determined.
The T200 default values should be in milli-seconds (as the variable name
indicates). They are not expected to be divided by the TS 12.21 OML
dividers for T200.
This change doesn't really make a difference with OpenBSC, as the BSC
always sets its own T200 values via OML, overwriting the defaults here.
There's no need to use memcpy(), which adds the risk that the types of
source and destination are not the same (see previous commit). Iterating
over the array and assigning each element is more robust.
t200_ms is an unsigned int [7] array, while the oml_default_t200_ms was
an uint8_t[7] array, which we memcpy() to the former as default
initializer. Fix this by turning oml_default_t200_ms into unsigned int,
too.
We re-use the 'wait_l1_conf' structure for implementing the
unacknowledge command window towards the PHY. This means that thre will
unconditionally be a 'wait_l1_conf' now, even for requests where the
caller didn't provide a call-back.
When re-starting OsmoBTS after unclean shutdown, the PHY is already
sending notifications (PH-DATA.ind, PH-TIME.ind, etc.) for the previous
physical channel / timeslot configuration. At the point those messages
are received, OsmoBTS might not even have A-bis OML up yet, and thus has
no clue how to process such messages (and subsequently likely crashes).
Let's block such primitives from passing further up the code until we
have received the TRX-OPEN response.
When writing the config file from the command line, we must not forget
to write the phy-netdev parameter, otherwise the program will fail to
re-start later :/
sysmobts-calib might be easily patched by a user that does not know
that firmware and firmware headers form a contract that should be
matched. Compare the version numbers and print a warning if it does
not look correct. This should be enough for a user to see that something
is not right. Continue anyway as the firmware might still be compatible
(because the ABI has not changed).
Fixes: SYS#1172
If using a too old kernel on newer devices the eeprom reading will
fail and maybe it is not possible to update the kernel after the
unit has been deployed.
Add a utility to read the EEPROM of revD+ from userspace to be used
to fix up the thing.
# Split common DSP call log file (produced by superfemto-compatible firmware) into 4 separate call leg files (MO/MT & DL/UL) with events in format "FN EVENT_TYPE":
cat $1.raw | cut -f2 -d')'| cut -f1 -d','| cut -f2 -d'>'| sed 's/\[u32Fn/fn/'| sed 's/\[ u32Fn/fn/'| sed 's/fn = /fn=/'| sed 's/fn=//'| sed 's/\[Fn=//'| sed 's/ An Onset will be inserted.//' > $1.tmp1
}
PREP "$1.DL.MT"
PREP "$1.DL.MO"
PREP "$1.UL.MT"
PREP "$1.UL.MO"
RD(){# reformat DL logs for consistency checks
cat $1.tmp1 | sed "$D_FST"| sed "$D_SPE"| sed "$D_FS1"| sed "$D_FS2"| sed "$D_UIN"| sed "$D_FIN"| sed "$D_UPD"| sed "$D_INH"| sed "$D_RP1"| sed "$D_ONS"| sed "$D_EMP"| sed "$D_FAC"| sed "$D_FO1"| sed "$D_FO2"| sed "$D_FP2" > $1.tmp2
}
RU(){# reformat UL logs for consistency checks
cat $1.tmp1 | sed "$U_FST"| sed "$U_SPE"| sed "$U_FP1"| sed "$U_FP2"| sed "$U_UPD"| sed "$U_ONS"| sed "$U_NOD"| sed "$U_UIN"| sed "$U_FIN"| sed "$U_RAT" > $1.tmp2
== Support for Dynamic Timeslots (TCH/F, TCH/H, PDCH)
OsmoBTS supports dynamic switchover of timeslots between different physical
channel configurations, initiated by the BSC via (non-standard) Abis messages
-- see the _OsmoBTS Abis Protocol Specification_ <<osmobts-abis-spec>>.
The Abis message handling for dynamic timeslots is independent of the BTS
model. However, dynamic switchover will only work for BTS models that implement
the internal API to reconnect a timeslot (_bts_model_ts_disconnect()_ and
_bts_model_ts_connect()_, see also <<osmobts_hardware_support>>).
Currently, these OsmoBTS models support dynamic timeslots:
* _osmo-bts-sysmo_
* _osmo-bts-litecell15_
* _osmo-bts-trx_
Dynamic timeslots are driven by the BSC and need to be configured there. When
using OsmoBSC or OsmoNITB, see the BTS configuration chapter on dynamic
timeslots in <<userman-osmobsc>> or <<userman-osmonitb>>, respectively.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
