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
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.